5 ms·

The time I spent doing commercial Smalltalk development was some of the most productive and enjoyable of my career. Couldn’t stand the company I was at, but lov

The time I spent doing commercial Smalltalk development was some of the most productive and enjoyable of my career. Couldn’t stand the company I was at, but loved the work itself. Later did some consulting with a company that was moving everything from smalltalk to Java because they didn’t feel like they could find devs or stay current if they didn’t. I still feel like we lost something or like other languages haven’t quite caught up in their own way, even though I know the world won’t go back.

mettamage 5y ago
According to you, what was lost? I've never fully experienced Smalltalk, but the few posts that came by on HN always fascinated me, since there's a whole interactivity element to it. And I've noticed when it comes to programming, I like interactivity.
- poulsbohemian 5y ago
  FYI: Responded to your email privately.
- capableweb 5y ago
  The Pharo "Features" page features animated GIFs and some text explaining the awesomeness of Smalltalk: https://pharo.org/features https://pharo.org/features
- smackeyacky 5y ago
  The only two things I miss and they are closely related: 1. being able to catch an exception, and injecting a sensible return value so the underlying code could continue. Its incredibly powerful although a lot of inexperienced smalltalkers used it as a crutch for poor design. I.e. I won't handle the error or do bounds checking, I will put a try/catch block around it and send back some value the code can handle. 2. The interactive debugger was truly fix and continue, not the pale imitation you get in .NET or Java. Your code crashed, it threw up an exception window, you fixed the method and restarted the thread of execution like nothing happened. You can kinda do this in .NET now but its slow and doesn't always work right. The rest of the environment goodies like variable inspectors and live expression evaluation are largely as good or better in java and C# than the classic commercial smalltalks.
  - pjmlp 5y ago
    Still not the same, but the recently hot reload on VS 2022, or JRebel get closer to the experience. And this is the best we currently have, other languages are even more behind than those two ones.
    - brabel 5y ago
      > And this is the best we currently have, Haha, no... have you heard of Lisp?
      - pjmlp 5y ago
        Haha, are you new around here? I have certainly heard about Lisp, in fact, many haven't heard about Allegro Common Lisp or Lisp Works, the only ones that matter, which the FOSS usually ignores. This doesn't change the fact that sadly Lisp and Smalltalk are almost nowhere to be seen in 2021 (in large deployments).
        casion 5y ago
        Clojure is most certainly on par or exceeds both in business use.
        jhgb 5y ago
        How is Clojure relevant for the topic of fully interactive development? Unlike Smalltalk or Common Lisp, it doesn't even attempt it.
        pjmlp 5y ago
        On par with Allegro and Lisp Works it isn't certainly not.
        casion 5y ago
        Agreed, Clojure very likely exceeds them combined in active business use.
rwmj 5y ago
As a counter-point, I did some Smalltalk development back in the 90s. It was slow, verbose, couldn't integrate with CVS, required you to use their editor, and produced a UI which was completely non-native. The development environment was a world unto itself (like Java actually), and cost a small fortune. We migrated to C++ pretty quick.
- jacquesm 5y ago
  Same here, I loved the language and the concepts behind it but the companies that populated the eco-system were terrible and users did not like the end result due to the lack of native interfaces. We too went the C++ route (specifically, Borland C++ Builder, which was very fast and easy to develop with) and never looked back.
  - worik 5y ago
    "Borland C++ Builder" I remember that. It was awful. It drank the OO koolaid complete with multiple derivation. For GUI I switched to the MS windows C-toolkit. Event driven and very easy to manage. The OO solutions from Borland and MS (MFC if memory serves) were very hard to use
    - jacquesm 5y ago
      Compared to the alternatives it was great, it compiled super fast and was very reliable. The MS windows C/C++ compiler drowned you in boilerplate, Borland just got out of the way and got you to focus on the job. I never did any deep dives into the OO solutions, for me it was just a way to get an Irix application ported over to Windows with minimal hassle.
      - worik 5y ago
        The MS MFC was bad too. I did not use that as much. When I had the choice I switched to using the C-SDK and an event loop. Twenty years ago now, but I can still recall my frustration. So much work (by Borland and MS) to make things so much worse

mettamage 5y ago

According to you, what was lost? I've never fully experienced Smalltalk, but the few posts that came by on HN always fascinated me, since there's a whole interactivity element to it. And I've noticed when it comes to programming, I like interactivity.

poulsbohemian 5y ago
FYI: Responded to your email privately.
capableweb 5y ago
The Pharo "Features" page features animated GIFs and some text explaining the awesomeness of Smalltalk: https://pharo.org/features https://pharo.org/features
smackeyacky 5y ago
The only two things I miss and they are closely related: 1. being able to catch an exception, and injecting a sensible return value so the underlying code could continue. Its incredibly powerful although a lot of inexperienced smalltalkers used it as a crutch for poor design. I.e. I won't handle the error or do bounds checking, I will put a try/catch block around it and send back some value the code can handle. 2. The interactive debugger was truly fix and continue, not the pale imitation you get in .NET or Java. Your code crashed, it threw up an exception window, you fixed the method and restarted the thread of execution like nothing happened. You can kinda do this in .NET now but its slow and doesn't always work right. The rest of the environment goodies like variable inspectors and live expression evaluation are largely as good or better in java and C# than the classic commercial smalltalks.
- pjmlp 5y ago
  Still not the same, but the recently hot reload on VS 2022, or JRebel get closer to the experience. And this is the best we currently have, other languages are even more behind than those two ones.
  - brabel 5y ago
    > And this is the best we currently have, Haha, no... have you heard of Lisp?
    - pjmlp 5y ago
      Haha, are you new around here? I have certainly heard about Lisp, in fact, many haven't heard about Allegro Common Lisp or Lisp Works, the only ones that matter, which the FOSS usually ignores. This doesn't change the fact that sadly Lisp and Smalltalk are almost nowhere to be seen in 2021 (in large deployments).
      - casion 5y ago
        Clojure is most certainly on par or exceeds both in business use.
        jhgb 5y ago
        How is Clojure relevant for the topic of fully interactive development? Unlike Smalltalk or Common Lisp, it doesn't even attempt it.
        pjmlp 5y ago
        On par with Allegro and Lisp Works it isn't certainly not.
        casion 5y ago
        Agreed, Clojure very likely exceeds them combined in active business use.

rwmj 5y ago

As a counter-point, I did some Smalltalk development back in the 90s. It was slow, verbose, couldn't integrate with CVS, required you to use their editor, and produced a UI which was completely non-native. The development environment was a world unto itself (like Java actually), and cost a small fortune. We migrated to C++ pretty quick.

jacquesm 5y ago
Same here, I loved the language and the concepts behind it but the companies that populated the eco-system were terrible and users did not like the end result due to the lack of native interfaces. We too went the C++ route (specifically, Borland C++ Builder, which was very fast and easy to develop with) and never looked back.
- worik 5y ago
  "Borland C++ Builder" I remember that. It was awful. It drank the OO koolaid complete with multiple derivation. For GUI I switched to the MS windows C-toolkit. Event driven and very easy to manage. The OO solutions from Borland and MS (MFC if memory serves) were very hard to use
  - jacquesm 5y ago
    Compared to the alternatives it was great, it compiled super fast and was very reliable. The MS windows C/C++ compiler drowned you in boilerplate, Borland just got out of the way and got you to focus on the job. I never did any deep dives into the OO solutions, for me it was just a way to get an Irix application ported over to Windows with minimal hassle.
    - worik 5y ago
      The MS MFC was bad too. I did not use that as much. When I had the choice I switched to using the C-SDK and an event loop. Twenty years ago now, but I can still recall my frustration. So much work (by Borland and MS) to make things so much worse