7 ms·

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 si

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-for-smalltalk-seaside https://stackoverflow.com/questions/8244502/version-control-...)

sanderjd 11y ago
> 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.
- AceJohnny2 11y ago
  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.
- pjmlp 11y ago
  You could generate an executable with a pruned image. At least with the commercial Smalltalks.
  - xrange 11y ago
    Can anyone tell us how cumbersome it is to do the same thing with the free Smalltalks?
    - david-given 11y ago
      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-gnu-smalltalk http://smalltalk.gnu.org/blog/bonzinip/seaside-development-g...
      - sanderjd 11y ago
        Neat, thanks for the pointer. Can you speak to what another commenter said about GNU Smalltalk being a not-particularly-great implementation?
        david-given 11y ago
        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.
    - deleted 11y ago
      [deleted]
  - pjmlp 11y ago
    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
- BuildTheRobots 11y ago
  (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? :)
  - david-given 11y ago
    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.
    - igouy 11y ago
      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".
  - sanderjd 11y ago
    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.
- david-given 11y ago
  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...)
  - ljw1001 11y ago
    Dear god, don't use Squeak. Pharo.
- igouy 11y ago
  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
  - sanderjd 11y ago
    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".
    - igouy 11y ago
      >>…how to fit everything together within the current software ecosystem…<< You mean like using Win32™ DLLs? http://www.object-arts.com/downloads/docs/parameterconversionandwrappermethods.htm 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 http://pharo.org/success
      - sanderjd 11y ago
        Neat, yes, that sort of thing!
        igouy 11y ago
        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 http://pharo.org/Companies
- igouy 11y ago
  >>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 http://portal.acm.org/citation.cfm?id=604258
- deleted 11y ago
  [deleted]
- mark_l_watson 11y ago
  How about writing web apps in Pharo (or Squeak)? There are several nice frameworks, Seaside just being on of them.
- coldtea 11y ago
  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.
- justaaron 11y ago
  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...
  - igouy 11y ago
    >>building "apps" for desktop or mobile? ok, you got me there... smalltalk is probably not apropo...<< … because?
AnimalMuppet 11y ago
> 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.
- vezzy-fnord 11y ago
  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.
  - AnimalMuppet 11y ago
    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.
bsdetector 11y ago
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.
- vezzy-fnord 11y ago
  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.
  - bsdetector 11y ago
    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.
    - igouy 11y ago
      Failed? pdf "Ubiquitous Applications: Embedded Systems to Mainframe" http://www.davethomas.net/papers/ubiquitous1995.pdf http://www.davethomas.net/papers/ubiquitous1995.pdf Smalltalk was replaced by free-as-in-beer future-of-the-internet Java.
      - bsdetector 11y ago
        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.
pron 11y ago
> 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.

sanderjd 11y ago

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

AceJohnny2 11y ago
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.
pjmlp 11y ago
You could generate an executable with a pruned image. At least with the commercial Smalltalks.
- xrange 11y ago
  Can anyone tell us how cumbersome it is to do the same thing with the free Smalltalks?
  - david-given 11y ago
    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-gnu-smalltalk http://smalltalk.gnu.org/blog/bonzinip/seaside-development-g...
    - sanderjd 11y ago
      Neat, thanks for the pointer. Can you speak to what another commenter said about GNU Smalltalk being a not-particularly-great implementation?
      - david-given 11y ago
        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.
  - deleted 11y ago
    [deleted]
- pjmlp 11y ago
  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
BuildTheRobots 11y ago
(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? :)
- david-given 11y ago
  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.
  - igouy 11y ago
    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".
- sanderjd 11y ago
  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.
david-given 11y ago
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...)
- ljw1001 11y ago
  Dear god, don't use Squeak. Pharo.
igouy 11y ago
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
- sanderjd 11y ago
  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".
  - igouy 11y ago
    >>…how to fit everything together within the current software ecosystem…<< You mean like using Win32™ DLLs? http://www.object-arts.com/downloads/docs/parameterconversionandwrappermethods.htm 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 http://pharo.org/success
    - sanderjd 11y ago
      Neat, yes, that sort of thing!
      - igouy 11y ago
        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 http://pharo.org/Companies
igouy 11y ago
>>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 http://portal.acm.org/citation.cfm?id=604258
deleted 11y ago
[deleted]
mark_l_watson 11y ago
How about writing web apps in Pharo (or Squeak)? There are several nice frameworks, Seaside just being on of them.
coldtea 11y ago
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.
justaaron 11y ago
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...
- igouy 11y ago
  >>building "apps" for desktop or mobile? ok, you got me there... smalltalk is probably not apropo...<< … because?

AnimalMuppet 11y ago

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

vezzy-fnord 11y ago
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.
- AnimalMuppet 11y ago
  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.

bsdetector 11y ago

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.

vezzy-fnord 11y ago
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.
- bsdetector 11y ago
  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.
  - igouy 11y ago
    Failed? pdf "Ubiquitous Applications: Embedded Systems to Mainframe" http://www.davethomas.net/papers/ubiquitous1995.pdf http://www.davethomas.net/papers/ubiquitous1995.pdf Smalltalk was replaced by free-as-in-beer future-of-the-internet Java.
    - bsdetector 11y ago
      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.

pron 11y ago

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