Hacker News Reader

Comment by coldtea | Hacker News Reader

This reads like a Smalltalk hype-man (like the guys hyping a rapper) - I think I've read this guy before on ST topics.

The "secret weapon" angle dismisses languages in wide use for all kinds of superficial reasons that didn't hurt major adoption across startups, unicorns, and huge companies like Google and Amazon.

e.g.:

"Python has many peculiarities in its design, especially with respect to object-oriented programming. Its multithreading capability is crippled by the GIL (global interpreter lock). Its lambdas are oddly restricted to single expressions. Its half-open intervals are unintuitive"

"Java is extremely verbose. It’s more awkward to use than Python. C# is Java on steroids."

etc.

while sidestepping major Smalltalk issues - first and foremost the lack of a wide and mature ecosystem of libs and a non-frequently-breaking-compatibility FOSS Smalltalk, or the lack of programmers to hire.

View on HN

Well, he probably is an Smalltalk evangelist but I don't see this as something bad.

"The secret weapon" I think makes reference to Paul Graham's essay Beating the average: http://www.paulgraham.com/avg.html and he probably thinks that Smalltalk gives the same kind of "unfair advantage" as Lisp did in Paul Graham's article.

According to some studies, Smalltalk seems to be very productive: https://www.cincomsmalltalk.com/main/2022/07/need-productivi...

http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty...

> According to some studies, Smalltalk seems to be very productive: https://www.cincomsmalltalk.com/main/2022/07/need-productivi...

In fairness however, Cincom develops and dells a commercial/proprietary Smalltalk implementation... you'll hardly see somebody saying "yeah our software is a pile of garbage" in their product/company website.

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.

>Well, he probably is an Smalltalk evangelist but I don't see this as something bad

Surely, not bad. Smalltalk could use far more adoption again!

But in his case, he isn't also giving the full unbiased picture, so it's more of a "marketing man/evangelist" than an "objective adopter/evangelist"...

What's often overlooked is that Viaweb was developed, as I recall, in the late 90s when the Internet was in its infancy and there were far less libraries than we have today which made hand-rolling everything in Common Lisp more viable.

I really like Smalltalk but basically he fails to explain what the added value of Smalltalk would be over Python as a baseline.

GIL is inconvenient but the times I was really limited by it are few. Lambdas are not Smalltalk blocks, but you can just define a local function and refer to it by name. This is like a block, the only thing you need to do is to bind the block to a name. Indentation-based syntax is not everyones preference (even not mine), but not using indentation is not a super power.

What I would say is a primary selling point of Smalltalk to this day is the seamless development experience with Class Browser/Editor/Playground/TestExecution.

Reply on news.ycombinator.com