What Killed Smalltalk?
pointersgonewild.com
pointersgonewild.com
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.)
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.
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 ;)
It implemented Smalltalk primitives in JavaScript so it can run a real, bit identical, Squeak image.
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...
pdf 10 pages
http://www.eli.sdsu.edu/courses/spring01/cs635/readingSmallt...
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.
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.
I'm going to go out on a limb here, and chalk that one up in the "famous last words" column. :)
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.
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.
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...
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.
I would say that smalltalk is way more "dead" in the sense that news doesn't make waves the same way scheme news does.
Don't leave us hanging, I'm sure lots of people would like to know of Scheme success stories besides Jak and Daxter.
mdfind -name .sbit'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...
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.
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.
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.
C - AT&T, UNIX vendors
C++ - Almost all C compiler vendors adopted it. CORBA and Windows Development helped it.
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.
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.
Rust and Go seem to fall pretty firmly in to that category as well.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
You mean it's not VRML? The 90s lied to me...
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.
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.
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.
So incompetent programmers ?
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.
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-...)
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.
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...
For example, this is how VisualWorks Smalltalk does it (Application Delivery chapter):
www.cincomsmalltalk.com/main/Documentation/VisualWorks/AppDevGuide.pdf
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.
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".
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...)
Most Smalltalk implementations have 4 pieces:
- VM like the JVM
- sources file
- changes file
- image file
> 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".
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?
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.
building "apps" for desktop or mobile? ok, you got me there... smalltalk is probably not apropo...
… because?
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.
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.
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.
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.
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.
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.
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.
http://www.ptidej.net/courses/ift6251/fall06/presentations/0...
Smalltalk-80 calcified Smalltalk.
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.
It wasn't; it did.
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.
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.
That's why we study the reasons why it failed so that we don't make the same mistakes again.
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.
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.
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.
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...
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.
They're only trending in hype -- not adoption.
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.
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.
"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).
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:
"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.
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.
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)
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.)
Why is Smalltalk Dead?
https://news.ycombinator.com/item?id=10071681
87 points 5 days ago 61 comments (http://c2.com/cgi/wiki?WhyIsSmalltalkDead)
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.
#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.
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.
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.
http://docs.racket-lang.org/reference/strings.html
...or something more extensive?
Also, I once got the snow yellow at over 3 meters.
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".
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
http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=...
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.
http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkVTutorial/S...
"Apple Team Developing Maclike Smalltalk"
https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=P...
I also found a flyer for Smalltalk-80 on the IBM AT for $1000 from around the same date.
This was -- USD 199.95 Smalltalk/V286 March 7, 1988.
https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=P...
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.
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?
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.
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.
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.
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.
Why would there be double-dispatch of 2 + 4 ?
Why would that require numeric coercion ?
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..
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.
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).
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.
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...
I still see them on the tail in terms of performance:
http://benchmarksgame.alioth.debian.org/u32/performance.php?...
http://benchmarksgame.alioth.debian.org/u32/performance.php?...
Here comparing with Racket ( not even Java, C#, C++ or C)
http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...
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.
http://benchmarksgame.alioth.debian.org/u64/which-programs-a...
-- but the question is always really really slow to do what exactly?