Slashdot Mirror
How Heraclitus would Design a Programming Language
CowboyRobot writes "Developer of Smalltalk Alan Kay has an interview on ACM Queue where he describes the history of computing and his approach to designing languages. Kay has an impressive resume (PARC, ARPAnet, Atari, Apple, Alan Turing Award winner) and has an endless supply of memorable quotes: 'Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term,' 'Once you have something that grows faster than education grows, you're always going to get a pop culture,' 'most undergraduate degrees in computer science these days are basically Java vocational training,' 'All creativity is an extended form of a joke,' and 'nobody really knows how to design a good language.'"
"The trouble is developers would prefer to write something in 5 characters than 30 characters in a mistaken belief that they are being more productive and that typing is the longest task they undertake."
I could not agree more. In fact we use some software with an internal scripting langauge...it is vector based and the company lures people in by say you need 30% less lines of code...to which I respond...so what. Frustrating. I don't care how many lines of code it takes as long as the flow is meaningful and understandable.
what?
Perl fills a 'tiny short-term need'? Is that why Morgan Stanley, RyanAir, Amazon, Ticketmaster and even increasingly Google to name but a few are using it for real, business-critical applications?
I'm so sick of all this anti-Perl talk. I write powerful applications in Perl and they are definetly not 'write only'. If anyone writes a 'write only' program in any language then it is the programmer who is at fault. Perl assumes a bit of intelligence on the programmer's side, rather than adopting Java's policy of bondage. And contrary to what a previous comment said, Perl is a general purpose language (with excellent built-in data structures and regular expressions, and a convenient and expressive syntax).
This guy might have an impressive [sic] resume, but he is badly showing his ignorance about Perl.
Yeah, but Larry Wall says that hubris is one of the three chief virtues of a programmer, so it's okay.
b. Early Descriptor Architectures in Capability-Based Computer Systems (nice book -- great to see it available again)
echo 33676832766569823265328479713269.8639857989Pq | dc
Kay works a lot on new ideas, many of them being incorporated into Squeak and Croquet. The ideas are still rough, though, so in some cases I don't know if I'd say they were accessible yet. Such is the nature of research. (But even kids are using Squeak.)
I agree completely. I have used Perl and it is one of the eisiest to use languages I have found, and it does not encourage one to write bad code. If someone is going to write bad code, they will write bad code in any language they use, they will find a way. Creating a restrictive language actually I believe can make the language worse, by placing a lot of arbitrary limitations on what can be done, the language can be made much more difficult for the programmer to use when they really do need to do something unusual, probably increasing the chances of an ugly hack. Perl makes simple things simple but if you need to do something more complex and demanding it doesnt make those things more complex than they need to be by saying, to borrow a phrase from 2001, "Sorry, I can't let you do that, Dave", placing a bunch of limitations on you.
I have written very readable Perl applications and I have found that when I show and teach other people Perl they too also write well written and readable applications, its quite natural, Perl makes writing well written applications that are clear quite easy, in fact, to me, it is eiser to read and understand a Perl program than it is a C or C++, far eisier in fact.
Perl also gives me a powerful environment that allows me to easily write powerful and large applications which are yet still maintainable, easily and quickly with minimal fuss.
Perl does things a bit differently than some other languages, especially in regards to its OO usage. But just because something is different doesnt mean it is bad. Some people it seems automatically if something is different they automatically think it is bad. However, i think perls OO system is actually very elegant and useable, at least as much so as the OO systems in Ruby, Python etc.
Perl, to me anyway, is powerful, rich, easy to use, and in which it is quite natural to write readable code, and has allowed me to write better code faster.
So I don't particularly like his pigoenholing of lisp - he says there were three working extensible languages, and smalltalk was one of them, kindof not mentioning however, that lisp _wrote the book_ on extensible languages.
I wouldn't be that hard on him.
If you search him further you'll see he has probably done more to promote Lisp than most others whose speciality isn't _already_ Lisp.
In his Turing award lecture this past October at OOSPLA 2004, he told the audience (paraphrased): "you owe it to yourself and your profession to seriously learn Lisp".
-Stu
This article has an interesting comparison between C, C++, Java, Perl, Python, Rexx, and Tcl.
If you want a quick and simple answer, you can't go wrong learning Python and/or C#: they are good, useful compromises between language design and practicality and if you do anything with computers, you'll probably find a use for them at some point. And they support and teach what are generally considered good mainstream programming practices. (Python has excellent numerical support, by the way, and may be a reasonable alternative to MATLAB if you don't depend on toolboxes that aren't available for Python yet.)
It is perfectly fine, though, to stick with C and MATLAB as long as they work for you; programming languages are a means to an end, and everybody's needs are different. I was using MATLAB for many years even though I thought the language sucked, and I stopped using it only when the language actually started getting in the way too much.
First off, every language has its purpose, and just because some of these languages aren't as well designed as the author's languages, that's not a good enough excuse to bash them.
When someone like Alan Kay, with a very inventive and academic background, criticizes the workhorse stuff out in the "real world", he's pointing out where the ideas don't work, rather than the thing itself. Basically, he's thinking on another level than the one most of us are.
He's not really saying Java just sucks. He's Java sucks insofar as it was founded on some bad ideas. That doesn't mean you can't or shouldn't do real work in it. It just means that there are limits to what you can do with it. Someone like Alan Kay can't really get over this, which is part of what makes him a genius.
Paul Graham (who, of course, is a big fan of Lisp), has written quite a bit on language design. I think I would have reacted to this interview the same way you have had I not read The Hundred-Year Language, and others. I highly recommend them.
Don't become a regular here -- you will become retarded.
> > You can specify layout of data down to the byte-order and bit-width,
> Replace "can" with "must", because what some view as a priviledge, others will find an obligation.
Except that it's not an obligation in Ada. It's an option available for when you need it. I almost never use it.
> > Ada didn't catch on much more are down to an early lack of good compilers
> Which was a direct consequence of language overcomplexity.
Yes, Ada overchallenged the compiler technology of the time. That problem has long since been surmounted: you can now get the GPL'd source code for a compliant Ada compiler (GNAT), and you can get commercial support for it if you wish (Ada Core Technologies).
> Writing a complete, minimally adequate C compiler is 6-month's work for a talented undergrad. Writing a complete Ada compiler...?
Given that the compilers already exist and are freely available, that's hardly an issue when choosing a language for an application. I happen to prefer the language that lets me write minimally buggy, highly maintainable code quickly, even if it did take someone more work to create the compiler.
Sheesh, evil *and* a jerk. -- Jade