6 ms·

I'm no programmer, but I remember back when Ruby 1.8.7 got really popular because of Rails even though Ruby 1.8.7 was not that secure or stable compared to othe

by da02 8y ago

I'm no programmer, but I remember back when Ruby 1.8.7 got really popular because of Rails even though Ruby 1.8.7 was not that secure or stable compared to other environments. (Yes, I know Ruby is better now.) But, I was wondering why someone didn't take Smalltalk (or Squeak or Pharo) and find a way to make it more popular? We have Node, Electron, Java, etc. So why not Smalltalk? Wouldn't it be easier to develop, run faster, and be more cross-platform than those popular environments? Is there something in Squeak or Pharo holding it back? Maybe the next Tim-Bernes Lee could use it to develop new protocols + a browser and create a safer and secure WWW-alternative?

hboon 8y ago
The short answer is it's different and unfamiliar to most newcomers: 1. The image-based paradigm [1] holds it back. Using Smalltalk, there's quite a change in development style, the existing development tools (text editors, version etc) mostly don't work [2], and deployment is at least slightly different. 2. The unfamiliar UI (mostly Morphic) looked very different. 3. The different (but incredibly simple) syntax looks strange to newcomers. There are paid tools that fix some of these, but they never quite caught on with lots of momentum, and they were used mostly in bigger enterprise shops. The biggest might have been IBM VisualAge (for Smalltalk), which later morphed into IBM VisualAge for Java and then Eclipse. [1] The image-based paradigm is really really great. If you haven't experienced it before, give it a go. It's worth it even if you are never going to use Smalltalk. [2] There's been effort to get git to work. I haven't been tracking it, but this was only in the recent few years.
- int_19h 8y ago
  How exactly does the image-based approach mesh with version control like git? I'm trying to picture a possible approach, but failing.
  - scroot 8y ago
    Check out https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg
  - hboon 8y ago
    Smalltalk has a concept of changesets. They can approximate diffs/patches. And while the code is exposed in code browsers (some kind of IDE/text editor window) in the image, and not exposed as text files, they certainly can be. So I'd imagine it's just a matter of exposing those into files (or still classes and methods as separate "entities") and commit those into git with a bit of markup.
    - int_19h 8y ago
      But the whole point of the image approach is that it's not just code, but also data, no? It would seem that it'd require some multiple-file text-based serialization format for images that would include both code and data, and would split it into files in a way reflecting the typical change patterns...
      - hboon 8y ago
        Code + data + live instances of the code/objects. Like I said, I haven't been tracking how they do it, but I'm guessing that they only track code. If you want to be able to deploy an image directly, you either have to write scripts (and check those in too, either standalone "scripts" or class-side initialisation) or save the entire image and deploy that. Saving the development image and deploying it directly is also not done that often because the development image contains things that can stripped off, e.g. development tools or object instances you use during development. Squeak and Pharo is usually distributed in various flavours, loosely — full and minimal images (I might not get the names right). So you take the former and install packages for development and the latter + packages for deployment, or you can build your own from the minimal image. But through this you can see how different it is and while it's great in many ways, some of the differences make it harder for newcomers to start and harder for everyone to use it in production. I forgot to mention Dolphin Smalltalk http://www.object-arts.com http://www.object-arts.com. It used to be a paid product, running on Windows. It has been open source for a few years now. I think product sales wasn't sustainable for the owners. But for several years, it is was the best Windows thick client development tool. It's a great example of Smalltalk well-done. You have the same image-based approach, but the windows are all native and familiar looking, so basically a multi-window development IDE. There's a deployment tool that helps you to strip down your image and build it into an exe (which was basically the Dolphin Smalltalk image + the shrunk image). It might still run, maybe it looks a bit outdated, it was actively developed until 2004 or so. If it still works, it's a wonderful way to experience Smalltalk.
  - anothergoogler 8y ago
    I believe Monticello has been the mainstream Smalltalk VCS for some time, but I don't know much about it: http://wiki.squeak.org/squeak/1287 http://wiki.squeak.org/squeak/1287
  - coldtea 8y ago
    An image could be serialized to anything, including edits... Aside from the code, all other user data is message sending, so it could also be serialized (if needed).
  - rjsw 8y ago
    GNU Smalltalk isn't image based.
  - protomyth 8y ago
    At a place I worked they checked the changed / added code[1] into a conventional version control with all our other code. There are quite a few adapters available. The final image deployed to production was a starting generic image which the build team applied all the code from the version control. Worked just fine. If image-based approach is the deciding factor, it really shouldn't be. There are tools. 1) Smalltalks have a text output format for code chunks
- flukus 8y ago
  > The image-based paradigm [1] holds it back. Using Smalltalk, there's quite a change in development style, the existing development tools (text editors, version etc) mostly don't work [2], and deployment is at least slightly different. It holds it back because it's a bad idea, otherwise Access/VBA apps would rule the world by now. It's a great environment for single developer RAD tools but it's horrible when you're trying to scale the team up because tools like git don't work well and you often don't want data to be shared between instances.
  - hboon 8y ago
    git didn't work with it (maybe it does now). But there has been native version control tools in Smalltalk. There was ENVY, and Squeak and Pharo has Monticello, Dolphin had something (can't remember its name). git is great in many ways, especially how it lets multiple developers to work more effectively on the same code base. But native version control tools on Smalltalk, while they might not work as effectively for large groups of developers, has native support — it can support things like versioning at method level. Rather than arguing Smalltalk is the best or that it is bad, I rather focus on what I think — it has many great features, it's just that it's so different that it can't ever be popular, at least not for the foreseeable future.
  - goatlover 8y ago
    Well git was made for text/file based programming languages. If SmallTalk had taken over instead, we would have the equivalent for image based languages.
- leoc 8y ago
  Apparently (not an expert) [1] Smalltalk was the leader in basically the Java niche until Java happened, whereupon the proprietary and rather expensive Smalltalks were wiped out, since not only was Java free as in beer and reassuring to C++ programmers, it also came in riding a truly preposterous hypewave. (For those who weren't there and haven't heard: it was roughly cover-of-Time-magazine scale. It was visible from space.) Then HotSpot—retrofitted from the Self VM, ironically—gave Java a performance advantage which (iirc) the existing ST VMs couldn't match. And while Smalltalk was almost the paradigm dynamic language, the proprietary STs had no impact in the scripting-language niche thanks to their licensing costs and inward-looking, image-based nature. (GNU Smalltalk was another story: I don't know what happened or failed to happen there.) [1] There was in fact an article written by someone who was an expert which did the rounds of /r/programming back in the day. But good luck finding it now of course.
  - 3rdAccount 8y ago
    I think it is called "Why Smalltalk failed" and is easy to find with a search. Java was web, Perl was web, and ST wasn't ready. Java and Perl were free as in beer, ST was expensive. I think ST hardware was expensive too. ST is very different from C & C++. ST had multiple vendors too.
    - leoc 8y ago
      "why smalltalk failed" may afaicr have been first thing I tried: https://www.google.com/search?q="Why+Smalltalk+failed" https://www.google.com/search?q="Why+Smalltalk+failed" . https://medium.com/smalltalk-talk/why-smalltalk-failed-to-dominate-the-world-93e7e4195039 https://medium.com/smalltalk-talk/why-smalltalk-failed-to-do... isn't the article I was looking for. It's much more recent, and much less in-depth. However http://wiki.c2.com/?WhyIsSmalltalkDead http://wiki.c2.com/?WhyIsSmalltalkDead covers a lot of the same ground, unsurprisingly. I'm pretty sure that late-'80s/early-'90s ST was largely run on commodity (or fairly-commodity) hardware: PCs, Macs, Unix workstations. It was commercial Lisp that tended to be tied to dedicated hardware. IIUC Smalltalk did have a then-expensive appetite for RAM though. The commercial STs of the time weren't good as CGI languages like Perl and PHP for the same reasons they weren't suitable as Perl-style scripting languages in general. Meanwhile, behind the hype it soon turned out that Java applets were not ready for prime time either, while servlets were something that could probably have easily been replicated in ST (and for all I know, likely were).
flukus 8y ago
Rails was about the first time a functional language (probably other types too) had a programmatic proponent, it leveraged ruby to create an easy way to build web apps and people/companies wanted web apps. Just about every other language was full of smug proponents who just wanted to show how little code you needed to generate Fibonacci numbers, as if that was at all relevant to most developers. They spent so much time telling everyone why $lang was great and very little time showing them how it could be used for great things. Just looking at the pharo homepage this jumps out: >Live, immersive environment: Immediate feedback at any moment of your development: Developing, testing, debugging. Even in production environments, you will never be stuck in compiling and deploying steps again! That doesn't appeal to me at all. I don't want to be debugging in live environment, I don't want users or testers having that power and I don't get stuck in compiling/deploying steps.
- coldtea 8y ago
  >Rails was about the first time a functional language (probably other types too) had a programmatic proponent, it leveraged ruby to create an easy way to build web apps and people/companies wanted web apps. Just about every other language was full of smug proponents who just wanted to show how little code you needed to generate Fibonacci numbers, as if that was at all relevant to most developers. Yeah, that wasn't it. Maybe you weren't there? This sounds like a third hand experience of the era. Functional languages have been used in major programming projects (and had popular apps, from Eclipse and AutoCAD) for decades before Ruby, not to mention AI work. Besides, PG's company used CL to build one of the first web stores way before Rails was even a thing. >That doesn't appeal to me at all. I don't want to be debugging in live environment, I don't want users or testers having that power and I don't get stuck in compiling/deploying steps. That's because you haven't used it.
e12e 8y ago
For a take on what happens when smalltalk and the web browser and js meet, see: https://lively-kernel.org/ https://lively-kernel.org/ For a more "traditional" smalltalk for js, see: https://www.amber-lang.net/ https://www.amber-lang.net/

by da02 8y ago

hboon 8y ago

The short answer is it's different and unfamiliar to most newcomers: 1. The image-based paradigm [1] holds it back. Using Smalltalk, there's quite a change in development style, the existing development tools (text editors, version etc) mostly don't work [2], and deployment is at least slightly different. 2. The unfamiliar UI (mostly Morphic) looked very different. 3. The different (but incredibly simple) syntax looks strange to newcomers. There are paid tools that fix some of these, but they never quite caught on with lots of momentum, and they were used mostly in bigger enterprise shops. The biggest might have been IBM VisualAge (for Smalltalk), which later morphed into IBM VisualAge for Java and then Eclipse. [1] The image-based paradigm is really really great. If you haven't experienced it before, give it a go. It's worth it even if you are never going to use Smalltalk. [2] There's been effort to get git to work. I haven't been tracking it, but this was only in the recent few years.

int_19h 8y ago
How exactly does the image-based approach mesh with version control like git? I'm trying to picture a possible approach, but failing.
- scroot 8y ago
  Check out https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg
- hboon 8y ago
  Smalltalk has a concept of changesets. They can approximate diffs/patches. And while the code is exposed in code browsers (some kind of IDE/text editor window) in the image, and not exposed as text files, they certainly can be. So I'd imagine it's just a matter of exposing those into files (or still classes and methods as separate "entities") and commit those into git with a bit of markup.
  - int_19h 8y ago
    But the whole point of the image approach is that it's not just code, but also data, no? It would seem that it'd require some multiple-file text-based serialization format for images that would include both code and data, and would split it into files in a way reflecting the typical change patterns...
    - hboon 8y ago
      Code + data + live instances of the code/objects. Like I said, I haven't been tracking how they do it, but I'm guessing that they only track code. If you want to be able to deploy an image directly, you either have to write scripts (and check those in too, either standalone "scripts" or class-side initialisation) or save the entire image and deploy that. Saving the development image and deploying it directly is also not done that often because the development image contains things that can stripped off, e.g. development tools or object instances you use during development. Squeak and Pharo is usually distributed in various flavours, loosely — full and minimal images (I might not get the names right). So you take the former and install packages for development and the latter + packages for deployment, or you can build your own from the minimal image. But through this you can see how different it is and while it's great in many ways, some of the differences make it harder for newcomers to start and harder for everyone to use it in production. I forgot to mention Dolphin Smalltalk http://www.object-arts.com http://www.object-arts.com. It used to be a paid product, running on Windows. It has been open source for a few years now. I think product sales wasn't sustainable for the owners. But for several years, it is was the best Windows thick client development tool. It's a great example of Smalltalk well-done. You have the same image-based approach, but the windows are all native and familiar looking, so basically a multi-window development IDE. There's a deployment tool that helps you to strip down your image and build it into an exe (which was basically the Dolphin Smalltalk image + the shrunk image). It might still run, maybe it looks a bit outdated, it was actively developed until 2004 or so. If it still works, it's a wonderful way to experience Smalltalk.
- anothergoogler 8y ago
  I believe Monticello has been the mainstream Smalltalk VCS for some time, but I don't know much about it: http://wiki.squeak.org/squeak/1287 http://wiki.squeak.org/squeak/1287
- coldtea 8y ago
  An image could be serialized to anything, including edits... Aside from the code, all other user data is message sending, so it could also be serialized (if needed).
- rjsw 8y ago
  GNU Smalltalk isn't image based.
- protomyth 8y ago
  At a place I worked they checked the changed / added code[1] into a conventional version control with all our other code. There are quite a few adapters available. The final image deployed to production was a starting generic image which the build team applied all the code from the version control. Worked just fine. If image-based approach is the deciding factor, it really shouldn't be. There are tools. 1) Smalltalks have a text output format for code chunks
flukus 8y ago
> The image-based paradigm [1] holds it back. Using Smalltalk, there's quite a change in development style, the existing development tools (text editors, version etc) mostly don't work [2], and deployment is at least slightly different. It holds it back because it's a bad idea, otherwise Access/VBA apps would rule the world by now. It's a great environment for single developer RAD tools but it's horrible when you're trying to scale the team up because tools like git don't work well and you often don't want data to be shared between instances.
- hboon 8y ago
  git didn't work with it (maybe it does now). But there has been native version control tools in Smalltalk. There was ENVY, and Squeak and Pharo has Monticello, Dolphin had something (can't remember its name). git is great in many ways, especially how it lets multiple developers to work more effectively on the same code base. But native version control tools on Smalltalk, while they might not work as effectively for large groups of developers, has native support — it can support things like versioning at method level. Rather than arguing Smalltalk is the best or that it is bad, I rather focus on what I think — it has many great features, it's just that it's so different that it can't ever be popular, at least not for the foreseeable future.
- goatlover 8y ago
  Well git was made for text/file based programming languages. If SmallTalk had taken over instead, we would have the equivalent for image based languages.
leoc 8y ago
Apparently (not an expert) [1] Smalltalk was the leader in basically the Java niche until Java happened, whereupon the proprietary and rather expensive Smalltalks were wiped out, since not only was Java free as in beer and reassuring to C++ programmers, it also came in riding a truly preposterous hypewave. (For those who weren't there and haven't heard: it was roughly cover-of-Time-magazine scale. It was visible from space.) Then HotSpot—retrofitted from the Self VM, ironically—gave Java a performance advantage which (iirc) the existing ST VMs couldn't match. And while Smalltalk was almost the paradigm dynamic language, the proprietary STs had no impact in the scripting-language niche thanks to their licensing costs and inward-looking, image-based nature. (GNU Smalltalk was another story: I don't know what happened or failed to happen there.) [1] There was in fact an article written by someone who was an expert which did the rounds of /r/programming back in the day. But good luck finding it now of course.
- 3rdAccount 8y ago
  I think it is called "Why Smalltalk failed" and is easy to find with a search. Java was web, Perl was web, and ST wasn't ready. Java and Perl were free as in beer, ST was expensive. I think ST hardware was expensive too. ST is very different from C & C++. ST had multiple vendors too.
  - leoc 8y ago
    "why smalltalk failed" may afaicr have been first thing I tried: https://www.google.com/search?q="Why+Smalltalk+failed" https://www.google.com/search?q="Why+Smalltalk+failed" . https://medium.com/smalltalk-talk/why-smalltalk-failed-to-dominate-the-world-93e7e4195039 https://medium.com/smalltalk-talk/why-smalltalk-failed-to-do... isn't the article I was looking for. It's much more recent, and much less in-depth. However http://wiki.c2.com/?WhyIsSmalltalkDead http://wiki.c2.com/?WhyIsSmalltalkDead covers a lot of the same ground, unsurprisingly. I'm pretty sure that late-'80s/early-'90s ST was largely run on commodity (or fairly-commodity) hardware: PCs, Macs, Unix workstations. It was commercial Lisp that tended to be tied to dedicated hardware. IIUC Smalltalk did have a then-expensive appetite for RAM though. The commercial STs of the time weren't good as CGI languages like Perl and PHP for the same reasons they weren't suitable as Perl-style scripting languages in general. Meanwhile, behind the hype it soon turned out that Java applets were not ready for prime time either, while servlets were something that could probably have easily been replicated in ST (and for all I know, likely were).

flukus 8y ago

Rails was about the first time a functional language (probably other types too) had a programmatic proponent, it leveraged ruby to create an easy way to build web apps and people/companies wanted web apps. Just about every other language was full of smug proponents who just wanted to show how little code you needed to generate Fibonacci numbers, as if that was at all relevant to most developers. They spent so much time telling everyone why $lang was great and very little time showing them how it could be used for great things. Just looking at the pharo homepage this jumps out: >Live, immersive environment: Immediate feedback at any moment of your development: Developing, testing, debugging. Even in production environments, you will never be stuck in compiling and deploying steps again! That doesn't appeal to me at all. I don't want to be debugging in live environment, I don't want users or testers having that power and I don't get stuck in compiling/deploying steps.

coldtea 8y ago
>Rails was about the first time a functional language (probably other types too) had a programmatic proponent, it leveraged ruby to create an easy way to build web apps and people/companies wanted web apps. Just about every other language was full of smug proponents who just wanted to show how little code you needed to generate Fibonacci numbers, as if that was at all relevant to most developers. Yeah, that wasn't it. Maybe you weren't there? This sounds like a third hand experience of the era. Functional languages have been used in major programming projects (and had popular apps, from Eclipse and AutoCAD) for decades before Ruby, not to mention AI work. Besides, PG's company used CL to build one of the first web stores way before Rails was even a thing. >That doesn't appeal to me at all. I don't want to be debugging in live environment, I don't want users or testers having that power and I don't get stuck in compiling/deploying steps. That's because you haven't used it.

e12e 8y ago

For a take on what happens when smalltalk and the web browser and js meet, see: https://lively-kernel.org/ https://lively-kernel.org/ For a more "traditional" smalltalk for js, see: https://www.amber-lang.net/ https://www.amber-lang.net/