Hacker News Reader

Comment by zeveb | Hacker News Reader

It's useful in education, but it also was competitive in what became the Java market. Weirdly, the world bought into a relatively static language when it had the option to go for the extremely dynamic and flexible SmallTalk instead. I have always thought it an extreme shame that the man-centuries (man-millennia?) sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead.

View on HN

Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control?

For a long time, Smalltalk and its brethren were terrible at sharing code; you had a bunch of stuff in an environment, and importing and exporting stuff was a nightmare. Has this changed?

Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run".

I'd be happy to be wrong about any of this. Smalltalk is my favorite language (that I'll never ship a product in) . . . but when you look at a couple of my recent projects, which are PHP + JavaScript + WebGL that interpret and let you look at a bunch of back-end statistics, I'd sure like to be using something better.

Regarding your last comment: surely there's a good compiles-to-JS option available these days? There's even a Smalltalk for client-side programming:

http://amber-lang.net/index.html

... not sure how that would work with WebGL though.

Amber's quite heavyweight and requires server-side support to do anything useful.

But Smalltalk's so simple that writing your own transpiler isn't that hard --- I have an entirely browser-side prototype in about 2kloc:

https://github.com/davidgiven/stellation/tree/stellation5/cl...

Performance is adequate, but not great. Method lookup is the dominating factor, because you need different code paths based on the type of the receiver (number, string, object...)

Of course, writing the libraries is the bulk of the work.

> Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control?

Possibly. But you may be looking at history through modern lenses. Java was released in mid 90s, and the open source VC tools of the day were RCS and CVS. SVN came in 2000. The explosive growth of DVCS came after that.

> Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run".

A Smalltalk image is similar to a bunch of Java packages bundled into a jar/war/ear/*ar file. You can run any number of OS processes, each a Smalltalk VM running an image, on a single computer. You can scale out by running Smalltalk VMs across multiple computers. Just as with Java and JVMs.

It's at least debatable whether or not an "extremely dynamic" environment is a pro or con when it comes to saving man hours

> sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead.

Well, one of the cornerstone technologies of the JVM, HotSpot, was actually developed for a Smalltalk implementation, Strongtalk, and later adapted for Java.

... and then some of that same team went on to do the compiler used by node, and Chrome (V8).

Modern JavaScript has many Smalltalk features.. [starts putting on flame retardant suit].

The best parts of JavaScript are where the Lisp and Smalltalk heritage is apparent.

The worst parts are where a PHB told Brandon Eich "we're going to call it Javascript, make it more like Java", and where the PHB told him "I don't care if it's done, we need to ship it".

Given the object model, I would add another Smalltalk descendent into the mix: Self http://www.selflanguage.org

Self was definitely an influence. It's where the prototype inheritance came from. Not sure that's a good thing. Smalltalk was more traditional in its inheritance model even if it was all duck typing.

For UI, prototype inheritance was nicer on the Newton (NewtonScript) than on the several of the class-based stuff I played with[1]. Morphic include in Pharo / Squeak is based on Self's UI. I actually like a prototype (other than performance issues) more than class-based. It has a much nicer, lighter feel for me. I just don't think Javascript is the best at it. I loved programming NewtonScript other than its clunky syntax in places. NeXTSTEP got around a lot of crappy class-based behavior by having live objects.

1) I swear I still have nightmares that include OnOk

Reply on news.ycombinator.com