The Strongtalk Type System for Smalltalk (2004) | Hacker News Reader

The Strongtalk Type System for Smalltalk (2004)

bracha.org

34 pointsmpweiher17 comments

I think I remember reading at one point that a bunch of the original Strongtalk tech was recycled by Sun Microsystems for the first JVM. A quick DuckDuckGo-ing yields some plausible confirmatory links such as https://github.com/jirkadanek/Strongtalk

It wasn't for the first JVM; it was for HotSpot, the JIT engine that replaced [1] Sun's previous JVM in 1999.

HotSpot was developed by the same team that worked on Strongtalk [2], including the linked submission's author Bracha, who were later acqui-hired by Sun [2]. See also my previous comments that summarize this and recount the achievements of the rest of the Strongtalk team, who all went on to be significant contributors to various domains [3][4].

[1] http://www.javaworld.com/article/2076604/hotspot--a-new-bree... [2] http://www.strongtalk.org/history.html [3] https://news.ycombinator.com/item?id=12160439 [4] https://news.ycombinator.com/item?id=12284279

Ah, that's an important distinction I had somehow forgotten that HotSpot wasn't there from the beginning. Thank you for the summary links--interesting history!

If I've understood the lore correctly, Sun chose Java over Self as their big language for the future. Some of the key people that worked on the Self VM (including Urs Hölzle and Lars Bak) left to join Anamorphic, founded by David Griswold. They built Strongtalk, and were later acquired by Sun, to incorporate the Self VM technology into Java. This was called HotSpot when it was released.

Note that the above is mostly unrelated to this paper, except where it mentions that type information wasn't used for performance.

Oh, and it's worth noting that Dart is essentially the modern version of all this: a dynamic, class-based language, a fast VM that optimizes base on type feedback, and an IDE based on optional static type annotations. It's no coincidence, given that Gilad Bracha and Lars Bak were the initial designers of Dart.

"The most important change introduced into Strongtalk is the move from structural to declaration based subtyping. This change was made because: Structural type descriptors do not express programmer intent, and are difficult to read. Error messages produced by structural checking are poorly localized and very hard to understand. This is especially true in a large system with lots of internal cross references like Smalltalk."

Word. Yet fast-forward 30-ish years and structural typing is sold as a feature again. I swear Golang is doing so much backwards that it's starting to look intentional, like a Google-sponsored LOLCODE.

If you want to apply these claims to Go interfaces, you should actually make the case for it by showing that it's an issue in Go programs. This is just snark.

Don't knock snark. It's perfectly valid way to challenge and traces its history to early computer science. It's why you fear goto. It's why I exploit it.

Nowadays, it has become pervasive on social media, and lost value as everyone uses it. It acts as a rhetorical device which can disguise the poor quality of of the argument.

The word to keep in mind here is 'can', or I would say 'may'. The increasing tendency of crying wolf at anything you don't like by squeezing it into a category where it can't rock the boat anymore is not really helping us move forward collectively.

I would say, if it's Millenial Style Snark (gawd I hate to brand all millennials that way but they do tend to sound like the younger halo/gta 5/etc playing crowd) where they say something stupid like "Tests or STFU" or "callbacks or GTFO", yeah, that's tiresome. It's the kind of tone I saw occasionally in early nodejs discussions. I wouldn't call that snark, however.

So I agree with your last statement. Snark to me implies a wit or cleverness as well as defiance and challenge. This is why it worked for Dijkstra. The brevity of the messages above are just a show of a lack of ability or desire to communicate and clearly express an idea. The above are just unnecessarily verbally abusive. They incite a negative response before the person even has had a chance to process other meanings of the message.

I sure hope turning the whole thing into a personality-attack was worth it for you. Do you ever consider the harm you do as you desperately fight to prevent alternate views from affecting your reality? Not to mention that it's a loosing game in the long run.

Brevity is a virtue; and Golang has very little of it.

Thing is, I'm not afraid of goto. This is more like random keywords behaving like goto in certain contexts.

I have enough scars from complex Golang-applications; I'm just wrapping up a port of a 5kloc Golang-codebase to C++ and one of the things that struck me is how much declaring intentions and having them checked by the compiler helps. It's not that easy to prove decreased readability, it's more a gut-feeling of additional effort being required to keep track of everything. It's an issue I've found in any language that favors structural sub-typing, it's just that Golang is pretty exceptional at bragging about about it. What saves Golang in my opinion is the possibility of declaring types in hierarchies, which solves some of the problems; but you still have the issue where random types are part of a hierarchy without any hints in the code except for which methods are implemented.

Okay, that's better.

I agree that in Go, sometimes it's a bit harder to understand the type hierarchy for interface types. Often it doesn't matter; finding all subtypes of io.Writer wouldn't be useful, for example. Also, if you want a closed type hierarchy (such as for an abstract syntax tree), it's possible using a private marker method.

The particular thing I'd disagree applies to Go is "error messages produced by structural checking are poorly localized and very hard to understand." I can see how sometimes that might be true for some languages, but I've found Go's error messages for interfaces not matching to be reasonable.

Also, there are benefits: the ability to declare a local supertype for a subtype from another package that's not easily modifiable can be very useful, and not having this ability in other language can be rather painful due to the need for adapters.

So this seems like an area where there are tradeoffs in language design, not one where there's an obvious winner and the other side is LOLCODE.

Don't get me started on down-your-throat, manual error-handling; imports tied to repositories and opaque, mandatory N*M-threading; the outright hostility to features like flexible locking. Or the overly draconian package reference rules which turns any non-trivial software into a packaging-puzzle. There is plenty more LOLCODE-worthy contraptions in there...

Look, they even admit themselves that the primary goal was for the language to be easy enough for beginners to not hurt themselves; which is fine if that's what you're looking for; for me it's mostly a no go, since I need more power than that to not drown in the complexity of the problems I'm solving.

> I swear Golang is doing so much backwards that it's starting to look intentional, like a Google-sponsored LOLCODE.

I pretty much agree with this.

However, I think structural types can be very useful (though as row types, not subtyping). But I think you do still need a way to specify nominal types. Something like OCaml's abstract types on top of a language with row-typed records would give you the best of both worlds.

Reply on news.ycombinator.com