Allen Wirfs-Brock, a language implementer and JavaScript standards editor, writes about Smalltalk and JavaScript history and language design.
Commenters link him as a firsthand source who was there at the beginning, and point to his responses and his long JavaScript history PDF.
> Racket uses a bytecode VM and/or a JIT, so Haskell being faster wouldn't surprise me.
They support AOT native-code compilation too, but they say the JIT generally performs better: https://download.racket-lang.org/docs/5.1/html/raco/ext.html but my experience in the past was that it didn't perform that well. Maybe it's improved.
> Go doesn't have a primitive type system because it makes it faster, but mostly because that's a design choice. Same thing for Java.
I agree: a primary goal for both languages was clarity, even at the expense of some generality. Java was very slow for a decade (HotSpot wasn't released until 01999 and wasn't very good until about 02002), but a few billion dollars and a Fortune-500 bankruptcy later, it's really pretty zippy! (As long as you don't care about startup time.) Golang, by contrast, was designed with higher performance goals, which it fell somewhat short of.
> Lack of ad-hoc polymorphism is usually a criticism of ML and its descendants, but Go and Java both lack it too
Ad-hoc polymorphism is absolutely fundamental to Java; one of its big differences from C++ was that nearly every callsite implied ad-hoc polymorphism, and that's where a lot of the optimization effort went. Golang isn't quite so radical about it, but its interface mechanism exists for almost nothing but ad-hoc polymorphism.
OCaml has ad-hoc polymorphism, FWIW, but people don't use it much.
> both added generics 10 years after the language was created
Golang was…
The author seems to know (well, was involved in) the history of Self and Strongtalk but seems disappointed that the people involved went on to work on and perfect what they see as inferior technology (Java, JavaScript).
In reality I think if we do an honest accounting of the situation we can see that these have been the more pragmatic engineering solutions for their times, and so that's where the $$ was. I worked in Java for years, but didn't particularly like it, but it is, I think, what the marketplace needed and could handle at the time.
And I think JS/ECMAScript etc. is a reasonable practical solution for the imperfect world that evolved out of Internet/browser tech.
Unlike the author I don't think Sun's fortunes would have been any different if Self/Strongtalk or some other Smalltalk-world inspired/derived tech had been pushed hard. The market didn't need or want it.
IBM did a similar pivot with their VisualAge line, and they did it for pragmatic reasons.
Finally, let's look at the bigger picture: in the end, what we have with the browser + modern JS on V8/SpiderMonkey etc. is a dynamic object oriented programming language that allows for dynamic manipulation of its environment, is accessible to any user, can be edited and inspected live, can present interactive media to users, and has a large community of authors.
Is this really that far off from what Alan Kay and Dan Ingalls originally wanted? Purists will gag, but I think as much as I hate front end dev in JS…
I started a project[1] a while back when it became clear that the underlying architecture for the new devtools in Firefox was going to be as problematic as Firebug's had been. Longtime Mozilla contributor Wladimir Palant just published a post a few days ago touching on some of the problems with devtools that he ran into when trying to work with it.[2]
The idea with sepsis-inspector is that it should be able to replace Hewitt's old DOM Inspector codebase and be stupid simple to extend with third-party viewers. (For anyone unfamiliar, DOMi has the ability to inspect not just webpages, but e.g. the Firefox UI [and Thunderbird, and SeaMonkey] and extensions as well.)
The interface between the Inspector itself and the viewers is nice and modular for the most part. It's basically Unix pipes in GUI form, with a few services for sugaring. Altogether, this makes its design a good foundation for a generalized inspector framework. (And I do mean generalized. Let's debug PNGs, PDFs, and Haxe, too, but I'm not even talking just the Web here. Want to use it to debug Gnome Shell or your Mono app? Sure. I mean, why shouldn't we be able to?)
Since DOM Inspector, Firebug, and the new Firefox devtools exist, I've focused most of my time on getting the architecture right and then teaching the Inspector how to do some things that those tools can't already do, rather than necessarily shooting for parity from the start. This means that if you download the sepsis-inspector add-on[3]…
From the past discussion:
http://wirfs-brock.com/allen/posts/914 - a direct response, well worth the read as it provides more context and a different perspective.
From my recent reading list:
Evolution of Smalltalk: From Smalltalk-72 through Squeak by Dan Ingalls: http://worrydream.com/refs/Ingalls%20-%20The%20Evolution%20of%20Smalltalk.pdf [pdf]. It's 101 pages but also worth reading, if for nothing else that what I found to be a really interesting story of how Smalltalk-80 was essentially bootstrapped from the similaryl named but nowhere as capable Smalltalk-72
The Early History of Smalltalk by Alan Kay: http://worrydream.com/EarlyHistoryOfSmalltalk/
Kay and Ingalls do a good job discussing the actual history of Smalltalk but with their own focus being on what it enabled, with very little interest in the actual commercial side of things. Wirfs-Brock's post gives more information about the context of Smalltalk in the commercial and enterprise setting.
Huh?
The Xerox Star was introduced in 1981 https://en.wikipedia.org/wiki/Xerox_Star
Apple's Lisa was introduced in 1983. https://en.wikipedia.org/wiki/Apple_Lisa
With it, Lisa Toolkit and Clascal (Pascal with Classes) http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/apple/lisa/toolkit_university/Clascal_Reference_Manual_Mar83.pdf
The Mac in 1984 https://en.wikipedia.org/wiki/Macintosh_128K
MacApp in 1985 https://en.wikipedia.org/wiki/MacApp
The Tektronix 4404 running Smalltalk, also 1984 http://www.wirfs-brock.com/allen/files/tek/4404-Flyer.pdf
The Amiga and Atari ST in 1985.
Windows was at 2.0 in 1987.
Heck, the NeXT cube had been introduced by fall of '88.
https://en.wikipedia.org/wiki/NeXT_Computer
I don't think a few code snippets prove the point. My conjecture is that any complex enough piece of code with essentially (not accidentally!) convoluted concepts will benefit from OOP more than any other style
Can we just appreciate the fact Python is such a Swiss Army Knife and allows for multi-paradigm approach?
Let's just not use low "bashing" of any paradigm as an excuse to neglect the design.
In some other thread someone mentioned lack of quality metrics. Well, this question has been asked previously, a recommended read from me: http://www.wirfs-brock.com/PDFs/How%20Designs%20Differ.pdf