Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cacm.acm.org

Post reply on HN
Print view View original

151–160 of 171 posts

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

#151

Post by jonjacky »

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…

An unusual historical paper from Niklaus Wirth, about many "good and original ideas (that) turned out to be less brilliant than they first appeared."

http://pascal.hansotten.com/uploads/wirth/Good%20Ideas%20Wir...

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

#152

Post by jonjacky »

Sharlin wrote: post #92
andi999 wrote: post #82

Earlier quoted context omitted.

So what? Sometimes ideas have to be reinvented, maybe this time they succeed. There could be two reasons why old ideas (talking about Software here) didnt succeed, one is Hardware wasnt capeable, the other is 'they didnt cross the chasm' - both might be different now (third option, the idea is bad, then one shouldnt do it again of course).

You're still assuming a linear model of history. My point was that history is cyclical, the same trends come and go. Static vs dynamic typing. Thin client vs thick client. Local vs distributed. Key-value vs relational. Monolithic vs micro*. And so on. 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…

This cycle was called the "Wheel of Reincarnation" in this 1968 paper by Myer and Sutherland about display processors.

http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...

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

#153

Post by jecel »

cromwellian wrote: post #54

Wow, He used my wife's portrait of himself. I was there the day she took it, it was the opportunity of a lifetime to meet one of my heroes, and he didn't disappoint. Knuth is incredibly sharp, lightning sharp for his age. He plays Emacs as masterfully as he plays his pipe organ in his home. I watched as he whipped around different buffers of literate programming, as he demoed some new angle on the properties of Sudok…

That is why this project is so important:

https://www.computerhistory.org/collections/oralhistories/

Except for Jon Conway, all the other people you mentioned were interviewed.

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

#154

Post by philipkglass »

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.

A typical experience when I re-implement a technique from an academic paper:

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.

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

#155

Post by jonathankoren »

xorcist wrote: post #95
jonathankoren wrote: post #50

Earlier quoted context omitted.

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.

No one, except Donald Knuth himself, widely regarded as one of the best explainers of algorithms we have?

I don’t think agreeing that no one else on the planet writes examples in assembly is the dunk you think it is.

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.

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

#156

Post by benlivengood »

contingencies wrote: post #137
benlivengood wrote: post #133

Earlier quoted context omitted.

> Isn't this now the standard reality for most desktop and mobile OSs? 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…

All good points. 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 fro…

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

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

#157

Post by blt »

contingencies wrote: post #123
Animats wrote: post #29

Earlier quoted context omitted.

Suggested reading. This will take some searching. - "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 ver…

As We May Think https://www.theatlantic.com/magazine/archive/1945/07/as-we-m... 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.…

Thanks for collecting the links, and to Animats for the great list!

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

#158

Post by andredz »

vector_spaces wrote: post #79
mikewarot wrote: post #35

Earlier quoted context omitted.

Look at the recent talks by Alan Kay, Ted Nelson, Joe Armstrong on YouTube. Watch "The Mother of all Demos" by Douglass Engelbart. 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 idea…

One of my favorite talks by Joe Armstrong -- computer science, a guide for the perplexed. He talks through what he feels are some important but forgotten ideas in CS https://youtu.be/rmueBVrLKcY

Thank you. This was great.

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

#159

Post by kevinwang »

wittycardio wrote: post #121

Seems to me that there are multiple histories of computing . One is the history of theoretical computer science which I think is what Knuth is referring to. This is actually fairly well preserved in academia and anyone with a CS background should have gone through it. Another is the history of programming, of which we know the origins but off late has become nearly impossible to track. The last is the social history…

> This is actually fairly well preserved in academia and anyone with a CS background should have gone through it.

I don't think I've been exposed to it, but I would love to be. Where did you learn about TCS history?

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

#160

Post by AnimalMuppet »

jerf wrote: post #119
brandmeyer wrote: post #108

Earlier quoted context omitted.

> Although the real problem today is that we need to run programs with less authority than the user running them, 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.

As the old saying goes, you go to war with the army you have. I have a bunch of fantastic solutions to all our problems, if only programmers would work 10 times harder for every line of code, and the project managers would be OK with that, and the business funding it would be OK with that, and society would be OK with getting 1/10th the software. Capabilities-based stuff is really neat , but it's also really complica…

It's worse than that. You implement your perfect, minimum capability system. Your programmers really implement that. Everything's great...

... until someone from marketing shows up, and says, "Hey, we also need it to...", and the program now needs a bunch of new capabilities.

Post reply on HN