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.'"
LOL - i like it :)
I'd disagree that there aren't people who can design decent languages. The problem is that they can't market them, and that developers continue to go back to the brain-dead syntax of C as if looking like C was an aspiration for a language.
Languages like Ada, Eiffel etc (which yes I have used commercially) are brilliant from a language perspective, especially for large projects. 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.
When you get into more "esoteric" areas like goal driven programming or agents then the languages become better, because the people using them are more aware of the purpose of the language and aren't constrained by a belief that it has to look like C.
C# and Java are great example of languages that took on that syntax and many of the constructs as its easier to get a language accepted when it looks like C than when a developer has to learn a new syntax that will in the long run be better.
The problem isn't language designers its us developers, we don't want to spend a week learning a new syntax for a loop, we want to use what we used before. In other words we are luddites.
Smalltalk was okay, but I prefered Eiffel, Java and C# are both by comparison rubbish, but they have better GUI libraries and marketing departments.
An Eye for an Eye will make the whole world blind - Gandhi
nobody really knows how to design a good language
s/good/universal/
PHP is good for web programming
Perl is good for system scripting
Java is good for object manipulation
C++ is good for GUI
ADA is good for secure stuff
Regexp is good for substitutions
ARM/Assembly is excellent for embedded apps (depending on your platform)...
Trolling using another account since 2005.
I would suggest targetting Parrot [slashdot.org] which makes implementing compilers 1000 times easier than ever before,
In light of more than half a century of dynamic language history, that's just astounding hubris. By comparison with systems like Lisp and Dylan, for example, the Parrot system is still enormously complex, limited, and cumbersome from the programmer's point of view. And compared to Smalltalk, Perl/Parrot isn't even in the same league when it comes to programming environments, browsers, and other tools (in fact, very little really is).
Kay's example of Perl as a language that reinvents the wheel poorly is as appropriate today with Parrot as it was for earlier versions of Perl. The fact that Perl is useful in practice (I use it all the time) because it has lots of libraries and ports doesn't change the fact that its foundations are poorly thought out.
But Perl! Ah, Perl! Such a bundle of contradictions! It violated every rule I held dear about language theory, and was a better language for it. Perl doesn't try to be a theoretically perfect language for any particular theory of linguistic perfection. It has principles, but it is not a slave to those principles. It has a degree of consistency, but never a foolish consistency.
No language on Earth has made me rethink my concepts of "what makes a good language" more than Perl.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
I kindof get the impression Kay hasn't looked at modern lisp as much as historic lisp - for starters, lisp has had structured data for, well, decades (no, lisp doesn't just do symbols and lists, okay?), and while us lispers applying lessons from compsci type theory piecemeal to practical lisp drives the static-typing bigots/purists into insane flamewars, the existence-proof of the applicability of such lessons that availability of type-inferencing lisp compilers such as CMUCL and SBCL shows that Kay's comments about lisp and types are again, while not exactly wrong, are mostly applicable to the lisp of yore (and with, lisp, we're really talking _yore_, compared to almost any still-used language around today except FORTRAN), not ANSI Common Lisp.
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. Every good lisp program extends the vocabulary of the lisp language into the problem domain (a characteristic shared with good Forth).
I confidently predict something vaguely recognisable as "Lisp" will outlast pretty much every other computer language on the planet. You see, new dynamic languages have a choice when they get to a certain point (a choice e.g. python is now facing) - do they add the remaining features of lisp and thereby "risk" being classed as a reinvented dialect of lisp, or refuse those features, maintain their independent identity, but forever cripple their language compared to lisp?
But I think that's as much as a function of the fact that a developer today is standing on the shoulders of giants more than ever.
To quote Isaac Newton, "If I have been able to see farther, it is only because I have stood on the shoulders of giants."
Frankly, we've hit a point where there's a lot less "science" in Computer Science, or rather, the need for such training in many programming jobs.
There's nothing wrong with a well rounded education but for some people they don't have the time or inclination to take on full engineering curriculums (as I did).
While I don't mind have gotten a rounded education in light of where tech careers have gone, it's too bad I didn't follow my father... construction. Given his real estate holdings, I doubt I will reach his station in life (economically) if I stay on a pure tech track... highly unlikely.
So if CS degrees are nowadays more about vocational training, so what. A tech degree of any kind, no matter how full of yourself you are, is not going to take you where it once might. That's reality. For all the noise we hear about a focus on math & science, it seems to me to be rendered somewhat moot since some Big Wig Biz guy is going to offshore such work anyway. So I ask, what's the point?
Don't get me wrong, a good foundation in math is good, we just don't all need to become math majors...
If you manage to learn and apply algebra, you can at least solve some practical math problems. But considering some of the stories of people who can't deal with fractions, well, obviously we're failing somewhere in the math department.
Anyway, just rambling now...
-M
> but rather "What Programming Language Would Heraclitus Design
Or even "Which...."
I strongly disagree. Not all of us are a bunch lazy idiots as you imply. If I didn't want to spend a week learning a new syntax for a loop I wouldn't have finished reading a second Perl 6 book yesterday, now would I? I have already spent man-months learning the language that is not even fully designed yet, so I would appreciate if you kindly exclude me--and most of Slashdotters--from your hasty generalization, for even though I would tend to agree with you that most of people in general are incompetent idiots, I believe that Slashdot community is a rare exception to this sad rule, or otherwise we wouldn't be so enthusiastically discussing the possibility of designing a Heraclitean programming language with its roots in the philosophy of ancient Greece--which nota bene would be an interesting addition to postmodern languages we already have. But even though I disagree with your premiss, I fully agree with your conclusion that Java and C# are rubbish, that of course is undeniable. But this conclusion by itself is quite useless unless we answer the question why they are the way they are. Why does the competence of your proverbial marketing department is nearly without exception reversely proportional to the technical advantages of the technology in question? When we answer this question, a lot of other answers will become clear.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Thanks,
--
Matt
complaining that young people today just don't understand anything, and that music they listen to, well, in my day.....
Yes, Mr. Kay puts forward some great ideas but the whole tone strikes me as whining. Smalltalk was great and as he says there are many new and interesting ideas out there now, why doesn't he implement them in an accessible way and drop the attitude that intellectual lighweights have ruined programming.
development.lombardi.com
The reason Perl is so popular is because it is SOOO easy to throw something together in no time at all that can access databases, websites, and so forth, without all of the messy class coding of the other languages. Would I want to write something huge in perl? Heck no. Because Perl is made for scripting and not for large projects. Same thing for PHP and and all of those languages he likens to Egyptian pyramids made from brute force.
Also, I don't know about him, but I know that at Purdue the CS degree requires the authoring of a compiler, some study of programming language theory, some classes about Database Theory (I can't remember the last time a vocational class taught tuple calculus and normalization), as well as some high level algorithm knowledge. I would consider at least that degree program a step above just some Java vocational classes, and his comment only highlights how egotistical he really is.
Just because he's really smart doesn't give him the excuse to be a real jackass.
I'm pretty sure that if you suggested to him that designing a language by following Perl's example was a good idea, he'd laugh at you, though.
Don't blame me; I'm never given mod points.
And off all the games I've seen on the cell phone, the ones i actually enjoyed playing were very simplistic, and probably were better off programmed in C.
Which API?
J2ME is constant across all mobile envs (symbian UIQ/Nokia, M$, Linux). What C-based phone multimedia API is?
IHBT, right?
echo 33676832766569823265328479713269.8639857989Pq | dc
Insightful? Did you read the post? Or where you simply dazzled by the Ph.D., some big words, and the ass kissing? Obviously someone's PHB has been let out of his cage and given moderator points.
Pan Tarhei Hosé? Panty Hose? And how do you become a Ph.D. and not learn how to avoid run on sentences. Now maybe I'm just a little more critical of my sources than your average Slashdot reader, but when someone with the MeatWorld name of Panty Hose makes a statement, I tend to be a little bit skeptical. And Dr. Pan Tarhei Hose doesn't smell right.
Get a clue people. Read before you moderate. Lets use some of those critical thinking skills we claim to have.
--Cam
All jocks think about is sports. All nerds think about is sex.
So what are the lessions to be learned from languages written in the past?
- API/Libraries are important, more important than the language itself, no matter how good your language is, if you don't have a bunch of libaries ready to use the common man will solve his problems faster and better in another language. (Perl/CPAN)
- good syntax is important, do/end are no fun, {}'s are easier to read to the common man (C)
- interoperability with other languages is important (C-libraries exported to scripting languages)
At least for me that seems to be the points that make a language successfull, while not necesarrily beatifull. Most of the powerfull, but mostly failed languages, of the past (Smalltalk, Lisp) seem to either ignore most or all of these points, worse they come with their own VM, their own development environment and such, so unless you do it their way you are mostly (hard to write or ship a few ten-line long script, hard/impossible into a native-binary, etc.).
I'm no fan of C, but...
1. I'm sure you meant to write "for (i = 10; i <= 100; i++)"
2. C's for loop construct is one of its good points, as it lets one put loop control in one place for a far broader range of loops than just iteration over an arithmetic sequence, e.g.
for (ptr = head; ptr != NULL; ptr = ptr->next)
becomes immediately recognizable as an idiom for iterating over a linked list.
There's nothing you can do with sed and awk that you can't do in just plain sh. Having 656K for the shell and 311Kb for awk and 41Kb for sed when writing a small tool is ridiculous.
Why not fork?
I'd dislike perl less if it were not the programming language of choice of the computer-illiterate.
:), leaving some very high-quality programmers. Many recent CPAN modules are case in point. There's Bryar and Catalyst, excellent Ruby-on-rails style MVC application platforms, just as one example. Template Toolkit, SOAP::Lite, Class::DBI (object/relational mapping) etc. are excellent tools to build upon.
:). The advantage is CPAN. Any application you want to write is 80% done already.
Good news. The vast majority of them have moved on to PHP
The advantage of Perl is not the Syntax. Hell, if it was, everyone would have moved on to Python by now
bp
*sigh* I'm sick of listeing to these old academics whine about the real world.
I mean, doesn't this say it all:
Once you have something that grows faster than education grows, youre always going to get a pop culture.
Oh yeah, because pop culture is bad. We don't want something to expand so fast we lose our academic control over it.
Oh, looky here! ---> . That's the world's tiniest violine playing...
Or:
One could actually argue--as I sometimes do--that the success of commercial personal computing and operating systems has actually led to a considerable retrogression in many, many respects.
Whiskey Tango Foxtrot? So it would have been better if all these lusers (those not in academia) had never got their hands on computers? Or was U.C.L.A. supposed to supply them to us?
I dont spend time complaining about this stuff, because...
Uh, right.
I have worked in the computer business as system technician, programmer, CTO, and product manager for about 15 years--have even been on some panels in academic seminars in connection with RDF and the Semantic Web. The reason these guys (and I do believe generalizations are in order) disagree with how things are done in the industry is simply because they don't understand it. It's really that simple. They are different areas of expertise.
Computer science research has its own goals. Scalability, design-for-change, open interfaces, those kinds of things are what it's all about. In the private sector on the other hand, one thing rules: cash flow. Cash flow makes the world go 'round, and it will take precedence over scalability, modular design, and documented interfaces eleven days per week. It's not stupidity, it's really very rational. Cash flow is not about economy in the simplest sense: it would be cheaper for me to buy a one-year public transport ticket instead of buying one every month, but I don't have that ammount of cash lying around, so it's still better (in a completely rational sense) for me to get the more expensive monthly solution rather than take a loan or whatnot. That is the reason why quick fixes are sometimes the smartest way of doing things. Something else is almost always smarter than the "best" design. (Insert "cost of last 10%" rant here.)
This is especially true about all small and medium-sized Internet companies that--recently burst bubbles notwithstanding--have created a huge new economy. They are employing millions of people around the world (directly or indirectly) and have introduced computer usage to pretty much every individual in the developed world.
This did not happen because everyone was stupid and did everything backwards, and it's not "unfortunate."
It also didn't happen because the academic institutions made it happen. Academia did not turn HTML into a de facto standard. In fact, if HTML had been as complex as RDF, and treated as strictly, there's a good chance the Web had never happened. The sloppyness of implementation that is a headache to most Web developers today may very well have been one reason why the Web grew so quickly. And there is still a good chance that RDF will never make it into the mainstream, it depends on how anal the developers of it plan to be. (Although even if it doesn't, it will probably still be used at 10 huge corporations around the world that are big enough to have their own in-house academic institutions.)
Keep teaching us about scalability, and if you want to listen we will explain something about what makes mainstream businesses able to pay for systems development at all.
I decided long ago that any language where '$|++;' is a complete line of code is not worth my time.
For reference, that's a pipe, not an 'L' or a '1', and that line turns off output buffering. OBVIOUSLY.
Perl is useful for a lot of different things, but so are a lot of other languages, and they aren't nearly so obtuse.
I don't know why you're bitching at Perl when it lets you code in the style you want.
1) with IO::Handle object:
use IO::Handle;
autoflush STDOUT 1; # or alternately: $io->autoflush(1);
2) with English variable names:
use English;
$OUTPUT_AUTOFLUSH = 1;
3) the terse way:
$| = 1; # because ++ doesn't mean jack in this context
I have to disagree here, the team that designed Ada for instance REALLY understood about application domains and the challenges of developing languages,
In my opinion, Ada is a good example of academic masturbation, coupled in that case with a good deal of practical programmer stupidity, and DOD megalomania. The language is unnecessarily cumbersome, unnecessarily hard to implement, and fails to make good safety guarantees. Eiffel, too, was hugely flawed when it started out (for starters, its type system was just broken), and it took far too long to fix its problems for it to make much of a dent in the market (today, Eiffel is an OK language, but has been obsoleted by other languages).
Your complaints about C are uninformed; C's design was not driven by some kind of macho attempt to save keystrokes, it was driven by trying to squeeze a useful compiler onto a tiny machine. Unlike Ada or Eiffel, which have never in their entire history been a reasonable solution to anything, C was a reasonable choice for its time and purpose; it's just that its time ended about two decades ago.
Of course, even languages as rotten as Ada or Eiffel greatly reduce the potential for errors relative to C, but that really isn't saying much. But there were actually decent, well-designed, practical languages around even in the mid-1980's--there was no need ever to use Ada or Eiffel.
Shortsightedness is not really the virtue you are painting it to be.
Buy the monthly right now, then eat beans and rice however many months it takes to save for a yearly. Then buy the yearly, and use the money you would have spent on monthlies to make other cost-cutting investments (and a nice steak dinner reward, of course).
For example, in my previous home I cut my water and sewer bills by 80% and my electric bill by 40% by investing in slightly more expensive appliances. Payback ended up being less than two years, because the cost of electricity and water has gone up faster than expected.
The unwillingness to take a hit now (those rice and beans meals) for a payoff later is the downfall of many businesses. Optimizing investments is not as simple as you make it out to be, and cash flow is a simplistic meter that does not apply to all business situations.
Substituting high liquidity for high efficiency is still over-generalizing; as people often say when discussing computer languages, every problem is unique and may require a unique solution. Every business likewise.
Now we are at the point where the good design of Lisp really shines :) You can implement Lisp very easy in every language. This makes Lisp highly portable. Once you get the Lisp-in-Lisp implementation running in any environment (which is easy, because the Lisp-in-Lisp is so short), you can be assured that your Lisp implementation works exactly as all the other Lisp implementations everywhere, because you have only one program that has to be tested for compatibility. All the other Lisp programs you can run inside the Lisp-in-Lisp environment.
And if you change the Lisp environment (by adding extensions to the language), you will surely implement them in Lisp, and magically they run everywhere you originally got Lisp-in-Lisp running. Differently in Perl, where extensions to the Perl language core are implemented in C, and use hundreds of files which have to be ported to a new system. A compatibility test for Perl has to check lots of features of the underlying system libraries for C, and because from system to system they differ slighty, you have such subtle differences like those documented in FAQ Part 8.
In comparision a compatibility test for Lisp just checks if the Lisp-in-Lisp is running smoothly. If you get half a page of Lisp running correctly, you get Lisp running correctly. This opens a lot of other possibilities: You can optimize your Lisp interpreter for your system without fear of losing the compatibility to any Lisp code you may get from other people. You can do profiling and selfoptimizing without fearing to stumble at obscure or esoteric features seldom used by anyone, but just a single library you depend on, which in turn creates nearly non trackable Heisenbugs (once you know in which part they occur, you don't know at which data, and once you know the data that triggers the bug, you don't know in which part of your software they occur) with your specially optimized version of Perl.
All together: The big advantage of Lisp is that it is completely self contained. Quite differently to Perl, which is contained in a somewhat POSIX compliant C based environment.
You know, when you set out to make fun of something, it helps if you actually know something about what you're making fun of. I don't have the time to give your posting a full-scale line-by-line fisking, so I'll just hit the high points here:
...
... in 1985.
... some people find LISP a bit daunting, and they keep wanting to write 'a + b' instead of '(add a b)' just because it's "shorter" and "clearer".
You name it, LISP implemented it way back when. Things like visual form designers, refactoring IDEs, regular expressions and the like don't count
They don't count because Lisp did implement them "way back when". LOOPS (a Xerox PARC OO system, one of the predecessors of CLOS) had a visual forms designer and a refactoring IDE
I've used LISP for 70 years...
Close, but no cigar. Lisp was invented in the late 1950's, so it's a little over 45 years old today.
I find "(+ a b c d e)" shorter and clearer than "a + b + c + d + e", myself.
LISP has exactly the strengths and weaknesses you would expect from a pure functional language.
One of the reasons Lisp is still around is that it isn't a pure-anything language. Check out those SETQs in the original LISP 1.5 manual.
Lisp invented conditional execution (Fortran at the time had only computed GOTO when Lisp introduced COND), and over the years it has absorbed structured programming, IDEs, and object-oriented programming, usually by helping to invent or extend them.
I just think it's weird that people always jump up and go 'LISP IS BETTER OH YES IT IS' when a language discussion comes round.
Yes, Grasshopper, it is good that you are learning to Question Authority. But, you should also Listen to Authority's Response, and if it turns out that Authority is Indeed Correct, you are obliged to Admit It.
To a Lisp hacker, XML is S-expressions in drag.
Funny? Geez, it's more like:
Amiga. You suck. (tech detail). You really suck. (obscure tech detail). You are the sux0rz. (painfully detailed examination of technology). Suck suck.
Did you notice that the grandparent was all metaphor and didn't even mention computers? There's a reason that's funny and this one isn't.
It appears Hericlitus did have something to say about all the perl-lisp-c++-java flamewars!
Hericlitus said that the universe was nothing but conflict and strife. What was experienced was illusion. What there is is a constant incessant flux, a raging fire. What is real is the logos (the binary code), that which lies beneath the fire. http://n4bz.org/gsr/gsr7.htm
Well, sometimes you eat the bear, sometimes the bear eats you.
...because it's not just "foreach n in X loop", it's "declare type Array_Bounds is Integer range 1 .. 5; begin for I in Array_Bounds'Range loop [...] end loop; end;".
A proper type system is worth a heck of a lot more than a few characters saved typing!
It has memory management, quite a sensible sort actually. First, you can manually deallocate things (like "free"). Second, you can take complete control of the memory allocation of a type via "storage pools" - allowing tricks like mark-and-release or garbage collection. Third, it's clever enough to free the storage for everything of a particular type, when that type goes out of scope. All of which makes a lot more sense than C's rather brute-force "malloc" and "free".
Also, Ada leaves C in the dust for bit-flipping. You can specify layout of data down to the byte-order and bit-width, the exact modulus of modular integers, the exact delta of fixed-point numbers, etc etc.
Personally I think the reasons Ada didn't catch on much more are down to an early lack of good compilers, and a stagnant library (no standard way to access sockets? Is this the 1980s?).
I've had to fix bugs in shell scripts written using awk and sed - you know, shell scripts that consist of a long chain of pipes from one awk script to the next? Man, anyone who bitches about how perl is write-only should try fixing awk pipe chains. Or shell scripts in general, really. There's a reason that there's a whole section in Unix Power Tools about nothing but the quoting rules in bash.
There's a lot that I can do with perl that I can't do with awk and sed: uncompressing flate-encoded streams in PDFs (using Compress::Zlib), parsing XML, controlling desktop apps using Win32::OLE, etc.
I have been on the receiving end of a big pile of spaghetti code written in Perl, chock full of bad things like subroutines that modify global variables and file manipulations that depend on chdir() calls 200 lines back. It's extremely easy to write incredibly crappy code in Perl, but as you mention yourself, it is possible to write clean, structured code in Perl.
I've found Perl to be a good solution to problems too complex to be resolved by a 10 line shell script, but simple enough not to require a C or C++ project. That includes the UI for an internal web application, the photo album CGI for my personal web site, and tons of relatively small tools that I use every day. I wouldn't call the language perfect, but it (and CPAN) gets the job done.
In other words, C isn't really a language. It's a core upon which a language can be built. C plus the standard library plus posix is a language. And even that relies heavily on the preprocessor to mutate your code to match local implementation quirks.
> When Ada was released it's documentation was something like 10 times as much as C++ had. C++ is larger Ada's NOW, and Ada hasn't changed. (Partially this is because C++ originally had poor documentation, and partially it's because the C++ specs repeatedly needed to be expanded.
Ironically (in the popular sense of the word), one of the reasons often cited as a reason to use C++ over Ada now ("Ada doesn't have standard class libraries") is the same reason often cited for not using Ada when it first came out ("there's way too much stuff in this language").
Sheesh, evil *and* a jerk. -- Jade