,
11 tweets,
4 min read
Read on Twitter
@StephenPiment I don't think "Worse is Better" really explains it. The LispM builders made a number of serious mistakes. For example, the IBM 801 papers had already been published at the point where they were designing the CADR but they didn't pay attention to them, and continued not to.
@StephenPiment (They presumed that microcoded architectures with complicated instructions were better, and never tried measuring to prove what was in fact a hypothesis. The hypothesis was, of course, desperately wrong.)
@StephenPiment They also presumed that portability wasn't really important, that tying software hand and foot to a particular CPU architecture was fine. That I can blame them for less; the first really portable OS (Unix) already existed but wasn't widely understood yet.
@StephenPiment And yes, Unix was primitive compared to what the LispM people were used to, but in many ways it was architecturally superior, and it was architecturally layered in a way that permitted rapid portability _and_ rapid evolution in a way that systems like ITS could never have.
@StephenPiment Also, the vision was wrong. First, I didn't really understand this until a few years ago, monotyped languages (and "dynamic" languages are just monotyped) are seductive, but in the end, humans need systems that prove more things about their programs.
@StephenPiment The whole edifice of modern type theory was unknown to the Lisp crowd. They did have a beautiful tool in that Lisp is homoiconic, and I think (based on how nasty syntax extension via PPX is in OCaml) _that_ is underappreciated by the ML crowd, but dynamism id ultimately flawed.
@StephenPiment The performance tax of having to do constant run-time checks alone is painful, and cannot be expunged. See what JavaScript runtimes that perform even modestly are like; it's terrifying how much RAM they eat. The tax on programmer mental energy is even worse.
@StephenPiment Second, and almost as bad, like the Smalltalk machines, the LispM model was a big ball of mud, where you couldn't even distinguish the edges of individual programs. Everything from debugging to version control to just delivering code is exceptionally painful in such a world.
@StephenPiment It was seductive — they had no better models of what a rich programming environment could be like — but it really wasn't something that could scale along any dimensions that counted. Yes, it had amazing things _for the time_ like online documentation and great editors.
@StephenPiment Lastly, and I think many people forget this, the LispMs were insanely expensive. _Insanely_. They cost multiples of your salary, not fractions. No ordinary hacker could ever hope to own one; the only people who could work with one every day worked for government subsidized orgs.
@StephenPiment To the people who worked with them, they were a paradise, and they mourned being ejected from Eden, but like the failure of the space program to make progress after Apollo, it was a false spring created with oceans of DARPA money and lacked a real technological future.
