[Natales]

I've always felt we don't appreciate history very much in our industry.

I've been lucky enough to work and hang out with some of the co-founders of very impactful projects, such as OpenStack and Cloud Foundry, and there are so many stories I've heard that I'm sure would be insightful and valuable lessons for whomever is embarking on new ideas. And yet, we all move so fast, that there is no time to stop and write them down.

I'm glad BK did. UNIX is foundational to essentially all software-driven technology today, in one way or another. His book (along with Dennis Ritchie) on the C Programming Language made a huge impact for me as a CompSci student in the 80s, as did UNIX itself (Ultrix and DG/OS were my fist UNIX variants).

I look forward to read his book.

[msla]

There's also the unavoidability of narratives, and how they influence what people look up to begin with. For example, there's a Unix history narrative which begins at Bell Labs goes to Berkeley and then out to the world; this is already extremely limited, in that it ignores Wollongong (where the first Unix port was done, to the Interdata/32, and where important work on TCP/IP networking was done) and what AT&T did with Unix after they closed the sources and what the Research Unix people were up to after Seventh Edition, but I think the biggest loss is that it completely sells Multics short: Unix began when Bell Labs left the Multics project, so Multics, in this narrative, is frozen in time as this unfinished thing that Our Heroes are already bailing out of, and that's what gets handed down, as if Multics never progressed an inch beyond 1969. Heck, you can even see this as Myth #1 on the multicians.org site:

https://multicians.org/myths.html

> 1. Myth: Multics failed in 1969. Bell Labs quit, Multics survived.

Now that we can use Multics about as easily as we can use Ancient Unix versions under emulation, you can spin up a perfectly functional 1980s-era Multics and see that, no, really, Multics evolved into something you can do stuff on.

That's the problem with narratives: They're both inevitable and inevitably limiting, narrowing the focus to what makes a comprehensible story as opposed to a day-by-day list of what happened. Humans create narratives as naturally, and as unavoidably, as breathing, but we have to be aware of what they do to our comprehension of history.

[pjmlp]

Specially annoying with that narrative, for those that care about computing history, is as C and UNIX are sold as the first of their kind, invented on magic moment, hand-waving what everyone else was doing.

Since history belongs to winners, if it wasn't for the accessibility of old conference papers and computer manuals, that would be indeed the only one we had to believe on.

[zantana]

I always thought one of the most interesting insights into this was the Unix Haters Handbook https://web.mit.edu/~simsong/www/ugh.pdf especially Dennis Richie's anti forward:

The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.

Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome.

Yet your prison without coherent design continues to imprison you. How can this be, if it has no strong places? The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.

[contingencies]

FYI if anyone visits Sydney and is in to the novel experience due to an interest in Unix history, you can request a window seat on the right side of the plane to typically see Wollongong[0] down the distant coast (past the Royal National Park[1]) slightly after takeoff.

[0] https://en.wikipedia.org/wiki/Wollongong [1] https://en.wikipedia.org/wiki/Royal_National_Park

[cptnapalm]

Speaking of Multics, I am reading "IBM's 360 and Early 370 Systems". In passing, the narrative mentions an early public rejection of S/360 by MIT and Bell Labs because it didn't have hardware-aided dynamic address translation used in time sharing. Instead, they went with a GE 600 series which lead to the development of Multics.

[kedean]

For what it's worth, this is one of the topics Kernighan's book covers. He goes over the breakup in pretty good detail and does talk about the further evolution of Multics.

[lizknope]

The Computer History Museum in San Jose is a great place. I spent an entire day there.

They have an excellent YouTube channel with thousands of hours of interviews with important people in the industry. They posted an interview with Brian Kernighan last week.

https://www.youtube.com/user/ComputerHistory/videos

https://www.youtube.com/watch?v=bTWv-l0JhAc

[sidpatil]

Slight correction: The Computer History Museum is located in Mountain View.

[trenchgun]

Thanks! I am visiting San Francisco soon and will definitely go check the Computer History Museum.

[emplynx]

These interviews are so good.

[ethbro]

Absolutely agreed. It's a shame we talk past each other, when so many answers were already discovered and documented in the past.

I try and keep the following in mind (even when my ego fights it).

(A) I am very unlikely to be the smartest person who's ever thought about a problem. (B) Even if their technology differed, some parts of their approach are useful. (C) Clues and references pop up in the oddest places, so ears open and notepad ready. (D) Accept references graciously, in the spirit of a gift. (E) Name dropping historical references without providing actual context is always in poor taste.

[pvg]

I've always felt we don't appreciate history very much in our industry.

Why do you feel this way? ACM has had a History of Programming Languages conference since the late 70s where the well known History of Lisp paper was presented. All sorts of popular accounts are, well, popular. Soul of A New Machine was published in '81, Hackers in '84, Accidental Empires in '92, just as a few examples off the top of my head.

[Natales]

I love the ACM and everyone trying to make the effort to preserve our history.

I see it from the perspective of someone working at a fast-moving, Silicon Valley-based software vendor. In that context, I don't see a lot of appreciation for history, in the day-to-day basis.

But it's not because people intrinsically don't care about it. It's more about our daily lives. We not only have to do what we all have to do, but we also have to keep up with the latest if we want to survive here. That line of thinking constantly pushes us forward, and doesn't reward looking at the past.

[pvg]

I suspect you might be extrapolating too far from the fact that you and your colleagues are, perhaps, exceptionally busy people.

If anything, the great speed of the industry's development has made it particularly concerned with its own history - things become history quickly, the principals are typically still around, etc. The ACM HOPL conference I mentioned started when high level languages had a total history of barely over 20 years. When McCarthy (who was surely also a very busy person) wrote his History of Lisp paper, Lisp was younger than Java is today. And as I said in a sibling comment, the interest extends far beyond industry participants - there are many popular accounts aimed at general audiences and many new ones are written at a seemingly increasing rate. There's a Computer History Museum which prides itself on its working exhibits right here in Silicon Valley. Industry history-related articles are hugely popular on HN - there's a couple of them on the front page right now.

[pjmlp]

And best of all, reselling old stuff as having discovered the powder just now.

[ethbro]

Believe Natales is speaking more to average everydev's state, than the existence of documented history.

If history exists, but nobody reads it, then are we not still lost?

[pvg]

I mentioned a bunch of popular books, not academic works. One of them had a multi-episode PBS TV show over 20 years ago! Since then, popular accounts of various famous and obscure aspects of industry history, biographies key people, etc have become even more common - I just picked some somewhat older ones.

[ethbro]

Popular with the folks around the office?

I don't work in SV, but I like to think I work in a fairly high-skill coding environment. And I regularly have to elaborate on historical references or suggestions.

[pvg]

I'm at a bit of a loss at what to tell you. I feel like we have just about overwhelming evidence that the claim the computer industry is uninterested in its own history is inaccurate. Beyond the tiny smattering of it I've mentioned, that evidence pokes us in the eye every day from the front page of HN. The person who brought this up is apparently too busy to evaluate any evidence and you are telling me the good people at your office know less about computer industry history than you do - a thing that might be as true and as nondispositive about anything ranging from Pokémon to Ming Dynasty Porcelain.

[ethbro]

We're discussing apples and oranges.

You're saying computer science history objectively exists.

I'm lamenting a lack of knowledge of it.

[Jach]

Your Pokemon remark seems in the right direction, I think disagreements here are perpetually going to revolve around what one's individual experiences have been and what other experiences one reads or hears most about and how much one lets all that impact what one believes about the "average everydev". At least until the CS departments worldwide take a break from the applied math, walk over to the social science departments, and ask how to start conducting scientific studies about subjective things so that we can collect some stronger evidence one way or another.

In the meantime, how is the (Bayesian) evidence from one's experience to be properly measured next to the existence of books, papers, journals, conferences, videos, some with easily accessible and fairly accurate sales or views numbers to prove a level of popularity? In my office I doubt more than 20 people, perhaps no more than 10, out of the thousand or so spread across the floors (which includes many non-devs) could name over 200 Pokemon. This doesn't negate the existence of millions of people who can do that and more elsewhere, and the millions of dollars in that market. But I think it is at least suggestive about the type of people my company, and companies like mine, tend to hire. Is it really a stretch to extrapolate and make a bet that "perhaps only 2% of salaried devs can name over 200 Pokemon"? How about something just as trivial, the names of all 50 united states?

Pokemon is Pokemon, it doesn't matter much for our field, but where the widespread self-hating of one's profession comes in is that depending on one's experience the bets might not seem to be that different for things more programmers (or other roles like managers) probably ought to know about, their field's own short history just one of them. I recently quipped to someone that I doubt more than 5% of developers are even familiar with the SOLID principles thus it's not very fruitful to ask about them in an interview unless knowing about them is a hard requirement. Even fewer have a good grasp of what each principle means, and even fewer know the trivia that the L is named after a woman (with even fewer still knowing the less trivial nature of what else she contributed to our industry). Maybe I'm over-extrapolating, or a bit pessimistic, maybe I'm letting my enterprise day-job and my conversations with others at places (both enterprise and not) jade me in my expectations for what I think the "average everydev" is like.

My underlying theory is that power laws are everywhere, which means if the distributions on facets like "knows Pokemon", "knows about SOLID", "frequents Hacker News", "knows important bits of computing's history", "writes/buys/reads technical books", et al. both trivial and non-trivial are power laws then the average level would be terribly low compared to the narrow peak on one side of the distribution. The mode, which is probably what influences a lot of personal-experience feelings about the average, is lower still. If your experience is mostly around the peak it may seem otherwise.

Who's to say how much it matters anyway, it's often a pointless discussion / complaint to me. Normal laws are also everywhere, and we know that at least IQ is normal. "Smart but ignorant" is acceptable for many things, and besides, ignorance need not be a permanent condition. One doesn't need to know that Lisp machines in 1990 could do full 3D rigging, editing, and effects (https://www.youtube.com/watch?v=6VmJVNYfxDc) in order to be effective for their Java shop employer.

[fourthark]

There’s a lot of good computer history books, but a book about the early days of Unix at Bell Labs has been missing.

Glad it has finally arrived!

[cptnapalm]

There was a UNIX oral history project at Princeton: https://www.princeton.edu/~hos/Mahoney/unixhistory

[zerkten]

> I've always felt we don't appreciate history very much in our industry.

FWIW Chris Harrison (https://www.researchgate.net/profile/Chris_Harrison2) taught a compulsory history of computing class at UMIST in the UK when I was there in 1999-2003. This seems pretty unusual, especially now that I live in the US and understand more about how universities work here.

[verisimilitudes]

That's interesting, because I also feel people don't appreciate computing history appropriately.

If you'd care to learn some real history, I suggest you read The UNIX-HATERS Handbook: http://web.mit.edu/%7Esimsong/www/ugh.pdf

With this book, you'll learn that UNIX and C are nothing admirable and have actually been responsible for successfully destroying much better systems and languages in the popular eye; languages including Lisp, APL, Simula, ALGOL, Smalltalk, and Forth all existed before C; systems such as ITS and Multics addressed concerns UNIX users still suffer under today.

Make no mistake, for all of RMS' admirable qualities, he's basically responsible for UNIX proliferating by copying it for GNU. You also shouldn't look at your modern BSD or GNU system and think this is what UNIX users used decades ago, because for all of their faults, GNU and BSD actually try to produce programs which work correctly and GNU goes much farther than several of the BSDs in this respect. The UNIX attitude is one of getting half the job done and leaving it at that.

In closing, UNIX has no philosophy. The UNIX philosophy is simply brand-named simplicity. The ideas of modularity and simplicity predate automatic computing and recorded history, and yet people will claim you're following UNIX if you write a program which adheres to these basic ideals. Further, those other qualities of this philosophy result in programs that aren't modular, simple, nor beautiful.

[bitofhope]

The Handbook is a fine document and any computing history fan worth their salt should read it, but it's hardly the best analysis of Unix in a historical perspective.

Blaming (or crediting, however you want to think about it) GNU for proliferation of Unix is anachronistic. RMS has repeatedly said he doesn't care for the design of Unix, but he chose it for the ease of implementation. GNU wasn't even bootable as a stand-alone OS before 1990s and certainly not production ready until Linux was. Using GNU utilities in proprietary Unices was popular, at least since the 90s, but I never heard anyone consider them a "killer app" for Unix.

[pjmlp]

I used to have a couple of PC World articles about Windows winning the Workstation market, until about GNU/Linux started to be mature enough to allow easy porting of commercial UNIX stuff into them.

Had Microsoft and IBM kept serious about their POSIX compatibility subsystems instead of a bullet point to win government contracts, and history would have played out much differently.

[pjc50]

It's certainly an interesting critique, but it also massively oversells itself and is totally lacking in self-awareness if you take it seriously.

Computing is absolutely full of widely deployed working technologies that enable people to get work done all day but that have rough edges. For every one of these, there is somebody saying that you should use <pet technology> instead. Usually with missionary levels of zeal. And yet at no point do they seriously address why people might have good reasons for adopting the allegedly inferior solution.

[msla]

> And yet at no point do they seriously address why people might have good reasons for adopting the allegedly inferior solution.

With an emphasis on "allegedly" sometimes. For example, C is hugely superior to Python in terms of machine efficiency. Does C support faster development cycles? That's right, you can write code that's practically as fast as tightly-optimized machine code! Does C prevent potentially catastrophic errors? That's right, you can write code that's practically as fast as tightly-optimized machine code! A lot of the True Zealots aren't quite as monomaniacal on a single narrow point, but the lack of ability to see a total solution is diagnostic.

So was ITS better than Unix? Not if you prioritize usability, support for application software, or ability to run on more than a single family of very expensive mainframe computers the world had begun to abandon by the time Unix hit its big growth phase. You can say similar things about LispMs, although they were more usable.

[de_watcher]

UNIX-haters handbook talks about some weird stuff that naturally felt out of use.

RMS worked on EmacsLisp.

[madhadron]

> I've always felt we don't appreciate history very much in our industry.

I agree. At the same time, unless you immerse yourself in oral tradition and try to assemble a picture of the diversity of what was going on from it, it's hard to get a sense of what has happened on a scale larger than a particular community, and sometimes not even then.

I occasionally think about trying to write a one volume history of computing.

> UNIX is foundational to essentially all software-driven technology today, in one way or another.

Except Windows, which comes from VMS, which predates Unix. And SQL, which comes from IBM mainframe land. I could probably come up with a few more, but it's late and I'm tired.

[cestith]

Largely agreed, but VMS by no means predates Unix.

Unix was in development in 1969, had a manual released inside AT&T in 1971 and was announced publicly in 1973. The first source license was sold in 1975.

VMS was released in 1977 as VAX/VMS on the VAX series of computers. Before VMS the DEC hardware ran various other operating systems such as RSX-11, TOPS-10, and optionally AT&T Unix (which was developed on the PDP series, first the PDP-7).

[acqq]

> Unix (...) first source license was sold in 1975.

> VMS was released in 1977 as VAX/VMS on the VAX series of computers. Before VMS the DEC hardware ran various other operating systems such as RTX-11, TOPS-10, and optionally AT&T Unix

Before VMS there was RSX-11 (note RSX not RTX):

https://en.wikipedia.org/wiki/RSX-11

"From 1971[5] to 1976 the RSX-11M project was spearheaded by noted operating system designer Dave Cutler, then at his first project.[5] Principles first tried in RSX-11M appear also in later designs led by Cutler, DEC's VMS and Microsoft's Windows NT.[6][7][8]"

In Dave's words:

https://tech-insider.org/windows/research/1992/11.html

"RSX-11M was introduced in 1973, 18 months after we started building"

Note Dave Cutler and note the years. I'd say the history is comparable.

[cestith]

Thanks for pointing out the typo. I'll fix that.

Note "heavily influenced" doesn't make RSX-11 any more VMS than it makes Multics into Unix, or CP/M into MS-DOS, or the NeXT into a Mac, or an Alto into a Mac or Windows.

Also note that 1973 doesn't significantly predate 1973. Don't confuse the first source license same with the announcement of availability, which I also noted. And Unix was in use internally at AT&T the same year DEC started on RSX-11.

[acqq]

Dave Cutler was the developer of of RSX-11, VMS and the NT.

I don't claim that his entire life work predates the work of somebody else, just that the products he delivered are definitely comparable in its commercial availability with Unix.

I would also be not surprised if his products had more users at these first years than Unix did. To do the history right one should not project the results visible today (or which happened much later) to the history.

[cestith]

The claim I was correcting was that VMS itself predated Unix itself. This claim is false on its face. Yes, multiple people in the history of the field have worked on more than line project.

[tannhaeuser]

Also from IBM: Hypervisors/VMs, ancestors of today's containers and SGML, foundation of HTML and XML

[onei]

I guess you could make the case that windows is written in C++, which is a superset of C which was designed while writing UNIX. Sure the OS is different, but it ended up being built from the same blocks. If we didn't have C, would we have Windows as it is today?

[jng]

Windows is not written in C++, even if Microsoft did embrace C++ quite a bit with the infamous MFC and so on. Windows was originally written using C and assembly language, using the Pascal calling convention for efficiency. It was originally a layer on top DOS which was written in assembly language. Being a "layer" or not was the subject of a very complex federal antitrust case back in the 90s. You can read "Undocumented DOS" and "Undocumented Windows" for some weird kind of technical investigation thriller which I found weirdly fascinating back in the day.

[pjmlp]

Since Windows Vista, Windows has been transitioning to C++, hence why they don't care much more about ISO C beyond of what is required by ISO C++ standard compliance.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...

[pjmlp]

Looking back at what Xerox PARC and ETHZ were doing with their workstations, maybe that wouldn't have been much of an issue.

[acqq]

Yes the high level language on first Macintoshes was Pascal. Lowest level was assembly.

Pascal was not bad at that role, and it would have been possible to develop all the code which was eventually written in C in Pascal too. At least in the dialects that weren’t made just for education.

[kabdib]

Apple's version of Pascal had a lot of non-standard extensions. If you squinted, it was essentially C.

[pjmlp]

So any system programming language with extensions for hardware access were essentially C? Even those 10 years older than C?

[pjc50]

I don't think there's anything in the nature of C per se that's required for Windows. Any reasonably low-level compiled language would have done the same job; Pascal is potentially the nearest substitute. Windows had to construct its own executable and library formats anyway.

[WalterGR]

Lisp comes to mind.

[dekhn]

I know a bunch of people in the long-term UNIX community and I've always been impresssed that most of them have kept 20+ years of email. This has been helpful in figuring out various historical details.

[DagAgren]

When it comes to Unix, history and the present are one and the same. We have been locked into the same model, the same OS, for decades now. Unix is being developed through small, incremental changes on top of a base that is massively out of date in 2019.

We appreciate history far too much. Unix is holding computing back, and it needs to go. It served its purpose, but it's done. It represent very few of the things that are important to computers in 2019, and it actively hinders many of them.

Unix needs be respectfully let to go into retirement, and new things given a chance to replace it finally.

[Nursie]

Let's have this new, wonderful thing or set of things up and running before we retire what we've got, eh?

[DagAgren]

We can't, because nobody will even consider giving anything new a chance if it is not Unix.

[Nursie]

So you propose what, that the industry as a whole voluntarilty re-enters the dark ages by throwing away its current crop of systems with no replacement in sight ?!

It looks to me like our current crop of unix derivatives and unix-likes is catering for a lot of needs very well. We have windows which is non-Unix.

I think the onus is on you to show that something else could be better, and better enough that the pain of relearning would be worth it.

[DagAgren]

We are in a dark age at the moment, is what I am saying, and I think we should be working at getting out of it.

[carapace]

> I've always felt we don't appreciate history very much in our industry.

That is British-grade understatement right there. :)

[doctor_eval]

Do you mean DG/UX? That was an awesome OS.

[pjmlp]

Indeed, that is what we used at the campus.

[Natales]

Yes! sorry for the memory lapse.

[sacrificedcapon]

In our industry's defense, our industry is relatively young. In other words, the industry is too busy making history to appreciate it. I'm sure as time passes, we'll start to appreciate the history of the industry more and more.

[KineticLensman]

> In our industry's defense, our industry is relatively young

If we take ENIAC [0] as the first computer (1945), then our industry is 74 years old. Let’s compare this with another tech industry – the aviation industry. The Wright brothers flew in 1903 [1]. 1903 + 74 = 1977.

I was a kid in the 1970s, fascinated by aerospace and aviation. There was a massive amount of aviation history around (I still have some of the aviation history books I bought then). So I think there has been plenty of time for the history of computing to appear. Even if we added another 15 years to shift the start of the history of computing (software engineering) at the development of COBOL [2] (approx the same as FORTRAN or LISP), there has still been a lot of time.

So I don’t think it’s industry youth / age alone.

[0] https://en.wikipedia.org/wiki/ENIAC

[1] https://en.wikipedia.org/wiki/Wright_brothers

[2] https://en.wikipedia.org/wiki/COBOL

[andreb]

We like to think that, but we do a lot of rediscovery of techniques and approaches that were invented in the 60s/70s.