[Nomen-dev] Pragmatic Language
Brought to you by:
bhurt
|
From: Brian H. <bh...@sp...> - 2003-10-22 21:38:32
|
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 |