Hacker News Reader

Comment by pnathan | Hacker News Reader

Oh, DOS.

It's always sad to read histories of computing during the 80s. It was a lost decade in many ways. Much more powerful and competent paradigms were alive and vital at the start, but by the end, they were all collapsing. A few different choices, a little bit better business sense, and we'd have a computer world profoundly alien to the one we have now.

It's still possible, of course. But it'd be wearing the hair shirt and being a lone hacker as you built up your system.

I refer, of course, to both Lisp and Unix machines, along with the various developments in parallel architectures. The Unix machines as sources of power and use lay quiescent for many years, until maybe the early 00s, and IMO the Lisp machines path has never been genuinely walked.

There's an elegy to be written for the loss of the operator of the computer being turned into a consumer rather than a producer (unix) or symbiont (lisp). Maybe rpg will write it one day.

View on HN

Well, DOS (by which I really mean the IBM PC) was arguably more "powerful" than Unix minicomputers of the time, in that there was never any OS sitting between you and the hardware. Compared to say, an iPad, it was a very developer-friendly machine.

Turbo Pascal, in particular, more or less introduced an entire generation to programming, especially since it had no copy protection.

Well, for disk access, it certainly was an OS. As for more powerful? Nah. Not sure how anyone could make that case given that the Unices of the time were already multi-user multi-tasking systems. Given the hardware DOS ran on, it had to be as small as it was, because the hardware itself didn't have the juice or the architecture to handle multitasking. When the hardware improved, multitasking became a necessity, and thus the need for more hardware abstraction, etc., in other words, a full OS.

I owe my entire career to GWBASIC, QBasic, and Turbo Pascal, all of which was done from an IBM PC. When I first discovered UNIX by way of Red Hat Linux I was utterly confused: all of those absurdly named directories in my root! And where were the executables? I remember pecking out some C in nano, compiling it, and then wondering how the hell you turn a.out into a.exe.

Yes. My first line of code was written in that primitive BASIC that came with the Commodore 64. But my first real program which did something useful -- a game, what else -- was written in GWBASIC.

I owe everything to DOS and GWBASIC.

Turbo Pascal was beautiful. Never quite understood why the industry chose C++.

Because TP only ran on DOS. C++ ran on diverse machines. C++ was also an open standard that anyone could (and did) implement.

I remember phoning up AT&T's lawyer to ask him if I could get permission to implement a C++ compiler, and call it C++. He laughed, and thanked me for asking, saying nobody else had bothered :-) I've always had warm feelings towards AT&T based on that experience.

Turbo Pascal 5.5 (the first version implementing Object Pascal and thus could be compared to C++ as opposed to C) was only on DOS indeed, but practically everyone was there and Turbo Pascal for Windows was released in 1991 just when Windows was taking off. But ignoring Turbo Pascal, Object Pascal was already implemented in Macintosh by both Apple (who got Niklaus Wirth to assist in designing the object oriented extensions) and others (most notably Think Pascal).

Of course these weren't standardized and had slight differences in their syntax, but at the time C++ wasn't standardized either and - again - not all compilers were compatible.

I think the main reason that C++ got its hold was that it was compatible with C which itself got its hold over other similar languages because the popular OSes of the time used it and provided headers in C, all documentation was about the C interface and most third party stuff hooked up with C. Borland initially tried to Pascal-ize the C bits of Windows (f.e. they converted the function declarations from C to Pascal in the Windows SDK docs they distributed up until and including Delphi 1) but eventually gave up (Delphi 2's Windows API docs use C syntax).

Of course that was up to early-90s. After that it was mainly Borland who used Pascal and they succumbed to Enterprise Envy, constantly and it wouldn't be until Free Pascal released version 1.0 years later (in 2000) that a competent 3rd party implementation would exist - and even that was mostly ignored until people started noticing Lazarus in very recent years. Of course now is too late to change the tide as no matter what a Pascal compiler may provide, most people have a ton of preconceived notions about the language.

If I may brag a bit, Zortech C++ was the tipping point for C++ adoption. Before ZTC++, C++ and Objective-C were neck and neck. But OC required a license from Stepstone to implement it, and C++ did not. ZTC++ was the first native, cheap, fast and effective compiler for DOS. I agree with you that DOS was where the action was in 1987. ZTC++'s debut was immediately followed by a veritable explosion of C++ articles in magazines, followed of course by its use.

Since ZTC++ was not a proprietary language, people felt confident to use it on DOS and use cfront elsewhere (and the nascent g++).

The success of ZTC++ directly caused Borland to do Turbo C++, followed by Microsoft C++, and other languages were simply left in the dust.

No OS between you and the hardware may not be more "powerful". Yes, you can do anything you want. That makes it powerful. But you have to do everything yourself. That... not so much.

Those grand machines with their powerful and competent paradigms required hardware resources that were too expensive to satisfy the burgeoning need for computing outside of a university or corporate data center.

But the DOS machines I used in my kiddiehood were much more powerful than the PDP-11s etc that Unix and its rivals had been developed on.

Sure, DOS was solving useful problems that Unix didn't. But there was no reason why an OS for computers with 20Mhz processors that whopping 640kB of RAM had to be as bad as it was.

Sure and you could buy SCO UNIX for that machine for only $3500.

Everyone knew DOS was awful, but it had all the software, and the alternatives (e.g. OS/2) were worse. Once Windows matured, adoption was immediate.

OS/2 wasn't worse than DOS. OS/2 was (eventually) worse than Windows. The problem with OS/2 was that it was part of IBM's PS/2 strategy, which was designed to create a non-cloneable new PC platform, and thereby return to a high-margin business. Windows, in contrast, chose to keep running on commodity hardware. The market chose "hundreds cheaper" over "technically better". IBM eventually tried to run OS/2 on PC clones, but by then, Windows had too much of a lead to overcome.

Many of those were only grand and expensive because they were implemented with discrete components instead of VLSI. If the people at Intel/IBM making the decisions felt that one of those old mainframe architectures were worth purchasing, they could have put them on a chip just as easily as the whole x86 mess.

I believe that eventually happened in the 80s for some form LISP machine as an expansion card for the mac. Not sure about that though...

I think in many ways, PC architecture--especially the bus--was IBM's attempt at poisoning the well to give their mainframe lines a little more runway. Part of why Gates parted ways with IBM over OS/2 was how busted memory management was on the 286 along with IBM's relative indifference to that.

As for Intel, their problem was that they were physics/chemistry guys, not architecture ones. So many of their architecture adventures have been disasters.

That was a very thought-provoking post. In the case of Unix, I believe that its awakening came once it became available outside of academia and the enterprise through FOSS *nix operating systems such as Linux and modern BSDs. This is anecdotal, but I remember when I first started using Linux when I was 15 years old (this was 14 years ago). The environment felt so powerful and so freeing compared to Windows. Later that year I learned about FreeBSD and started using it. I remember spending hours browsing the source code tree, reading documentation written by AT&T Unix guys and some of the original Berkeley CSRG staff. These experiences encouraged me to pursue a career in computer systems research, one that I am still pursuing today.

I didn't know about Lisp machines until the early part of this decade. But everything I've read about them generates the same excitement I had about Linux and BSD coming from Windows. In some ways Lisp machines are even more powerful than the Unix environment is. Unfortunately, there is no Linux/BSD analogue of the Genera operating system. Genera was never open-sourced, and I have not heard of any Linux or BSD analogues to Genera. The source code to some earlier Lisp machine operating systems have been released, but these operating systems lack the complete feature set of Genera.

Also, it would be difficult to develop a clone of Genera and have it gain traction in the broader community today. Linux not only benefitted from the already-existing work on the GNU toolkit, but it also emerged at a time when PC users were mainly using MS-DOS and Windows 3.0. The GNU toolkit and X11 is a dramatic upgrade from MS-DOS and Windows 3.0 unless you need access to proprietary software packages that could only run on DOS or Windows. But what if Linux had come of age during the days of Windows 2000? The story regarding Linux's adoption among PC enthusiasts might have been very different. In the case of a Genera clone, all work would have to be done from scratch, and it would have to compete against full-featured, readily-available operating systems like Linux, the BSDs, and Windows 10. It would also take a lot of time to write: the period of time between the founding of the GNU Project (1984) and the release of the first Linux kernel (1991) was seven years.

The closest thing we have to anything like Genera is Pharo, a modern derivative of Smalltalk. But even with Pharo it will take a lot of work to develop a suite of utilities that could make Pharo an environment that can be used as a daily-driver operating system.

Even so, I'd love to use a FOSS clone of Genera that's updated for the needs of the next decade or two of computing.

I realized this evening I should have said Lisp/Smalltalk.

I would also agree regarding market conditions.

One other thing, since this textbox is here and you're contemplating similar thoughts: the Modula-2/Oberon OS system in the 90s deserves some serious re-analysis and recognition of what it did do. My memory of a paper - and I haven't found this source when I went looking for it - is that it had a full networked productivity suite suitable for all users of the CS department? University? hosting Oberon's development. And it was used heavily in that place. It was a hardware-software-language codesign project, if I remember right. Maybe the last of its kind in the wild outside of the Linux/DOS projects with C and Intel processors.

I do agree that someone who dropped a reasonably decent starting point for the Next Lisp OS in a fashion that multiple people could contribute to could get some traction and power. A lot of water has passed under the bridge since Lisp machines went away, and the model users and environments are substantially different. My reckoning is that a genuinely next-gen system would wind up with a trusted-compute base, maybe even a trusted-compute kernel, using Rust or other forward-looking technology, with the lisp system sitting on top. Broadly: rust would provide syscalls & drivers, then boot sbcl for the init and then the main user.

It would be a fascinating exercise in modern OS & userland redesign. I think there's probably a PhD in it; as far as I know, that world has lain fallow for a few decades now in academia.

ETHZ, Swiss Federal Institute of Technology Zurich.

http://www.progtools.org/article.php?name=oberon&section=com...

Thank you! I must have read that page years ago, and I lost the link.

There are a lot of lessons from the 70s/80s even 90s that are completely absent from today's personal computing environments, and they are ripe for a comeback. Oberon/Genera-like systems had one thing right: make your system reasonably transparent all the way down. Design hardware for the system — not the other way around. Smalltalk systems went a step further, showing not only what true OO could be like, but that you could layer relationships of complexity atop one another and allow regular users to peek under the hood, at varying degrees of detail and difficulty, as they needed. Apple had something close to this with Hypercard in the 80s and 90s.

Unlike that previous era, we have big advantages today that make me think the world is ready for reconsider all of this. The first is that we have more universally adopted standards for exchanging data (we don't bitch as much about compatibility across systems). The second, and somewhat related point, is that we can assume high network connectivity most of the time (itself a kind of universal standard). As I've said before: all a new system needs in order to be "viable" to the existing world is a web browser. Everything else can be rethought.

Today I will be doing yet again another project for a client who simply needs to have data pulled in from a bank as CSV and inserted into their existing Excel template. This is in theory a very simple programming task. But the ecosystem and our environments make it tremendously and unnecessarily difficult. If we had "real" personal computing, they wouldn't even need someone like me.

Broad agreement about the network parity aspect. If you can have a working TCP/IP stack /and/ can run Chrome, you have the ability to pretty much be "usable" by many users.

I'd like to stop the argument there though and ask, first, why bother for a research project? Not that it's useless, but if you're trying with a few other hackers to reconceptualize OS layout and write the relevant tools for your system, you've got enough on your back.

Arguably in this hypothetical next-gen system, if you can provide an interface that looks like a Linux container, you can run a Linux application like Chrome and be done with it.

(and even more to my point original point of things could have been very different: web browsers are essentially reimplementing a cross-platform GUI without a toolkit and with a custom language (JS). Maybe it's time we just had plain old network applications without a web browser..... but that's a different discussion, a different musing).

By web browser I didn't necessarily mean Chrome. I mean a browser completely re-implemented in the new system, preferably a "live" system of "objects". I realize it's a tall order. But it would solve your issue with network applications, because people could just rip out the objects used the browser and use them elsewhere as they go. As more people adopt this system, they would forget about the browser altogether, since the objects themselves can communicate remotely. In essence: the web browser part would be for adoption, but the system can be so good that it eventually becomes obsolete.

> why bother for a research project?

We'll never get anything new if we don't. Linux and containers are band-aids. They are not original solutions. We shouldn't be squeamish about re-implementing everything from the ground up. The big problems in personal computing have not yet been solved. If anything, we've been regressing — in the wrong way.

I see what you mean, but the raw volume of work is an enormous load to carry for a dedicated few.

and IMO the Lisp machines path has never been genuinely walked.

Even with special "Lisp-optimised" hardware they were still extremely slow compared to other contemporary machines.

In our Fraunhofer lab we had a couple Symbolics, a Vax and a bunch of PCs. Everybody thought the Symbolics were super cool but nobody could figure out how to get any work done on it that was appreciated by the outside world, they were just considered a shiny toy.

They were not extemely slow compared to contemporary machines. Keep in mind: Lisp Machines were single-user workstations mainly for developers and were developed originally in the end 70s and commercialized in the 80s.

Commercial Lisp Machines (LMI, Symbolics, TI) were basically as fast as contemporary machines 1981-90. Especially for running Lisp. The first systems appeared end 70s and there basically almost no machines like them. LMI and Symbolics machines were basically the first or at least among the first GUI-based workstations in the early 80s. In the mid 80s a Lisp Machine was as fast as the then contemporary machine, but much more extensive in capabilities - which made the hardware very expensive.

In 84 Apple released a Mac with tiny b/w screen, an 8 Mhz 68000, 128kbytes memory, no virtual memory, a floppy drive, no extension cards, no development environment, ...

At that time the Lisp Machine from Symbolics used a 68000 as a frontend processor for its megapixel console, had ethernet, supported several megabytes of RAM, had a dozen of extension slots, had disk drives, tape drives, color graphics options, and an object-oriented OS running with 100+ virtual memory with garbage collection.

At the end of the 80s machines catched up - especially the Unix machines - but they were not dramatically faster for running Lisp. But they allowed machines with less RAM running C code/applications - while RAM was really expensive. Real faster machines appeared in the early 90s, when Lisp Machines were already abandoned and newer Lisp architectures based on Lisp RISC chips were not brought to the market - due to lack of customers interested in expensive niche technologies...

In the end 80s a 68030 wasn't running Lisp faster than a Lisp Machine - basically the same for the usual (micro-) benchmarks. The 68040 in the early 90s was slightly faster, then. Generally the during its lifetime 75-92 the Lisp Machine architectures were not designed for speed, but for other capabilities - they were basically enablers for the first development workstations with able to run large (at that time) software/datasets. A single Macsyma could thrash a timesharing mainframe end 70s, but on a Lisp Machine the user had Macsyma on his 'personal computer' with his/her own 1MB-4MB RAM and his/her own virtual memory.

SGI Machines in the mid-80s used Motorola processors - thus weren't 'extremely' faster either. The early MIPS processors weren't much faster either - around 1990 SGI introduced cheaper SGI machines with good graphics - but still not with 'extremely' fast CPUs...

How much did a Lisp Machine cost? With the specs you're listing I imagine it was 10-100x a PC.

When we used PCs for AI development in Lisp in the end 80s/early 90s, they were large Compaq PCs with disk, large screen, backup, graphics card, lots of RAM, Lisp license etc. -> 25k$ or more.

A Lisp Machine new in 1984 would be around 80k$. Prices were then coming down a bit for delivery systems and also for embedded boards. But you could think that end of 80s a large Lisp Workstation was three times as expensive as a high-end PC or Mac. But for PCs RAM was still expensive and the 32bit Intel processor wasn't really that good running Lisp. RISC systems (SPARC, MIPS, ALPHA, ...) were better at that and their Lisp systems were better than the ones for PCs. But the real good Lisp systems (Allegro CL, LispWorks, Lucid CL) for RISC appeared or matured only end 80s/early 90s. 64bit Intel is okay nowadays, too.

Some Lisp systems were also stretching PC/Workstation capabilities, since they were large memory-hungry applications - they triggered specific bugs in larger configurations. Imagine in the early 90s a CAD system written in Lisp running in hundreds of MBs of RAM, where each CAD workplace cost 1-2 million... stuff like that used by FORD for example to design cars...

With the cheapest one being 3x the cost of high-end PCs (so not the average PCs, which were and are the majority of PCs sold), the economics kind of say why Lisp Machine didn't fare that well.

If I have to pay 3-5-10x of an already expensive PC for the average person, that thing'd better be life changing amazing.

There were cheaper machines. But generally I would guess all in all it were 2 times the cost of a PC. Symbolics also sold a development environment for Windows (called CLOE) and Lisp Machines on boards for Macs and SUNs. TI had a board for Macs too, but TI left the market end 80s very quickly.

Symbolics then was also developing a virtual Lisp Machine - an emulator running on 64bit DEC Alpha machines - the software did cost around $5k later.

But keep in mind when PCs became viable for Lisp development on a comparable level, it was already end 80s. Something like a Mac IIx from end 88 was not faster and came with a 40MB Disk. I got a used Lisp Machine from 1986 which had a 600MB disk drive - the drive alone was more expensive than 2 Mac IIx machines. When research labs bought machines like such a Lisp Machine in 1982 for 100k$, they were basically ten years ahead of the market. When budget for these projects were shrinking and the competition was catching up (first RISC Unix workstations and then high-end PCs) it was already endgame time.

Additionally companies moved some Lisp software away to C++ - because C++ applications were usually thought to use less system resources at application runtime.

Reply on news.ycombinator.com