5 ms·

Having done some Smalltalk development, I can confirm for certain sorts of problems e:g complex engineering problems where the data model is inherently very com

by nickd2001 4y ago

Having done some Smalltalk development, I can confirm for certain sorts of problems e:g complex engineering problems where the data model is inherently very complex, Smalltalk can really help to the point of being game-changing and allowing people to even attack certain problems at all in the first place. But Smalltalk's image-based dev, and lack of integration with the rest of the ecosystem, really hinders too! Smalltalk is both a blessing and a curse. I'd say for most companies Smalltalk doesn't give an advantage because most companies aren't actually solving problems that are all that complex. Its specific niche problems Smalltalk is good at. And even then, you'd have to do without things like numpy or scipy, i:e other languages have better more powerful libraries at your disposal. You could kind of cobble things together, get Smalltalk to call out to other languages to use their libraries, but that does start to get messy. One thing I would still use Smalltalk for would be pure computer science research. Its good for modelling things.

brabel 4y ago
> complex engineering problems where the data model is inherently very complex, Smalltalk can really help Interesting, what are the features of smalltalk that make that possible? Wouldn't it be very similar to JS or Lisp for representing data?? Also, given its dynamic nature, doesn't it make very hard to wrap your head around complex code bases after they grow beyond what you can keep in your head at the same time (as any other dynamically typed language)?
- rbanffy 4y ago
  The way you model systems in ST, with objects and messages being passed between them, matches some physical models very closely.
  - nickd2001 4y ago
    This. And also Smalltalk is so succinct and has simple syntax, that one can "see the wood for the trees" when dealing with an inherently complex data model. I am unfraid for example of a long multi-pronged inheritance hierarchy of classes in Smalltalk, as its still reasonably easy to see what's going on, and there isn't a huge amount of code, whereas in other languages that'd be a nightmare. Java is notorious for that but actually that'd be bad in Python too
    - rbanffy 4y ago
      > Smalltalk is so succinct and has simple syntax There is an interesting aspect in there - the simpler and easier to do complicated stuff, the higher the odds of NIH syndrome: while nobody would try to reinvent the wheel in Java or C#, I've been tempted to reinvent partial wheels for my very own needs that squeak and wobble in very specific ways in such languages, just because it's so easy. It's something in the same line as seeing traditional design patterns just vanish when the language syntax has features that make their implementation trivial. You may need a library for, say, observers in C++, but they are so easy to implement in Python or Smalltalk that you'd feel no need to use something pre-built for that.
  - cutler 4y ago
    How is that different from Ruby or Elixir?
    - Jtsummers 4y ago
      Ruby's object model is based on Smalltalk's so I wouldn't expect much of a difference. And Elixir, courtesy of Erlang, has a "model the world through communicating processes" model which strongly mirrors the Smalltalk model. So developing a program in each of these languages can be, though doesn't have to be, very similar in style. With a focus on communicating entities (be they processes or objects) allowing them to manage their own state over time in response to messages from other entities.
      - cutler 4y ago
        So Smalltalk doesn't really offer much for all the sacrifices you make by adopting it.
        rbanffy 4y ago
        As with any real-world technology, it all depends on what you want to sacrifice.
        deleted 4y ago
        [deleted]
        coldtea 4y ago
        It does, as neither Elixir nor Ruby (Ruby even less) give the same developer experience. Elixir/Erlang has the messaging idea too, and Ruby has some of that model, but there's nowhere clear to how Smalltalk implements it, working withing the image/IDE, the introspection capabilities and so on...
- nickd2001 4y ago
  "doesn't it make very hard to wrap your head around complex code bases after they grow beyond what you can keep in your head at the same time (as any other dynamically typed language)?" - I'd say Smalltalk's really nice simple development environment, with the debugger being super easy to use, saves your bacon here. I always found it very easy indeed to inspect code, find out what it's doing. And there was less code in the first place. I think you raise a valid concern, but other strengths of the language and its development environment make this less of an issue than it might be. Somewhat hard to explain - best to download Pharo, read Pharo By Example, and have a play :)
- coldtea 4y ago
  >doesn't it make very hard to wrap your head around complex code bases after they grow beyond what you can keep in your head at the same time (as any other dynamically typed language)? That's just old wives tales. Static or dynamic types don't change whether you can keep the codebase "in your head at the same time". It just provides some static guarantees regarding some invariants.

brabel 4y ago

> complex engineering problems where the data model is inherently very complex, Smalltalk can really help Interesting, what are the features of smalltalk that make that possible? Wouldn't it be very similar to JS or Lisp for representing data?? Also, given its dynamic nature, doesn't it make very hard to wrap your head around complex code bases after they grow beyond what you can keep in your head at the same time (as any other dynamically typed language)?

rbanffy 4y ago
The way you model systems in ST, with objects and messages being passed between them, matches some physical models very closely.
- nickd2001 4y ago
  This. And also Smalltalk is so succinct and has simple syntax, that one can "see the wood for the trees" when dealing with an inherently complex data model. I am unfraid for example of a long multi-pronged inheritance hierarchy of classes in Smalltalk, as its still reasonably easy to see what's going on, and there isn't a huge amount of code, whereas in other languages that'd be a nightmare. Java is notorious for that but actually that'd be bad in Python too
  - rbanffy 4y ago
    > Smalltalk is so succinct and has simple syntax There is an interesting aspect in there - the simpler and easier to do complicated stuff, the higher the odds of NIH syndrome: while nobody would try to reinvent the wheel in Java or C#, I've been tempted to reinvent partial wheels for my very own needs that squeak and wobble in very specific ways in such languages, just because it's so easy. It's something in the same line as seeing traditional design patterns just vanish when the language syntax has features that make their implementation trivial. You may need a library for, say, observers in C++, but they are so easy to implement in Python or Smalltalk that you'd feel no need to use something pre-built for that.
- cutler 4y ago
  How is that different from Ruby or Elixir?
  - Jtsummers 4y ago
    Ruby's object model is based on Smalltalk's so I wouldn't expect much of a difference. And Elixir, courtesy of Erlang, has a "model the world through communicating processes" model which strongly mirrors the Smalltalk model. So developing a program in each of these languages can be, though doesn't have to be, very similar in style. With a focus on communicating entities (be they processes or objects) allowing them to manage their own state over time in response to messages from other entities.
    - cutler 4y ago
      So Smalltalk doesn't really offer much for all the sacrifices you make by adopting it.
      - rbanffy 4y ago
        As with any real-world technology, it all depends on what you want to sacrifice.
      - deleted 4y ago
        [deleted]
      - coldtea 4y ago
        It does, as neither Elixir nor Ruby (Ruby even less) give the same developer experience. Elixir/Erlang has the messaging idea too, and Ruby has some of that model, but there's nowhere clear to how Smalltalk implements it, working withing the image/IDE, the introspection capabilities and so on...
nickd2001 4y ago
"doesn't it make very hard to wrap your head around complex code bases after they grow beyond what you can keep in your head at the same time (as any other dynamically typed language)?" - I'd say Smalltalk's really nice simple development environment, with the debugger being super easy to use, saves your bacon here. I always found it very easy indeed to inspect code, find out what it's doing. And there was less code in the first place. I think you raise a valid concern, but other strengths of the language and its development environment make this less of an issue than it might be. Somewhat hard to explain - best to download Pharo, read Pharo By Example, and have a play :)
coldtea 4y ago
>doesn't it make very hard to wrap your head around complex code bases after they grow beyond what you can keep in your head at the same time (as any other dynamically typed language)? That's just old wives tales. Static or dynamic types don't change whether you can keep the codebase "in your head at the same time". It just provides some static guarantees regarding some invariants.