Lambda the Ultimate

Seems it was mentioned already. Sorry about that.

It seems to me, listening to these people talk, as if they are trying to cover up something, almost as if they are embarrassed these things are used like they are. It is important to note that Java wasn't meant to be more than a language for set-top boxes, a C++ with a VM, until Sun saw it as a potential revenue generator. C was for Unix building and C++ was an experiment in C. The reason they all took off is because you can do things in them without knowing the real computer science behind the ideas (especially Java, although C# is becoming a little academic now-a-days).

For instance, how many Java programmers do you think look at inner classes and see them as a poor man's closures, and understands the concept of closures and the reasons why the Java hack doesn't add up? I'd suspect very few.

In my mind, the next language for moving computer science forward has to be from the Lisp branch, because of it's flexibility and power. Sadly, we're getting more abstracted Java languages (RoR) and that isn't going to expand anyone's mind. Algol languages are getting so top-heavy because of their verboseness that the IDEs are in the GIGs now, implementation of applications written in these languages have a failure rate of 70% and new languages are still pushing the code out and down more, instead of sideways.

Java has always been, in my mind, a wrapper around a database with some poor interfaces stapled on top for web, desktop (swing,awt) and mobile. It's CRUD enabling, and that's all it can ever be. You can have as many objects dancing around caching and adapting and abstracting as much as you want, but at the end of the day, they all have to report to the same inflexible master.

In fact, many patterns are simply ways of managing the complexity their own existance brings about.

I think the idea of a database being invisible, and code / data being thought of as one and the same and automatically persisted is the important next step. The idea of making our code relational and then worrying about another relational model on another server and syncing with that will become laughable, Oracle be damned.

Of course, this already exists (Allegro 8.0) but to do this you need a large business advocate, and since Sun was interested in quickly converting C++ users (later, post Gosling) and Microsoft was interested in quickly converting Java users, the desire for innovation is just not there because of the need for the quick get.

We're still in the dark ages it would seem.

I agree 100% with your conclusions. It seems that instead of less code and less testing we get more code and more testing for the same task as yesterday...

...implementation of applications written in these languages have a failure rate of 70%...

Where does 70% percent come from? And what do you mean by "failure"? By failure do you mean -- you can't even run the blasted thing? Or, it doesn't do what you wanted? You couldn't compile it in the first pass? Or...?

Most of the time it means that it does not do what you wanted. It also means nasty bugs like wild pointers, memory corruption etc.

Maybe we should remember what Richard Gabriel stated 1996 in "Patterns of Software" that Lisp went down in the late 80s - early 90s with all the Lisp machine and AI companies because big vendors moved to C++ considering C++ maintenance as safer, cheaper and simpler. I don't believe they will revise their judgement about Lisp 15 yrs later just because scripts will now be stored in databases.

We're still in the dark ages it would seem.

I always thought the "dark ages" were also those of the big cathedrals some software engineers would like to construct? Mental disorientation?

Kay

Maybe we should remember what Richard Gabriel stated 1996 in "Patterns of Software" that Lisp went down in the late 80s - early 90s with all the Lisp machine and AI companies because big vendors moved to C++ considering C++ maintenance as safer, cheaper and simpler. I don't believe they will revise their judgement about Lisp 15 yrs later just because scripts will now be stored in databases.

The grass is always greener on the other side of the fence. C++ seemed safer, cheaper, and simpler, but C++ didn't last long. For the most part C++ has lost to Java (C# in Microsoft shops), which was supposed to be this really great language. Now there is a large group of disillusioned Java programmers looking to languages like Ruby or Python to save the day. My guess is this sort of thinking will continue ad infinitum, not because languages are improving (most in the language community will agree that there hasn’t been a whole lot of ground breaking research in languages for the past 20 years, especially research that has found its way into mainstream languages), but because “the grass is always greener on the other side of the fence.”

The unknown always promises the best to those who are optimistic enough to believe, despite what history has shown us, the next popular language will fix all our problems. A quick glance at our past shows us that despite all the optimism, languages don’t deliver on the promises, because languages can’t fix the idealism of optimistic managers who believe some technology will fix all of their bad decisions (decisions which may include, but are not limited to, hiring the wrong programmers and choosing the wrong language).

That said, Hindsight is twenty/twenty (I’m full of clichés today, aren’t I?). In other words, why should be believe that managers will not conclude that Lisp was the better choice 15 to 20 years later? For the most part it’s a different set of managers, so they wouldn’t be admitting to making a mistake (“those managers before us made some bad decisions that we need to fix”). In hindsight, C++ clearly wasn’t the answer and Java doesn’t look like the answer either. The previous generation of managers made some bad decisions, what’s to say that moving from Lisp to C++ wasn’t one of them? (I’m not arguing for or against here, I’m just pointing out a possible reasoning of a modern technology manager).

Not all languages are created equal. However what language is best varies from person to person. If all people had the same thinking process then we would all be writers, artists, and mathematicians, but we’re not because we don’t have the same thinking process. Even among those who are writers, artists, or mathematicians the thinking process varies. This is evident by the variation in literature, art, and styles of mathematical proof and the varieties of mathematics, from Numerical Analysis to Group Theory. Java isn’t the language for the masses, and neither is Python. If this were so, then why are many Java programmers getting hyped up on Python or Ruby? Why do so many programmers consider Lisp or Scheme to be the most elegant language? The truth is, Scheme fits the thinking of some programmers and another language (especially one that isn’t functional) feels foreign and even wrong when the most obvious solution is simple and elegant in Scheme (and very likely not even possible in the other language). The same is true of Python. Why do you suppose there is so much argument over ideas like map() and reduce() in Python? Why is the debate so heated? Because, those who find functions like map() and reduce() intuitive, cannot fathom why Guido would consider them worthless and claim the incomprehensible list comprehension more readable. Likewise Guido cannot fathom why some programmers argue in favor of retaining map() and reduce() when list comprehensions are clearly more readable, and just as powerful.