[clue-talk] Stupid OCaml tricks

Nate Duehr nate at natetech.com
Tue Aug 15 01:16:47 MDT 2006


Now that I have some time, I'll jump back to Matt's comments, 'cause  
I really liked a number of them, and they helped me see some holes in  
my thought process.

On Aug 14, 2006, at 4:16 PM, Matt Gushee wrote:

> "They're both doing the same things at the hardware level."
>
> Sure, but I'm talking about an *interactive* program, not batch  
> processing. What happens when is crucial.

Great point.  See my comments about me not being a GUI coder.  :-)

>> I very much disagree with your statement that performance is more  
>> negatively affected by the first example vs. yours.
>
> Perhaps I should have qualified that statement a bit. The key point  
> is that in my version the branching is restricted to the time when  
> the user specifically invokes a mode change, which in my opinion is  
> the time when delays will be most tolerable. (BTW, I notice you  
> haven't really addressed my other point, about the design of the  
> program).

Ha, I avoided the design, 'cause I'm CLUELESS on that part.  I was  
able to effectively read your code, even in a language I don't know  
-- and coming from a sysadmin who's trudged through some REALLY  
crappy code in my day to find a silly bug or prove it was there to  
kick it back over the hill to the highlands of "Engineering - Where  
the magic happens"... (heh)... I can definitely say it's a HUGE plus  
that you can write READABLE code that someone with a background in  
sysadmin and programming can easily figure out what (generally)  
you're doing, even if it's a language they don't know the syntax of.

> I don't think the number of languages *in existence* has anything  
> to do with it. Surely, the number of *layers* in any given system  
> does. And I suppose if any given individual or group is involved  
> with too many languages to master any one of them, that's obviously  
> an issue. But the fact that something is new (or different) doesn't  
> mean it's badly designed or implemented. Java vs. C#? Sure, we  
> dislike Microsoft for various reasons, and we know they've released  
> a lot of crappy software. And C# is specifically a me-too language.  
> Nonetheless, it has been argued by people who have no particular  
> axe to grind that C# is better-done than Java. I don't really know  
> if that's true or not, and don't really care--I could come up with  
> a dozen similar examples, some of which will be true. BTW, OCaml  
> isn't all that new--it's been around since 1985, and has its roots  
> in Standard ML, which existed for maybe 20 years before that.

My concern with all the languages is similar to the "real-world"  
problem of languages... if everyone has their own pet language, how  
does anyone not using that pet language really benefit from it?  You  
mentioned that it takes some uber-geek skills to code in a lot of  
languages and I definitely agree with that!  Kinda my point in  
reverse... if it takes that level of brainpower, why is there a new  
language every year, it seems?  In 20+ years of computers doing the  
real work of business, we haven't hit upon a few languages that so  
far outstrip there counterparts at doing a MAJORITY of standard  
computing tasks that we keep making more?  Just thoughts... no harm  
meant by it.

>> I'm not sure how you get the typical coder off of his/her huge  
>> interest in "new things" long enough to explain that new languages  
>> are just "yet another boring abstraction tool"
>
> They are that, but they're not just that. Maybe for someone who's  
> such a friggin' genius they can look at any programming language  
> and see straight through to the assembly code behind it, it makes  
> no difference what language they use. Most people aren't quite that  
> smart (or maybe I should say their intelligence is focused  
> elsewhere), so I will insist that the structure and syntax of the  
> language--and the idioms--can make a big difference in how  
> effectively you can think about the program--and thus how  
> productive you are in going from design to implementation.

Funny - this also is my point I'm having a hard time putting in  
words.  With so many different factions of people coding in various  
"stuff"... as a whole, the "focus" doesn't seem to be there to kick  
IT to a higher level overall.  Right now it seems like we're in a  
stage where someday we'll look back fondly and thing... wow, did  
people really code in four or five different languages just to build  
a web page?

>> and get them to focus in on solid code writing and quality output.
>
> Always important. I don't disagree with you there.

We all seem to agree on this point, but I don't see the industry as a  
whole moving toward real action to force this issue.  Bad code is  
released every day in business... REALLY bad code.  Some of the bugs  
I've seen supporting commercial products have been of the variety  
that you scratch your head and go... "How did THAT make it by so many  
people?  That's 2nd year programming silliness!"

>> Maybe it is best summarized this way: If two programs produce the  
>> same inputs and outputs and are written in two different  
>> languages... Who cares?  Only the programmer.  The end-users don't  
>> care about what it's written in, and never will
>
> Certainly the users don't care, and that's probably a good thing.  
> Because if they did care, they would probably be demanding software  
> written in Visual Basic or Java.

Heh... some shops do this.  Not sure if that's good or bad...

>
>> and instead have the discipline to work on refining the code  
>> written in whatever language I already wrote it in.  So maybe this  
>> revelation will help me personally to stop screwing around with  
>> whatever language fad has hit this year and work on a longer-term  
>> goal of writing stuff that works so well, no one cares what  
>> language it was written in.
>
> Sure. OCaml isn't a fad, though. It's got a lot of solid theory and  
> practice behind it, and a small but smart and serious community  
> around it. My presentation is likely the most hype you'll ever see  
> about it. You want fads? Try Ruby on Rails.

Heh heh.. I played with that fad a bit.  It did do some nifty  
stuff... (haha... proof that I can be wooed by shiny objects -- no  
pun intended? -- too!)
>>

>> Just some thoughts... what do you think?  I really think  
>> evangelizing ANY language is far less useful than just working on  
>> stuff... at this point.
>
> You may be right, but then why have meetings and presentations at all?

Hmmm.. ouch.  Okay okay.

> And personally, I'm not a big fan of technology evangelism in  
> general. One of the reasons I didn't do well as a "technical  
> instructor" was that a large part of the "instruction" was supposed  
> to be uncritical evangelism of XML, about which I always had some  
> skepticism. For what it's worth, I couldn't advocate any technology  
> unless I truly believed it was worthwhile, and even then I try to  
> be honest about its shortcomings.

We'd get along in person, I'm sure... haha... I'd make a horrible  
salesman, 'cause people get scared off when you talk honestly about  
the shortcomings of any system you're trying to sell them!  :-)  Then  
the next sales guy (competitor) will pitch his product without the  
negatives even if it's worse, and I'd lose the sale!  Some people  
were just meant to work on keeping infrastructure running, and far  
away from prospective customers... methinks.  I could probably  
swallow my misgivings and sell something I really had to, in order to  
eat, if it ever came to that... but it'd be no fun at all for me.

>> Faster and faster machines make it "not worth looking at" in most  
>> applications.
>
> That's an interesting point. I think it depends partly on who your  
> users are. If you are an enterprise developer, nobody cares about  
> performance because they can just buy more hardware and recover the  
> costs from their customers. If you are targeting home and small- 
> business users I think performance still matters--though not  
> necessarily in the sense of raw number-crunching performance. But  
> the responsiveness of a GUI, for example, is very important, and  
> often neglected because it isn't glamorous (and you can sell  
> millions of $$ worth of software before people find out how badly  
> it sucks). If I were still trying to make a living as a developer I  
> would be targeting the latter market, probably small businesses in  
> particular, because those are people that I respect.

Linksys routers are a pretty good case in point -- they used Linux  
and they might feel the got "bitten" by embedding it and eventually  
having to open their source, but the spin-offs for the little Linksys  
routers have been pretty impressive.   I have a DD-WRT load on my  
Linksys here, and that was "something new" that really made me happy  
about Linux and where it's grown into.  Embedded stuff that works  
well is soooo nifty.  Especially if it's really inexpensive too.
>>

>> Joel's comments above about knowing how the hardware works all the  
>> way down to the bit level, is very interesting.  If you had to  
>> guess, out of all the developers you've met, how many have coded  
>> in Assembly on their chosen work platform?  Not many, I'd say.   
>> Ever meet someone who has coded in Assembly on their chosen  
>> platform that didn't know their "stuff" ten times better than  
>> everyone else you ever worked with on that platform?  Not me.   
>> Anyone who's had the discipline to go to that level -- is always  
>> an EXCELLENT programmer.  They usually have amazing insight into  
>> how to get the most out of the chosen hardware platform too.
>
> That's a valid point, and I think people like that (like you,  
> maybe?) deserve more recognition and respect than they often seem  
> to get. But that's not the whole picture: someone needs to design  
> applications for users--*for people.* Very few people are good at  
> both aspects of the job, but both have to be done well to create a  
> really good product.

Probably not me... I just wish I supported some of those brainiac  
guy's code and less code with serious goofs in it.  :-)  Being in the  
customer support "trenches" for going on 10 years now... maybe I'm  
just needing to get away from some of it and spend some time writing  
something nifty, or whatever.   What I'm really good at is managing  
large server farms, but it's hard to prove that's "what you do well"  
if you haven't done it in a while... one of my projects I help out  
with now has over 1000 machines, all rsync updated every night with  
any new code, and just keeps chugging along... the whole thing is  
done in shell scripts.  Amazingly fun.  It definitely was a "team  
effort" of a lot of folks scattered around the U.S., Canada, and  
Australia.  (Somehow the UK never got involved heavily in the server  
side of that project, but they're active...)  Nifty.  The code is  
truly spaghetti, though... bunch of non-coder sysadmins hacked it all  
together... heh.  Like me.

>> Take (for another example) GUI interfaces.  Has any REAL paradigm  
>> change happened in them since the machines at Xerox added a  
>> mouse?  Sure they're prettier, but not a single bit easier to use  
>> for anyone.  Some people take the time to try to make them as good  
>> as possible, but it's so rare... they'd rather switch from raw X  
>> coding, to Qt, to GDK, to god knows whatever else every few years  
>> and never produce anything really different or better,
>
> True. The GUI toolkits just keep on getting more complex. But I  
> don't think either going back to basics (raw Xlib) or continuing to  
> add layers is the solution. Widget libraries give you productivity  
> in creating applications, but that doesn't mean that more is  
> better. I think there must be a happy medium somewhere.

Definitely.  I think I need to go play with some of them... maybe  
it's time... that or I'm going to disappear into the underbelly of  
direct chip coding and go play with more embedded stuff.  Not sure  
yet.  Kinda at a cross-roads (self-inflicted) right now...

Perhaps I should try out OCaml!  :-)  Heh heh...

--
Nate Duehr
nate at natetech.com






More information about the clue-talk mailing list