Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

Given Maxime's background notable background in JIT and optimizing compiler research, I'm quite disappointed that her argument for Smalltalk's failure is the simplistic and routinely thrown around canard of "pragmatism".

Why condemn Smalltalk for its idealistic vision when a lot of functional languages that are so trending are just as idealistic?

(A few notes: there are implementations of Smalltalk these days which do not involve graphical environments. GNU Smalltalk is the most advanced.

The assertion that textual mediums for writing code are always superior over visually enhanced ones isn't an argument so much as a culture war. It's also self-evidently of little weight, as the benefits of having a full-fledged Smalltalk VM are immediately visible.

Furthermore, the idea of Smalltalk as the hermit kingdom that locks you in to its toolset isn't as true anymore like it was in the past. Tools like Monticello can interact reasonably well with the outside world: https://stackoverflow.com/questions/8244502/version-control-...)

View on HN

> the benefits of having a full-fledged Smalltalk VM are immediately visible.

I'm not so sure they are. I've personally never been able to wrap my head around how I would use any of the Smalltalk environments I've played with to create and distribute something useful to a real person, entirely due to the necessity of "a full-fledged Smalltalk VM". It seems too all-or-nothing; maybe it would work well as an entire OS, but it doesn't work great at the application level.

From trying multiple times to give Smalltalk a spin, this has been my thought as well. It has a bootstrap problem, where it's hard to integrate it with the rest of the software ecosystem. I'm sure there are solutions to that, but they aren't advertized as well.

You could generate an executable with a pruned image. At least with the commercial Smalltalks.

Can anyone tell us how cumbersome it is to do the same thing with the free Smalltalks?

GNU Smalltalk is script based and while it's got support for images you don't have to use it if you don't want to. You can write a viable program by just creating a script with #!/usr/bin/gst at the top.

It also comes with Seaside, which is a pretty nice web app framework, and will run out of the box. Instructions here:

http://smalltalk.gnu.org/blog/bonzinip/seaside-development-g...

Neat, thanks for the pointer. Can you speak to what another commenter said about GNU Smalltalk being a not-particularly-great implementation?

All I have is anecdata, and stale anecdata to boot, so it would just be misinformation. I do see that the last release was two years ago, though.

Since I cannot edit my comment any longer.

For example, this is how VisualWorks Smalltalk does it (Application Delivery chapter):

www.cincomsmalltalk.com/main/Documentation/VisualWorks/AppDevGuide.pdf

(stupid question; I know nothing about smalltalk, but:) the necessity for a "fully fledged VM" doesn't seem to have slowed down Java adoption. Could you enlighten me as to how/why I've entirely missed the point please? :)

The Java VM is like a virtual processor --- it lets you run an ordinary program that's written in Java bytecode.

The Smalltalk VM is like a machine emulator --- it runs a complete Smalltalk system, complete with its own screen, GUI, multiple processes and concurrent programs, IDE, debugger, editor, etc, all mixed together. This typically all runs inside a single window, with its own windowing system.

It's a hangover from the days when Smalltalk would run on the bare metal of a computer --- it was the entire operating system.

You seem to have confused the Smalltalk VM with the Smalltalk image.

Most Smalltalk implementations have 4 pieces:

- VM like the JVM

- sources file

- changes file

- image file

No it does not "typically all run inside a single window, with its own windowing system".

Yeah, to say the same basic thing as the other commenter, but to use a different analogy, the "fully fledged VM" of Smalltalk is (or has been, in my experience) more like running a different OS in a VirtualBox window than like running a Java program. I think the JVM is a bit misleadingly named, or at least uses the VM terminology in a different way; it's really "just" an interpreter for a fairly simple assembly-ish language with a large runtime.

I'd have to agree. I have never wanted to write a program that would run inside a Smalltalk environment. I have never wanted to use a Smalltalk environment --- every time I've tried one I end up ragequitting after a few minutes because of the ghastly nested windowing system.

And I love Smalltalk, as a language. I want to write programs in it, and use it more, and get stuff done in it, but I'll be damned if I'll fight Squeak's windowing system and bizarre VCS.

Right now the only way I have to run Smalltalk is via Gnu Smalltalk, which is a bit old and cranky and not very fast. This makes me very sad.

(I wonder if I could translate Smalltalk source in to Lua and push it through LuaJIT...)

Dear god, don't use Squeak. Pharo.

You seem to have confused the Smalltalk VM with the Smalltalk image.

Most Smalltalk implementations have 4 pieces:

- VM like the JVM

- sources file

- changes file

- image file

To quote myself:

> I've personally never been able to wrap my head around how I would use any of the Smalltalk environments I've played with to create and distribute something useful to a real person

I'm not confused about the existence of different pieces, I've just never been able to wrap my head around how to fit everything together within the current software ecosystem to create and distribute something useful to a real person. This may be due to any number of things: poor intelligence or research on my part, poor marketing on the part of the smalltalk community, poor documentation, or a design that just doesn't fit in very well.

I'm not at all convinced it can't be done, I've just never been able to figure it out. I'd really love to read an article along the lines of, "here's how we successfully created and deployed a non-trivial smalltalk application sometime within the last 5 years".

>>…how to fit everything together within the current software ecosystem…<<

You mean like using Win32™ DLLs?

http://www.object-arts.com/downloads/docs/parameterconversio...

I haven't been looking for Smalltalk success stories. This sort-of thing?

http://pharo.org/success

Neat, yes, that sort of thing!

fwiw There's also a list of companies on the Pharo website, maybe their websites show more of that sort of thing --

http://pharo.org/Companies

Thanks for doing my googling for me. Clearly the last time I really gave it a go was more on the Squeak side than Pharo, which looks pretty great.

>>but it doesn't work great at the application level.<<

And yet --

A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36.

http://portal.acm.org/citation.cfm?id=604258

How about writing web apps in Pharo (or Squeak)? There are several nice frameworks, Seaside just being on of them.

How is it any different than requiring a runtime (e.g. Java or NET)? That you also distribute the image? That's not that big a difference distribution-wise.

depends upon your definition of application... a machine-consuming set of processes working together, possibly across a distributed network? ummm yeah perfect. smalltalk, erlang, and a handful of other candidates... Java would be considered "experimental" in such environments, as supervisory trees etc are not inherent.

building "apps" for desktop or mobile? ok, you got me there... smalltalk is probably not apropo...

>>building "apps" for desktop or mobile? ok, you got me there... smalltalk is probably not apropo...<<

… because?

If the reason for Smalltalk's failure is simple pragmatism, how could anybody's argument rise above that level?

The "blank canvas" features of Smalltalk like the image, monkey patching, edit and resume, modifying individual object instances, retry, and so on are wonderful for experts and just terrible chaos for everybody else.

When you are designing a language, the thing to keep in mind is that an expert can create a masterpiece even from a Java-style "connect the dots" language, they just don't like to, but when using a language designed for experts the common programmer struggles to even create something common.

Smalltalk wasn't designed for experts, quite the opposite. That was a major intention, part of a line of efforts to remove the artificial segmentation between user and programmer.

Smalltalk was designed for experts. It wasn't intended to be designed for experts though.

That's why we study the reasons why it failed so that we don't make the same mistakes again.

Failed?

pdf "Ubiquitous Applications: Embedded Systems to Mainframe"

http://www.davethomas.net/papers/ubiquitous1995.pdf

Smalltalk was replaced by free-as-in-beer future-of-the-internet Java.

Yes, failed. Smalltalk failed.

As in, it's been around for 40 years and it's not even in the top 50 on TIOBE ranking vs C which is everywhere. The index has its flaws, but being >50th is certainly a significant failure.

Java is often claimed to be inspired by Smalltalk, but it's opposite in almost every way. Instead of an image, there's files. Instead of a persistent runtime and data, programs are started from scratch. Instead of monkey patching, classes are not modifiable. And so on. Java, intentionally or not, learned from the failure of previous languages.

Actually Java is derived from Simula. The core of the language, even inner classes, map almost 1:1 with it.

I guess it really depends on what you care about when you think about "failure" and "success". The type of languages that are popular in the industry is just like the type of operating systems that are popular in the offices of companies. Nothing to do with being actually good. Just barely good enough to make something the company can profit off.

> As in, it's been around for 40 years and it's not even in the top 50 on TIOBE ranking vs C which is everywhere. The index has its flaws, but being >50th is certainly a significant failure.

Are we assuming that the only type of success is continued growth and adoption? By this measure, every language that will ever have been conceived will fail eventually... Or is there a cut-off when you can't say a language failed any longer because at least it peaked high?

There are lots of languages that have been big and have influenced all of programming and software development. I don't know if we can just blanket label them as failures because they don't have many users at the moment. These are languages that have inspired far more advancement in programming than most of the popular ones.

>>Smalltalk was designed for experts.<<

We have been teaching Smalltalk to children since the Spring of 1974…

pdf "TEACHING SMALLTALK" SSL 77-2 June 1977 XEROX PARC

https://ia601606.us.archive.org/15/items/bitsavers_xeroxparc...

I think there is an in-between ground not covered by your comment. Good languages tickle (some class "foo" of) programmers in ways that tend to expand their repertoire. Many of those expansions enable better approaches to system design.

It may be true that "experts" could do it even in Java, but many "foo-level" programmers would just do it the Java-way in Java, but can appreciate the better features of a better language in context.

It's also probably true that many programmers will struggle with foo-level features. That harkens back to Vanier's LFM and LFSP essay: http://www.paulgraham.com/vanlfsp.html. Having seen LFM approaches to systems over the years, I'm skeptical that it is the right approach for anything with much complexity. YMMV.

> Why condemn Smalltalk for its idealistic vision when a lot of functional languages that are so trending are just as idealistic?

I don't think she condemned Smalltalk for being idealistic. I think she said that Smalltalk condemned itself to irrelevance by being idealistic. And, yes, that's a danger for the currently trendy functional languages, too.

If your language is harder to get real work done in than the alternatives, your language won't get used. So if your commitment to your version of "purity" is making it harder for your language to be used in the wider programming world, then you are dooming your language to irrelevance. And that's your choice, if you want to make it. If you want your ideas to be useful to people, though, you have to care about making your language usable by people for the tasks that people need to do.

Unfortunately the ultimate implication of this argument is to largely rehash the same old ideas and biases that most programmers are mentally comfortable with, and never really push any boundaries. This is the vicious cycle we're stuck in now, and it must be broken eventually.

I didn't say that there was no place for languages to single-mindedly follow their own idea of purity. I said that doing so and popularity were often at odds.

There's nothing wrong with your language following your ideas to the logical extreme, and seeing where it leads. There's nothing wrong with saying, "This approach solves some of these problems that other languages have." But what bugs me is the people who think that their language is The One Right Way(TM), and everybody else is too stupid to see it, when the actual reality is that their language just isn't all that they think it is in real-world use.

All in all, I think that the majority of programmers aren't as stupid as you think they are. I think that they'll learn a language that offers them real advantages for what they're trying to do. They won't learn every language that comes along, though. They won't learn every language that gets hype for a while. They need to see that it will actually gain them something before they invest in it.

they might not necessarily have something to immediately gain if all tooling in a given field has already bent to the will of a different paradigm... in web-land, we are only at the level of REST api's now, after years of bloat like SOAP xml/rpc stuff... sometimes people have to get fed-up with an entire way of doing things before we see significant change...

> If you want your ideas to be useful to people, though, you have to care about making your language usable by people for the tasks that people need to do.

I would make a distinction between ideas and languages. Ideologically "pure" languages force us to re-think the assumptions we make in other languages. For example, as a language Haskell could have abandoned purity in order to perform side-effects in the correct order; instead it stuck to its guns and eventually monads, applicative functors, arrows, algebraic effect handlers and all kinds of other techniques were discovered to overcome the problem in a "pure" way. Regardless of whether Haskell is "usable by people for the tasks that people need to do", the fact that it exists and remained "pure" has lead to better libraries in other languages (eg. LINQ).

Likewise for Lisp (garbage collection, higher-order functions, macros, s-expressions, etc.), Scheme (tail-call optimisation, call-cc, the "Lambda the Ultimate" papers, etc.), Smalltalk (message-passing, doesNotUnderstand, etc.), Self (prototypes, morphic, etc.), and so on.

Whether these languages are useful day-to-day doesn't really matter. More important is that their purity forced smart people to look at the world in a new way, which has lead to all kinds of ideas which are being adopted in more pragmatic languages like Python, Javascript, etc. either at the language level or at the library level.

Oh, I agree. The pioneers get shot, and the next wave learns. The question for a language designer is, which do you want your language to be? Do you want it to be, essentially, a long-running research project that explores in one direction as far as you can? Or do you want it to be a useful tool for a large number of people? If you choose the former, don't complain when you don't get the latter.

> Whether these languages are useful day-to-day doesn't really matter

No. Usefulness does matter because, at the end of the day, programming languages are tools, and a useless programming language has no more value than a hammer that breaks if you hit it on anything.

It's nice that there are research languages out there that explore new ideas, but Smalltalk 80--the prototype for all modern Smalltalks--was designed and released to be useful day-to-day, and the Smalltalk distributions out there now--Pharo and Squeak--really look like they want to attract users.

> Smalltalk 80--the prototype for all modern Smalltalks--was designed and released to be useful day-to-day

That's a straw man. Yes, Smalltalk 80 was designed and released to be useful day-to-day, but it certainly wasn't the prototype. As I understand it, Smalltalk 71 was the first semi-formal definition, and 72 was the first working version. These were designed explicitly for programming language research at Xerox PARC. After After a few iterations, the good ideas were packaged into Smalltalk 80.

In fact, Alan Kay actually seems to be disappointed that Smalltalk 80 had such a different goal than earlier Smalltalks. From http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

> This was why I complained at the last OOPSLA that - whereas at PARC we changed Smalltalk constantly, treating it always as a work in progress - when ST hit the larger world, it was pretty much taken as "something just to be learned", as though it were Pascal or Algol.

> Smalltalk-80 never really was mutated into the next better versions of OOP. Given the current low state of programming in general, I think this is a real mistake.

So, you're saying that the prototype for Pharo and Squeak was Smalltalk 71 or one of the other, earlier versions of Smalltalk?

In any case, I know the early history of Smalltalk too. All I'm saying is that your original point was flawed: the ultimate goal of programming languages is to be useful tools; otherwise, they are merely art.

Experimentation during the development of a programming language is an obvious part of inventing them--as experimentation and prototyping is with any tool--but experimentation is not their ultimate goal.

> the ultimate goal of programming languages is to be useful tools; otherwise, they are merely art.

Many programming languages exist to be "merely" art; eg. pretty much everything on esolangs.org. There's nothing wrong with that.

Also, you're the only one talking about "useful tools". I used the phrase "useful day-to-day" very carefully: for example, space telescopes are "useful tools", but they're not useful for the day-to-day tasks people encounter in the way that a hammer is.

I think the suggestion is that Alan Kay was disappointed that there was no Smalltalk-82, Smalltalk-84 and perhaps disappointed that there was no Smalltalk-04 with all the base libraries re-designed around traits.

http://www.ptidej.net/courses/ift6251/fall06/presentations/0...

Smalltalk-80 calcified Smalltalk.

Skimming, I could not discern the difference between traits and interfaces, although the paper seems to distinguish the two. Could you summarize? I'm interested and I lack the bandwidth for a careful reading at the moment.

You have the reference, read the paper at your leisure.

I intend to.

I don't know if it's what you meant, but I read your comment as overly dismissive. Pulling things out of references makes for better conversation. Of course, if you also don't have time or bandwidth, or it is just really hard to summarize, that is understandable.

>>If your language is harder to get real work done in than the alternatives, your language won't get used.<<

It wasn't; it did.

>If your language is harder to get real work done in than the alternatives, your language won't get used.

Both statements couldn't be further from the truth about Smalltalk.

It was far easier to get real work done (still is over many languages) and it had a decent following, considering compilers were commercial, people avoided so dynamic languages for C/C++ at the time, and it was pro-internet.

> Why condemn Smalltalk for its idealistic vision when a lot of functional languages that are so trending are just as idealistic?

They're only trending in hype -- not adoption.

Reply on news.ycombinator.com