The Enduring Legacy of Dennis Ritchie (2012) [pdf](cs.columbia.edu)
cs.columbia.edu
The Enduring Legacy of Dennis Ritchie (2012) [pdf]
http://www.cs.columbia.edu/~aho/Talks/12-09-07_DMR.pdf
8 comments
[deleted]
[deleted]
For decades I have loved Ritchie's design aesthetic. Some years ago I met one of his close family members without realizing it and we bonded over our love of both classical studies and indigenous issues. At some point through random chats I talked about what an influence Ritchie was on me. My friend was shocked that I had heard of her relative whom her family considered as a pleasant eccentric, and she was gobsmacked when I told her stories about him that she had heard for countless years from the man himself over the holiday dinner table which everyone had rolled their eyes at. The concept outsiders had heard of him was astonishing. I was similarly amazed that my super smart friend was so close to him. As time proceeded I became something of friends with Dennis, not close, but someone he at least knew and we exchanged some amusing letters and gifts.
When I called my friend to tell her that Dennis had passed away it was the first she heard of it.
Not everyone likes Dennis' design aesthetic but it's been valuable to me in my career to find someone else, someone well known, who had similar predilections.
Dennis was genuinely a wonderful person who had excellent design taste. I miss him though I can still meet with him any time I like by thumbing through the K&R.
When I called my friend to tell her that Dennis had passed away it was the first she heard of it.
Not everyone likes Dennis' design aesthetic but it's been valuable to me in my career to find someone else, someone well known, who had similar predilections.
Dennis was genuinely a wonderful person who had excellent design taste. I miss him though I can still meet with him any time I like by thumbing through the K&R.
I 100% agree with the paper.
However, one should not mistake historical contributions with state of the art needed today. Unix and C are still largely relevant and will continue to be so for a long time, even more so their legacy, but one should not interpret that as if nothing better is needed now. For Unix derivatives, well they evolved and are already largely not the same thing as the historical versions. For the C programming language, it is a way more complicated situation. Of course it evolved too, but I would say not as much, especially in areas (safety) where we now have pressent needs.
C has contributed greatly to the world and will continue so. But don't forget that so does Cobol.
However, one should not mistake historical contributions with state of the art needed today. Unix and C are still largely relevant and will continue to be so for a long time, even more so their legacy, but one should not interpret that as if nothing better is needed now. For Unix derivatives, well they evolved and are already largely not the same thing as the historical versions. For the C programming language, it is a way more complicated situation. Of course it evolved too, but I would say not as much, especially in areas (safety) where we now have pressent needs.
C has contributed greatly to the world and will continue so. But don't forget that so does Cobol.
It also doesn’t signal that any of the options that exist today are not better, too: switching costs are frequently underestimated.
The comments on the MIT approach versus the New Jersey style is interesting considering that by '89 MIT's X Window System was a major contributor to the success of Unix Workstations and the X Windows "Principles" seem a lot like Unix'. https://en.wikipedia.org/wiki/X_Window_System#Principles and https://en.wikipedia.org/wiki/Worse_is_better
"Small is beautiful" -- combined with the principle that each program should do one thing and do it well you the key to improving so many irrationally ambitious software projects.
Except the way it's presented by Aho is farcical. Smalltalk is small and beautiful. Forth is small and beautiful. Scheme is small and beautiful. C is NOT small and beautiful. Unix is NOT small and beautiful.
Aho is going off the cliff here. To me this looks more like a no holds-barred whitewashing than a eulogy. Richard Gabriel (to say nothing of the MIT crowd) was absolutely right, and it's painful to see him so easily dismissed. We should lament C and Unix being so prevalent today, not wear them like a badge of honor.
Aho is going off the cliff here. To me this looks more like a no holds-barred whitewashing than a eulogy. Richard Gabriel (to say nothing of the MIT crowd) was absolutely right, and it's painful to see him so easily dismissed. We should lament C and Unix being so prevalent today, not wear them like a badge of honor.
Wait, saying both C and UNIX aren't small and beautiful seems like one major oxymoron. Care to elaborate on those?
IIUC, both of them were created in a small and concise design to perform tasks that most systems of the time failed to hold up to. In fact, the very reason they've endured such long time spans must be enough proof of their beautiful concise yet efficient design. Take any language or operating system today, they just cannot design them without some inspiration or functionality derived from C or UNIX.
Complexity today is insane, take Linux for example, but the darn thing works! The original UNIX was the exact opposite of today's major operating systems in a way, which was designed to perform tasks based on the UNIX philosophy. Linux or any other OS today take complexity to levels the creators of UNIX never foresaw and is one of those aspects they wish today wasn't done. But the world itself has changed since the 70s, and so has Linux too, evolved into having thousands of system calls, whereas the original UNIX had 20.
Complexity today is insane, take Linux for example, but the darn thing works! The original UNIX was the exact opposite of today's major operating systems in a way, which was designed to perform tasks based on the UNIX philosophy. Linux or any other OS today take complexity to levels the creators of UNIX never foresaw and is one of those aspects they wish today wasn't done. But the world itself has changed since the 70s, and so has Linux too, evolved into having thousands of system calls, whereas the original UNIX had 20.
> At the insistence of Doug McIlroy, the early Unix systems had on-line manual pages making the system much easier to learn and use.
I’m reminded of one of my favorite parts of the early UNIX story, the fact that adding the “BUGS” section to man pages was motivation to fix the bugs instead of documenting them. Shame is a powerful motivator.
I’m reminded of one of my favorite parts of the early UNIX story, the fact that adding the “BUGS” section to man pages was motivation to fix the bugs instead of documenting them. Shame is a powerful motivator.
The requested URL was not found on this web server:
/~aho/Talks/12-09-07_DMR.pdf
Working fine here. Do you have any DNS level blocking going on for which that server could be a false positive? Alternately (but probably less likely) they may be moving things around and a DNS change hasn't propagated to your upstream resolvers yet. What address does the server name resolve to at your location?
Could also mean they have multiple addresses for that name and not all of them point to a host with that file. I'm not in a position to try check that ATM.
Could also mean they have multiple addresses for that name and not all of them point to a host with that file. I'm not in a position to try check that ATM.
A 404 is a server side error.
... which can result from the wrong server being asked to fulfill a request due to DNS issues.
I've seen blocking implemented by responding with another server address that is supposed to give some meaningful responses (an "ad blocked" image instead of the user just getting an unable-to-load image icon, for instance). This is getting less useful as HTTPS becomes more ubiquitous as you need to install your own signing key on the client machines to pull it off and it isn't often with the hassle, but it is still sometimes attempted.
I've also seen DNS level blocking send out 127.0.0.1 which strikes me as stupid.
I've seen blocking implemented by responding with another server address that is supposed to give some meaningful responses (an "ad blocked" image instead of the user just getting an unable-to-load image icon, for instance). This is getting less useful as HTTPS becomes more ubiquitous as you need to install your own signing key on the client machines to pull it off and it isn't often with the hassle, but it is still sometimes attempted.
I've also seen DNS level blocking send out 127.0.0.1 which strikes me as stupid.
All of the things outlined could result in them asking for the document from the wrong server.
Works fine here too.
Works fine here too.
DNS blocking doesn't result in a random server being chosen to get a 404 from it results in a connection error. Works fine for me as well, I'm just pointing out the 404 error didn't come from blocking the server.
If it's redirecting to 127.0.0.1 or a local LAN IP or a local proxy or... lots of things that could cause a 404 resulting from confused DNS.
I had the same issue, but the Wayback link works:
https://web.archive.org/web/20191013203137/http://www.cs.col...
https://web.archive.org/web/20191013203137/http://www.cs.col...
[deleted]
What a sublime and witty joke.
Dennis replied: I don’t know. I never had to learn C."