Comment by nickd2001 | Hacker News Reader

Comment by nickd2001 | Hacker News Reader

Parent Full thread

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.

> 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)?

The way you model systems in ST, with objects and messages being passed between them, matches some physical models very closely.

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

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

How is that different from Ruby or Elixir?

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.

So Smalltalk doesn't really offer much for all the sacrifices you make by adopting it.

As with any real-world technology, it all depends on what you want to sacrifice.

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

"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 :)

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

Reply on news.ycombinator.com