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."

Comments

Lua

[Hougaard]

All my votes goes to Lua. www.lua.org. A fantastic language, small and very fast!

XML and Lisp.

[DGolden]

XML is, as is touched upon briefly in the aritcle, just lisp s-expressions, but with phenomenally annoying syntax.

If you have to work with XML, and you know some Scheme, I recommend translating it into Scheme form, via ssax. It makes XML not quite such a pain in the arse.

Re:XML and Lisp.

[jacobm]

You are confused. There are such things as s-expressions, which are, loosely, any sort of balanced nested parenthesis thingy:

((() ((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!

Liquid Nitrogen Ice Cream

[John Harrison]

From the article (seriously):

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.

Years ago I read an article about a guy from Jackson Hole, Wyoming who made gourmet ice cream. He had determined that the two things that separated good tasting ice creams from the rest were:

1. Fat. Ice cream needs lots of fat.

2. Size of the ice crystals. The water in ice cream can be frozen in big crystals or little ones. If you freeze it slowly, you get big crystals. Freezing quickly leads to small crystals. Small crystals == better ice cream.

So this guy found that he could make the smallest crystals by pouring everything into a big bowl with some liquid nitrogen and stiring it really quickly. This was after trying several different methods of freezing the ice cream, none of which were fast enough for him.

He said that a good test of ice cream was whether it floated in water. Good ice cream should be dense enough to sink. I guess this is due to the high fat content. Of course once you put it in water, it is no longer good ice cream, right?

Re:Liquid Nitrogen Ice Cream

[TheSync]

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.

You can check out my video about making ice cream with liquid nitrogen. I'm a bit afraid about the butter part, generally LN2 ice cream is made with milk and heavy cream, plus sugar and vanilla. I'll have to try the pouring mix into LN2 rather than pour LN2 into mix.

Academia to Hackers

[Tom7]

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...

Re:Academia to Hackers

[Tom7]

> You don't get to the cutting edge of programming
> lanugage implementation by wasting your time
> reading the many years of esoteric research
> published on the subject, especially since real
> languages frequently have to do things that don't
> make for terribly fascinating research.

Of course this is true, but I am not asking anyone to waste years on *esoteric* research. I am merely proposing that people designing a new OS or programming language look at the current state of the art; to at least know about and consider seriously the *known good ideas* in academia.

Here are some glaring examples of features that ML (for instance) has that are *damn useful*, totally not esoteric, yet typically don't even find their way to the table in the design of a slashdot programming language:

- parametric polymorphism. (No casts!! Java is slowly getting this, finally; they call it "generics").
- datatypes and pattern matching. (Makes processing recursive data structure like lists and parse trees beautifully simple!)

There are many other things I can think of, which have varying degrees of obscurity, but I think these two are firmly on the useful side.

My point is that people somehow bizarrely confuse "popular" with "state of the art". Like, in a slashdot discussion about programming languages, I invariably hear, "X is better than Y because X is object-oriented," as if object-oriented programming is the pinnacle of PL design. It's 30 years old! (Even the ideas I propose above are about that old!) It is worth looking at more recent ideas, and those aren't typically to be found in mainstream programming languages.

Obviously...

[mirko]

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.

Best quote from the article

[avdi]

"Sadly, few people seemed to have heard much about Ruby, something they
will probably come to regret in time."

Re:Whats the "lighest" you can get?

[Anonymous Coward]

SBN.

Subtract and Branch if Negative.

It takes 3 operands (although you can reduce this to two and an accumulator register if you'd like). Its implementation is effectively:

if (A - B) 0 then jump C

Make variables defined by their first use, and have line numbers for branches and you're done.

Re:Whats the "lighest" you can get?

[scrytch]

Can we get even more lightweight? :)

Oh my, yes. All you need to compute is three operations (and another couple to do i/o). Check out unlambda. Lighter than brainfuck, probably even more maddening, since it doesn't have state like a turing machine does.

Change the i/o ops to read and write arbitrary memory locations, and you could write an operating system in unlambda (same goes for any other of these toy languages)

Re:Whats the "lighest" you can get?

[Anonymous Coward]

I was talking about the S and K combinators, which are these closed functions:

K x y = x
S x y z = (x z)(y z)

You can actually get down to just one function! Moses Schonfinkel invented the S and K combinators, and in the paper in which he proposed them he suggested that you could define a function J:

J J = S
J S = K

So you can write S as JJ, and K as J(JJ). Then you can write any function with just J's and parentheses.

There's even a more natural way. Henk Barendregt points out (in his classic book on the Lambda Calculus) that you can define a function:

X y = y K S K

Then:
X X = X K S K
= (K K S K) S K
= (K K) S K
= K K

So (X X) X = (K K) X = K
and X (X X) = X (K K) = K K K S K = K S K = S.

Now that is cool!

Next time include the requirements

[alext]

Yes, great idea, but one could argue that both academics and the worthy hackers are somewhat removed from typical user contexts. There are plenty of requirements in the 'enterprise applications' space (not to mention the scientific modelling space etc.) that are virtually never addressed in basic programming language, but only in endless 'frameworks', 'wizards' and other add-ons that are really band-aids for concepts not considered at language design-time. For example:

Commercial information tends to be persistent, not transitory. A good language should work directly with stored data.

Processes in organizations are long-lived and distributed, whereas typical programming languages just deal with transient threads etc. (outside workflow systems such as WebLogic Integration).

Programs represent rules, algorithms and other forms of knowledge that end-users will want to add to (e.g. a discount formula). Not only should the environment allow run-time modification and extension, it should also support representations and syntaxes accessible by non-programmers.

Every action has a principal actor associated with it, and typical commercial environments need to record who it was for auditing and access control purposes. If a programming language has no concept of Principal, one has to be stuck awkwardly on the side (e.g. Java EJB isCallerInRole).

Transactions are a very common programming model. At the very least, there should be support for creating and propagating transaction IDs, restarting procedures etc.

What else? Run-time metrics, versioning, SQL-style set predicates... well, you get the idea. People have to wake up to the fact that there is still a huge disconnect here.

(Amazing to think that Java gave Microsoft some ideas and a wide-open goal, and they came up with C#).

The research is there for the taking!!

[alienmole]

I am asking because I don't know. My suspicion, however, is that most of this knowledge is locked in high-priced peer-reviewed journals, overpriced textbooks, and papers distributed among an elite group, rather than being released freely to the community of developers who work on free software.

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!

rebol

[Graspee_Leemoor]

I am a bit of a language freak and have a long-time habit of hearing about a new language, reading a brief feature list, getting really excited, reading the language and library docs, discovering something I don't like, e.g. in C# the way methods aren't virtual by default, going off the language intensely then adding it to my cv anyway.

But when I checked out rebol that was mentioned in the article I found it was in fact as good as it first seemed, maybe better.

Within an hour of first hearing about rebol I had written a gui program that displayed the live picture of the Tokyo Tower on the net and updated it every 60s.

When I first wrote this program, it was as a learning experience for c#- and it took a hell of a lot longer to write and the code is much longer.

So maybe for me rebol is the ultimate lightweight language!