Hacker News new | comments | show | ask | jobs | submit login
What Killed Smalltalk? (pointersgonewild.com)
104 points by Garbage 844 days ago | hide | past | web | favorite | 185 comments



Smalltalk is a lovely, lovely language. It's fantastically simple --- it's got about four syntactic elements: you can call methods, you can declare and assign variables, you can create closures (called blocks in the Smalltalk world), and you can return from methods. That's about it. There's no control flow --- you do that through passing blocks into methods. You can learn the entire language in five minutes.

Of course, learning the library is another matter. But it's always depressed me that nearly forty years later, our high-tech and ultrafast dynamic languages still cannot hold a candle to Smalltalk for clarity, simplicity and usability.

(And the way that every time they invent a new feature, chances are Smalltalk had it in 1980. Better.)


> Smalltalk is a lovely, lovely language. It's fantastically simple... learning the library is another matter.

I think that's a fundamental issue. On the surface, Smalltalk seems very simple and easy to grasp but as you delve deeper and deeper it gets harder to follow and more magical. Examining how the underlying platform worked made my head spin. I went from a Smalltalk proponent to a detractor the more I learned about it and used it.

I think that's the fundamental problem with every "simple" language; it just forces the complexity to spill out into another layer.


That's a horrible reason to hate a language. Every language has layers of complexity. In C++ or Java the complexity is in the compiler, the library and the runtime. In Smalltalk it just happens that the layers are available to everyone to inspect. You are free to inspect or ignore it, but the complexity never really goes away even if you don't see it.


Seems like it's a trait shared all these: FORTH, ST, Lisp. They're the logical machine right in your face. No strict classical lexer / parser / language / compiler / binary layering. It's very thin and hackable.


The simpler something is, the more you have to build yourself, though the likelihood is that you'll have to learn some library.


I'm intrigued. Can you point to a book or guide that expands this further, is beginner friendly and not 300 pages? Thanks!


Perhaps "I Can Read C++ and Java But I Can’t Read Smalltalk"

pdf 10 pages

http://www.eli.sdsu.edu/courses/spring01/cs635/readingSmallt...


In the time it takes to write a 10 page document, any reasonable person could learn to read smalltalk.


No one is being asked to write a 10 page document.


Amber has a really nice interactive tutorial:

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

It's actually running in your browser, and the whole thing is a live coding environment in disguise. Well worth a play.


First thing I get when clicking "DoIt" in Chrome or Firefox is "Parse error on line 1 column 47 : Unexpected character null".

Edit: turns out, I should've looked more closely. You're supposed to select particular text before pressing the button. If you do this it works. Still, they might want to consider a more friendly error message ;)


I think what it's trying to tell you is that you haven't selected any text inside the edit window. (I agree it's a terrible error message.)


Almost as terrible is the fact that the listed keyboard shortcut alternative to clicking DoIt (CTRL d) actually deletes, rather than executes, the selected text.


In Chrome, at least, Ctrl+Shift+D works. So might be an implementation detail.


You can also try SqueakJS https://bertfreudenberg.github.io/SqueakJS/

It implemented Smalltalk primitives in JavaScript so it can run a real, bit identical, Squeak image.


Maybe start with "Smalltalk 80: The Language", and just read the first three chapters:

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

Also available for $1.89 (plus shipping) used from Amazon:

http://www.amazon.com/Smalltalk-80-Language-Adele-Goldberg/d...


Those are very dated and not really beginner friendly.


How is learning the library difficult? Or more difficult than learning libraries in any other language?


> But it's always depressed me that nearly forty years later, our high-tech and ultrafast dynamic languages still cannot hold a candle to Smalltalk for clarity, simplicity and usability.

You're aware that these are extremely subjective attributes, right?

Most people not using Smalltalk (or who tried it and decided to not use it) will argue that Smalltalk is anything but clear, simple or even usable (seriously, even Pharos or Squeak have the usability of late 90s IDE's).

And of course, there's the fact that Smalltalk is dynamically typed, a class of languages that's fast headed for extinction.


> Smalltalk is dynamically typed, a class of languages that's fast headed for extinction.

I'm going to go out on a limb here, and chalk that one up in the "famous last words" column. :)


I dunno, a lot of modern language academic research and push are going towards a very compile-time-typing-everywhere mode. see Haskell and Idris, for instance


And a huge proportion of language research gets ignored by the mainstream, so it's not a very useful indicator.

For static typing to "win" (and though my favourite language these days is Ruby, I hope it does in the long run), it will need to become near transparent.

If type inference is sufficiently advanced to avoid almost all type annotation, and the type system just gets out of your way 99% of the time, then yes, dynamically typed languages might be heading for extinction.

But you'll have to wait a very long time for that, judging by the current crop of statically typed languages.


... which are known to drive major trends in modern programming language usage? Sorry, not seeing your point.


Note that I was talking about the language, not the environment! I totally agree that Smalltalk IDEs and the general development workflow is poor (and is most likely the reason why it's so little known).


Sigh. Nothing killed Smalltalk. It's not dead. Neither is Scheme. Yeah, both of those languages have pretty small communities, but that's viable in the Internet Age.

Heck, even Self, which nobody ever used for actual shipping software (as far as I know), still has some life in it. The latest release was last year and runs on Linux, Mac OS X. (What, no Solaris support?) http://blog.selflanguage.org/2014/01/12/self-mallard-4-5-0-r...

Compared to Self, Smalltalk and Scheme are downright mainstream, and used in all sorts of production software.

This is important if you're planning on inventing a new programming language. The chances that you create the next Javascript or Java are slim to none. Those languages are platforms that are backed by large companies. Languages invented by enthusiastic geeks can succeed, but they don't take over the world. Even when success does come, it's after decades as niche languages with tiny communities.

If you consider Smalltalk and Scheme dead, be prepared to have your language be stillborn.


Self gets used by the enthusiasts in production, for a suitable definition of production. I believe the Self website is served by a webserver written in Self for example. I've also served my blog in the past from a Self webserver.

I found the comment in the post about how a few lines of code would be better than the object interactions in the GUI interesting. I thought this would be the case when I started using Self too but even with the GUI you still write code. The method bodies for example are all textual code that feels like programming in any other language.

Where the GUI excels is exploring systems, prototyping designs - and then refactoring the design towards a production implementation. It also makes the applications 'live' for users. They can drill down into the application objects and see how things work. The line between OS, application, and development is very blurry in Self.


Yep, the Self website is running on a Self webserver (which is itself running on a half written Self cloud). Seems to be fairly stable, all things considered.


I wonder if Smalltalk doesn't have much larger community now, than it did in the 80s. Sure, other languages are bigger still -- but if we have, say a thousand times as many Smalltalk programmers today, as in 1980 -- then hopefully the language will keep getting better. Especially since there are now a few Free/open source implementations, tutorial/books and frameworks.


Hmm, I wonder if Pharo/Squeak publish their download numbers? Is the recent uptick in smalltalk articles on HN an indicator in increasing interest in the language (even though they've been mostly harsh).


SmallTalk was taught as a course when I was at University in the 90s. I doubt that's the case now even though conceptually it's a good language in a CS education. We also had courses with functional languages (at that time ML) and Lisp was taught with AI.


Maybe. I don't think being featured in CS education is all that interesting (for fringe languages). I was thinking more along the lines that computing is becoming way more accessible all the time (for one thing a full Smalltalk image+vm is no longer a "large" download) -- so the number of people contributing to Seaside, Pharo etc might be growing.

I also wonder a bit about Gemstone/GLASS (the ones behind the Ruby maglev vm/system).

As for packaging as others have commented on, I found[1] -- but I think things like the rise of quicklisp[2] shows that these truly powerful languages (and I think Smalltalk is indeed "lisp powerful") can spring up from the brink of death/irrelevance through the serendipitous release of a framework/tool/technique etc.

It just occurred to me that it might be interesting to implement Smalltalk on top of Racket as a language -- Racket has (seemingly) great support for creating deployable executables[3].

[1] http://forum.world.st/Create-a-exe-application-in-Pharo-2-0-...

[2] https://www.quicklisp.org/

[3] http://docs.racket-lang.org/raco/exe-dist.html

[4] See eg: http://queue.acm.org/detail.cfm?id=2068896 for an example "Adventure"-like language. Or scheme-without-parens: http://pkg-build.racket-lang.org/doc/sweet/index.html

PS: Related to Racket and languages, I also came across this nice little post:

"7 lines of code, 3 minutes: Implement a programming language from scratch" http://matt.might.net/articles/implementing-a-programming-la...


Unfortunately, modern smalltalk environments (pharo, squeak) are terrible compared to modern Common Lisp implementations.

The libraries are not there, monticello doesn't even support HTTPS last I checked, nevermind cryptographic signatures, they don't support concurrency via native OS threads, the FFIs are a joke (just take a look at pharo), the graphical environments are laughable (pharo and squeak look like total crap on OSX retina machines, the font rendering gives you headaches, yes it's THAT bad), performance is abysmal, I could go on for ages...

Common Lisp on the other hand has multiple mature opensource native code compilers (SBCL and CCL) that support multiple platforms, concurrency via OS threads, have amazing foreign function interfaces, performance that is close to C, optional paid support for the opensource implementations, a development environment that is more traditional but also lets you program 100% interactively from within the image without compromising when it comes to interfacing with traditional version control, also support snapshots and so on.

Smalltalk is more "dynamic" than Common Lisp and is also better (in theory) when it comes to interactive development. But in practice, Pharo and Squeak are stuck in the 90s at best and compromise in areas that today are of paramount importance. Common Lisp doesn't and gives you all the options.


Same - I did Programming 1 and Programming 2 in VisualAge for Smalltalk in 1997


> Languages invented by enthusiastic geeks can succeed, but they don't take over the world.

Ruby, Python, and Lua are all obvious counter-examples to the idea that enthusiastic geeks cannot create languages that are many orders of magnitude more successful than SmalllTalk and Scheme. Even CoffeeScript, if you can call it a complete language, is in the realm of that success.

The only language that has come out recently that is successful purely because of the backing of a large company is Swift.


Ruby, Python, and Lua were all created in the early nineties, when the alternatives were Tcl and Perl. And it still required each of them a decade or more to take off.

This was also at a time when most programming languages did not have free implementations and companies actually sold compilers and interpreters. The programming language landscape was totally different back then.


Actually, those are the very languages I had in mind. Perl too. Yes, they have many more active developers than Smalltalk. But you know what? I was part of the Ruby community before Rails, and it was tiny. That was after it had been around for 10 years.

So I'll say it again. If you want to create a new language, go for it! But I wouldn't sneer at Smalltalk and Scheme in the process. Those communities are relatively small, but they're still huge compared to your brand-new language, and they will be for decades. And if you judge language success by innovation and influence rather than developers... well, you have even bigger shoes to fill.


>Actually, those are the very languages I had in mind. Perl too. Yes, they have many more active developers than Smalltalk. But you know what? I was part of the Ruby community before Rails, and it was tiny. That was after it had been around for 10 years.

So? Languages might take a while to catch on. Ruby has a huge community and lots of jobs now. And Python has had that even without something like Rails to dominate adoption. Perl was also huge back in the day.

As a counterexample Dart is nowhere near even Ruby pre-Rails was, even though it's from a major vendor.

And of course C, C++ etc didn't succeed because they had the backing of a major vendor, like Java or C# did.


> And of course C, C++ etc didn't succeed because they had the backing of a major vendor, like Java or C# did

C - AT&T, UNIX vendors

C++ - Almost all C compiler vendors adopted it. CORBA and Windows Development helped it.


Having support from third party vendors is not the same as succeeding because you have the backing of a major vendor (and especially one who created you), like Java or C# or Swift.


C would have been a footnote in the history of programming languages if AT&T didn't offered the code to a few universities, whose students created the UNIX workstations like in Sun's case.

In the late 80's the language had zero value in the hobbyist world.

The few compilers that existed generated crappy code, were not even K&R compatible and only mattered to those that had access to UNIX either at work or university.


C was invented at Bell Labs, a subsidiary of AT&T. Surely that counts as "backing of a major vendor"? C spread along with UNIX, which AT&T as vendor licensed to many other companies. It was also helped along by AT&T's own use of C and UNIX in its internal systems, especially telephone switch development.


> The only language that is successful purely because of the backing of a large company is Swift.

Rust and Go seem to fall pretty firmly in to that category as well.


I wouldn't really call Rust isn't successful yet, though it showing signs that it may become that way. Go, maybe, its at least farther along the path.


>The only language that has come out recently that is successful purely because of the backing of a large company is Swift.

We don't know that. I mean it's not like ObjC, where the main pusher and motivation to adopt it was Apple having it for OS X (as evident by the relative lack of adoption of ObjC in Linux, NextStep etc).

Swift does have got people genuinely interested to use it even outside the Apple ecosystem, they just don't have the chance to, yet.


don't capitalize the T. Just Smalltalk. It's cleaner


>Sigh. Nothing killed Smalltalk. It's not dead. Neither is Scheme. Yeah, both of those languages have pretty small communities

That's how we define "dead" for languages: "pretty small communities".

>but that's viable in the Internet Age.

Viable to exist and continue having small communities. But not viable for what matters to lots of people, mainly being able to use them for their company/projects with great support from various sources, documentation, books, new releases and bug fixes commining round the clock, and answers for their questions on Stack Overflow.


Oh stop picking his reply apart when you exactly what his point is: if you consider smalltalk "dead", and you are "going to invent a cool new language" then you can probably get into the BACK of the popularity line, after REBOL or whatever, as basically you aren't worthy... not even close to worthy...

in a nutshell, a still-revered, still-used (niche public) language built by people with an actual high-level concept (TDD) from the academic world with the support of much of industry at the time, said language probably can safely stay on it's pedestal despite such a fluff-brained "analysis" as linked article purports to provide...

i mean the central point of this article is: "I'm going to make a language that will be big and smalltalk is a convenient hoity toity strawman for me to knockdown"

weak.


>then you can probably get into the BACK of the popularity line, after REBOL or whatever

I don't know. Golang, Rust, Clojure and Scala seem to do quite well for themselves, quite better than Smalltalk.

I don't have exact numbers of course, but considering job postings, use by high profile companies, books coming out, conferences, tooling created, blog posts and HN articles, they are way ahead of Smalltalk today.

Besides this:

>as basically you aren't worthy... not even close to worthy...

Sounds fishy to me. Even if you're not worthy there's no reason not to try if one wants to. And that's how we do get the 1 in 10.000 languages that ARE worthy anyway.


I don't think you got his comments to you at all.


I don't know, I think I just disagree with his points (and agree more with the article).

He says: " a still-revered, still-used (niche public) language built by people with an actual high-level concept (TDD) from the academic world with the support of much of industry at the time, said language probably can safely stay on it's pedestal despite such a fluff-brained "analysis" as linked article purports to provide..."

To which I disagree. What do you think I didn't get?


Scheme is actually used quite a few places, just not as much as a general purpose implementation language.

I would say that smalltalk is way more "dead" in the sense that news doesn't make waves the same way scheme news does.


>Scheme is actually used quite a few places

Don't leave us hanging, I'm sure lots of people would like to know of Scheme success stories besides Jak and Daxter.

http://c2.com/cgi/wiki?LispInJakAndDaxter


former PLT scheme = Racket...

it's a tight little platform! batteries included... check out DrRacket, and it's dependency graphs that appear upon mousing over defined words...it will even show graphics and mathematical symbols in the REPL if that happens to the be the domain of the functionality you are testing... loads of libraries available... great package system. there's a pretty basic thread-per-connection web server (extension of a generic server i forgot the name of) included and you can get up and running building something very very quickly...


OS X ships with a couple hundred files worth of Scheme related to sandboxing:

    mdfind -name .sb


lilypond is a big one. Better music notation quality than finale and sibelius.


I generally like Uncle Bob, but he isn't a Smalltalker and didn't demonstrate any insight into Smalltalk's unpopularity in that talk.

Worse, this is hardly the first or only time a prominent Rubyist ignorant of Smalltalk has publicly attacked it. Sarah Mei did so in a talk two years ago, mocking it for not having any conferences of its own (ESUG, Pharo Days, and Smalltalks apparently don't count), and she and Steve Klabnik recently had fun tweeting anti-Smalltalk quips back-and-forth.

Given that most of the non-awful stuff (where "awful" means, for example, syntax too complicated to be described by a CF grammar or horrible performance) they like about Ruby was lifted directly from Smalltalk, you'd expect Rubyists to be extremely deferential and respectful towards Smalltalk and Smalltalkers, but they aren't. Instead they're arrogant and condescending despite being ignorant, validating all of the well-earned stereotypes of Rubyists.

As for why Smalltalk "died" (cf. pharo.org) I would say it was too expensive, both in licensing terms and hardware costs. You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk. Some vendors would charge (and still charge) a percentage of your revenue forever, which is insane. Then Java came along, and it was free.

Smalltalk also missed out on the open source revolution, not having viable libre implementations (Pharo, GNU) until relatively recently.


I suspect it was performance, cruft, and aesthetics that killed it more than price. After all, expensive things that get popular generally become cheaper (or have cheaper versions released).

My experience with SmallTalk was that by the time it had any chance of uptake it was already knee-deep in cruft (e.g. multiple overlapping visual class hierarchies that would be mixed and matched within projects to devastatingly awful effect).

In my experience (admittedly mostly dealing with IBM and IBM-sanctioned vendors) a typical Smalltalk demo was a program that ran 10x slower than VB on a computer with twice as much memory (and at least as good a CPU) as anyone other than a Smalltalk coder had.

And Smalltalk programs tended to look awful and not be easily fixed (because of the overlapping cruft issue).

I'm pretty sure that Rubyists are no more ignorant of Smalltalk than Smalltalkers are of Simula.


It's weird, I've read stories about Visual Age for Java being better (UX, speed) than the first versions of Eclipse. Unless early Eclipse were unbearably slow, I took it as a sign that ST was solid for complex programs.


> I suspect it was performance, cruft, and aesthetics that killed it more than price. After all, expensive things that get popular generally become cheaper (or have cheaper versions released).

I think performance was a huge problem (I did mention it in passing). But you have to remember that just getting your hands on Smalltalk was difficult back then. There were no free versions, and the commercial versions were expensive. At least with Unix, most university workstations in the 80s had a copy, unlike VMS. The result: a proliferation of free Unix-like OSes while the less accessible VMS slowly fades into obscurity.

> I'm pretty sure that Rubyists are no more ignorant of Smalltalk than Smalltalkers are of Simula.

I don't understand the analogy. Ruby is an unoriginal Smalltalk knock-off that compromises its purity, simplicity, and dynamicity. Rubyists should therefore express deep admiration for Smalltalk in the same way Smalltalkers do Lisp, but they don't. Simula was an ALGOL-60 derivative that had classes and co-routines; by comparison, Smalltalk was nothing short of revolutionary, yet I've never seen a Smalltalker attack it.


Given the most common mention of smalltalk is of it being the first OO language and I seldom see it corrected by people who should know better. At least Rubyiata acknowledge Smalltalk exists.


>>I suspect it was performance, cruft, and aesthetics… In my experience (admittedly mostly dealing with IBM and IBM-sanctioned vendors) a typical Smalltalk demo was a program that ran 10x slower than VB on a computer with twice as much memory…<<

So incompetent programmers ?


>>You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk in the 80s or 90s.<<

Different Smalltalk implementations, different prices:

https://books.google.com/books?id=wJswszKTwl4C&pg=RA1-PA43&l...

>>Then Java came along, and it was free.<<

Free and The-Future-of-the-Internet TM.

----

There is an important technical / licensing / business problem with Smalltalk that has not been mentioned -- lack of library standardization.

Apart from a few core classes, each Smalltalk implementation had different class names and method names for things that once-upon-a-time were special but quickly became commonplace -- like windows and menus and …

So you could never hire a "Smalltalk" developer: you hired a VW developer or a Smalltalk/V developer or a VA developer and waited for them to get up to speed with an unfamiliar environment.


Notice ParcPlace's offering is more than 7x that of MS or Borland. I believe both it and Digitalk's competitively-priced alternative were merged into a single product after PP and Digitalk merged.


The businesses merged, not the products.


You're correct; a product line merger was attempted but failed, so VSE was ultimately just killed off.


I'm a Rubyist. I've never written a serious software with Smalltalk, but I love the core ideas of Smalltalk.

I'm not convinced this is the end of Smalltalk. Given the increasing interest in virtual reality (the Rift, Magic Leap, HoloLens, et. al), I think there will be a significant interest in being able to directly program an immersive VR environment.

I think Pharo and the quiet work on Open Cobalt will surprise people once people start looking for ways to live-edit things in a VR environment, and the kids in the upcoming generation gets a hold of it.


That's nice of you to say, but I think Smalltalk will probably remain unpopular because it's too different (image-based environment), too powerful (in the Lisp sense, where you can modify core parts of the system while it's running, including the compiler), and worst of all, it's now old, and most developers aren't interested in old tech.


Unless they reinvent the old tech :-)

The image-based environment throws me off, but it's being reinvented in a different way: Docker container images.

I'm not really thinking about popularity as a general platform like the way a lot of people use say, Java. I'm thinking about a niche area that is still relatively obscure, will be popular in the future, and very few other technology platform will fit it well.

I think a lot of people will try to throw Javascript as the scripting language for the building VR worlds. It might be workable, but the mindshare for creating VR content is still up for grabs.

The biggest obstacles I think will be in two areas:

(1) An equivalent Github / Open Source thing. Open Source did not really take off until Github and it's sibling clones got popular. That property was written extensively by Stephen O'Grady of Redmonk -- git and Github made things easy to fork and easy to merge, which reduces the friction of having the community contribute things back. I'm not necessarily saying to implement Github for SmallTalk, because that would not bring the uniqueness of SmallTalk in. But for example, I can dip into Github and check out what the Python or Lua community are doing. Montecello baffled me until I realized that you're not supposed to interface it with the web, you're supposed to interface it from inside the SmallTalk environment. This leads to the psychological shadow-side of what makes SmallTalk awesome.

(2) The all-inclusive environment of SmallTalk shares a similar attitude that long-time Lispers have with their environment, particularly Emacs. This is more of a psychological thing. At the minimum, there's likely not as big of a push in creating the tools mentioned in (1). This is the psychological shadow-side of having a very comfortable environment that you can customize to you. There's always going to be some sort of emotional resistance to bringing new stuff in there. Montecello is a great example: the web is kinda the lingua franca of exchanging ideas, so if it's not on there, it's hard to see. I go looking at the Montecello repositories via the web browser, and that experience was broken. It took me a while to realize I was supposed to browse that stuff from inside a SmallTalk environment. (So just off the top of my head: one idea is say, use that Squeak -> Javascript to host an image so you can browse into the SmallTalk world; preset it with Montecello. Just as a starting point.)

I've only looked at the community on the surface, but I'm willing to bet that the Pharo folks are making changes in there.

For me, SmallTalk is a really important technology, not for the world as a whole, but for kids. I usually think of my step-daughter as the yard stick: what would I want to show her about this world? I'm not intending her to make a living off of SmallTalk, but something better, more important: this idea that she can remake her environment by first conceiving and envisioning, and then clearly expressing her intent. That's a skill she can take into any domain.

But yeah something like: run around in a voxel engine like Minecraft, and being able to edit any voxel block in front of you to do something, or even add completely new behaviors. And sharing that with your friends. While using an Oculus Rift. Something along those lines.


"the mindshare for creating VR content is still up for grabs."

You mean it's not VRML? The 90s lied to me...


Ha! I vaguely remember that. Thanks for bringing it up -- gonna check that out sometime too.


> mocking it for not having any conferences of its own

As someone who has not worked in ruby, I have to say that this reads like great parody of the ruby community as seen from an outsider perspective.


... I'm not sure which tweets you're talking about, exactly, but I have a lot of respect for Smalltalk. Some of my earliest programming was in Hypercard, which used a derivative of it. Smalltalk Best Practice Patterns is a favorite book of mine.

The only thing I can think of was quoting that old adage, "In an OO codebase, everything happens somewhere else," which was said by a prominent Smalltalker but is about far more than Smalltalk.

I don't use Smalltalk personally because its greatest strength, the image, is also its greatest weakness, a very unusual development environment. Vim keybindings are basically part of my DNA by now, and it's much harder to share code without a textual representation.


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


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


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


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.


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.


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


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


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.


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.


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


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


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.


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.


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


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.


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


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.


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.


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

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.


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 your language is harder to get real work done in than the alternatives, your language won't get used.<<

It wasn't; it did.


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


How to determine the aliveness/deadness of a language:

1. Work out what you want to build, and functionalities that you would require. 2. Do a search for libraries in language X. If success, go to 3 else it is dead for you - look at another language. 3. Look for adequate documentation and an active, helpful community. If success, go to 4 else it is dead for you - look at another language. 4. Try building a quick and simple application. If you found it enjoyable and offers something other tools you already know don't, go to 5 else it is dead for you - look at another language. 5. Build something more substantial. If you still find it enjoyable, go to 6 else it is dead for you - look at another language. 6. Congratulate yourself that you have discovered an enjoyable and useful tool. And that you took the time and effort to explore the language yourself and made an informed decision, and not just read someone's opinion and went with it. You may also start to suspect most opinions are from people who never actually used the language for anything more that what you just did, or inherited a dreadful codebase.

I did all this and I found myself using Pharo about three years ago. I still am, and I enjoy it tremendously. Also, (Pharo) Smalltalk is the most alive language I have ever used.


What have you built with Pharo? (Genuine question...)


Libraries to access Pin (pin.net.au), Stripe (not yet complete), Twilio (almost complete). My own bindings to SQLite. Libraries to write Latex files. Currently writing web server proxies for accessing Australian government mandated web services. None are yet released, but I am aiming to make a commercial service out of them so they may never be open sourced.


Pin employee here, if you've built something that supports us we'd love to add it to our integrations page.


So I was interested when someone noted that apparently Pharo/Squeak stumble when it comes to unicode:

https://www.reddit.com/r/programming/comments/3ha1gu/why_are...

...it seems like that could potentially lead people to be skeptical about an environment/language that is touted as being highly productive, with automated refactoring ease, unit testing, test driven development, and turtles-all-the-way-down, etc.


I really enjoyed learning and toying around with Smalltalk and Scheme. What killed it for me was that for all the fun abstractions, they were so isolated in their own environment and disconnected from the operating system that it was not apparent how you would use them for anything real. Processing files, connecting to databases and other network resources, and interacting with the user are core practical services that need to be front and center to get new users to connect to your language, but if those elements are ghettoized into awkward libraries that don't work as elegantly as the abstract parts of the language then you aren't going to get traction, except for very specialized purposes.


It always seems like languages that typically are used in an all-encompassing environment are at a disadvantage when it comes to widespread adoption compared to languages that anyone can just start using in their existing OS, with their existing GUI, editor, etc.


Visual C++? Or Visual Basic?


Are you suggesting those as counterexamples? Neither one is an example of an "all-encompassing environment."

"Visual C++" no longer exists, it's just part of Visual Studio now. When it did exist, it was merely an IDE for regular C++, not any kind of separate environment.

Visual Basic was a package including a GUI toolkit, a programming language, and an IDE for developing ordinary Windows applications. These tools were deployed and used as ordinary Windows applications. There was no separate computing environment with its own windowing system, data storage mechanisms, UI conventions, etc. And the current Visual Basic .NET isn't even that anymore; it's just another .NET language now, where you can swap out the IDE or GUI framework for whatever is available (including none at all if you like, you don't need either one to have a useful VB.NET program).


Visual C++ came after regular C++


> Not everything has to have a visual metaphor. This is again a case of pushing some idealistic principle too far, in my opinion.

True.

But, for example, GNU Smalltalk doesn't need GUI?

https://www.gnu.org/software/smalltalk/manual/html_node/Tuto...

One maintained Smalltalk implementation with GUI that can be tried:

http://squeak.org/

"Squeak is an open-source Smalltalk programming system with fast execution environments for all major platforms. It features the Morphic framework, which promotes low effort graphical, interactive application development and maintenance."

For other opinions about the death of Smalltalk, there was a link to c2 resources called WhyIsSmalltalkDead on the HN just 4 days ago:

https://news.ycombinator.com/item?id=10071681

What I certainly agree is that the successful language has to be able to interact with as much as possible on the host system, as efficient and as flexible. Note that we still use Fortran code, for example, for numeric libraries

https://en.wikipedia.org/wiki/LAPACK

and that C easily links and calls Fortran routines.


You can run squeak in the browser: http://bertfreudenberg.github.io/SqueakJS/

Another one is http://pharo.org/ (haven't tried it)

But I've worked with Squeak quite a bit in university, and the consensus generally was: The language is really nice, and a joy to use for many things. The environment is awful and makes working with it a pain, and since everything is integrated so closely there are no obvious ways around that.


Doesn't seem as dead as the article suggests. In addition to squeak:

http://pharo.org/ http://www.strongtalk.org/

One of the more impressive things I've seen in the past (like 5 years ago?) was DabbleDB (https://en.wikipedia.org/wiki/Dabble_DB), also written in smalltalk (the company / app was acquired, see https://news.ycombinator.com/user?id=avibryant)


Also see Amber, which is not technically a Smalltalk but fakes it very convincingly. It runs in a web browser, compiling to Javascript.

http://amber-lang.net/

Load up that page and press the button, and a Smalltalk IDE will pop up for you to play with. (It sounds like an amazing way to write web apps, actually, as it supports writing changes back to the server; but the backend infrastructure is heavier-weight than I'm happy with.)


Also see

Why is Smalltalk Dead?

https://news.ycombinator.com/item?id=10071681

87 points 5 days ago 61 comments (http://c2.com/cgi/wiki?WhyIsSmalltalkDead)


Smalltalk is no more visual or tied to GUIs than C++ is. There's at least one variant, GNU Smalltalk, which doesn't have an IDE. Squeak is a rather nice IDE, though, and makes a good point in the way it blurs the boundary between programming language and operating system. We've had Lisp Machines; I think a Smalltalk machine would be cool.

You can visualize the space of programming languages as having local maxima where, if you modify the language in any way, you make it worse. I think Smalltalk occupies one such local maximum, Prolog another. Others are less clear-cut.

Of course, being good doesn't equate with being popular. Java is a Smalltalk-C hybrid and is very popular. It aimed very well at the average programmer, and hit its target.


we had Smalltalk machines. The same hardware which ran Xerox' Lisp Machine OS also ran Smalltalk. The processor microcode was different and it booted into Smalltalk on the metal.


Smalltalk's death had almost nothing to do with the language itself. It died for four reasons:

#1 was price, and especially requiring companies to pay royalties on the software they write with your tools,

#2 was the epic mismanagement at ParcPlace/Digitalk (including the merger of the two),

#3 is that Smalltalk was (when the web took off) pretty damn bad for writing server-side Web applications, because of the threading model and blocking IO, and

#4 concerns about security: the lack of high quality libraries for things like encryption, for one thing, and more fundamentally, the way you can do _anything_ once you're in the VM.)

The last one is the only one that's related to the tech itself. If IBM had open-sourced VisualAge when they decided to dump it, it would probably be fairly popular now.


The premise that Smalltalk was driven by idealism over pragmatics is suspect. We got GUI's and personal computers and object oriented languages and IDE's because Smalltalk sliced the envelope with it's cutting edge approach. Martin's talk was more than 35 years after the first release of Smalltalk...it's older than C. A discussion about all the problems Uncle Bob avoids by not using C would be both longer and duller...his talk describes why he didn't choose Smalltalk when he replaced the pain that C++ inherited from C...that 20 years after Smalltalk was invented he found a better option funded by Sun, isn't all that surprising.


The final comments about Scheme seem like a digression from the thesis. Scheme is almost the antithesis of Smalltalk, in that only an essential core language is provided.

I suppose she's arguing that "good is somewhere between Smalltalk and Scheme" but the closing came across as offtopic, as if she were surprised to find that a language famed for its minimalism was actually minimalist.


>Scheme doesn’t include the most basic string routines.

Whoa, really? Racket, arguably the most popular Scheme implementation, seems to have a nice standard library with tons of implemented SRFIs. Also, it seems to be gaining popularity (albeit slowly) not only for itself but for Lisps in general.


> Racket, arguably the most popular Scheme implementation

Umm, NO. Racket isnt a "Scheme implementation". Racket was a Scheme as long as they called themselves MzScheme. Then they decided that they changed too much that a complete name change was justified in order to not confuse users.

Racket isnt a "Scheme implementation" for the same reason Scheme isnt a "Lisp implementation".


From http://racket-lang.org/new-name.html -- "Racket is a Scheme". The name change was about very different things than "basic scheme routines", and it would be hard to find any basic scheme implementation without any.


Scheme is a "Lisp implementation", it's just not a "Common Lisp implementation"


Racket is its own language now, it isn't Scheme per-se. They've split apart because of disagreements over which direction the language should take.


True... it does include R5RS though, and I think it does include lot of libraries for that too.


...is this the string library you are referring to?

http://docs.racket-lang.org/reference/strings.html

...or something more extensive?


I am not sure what you are getting at? More extensive? Those are basic string functions.


One man's paltry can be another man's extravagant. If you are coming from R5RS, then that Racket library would be a breath of fresh air. If you are coming from Perl, then maybe not so much.


That's the first time I hear of Racket being accused of being too small... Looking at http://perldoc.perl.org/index-functions-by-cat.html#Function... I count about 30 functions (including regexp ones); looking at the racket page I count over 50.

Also, I once got the snow yellow at over 3 meters.


I don't like the culture of killing things and saying that things are dead when they still have individuals extracting value from it. I also don't find particularly strong or appealing, the Tyranny of the Majority friendly Argumentum Ad Populum nor the Keynesian Beauty Contests as drivers for design language (actually for nothing in life and not only language design).

On the other hand, I do find interesting that the User Experience gets used on language and frameworks and tooling design.

While Smalltalk never really rocked it at UI and UX, it was good enough to inspire Steve Jobs to do the GUI of a system right (in terms of UX) on the mackintosh.

Regardless of comunity size, I still want to see what's the next thing that will create such degree of positive influence in these days and for the next decadeds.

Good luck


While the article raises a few good points, I got distracted by the statements about Scheme at the end of the article. Yes r5rs might be overly minimal, but all real-world scheme implementations contain the usual basic tool functions like string parsing. The performance quoted of a minute for parsing a megabyte sized file can only mean two things: either a defunct scheme was used or the program used contained major flaws - this can happen if you are new to a language, but this is not a useful measure of the language. Even garden-variety byte code interpreters should do this in seconds.



Although Smalltalk was early computer language from the 1970s, it could not run efficiently on most computers until the 32bit CPUs came along in the 1990s. By then the simple C language and it's OOP hybrids dominated the coding world.

Smalltalk came on the scene before computer operating systems were well developed as we know them now. Hence Smalltalk did a little bit of everything- code, GUI, OS, IDE. This an advantage in providing an unified API to all these services. However all these services are not as well developed inside Smalltalk as in the layered systems we have now.


May 1988, Smalltalk/V286 was viable on commodity hardware.

http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkVTutorial/S...


The Apple Macintosh was released in 1984, Smalltalk ran on it fairly soon after this. The problem was that it wasn't available to the general public, only to universities.


Apparently $150 to businesses.

"Apple Team Developing Maclike Smalltalk"

https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=P...


Ok. My memory of it was from a bit earlier, I first saw it sometime in 1986. You would have had to add the cost of APDA membership to the $150 stated in your link. I found an OOPSLA conference report that described seeing a demo of the Apple Smalltalk+MacApp product.

I also found a flyer for Smalltalk-80 on the IBM AT for $1000 from around the same date.


I very much doubt that Smalltalk-80 was fun to use on a lowly PC-AT ;-)

This was -- USD 199.95 Smalltalk/V286 March 7, 1988.

https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=P...


Smalltalk/V (not 286) was perfectly usable on a PC of the day, I ran it on an Olivetti M24 with a paper white display.

The Smalltalk-80 flyer states that an 8MHz 286 was faster than a Xerox Dolphin and 20% of the speed of a Xerox Dorado. The painful part would have been the display, they were just using EGA (640x350) so you couldn't see much at one time. I saw a demo of this and don't remember thinking that it was too slow.


Back-in-the-day I did not consider Smalltalk/V usable, that changed with V286 :-)


Wow that Robert Martin talk has not aged well. I couldn't imagine that being a talk at Rails Conf now. Good info, but it feels a bit off 6 years later.


What changed in the subsequent 6 years?


> For instance, Smalltalk had the ability to suspend running programs into a saved image, and resume execution later at the saved point.

I'm curious - is this just a continuation? Or is it baked into the language, like exception handling or something? Any smalltalkers want to expound or link to relevant docs/tutorials?


Yes, it is a continuation, although it's more comprehensive than call/cc. When you save a Smalltalk image it serializes not only the call stack but the entire heap. It's rather like a core dump that can resume executing.

It's typically implemented in the VM as a primitive function kind of like posix fork(). When it returns, the entire state of the program has been saved to disk. The return value is a boolean, which tells you if you're returning from the original call, or resuming from the saved image.

Classical Smalltalk dialects didn't have continuations as a flow control construct, but they did have reified stack frames, so it was possible to implement Scheme-style continuations in a few lines of code.


It's baked into the VM.

When they say that in Smalltalk, everything's an object, they're seriously not kidding. Everything is an object, including compiled code, stack frames, execution contexts, threads, etc. A traditional Smalltalk system uses an object table, where all object pointers are really references to a slot in the table; this allows the garbage collector to move objects around in memory easily.

This means that it becomes trivial to dump everything out to disk, reload it later, update the object table, and suddenly the entire state of your system is restored (ignoring host OS resources, of course, but traditionally Smalltalk didn't use an operating system).

I did have a handy sample for GNU Smalltalk that would snapshot an image containing a running thread which, when the thread was reloaded, would seamlessly resume but, er, I seem to have lost it.


You could call it a continuation, I guess, but continuations don't generally persist between separate invocations of your programming. The image is a file that can be passed around and when you open/execute (or whatever you want to call it), the program resumes where you left off.

This is how most Lisp applications are distributed as well. Starting from a clean image (that is, one containing only the language standard library) you build up the initial state of your app by compiling the source files, and then dump the whole shebang as an image.


I programed in Smalltalk-80 from 1990-1995. I used it at Morgan Stanley to build a derivative trading system that was distributed between London and NYC. It was running on networed Sun Sparcstations. Traders would collaborate on the same trading "book" across different machines. One of the big battles of getting the system installed was persuading traders to make room and to use a mouse to control the system.

St-80 was a great system and by way my favorite programming experience. I remember visiting Jim Gosling to hear about Oak (which subsequently became Java) and thinking that it was neat but a pale imitation of Smalltalk.

What "killed" Smalltak were a thousand cuts. A huge problem was the fact that hardware in those days was slow. Our production machines had a 25 Megahertz processor which had problems with the interpreted language that was also painting a GUI.

For a long time St-80 would just take 100% of the puny cpu even when there was nothing going on. Eventually there was 4-line event driven patch that cleared that up but that did not help when the program actually did some work.

For finance double-dispatch arithmetic made things worse since even a simple addition would result in a bunch of message sending that was cute and pure but slow.

The monolithic image was an issue too since shipping and delivering production code was hard. There were source control system but ultimately the image was a hug blob that had to be shipped around. Another issue was the windowing system. Smalltalk was its own universe and basically grew out of being the whole environment for a machine (e.g. Xerox Star).

There were no namespaces so it was hard to segments certain kinds of code and you'd end up fiddling with the innards of St which may have unintended consequences.

It did not integrate with the window managers of the day (e.g. Motif) and could not use native widgets so we had to try to style our widgets to look like the window manager.

I think the folks at ParcPlace were great inventors and engineers (Peter Deutsch is a god) but they were not fast enough to respond to the pressures of the market.

I wonder what would happen if Gigahertz machines were avaible for Smalltalk and if ParcPlace had managed to make their system have a decent package manager and to call native widgets.

It was also hard to find engineers since C/C++ was there flavor de jour. At Morgan Stanley there was also APL/A+/J but ultimately Java took the world over and now then Javascript which started off as an interpreted language with a lot less that St-80 but some times timing is everything. Moore's law helps too.

With all that said St-80 is still the gold standard of my programming life which included other fun systems such as Interlisp-D and NextStep.


>>For finance double-dispatch arithmetic made things worse since even a simple addition would result in a bunch of message sending that was cute and pure but slow.<<

Why would there be double-dispatch of 2 + 4 ?

Why would that require numeric coercion ?


My personal opinion is what killed most very good languages is the "elite" and "math" aspect of them.

By elite I mean people who thought they were so much superior to everyone else (And they were!), that they'd left the beginners and inexperienced programmers out of the discussions and decisions. But guess what, high level people who make decisions aren't always the best programmers, so C++ won because they had better sales people and were more beginners and sales friendly.

By "Math", I mean that most functional books and tutorials used to only focus on physics or maths aspect of the language, or AI.. whereas the languages who seemed to have won the war (Think Perl, PHP at the time, or Python/Ruby) were much more practical in how the language can be used to solve day-to-day pragmatic problems.

I think it's changing.. and it's really nice to see amazing concepts from LISP in the mainstream/hipsters languages..


>so C++ won because they had better sales people and were more beginners and sales friendly.

Actually C++ is far worse for beginners than Smalltalk (which is casually used as a teaching language to kids, as Squeek etc).

The comment about "math" and "elite" show no familiarity with Smalltalk or the environment back then.

What you say might be true for Haskell, or even CL, but it doesn't have anything to do with Smalltalk.


I really like C++, but I think it mainly won because it was friendly to the huge number of programmers that already had years of experience with C at the time. Easy use of existing C projects was also a huge benefit.


Languages thrive or die. The successful ones are those enable(d) less capable people at the time to do fashionable works as good as, or even better than the professionals. It has nothing to do with anything other than marketing strategy: find a under served market segment and empower idiots to do mediocre+ works with little efforts. In order to achieve so, language designers have to break old paradigms, simply because if they don't, the less capable people at the time just don't understand, nor capable of (otherwise, they would be professionals).


> The successful ones are those enable(d) less capable people at the time to do fashionable works as good as, or even better than the professionals. It has nothing to do with anything other than marketing strategy: find a under served market segment and empower idiots to do mediocre+ works with little efforts. In order to achieve so, language designers have to break old paradigms, simply because if they don't, the less capable people at the time just don't understand, nor capable of (otherwise, they would be professionals).

Most of the (most) popular languages aren't revolutionary and they're also weak in terms of level of abstraction.

Reading your comment, one would assume that Lisp, batteries included-Schemes, Python, Ruby, Perl, Haskell, etc. are topping the charts. In reality, though, people are mostly using Java, C, C++, C# and yes... Python is very popular. It's outrun completely by languages that require far more work to do less, however.

I don't know if I'm misreading your comment, but the above seems to stand in contrast to your point. The most popular languages are the ones with a lower level of abstraction, less expressive power and that require a programmer to write/manage more to do less, meaning they make more effort for these 'mediocre+' results.

A point can be made that you think less while using these languages, but what time you don't spend on thinking is spent on writing (and then debugging) and I guess this is the 'less capable' part of your post, but this doesn't cover the fact that the languages that've enabled people to leapfrog business professionals (think Ruby + Rails being used to leapfrog professionals in web development) have almost nothing in common with the top list of used programming languages.

The most used programming languages remain and have pretty much always been languages that use C syntax and don't actually push the envelope too much. Some rankings will have PHP and JS up there with the rest of them, but these fall neatly into the fold and are about as 'lame' as the rest of the top (with JS trying to walk lately).


It's less dramatic -- languages thrive or fade away ;-)


don’t perform very well (see CPython, Ruby)

Sigh. I really wish that smart people would stop spreading myths. Ruby, at least, performs quite well. The "Ruby is slow" days are years behind us.


I'm like the biggest Ruby fan out there, but c'mon – that's just not true!

Ruby is great at many things, and it has adequate performance for many situations -'Fast Enough', as DHH said. And with liberal use of C extensions, I've used it in some high-performance scenarios where the expressiveness was more beneficial than the complexity of using extensions.

But it's really not fast – up to 100x slower than Java (http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...) or 30x slower than Javascript on V8 (http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...). I know these are micro benchmarks, but they're useful for comparison.

Some of this is down to the nature of the Ruby interpreter and will improve with time (and with implementations like JRuby). Some of it is down to the highly dynamic nature of the language. The point remains though – if you need high performance for a particular task, Ruby may not be the best option.


Ruby isn't that much slower than other slow languages. But compared to the fast ones it is really really slow.


There's a chart for that --

http://benchmarksgame.alioth.debian.org/u64/which-programs-a...

-- but the question is always really really slow to do what exactly?



>Ruby, at least, performs quite well.

Are you talking absolute performance (as in machines are faster now, so speed has become less important) or relative performance (compared to performing the same task with a different interpreter/complier)?

https://benchmarksgame.alioth.debian.org/u32/benchmark.php?t...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: