Comment by justinpombrio | Hacker News Reader

Comment by justinpombrio | Hacker News Reader

Parent Full thread

No, it's just that this principle isn't true. There are a lot of factors that influence which languages and systems persist. Being of sound design is a factor, but not the biggest one.

Take Javascript, for example. It's the top language on Github. Its not there because its everyone's favorite language, or because it's an ideal language for writing reliable software. Its there because its baked into web browsers. We're now starting to get full-featured reliable compilers into JS with sourcemaps and whatnot, plus things like webassembly. So it's becoming quite reasonable these days to write code for the web in a language that isn't JS and not feel like a second-tier citizen. But that hasn't always been the case, so people wrote a lot of JS out of necessity. And that's why it's at the top.

(I don't mean to riff on JS in this post. There are plenty of other opportunities for that. The language has improved over the years, and this is surely part of the reason it's remained at #1, and part of the reason why browser vendors didn't throw up their hands and try a different language instead. But the main reason its at the top is because it's the language of the web.)

If SmallTalk were built into browsers instead of JS, then we'd all be writing SmallTalk. And it'd be blazing fast. And that has nothing to do with how sound its design is.

One turning point that saddens me as an ex-Smalltalker - at one point there were negotiations underway to have Smalltalk installed by default on all new Sun Workstations (this was back when Sun was a very significant player), but it fell through for financial reasons. Had this been the case, I'm sure Smalltalk would be significantly better known and more commonly used.

And as justinpombrio says above, that has nothing to do with how good or bad the language is.

Had not heard that, but this is truely heartbreaking. I still think that Smalltalk is the better language than most of the modern object oriented languages, and be it only that is is a bit more pure and its "successors" are too much a mix with other paradigms. Just thinking of Python - it is in a wide range of features equivalent to Smalltalk withtout being as consequent in the object orientation.

One could only dream of how nice the programming world would be, if Sun had pushed Smalltalk instead of Java. Ironically, Hotspot started its life as a Smalltalk VM and only when Sun took over the development was turned into a Java VM.

Actually, Sun tried to license Smalltalk from Parcplace to use in embedded devices. At that time Parcplace was quite happy to charge $3000 per seat and didn't make a reasonable offer to Sun, so the Oak (now Java) project was started instead.

To make things even worse, Parcplace merged with their main rival, Digitalk, which offered Smalltalks for PCs and Macs for $100 to $500. They promptly replaced those with "enterprise" products costing way more making it impossible for new people to learn the language except with toy implementations like Little Smalltalk and GNU Smalltalk (which later evolved into a very decent implementation). For some reason the nice Smalltalk/X (commercial, but free for educational use) only had a small niche in Europe.

Note that Sun already had a Smalltalk in the form of Self, but Java was created anyway and Sun decided to use it exclusively killing Self and Tcl (which spun off instead of dieing). Part of the Self group merged with a group researching Smalltalk with optional type declarations (Dart is the latest version of that) to create the company Animorphics to develop StrongTalk.

Meanwhile, the Pep project at Sun demonstrated that you could run Java on the Self VM and greatly outperform all existing Java implementations (which were simple bytecode interpreters). The Animorphics team did the same and showed off Java on their VM, which caused Sun to buy them to make this demo into the HotSpot VM.

Or if PHP were built into browsers, we'd all be using PHP.

And the world would be slightly dumber, and even more willing to accept shoddy design.

Shudder

(Yes, modern PHP is okay, but there are still a thousand and one bits of legacy baggage from a darker time that yet remain to be fixed - things like sane process control (PHP can't reliably access subprocess return values!), standard I/O support (can't read from stdin one char at a time, so sane CLI tools are broken), DB sanity (the SQLite3 extension will run all queries twice unless you code around bugs that have been known about for 10 years), etc), socket I/O (you physically cannot write rock-solid sockets code; the builtin streams functionality _and_ the socket extension do not provide enough surface area to handle all plausible error conditions, and it's entirely possible your script will hard-crash in certain obscure scenarios because the runtime doesn't give you the ability to trap all errors), and because of these longstanding issues PHP _does still have_ a sad culture of "it's okay, we'll just do this crazy horrible workaround", and nobody's fixing it.

I wanted to give a practical example, but unfortunately I can't find it. I was debugging some incredibly confusing socket behavior one day, and found where a major library/framework had hit exactly the same problem, and what they did - it was a remarkably well-engineered solution - was to setup a custom error handler, preg_match() the PHP error string (!) inside the error handler, then use some magic "if this is set to this and that var equals that value" derived from reading the PHP source code to detect a socket error condition. This code is still in place since PHP 7 hasn't fixed any of this, I just can't remember the library name or where to look for the code unfortunately.

</rant>

Reply on news.ycombinator.com