Back to the future...

So if Java is a victory for Smalltalkâ€™s implementation choices, and Ruby is a victory for Smalltalkâ€™s language choices, what do you do if you want both? Thereâ€™s still only one option: use Smalltalk.

You be the judge.

Comment viewing options

I think I've heard that one before. And I'm not sure Java or Eclipse or Ruby is a "victory" for Smalltalk. Why did IBM ditch Smalltalk?

I do like Smalltalk though. The syntax is dead simple and some of the environments are decent - I wouldn't put the ones I've tried in the same league as Eclipse or IDEA, but for a dynamically typed language...

It seems to me that nostalgia, the need to be different than the mainstream (is Ruby now mainstream?), and a lack of understanding about timing, marketing, and a whole host of other factors of why a language "dies" is the cause of these writings.

Smalltalk's stepchildren

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.

As I recall...

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.

Ruby isn't perfect, but I love it

The problem with Smalltalk and Lisp is that some of the best stuff for them is commercial. It means that the open source (general) community can't enjoy them while using those languages. Also, a program needs to talk to the rest of the world, meaning that it should be easy to create bindings for external programs like databases, GUIs, etc; else you will need lots of rewriting (reinventing the wheel) to get a good enough system. Ruby provides support for external bindings; this support may be one of the easiest of all programming languages.

Considering the tradeoffs, Ruby is the only tool that I want to use, so I'm guilty of wanting to use Ruby for as much as I can. I have been using Ruby for 3 years already, so Ruby on Rails was not the reason for me to use Ruby. Actually, Ruby on Rails is just ONE way to use Ruby for web applications. There are several web frameworks with their own approaches. Also, nothing is stopping you from creating your own or something. "If you can't beat them, join them." If I couldn't beat Ruby on Rails, I would join them. But I think I can beat them with my own approach. Hope you can, too.

The next hundred confessions

Seasoned thoughts in a moment where OO seems both to dominate and stagnate or just a glimpse of nostalgia?

As I see it the opinion leaders in the OO crowd, people like Martin Fowler start talking about DSLs...

Kay

OO and DSL are complementary in Ruby

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

Image based languages

One point that both Java and Ruby have in common with each other--and differ from Smalltalk on, is that neither is an image-based language. While image-based languages certainly have their appeals (especially as recently as five or ten years ago, when Visual Studio was as good as it got in IDE-land); I'm of the opinion that a clean separation between a program's source and it's running instances is a Good Thing, and that modern IDEs eliminate most (if not all) of the advantages of being image-based.

Efforts to produce a non-image-based Smalltalk seem to have gone nowhere, and the Smalltalk community seems to be hostile to the idea. But most software development practices tend to assume that program source is a series of text files that can be checked into a configuration management system, passed around a network, and be used to recreate an executable on demand--the architecture of Smalltalk just doesn't fit into this paradigm.

You can have both

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.

Eclipse IDE + deployed image

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

classes and methods passed-around and versioned

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

I should mention...

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 :-)

A hypothesis

Having worked hard to promote many languages (Lisp, Dylan, etc.), I've begun to suspect that there's certain features a language needs to bring to the table before it has a prayer of wide adoption:

1. A high-quality, cross-platform, open-source implementation.
2. The ability to store code in text files.
3. A command-line implementation which loads small programs quickly.
4. Support for portably interfacing to C.
5. Good library repositories and/or packaging.
6. An Algol-like syntax which isn't too weird.
7. Support for currently popular programming paradigms (people seem to change languages first and then to start slowly thinking in the new language).

Obviously, there's also a huge element of luck and timing--we only get one popular new language every 5 to 10 years.

Now, many of the items on this list are of zero theoretical interest, but getting even a few of them wrong seems to doom even very good languages.

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. Of course, the latter is pretty much the (admirable) intent of Haskell, which causes something of a dilemma. Although people approve of discipline in theory, they tend not to like it much in practice.

* 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. :-)

Hear hear

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!

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

And a few more for the list...

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.

Heh

I think it may be easier to go back in time to 1980 and just provide the language than to satisfy all the bullets in these lists ;)

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

Double heh

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.

Smalltalk on 8086-based DOS machine

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.

How much was it?

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.

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.

Not so much

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

Models of Software Acceptance - Richard P Gabriel

See Richard P Gabriel "Models of Software Acceptance" pdf

I think that a widely popular

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?

Being there...

We started building Dolphin in 1995 and, when Java floated in on the Internet bubble later that year, our disappointment was palpable. It wasn't just that Java was getting very big, very fast and was obviously going to make it harder to sell Dolphin to the masses. It was more that, really, the designers had just missed the point. Or at the very least they had missed an opportunity. Yes, they had a virtual machine and garbage collection, which was more than C++ ever did but what about all that other stuff they could have taken from Smalltalk? What about dynamic typing? What about keyword selectors to aid readability? What about proper Reflection? What about "Everything is an object"? Heck, you couldn't even add two Integers together. It was very sad.

Why "Swimming against the Tide"?