Let's Not Dumb Down the History of Computer Science (2014)
cacm.acm.org
cacm.acm.org
The whole sequence of articles/talks is interesting:
- (2007, Martin Campbell-Kelly), "The History of the History of Software" (DOI: 10.1109/MAHC.2007.4407444 ) — the trigger for what follows.
- (2014, Donald Knuth): "Let's Not Dumb Down the History of Computer Science". Video: https://www.youtube.com/watch?v=gAXdDEQveKw Transcript: this submission (As mentioned, there was also a 2009 talk at Greenwich of which I can only find a 6-minute video: https://www.youtube.com/watch?v=sKUg0V7pt8o)
- (2014, Martin Campbell-Kelly): "Knuth and the Spectrum of History": https://ieeexplore.ieee.org/document/6880249 (click on PDF)
- (2015, Thomas Haigh): "The Tears of Donald Knuth": https://cacm.acm.org/magazines/2015/1/181633-the-tears-of-do...
The short version is that over the years, in all "history of X" fields other than history of mathematics, the proportion of papers with technical content—exactly what ideas did people come up with, and how, etc—has decreased, while historians have taken a turn towards broader social commentary. In this talk, Knuth explains why he finds this unfortunate and what value practitioners can get from history. (He also ends with examples of this kind of history waiting to be written.) In his reply, Haigh points out that if computer scientists want such history they'll have to write and fund such writing; historians as a field won't do it.
(Someone in the YouTube comments points out that military history is like this: there exist military historians writing technical history about things like the "terrain, weapon systems, tactics, strategy, etc", funded by the military, because members of the profession do care about this. Unfortunately, this doesn't seem to be much the case in computer science.)
BTW, here are a couple of papers that Knuth wrote himself, which I would guess is the kind of historical writing he'd like to read (rich in technical detail):
- Von Neumann's First Computer Program (1970): https://fermatslibrary.com/s/von-neumanns-first-computer-pro...
- Ancient Babylonian algorithms (1972): http://www.realtechsupport.org/UB/NP/Numeracy_BabylonianAlgo...
- The Early Development of Programming Languages (1976): https://news.ycombinator.com/item?id=25717306
Luckily, the raw PDF is available at http://public.callutheran.edu/~reinhart/CSC521/Week3/KnuthVo...
I think it's a valid point/pursuit but somewhat sisyphean. Technical is harder to follow. That means fewer people will read it, even people who do have the skill to. Publishing is a medium, not entirely unlike HN or pop science books and has a media dynamic. I think history of X tends to go "accessible" in every field, with the counterexamples (eg mathematics) being exceptions. A HN article with lots of code is harder to read, digest and comment than an article about the business/societal implications of facebook's new policy on squirrels. Even people who do read the former, can read more of the latter more easily... so they do.
Also, generalities tend to be more evocative than specifics. If there is a message to the "story" about small teams, outsiders, or other cultural element... that's engaging. Technical is necessarily specific, and a lot of actual invention is somewhat random... without a wider implication.
I'm skeptical that "history of X" fields can really focus on what he wants them to focus on. The types of insights that he's looking for are, as he says himself, best found in primary sources. There will always be a limited supply of these, since people who write books and people who invent things overlap irregularly.
On the positive side, since he seems to mostly want inspiration, a little can go a long way.
Totally tangential... Military historians used to play a lot of "tactics," trying to recreate battles with board game pieces or whatnot. There are endless generations of such commentary on Roman vs Etruscan spear formations. The evolution of helmets or whatnot. I don't think we learn much from this.
I recently finished an excellent one volume history of the Civil War, "Battle Cry of Freedom." It was written by James McPherson, a historian. This book has informed my understanding of not just the Civil War, but also the lead up to it. I believe this context is essential for understanding where we are now.
Capability based security, for example was something that allowed you to run any program, with no danger to your system. It's not part of any common OS. They had it at Xerox PARC, but Steve Jobs chose not to take that part.
On the other hand, the PARC focus on replicating paper was a step backwards from work by Engelbart and others.
The limitation of a single desktop was put in place to allow children to ease into the desktop metaphor... it wasn't meant for adults to be stuck with the training wheels on.
I've been digging back, looking for the ideas we missed... and boy, there are some really powerful tools waiting to be reified in a modern context.
I know, I know. Norm Hardy was really good, his system, KeyCos, worked, and few could understand him. I used to know his "explainer", Susan Rajunas. We don't even have proper "rings of protection", like Multics, any more.
Although the real problem today is that we need to run programs with less authority than the user running them, and we still lack a good conceptual model for doing that. "Allow write to SD card" is far, far too powerful a privilege to grant.
All true; But. What really stopped capability systems is that most users cannot be bothered to grant minimum privilege. Even most developers cannot - we invented containers in part as a way to mitigate the consequences of failing to grant minimum privilege.
Capabilities-based stuff is really neat, but it's also really complicated to put into practice, and I live in a world where it's often a struggle to get developers to label their brand new REST interface for whether or not it's "admin only". Personally, I think a lot of that "really complicated to put into practice" is essential complexity, not incidental; anytime you sit down and really think about what the optimal permissions scheme around any even slightly non-trivial system ought to be, you generally end up with something pretty complicated. But even if the perfect system existed and you handed it to the real developers we have today, you'd still be working with people who would do whatever the simplest thing they could do to fully bypass the capabilities system is and get on with life without a moment's twinge of conscience.
I don't want to be too hard on the average programmer; contra fashionable cynicism, things are actually getting better on the decade time scale. But at the current pace, "capabilities" are probably still a decade or two away from even being "niche".
... until someone from marketing shows up, and says, "Hey, we also need it to...", and the program now needs a bunch of new capabilities.
Also because it's extremely difficult to grant minimum privilege on your typical general-purpose OS today. Spawn a new process and the default is that it has all the same authority that you do - it takes a lot of work to dial that down.
This is typically inverted in a capability system: the program only has the authority that you give it.
Isn't this now the standard reality for most desktop and mobile OSs?
"Allow write to SD card" is far, far too powerful a privilege to grant.
Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless. Having spent some time with both carriers and mobile device manufacturers, there are also areas of undeclared commercial utility in keeping control with the OS (device manufacturer) and out of the hands of the user: DRM, app sales, increased chargeable mobile data use, reduced chance of non-cellular data paths (mesh networking), etc.
When you had someone $3.50... you're giving them $3.50 of capability, and no matter how clever the Loch Ness Monster is, they'll never get more than that $3.50.
If on the other hand, you have to give them the entire wallet... like you do in Windows, Linux, etc... the game is over.
Capability Based Security is NOT the same as "Global Permission to do X"
PayPal exists because it is an instantiation of capabilities for finance on the internet.
That was the old way. The new way is you give them your credit card or WeChat 'bill me' code. You get billed whatever the merchant wants to bill. Any post-facto complaint will be at the cost of your own time.
Your further analogy is factually inaccurate. Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps.
Sure, that may be the "new" way, but that doesn't mean it's better! Much of the payment fraud online couldn't exist if customers were in control of how much money to send and when rather than the merchant.
>Under Windows, AFAIK most programs have a partially restricted permission set, hence Run as administrator. In Linux, under modern distributions, most programs run in both a user and a cgroup context, and some under further restrictions such as chroot and caps.
Under normal circumstances, they're restricted only to the extent that your user is restricted. That's far from the level of granularity that GP is talking about.
Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities.
Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to the entire viewer app. A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail.
Designing a safe and useful capability desktop/mobile environment is hard. Modern UIs and CLIs are just papering over the details of actual objects in the privilege system. Icons and filenames are only a human-readable representation of objects accessible with capabilities and so there's a disconnect between UI representation, user intent, and user interactions. Solving that means replacing arbitrary custom UIs with trusted, object-aware system UIs that reveal the actual state of capabilities and objects instead of a simplified representation.
> Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless.
The UI model would have to be significantly different with a lot of trusted components. Basically any UI element that can grant a capability to another app/process has to be part of the trusted system. That means a user-level app can't even ask for permissions to objects because it can't see them, know they exist, or refer to them in a way the system UI could grant a capability. Interaction between applications would be more like a smart clipboard; a user would open their camera app, take a picture, and grant a read capability to an app that's waiting for it.
There's a lot of 'convenience' lost in a pure capability system because there's no default trust in the good intentions of app developers.
There is a potential further development that allows convenience; formal proofs for application software that adheres to a particular data management policy. Say instagram wants to formally verify that photos taken automatically by the app (selfie button or whatever) can never be uploaded without user permission. Prove that the component for taking photos within the app drops all capabilities to the network and the main app itself before taking any photos; all it can do is fill up a particular folder/directory with new photos that are visible to the user, who can then trigger an upload (grant capability to a particular photo to the main app from a secure view of the directory) with another trusted interface. That trusted component could be granted a capability to the camera itself once the proof is verified.
Clearly if reasonable security is a goal default trust should be restricted. Minimum trust thresholds should be distinct from sometimes-needed trust which should be delineated on a per-item/per-session/temporally restricted basis.
Currently the way the web works, 1st party user downloading almost any 2nd party file means a 3rd party app of user-defined identity starts and reads the 2nd party file from a 4th party server in a 5th party format running on a 6th party OS with a 7th party network, 8th party browser and 9th+ party certificate chain in an unknown filesystem context. What is wrong with this picture? You can't establish trust in this context. All you can do is establish boundaries for failure.
Modern history has shown that this tower-of-crap™ approach is the most commercially expedient means to distribute new functionality to general computing devices. I would argue that the path forward in general computing is therefore to work on processes to enhance and apply those restrictions using improved architectural decisions at the interface level combined with CI/CD processes that automatically apply them.
In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage.
Yep. This has to come from OS vendors and while iOS and Android took some steps in this direction they're still basically POSIX about it instead of capability-based.
There's also a really unfortunate trend where apps want to be the entire user interface for everything. Manage the SMSs, be the camera and photos albums, handle payments, etc. This breaks all security guarantees by the OS.
Isn't this precisely how iOS works?
I'm not an expert on iOS. From reading their latest security guide and a bit of wikipedia I think the following is true:
* iOS uses the ZNU kernel, a Mach derivative with BSD POSIX environment with traditional POSIX processes, ipc, filesystems, and networking. * iOS implements runtime security by process/user-id separation and ACLs on system and inter-process APIs. The ReplayKit uses a similar idea by giving an app a handle on a single recording session, but it's implemented on top of the POSIX framework. For contacts it's clearly ACL based and either an app has access to all contacts or none whereas a capability system would allow a particular form of access to a single contact.
Capability systems are implemented by a kernel enforcing capabilities as the sole method of interacting with other objects in the system. There is no generic open(), connect(), read(), or listen() although there are similar methods on certain capabilities processes can hold.
For example, the user could provably give one contact to an app which was further allowed to share that contact with a third app under certain circumstances e.g. "schedule a call to Mom next Thursday" which would involve granting a scheduling app a capability to initiate a phone call but only to the number in the particular contact within a certain time window, by granting a re-grantable capability to the phone number (and maybe display name) subfield(s) of the Mom contact, which the scheduler would hand off to the phone dialer at the desired time. This is a mildly contrived example because of the complexity of generating the specific capabilities necessary to accomplish it, but it should give an example of what is possible to do securely with a capability system that would be difficult or impossible with traditional ACLs.
Apps are heavily sandboxed on the app bundle level. Any code that's installed from the App Store in an app bundle has no way to access the filesystem outside of its sandbox. There is no "access the file system" permission like on Android or on desktop OSes.
Inter-app communication is extremely limited. There is no way for an app to launch a process in another app bundle. When you open a file from the system Files app, your app gets access to that file only.
There is a small handful of high-level APIs that allow inter-app communication, including a URL handler, and a "share this file" dialog box, where you give the OS a file URL and the OS lets the user pick another app and the OS grants access to only that file to the other app. There are also some very narrowly-defined APIs for audio plugin-type data stream integration (which is gated by App Store approval)
There is no OS-mediated way to share live objects (you can share objects, but the receiving app just gets a copy of the state of it at the time of sharing)
For the OS-managed databases (photos, contacts, music etc), the exposed APIs vary wildly in how they manage permission
That's the key indication that there aren't capabilities underlying the databases. If there were, access would be more granular and uniform.
For FreeBSD there's Capsicum(1) and for Linux, although the implementation is not strictly capabily-based, there's SE-Linux which depending on the usecase resembles capability-based restrictions.
Also, although not based around capabilities, Linux has supported them for awhile https://linux.die.net/man/7/capabilities
The main implementation difference in a capability based system is using a PowerBox to select files to give to a process, instead of letting the process access everything the user has rights to.
There is a lot of stuff online, just follow the threads. I've been pushing Capability Based Security for a decade... only in the last 6 hours did I learn that they had it at Xerox PARC, in an offhanded comment by Ted Nelson at the end of one of his videos, where he mentions the great ideas that got away.
To be fair:
1) Apple II and Macintoshes were slow
2) and single user
3) and pre-Internet (no networking, even.)
Microsoft also had to make an early choice about what features to add to DOS, particularly networking or multiuser, and networking was chosen to implement first. (Probably because of Novell and other early networking competitors.)
> the PARC focus on replicating paper was a step backwards
"Replicating paper" was resurrected about 10 years ago when everybody was making apps with a UI like books turning pages. There was actually a programmer (Russian name if I receall) who specialized in consulting on that, advising companies on what algorithms to use and how to get the page flipping appearance they wanted. I thought it was pointless but hilarious, as it was totally ornamental.
Adults can use training wheels too when first learning to ride a bike. But once they're competent, it's more expressive to ride without.
Use by the non-initiated may not be that high, but that shouldn't be surprising given that user education is a very scarce resource and it's being spent elsewhere.
Every KDE I've installed (Slackware, Mandrake, Ubuntu, Fedora), to my recollection defaulted to multiple desktops.
I'm so happy Win10 has virtual desktops as in moving from Linux to MS Windows - mandated by my workplace - that was a massive pain point.
It might not be the most visible feature for most users, but it is definitely an important one, which I would hate to see go away.
When you add a commit to an OS, the legacy impact of that stays with the OS and must be un-done by anyone who changes it.
https://archive.org/details/bitsavers_xerox
And then go over to symbolics, Borland, whatever.
It's talked about in just about every tribal knowledge compendium. It's assisted by doctors in some countries, almost completely ignored in others.
Basically, haven't we "reinvented" this via "The Eternal Mainframe"? Only now it's called Amazon Web Services?
Nowadays still available as Unisys ClearPath MCP, with high level security as selling point, while it will take generations to fix UNIX and C's adoption at large, if ever.
At least they created Object Pascal and did two OSes with it, and contributed later on to the C++ industry adoption, instead of being yet another C powerhouse cloning UNIX.
‘No danger to your system’ shouldn't be conflated with ‘no danger to you.’ The problem with capabilities is that they reinforce and solidify the ‘smartphone model’: your data isn't yours, it's an app's, so what you're permitted to do with it is entirely controlled by someone else.
Something like capability based security would be a godsend for the corporate and enterprise environment compared to what's commonly in place.
https://canvas.harvard.edu/courses/34992/assignments/syllabu... - Classics of Computer Science
and that page contains this link to a spreadsheet with links to over 150 historic papers and other sources:
https://docs.google.com/spreadsheets/d/1wS6O7-ZoFL7Cfjgt-kdh...
http://pascal.hansotten.com/uploads/wirth/Good%20Ideas%20Wir...
Fuck the algorithm!
I created a History of Tech Design class [0] of 6 different tracks for design students. I’m not an historian, but I have some training in finding original sources, sorting them, accessing archives… it helped a lot, and I could use a lot of primary sources full of not-well-known details.
Back in the 90s it would have taken me weeks or months to just access this amount of historical material!
I had to turn this class into something accessible and interesting for design students / pros, but I certainly do not consider that dumbing down, just: Know your audience!
[0] https://workflowy.com/s/strate-history-of-te/a4ID6kKtznLwQC7...
(Not in my notes but just yesterday I stumbled upon the original 1990 memo by adobe co-founder John Warnock for the PDF project, Camelot. Great read)
You are absolutely right that there’s so much more in boxes somewhere and in the mind of the people who were there, but as a starting point online archives are great. We can only encourage more digitization of more archives (it’s a lot or works, organizing and sorting even before scanning)
Do you just disagree with the research of the last ten years for some reason so dismiss it as not the real research and think there's some kind of under-appreciated research out there?
I think it is somehow related to the power of computer science to change the human condition. Everyone is thinking about the future. Mathematicians also crave novelty, but I don't think they feel "my work could change the world" in the same way as CS researchers.
Learning about CS history would make us better researchers, and thus more likely to change the world, but that line of motivation is not direct enough to excite people. There is still so much low-hanging fruit that can be plucked with only shallow knowledge of the field.
I don't need to know about DARPA to create a wordpress page or a C# Windows Service...
Until you do, of course. At which point it's clear you should've known about it years ago.
Not sure where the disconnect is because at no point have I said you shouldn't learn how to do your job correctly - and understanding Big O, SOLID, YANGI, etc are all important to know... but have nothing to do with history.
So again... history isn't needed to be a good engineer. And being a good engineer and KISS programming is possible without understanding 100 years of history.
But programmers don't want to be accountants, they want to use new and shiny things even when it's not the pragmatic choice, even when it would be better engineering to understand things in a broader context, to understand the history behind these "new" (actually old) things.
Same for stuff like construction and cooking... stuff that's been around a very long time has become rather stable and of course it isn't going to be "reinvented every five years".
> when it would be better engineering
again... I don't need to understand history to understand Big O and which algorithm to use in the right circumstances or when procedural programming is proffered to functional.
At no point in my career have I ever NEEDED history to decide which library to use, which sorting algorithm is suitable and how to create functional apis or windows services.
History is nice to know... but still 100% not needed at any stage of the process.
I'm not sure where the disconnect is because I like history... I like learning about American history, world history, programming history... but none of that has ever been relevant in any of my jobs when it comes to day to day decisions and projects.
"don't reinvent the wheel" is a separate topic and while I can agree that many things get reinvented - computers are still a very young industry compared to stuff like accounting and architecture.
Yes, sometimes these have to do with changing requirements or hardware capabilities, but more often they're just about a new generation wanting shiny new things rather than boring old things. Except that the shiny new things were the boring old things of the previous iteration.
Many ideas of the yesteryear were not bad or even infeasible, indeed they were successfully put into real-world use. Until the tide changed and they became unfashionable for whatever reason. And then they became fashionable again, but without a view of the history there's little synthesis of ideas, little learning from past experiences beyond the current cycle.
http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...
There are good reasons to learn assembler, basic, forth, lisp, smalltalk, pascal, c, c++, python, java, etc. even if you don't use them on a regular basis.
> good reasons to learn
Of course... but none of that needs HISTORY to use effectively.
Knowing functional programing, procedural, async, etc, etc, etc... I can know all of that without needing to know history.
One doesn't need the other.
An equally important part is the ordering and the reasons something happened.
You can know how to write simple programs in all paradigms, but fail to understand what to use when. You might have memorized a long list of algorithms but not understand the trade-offs involved in choosing one.
Of course history is not the only way to understand this, but it is definitely one good method.
They are related and good to know... but I don't need to know history to flip burgers, run a business or plan my next sprint.
I'm not arguing history is unimportant or good to know or even possibly useful just to have ideas of what to do - or what not to do... I'm just arguing it's importance is over-emphasized.
Why would you want to handicap yourself or your field by making it harder to “talk” to those a little bit further before you?
Your building is resting on their foundations whether you acknowledge it or not. They may have had a solution for the problem you’re facing.
If you don't like the term, use another one. But without history you're bound to cargo cult computer science where what you have to do next is plan your sprint. Why do you need a sprint anyway? You might never know if you need a sprint any more if you don't know what problem was it supposed to fix.
As Knuth was trying to point out, history should be more than tables and time lines.
It should provide details of how important advances where made and how solutions to big problems where found.
And the reason being, since those historical details aren't being recorded, it's more than likely you are in fact solving business problems today using the same techniques discovered in the past, you just don't know it.
It totally looks like you don't. Are you sure about this sentence? Every other sentence seems to contradict this one.
I probably don't do as much as I could/should... but I am a successful programmer who has never needed "history" to understand basic programming principles.
I seem to consider history and good engineering to be different topics while everyone else seems to think you can't understand Big O, YAGNI, SOLID, the difference between Functional Programming and Procedural programing, etc, etc, etc without understanding the history of how assembly turned into c...
Because History is interesting... but not needed to be a good engineer and a good programmer.
You may want to think whether learning wordpress is the same with learning history of html at decade level.
Since you're publicly exposing your thoughts, let me tell you that what you are doing is expressing your ignorance and being proud of it. You may want to drop the second part.
I don't need to know history to code html, php, javascript, etc. I've a very successful programmer without using the "history' of programming in any shape or form.
"expressing your ignorance" or... I'm simply expressing that I'm a successful programmer who's never used "history" in a decade+ of programming...
You may want to reevaluate "ignorance" as you make claims that you can't support (IE: "disdain" for history and "can't code wordpress" - again, neither statements I've made). Reread my comments.
recap of them: I like history. I don't need history to code wordpress or windows services.
What I want to say is that there are entire domains of competence that are irrelevant to a large degree to doing the day's job. Knowing history of computing will not necessary help in making a better program in a way that can be noticed. But history of computing is closely related to computing. Unlike for example history of knitting. Although neither will make you a better programmer now, the first has much better chance at that than the second (although we don't exactly know that). Thus, when someone downplays the importance of history of programming to improving a programmer's mastery, I see it as touting ignorance at not seeing the connections between the two: self sufficiency, arrogance of ego being trapped by the light of today's fads, pop culture that doesn't care about the past or the future.
Or maybe I'm projecting...
Maybe it's a combination of you "projecting" and me not being clear. And trying to discuss what could be deep conversations in a little more than a twitter tag of 140 chars.
I'm personally a .Net Developer and while I do stick with the latest versions (IE: .Net Core), I also have enough experience to know the past (IE: ADO vs Entity Frameworks). I was trained in school on a mainframe (IBM DB2 with RPG and SQL). I'm not trying to stick with the latest "hotness" as most of MY work is actually done via Windows Services, API interactions and moving files around - definitely not the latest fad. With that said, I am working on using good tools to get my job done faster/better - IE: CI/CD pipelines to automate builds, testing, deployment, etc. Tools that didn't exist 5 years ago could be the latest fad but I don't think that's what you are suggesting.
I'm more worried about learning different things (IE: Functional, procedural, async, parallel, etc) than I am worried about "history" of those. When I pick up a programming book, I'm less worried about the "Microsoft created version 1 in 2000 and version 2 in 2005 and..." and more concerned about do's, do not's, best practices, etc.
Maybe it's my personality and the way I "deemphasize" history... it's not that I think it's unimportant... I just think that it's more important to focus on other things. Learning some history along the way is good and fun but it's never been my focus and I've never used what I consider "history" in an interview or a job on a day to day. Maybe that's rubbing people the wrong way lol
Step 1. Go to software conference.
Step 2. Get into hallway track conversation where a historical anecdote and its lessons are relevant.
Step 3. Say things that prompt y'all to have insight and establish trust that you're thoughtful about how to build software.
> Step 1. Show 10+ years of experience
> Step 2. Never talk about history because I don't need history to solve business problems with programming
> Step 3. Make 6 figures.
So again... 99% of programmers won't ever use the history of DARPA and the birth of the internet to land a job.
1. What really matters is delivering business value.
2. Networking at conferences and talking about the social context of technology is useless.
An architect will learn about the history of hundreds of buildings at school.
A product designer like a designer designing chairs, knows about the history of chairs, has dozens of example of chairs in their mind.
That developers strive to be so a-historical is a sad state of affairs. It makes the whole field naive and stuck in a perpetual present.
But digital art and web design are in the same mode too, so it’s something about the whole digital fields.
The only exception is game design, where it’s considered important and valued to learn about old games, play them, understand how they worked.
I know because I was looking how to efficiently generate power sets and eventually the only good answer was in TAoCP!!!
So the answer is: history, the kind of history full of technical details that Knuth argues for, is extremely useful for our profession.
It is the empty, pop history, made without algorithm descriptions and full of only anecdotes what you are thinking about? Knuth argues against that!
- "As We May Think"
- Von Neumann's report on the EDVAC.
- The invention of index registers, originally called the "B Box". (The "A Box" being the main arithmetic unit.) Von Neumann missed that one.
- The original 19 page definition of ALGOL-60.
- HAKMEM, from MIT.
- A description of the SAGE air defense system.
- Something that describes how the Burroughs 5500, a very early stack machine, works.
- Something that describes how the IBM 1401 works. At one time, there were "business computers", all decimal, and they were very strange machines.
- Djykstra's original P and V paper.
- Wirth's Pascal manual, the one with the compiler listing
- The Bell System Technical Journal issue that describes UNIX.
- Jim Blinn's "A trip down the graphics pipeline", for the basics of classical computer graphics.
The First Draft Report on the EDVAC http://history-computer.com/Library/edvac.pdf
The invention of index registers https://en.wikipedia.org/wiki/Index_register#History
Report on the algorithmic language ALGOL 60 https://sci-hub.do/10.1016/s0066-4138(61)80016-5
HAKMEM https://news.ycombinator.com/item?id=18793554
SAGE https://en.wikipedia.org/wiki/Semi-Automatic_Ground_Environm...
B5500 https://github.com/pkimpel/retro-b5500 https://en.wikipedia.org/wiki/Burroughs_large_systems#B5000 http://www.retrocomputingtasmania.com/home/projects/burrough...
IBM 1401 https://en.wikipedia.org/wiki/IBM_1401 http://www.columbia.edu/cu/computinghistory/1401.html
P&V https://en.wikipedia.org/wiki/Semaphore_(programming)
PASCAL – User Manual and Report http://seriouscomputerist.atariverse.com/media/pdf/book/Pasc...
The UNIX Time-Sharing System https://archive.org/download/bstj57-6-1905/bstj57-6-1905.pdf
A Trip Down The Graphics Pipeline: The Homogeneous Perspective Transform http://cfile204.uf.daum.net/attach/272FF54D519C8D973525F4
> Computing is pop culture. [...] Pop culture holds a disdain for history. Pop culture is all about identity and feeling like you're participating, It has nothing to do with cooperation, the past or the future—it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from]. - Alan Kay
Changed how I think about my career.
Nike & BLM, Tesla & global warming, Apple and computing without a 1000 page manual.
Nike validated Kaepernick at a moment for the first time that more kids of color are born than white.
https://www.slideshare.net/superbrands_poland/douglas-holt-h...
And of course these sort of people don't actually have any in depth historical knowledge.
I particularly like how he had the insight of making the statement true only for "people who write code for money." Growing up in various computing "scenes" (open source, hacking, demoscene) in the 90's and 2000's, nobody did anything for money. And it seemed everybody had the utmost respect for the history of the scene. Demosceners were all about "old school" stuff and the old Amiga days. Hacking ezines and forums retold the tales of Captain Crunch and other legendary hackers from yore. And the open source community was still full of completely antiquated practices that some would have question but nobody would have dared to disrespect.
Only when I started programming as a job did I encounter people who, strangely, had no interest for such things. There was plenty of enthusiasm for new languages, but little for their genealogy. It really seemed odd to me and I think the lack of love for the "craft" and its history is ultimately what drove me out of industry and to academia.
There are only a couple of fields that are different - media (movies/broadcast), military, medicine. Probably because of the built-in human drama that's easily accessible?
As others have mentioned, Computer Science has a little human drama but few have sacrificed their lives or appeared heroic. It's a pretty dry field to document - more similar to road building.
I have to say, I'm worried. Just in 2020, we lost of a lot of greats, including Jon Conway, Larry Tessler, Chuck Peddle, Bert Sutherland, Frances Allen, most recently Brad Cox. We're losing not just a lot of history, but a lot of the historians themselves, the people to whom can tell the stories that may not have been written down yet.
https://www.computerhistory.org/collections/oralhistories/
Except for Jon Conway, all the other people you mentioned were interviewed.
The rise of open source software is finally letting us view some of that software. But we may never publicly know what some past giants did.
However, it's not generally available (unlike late 20th century literature). If windows sold with the source code (even if you were forbidden from doing anything with it), then we would be reading windows source code in our CS classes.
If you’re learning an algorithm, just stick to pseudocode, otherwise youre stuck with MMIX bullshit.
[edit]
I noticed you mentioned "heap" assuming you're talking about the data-structure, that would probably be in a different class than one where you read windows source code. Just like you probably wouldn't read Joyce in a class on composing newspaper articles.
I still think it's useful to dissect existing code to get an idea of how complicated it really can be. A CS undergrad may graduate without ever reading or writing a single program over 1kloc. Even from an academia perspective, having a concept that real-world software is usually 100s or 1000s of kloc is likely useful.
1) Read the paper's high level description and pseudocode.
2) Write some test cases.
3) Write code based on the paper's pseudocode.
4) Observe that my test case results do not match what the authors show.
4a) Fiddle repeatedly with possible ambiguities in the pseudocode-to-real-code translation until test cases match publication. This involves a certain amount of mind reading and speculation. "They said argmax, but there are possible singularities... maybe argmax followed by clamping."
4b) Request source code from the authors. Upon receiving it, find that their real implementation diverges in small but significant ways from the pseudocode that was published. They have mixed actual-code algorithm outputs with incomplete pseudocode algorithm descriptions in the paper.
Have you ever heard of anyone reaching out of those books, or even read all of them? He maybe heralded because of when we wrote them, but there are much better written books in 2021.
I hate reading pseudocode because I do always have to wonder "what the person writting this had actually on their mind"
an actual source code is literally what's going on.
I've found annotated source code to be an extremely useful learning resource, personally.
There are a few pleasant exceptions. For instance, Neurology Minute have had occassional bits on the history of neurology. See https://neurologyminute.libsyn.com/
However, when reading something historical ( for instance this interesting podcast on the history of the Inverted Brachioradialis Reflex) https://neurologyminute.libsyn.com/history-of-neurology-3-hx..., there is no expectation that it will actually contribute to practice.
South Africa is renowned for grooming some of the world's best doctors (as subjective as this sounds, it is largely owed to the relentless influx of patients in state hospitals and the inevitable hands-on experience that follows).
So practically speaking, you have some very young yet very experienced doctors emerging from the assorted residency programmes and specialisations.
And yet the history is largely overlooked - which is mostly a function of "not enough time to learn this as well" - and I know this because I was fortunate enough to collaborate with a very old and respected Neurologist in Pretoria who has made it his personal mission to collate all the historical tidbits on his field, so that he can pass it on to the next generation.
He has subsequently prepared a rather extensive 2,000+ page archive on the history of Neurology (all manually typed up in his old Word installation), and I'm helping him transpose it onto a an easily searchable website so that his work can live on.
Anyhow your comment reminded me of this, thought I'd share :)
https://blog.eutopian.io/the-next-big-thing-go-back-to-the-f...
We’ve sort of settled on the architecture of our “stack” mostly by historical accident. It has constantly been the local maxima for various variables throughout our short history. And because of the inertia of the mass of what we’ve built that mostly works we don’t look outside very far.
There are a lot of excellent ideas that were too early, or due to a coin toss not taken, or killed because of winner-takes-all market competition, or because they were just some footnote at the bottom of a paper some researcher wrote and never investigated. These ideas are ripe for investigation.
I’ve been reading papers and looking at source code from the early days of programming languages. There was definitely more interplay between the design of the machine’s API (the instruction set) and programming language designers than we see these days. Our ISAs are made to emulate a PDP-11 running C (a glib take I know but not entirely inaccurate). Oh yeah, we also now get an instruction that handles JavaScript floats better. :-)
Another issue is that CS is a branch of applied math that also happens to be extremely profitable. Math operates on much larger timescales than other domains. But business and economics demands immediate attribution. McCulloch and Pitts had their Hebbian neural network almost a century ago. Kleene of the Regex fame designed his neural network in 1951 [0]. These vast timescales are quite normal for advanced mathematics. But in 2010 GPUs became cheap and the obscure theories of the pre-GOFAI age are suddenly immensely profitable. Of course the names and associations would be with their most recent implementors. The ones who actually applied and made it possible, rather than those whom dreamt it up a century ago.
Edit: Meaning there are pretty straightforward reasons to care about history.
Some ideas just need a big engine.
- how far we came in each decade
- how brilliant people had to be to invent ideas that feel obvious to us
- how much people got done with previous decades' technology
- how many times history the consensus of expert opinion mis-predicted the next development
because we want to believe
- the current state of the art is close to perfection than it is to the last generation
- we only have to embrace the obvious
- people who are one step behind the times are at an insurmountable disadvantage to us who are up-to-date
- the future will bring nothing more than a higher perfection of the ideas we embrace now
It's intellectual millennialism. We want to think that the new ideas we receive at the beginning of our career are the final piece of the puzzle, that there's no point in generations beyond us. Our ideas give us special powers to accomplish things that no previous generation could accomplish, and no subsequent generation will accomplish much more, or the same things much easier, than we did. We are standing at the end of history. We are the generation that left the desert and entered the promised land.
History upsets all that. History teaches us that the future will stand in relation to us as we stand in relation to the past, whereas we want to believe that we are equals with the future and superior to the past.
This isn't really about history. This is about ideas which could still be useful today but which have been forgotten, for a variety of reasons.
Most CS departments don't have anyone who specialises in this. And academic historians have other priorities.
Calling this dumbing down doesn't help. It's not about historians "dumbing down" CS, it's about not understanding the difference between what historians do - create narratives - and what archivists and researchers do, which is more closely related to continuing research and development.
Physics actually has the same problem. Anything outside a limited mainstream is forgotten very quickly. Math seems less prone to it, perhaps because math is made of academic papers and nothing else, and there's more of a tradition of open exploration and communication.
Similarly Michael Abrash’s articles on the development of Doom et al.
(Wonder why all these examples are from computer games…)
Our interfaces with computing have changed so radically and many things are legitmately obselete for the majority of us; no one is likely to reach for a punch card or a 3.5" floppy (might be a few edge cases on this one :) ).
Most of this is the facade of computing though and many of underlying fundamentals are the same but I feel that this outward appears of transiency leaves us flippant about the retrospective.
It's not a great comparison but lets look at military history, many of the tactics, and hardware remain the same for decades with design and development taking an significant portion of time. the F35 has been in development for nearly 2 decades and it's only now at the beginning of it's service life.
It’s crazy to think about the carbon we are pumping into the atmosphere in order to do the same computations over and over again. Same goes with layout and rendering on the client. There’s no reason we can’t just do this for a few standard widths and send that static content to the client.
I'd love to see this. Please put it on your webpage Dr. Knuth!
I don't think I've been exposed to it, but I would love to be. Where did you learn about TCS history?
Does anyone know about whom Knuth was referring? Did this have anything to do with the work on the PL/I compiler?
Or accountancy - another old trade with immediate commercial value, though perhaps without as much intellectual property.
Talking in broad strokes about a novel solution that is later patented probably won’t get the patent invalidated. Showing the code for the implementation would.