←back to thread

1401 points alankay | 2 comments | | HN request time: 0.001s | source

This request originated via recent discussions on HN, and the forming of HARC! at YC Research. I'll be around for most of the day today (though the early evening).
Show context
qwertyuiop924 ◴[] No.11943148[source]
Hey Alan,

You seem very disapointed and upset with the way computing has gone in the last decade. Speaking as a younger (15) and more satisfied (I still think the UNIX abstraction is pretty solid, despite what others may say) programmer, how do you not get depressed about the way technology is going?

Also, what do you propose to eliminate the "re-inventing the flat tire" problem? Should every programmer be forced through a decade of learning all of the significant abstractions, ideas, and paradigms of the last 50 years before they write anything? Because I don't see another solution.

replies(1): >>11945693 #
alankay ◴[] No.11945693[source]
I do get depressed -- how could one not? -- the trick with depression is to not allow it to take you into in-action.

Re: Unix etc. try to imagine computer systems without "operating systems" as they are thought of today (hint: look at the Internet, etc.).

The basic heuristic here is to avoid the "when you criticize something you are implicitly buying into it's very existence!". First try to see if there is anything worth existing! (OSs are not necessary ...)

How long does it take to learn real science? And shouldn't computer science be a real science?

Another way to look at this is that anyone could be a doctor until recently (really recently!) because no one knew what was going on. And a lot of damage was done (and is still being done.) Once some real knowledge is obtained, we can't afford to have random practitioners dabbling into important things. (The idea that this might be OK is another pop culture delusion and desire ...)

replies(2): >>11946855 #>>11958118 #
qwertyuiop924 ◴[] No.11946855[source]
...and I'm not sure I agree. The idea that code from randoms shouldn't be put into critical infrastructure is certainly true. But the idea that people shouldn't tinker, hack on code, and learn, even if they end of with non-optimal, possibly broken code, is a dangerous one, because that's how people learn. And yes, they should dabble in important things. How else do they learn them. It's then our job, as the Real World, to analyze our dependancies, and make sure we can trust them to be well written, and that they aren't just toys.

As for whether operating systems are necessary, by most common definitions (being, as I understand it, a set of software that defines a common base of abstractions over hardware, so as to allow multiple other pieces of software to access said hardware at a higher level of abstraction), yes, they are, if you don't want to go mad. But I get the feeling that isn't what you meant...

In short, I can respect your opinions, but I do not agree with all of them. Much of this derives from the mindset that tinkering with even the most important things, regardless of skill, is important to learning. If that makes me stupid, so be it.

replies(1): >>11946990 #
1. alankay1 ◴[] No.11946990{3}[source]
It's not the learning process that is in question, but the ramifications of really extending the industrial revolution to distributing broken code.

(No language has ever been more set up to allow tinkering with everything for the purpose of learning than Smalltalk -- I think you probably realize this.)

I think most people would not recognize most exiting OSs in use by your definition in your second paragraph.

replies(1): >>11976234 #
2. qwertyuiop924 ◴[] No.11976234[source]
Okay. What is the definition of the OS in your opinion?

And thank you for taking the time to disagree with me respectfully. So many do not.

And I do recognize the tinkering capabilities of smalltalk. This is why I found your points odd.

I have yet to learn Smalltalk. The full environment, as opposed to text editor development feels odd to me, especillay after struggling with monsters like Eclipse. Also, SBE is several years out of date, and there isn't really much in the way of good documentation for those who don't already know what they're doing.