8 ms·

War of the workstations: How the lowest bidders shaped today's tech landscape

174 points by lproven 3y ago

kens 3y ago
This is a very interesting article on computer history. There's a lot that I disagree with, though...
- lproven 3y ago
  Like I said above -- please do read my earlier comments -- I'd love to hear what, and why.
tyingq 3y ago
There's a lot that rings true here, but the article keeps noting that the IBM PC won partially because it was cheap. That's only true versus the examples the authors cite. In the business space, it was pretty expensive when compared to, for example, business oriented Z80/CPM platforms. And it was very expensive compared to the variety of home 8-bit choices. There were a lot of different markets/niches at the time, and things changed quickly, so it's hard to distill the history into soundbites about what happened and why.
- lproven 3y ago
  Not quite. Firstly, re predecessors: DOS was a lot more capable than CP/M-80 and any 8-bit systems. It displaced them for much the same reasons x86-64 displaced x86-32: it became affordable to have lots of RAM. In the early 1980s, 8080/Z80 couldn't handle >64kB without clunky paging. Some 25Y later, x86-32 couldn't handle >4GB without clunky paging, in much the same way. Secondly, re the PC's cheapness. I'd argue the PC was cheap for a business machine, but it's not simply that the PC hardware was cheap, but the bigger point that the bundle of the cheap machine and the cheap OS is what won out. The PC launched with 3 OSes: PC DOS, the UCSD p-System (a self-hosted Pascal IDE based on a JVM-like environment), and DR's CP/M-86. MS-DOS was about ¼ of the price of the other offerings. DR had an amazing comeback planned: it added the multitasking of MP/M to CP/M-86, creating Concurrent CP/M, then bolted on MS-DOS emulation, to create a multitasking OS that could run and multitask MS-DOS apps on a 286: Concurrent DOS (CDOS for short). It also had a multitasking version of the GEM GUI called X/GEM. This is something even the later OS/2 1.x couldn't do, and of course OS/2 1.0 didn't have a GUI at all. But CDOS/286 depended on a feature of the development versions of the 80286 which Intel removed from the final shipping version. So, when IBM launched the first 286 PC, CDOS didn't work. Intel put the hardware feature back but it was too late: the OS had been killed at birth -- it didn't work on shipping 286 kit. Only native apps multitask. DR had a fallback plan: it promoted CDOS as a realtime OS and made a living for years afterwards, but the big product to outdo DOS, which originated as a clone of DR's CP/M anyway, was thwarted. So it's not just "the PC was cheap", no. It's bigger than that. It's: * On the business desktop, the PC was cheap, _and_ the dominant PC OS was cheap, and the PC was built from open COTS parts and ran a COTS OS so was cheap to clone. * In academia and research, UNIX on mostly-COTS hardware killed off elaborate proprietary OSes on proprietary hardware. While PCs used x86, ST-506 and then ESDI and then IDE disks, ISA slot cards, etc., workstations used fancy 32-bit CPUs on fancy buses like NuBUS, VMEbus, and so on, with SCSI storage... and later moved to RISC chips with fancy buses and SCSI. This killed off proprietary non-open non-standard OSes such as VMS, Apollo DomainOS, and other exotica. Meanwhile, in business, DOS killed DR and the p-System and all the eight-bits. Later, Windows killed all the 16-bit GUI machines, except the Mac, which only survived by self-destroying and becoming a Unix machine.
  - akira2501 3y ago
    > ISA slot cards This was actually bigger than I think people remember. IBM gave away all the information on their bus standard immediately. They clearly understood they had to create a robust third party add on market for the PC and this would be key to driving the platform. They were not wrong.
    - FirmwareBurner 3y ago
      They were not wrong in terms of what had to be done to make the OC platform the dominant one, except they didn't get to profit from the PC business for too long. The openness "mistake" is what Apple fought to avoid.
      - toyg 3y ago
        And Apple almost died because of that opposition to openness. They only returned to profitability once they promised to be as open as everyone else: having intel processors and a standard Unix userland. (They then got filthy rich by effectively pivoting to portable computing, a world where openness and standardization were never essential.)
        lmm 3y ago
        > And Apple almost died because of that opposition to openness. They only returned to profitability once they promised to be as open as everyone else: having intel processors and a standard Unix userland. Not really. The brief time when they allowed what we would now call "hackintoshes" was when they came closest to dying. They adopted intel processors for cost reasons, but went out of their way to keep their system "different". (And IIRC that was after they'd recovered to healthy profitability on the back of the iMacs and iPod)
        qwytw 3y ago
        > They only returned to profitability once they promised to be as open as everyone else: having intel They were profitable in the early 2000s with PowerPC and they probably would've stayed on it had it remained competitive with Intel.
snakeyjake 3y ago
LISP fetishism must be resisted every time it appears. Programmers who learn LISP and think they have become enlightened are no different than drunks who ramble on about how it is impossible to know if the colors they see are the same as the colors you see.
- Phiwise_ 3y ago
  It's a strange sort of Lisp fetishism that wants to bring back Smalltalk instead of Lisp.
  - lproven 3y ago
    Exactly! :-)
- lproven 3y ago
  I'm not a Lisp fetishist and I personally find it nearly as unreadable as Perl and APL. The article is in fact expressing my admiration of Dylan, if you look more closely, and Smalltalk and other things of that ilk. Lisp was a tremendously important step... In 1959. They should have continued with the planned Lisp-2, but they didn't, and sadly, McCarthy is dead now. In its absence, Dylan is about the best candidate for a Lisp-2 we have.
  - agumonkey 3y ago
    As a somehow lisp head, and even though I mellowed with time, especially about syntax, I still don't think there's anything wrong with sexps. It might be a neurological trait, some people just can't live with a syntactic layer.. their brain might rejoy with it, think clearer and faster. I, for one, is the opposite, it removes one dimension in the problem space, and structural edition is so cute. I also have a tiny personal bet that in 30 years, if people are still writing code.. someone will make sexps mainstream.. just like closures are now, just like tree processing / ast / transpiling is mainstream now.. it just take time to cook the mainstream.
    - 3y ago
avidphantasm 3y ago
So computers should’ve stayed expensive and inaccessible to most people. Yeah, that’s how markets grow.
- lproven 3y ago
  That is not only not right, that is not even wrong. It's not even a misinterpretation of what I was saying. It's like taking the first letter of each line, spell checking it until it reads as English somehow, and disagreeing with the result! I am saying we shouldn't have done it the cheap way. We should have done it the best way when it was visible what was the better but more expensive way. Because that is what we must do know, but it's going to be much harder and much more expensive now because we need to replace 30+ years of accumulated useless cruft, while staying interoperable with it throughout.
  - avidphantasm 3y ago
    You’re not wrong, it’s just not how technology tends to develop. We always go with “good enough for now.” Even if some people understand in the moment that there is a better way, there is always a tension between goal and subgoal pursuit. Usually, developing IT systems is the subgoal to the domain goal. Once the IT system is “good enough” to accomplish the domain goal, we move on.
    - lproven 3y ago
      > We always go with “good enough for now.” The whole point of the piece is that not everyone does this and there are plentiful counter-examples, and while they never took over the mainstream, they have survived for decades despite going against the flow. I can say this with authority because I wrote the article, and delivered the original talk upon which it's based.
Phiwise_ 3y ago
Glad to see you're still fighting the good fight on this one, lproven. If anyone finds this interesting, Liam has three great fosdem lectures out introducing this topic from the perspective of business software dev, hardware tech, and open source. I found the first after reading The Unix-Haters Handbook, and as much as I like its style Proven's videos are broader and up-to-date, so much better for learning: The Circuit Less Traveled: https://news.ycombinator.com/item?id=16309195 https://news.ycombinator.com/item?id=16309195 Generation Gaps; a heretical history of computing: https://news.ycombinator.com/item?id=22265615 https://news.ycombinator.com/item?id=22265615 Starting Over; a FOSS propisal for a new type of OS for a new type of computer: https://news.ycombinator.com/item?id=26066762 https://news.ycombinator.com/item?id=26066762 I also coincidentally found what might be the only good video about the Apple Newton on the internet today (although with the state of google search it's impossible to know outside of youtube). It makes a great supplement to the discussion of breaking the mold of OS conventions: https://www.youtube.com/watch?v=5kxRi34PqWo https://www.youtube.com/watch?v=5kxRi34PqWo The channel also has full interviews used in the dicumentary. I haven't seen the newest one, but it's two hours with a Mac and Newton architect so it's probably great: https://www.youtube.com/watch?v=KsaGx0loR3M https://www.youtube.com/watch?v=KsaGx0loR3M
- lproven 3y ago
  Oh, thank you! :-) That was a very pleasant Newtonmas surprise to read! :-D Yes, the core of this article was adapted -- with my editors' full knowledge and agreement, of course -- from one of my FOSDEM talks. I plan to return with some more of the talk -- and some new stuff! -- in later pieces. Sadly, the FOSDEM organisers did not accept my proposal for a talk this year. Ah well.
  - DonHopkins 3y ago
    I started reading the article, and it was making so much sense that I scrolled back up to the top to see if you wrote it, and you did! So I came here to say I really love your work because you really get the big picture and do your research, but somebody beat me to it, dammit! After recently watching that depressing trending four hour youtube video about psychopathic plagiarizing charlatans, it's really refreshing and uplifting to read something original that's so well researched with great citations. I hope you don't get plagiarized too, but if you do, consider it the highest form of flattery.
e-dant 3y ago
I wonder if there’s room for a theory of convergent evolution, in software and languages, towards something that is generally appreciated. Maybe there will always be camps arguing for one thing or another, but together and over the longest term, do they all pull in one general direction? I’m not so sure I agree with most of the article. The perspective is valuable.
- lproven 3y ago
  > towards something that is generally appreciated. I think it's simpler than that. It's convergence to the lowest common denominator. The simplest implementation of the simplest thing that does the job, in the simplest easiest language that is capable of it. But because "simple" can be taken to extremes of very clever but abstruse tools that only near-genius level minds can use effectively, and those folks do not work well together, what ends up cheap at first is the simple easy thing that is simple and easy to get working. Lisp might be arguably simpler in a theoretical sense but for a lot of ordinary folks it's just too weird and too hard. APL is "simple" inasmuch as a hundred lines of nested loops can be written as one line of a dozen hieroglyphics that does the same task in one operation... but there are only a few hundred people on the planet that can read it. C is a simple tool for simple computers but you can pick it up and learn how to use it with just a book and some time. It's fiddly and hard to do anything clever which means programmer must do grug brain stuff. https://grugbrain.dev/ https://grugbrain.dev/ And that means others can follow it, and work with it, and that means teams scale. Not very well but a bit. So companies can hire rooms full of grugs and make it work. Result, fairly simple dumb tool beats clever fancy more capable tool. Result, people who like the dumb tool have strength of numbers and they mock the speccy nerdy weirdos who like the weird tool. Which is fine until you end up with a million programs built from a million lines of C each and a million techies trying to get them to work together. Then you end up with an industry that makes billions of dollars a month, selling billions of lines of code that nobody understands, and hundreds of thousands of people trying to prop it up and keep it working. By that point it becomes clear that you should have employed a dozen geniuses to do it in a few thousand lines of the weird nerdy tool. You'd have ended up with something smaller and simpler and easier to maintain, and even the paycheques of the dozen geniuses would be less than the paycheques of a thousand grug brain developers. But it's too late. The geniuses retired or went off to grow bonsai or something. All that's left is people who only know the grug brained methods. It is easy to believe it's some kind of elegant evolution of the best possible solution... but it's not really. It's lots and lots of the cheapest worst solution until everything else dies out. That is what I am trying to get at here. But I am always learning and I try hard to be open minded. If you have specific point by point rebuttals, I'd love to read them!
jauntywundrkind 3y ago
> The story about evolution is totally wrong. What really happened is that, time after time, each generation of computers developed until it was very capable and sophisticated, and then it was totally replaced by a new generation of relatively simple, stupid ones. Then those were improved, usually completely ignoring all the lessons learned in the previous generation, until the new generation gets replaced in turn by something smaller, cheaper, and far more stupid. Beautifully said. But for the last couple decades not even that is true. It's just been more and more of the same OSes, doing basically the same things. What it means to develop a native app is pretty fundamentally unchanged since Windows 3.11 or ISX days. Software has changed, but only neo-mainframes. All the groupware and multi-tenant and scale-out software systems the author decries as lost? Rebuilt as online systems, powered by communicative capitalism and vast data-keeps ("the cloud"). > We run the much-upgraded descendants of the simplest, stupidest, and most boring computer that anyone could get to market. They were the easiest to build and to get working. Unsaid here is I think where we really got on the fixed path, is what begat honogenization. Everyone else seemed to have been competing to build better hardware+software+peripheral systems against everyone else (with some close alliances here and there). 1989 changed everything. The EISA bus was the reformation of a thousand different competing computing industries into a vaster cohesive competitive ecosystem, via the Gang of Nine. https://en.wikipedia.org/wiki/Extended_Industry_Standard_Architecture#The_Gang_of_Nine https://en.wikipedia.org/wiki/Extended_Industry_Standard_Arc... . This commodified what used to be closed systems. Everyone either adapted to the homogenized common systems, or, one by one, the DECs and Suns and every other computer maker folded or got sold off. The business model, to me, defines what happened. Giving up on being proprietary, giving up on controlling "your" ecosystem was the hinge point. Computing was boutique and special systems, competing on unique and distinct features and capabilities. With the rise of interchangable computing parts it transitioned to a more collaborative & much more competitive system. Distinction carried the risk of being too far afield, of your stuff not being compatible with the others. You had to play in the big tent. Versus all the other upstarts playing against you. Meanwhile the legacy featureful unique & distinct business-model players never could get enough market share to survive, could certainly never compete downmarket, and slowly has positions eroded up and up market until those last upmarket places collapsed too. The love of lisp here has many of the same pitfalls. Sure it's an elegant modifiable system, one that can be shaped like a bonsai tree into distinct and beautiful forms. And I hope we see the rise, I hope very much, that we make software soft again, that big overarching ideas of cohesive computing where OS and apps and user's will blend together in dynamic fashion rise again. But the peril is disjointedness. The peril is a lack of cohesion, where different users have vastly different bespoke systems and commonality is lost. I'm tempted to stop here while I've said little that feels controversial. Putting in anything people dont want to hear risks the greater message, which is that the new ways could arise via many many means. But, I do think: the brightest most malleable most user controlled system we have is the web. Userscripts are very powerful, and they grant us power over disjointed chaotic industrial systems, which have no desire to let the user shape anything. I believe that, with a little effort, with tools already available like web components, we can build very sympathetic forms of computing. HTML like LISP can make visible and make manifest all the components pieces of computing, can be an S-expr like system, as we see with modern front-end-derived router technology for example. The whole web might not be terraformed in our lifetimee, we might not dislodge the contemporary industrial web practices to make all the web excellent, but I think many stable wonderful media forms that spread and interoperate can take root here, I think they already resemble the alive system of the gods the author so nicely speaks to. I too speak, for malleable systems everywhere (not mine but https://malleable.systems https://malleable.systems ), and for the web as one conduit to bring us closer to the gods.
facialwipe 3y ago
After reading 30% of the article, it became clear to me that the author has probably never created a GitHub account.
- lproven 3y ago
  You didn't look very hard. https://github.com/lproven https://github.com/lproven
- mtrower 3y ago
  I’d be interested to hear how you reached that conclusion, and what that conclusion is meant to imply.
  - facialwipe 3y ago
    This ridiculous paragraph: “Now Lisp and Smalltalk are just niche languages – but once, both of them were whole other universes. Full-stack systems, all live, all dynamic, all editable on the fly. The closest thing we have today is probably JavaScript apps running in web browsers, and they are crippled little things by comparison.”
    - p_l 3y ago
      ... And what's untrue about it? I have tasted development on Smalltalk, with Common Lisp on modern tools, and even with Symbolics Genera 8.3/8.5. The kind of environment they provide pretty much by default an environment that at best you're going to have to bring with yourself in case of JS - in case of modern Lisp, it's usually a matter of installing an IDE plugin first though, but commercial stuff comes with IDEs as well. The best of "built in" support for JS in browsers pales in comparison to what was one mouse click away under Genera. Similarly most desktop/server environments except niche ones (Erlang ones? modern Lisps, Smalltalks). Even the better parts of less capable language tooling is often overlooked (advanced debugger support in things like Visual Studio, etc.) That paragraph is nowhere near ridiculous to anyone who actually used the tools, even if they agree with the dissenting voice about NT with (D)COM that was written on symbolics lisp user groups ~1995 - because the process described there is also now often disregarded unless one develops exclusively for Windows.
ashton314 3y ago
The description of Lisp machines sounds a lot like running Emacs in a way. Is Emacs… just a Lisp machine emulator?! (There is a lot I dislike about Emacs Lisp; there is a lot of power in it though. :)
- marcosdumay 3y ago
  It's a Lisp interpreter that happens to come with a text editor. I guess you can replace the text editing default skin, but I never tried it.
- pandaman 3y ago
  Emacs predates Lisp machines, but a version of Emacs was written in Lisp and used there (EINE[1]). The point of a Lisp machine was that it ran Lisp natively or, at least, closer to native than, say, a 8086 DOS box. 1. https://en.wikipedia.org/wiki/EINE_and_ZWEI https://en.wikipedia.org/wiki/EINE_and_ZWEI
  - lispm 3y ago
    EINE was the second Emacs (the first was TECO EMACS, an Emacs written in TECO macros) and EINE was the first one to be (completely) written in Lisp, on a GUI-based system.
- mtrower 3y ago
  In some sense, you might consider it to be a crude one. If you configure your computer to boot directly into full screen emacs, never leave it, and do your damndest to interact only with in-process elisp, you might get some feel for what such a machine could be like. It will also be a frustrating experience, since emacs was never really intended to be used in such a way. There’s going to be a lot of friction and limitations. Still, it’s a fun exercise for the right sort of person :)
  - DonHopkins 3y ago
    You've just described the user interface to every cloud server I use. 0) ssh to server 1) run screen -RD 2) run user emacs in one screen, run user shells in emacs 3) run root emacs in another screen, run root shells in emacs 4) run top in another screen 5) run nvitop in another screen on gpu servers 6) try to remember not to leave tail -f foo.log running in any shells or server explodes after six months
hkgjjgjfjfjfjf 3y ago
[dead]
amadeuspagel 3y ago
Is this "Worse is Better", but in the snarky and obnoxious style of The Register?
- LeoPanthera 3y ago
  The answer to this is in the article.
msh 3y ago
I think the author confused lowest bidder with producing something people could afford. For all their weaknesses micro's could be purchased by normal people. You could not produce a lisp machine or alto equalent in the 80' that it was possible to afford for regular people.
- ta988 3y ago
  And Lisp machines were extremely complicated to use. Every time I see one at Vintage computer conventions I am reminded that.
  - lispm 3y ago
    Slightly more complex than the UI of something like GNU Emacs, but with a better user interface. Keep in mind that not that many machines ever existed, I would think around 10000 -> thus the UI was less polished, but more capable. It's definitely more difficult, because it does not look&feel like common other user interfaces (say, the Desktop Metaphor used by Apple and others), plus it lacks a few decades improvements.
  - dreamcompiler 3y ago
    They were complicated to use but they were also self-teaching. I learned how to use a Lisp machine by sitting in front of one and trying things. By the end of a week I was fluent. And this was before the Internet; there was no Google. The machine itself contained all the docs and tutorials you needed to learn it. This was a remarkable achievement. Once you learned it you felt like a god because of the abilities the machine gave you. Some degree of learning curve was more than acceptable for that kind of power.
    - DonHopkins 3y ago
      And once you let the Lisp Machine teach you everything about itself, you had superhuman abilities! One of my favorite Lisp Machine stories (I've fixed dead links to point to archive dot org, and archived the file from stanford's ftp to my https server): https://news.ycombinator.com/item?id=30812434 https://news.ycombinator.com/item?id=30812434 Reposting this from the 2014 HN discussion of "Ergonomics of the Symbolics Lisp Machine": https://news.ycombinator.com/item?id=7878679 https://news.ycombinator.com/item?id=7878679 http://lispm.de/symbolics-lisp-machine-ergonomics http://lispm.de/symbolics-lisp-machine-ergonomics https://news.ycombinator.com/item?id=7879364 https://news.ycombinator.com/item?id=7879364 eudox on June 11, 2014 Related: A huge collections of images showing Symbolics UI and the software written for it: https://web.archive.org/web/20201216064308/http://lispm.de/symbolics-ui-examples/symbolics-ui-examples.html https://web.archive.org/web/20201216064308/http://lispm.de/s... ... agumonkey on June 11, 2014 Nice, but I wouldn't confuse static images with the underlying semantic graph of live objects that's not visible in pictures. DonHopkins on June 14, 2014 Precisely! When Lisp Machine programmer look at a screen dump, they see a lot more going on behind the scenes than meets the eye. I'll attempt to explain the deep implications of what the article said about "Everything on the screen is an object, mouse-sensitive and reusable": There's a legendary story about Gyro hacking away on a Lisp Machine, when he accidentally trashed the function cell of an important primitive like AREF (or something like that -- I can't remember the details -- do you, Scott? Or does Devon just make this stuff up? ;), and that totally crashed the operating system. It dumped him into a "cold load stream" where he could poke around at the memory image, so he clamored around the display list, a graph of live objects (currently in suspended animation) behind the windows on the screen, and found an instance where the original value of the function pointer had been printed out in hex (which of course was a numeric object that let you click up a menu to change its presentation, etc). He grabbed the value of the function pointer out of that numeric object, poked it back into the function cell where it belonged, pressed the "Please proceed, Governor" button, and was immediately back up and running where he left off before the crash, like nothing had ever happened! Here's another example of someone pulling themselves back up by their bootstraps without actually cold rebooting, thanks to the real time help of the networked Lisp Machine user community: ftp://ftp.ai.sri.com/pub/mailing-lists/slug/900531/msg00339.html => https://donhopkins.com/home/SlugMailingList/msg00339.html https://donhopkins.com/home/SlugMailingList/msg00339.html (I archived the whole directory so you can follow the "Followups" links to read the whole discussion.) Also eudox posted this link: Related: A huge collections of images showing Symbolics UI and the software written for it: http://lispm.de/symbolics-ui-examples/symbolics-ui-examples.html http://lispm.de/symbolics-ui-examples/symbolics-ui-examples....
BaculumMeumEst 3y ago
> Software built with tweezers and glue is not robust, no matter how many layers you add. It's terribly fragile, and needs armies of workers constantly fixing its millions of cracks and holes. Dude, come on. I really don't think anyone who actually worked on a medium to large Lisp codebase would write something like this.
- Phiwise_ 3y ago
  The author of the linked blogpost, Mark Tarver, has spent over a decade developing his own pair of Lisp dialect and symbolic AI system, called "Shen" and "The Logic Lab".
  - agumonkey 3y ago
    I have no say in the matter but I think it's a matter of crowd and sociology rather than tools. I've seen people go into shock at the first mention of smalltalk. "Message not understood" they said. These languages are powerful weapons, for some it will allow creating suns, for other it will be a self damaging nuclear meltdown.
di4na 3y ago
One thing i think forgotten here, which actually is in the Worse is Better talk. But people tend to miss it. These ST and Lisps systems failed at another aspect. Reuse. The biggest change of the past 2 decades in software engineering compared to previous generations is the amount of reuse. It is tremendous. It is hard to talk of cause and effects here, but mostly this is due to the Internet. At this point, the vast majority of code running on any proprietary system is... Open source infrastructural packages. This condition a lot of the current ecosystem. You can only reuse code on systems in which said code runs well. As such, the Linux "stability" combined with x86 won, same as C and friends because of the tooling that made the code "portable". Yes i know. It is far from magically portable, but it is far more than full machine living image SmallTalk or Lisp like. As such, these "living code" are fundamentally evolutionary deadend. They are amazing but they cannot easily move to different machines and sharing parts of them is hard to separate from the rest of the living organism. On top of this, a lot of the elements to make this kind of machine works does necessitate deep in depth expertise. As the piece shows, the Newton is a pale copy of the goal because they did not have that knowledge in house nor the time (or money) to create it. Same thing all over the stack. A good efficient logger need deep expertise. Same for a good localization library. Same for a good set of graphic servers. Same for audio servers. Same for a http parser or a network library. A good regexp engine is knowledge knows by less than 10 people in the world probably. Once you realise that, you realise that at scale reuse is the only realistic way forward for software so ubiquitous as it is today. And that is how we got the current FOSS ecosystem, not because the code is better but because it would need too many licences to be manageable without breaking the bank in numbers of lawyers. Same thing for the Worse is Better. It works because it provides extension points and can adapt. Something the Lisp and SmallTalk machines fundamentally failed to provide. And that is something Richard Gabriel focuses on far more than the whole New Jersey schtick in his talk.
- deleted 3y ago
  [deleted]
- smackeyacky 3y ago
  Lisp and Smalltalk failed because it was near impossible to share the code. Living images are really hard to merge. Smallltalk did eventually get a fantastic solution for code sharing between living images (Envy/Developer) but by that stage it was too late. All that philosophical guff about “worse is better” had nothing to do with the practical ease of sharing files rather than a tangled mess of code that Lisp and Smalltalk encouraged. Sharing files is definitely not “worse” by any definition.
6stringmerc 3y ago
This is one angle of the history and I do think it is a useful and accurate representation for what it describes. My critique: This lacks context regarding the still ongoing conflict between terminals and functional workstations. Time and again there is a back and forth in the computing realm. Case in point - I was selling SaaS deployments of what had been traditionally an On-Premises large cost platform. Who gets control is, to me, fundamentally a more significant angle on the history and future of computing. Again, will AI be on your phone or via network sends to a Host? Cost is a factor but I believe quite downstream from how these decisions are truly reached at the time.
- api 3y ago
  Local and personal vs remote and centralized tends to follow the same pattern as hardware and OSes that this article describes. The wheel turns when the precious iteration gets complex and expensive. Cloud offered an escape hatch from the nightmare of Microsoft centric enterprise IT and expensive complicated on premise business applications, not to mention the awful bureaucracy of IT departments themselves. Now I get the sense that cloud has become complicated, expensive, and encrusted with hordes of consultants and vendors layered on top of vendors. A back to local anti-cloud movement has been brewing for a while but hasn’t quite boiled over. You’ll probably soon start seeing more and more articles about how much money a company saved by leaving cloud. … and the wheel will turn once again.
  - agumonkey 3y ago
    > Local and personal vs remote and centralized tends to follow the same pattern as hardware and OSes that this article describes. The wheel turns when the precious iteration gets complex and expensive. I've been looking for a name on such pattern, compression/diffusion based on cost, scale, market. It's so prevalent.
shrubble 3y ago
Things to add: Wirth's Oberon hardware and software a small but successful bit of software that was ported to many other architectures and the language remains influential. Also Apollo's DomainOS which had network transparency in the early 1990s
- eschaton 3y ago
  Domain/OS was the final name of the system, it was originally called Aegis and had network transparency in the early 1980s.
- DonHopkins 3y ago
  ITS (which Richard Gabriel discussed in his "Worse is Better" paper in relation to the "PC-loser-ing" problem in particular, and the "better" MIT school of design in general) had a network transparent file system in the 70's! https://en.wikipedia.org/wiki/Incompatible_Timesharing_System https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste... https://www.techopedia.com/definition/26097/incompatible-timesharing-system-its https://www.techopedia.com/definition/26097/incompatible-tim... Techopedia Explains Incompatible Timesharing System [...] The ITS OS was developed in late 1960s and continued to be used up to 1990 at MIT, and until 1995 at the Stacken Computer Club in Sweden. Some of the important technical features of ITS are as follows: The operating system contained the first device-independent graphics terminal output. The screen content was controlled using generic commands created by a program. The content was usually translated into a sequence of device-dependent characters defined by the terminal the programmer was using. Virtual devices were supported in software run in user processes called jobs. It provided inter-machine file system access and was the first OS to include this feature. It provided a sophisticated process management in which the processes were organized in a tree. Any process could be transparently frozen or restarted at any point in time. A highly advanced software interrupt facility was provided, which could operate asynchronously. It supported real-time and time-sharing operations, which worked simultaneously. [...] https://web.stanford.edu/class/cs240/old/sp2014/readings/worse-is-better.html#:~:text=The%20PC%20loser%2Ding%20problem%20occurs%20when%20a%20user%20program,user%20program%20must%20be%20saved https://web.stanford.edu/class/cs240/old/sp2014/readings/wor.... [...] Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,'' where ``loser'' is the affectionate name for ``user'' at MIT. [...]
lispm 3y ago
If one wants to read a description of the hard- and software of a Lisp Machine from the 1980s, here are two good and lengthy overviews of second and third generation systems. The first generation were the research prototypes developed at MIT: CONS and CADR. The Symbolics 3600 is an improvement (and a commercial offering) and the TI Explorer then already moved to higher integration incl. a special Microprocessor. Both operating systems were based on the original MIT Lisp OS. The TI Explorer from 1988 already supported Common Lisp, which Symbolics at that time also did. The Symbolics 3600 from 1983 ran ZetaLisp (aka Lisp Machine Lisp), a very object-oriented Lisp, using the Flavors object-system. Symbolics 3600 in 1983 The Symbolics 3600 was the first improved machine after Symbolics was founded, released in 1983. The first machine, the LM-2, was a re-packaged version of the MIT CADR. The 3600 was an improved design with 36bit architecture (plus 8 bit ECC). Typically a machine new would have cost around $100k in 1983. When the machine boots up, it says "Yes, master" on a LED display. It was very extensible with memory, color graphics, disks, tapes, network, printer, ... It had a console with special keyboard, mouse, high-res b&w screen and digital audio. A dedicated Motorola 68000 was the Front End Processor. The Symbolics 3600 Technical Summary from 1983 http://www.bitsavers.org/pdf/symbolics/3600_series/3600_TechnicalSummary_Feb83.pdf http://www.bitsavers.org/pdf/symbolics/3600_series/3600_Tech... A brochure for the machine: http://www.bitsavers.org/pdf/symbolics/brochures/3600_Jul83.pdf http://www.bitsavers.org/pdf/symbolics/brochures/3600_Jul83.... TI Explorer in 1988 The second overview is from TI and is from 1988, not long before they were quitting the market. There machine range was called TI Explorer, after licensing some technology from LMI (Lisp Machine, Inc.), another Lisp Machine company. TI had in 1988 already developed a Lisp Megachip, a 553k transistor 32bit CPU for running Lisp. The Chip design was done inhouse using a dozen Lisp Machines (including several from Symbolics). It was at the time one of the first CPUs of that complexity. The CPU had been financed by DARPA and one of the applications thought was adding a Compact Lisp Machine into a fighter plane, running an AI-based co-pilot, based on a large research project (Pilot's Associate). The TI Explorer itself used the NuBUS as extension bus. Their console was attached via a fiber-optic cable. The TI Explorer Technical Summary from 1988: http://www.bitsavers.org/pdf/ti/explorer/2243189-0001D_ExplTech_8-88.pdf http://www.bitsavers.org/pdf/ti/explorer/2243189-0001D_ExplT...
- DonHopkins 3y ago
civilized 3y ago
It's an interesting perspective but ultimately unsatisfying because it doesn't touch on basic questions it seems like anyone would think to ask. For example: from a hardware perspective, today's "microcomputer" hardware is vastly more powerful than the mainframes of old, is it not? The time when it was much less powerful was long ago. If the old philosophy is so vastly superior, what's stopping folks from recreating it in today's computing ecosystem?
- geocar 3y ago
  I kindof think that’s what private cloud is: mainframe-style workflows and architectures on (many) microcomputers.
- jdksmdbtbdnmsm 3y ago
  The article is comparing systems from the same or close time periods. To merely compare modern systems with systems from 30+ years ago ignores what happened in those 30 years, which is why your comment says so little.
  - civilized 3y ago
    It's also trying to suggest that that history explains the dominant computing paradigms today. I think that historically-driven thinking only goes so far when today's hardware is vastly more powerful than anything we used to have. Any paradigm that serves users better could be used on today's very capable hardware, and presumably it would be extremely attractive. So why does this article sound like moving to the old paradigm that it prefers is a lost cause? We're not at the end of history quite yet.
    - mtrower 3y ago
      Well, in my opinion, inertia is a dominant factor. There is an enormous amount of inertia present in the current systems and thought patterns. Redesigning the world from scratch while applying different principles is hard, especially when you need to catch up with 30 years of evolution and situational developments. The point of the article, I believe, is that the current set of principles underlying modern systems are not necessarily sacred and immutable. It does not follow that applying differing principles to today’s ecosystems, where current principles have metastasized, would be easy or even necessarily achievable.
II2II 3y ago
There is so much to unpack here, but I am going to focus upon one thing: interpretation. The recounting history aspect of the article coincides with my understanding of the history of computing. The point of victors writing the history is certainly valid. While this is not the case literally, their success has offered a sense of legitimacy to their versions of history. Our acceptance is also shaped by our own experiences, which will favour the victors simply because they gained our acceptance back in the day. Yet I also think that the "lowest bidders" interpretation is deeply flawed for two reasons. One reason is that the success of the successors was built upon making computing more affordable to a broader base of customers. That is to say that there is a lower end to the cost of a vacuum tube based computer, which is higher than the cost of a transistorized computer, which is higher than one based upon integrated circuits, which is higher than one based upon microprocessors. The goal at each stage isn't necessarily to be the lowest bidder, but it is to sell computers at a lower price point than the prior generation. The second issue is that customers rarely needed the best technology at the time. Such an ideal would force many adopters into bankruptcy. The real point is to adopt technology in a way that either to improve efficiency, improve accuracy, or enable them to do more. That does not necessarily imply they need the best technology. It does imply they need technology which balances a cost-benefit analysis. Good is often the enemy of the best because it does not strike that balance. In a sense, that suggests that the best is not actually the best (i.e. it fails on some criteria). Of course the real point of the article is that some technologies were delayed and some have never been adopted at a large scale. The delays were necessary, not just because they required more sophisticated software but because they required time to implement. To understand that you only need look at our mobile devices. We are over a decade into the introduction of the smartphone, yet the software has yet to reach the sophistication of software seen on traditional desktop computers. While some of this is due to shifting priorities and the challenges of adapting traditional interfaces to fit within new interfaces, part of it is also due to the effort required to port software that may have 20 years of development behind them to a new platform. The second crack at a problem may be easier, but it is not easy. As with the author, I have much disappointment in the paths not taken. Or, to be more accurate, the paths so rarely taken that the industry can, by in large, be considered to be striving towards homogeneity. While I have no real love for LISP[1], SmallTalk helped me to understand object oriented programming much more deeply. While I have never truly pursued them, other oddities helped me realize that there is a plurality of paths the technology could have followed (Oberon comes to mind). As for retrocomputing, I truly appreciate those who choose to document the history of computers. It has guided my understanding that what we have today is not a foregone conclusion, and that our pet technology may have taken a very different path (and, perhaps, a better path) if the various detours were followed through to their conclusion. That said, I also believe that the path we have followed is viewed with too much cynicism in the eyes of some. It would have been better to have more diversity in our toolkit, than to prefer one approach over another. [1] Okay, I'm weird. I love the syntax of LISP, brackets and all, while I can appreciate the benefits of functional programming. I simply haven't crossed the threshold to view it as a useful language, even in an abstract way.
anigbrowl 3y ago
Really outstanding article. The opening paragraphs did not hint at the depth to come; I'm happy I put in the time to read the whole thing. There were little bits I disagreed with or thought overly simplified, but on the whole a banger. This bit jumped outa t me: The language was called Dylan, which is short for Dynamic Language. It still exists as a FOSS compiler. Apple seems to have forgotten about it too, because it reinvented that wheel, worse, with Swift. Have a look. Dylan is amazing, and its SK8 IDE even more so (a few screenshots and downloads are left). Dylan is very readable, very high-level, and before the commercial realities of time and money prevailed, Apple planned to write an OS, and the apps for that OS, in Dylan. On investigating the screenshots, Dylan turned out to be remarkably reminiscent of Visual Basic - arguably another good design that has rather unfairly fallen by the wayside.
- DonHopkins 3y ago
  I was lucky enough to get the chance to play around with sk8 when I worked at Kaleida. It was absolutely amazing, totally reflective and introspective and browsable and editable and even graphically beautiful! I just wrote about it a month ago (plate of shrimp!!!): https://news.ycombinator.com/item?id=38406111 https://news.ycombinator.com/item?id=38406111 DonHopkins 31 days ago | parent | context | favorite | on: The Revival of Medley/Interlisp When I worked at Kaleida (a joint venture of IBM and Apple), I had the wonderful opportunity to play around with Sk8, which was amazing! It was kind of like Dylan and ScriptX, in that it was an object oriented dialect of Lisp/Scheme with a traditional infix expression syntax. But it also had wonderful graphics and multimedia support, and cool weird shaped windows, and you could point at and explore and edit anything on the screen, a lot like HyperCard. Q: What do you get when you cross Apple and IBM? A: IBM! https://en.wikipedia.org/wiki/SK8_(programming_language) https://en.wikipedia.org/wiki/SK8_(programming_language) >SK8 (pronounced "skate") was a multimedia authoring environment developed in Apple's Advanced Technology Group from 1988 until 1997. It was described as "HyperCard on steroids",[1] combining a version of HyperCard's HyperTalk programming language with a modern object-oriented application platform. The project's goal was to allow creative designers to create complex, stand-alone applications. The main components of SK8 included the object system, the programming language, the graphics and components libraries, and the Project Builder, an integrated development environment. [...] The SK8 Multimedia Authoring Environment: https://sk8.dreamhosters.com/sk8site/sk8.html https://sk8.dreamhosters.com/sk8site/sk8.html What is SK8? SK8 (pronounced "skate") is a multimedia authoring environment developed in Apple's Research Laboratories. Since 1990, SK8 has been a testbed for advanced research into authoring tools and their use, as well as a tool to prototype new ideas and products. The goal of SK8 has been to enable productivity gains for software developers by reducing implementation time, facilitating rapid prototyping, supporting cross platform development and providing output to multiple runtime environments including Java. SK8 can be used to create rich media tools and titles simply and quickly. It features a fully dynamic prototype-based object system, an English-like scripting language, a general containment- and renderer-based graphic system, and a full-featured development interface. SK8 was developed using Digitool's Macintosh Common Lisp. [...] Sk8 Users Guide: https://macintoshgarden.org/sites/macintoshgarden.org/files/manuals/SK8_0.9_User_Guide.pdf https://macintoshgarden.org/sites/macintoshgarden.org/files/... Lots more information discussion of Sk8 at this link -- I'll just include the first comment, but click for more: https://news.ycombinator.com/item?id=21846706 https://news.ycombinator.com/item?id=21846706 mikelevins on Dec 20, 2019 | parent | context | favorite | on: Interface Builder's Alternative Lisp Timeline (201... Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It also had some features meant to make it easier to generate small, fast artifacts--for example, it had a module system, and separately-compiled libraries, and a concept of "sealing" by which you could promise the compiler that certain things in the library would not change at runtime, so that certain kinds of optimizations could safely be performed. Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements. It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral. Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years. Alan Kay was around Apple then, and seemed to be interested in pretty much everything. Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered. Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS. Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.
PeterStuer 3y ago
I was around when our lab replaced Symbolics Lisp Machines with Sun workstations. Maybe this was a European (or non-US) thing, but non of the Lisp vendors had a built out worldwide distribution and service network, so buying and actually getting machines delivered was not a trivial undertaking. Once Sun did add the support for performant garbage collection that Lisp needed, the choice was clear. Local sales and service clenched the deal, and versatility and broader support were cherries on top. Then the whole lisp machine business collapsed so they weren't even a remote option anymore. A relatively short term later Suns where replaced by Apple Mackintoshs running Mac Common Lisp. MCL was a very decent Lisp environment, machinrs were cheap and by now used for much more than just programming. The next wave would have been PCs, which had far better support. Apple never seemed to understand that your work depended on your computer, and that driving to an Apple store to drop of your machine so you could hopefully pick it up again in 2 to 3 weeks was not a serious option. Meanwhile Dell and the likes offered cheap Next Business Day on-site service. But PC's for Lisp would be held back for a long time by Allegro cornering the PC Lisp market with a product that at the time felt inferior to MCL, while having very aggressive (phone) sales techniques and extremely high prices.
anovikov 3y ago
Well the mainframes never went away. I know a guy - he's now retired but i knew him since 15 years back when he was very active in development - who was a mainframe programmer in banking all his career - and he is the happiest developer i knew. In that industry, the entire stack is coherent and stable, and exists to get things done, not to confuse or bullshit people into infinite rewriting into next shiny framework. There's always a budget to get things done properly, clients know what can be done and what can't. Everything is conservative and things really get delivered, and work in production, in time and on budget, and that ecosystem appears to select people who are able and willing to work that way, not "move fast and break things". And, he retired rich, never doing anything but actual coding for money. But of course, i could never break into things like that because it's not built with people with ADHD and no formal educational credentials in mind, to say the least. That's real business, not hippie hackspace.

174 points by lproven 3y ago

kens 3y ago

This is a very interesting article on computer history. There's a lot that I disagree with, though...

lproven 3y ago
Like I said above -- please do read my earlier comments -- I'd love to hear what, and why.

tyingq 3y ago

There's a lot that rings true here, but the article keeps noting that the IBM PC won partially because it was cheap. That's only true versus the examples the authors cite. In the business space, it was pretty expensive when compared to, for example, business oriented Z80/CPM platforms. And it was very expensive compared to the variety of home 8-bit choices. There were a lot of different markets/niches at the time, and things changed quickly, so it's hard to distill the history into soundbites about what happened and why.

lproven 3y ago
Not quite. Firstly, re predecessors: DOS was a lot more capable than CP/M-80 and any 8-bit systems. It displaced them for much the same reasons x86-64 displaced x86-32: it became affordable to have lots of RAM. In the early 1980s, 8080/Z80 couldn't handle >64kB without clunky paging. Some 25Y later, x86-32 couldn't handle >4GB without clunky paging, in much the same way. Secondly, re the PC's cheapness. I'd argue the PC was cheap for a business machine, but it's not simply that the PC hardware was cheap, but the bigger point that the bundle of the cheap machine and the cheap OS is what won out. The PC launched with 3 OSes: PC DOS, the UCSD p-System (a self-hosted Pascal IDE based on a JVM-like environment), and DR's CP/M-86. MS-DOS was about ¼ of the price of the other offerings. DR had an amazing comeback planned: it added the multitasking of MP/M to CP/M-86, creating Concurrent CP/M, then bolted on MS-DOS emulation, to create a multitasking OS that could run and multitask MS-DOS apps on a 286: Concurrent DOS (CDOS for short). It also had a multitasking version of the GEM GUI called X/GEM. This is something even the later OS/2 1.x couldn't do, and of course OS/2 1.0 didn't have a GUI at all. But CDOS/286 depended on a feature of the development versions of the 80286 which Intel removed from the final shipping version. So, when IBM launched the first 286 PC, CDOS didn't work. Intel put the hardware feature back but it was too late: the OS had been killed at birth -- it didn't work on shipping 286 kit. Only native apps multitask. DR had a fallback plan: it promoted CDOS as a realtime OS and made a living for years afterwards, but the big product to outdo DOS, which originated as a clone of DR's CP/M anyway, was thwarted. So it's not just "the PC was cheap", no. It's bigger than that. It's: * On the business desktop, the PC was cheap, _and_ the dominant PC OS was cheap, and the PC was built from open COTS parts and ran a COTS OS so was cheap to clone. * In academia and research, UNIX on mostly-COTS hardware killed off elaborate proprietary OSes on proprietary hardware. While PCs used x86, ST-506 and then ESDI and then IDE disks, ISA slot cards, etc., workstations used fancy 32-bit CPUs on fancy buses like NuBUS, VMEbus, and so on, with SCSI storage... and later moved to RISC chips with fancy buses and SCSI. This killed off proprietary non-open non-standard OSes such as VMS, Apollo DomainOS, and other exotica. Meanwhile, in business, DOS killed DR and the p-System and all the eight-bits. Later, Windows killed all the 16-bit GUI machines, except the Mac, which only survived by self-destroying and becoming a Unix machine.
- akira2501 3y ago
  > ISA slot cards This was actually bigger than I think people remember. IBM gave away all the information on their bus standard immediately. They clearly understood they had to create a robust third party add on market for the PC and this would be key to driving the platform. They were not wrong.
  - FirmwareBurner 3y ago
    They were not wrong in terms of what had to be done to make the OC platform the dominant one, except they didn't get to profit from the PC business for too long. The openness "mistake" is what Apple fought to avoid.
    - toyg 3y ago
      And Apple almost died because of that opposition to openness. They only returned to profitability once they promised to be as open as everyone else: having intel processors and a standard Unix userland. (They then got filthy rich by effectively pivoting to portable computing, a world where openness and standardization were never essential.)
      - lmm 3y ago
        > And Apple almost died because of that opposition to openness. They only returned to profitability once they promised to be as open as everyone else: having intel processors and a standard Unix userland. Not really. The brief time when they allowed what we would now call "hackintoshes" was when they came closest to dying. They adopted intel processors for cost reasons, but went out of their way to keep their system "different". (And IIRC that was after they'd recovered to healthy profitability on the back of the iMacs and iPod)
      - qwytw 3y ago
        > They only returned to profitability once they promised to be as open as everyone else: having intel They were profitable in the early 2000s with PowerPC and they probably would've stayed on it had it remained competitive with Intel.

snakeyjake 3y ago

LISP fetishism must be resisted every time it appears. Programmers who learn LISP and think they have become enlightened are no different than drunks who ramble on about how it is impossible to know if the colors they see are the same as the colors you see.

Phiwise_ 3y ago
It's a strange sort of Lisp fetishism that wants to bring back Smalltalk instead of Lisp.
- lproven 3y ago
  Exactly! :-)
lproven 3y ago
I'm not a Lisp fetishist and I personally find it nearly as unreadable as Perl and APL. The article is in fact expressing my admiration of Dylan, if you look more closely, and Smalltalk and other things of that ilk. Lisp was a tremendously important step... In 1959. They should have continued with the planned Lisp-2, but they didn't, and sadly, McCarthy is dead now. In its absence, Dylan is about the best candidate for a Lisp-2 we have.
- agumonkey 3y ago
  As a somehow lisp head, and even though I mellowed with time, especially about syntax, I still don't think there's anything wrong with sexps. It might be a neurological trait, some people just can't live with a syntactic layer.. their brain might rejoy with it, think clearer and faster. I, for one, is the opposite, it removes one dimension in the problem space, and structural edition is so cute. I also have a tiny personal bet that in 30 years, if people are still writing code.. someone will make sexps mainstream.. just like closures are now, just like tree processing / ast / transpiling is mainstream now.. it just take time to cook the mainstream.
  - 3y ago

avidphantasm 3y ago

So computers should’ve stayed expensive and inaccessible to most people. Yeah, that’s how markets grow.

lproven 3y ago
That is not only not right, that is not even wrong. It's not even a misinterpretation of what I was saying. It's like taking the first letter of each line, spell checking it until it reads as English somehow, and disagreeing with the result! I am saying we shouldn't have done it the cheap way. We should have done it the best way when it was visible what was the better but more expensive way. Because that is what we must do know, but it's going to be much harder and much more expensive now because we need to replace 30+ years of accumulated useless cruft, while staying interoperable with it throughout.
- avidphantasm 3y ago
  You’re not wrong, it’s just not how technology tends to develop. We always go with “good enough for now.” Even if some people understand in the moment that there is a better way, there is always a tension between goal and subgoal pursuit. Usually, developing IT systems is the subgoal to the domain goal. Once the IT system is “good enough” to accomplish the domain goal, we move on.
  - lproven 3y ago
    > We always go with “good enough for now.” The whole point of the piece is that not everyone does this and there are plentiful counter-examples, and while they never took over the mainstream, they have survived for decades despite going against the flow. I can say this with authority because I wrote the article, and delivered the original talk upon which it's based.

Phiwise_ 3y ago

Glad to see you're still fighting the good fight on this one, lproven. If anyone finds this interesting, Liam has three great fosdem lectures out introducing this topic from the perspective of business software dev, hardware tech, and open source. I found the first after reading The Unix-Haters Handbook, and as much as I like its style Proven's videos are broader and up-to-date, so much better for learning: The Circuit Less Traveled: https://news.ycombinator.com/item?id=16309195 https://news.ycombinator.com/item?id=16309195 Generation Gaps; a heretical history of computing: https://news.ycombinator.com/item?id=22265615 https://news.ycombinator.com/item?id=22265615 Starting Over; a FOSS propisal for a new type of OS for a new type of computer: https://news.ycombinator.com/item?id=26066762 https://news.ycombinator.com/item?id=26066762 I also coincidentally found what might be the only good video about the Apple Newton on the internet today (although with the state of google search it's impossible to know outside of youtube). It makes a great supplement to the discussion of breaking the mold of OS conventions: https://www.youtube.com/watch?v=5kxRi34PqWo https://www.youtube.com/watch?v=5kxRi34PqWo The channel also has full interviews used in the dicumentary. I haven't seen the newest one, but it's two hours with a Mac and Newton architect so it's probably great: https://www.youtube.com/watch?v=KsaGx0loR3M https://www.youtube.com/watch?v=KsaGx0loR3M

lproven 3y ago
Oh, thank you! :-) That was a very pleasant Newtonmas surprise to read! :-D Yes, the core of this article was adapted -- with my editors' full knowledge and agreement, of course -- from one of my FOSDEM talks. I plan to return with some more of the talk -- and some new stuff! -- in later pieces. Sadly, the FOSDEM organisers did not accept my proposal for a talk this year. Ah well.
- DonHopkins 3y ago
  I started reading the article, and it was making so much sense that I scrolled back up to the top to see if you wrote it, and you did! So I came here to say I really love your work because you really get the big picture and do your research, but somebody beat me to it, dammit! After recently watching that depressing trending four hour youtube video about psychopathic plagiarizing charlatans, it's really refreshing and uplifting to read something original that's so well researched with great citations. I hope you don't get plagiarized too, but if you do, consider it the highest form of flattery.

e-dant 3y ago

I wonder if there’s room for a theory of convergent evolution, in software and languages, towards something that is generally appreciated. Maybe there will always be camps arguing for one thing or another, but together and over the longest term, do they all pull in one general direction? I’m not so sure I agree with most of the article. The perspective is valuable.

lproven 3y ago
> towards something that is generally appreciated. I think it's simpler than that. It's convergence to the lowest common denominator. The simplest implementation of the simplest thing that does the job, in the simplest easiest language that is capable of it. But because "simple" can be taken to extremes of very clever but abstruse tools that only near-genius level minds can use effectively, and those folks do not work well together, what ends up cheap at first is the simple easy thing that is simple and easy to get working. Lisp might be arguably simpler in a theoretical sense but for a lot of ordinary folks it's just too weird and too hard. APL is "simple" inasmuch as a hundred lines of nested loops can be written as one line of a dozen hieroglyphics that does the same task in one operation... but there are only a few hundred people on the planet that can read it. C is a simple tool for simple computers but you can pick it up and learn how to use it with just a book and some time. It's fiddly and hard to do anything clever which means programmer must do grug brain stuff. https://grugbrain.dev/ https://grugbrain.dev/ And that means others can follow it, and work with it, and that means teams scale. Not very well but a bit. So companies can hire rooms full of grugs and make it work. Result, fairly simple dumb tool beats clever fancy more capable tool. Result, people who like the dumb tool have strength of numbers and they mock the speccy nerdy weirdos who like the weird tool. Which is fine until you end up with a million programs built from a million lines of C each and a million techies trying to get them to work together. Then you end up with an industry that makes billions of dollars a month, selling billions of lines of code that nobody understands, and hundreds of thousands of people trying to prop it up and keep it working. By that point it becomes clear that you should have employed a dozen geniuses to do it in a few thousand lines of the weird nerdy tool. You'd have ended up with something smaller and simpler and easier to maintain, and even the paycheques of the dozen geniuses would be less than the paycheques of a thousand grug brain developers. But it's too late. The geniuses retired or went off to grow bonsai or something. All that's left is people who only know the grug brained methods. It is easy to believe it's some kind of elegant evolution of the best possible solution... but it's not really. It's lots and lots of the cheapest worst solution until everything else dies out. That is what I am trying to get at here. But I am always learning and I try hard to be open minded. If you have specific point by point rebuttals, I'd love to read them!

jauntywundrkind 3y ago

> The story about evolution is totally wrong. What really happened is that, time after time, each generation of computers developed until it was very capable and sophisticated, and then it was totally replaced by a new generation of relatively simple, stupid ones. Then those were improved, usually completely ignoring all the lessons learned in the previous generation, until the new generation gets replaced in turn by something smaller, cheaper, and far more stupid. Beautifully said. But for the last couple decades not even that is true. It's just been more and more of the same OSes, doing basically the same things. What it means to develop a native app is pretty fundamentally unchanged since Windows 3.11 or ISX days. Software has changed, but only neo-mainframes. All the groupware and multi-tenant and scale-out software systems the author decries as lost? Rebuilt as online systems, powered by communicative capitalism and vast data-keeps ("the cloud"). > We run the much-upgraded descendants of the simplest, stupidest, and most boring computer that anyone could get to market. They were the easiest to build and to get working. Unsaid here is I think where we really got on the fixed path, is what begat honogenization. Everyone else seemed to have been competing to build better hardware+software+peripheral systems against everyone else (with some close alliances here and there). 1989 changed everything. The EISA bus was the reformation of a thousand different competing computing industries into a vaster cohesive competitive ecosystem, via the Gang of Nine. https://en.wikipedia.org/wiki/Extended_Industry_Standard_Architecture#The_Gang_of_Nine https://en.wikipedia.org/wiki/Extended_Industry_Standard_Arc... . This commodified what used to be closed systems. Everyone either adapted to the homogenized common systems, or, one by one, the DECs and Suns and every other computer maker folded or got sold off. The business model, to me, defines what happened. Giving up on being proprietary, giving up on controlling "your" ecosystem was the hinge point. Computing was boutique and special systems, competing on unique and distinct features and capabilities. With the rise of interchangable computing parts it transitioned to a more collaborative & much more competitive system. Distinction carried the risk of being too far afield, of your stuff not being compatible with the others. You had to play in the big tent. Versus all the other upstarts playing against you. Meanwhile the legacy featureful unique & distinct business-model players never could get enough market share to survive, could certainly never compete downmarket, and slowly has positions eroded up and up market until those last upmarket places collapsed too. The love of lisp here has many of the same pitfalls. Sure it's an elegant modifiable system, one that can be shaped like a bonsai tree into distinct and beautiful forms. And I hope we see the rise, I hope very much, that we make software soft again, that big overarching ideas of cohesive computing where OS and apps and user's will blend together in dynamic fashion rise again. But the peril is disjointedness. The peril is a lack of cohesion, where different users have vastly different bespoke systems and commonality is lost. I'm tempted to stop here while I've said little that feels controversial. Putting in anything people dont want to hear risks the greater message, which is that the new ways could arise via many many means. But, I do think: the brightest most malleable most user controlled system we have is the web. Userscripts are very powerful, and they grant us power over disjointed chaotic industrial systems, which have no desire to let the user shape anything. I believe that, with a little effort, with tools already available like web components, we can build very sympathetic forms of computing. HTML like LISP can make visible and make manifest all the components pieces of computing, can be an S-expr like system, as we see with modern front-end-derived router technology for example. The whole web might not be terraformed in our lifetimee, we might not dislodge the contemporary industrial web practices to make all the web excellent, but I think many stable wonderful media forms that spread and interoperate can take root here, I think they already resemble the alive system of the gods the author so nicely speaks to. I too speak, for malleable systems everywhere (not mine but https://malleable.systems https://malleable.systems ), and for the web as one conduit to bring us closer to the gods.

facialwipe 3y ago

After reading 30% of the article, it became clear to me that the author has probably never created a GitHub account.

lproven 3y ago
You didn't look very hard. https://github.com/lproven https://github.com/lproven
mtrower 3y ago
I’d be interested to hear how you reached that conclusion, and what that conclusion is meant to imply.
- facialwipe 3y ago
  This ridiculous paragraph: “Now Lisp and Smalltalk are just niche languages – but once, both of them were whole other universes. Full-stack systems, all live, all dynamic, all editable on the fly. The closest thing we have today is probably JavaScript apps running in web browsers, and they are crippled little things by comparison.”
  - p_l 3y ago
    ... And what's untrue about it? I have tasted development on Smalltalk, with Common Lisp on modern tools, and even with Symbolics Genera 8.3/8.5. The kind of environment they provide pretty much by default an environment that at best you're going to have to bring with yourself in case of JS - in case of modern Lisp, it's usually a matter of installing an IDE plugin first though, but commercial stuff comes with IDEs as well. The best of "built in" support for JS in browsers pales in comparison to what was one mouse click away under Genera. Similarly most desktop/server environments except niche ones (Erlang ones? modern Lisps, Smalltalks). Even the better parts of less capable language tooling is often overlooked (advanced debugger support in things like Visual Studio, etc.) That paragraph is nowhere near ridiculous to anyone who actually used the tools, even if they agree with the dissenting voice about NT with (D)COM that was written on symbolics lisp user groups ~1995 - because the process described there is also now often disregarded unless one develops exclusively for Windows.

ashton314 3y ago

The description of Lisp machines sounds a lot like running Emacs in a way. Is Emacs… just a Lisp machine emulator?! (There is a lot I dislike about Emacs Lisp; there is a lot of power in it though. :)

marcosdumay 3y ago
It's a Lisp interpreter that happens to come with a text editor. I guess you can replace the text editing default skin, but I never tried it.
pandaman 3y ago
Emacs predates Lisp machines, but a version of Emacs was written in Lisp and used there (EINE[1]). The point of a Lisp machine was that it ran Lisp natively or, at least, closer to native than, say, a 8086 DOS box. 1. https://en.wikipedia.org/wiki/EINE_and_ZWEI https://en.wikipedia.org/wiki/EINE_and_ZWEI
- lispm 3y ago
  EINE was the second Emacs (the first was TECO EMACS, an Emacs written in TECO macros) and EINE was the first one to be (completely) written in Lisp, on a GUI-based system.
mtrower 3y ago
In some sense, you might consider it to be a crude one. If you configure your computer to boot directly into full screen emacs, never leave it, and do your damndest to interact only with in-process elisp, you might get some feel for what such a machine could be like. It will also be a frustrating experience, since emacs was never really intended to be used in such a way. There’s going to be a lot of friction and limitations. Still, it’s a fun exercise for the right sort of person :)
- DonHopkins 3y ago
  You've just described the user interface to every cloud server I use. 0) ssh to server 1) run screen -RD 2) run user emacs in one screen, run user shells in emacs 3) run root emacs in another screen, run root shells in emacs 4) run top in another screen 5) run nvitop in another screen on gpu servers 6) try to remember not to leave tail -f foo.log running in any shells or server explodes after six months

hkgjjgjfjfjfjf 3y ago

[dead]

amadeuspagel 3y ago

Is this "Worse is Better", but in the snarky and obnoxious style of The Register?

LeoPanthera 3y ago
The answer to this is in the article.

msh 3y ago

I think the author confused lowest bidder with producing something people could afford. For all their weaknesses micro's could be purchased by normal people. You could not produce a lisp machine or alto equalent in the 80' that it was possible to afford for regular people.

ta988 3y ago
And Lisp machines were extremely complicated to use. Every time I see one at Vintage computer conventions I am reminded that.
- lispm 3y ago
  Slightly more complex than the UI of something like GNU Emacs, but with a better user interface. Keep in mind that not that many machines ever existed, I would think around 10000 -> thus the UI was less polished, but more capable. It's definitely more difficult, because it does not look&feel like common other user interfaces (say, the Desktop Metaphor used by Apple and others), plus it lacks a few decades improvements.
- dreamcompiler 3y ago
  They were complicated to use but they were also self-teaching. I learned how to use a Lisp machine by sitting in front of one and trying things. By the end of a week I was fluent. And this was before the Internet; there was no Google. The machine itself contained all the docs and tutorials you needed to learn it. This was a remarkable achievement. Once you learned it you felt like a god because of the abilities the machine gave you. Some degree of learning curve was more than acceptable for that kind of power.
  - DonHopkins 3y ago
    And once you let the Lisp Machine teach you everything about itself, you had superhuman abilities! One of my favorite Lisp Machine stories (I've fixed dead links to point to archive dot org, and archived the file from stanford's ftp to my https server): https://news.ycombinator.com/item?id=30812434 https://news.ycombinator.com/item?id=30812434 Reposting this from the 2014 HN discussion of "Ergonomics of the Symbolics Lisp Machine": https://news.ycombinator.com/item?id=7878679 https://news.ycombinator.com/item?id=7878679 http://lispm.de/symbolics-lisp-machine-ergonomics http://lispm.de/symbolics-lisp-machine-ergonomics https://news.ycombinator.com/item?id=7879364 https://news.ycombinator.com/item?id=7879364 eudox on June 11, 2014 Related: A huge collections of images showing Symbolics UI and the software written for it: https://web.archive.org/web/20201216064308/http://lispm.de/symbolics-ui-examples/symbolics-ui-examples.html https://web.archive.org/web/20201216064308/http://lispm.de/s... ... agumonkey on June 11, 2014 Nice, but I wouldn't confuse static images with the underlying semantic graph of live objects that's not visible in pictures. DonHopkins on June 14, 2014 Precisely! When Lisp Machine programmer look at a screen dump, they see a lot more going on behind the scenes than meets the eye. I'll attempt to explain the deep implications of what the article said about "Everything on the screen is an object, mouse-sensitive and reusable": There's a legendary story about Gyro hacking away on a Lisp Machine, when he accidentally trashed the function cell of an important primitive like AREF (or something like that -- I can't remember the details -- do you, Scott? Or does Devon just make this stuff up? ;), and that totally crashed the operating system. It dumped him into a "cold load stream" where he could poke around at the memory image, so he clamored around the display list, a graph of live objects (currently in suspended animation) behind the windows on the screen, and found an instance where the original value of the function pointer had been printed out in hex (which of course was a numeric object that let you click up a menu to change its presentation, etc). He grabbed the value of the function pointer out of that numeric object, poked it back into the function cell where it belonged, pressed the "Please proceed, Governor" button, and was immediately back up and running where he left off before the crash, like nothing had ever happened! Here's another example of someone pulling themselves back up by their bootstraps without actually cold rebooting, thanks to the real time help of the networked Lisp Machine user community: ftp://ftp.ai.sri.com/pub/mailing-lists/slug/900531/msg00339.html => https://donhopkins.com/home/SlugMailingList/msg00339.html https://donhopkins.com/home/SlugMailingList/msg00339.html (I archived the whole directory so you can follow the "Followups" links to read the whole discussion.) Also eudox posted this link: Related: A huge collections of images showing Symbolics UI and the software written for it: http://lispm.de/symbolics-ui-examples/symbolics-ui-examples.html http://lispm.de/symbolics-ui-examples/symbolics-ui-examples....

BaculumMeumEst 3y ago

> Software built with tweezers and glue is not robust, no matter how many layers you add. It's terribly fragile, and needs armies of workers constantly fixing its millions of cracks and holes. Dude, come on. I really don't think anyone who actually worked on a medium to large Lisp codebase would write something like this.

Phiwise_ 3y ago
The author of the linked blogpost, Mark Tarver, has spent over a decade developing his own pair of Lisp dialect and symbolic AI system, called "Shen" and "The Logic Lab".
- agumonkey 3y ago
  I have no say in the matter but I think it's a matter of crowd and sociology rather than tools. I've seen people go into shock at the first mention of smalltalk. "Message not understood" they said. These languages are powerful weapons, for some it will allow creating suns, for other it will be a self damaging nuclear meltdown.

di4na 3y ago

One thing i think forgotten here, which actually is in the Worse is Better talk. But people tend to miss it. These ST and Lisps systems failed at another aspect. Reuse. The biggest change of the past 2 decades in software engineering compared to previous generations is the amount of reuse. It is tremendous. It is hard to talk of cause and effects here, but mostly this is due to the Internet. At this point, the vast majority of code running on any proprietary system is... Open source infrastructural packages. This condition a lot of the current ecosystem. You can only reuse code on systems in which said code runs well. As such, the Linux "stability" combined with x86 won, same as C and friends because of the tooling that made the code "portable". Yes i know. It is far from magically portable, but it is far more than full machine living image SmallTalk or Lisp like. As such, these "living code" are fundamentally evolutionary deadend. They are amazing but they cannot easily move to different machines and sharing parts of them is hard to separate from the rest of the living organism. On top of this, a lot of the elements to make this kind of machine works does necessitate deep in depth expertise. As the piece shows, the Newton is a pale copy of the goal because they did not have that knowledge in house nor the time (or money) to create it. Same thing all over the stack. A good efficient logger need deep expertise. Same for a good localization library. Same for a good set of graphic servers. Same for audio servers. Same for a http parser or a network library. A good regexp engine is knowledge knows by less than 10 people in the world probably. Once you realise that, you realise that at scale reuse is the only realistic way forward for software so ubiquitous as it is today. And that is how we got the current FOSS ecosystem, not because the code is better but because it would need too many licences to be manageable without breaking the bank in numbers of lawyers. Same thing for the Worse is Better. It works because it provides extension points and can adapt. Something the Lisp and SmallTalk machines fundamentally failed to provide. And that is something Richard Gabriel focuses on far more than the whole New Jersey schtick in his talk.

deleted 3y ago
[deleted]
smackeyacky 3y ago
Lisp and Smalltalk failed because it was near impossible to share the code. Living images are really hard to merge. Smallltalk did eventually get a fantastic solution for code sharing between living images (Envy/Developer) but by that stage it was too late. All that philosophical guff about “worse is better” had nothing to do with the practical ease of sharing files rather than a tangled mess of code that Lisp and Smalltalk encouraged. Sharing files is definitely not “worse” by any definition.

6stringmerc 3y ago

This is one angle of the history and I do think it is a useful and accurate representation for what it describes. My critique: This lacks context regarding the still ongoing conflict between terminals and functional workstations. Time and again there is a back and forth in the computing realm. Case in point - I was selling SaaS deployments of what had been traditionally an On-Premises large cost platform. Who gets control is, to me, fundamentally a more significant angle on the history and future of computing. Again, will AI be on your phone or via network sends to a Host? Cost is a factor but I believe quite downstream from how these decisions are truly reached at the time.

api 3y ago
Local and personal vs remote and centralized tends to follow the same pattern as hardware and OSes that this article describes. The wheel turns when the precious iteration gets complex and expensive. Cloud offered an escape hatch from the nightmare of Microsoft centric enterprise IT and expensive complicated on premise business applications, not to mention the awful bureaucracy of IT departments themselves. Now I get the sense that cloud has become complicated, expensive, and encrusted with hordes of consultants and vendors layered on top of vendors. A back to local anti-cloud movement has been brewing for a while but hasn’t quite boiled over. You’ll probably soon start seeing more and more articles about how much money a company saved by leaving cloud. … and the wheel will turn once again.
- agumonkey 3y ago
  > Local and personal vs remote and centralized tends to follow the same pattern as hardware and OSes that this article describes. The wheel turns when the precious iteration gets complex and expensive. I've been looking for a name on such pattern, compression/diffusion based on cost, scale, market. It's so prevalent.

shrubble 3y ago

Things to add: Wirth's Oberon hardware and software a small but successful bit of software that was ported to many other architectures and the language remains influential. Also Apollo's DomainOS which had network transparency in the early 1990s

eschaton 3y ago
Domain/OS was the final name of the system, it was originally called Aegis and had network transparency in the early 1980s.
DonHopkins 3y ago
ITS (which Richard Gabriel discussed in his "Worse is Better" paper in relation to the "PC-loser-ing" problem in particular, and the "better" MIT school of design in general) had a network transparent file system in the 70's! https://en.wikipedia.org/wiki/Incompatible_Timesharing_System https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste... https://www.techopedia.com/definition/26097/incompatible-timesharing-system-its https://www.techopedia.com/definition/26097/incompatible-tim... Techopedia Explains Incompatible Timesharing System [...] The ITS OS was developed in late 1960s and continued to be used up to 1990 at MIT, and until 1995 at the Stacken Computer Club in Sweden. Some of the important technical features of ITS are as follows: The operating system contained the first device-independent graphics terminal output. The screen content was controlled using generic commands created by a program. The content was usually translated into a sequence of device-dependent characters defined by the terminal the programmer was using. Virtual devices were supported in software run in user processes called jobs. It provided inter-machine file system access and was the first OS to include this feature. It provided a sophisticated process management in which the processes were organized in a tree. Any process could be transparently frozen or restarted at any point in time. A highly advanced software interrupt facility was provided, which could operate asynchronously. It supported real-time and time-sharing operations, which worked simultaneously. [...] https://web.stanford.edu/class/cs240/old/sp2014/readings/worse-is-better.html#:~:text=The%20PC%20loser%2Ding%20problem%20occurs%20when%20a%20user%20program,user%20program%20must%20be%20saved https://web.stanford.edu/class/cs240/old/sp2014/readings/wor.... [...] Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,'' where ``loser'' is the affectionate name for ``user'' at MIT. [...]

lispm 3y ago

If one wants to read a description of the hard- and software of a Lisp Machine from the 1980s, here are two good and lengthy overviews of second and third generation systems. The first generation were the research prototypes developed at MIT: CONS and CADR. The Symbolics 3600 is an improvement (and a commercial offering) and the TI Explorer then already moved to higher integration incl. a special Microprocessor. Both operating systems were based on the original MIT Lisp OS. The TI Explorer from 1988 already supported Common Lisp, which Symbolics at that time also did. The Symbolics 3600 from 1983 ran ZetaLisp (aka Lisp Machine Lisp), a very object-oriented Lisp, using the Flavors object-system. Symbolics 3600 in 1983 The Symbolics 3600 was the first improved machine after Symbolics was founded, released in 1983. The first machine, the LM-2, was a re-packaged version of the MIT CADR. The 3600 was an improved design with 36bit architecture (plus 8 bit ECC). Typically a machine new would have cost around $100k in 1983. When the machine boots up, it says "Yes, master" on a LED display. It was very extensible with memory, color graphics, disks, tapes, network, printer, ... It had a console with special keyboard, mouse, high-res b&w screen and digital audio. A dedicated Motorola 68000 was the Front End Processor. The Symbolics 3600 Technical Summary from 1983 http://www.bitsavers.org/pdf/symbolics/3600_series/3600_TechnicalSummary_Feb83.pdf http://www.bitsavers.org/pdf/symbolics/3600_series/3600_Tech... A brochure for the machine: http://www.bitsavers.org/pdf/symbolics/brochures/3600_Jul83.pdf http://www.bitsavers.org/pdf/symbolics/brochures/3600_Jul83.... TI Explorer in 1988 The second overview is from TI and is from 1988, not long before they were quitting the market. There machine range was called TI Explorer, after licensing some technology from LMI (Lisp Machine, Inc.), another Lisp Machine company. TI had in 1988 already developed a Lisp Megachip, a 553k transistor 32bit CPU for running Lisp. The Chip design was done inhouse using a dozen Lisp Machines (including several from Symbolics). It was at the time one of the first CPUs of that complexity. The CPU had been financed by DARPA and one of the applications thought was adding a Compact Lisp Machine into a fighter plane, running an AI-based co-pilot, based on a large research project (Pilot's Associate). The TI Explorer itself used the NuBUS as extension bus. Their console was attached via a fiber-optic cable. The TI Explorer Technical Summary from 1988: http://www.bitsavers.org/pdf/ti/explorer/2243189-0001D_ExplTech_8-88.pdf http://www.bitsavers.org/pdf/ti/explorer/2243189-0001D_ExplT...

DonHopkins 3y ago

civilized 3y ago

It's an interesting perspective but ultimately unsatisfying because it doesn't touch on basic questions it seems like anyone would think to ask. For example: from a hardware perspective, today's "microcomputer" hardware is vastly more powerful than the mainframes of old, is it not? The time when it was much less powerful was long ago. If the old philosophy is so vastly superior, what's stopping folks from recreating it in today's computing ecosystem?

geocar 3y ago
I kindof think that’s what private cloud is: mainframe-style workflows and architectures on (many) microcomputers.
jdksmdbtbdnmsm 3y ago
The article is comparing systems from the same or close time periods. To merely compare modern systems with systems from 30+ years ago ignores what happened in those 30 years, which is why your comment says so little.
- civilized 3y ago
  It's also trying to suggest that that history explains the dominant computing paradigms today. I think that historically-driven thinking only goes so far when today's hardware is vastly more powerful than anything we used to have. Any paradigm that serves users better could be used on today's very capable hardware, and presumably it would be extremely attractive. So why does this article sound like moving to the old paradigm that it prefers is a lost cause? We're not at the end of history quite yet.
  - mtrower 3y ago
    Well, in my opinion, inertia is a dominant factor. There is an enormous amount of inertia present in the current systems and thought patterns. Redesigning the world from scratch while applying different principles is hard, especially when you need to catch up with 30 years of evolution and situational developments. The point of the article, I believe, is that the current set of principles underlying modern systems are not necessarily sacred and immutable. It does not follow that applying differing principles to today’s ecosystems, where current principles have metastasized, would be easy or even necessarily achievable.

II2II 3y ago

There is so much to unpack here, but I am going to focus upon one thing: interpretation. The recounting history aspect of the article coincides with my understanding of the history of computing. The point of victors writing the history is certainly valid. While this is not the case literally, their success has offered a sense of legitimacy to their versions of history. Our acceptance is also shaped by our own experiences, which will favour the victors simply because they gained our acceptance back in the day. Yet I also think that the "lowest bidders" interpretation is deeply flawed for two reasons. One reason is that the success of the successors was built upon making computing more affordable to a broader base of customers. That is to say that there is a lower end to the cost of a vacuum tube based computer, which is higher than the cost of a transistorized computer, which is higher than one based upon integrated circuits, which is higher than one based upon microprocessors. The goal at each stage isn't necessarily to be the lowest bidder, but it is to sell computers at a lower price point than the prior generation. The second issue is that customers rarely needed the best technology at the time. Such an ideal would force many adopters into bankruptcy. The real point is to adopt technology in a way that either to improve efficiency, improve accuracy, or enable them to do more. That does not necessarily imply they need the best technology. It does imply they need technology which balances a cost-benefit analysis. Good is often the enemy of the best because it does not strike that balance. In a sense, that suggests that the best is not actually the best (i.e. it fails on some criteria). Of course the real point of the article is that some technologies were delayed and some have never been adopted at a large scale. The delays were necessary, not just because they required more sophisticated software but because they required time to implement. To understand that you only need look at our mobile devices. We are over a decade into the introduction of the smartphone, yet the software has yet to reach the sophistication of software seen on traditional desktop computers. While some of this is due to shifting priorities and the challenges of adapting traditional interfaces to fit within new interfaces, part of it is also due to the effort required to port software that may have 20 years of development behind them to a new platform. The second crack at a problem may be easier, but it is not easy. As with the author, I have much disappointment in the paths not taken. Or, to be more accurate, the paths so rarely taken that the industry can, by in large, be considered to be striving towards homogeneity. While I have no real love for LISP[1], SmallTalk helped me to understand object oriented programming much more deeply. While I have never truly pursued them, other oddities helped me realize that there is a plurality of paths the technology could have followed (Oberon comes to mind). As for retrocomputing, I truly appreciate those who choose to document the history of computers. It has guided my understanding that what we have today is not a foregone conclusion, and that our pet technology may have taken a very different path (and, perhaps, a better path) if the various detours were followed through to their conclusion. That said, I also believe that the path we have followed is viewed with too much cynicism in the eyes of some. It would have been better to have more diversity in our toolkit, than to prefer one approach over another. [1] Okay, I'm weird. I love the syntax of LISP, brackets and all, while I can appreciate the benefits of functional programming. I simply haven't crossed the threshold to view it as a useful language, even in an abstract way.

anigbrowl 3y ago

Really outstanding article. The opening paragraphs did not hint at the depth to come; I'm happy I put in the time to read the whole thing. There were little bits I disagreed with or thought overly simplified, but on the whole a banger. This bit jumped outa t me: The language was called Dylan, which is short for Dynamic Language. It still exists as a FOSS compiler. Apple seems to have forgotten about it too, because it reinvented that wheel, worse, with Swift. Have a look. Dylan is amazing, and its SK8 IDE even more so (a few screenshots and downloads are left). Dylan is very readable, very high-level, and before the commercial realities of time and money prevailed, Apple planned to write an OS, and the apps for that OS, in Dylan. On investigating the screenshots, Dylan turned out to be remarkably reminiscent of Visual Basic - arguably another good design that has rather unfairly fallen by the wayside.

DonHopkins 3y ago
I was lucky enough to get the chance to play around with sk8 when I worked at Kaleida. It was absolutely amazing, totally reflective and introspective and browsable and editable and even graphically beautiful! I just wrote about it a month ago (plate of shrimp!!!): https://news.ycombinator.com/item?id=38406111 https://news.ycombinator.com/item?id=38406111 DonHopkins 31 days ago | parent | context | favorite | on: The Revival of Medley/Interlisp When I worked at Kaleida (a joint venture of IBM and Apple), I had the wonderful opportunity to play around with Sk8, which was amazing! It was kind of like Dylan and ScriptX, in that it was an object oriented dialect of Lisp/Scheme with a traditional infix expression syntax. But it also had wonderful graphics and multimedia support, and cool weird shaped windows, and you could point at and explore and edit anything on the screen, a lot like HyperCard. Q: What do you get when you cross Apple and IBM? A: IBM! https://en.wikipedia.org/wiki/SK8_(programming_language) https://en.wikipedia.org/wiki/SK8_(programming_language) >SK8 (pronounced "skate") was a multimedia authoring environment developed in Apple's Advanced Technology Group from 1988 until 1997. It was described as "HyperCard on steroids",[1] combining a version of HyperCard's HyperTalk programming language with a modern object-oriented application platform. The project's goal was to allow creative designers to create complex, stand-alone applications. The main components of SK8 included the object system, the programming language, the graphics and components libraries, and the Project Builder, an integrated development environment. [...] The SK8 Multimedia Authoring Environment: https://sk8.dreamhosters.com/sk8site/sk8.html https://sk8.dreamhosters.com/sk8site/sk8.html What is SK8? SK8 (pronounced "skate") is a multimedia authoring environment developed in Apple's Research Laboratories. Since 1990, SK8 has been a testbed for advanced research into authoring tools and their use, as well as a tool to prototype new ideas and products. The goal of SK8 has been to enable productivity gains for software developers by reducing implementation time, facilitating rapid prototyping, supporting cross platform development and providing output to multiple runtime environments including Java. SK8 can be used to create rich media tools and titles simply and quickly. It features a fully dynamic prototype-based object system, an English-like scripting language, a general containment- and renderer-based graphic system, and a full-featured development interface. SK8 was developed using Digitool's Macintosh Common Lisp. [...] Sk8 Users Guide: https://macintoshgarden.org/sites/macintoshgarden.org/files/manuals/SK8_0.9_User_Guide.pdf https://macintoshgarden.org/sites/macintoshgarden.org/files/... Lots more information discussion of Sk8 at this link -- I'll just include the first comment, but click for more: https://news.ycombinator.com/item?id=21846706 https://news.ycombinator.com/item?id=21846706 mikelevins on Dec 20, 2019 | parent | context | favorite | on: Interface Builder's Alternative Lisp Timeline (201... Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It also had some features meant to make it easier to generate small, fast artifacts--for example, it had a module system, and separately-compiled libraries, and a concept of "sealing" by which you could promise the compiler that certain things in the library would not change at runtime, so that certain kinds of optimizations could safely be performed. Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements. It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral. Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years. Alan Kay was around Apple then, and seemed to be interested in pretty much everything. Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered. Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS. Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.

PeterStuer 3y ago

I was around when our lab replaced Symbolics Lisp Machines with Sun workstations. Maybe this was a European (or non-US) thing, but non of the Lisp vendors had a built out worldwide distribution and service network, so buying and actually getting machines delivered was not a trivial undertaking. Once Sun did add the support for performant garbage collection that Lisp needed, the choice was clear. Local sales and service clenched the deal, and versatility and broader support were cherries on top. Then the whole lisp machine business collapsed so they weren't even a remote option anymore. A relatively short term later Suns where replaced by Apple Mackintoshs running Mac Common Lisp. MCL was a very decent Lisp environment, machinrs were cheap and by now used for much more than just programming. The next wave would have been PCs, which had far better support. Apple never seemed to understand that your work depended on your computer, and that driving to an Apple store to drop of your machine so you could hopefully pick it up again in 2 to 3 weeks was not a serious option. Meanwhile Dell and the likes offered cheap Next Business Day on-site service. But PC's for Lisp would be held back for a long time by Allegro cornering the PC Lisp market with a product that at the time felt inferior to MCL, while having very aggressive (phone) sales techniques and extremely high prices.

anovikov 3y ago

Well the mainframes never went away. I know a guy - he's now retired but i knew him since 15 years back when he was very active in development - who was a mainframe programmer in banking all his career - and he is the happiest developer i knew. In that industry, the entire stack is coherent and stable, and exists to get things done, not to confuse or bullshit people into infinite rewriting into next shiny framework. There's always a budget to get things done properly, clients know what can be done and what can't. Everything is conservative and things really get delivered, and work in production, in time and on budget, and that ecosystem appears to select people who are able and willing to work that way, not "move fast and break things". And, he retired rich, never doing anything but actual coding for money. But of course, i could never break into things like that because it's not built with people with ADHD and no formal educational credentials in mind, to say the least. That's real business, not hippie hackspace.