|
|
|
|
|
|
by opinali
4073 days ago
|
|
|
I usually love James Hague's posts, but this one has his head buried deep in the sand. And he's enough of a veteran to remember early Lisp and Smalltalk systems, where excessive openness in all aspects looked awesome for prototyping/hacking or academic toy programs (or what is considered toy-size in the last 20 years anyway), but was a disaster even for the mid-1990's definition of programming in the large. Attempts to discipline these languages came too late, so they got overrun by competitors with lots of "paranoid" rules like C++, Java, hell even Eiffel. (Not the single reason of course but one important reason; not even the gurus could help themselves to not abuse dark magic and write application code that would be compatible across minor updates of the language/frameworks, let alone other compilers/VMs/platforms.) If you need extra evidence with more current technology, see most "bad parts" of Javascript (successful, but in the same way that the Titanic was wildly successful for one week; people who build large JS apps have been in a mad rush to fix or replace it for the best part of the last decade, hopefully with ES6 coming as a first major win in that direction). TLDR sorry James, we have tried the elegance of extremely simple and open language/runtime architectures, and that was always an abject failure. |
|
|
Just because it was tried in the past, doesn't mean it wasn't the right direction.
> Attempts to discipline these languages came too late,
So, as an industry, we were learning and now we know some basic principles. Discipline does a great deal for Erlang. Ironically the game sockets he describes are basically how Erlang functions at scale. To say the practice is always an abject failure is burying your head in the sand.