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."
Interesting weekend! Here's the summary in case you can't get on, (or if you're lazy!)
As I've indicated, the interest of the workshop was as much what was going on outside the talks as well; Dan and I got to meet a load of interesting and clever people, and it was challenging for us to discuss our ideas with them - especially since we didn't always see eye to eye with our academic counterparts. Sadly, few people seemed to have heard much about Ruby, something they will probably come to regret in time. Dan seemed to have picked up a few more interesting technical tips, such as a way to collect reference count loops without walking all of the objects in a heap. Oh, and we found that you should pour liquid nitrogen into containers first rather than trying to make ice cream by directly pouring it into a mix of milk and butter. And that the ice-cream so produced is exceptionally tasty.
But seriously, what did we learn? I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems like threading, continuations, despatch and the like, but not very interested in working out all the implications. To bring an academic success to commercial fruition requires one, as Olin Shivers puts it, "to become Larry Wall for a year" - to take care of all the gritty implementation details, and that's not the sort of thing that gets a PhD.
So the impetus is on us as serious language implementors to take the time to look into and understand the current state of the art in VM research to avoid re-inventing the wheel. Conferences such as LL1, and the mailing list that has been established as a result of it, are a useful way for us to find out what's going on and exchange experience with the academic community, and I look forward intently to the next one!
And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
Well, we can see that you learned to program in BASIC. ;) Not all languages need assignment as their primary form of computation ...
::= x (variable)
I'd say that the lambda calculus is more lightweight, and also easier to program in than your example:
exp
| exp1 exp2 (application)
| (fn x => exp) (function)
Basically the key is that you have higher-order functions (you can pass them around), and that's it. With this, it's relatively easy to code up booleans, integers, lists, recursive functions, trees, or practically anything. (If you wanted to do IO, you'd need some kind of primitive functions for interfacing with the machine.) Since everything is higher-order, it's easy to code these once and then pass them around. It's not as nice as a modern language, but it's nicer than a turing machine...
Actually, there is a simpler language that uses only two functions (!), but this one is pretty hard to program in directly.
I sure hope next year's LL2 addresses this issue.
"Trust me - I know what I'm doing."
- Sledge Hammer
any similar conference i've ever been to (including some W3C working sessions) have been extremely professional, even when working on standards. IMO the only time you get flamefests is on the internet on boards/newsgroups populated by wannabes who don't fully understand what they're flaming about, and the flames are pretty much just a front to cover their lack of knowledge/experience. on the other hand, stick a bunch of knowledgable people in the same room, and considerable respect for each other is shown.
If you want to experience the Turing tarpit (where anything is possible, but nothing is easy enough to actually do) firsthand, try the Brainfuck language, based closely on the turing machine. the language has 8 instructions, and only one of them (input) has any arguments beyond an implicit current location. The compiler is 240 bytes!
My Karma: ran over your Dogma
StrawberryFrog
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.
I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems ... but not very interested in working out all the implications.
This is the best paragraph in the article. Here's what makes me sad:
Slashdot-type hackers have an amazing ability to get things done. They can really come up with a working product faster than anyone.
BUT, slashdot-type hackers have a tendency to implement olddd ideas, and also frequently to make well-understood mistakes. It is true that we are on the cutting edge of implementing internet protocols and maybe window managers, but in other areas we are implementing 30 year-old ideas still. (OS design and programming languages come to mind especially.)
WHO, if not the hackers, will embrace this stuff? They are the only ones that are supposed look beyond the hype and marketing and status quo to evaluate things based on technical merits, and to create implementations of new ideas.
I know only the OS design that I learned in my undergraduate course. But that is enough to know that the design of the kernel is very conservative! Where are capabilities? Where is fine-grained access control? Does anybody *really* think that their internet daemons should run as *root* just so they can open up a port with a low number? (I know there are plenty of workarounds...) I am sure that there are dozens of great ideas in OS design from the last 20 years that would be totally appropriate for a hacker's kernel.
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, which, even though it is not my personal favorite, I think could become really popular with slashdot-style hackers. It is really fast -- probably the fastest, it is hacker buzzword-compliant (it has "objects"), and yet it has taken many great ideas from academia and put them in a really usable, accessible form. Try it if you are in for a taste of something different!)
Anyway, just trying to say that if you are tempted to go hack up your own programming language, please at least don't assume that Perl is the state of the art because it is the most popular scripting language or something. Take a class, read a book, and check out some of the weirder languages coming out of academia first. Hackers are how the revolution happens...
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.
If we don't take the learning curve into account, you might en up with Color Forth
(or any other Forth derivate, such as BigForth - for Linux and Windows - which include a breathtaking GUI RAD : Minos)...
Here's a small ColorForth program: This consists of an IDE disk driver.
Trolling using another account since 2005.
From the review:
Paul Graham rounded off the talks by talking about his new dialect of Lisp, which he called Arc. Arc is designed to be a language for "good programmers" only, and gets away without taking the shortcuts and safeguards that you need if you're trying to be accessible.
I predict that someone will later come out with a new and improved version of this language which is backward compatible, and runs 10 times faster. That language will, of course, be called Zip.
- Mike
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.
((() ((hi) (there mr)) slashdot) guy () () ())
is one, for example. Lisp (and Scheme, a dialect of Lisp) both a) represents programs as a particular subset of s-expressions, which we'll call the set of s-programs (which makes sense, right? Every program is a piece of data, but not every piece of data is a program), and b) has facilities for very easily manipulating s-expressions -- they are Lisp's favorite datatype (the name LISP comes from "LISt Processor," in fact, and s-expressions are really just a way of writing down lists). The appeal of using Lisp dialects to process XML is based not on the fact that those programs are S-expressions, but that they process S-expressions easily -- and, as it turns out, XML expressions can be trivially converted to S-expressions -- let's say that there's a subset of s-expressions called X-expressions, and there's a trivial bidirectional mapping between X-expressions and XML expressions.
So, let's say you want to write a program that reads and/or writes XML to communicate with the world. You can just write your program as a normal old S-expression-manipulating program, like Lispers have been doing since 1958, and then right where you read in the data, you call some function that reads an XML datum instead, and right where you write it out, you call some function that writes an XML expression. Now you can still use all the XML-processing gizmos you already have, but you can also write your own XML-processing gizmos really easily. In fact, I've been involved for some time in a Web programming language project, and that's how we manipulate XHTML: we read in XHTML expressions, manipulate them with Scheme code that's easy to write because the XHTML-to-S-expression mapping is so thin, and then write out XHTML expressions to the web browser. None of the other XML-based tools in the chain (the web browser, XML editors you use to generate the web page templates, et cetera) need to know or care about the fact that my implementation is in Scheme.
The only smugness you hear from the Lisp people (and this is where the faux comparisons between Lisp and XML come in) stems from the fact that Lispers have been storing their data the way XML does, only more cleanly and with less typing, for years. Now XML comes along and everybody thinks it's going to usher in world peace and change the way we put our pants on. Well, dammit, Lispers were already putting their pants on a different way, thank you very much!
-jacob
You couldn't be further from the truth. Someone's already mentioned CiteSeer. I've read and downloaded hundreds of papers from there. Google is great for tracking down papers, too.
Another nice resource is library.readscheme.org. It's Scheme-specific, but Scheme is the root of much research about programming languages and the underlying concepts - it pretty much spawned the field of functional programming.
The biggest barrier to entry for this sort of stuff is your own existing knowledge. There's no pill you can take to pick it all up overnight. You have to work hard at it. This is the real reason to go to a real universities - not to learn how to program in the language du jour, but to learn about what some very smart people have already figured out over decades, centuries, millenia, and to learn how to think like those people.
There aren't many shortcuts here. It doesn't help to be told that there's a simple solution to the problem you're working on, if it involves a network of deep concepts you've never heard of and are totally unfamiliar with. To take some examples from functional programming: closures, continuations, continuation passing style, fold operators, polymorphic type inference... If you don't know what all those things mean, and can't use them in your code, you're unnecessarily limiting yourself and denying yourself leverage that can help get big, complicated things done more quickly, with less fuss.
One way to start out is to learn some advanced languages. Scheme is a good starting point because there's so much tutorial literature for it. You can pick up the computer science concepts as you go along. Read Structure and Interpretation of Computer Programs (SICP) and How to Design Programs (HTDP). Join the ACM. There's so much stuff out there, go look for it, and apply yourself!