Lambda the Ultimate

The article makes a valid point, though, which is that some architectural and design decisions from Smalltalk (etc.) made it into Java, and other decisions from Smalltalk made it into Ruby, but neither fulfill all of the promise which the original model languages held out. That's for a variety of reasons: apparent design conflicts, e.g. Java is statically typed, Smalltalk isn't; or they just haven't gotten there yet, e.g. Ruby probably doesn't have the same kind of VM technology mainly because it hasn't had the equivalent resources thrown at it.

None of this necessarily makes Smalltalk the ideal choice of language, but I think the argument isn't as easily dismissable as all that, except on the admittedly important grounds of market acceptance.

It was years ago when I heard this - third hand, so take it with a large grain of salt.

As I recall though, IBM dropped smalltalk for Java because it was becoming clear from the hype that Java would take off (particularly if IBM got behind it), while Smalltalk never would. So they jumped on a lesser bandwagon because it gave them the advantages of a popular OO language (you can hire experienced coders, and you don't have to sell the customer on your choice of language), without the disadvantages of something like C++.

IBM at that time thought smalltalk was better, but they also could see that it would never go anywhere, while this Java thing just might. History have shown that Java did go someplace, while smalltalk is still something you rarely see out of a CS classroom.

You don't need to forfeit OOness or DSLness. Just support both.

Personally, I like both. OOness for the backend (solid code), and DSLness for the frontend (easy-to-use code).

Try Slate. We work from files and a REPL and can still produce a wide variety of images. The usual Smalltalk-ish stuff will come later, but will not crowd out the rest. Done properly, it can even use the same architecture, e.g. IDE in one image for a tiny core image for deployment, partnered over a socket.

There rightly isn't a point in dropping functionality that images make trivial, but there is a point in re-thinking how the whole system should work so that both camps can co-exist in the same community.

"The complete Resilient System comprises a development environment running on a PC and a running Resilient Virtual Machine deployed on an embedded system or run locally."

Design, Implementation, and Evaluation of the Resilient Smalltalk
Embedded Platform (pdf)

Yes, in Smalltalk we would expect to work on a class or a method, in a specific user interface context, rather than as text in a file.


iirc by '90 there was a fine-grained configuration management system for Smalltalk, tightly integrated with the IDE - accept method changes in the IDE and a new edition of that method was created in the shared repository across the network, let's just say continuous integration.


As for executables on demand - Smalltalk/X started off as a Smalltalk to C compiler ... so if you need inline C ...

As for executables on demand, I should also mention the Smalltalk MT and the popular Dolphin Smalltalk Community Edition language implementations.


The Computer Language Shootout has made me very aware that programming language isn't a synonym for programming language implementation :-)

* Canned libraries (even if wrappers around C/POSIX) for such things as networking, regexes, XML, database connectivity, and other common everyday problems faced by application programmers

* A low conceptual barrier to learn the new language (syntax and support for existing paradigms are part of this)

* An O'Reilly book on the language. :)

* A major corporation (Microsoft, Sun, IBM, Bell Labs) OR a charismatic figure (Larry Wall, Guido von Rossum, Matz) who is associated with the language.

And, a controversial one:

* A focus on serving the needs of application programmers, as opposed to programming language research. I realize that these are not mutually exclusive; however, they have a reputation for being so. My theory (which I think is unfortunate, but true) is that if a language EVER gets tagged with the "academic" label; it's doomed to remain a niche language. Lisp, Haskell, ML, Oz, Prolog, and numerous others all suffer from this typecasting (though O'Caml might yet escape from this particular snare). My further suspicion is that certain benevolent dictators are aware of this, and will remove perfectly useful features from languages (like lambda), in part to avoid this particular pitfall--at least until the userbase is ready.

But maybe I'm just being feisty today. :)

At some point in Ruby's history, Matz apparently sat down and cloned Perl's standard library. Today, if I were promoting a new language, I'd probably do the same thing: Find a popular scripting language with a good standard library, and re-implement everything. That way, you're sure to all the tedious stuff like networking and popen3.

If your languages has multiple popular implementations, support all of them, like the Boost folks do with C++.

As for the O'Reilly book, well, you can always substitute something by Dave Thomas. :-)

I'd add "a debugger" even though I know everybody claims you don't need them when doing FP. But if you are interfacing to anything else (per #4 on your list), you need a debugger!

...to mean "source level debugger". I'm not interested in anything that compiles to C and then tells me to use gdb on the generated code.

Just in case it isn't obvious. :)

Regarding FP and debuggers; there was a thread on LtU a while back (probably over a year) concerning debuggers and Haskell; and the problems associated with debugging lazy-evaluated code.

And, of course there's the related flamewar about debuggers vs unit testing. :) I won't say much here, other than to note that I prefer to have as many tools at my disposal as possible; and get annoyed at folks who insist that I should discard some of them without clear and convincing evidence that they, in fact, are harmful. Note that arguments like "use of X is a sign of laziness/sloppiness" does not constitute either clear or convincing evidence, in my not-so-humble opinion.

8. A well-thought-out standard build/deployment/packaging/installation solution. It doesn't have to be perfect, but it does have to exist, and more importantly there has to be one of them which is dominant. The only must-have feature here is separately deliverable modules.

9. A well-thought-out standard documentation convention, followed by all standard libraries.

Nowadays I would say that 4) could be replaced by a way of portably interfacing with Java, rather than C, at least for certain application domains. (Transitively via JNI, that of course gets you portable interfacing with C.) I can't imagine a successful business programming language being launched now (by someone not in Redmond) that didn't couldn't leverage the Java libraries.

I think we should make these lists annual, too. Behold the 2005 must-have list for striving languages.

In 1980; we didn't have TCP/IP support, RDBMS support, and lots of other stuff to worry about.

Of course, Smalltalk was barely known outside of Xerox then, and unacceptable to most corporate data processing departments (what IT was called in those days) due to needing a graphics workstation to run on. While terminals were commonplace by then, most office terminals were monochrome, character-oriented devices--in your choice of green or amber. It wasn't until the early 90s that your average office computer came even CLOSE to fulfilling the requirements for a useable Smalltalk environment.

Some folk at Computer Sciences Corporation didn't know that Smalltalk couldn't be implemented on an 8086-based DOS machine - so they created Digitalk Methods and then Smalltalk/V.


In 1988, with Smalltalk/V 286 they really had something usable.

And what sort of graphics hardware did it require? IIRC, in 1988 VGA was just starting to show up (and was very expensive)--and we're talking about 640x480x16 color VGA. EGA was a much cheaper option--providing sorta-reasonable color. However, most PCs of the era were monochrome.

It may have been workable; it may not have been--I don't really know. Many businesses that DID want graphics at the time, didn't have PCs--they either had workstations running some flavor of Unix (NeXT, HP, etc), or they had Macs. And usually, those were given to productivity persons--draftspersons, engineers, artists, designers--who needed such; managers, secretaries, order entry persons, and such--if they had PCs--generally had monochrome.

I have a vague memory of a colleague using green-screen Smalltalk/V on 8086.

The only special thing about the machine I used Smalltalk/V 286 on was the extended memory - maybe a whole megabyte. The display was monochrome not color, but at least it wasn't green.

Sorry it took a while, I found a scanned pdf of The Smalltalk Report 1(1) Sept 1991, which includes an advert on page 17:

• $150 Smalltalk/V DOS
• $385 Smalltalk/V 286 DOS
• $395 Smalltalk/V Mac
• $475 Smalltalk/V PM OS/2
• $475 Smalltalk/V Win Windows 3.0

And some more detail from the first issue

"Digitalk introduced Methods, a text based Smalltalk, in 1985, and then Smalltalk/V, a graphics version, in 1986."

See Richard P Gabriel "Models of Software Acceptance" pdf

I think that a widely popular Lisp is blocked only by the challenge of infix macros, and a widely popular Haskell mostly by the difficulty of writing ugly, stateful programs.

The latter's actually pretty easy in Haskell if you're able to do IO at all. You'll regret it, but when won't you?