Let's Not Dumb Down the History of Computer Science (2014) • Hacker News Board

Re: Let's Not Dumb Down the History of Computer Science (2014)

#41

Post by TheOtherHobbes » Thu, Jan 28, 2021, 8:25 AM UTC

username90 wrote: post #2

The main problem seems to be that computer scientists don't care about history. That seems a bit strange to me, since there is no lack of people to analyse the historical parts of mathematics of physics. Maybe the problem is that computer science history doesn't seem like history yet since it is relatively recent?

The main problem is that computer researchers don't always write up their ideas in papers. And source code is hard to read, system dependent - you can't understand it without being familiar with hardware which may not even exist any more - and may be impossible to access.

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.

Re: Let's Not Dumb Down the History of Computer Science (2014)

#42

Post by sanxiyn » Thu, Jan 28, 2021, 8:27 AM UTC

jonathankoren wrote: post #11

aidenn0 wrote: post #7

Earlier quoted context omitted.

Programs source code is just as copyrighted as late 20th century literature. 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.

No we wouldn’t. Source code is notoriously hard to read if you’re not familiar with it, and optimized source code using internal APIs is even harder. If you’re learning an algorithm, just stick to pseudocode, otherwise youre stuck with MMIX bullshit.

MMIX is not bullshit. Knuth is interested in concrete complexity as well as asymptotic complexity, e.g. why quick sort is faster than heap sort, so he needs concrete model of computation. It may be an overkill if you aren't interested in concrete complexity, but it serves a purpose.

Re: Let's Not Dumb Down the History of Computer Science (2014)

#43

Post by saagarjha » Thu, Jan 28, 2021, 8:28 AM UTC

mikewarot wrote: post #27

Unlike Medicine, many of the ideas that we had in the past were better than the commonly accepted way things are done 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 backwar…

Well, better in some sense: they might be cleaner, or more robust on some axis, but perhaps not practical or efficient. But, with computing the landscape can change rapidly so it is always good to see if older ideas can now be made a reality.

Re: Let's Not Dumb Down the History of Computer Science (2014)

#44

Post by fooker » Thu, Jan 28, 2021, 8:28 AM UTC

wernercd wrote: post #38

mikewarot wrote: post #36

Earlier quoted context omitted.

The optimization bottleneck you're fighting against in the game might have been solved 50 years ago, if you don't know history, you don't have a complete toolkit of all the good tools. 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.

I don't need history to know algorithms... so "that was solved 50 years ago" doesn't teach me how to build a balanced node tree or actually matter if I simply know to use sort library method A instead of B. > 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. On…

History is not just about time — what happened when.

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.

Re: Let's Not Dumb Down the History of Computer Science (2014)

#45

Post by sanxiyn » Thu, Jan 28, 2021, 8:28 AM UTC

ed25519FUUU wrote: post #5

dwheeler wrote: post #3

One problem in understanding computer science history is the essentially perpetual copyright laws. It's illegal to view or share many important past programs' source code, a problem not shared by other fields. Imagine discussing literature without being allowed to read it! There are exceptions, but they are exceptions. The rise of open source software is finally letting us view some of that software. But we may never…

Is the actual source code that important? I’m trying to think of what I’m missing. I’m personally more interested in the comments left in the code of some or those old projects than the actual code, which was probably full of bugs and a bit crufty just like the stuff we write today.

Yes it is important. Sometimes details matter, and often the only place details can be found is actual source code.

Re: Let's Not Dumb Down the History of Computer Science (2014)

#46

Post by redis_mlc » Thu, Jan 28, 2021, 8:29 AM UTC

mikewarot wrote: post #27

Unlike Medicine, many of the ideas that we had in the past were better than the commonly accepted way things are done 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 backwar…

> Capability based security, ... They had it at Xerox PARC, but Steve Jobs chose not to take that part.

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.

https://en.wikipedia.org/wiki/Skeuomorph

Re: Let's Not Dumb Down the History of Computer Science (2014)

#47

Post by svat » Thu, Jan 28, 2021, 8:31 AM UTC

bboreham wrote: post #39

I would submit that the “Graphics Gems” series of books does document a lot of rendering techniques in their historical context. They were written to be current for practitioners at the time, but the connections are drawn. Similarly Michael Abrash’s articles on the development of Doom et al.

Also I guess Fabien Sanglard's "Game Engine Black Books" (on Doom and Wolfenstein 3D: https://fabiensanglard.net/gebb/), and John Aycock's book "Retrogame Archeology: Exploring Old Computer Games".

(Wonder why all these examples are from computer games…)

Re: Let's Not Dumb Down the History of Computer Science (2014)

#48

Post by aidenn0 » Thu, Jan 28, 2021, 8:39 AM UTC

jonathankoren wrote: post #26

aidenn0 wrote: post #12

Earlier quoted context omitted.

I mean Joyce is notoriously hard to read, no?

While there is only one Joyce, please tell me how build 627252 of Windows 3.11 glonkglonk.cpp is a unique example that provides more insight into a heap, than five lines of pseudocode.

"Here's 5 lines of pseudocode" "Here's a real-world implementation of the pseudocode. Note this section does not improve the asymptotic case, but has significant constant-factor advantages for small inputs."

[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.

Re: Let's Not Dumb Down the History of Computer Science (2014)

#49

Post by wernercd » Thu, Jan 28, 2021, 8:46 AM UTC

fooker wrote: post #44

wernercd wrote: post #38

Earlier quoted context omitted.

I don't need history to know algorithms... so "that was solved 50 years ago" doesn't teach me how to build a balanced node tree or actually matter if I simply know to use sort library method A instead of B. > 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. On…

History is not just about time — what happened when. 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 definitel…

Well like I said... I enjoy history. but. I've never used history to solve business problems.

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.

Re: Let's Not Dumb Down the History of Computer Science (2014)

#50

Post by jonathankoren » Thu, Jan 28, 2021, 8:47 AM UTC

sanxiyn wrote: post #42

jonathankoren wrote: post #11

Earlier quoted context omitted.

No we wouldn’t. Source code is notoriously hard to read if you’re not familiar with it, and optimized source code using internal APIs is even harder. If you’re learning an algorithm, just stick to pseudocode, otherwise youre stuck with MMIX bullshit.

MMIX is not bullshit. Knuth is interested in concrete complexity as well as asymptotic complexity, e.g. why quick sort is faster than heap sort, so he needs concrete model of computation. It may be an overkill if you aren't interested in concrete complexity, but it serves a purpose.

There’s a reason why no one explains abstract algorithms in assembly. It’s a trash idea, that obscures more than it illuminates. It’s a flex. A flex that is marginally above explaining an algorithm through a wiring diagram of thermionic valves.