[Nomen-dev] Pragmatic Language

[Brian H. <bh...@sp...>]

While I'm "bombarding" this list with traffic, I'm going to make more 
comments.  I heard about "praglang"- the Pragmatic Programming Language, 
back when it was posted to slashdot.

Here's the link which precipitated this diatribe:
http://lambda.weblogs.com/2003/10/22#a9361
but first, I want to rant a little bit on praglang in general.

I'm a *huge* fan of the book Pragmatic Programmer.  If you haven't already 
read this book, run, don't walk, to the bookstore, buy a copy, and read it 
now:
http://www.amazon.com/exec/obidos/tg/detail/-/020161622X/qid=1066855949/sr=1-1/ref=sr_1_1/103-3353375-7406269?v=glance&s=books

One of the things they recommend in this book is that you should learn a 
new programming language every year (after a couple of decades you can 
probably slack off a bit).  No one language is perfect for everything, and 
the more languages (and the more different types of languages) you know, 
the more likely you will know a good language for any given problem.

As such, the very idea of "the ultimate pragmatic programming language" is 
a contriction in terms.  Making the one perfect language for a philosophy 
that doesn't beleive in the one perfect language is, um, futile at best.

I was subsribed to the list for a couple of weeks, and played the 
curmudgeon.  The philosophical oxymoron isn't the only error they're 
committing.  They're also doing design by committee- a death knell for an 
open source project.  Every successfull FOSS project I know of started as 
a small number of people (often one) writting code.  Every FOSS project 
that I know of that started as a wish list never got anywhere.  Starting 
as a tar-ball of code is no gaurentee of success, more like starting as a 
wishlist and a committee is a gaurentee of failure.  Even when design by 
committee projects are driven through to completion, I'd still label them 
as failures- consider C++ as an example.

Worse yet, from my (short) stint on the mailing list, I've already
identified three camps- the Java camp, the Python/Ruby camp, and the
Lisp/Haskell camp.  Each camp has it's idea of what praglang should be
like- it should be like their other favorite language, just slightly
different.  The approximate breakdown of the list was 50% Python/Ruby, 40%
Java, 10% Lisp/Haskell.  Which means that the list, last time I checked 
it, was one long religous flame-war on programming paradigms.  Which gets 
me back to the original link: I've expected an effort to drive out the 
Lisp/Haskell heretics for a while now.  I didn't expect it to be so, um, 
lame.

The example he uses is incredibly bad.  Basically, he is increasing the 
interdependency of the modules.  He has five modules, A calling B, B 
calling C, C calling D, and D calling E.  He now wants to instrument E and 
pull the data into A?  A) Why?  I can see wanting to gather 
instrumentation data and handing it off to another program (profiling), 
but why should A care how often E is called, if at all?  B) In doing so, 
he is adding implicit direct dependencies between A and (C and D).  Before 
A didn't care who B called to get it's result.  Now A depends upon B 
calling C, C calling D, and D calling E.  Change any of these- say, 
changing C so that it calls D' which calls E', instead of calling D which 
calls E- can break A.  Unless A doesn't care if E is called at all, in 
which case we're back to "so why does A need to know this?".

There is a need for imperitive programming- there are things you can do in 
O(1) with imperitive, which take O(log N) in functional.  The classic 
example is that an array lookup is O(1), while a balanced tree traversal 
is O(log N).  This can make a large difference in the speed of the program 
(10-fold plus speed differences), so it's important.  But this example is 
just stupid.

Brian