Slashdot Mirror
Lightweight Languages
Denise writes: "'What happens if you get a bunch of academic computer scientists and implementors of languages such as Perl, Python, Smalltalk and Curl, and lock them into a room for a day? Bringing together the academic and commercial sides of language design and implementation was the interesting premise behind last weekend's Lightweight Languages Workshop, LL1, at the AI Lab at MIT.' Simon Cozens report, on perl.com, says it wasn't the flame fest you might have imagined."
Big Bummer. This is a language that needs more exposure. I'd love to use it in place of perl if there were more toolbox modules out there for it. It needs to reach a critical mass before the really complicated modules, like template toolkit, get written - and before they get written people aren't able to write the quick and dirty programs (that languages like perl are famous for) that give it the critical mass... vicious circle.
General use. For example, could you write a simple game (Say, Pong) with it? How about the perenial favourite "What is your name?" Could you do more complex things with it, such as mangle a simple email address into an RFC 2822 compliant address? Sort a list of values?
Think simple tasks that you would do with e.g a shell, or Perl, or even small C programs. How far can you strip a language down, yet still be able to acomplish those tasks?
There was a bit of a superior attitude from some of the academics, who feel that languages like Perl and Python reinvent the wheel and neglect the body of academic research by coming up with suboptimal solutions to PL problems that have long since been "solved" in the PL literature. Maybe "frustrated" is a better word than "superior." While I can totally appreciate their point of view, I found myself cringing in embarrassment once or twice when a harangue by one of the academics went a little overboard. There has already been one post on the LL1 mailing list that I feel crossed the line.
The discussion came to a bit of head during the (very interesting) "Worse Is Better" panel (based loosely on the writings of Richard Gabriel), which centered on the question of why the most popular languages aren't the "best" ones.
Like I said, though, it was mostly very congenial. Ultimately, I think each camp took something away from the encounter: both new-found implementation techniques, and a greater knowledge of and interest in the other community. There are some practical issues that the Perl/Python guys have to deal with (e.g., interfacing with legacy languages like C) that aren't really addressed by academics, and I think it was great that these issues were brought to light.
The LL1 website, if anyone is interested, is ll1.mit.edu.
it wasn't the flame fest you might have imagined
Not surprising. The only people who get into flame-fests about programming language choice are insecure newbies. It comes down to the same reason kids argue about whose game system is better: they got one for Christmas and feel compelled to defend their choice, because they can't afford another. Once you know a sizable number of computer languages--especially different styles of language--then you no longer feel a need to be so petty. Different languages have different strengths.
I know a bit more about PL design. Being in academia pollutes the mind, I know, but I am sure that almost all I see in the slashdot PL community is reworking of old, mediocre ideas. Who in the world will use and develop new programming languages if not hackers?
(So, the PL fanatic in me wants to point out caml [inria.fr], which, even though it is not my personal favorite, I think could become really popular with slashdot-style hackers.
Of course ML languages are 20 years old, and Caml was developed *before* Perl and Python. So it isn't necessarily that the newer ideas are better, just that lots of good ideas tend to get lost to history for various reasons.
I doubt this is the first effort to create a popular open VM, but it seems to be one of the most heavily promoted. Hopefully we will see Parrot-based languages springing up everywhere, and perhaps even ports of existing languages.
He was invited. He just couldn't make it that weekend. Which was a pity, because I wanted to discuss getting an INTERCAL parser for Parrot... :)
I'm really excited about this language. They're going to give an honest shot at making a lisp that will have more general appeal (read the part about onions: they're taking the "onions" out of common lisp), yet still maintain the raw power of macros. It should be very exciting.
Please god no. Not that, anything but PHP.
Why the hell anybody thinks a crippled perl clone whose sole distinguishing point is that it is embedded in HTML (another evil practice BTW - all 'code embedded in webpages' systems should be stamped out), is good for anything is beyond me. And yes, I have used it, many times, and bear the scars.
Caml does full type inference for you, so that you have to write fewer types than you would in C or java.
In fact, in Caml you really only have to write types when you write down an interface to a module -- and this is exactly what languages without sophisticated type systems lack. It is very difficult to write precisely what your interface is without writing down types, and if the type language is poor (ie, Java, or worse: perl) then writing interfaces becomes more an exercise in documentation and finger-crossing.
(Personally, I also find that automatic type checking is very conducive to writing maintainable programs. It keeps me from making the gross hacks that are so tempting in perl. Typically it doesn't make my programs any longer or more difficult to write, since ML-family languages have lots of features to capture the common idioms that require this "flexibility" in perl et al.)
Careful not to make too many generalizations. I think Caml is much nicer than other typed languages you mention.
I agree completely with your point. I wasn't trying to disagree with it in my earlier post, which was at least partially a poor attempt at a joke anyway. My only point was that everybody has a finite amount of time on their hands over the course of their careers -- there's time for keeping up with research, there's time for working on one's own projects, but rarely do the two meet. Most people in the field, I'm sure, have spent a significant amount of time on both. However, their experience will range along a sliding scale from 100% academic to 100% practical. It's a tradeoff, just like everything else in engineering and/or life (there are those who claim the two are mutually exclusive...). There's no such thing as a 200% career, at least for most of us. God knows I'd love to be the guy who knew everything and had done everything, but alas...