MishMash

Frameworks

Bill de hÓra: A  framework is a patch for a programming language.

Vlerq

Chris Double points to Vlerq, a new research language:

Vlerq is a research project for data structures.

It ignores conventional wisdom and introduces another way of representing and manipulating data in software. The implications are quite far-reaching, and exciting as well as frustrating.

Vlerq is an acronym which describes the idea:

• Take Vectors
• Add a Language
• Make it Embeddable
• Use the Relational model
• Include a Query mechanism

The presence of Shared and mapped boxes is interesting: transparent interfaces to external data sources built right in to the language.

“Views” is I guess a term borrowed from databases, it seems to mean what I would call "table". I was hoping it would mean that you could construct different views of the same data and treat them the same was as the main data structures.

Kay Interview

Via James Robertson, an interview with Alan Kay at ACM Queue:

  One of the things that people realized from these extensible languages is that   there is the unfortunate difficulty of making the meta-system easy to use. Smalltalk-72   was actually used by children. You’re always extending the language without   realizing it when you are making ordinary classes. The result of this was that   you didn’t have to go into a more esoteric place like a compiler compiler—Yacc   or something like that—to add some extension to the language.

As ever from Kay, some lovely ideas. Well worth a read.

I didn't realise quite how much Smalltalk had changed through the 70s. Sounds as if I could do to get my head round Smalltalk-72 at some stage.

And Lisp begat Smalltalk, and Smalltalk begat …

Funny timing. I tried to print out this family tree of programming languages (printable PDF version s available) the other day, and somehow failed (sometimes things just don't get through, and there are too many computers between me and the printer, managed by somebody else, for it to be worth doing anything other than shrugging), so I tried again this morning. I had a browse, said "ah!" a few times, and went back to my morning engagement with bloglines. Next up, Smalltalk weblogs, and James Robertson linked to the same diagram, while in a comment gabriele renzi points to an alternative, slightly whimiscal but nonetheless worthwhile view.

I have to say I'm slightly surprised at how little influence seems to be shown from Smalltalk (and Lisp) out. There's a limit to what can be shown on a diagram like that, I guess, and the connections are all at the conception of a language (so the ongoing slow accretion of Lisp/Smalltalk features in various "agile" languages doesn't appear). Still, I'd have thought C++ owes a lot to the modifications Smalltalk made to the Simula model of computation, for example.

Then again, perhaps it's better not to show such things when they are so badly corrupted in transfer, lest the source of the ideas be blamed for the result.

There would be an interesting linguistic study in how the concepts established in the development of Smalltalk were diluted as they spread; how the same words came to have weaker meanings more in keeping with what people knew already.

Eiffel is for building towers!

Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place. [Alan Perlis, Foreword to SICP]

Eiffel (it has just occured to me) is for building towers (of course) -- imposing, breathtaking, static structures built by hundreds of employees riveting carefully crafted pieces of iron into place.

You can do a lot more with iron than you can with blocks (though if you want to build a breathtaking pyramid, you're probably as well sticking with blocks) but still at times you just can't do enough. It took me three years of writing code in Eiffel before I realised it just wasn't going to take me where I nedeed to go, which is depressing given that I already knew Smalltalk. In the end it was reading SICP that opened my eyes.

It's worth continuing the quote:

The organizing principles used are the same in both cases, except for one extraordinarily important difference: The discretionary exportable functionality entrusted to the individual Lisp programmer is more than an order of magnitude greater than that to be found within Pascal enterprises. [Alan Perlis, Foreword to SICP]

Discretionary exportable functionality is key — functionality such as the ability to compile and install code at run time, as I just mentioned. While non-Free licensing can get in the way a bit, it is only in languages like Lisp and Smalltalk that there is any hope of blurring the boundary between developer and user, and it is only when this is done that computers can hope to fulfill any significant fraction of their potential. This, of course, was one of the fundamental drivers for Smalltalk. Lisp supports it (in my interpretation) for the simple reason that, given that it is possible, it would be perverse to do otherwise.

There's a lot of perversity around.