4 ms·

What I remember the most about Jobs' death are 2 things: 1) Most of the media did an heavy coverage of his death and legacy. 2) Exactly 1 week after his death

What I remember the most about Jobs' death are 2 things: 1) Most of the media did an heavy coverage of his death and legacy. 2) Exactly 1 week after his death one of my personal heroes died too: Dennis MacLister Ritchie. Almost no one paid attention. From computers to micro-controllers, from satellites to abs breaks, Ritchie's legacy goes far deeper and wider than Jobs'. Almost every programmer today touches some of his legacy every day at work. However very few magazines and newspapers mentioned him. I suspect that, even here at HN, many programmers don't even know who he was. I think that's sad... * Edit: Dennis Ritchie and Ken Thompson created the most influential, revolutionary and innovative software system in history, the Unix operating system. He also created the most influential of all programming languages, C.

soperj 5y ago
Dennis Ritchie's book on C is pretty well required reading for anyone going through a computer science program no?
- sokoloff 5y ago
  I suspect there are CS programs that don’t even teach C at this point.
  - soperj 5y ago
    That seems really weird to me. We even did a machine language course even though we will never do any machine language programming. It's good to understand what the hell is going on. C is amazing in explaining how memory management works, since you have to do it all yourself.
    - float4 5y ago
      For an undergrad course on compilers that I took, I had to build a parser, implement a state machine and a few other things. All in Haskell. For my master's I took a course on static analysis, for which we had to perform usage analysis, type error diagnosis, implement a type checker etc. All in... Haskell.
      - soperj 5y ago
        We did something similar, not in Haskell unfortunately. We did have a programming languages class that introduced us to haskell. It seems so damn intuitive. As a web developer though there just isn't the support for that language unfortunately.
    - robotresearcher 5y ago
      C teaches you how PDP11 memory management works. Modern PC/server hardware doesn't work like this, neither do modern applications that use accelerators, and while the system works hard to present this virtual address space to your runtime, you don't need to think about it in many languages, from LISP to Swift. Most devs write Javascript. I say this as a person who loves C and taught it lovingly to undergrads for many years. Embedded system programming is a lovely niche, but we don't need to design CS curricula around it.
      - soperj 5y ago
        I would hope you wouldn't be designing cs curricula around javascript, because even javascript frameworks are moving to typescript. This seems like not teaching calculus because you can do it on a calculator. I didn't do a degree that focused on C development, but I still had to know how to do it. God forbid any of your graduates end up working on an operating system at some point.
        robotresearcher 5y ago
        > I would hope you wouldn't be designing cs curricula around javascript I didn't propose that. I'd expect a good curriculum to expose students to several languages, so that picking up another one is not an ordeal.
    - Jetrel 5y ago
      Someone beat me to the punch, but yeah, at this point, C barely works the way actual computers work under the hood. It works the way a PDP-11 does, and most modern computers have been forced (even at the CPU level) to basically act as PDP-11 emulators. Take, for example, the entire stack-and-heap thing. That's not a bedrock feature of computing; it's merely a thing that was particularly convenient to do on a PDP-11. But if you're working in C, you have to do it - so it stays a "seemingly bedrock" feature even if the hardware has drifted far from the PDP-11. A lot of these features boiled down to the ISA making it fairly convenient to do them that way - there were built-in instructions that made it pretty easy to "color-by-numbers" and get the job done. --- This is similar to how we (societally) did barely any woodworking with screws before we had the industrial processes (like lathes or whatnot) to make them. Nails weren't some magic ground-truth or axiom of woodcrafting - it was just obscenely difficult to craft a screw, so why would anyone in their right mind attempt to build something with them?
      - soperj 5y ago
        Screws are a terrible way to build something still though compared to a properly fitted mortise & tenon.
  - solveit 5y ago
    I went through the joint honours degree in mathematics and computer science at Oxford (that's basically a particularly rigid double major for people unfamiliar with the British system). I did not learn C, mostly because I spent a good deal of effort trying to stay as far from actual implementations as possible, but I'm sure it's quite possible for even straight CS students to not learn C. I don't believe that any required courses (which in particular does not include a course on operating systems) use C.
  - 908B64B197 5y ago
    The ones that matter do. If a CS/Engineering program doesn't have an OS class with non-trivial labs in C, it's simply not serious and a red flag on a resume.
    - sokoloff 5y ago
      I looked over the degree requirements for an MIT 6-3 (Comp Sci part of EECS) degree and it looks to me like you can get one without taking a course in C. Maybe MIT EECS "doesn't matter", but I doubt that.
      - 908B64B197 5y ago
        Peeking at the course required[0], it's hard to avoid microcontrollers. Furthermore, 6.004[1] looks like it has to involve C at some point. [0] http://catalog.mit.edu/degree-charts/computer-science-engineering-course-6-3/ http://catalog.mit.edu/degree-charts/computer-science-engine... [1] http://catalog.mit.edu/search/?P=6.004 http://catalog.mit.edu/search/?P=6.004
    - soperj 5y ago
      You are probably my least favourite poster on here, but I agree with you here.
- mattnewton 5y ago
  It was not for me; C wasn’t even taught outside of an elective on operating systems, the main CS course was mostly Java and python with one quarter focused on C++.
  - soperj 5y ago
    That's really sad. I mean, we weren't actually taught any programming language, but we had courses that required C, so the Ritchie & Kernighan book was part of the deal.
- approxim8ion 5y ago
  It wasn't in my program. There was a lousy textbook that is only popular among engineering programs in my country, and only a few offhanded mentions of K&R.
- wheelinsupial 5y ago
  Depends on the instructor. Some profs where I studied will assign K&R C for reading and others will use King's C Programming: A Modern Approach. King is a much more gentle introduction IMO.
outside1234 5y ago
Really? I mourned Ritchie's passing much more than Jobs. I think perhaps the reason it feeling like that is that Jobs was a figure that consumers knew, but I definitely think folks in engineering mourn Ritchie's passing more.
disneygibson 5y ago
Ritchie’s contribution was so fundamental that it was almost impossible to actually recognize his achievements. It’s like honoring the guy that invented the pencil. Jobs, on the other hand, ran a company that sold products which billions of people knowingly interacted with on a daily basis. No need to compare the two. One built the foundation, the other built the pretty house on top of it.
- musicale 5y ago
  > One built the foundation, the other built the pretty house on top of it. Though the original Mac didn't use UNIX or C. ;-)
philwelch 5y ago
Steve Jobs was a celebrity. Celebrities are, well, celebrated. People who do important work don't necessarily become celebrities. I used to find that deeply unfair, but I'm not sure being well-known among the common populace is necessarily something to be desired in the first place.
Jetrel 5y ago
The thing that made Jobs consequential was the old Henry Ford-ism of "If I'd asked people what they wanted, they'd have asked for a faster horse." Dennis Ritchie did a damn fine job making what he did, but what he did was essentially just going with the flow; unix and C are like selling sugar to bees. They essentially "sell themselves"; they have qualities that programmers look at and inherently go "I want that!". What Jobs did was going against the flow. I'm going to go ahead and say something outrageous: we wouldn't have gui software without him. Or more accurately; it would be about as common as Lisp or Smalltalk. You'd have these isolated islands of gui development for a few specialist apps, but it would basically be workstation stuff, because only dedicated, specialist machines would be capable of running it. What he understood was that most changes in technology aren't caused by historical inevitabilities or meritocratic ascendence of technology that's ready for prime-time, but are caused by social factors. GUIs had been technologically ready for years, but would only take off with the right social factors. One of these was to have a platform where all machines were guaranteed to have all the necessary ingredients to support GUIs; it was "safe" as a developer to do that, because you knew the entire addressable market could run your stuff. Furthermore, they took the "crazy" additional step of expressly forbidding non-gui ports from other platforms for a few years, and kept it quite difficult to do after that embargo ended. They adamantly wanted people to come up with brand-new, gui-based solutions to common app categories, rather than just porting over some famous app from a command-line paradigm. This was critical - both MS Word, and Excel were born in that environment (yes, as mac programs, first), and it was particularly because Excel didn't get stabbed in the cradle by now-forgotten juggernauts like VisiCalc. If VisiCalc had been ported to the original mac, Excel wouldn't have stood a chance. But that's emblematic of what it actually would have been like: if VisiCalc even could have been ported, that's what 90% of mac software would have been - command-line apps. Even native, non-ported apps are would have been mostly command-line apps, because they're just plain easier to write. At that point, it's not a Mac - it's not even a GUI machine then, and why would you even buy it if it didn't do anything unique? They had to artificially prevent that to "jump-start" us into a world where everything would actually all be gui stuff, across-the-board, no matter what, to allow us to experience what that's actually like. ---- That was the trick; it was a "gateway drug". Once you'd bought a machine to run Excel or Word, suddenly you had the ground conditions that made it possible for something like Photoshop or PageMaker to exist. You couldn't make a business out of apps like these without a large market of people already "forced" to be 100% gui-and-mouse. Spreadsheets are possible on a commandline, if awkward. Drawing apps (not plotting apps, drawing apps) are impossible without a mouse. And without that captive market, the business case to dare making them couldn't be made, nor could the "hey, that's only $100, let's buy that on a lark because I've already got a machine that can run it" rationale be possible. This wasn't an accident. This was planned. Much like a competent city planner; this wasn't a historical accident, but was a deliberate consequence of choices intended to achieve it. Jobs saw exactly what socio-political-economic forces were preventing this from happening, and set up an "artificial greenhouse" where these proverbial plants could take root, and grow big enough to survive outside the greenhouse. ---- Another great example of social forces like this was phone app stores. We've had the tech to do (considerably simpler, but functionally similar) ones as early as 1995. Early Nokia phones easily could have done gameboy-level (or palmpilot-tier) apps on a mobile store, but somehow, nothing like that happened. For decades. It simply was not a technological problem - it was a social and political problem. The phone vendors expressly forbade any app distribution, period. Apps were pre-bundled (and hard-locked) on phones as selling perks to move the hardware, not as a fungible quantity of their own. Only a political deal, an "offer they couldn't refuse", was capable of breaking that logjam. Apple had to play the phone companies against each other, using a new piece of hardware that wouldn't remain novel for more than a few years, and using that as a bargaining chip to demand control-transfer over the software part of the phone. Famously, several of the most successful carriers like Verizon told them to (and I quote) "go f** themselves". Only a back-bench carrier, Cingular (later bought by AT&T) was willing to humor them, but once that Pandora's box was opened, the reluctance of all the other phone vendors quickly caved. After that, because they wanted to ensure Apple wouldn't achieve hegemony over the OS supply, they quickly became favorable towards allowing other phone OSes "with app distributions" to exist. But it's exactly that - goading the phone companies into a position where they were "politically inclined to allow app markets to exist" that was Job's genius. We wouldn't have "not had Android because there wouldn't have been an iPhone to copy". We would have not had Android because the phone carriers would never have allowed it to exist. Nobody would be allowed to sell it - we'd all be stuck on embedded symbian-or-whatever stuff with apps pre-flashed into the firmware. ---- Politics is the greatest barrier to tech innovation. Not "actually creating the tech". Jobs was "the politician we needed". There's an EXTREMELY similar schtick with Elon Musk and SpaceX. Politics are the number one reason NASA and Boeing et al couldn't develop reusable rockets. It's particularly ironic in that case, because those companies had, in many cases, literally the very people who later made the breakthroughs, but those people simply were not allowed to spend their time working on it, at those companies. For almost half a century, in that case. That's how technological stagnation happens.

soperj 5y ago

Dennis Ritchie's book on C is pretty well required reading for anyone going through a computer science program no?

sokoloff 5y ago
I suspect there are CS programs that don’t even teach C at this point.
- soperj 5y ago
  That seems really weird to me. We even did a machine language course even though we will never do any machine language programming. It's good to understand what the hell is going on. C is amazing in explaining how memory management works, since you have to do it all yourself.
  - float4 5y ago
    For an undergrad course on compilers that I took, I had to build a parser, implement a state machine and a few other things. All in Haskell. For my master's I took a course on static analysis, for which we had to perform usage analysis, type error diagnosis, implement a type checker etc. All in... Haskell.
    - soperj 5y ago
      We did something similar, not in Haskell unfortunately. We did have a programming languages class that introduced us to haskell. It seems so damn intuitive. As a web developer though there just isn't the support for that language unfortunately.
  - robotresearcher 5y ago
    C teaches you how PDP11 memory management works. Modern PC/server hardware doesn't work like this, neither do modern applications that use accelerators, and while the system works hard to present this virtual address space to your runtime, you don't need to think about it in many languages, from LISP to Swift. Most devs write Javascript. I say this as a person who loves C and taught it lovingly to undergrads for many years. Embedded system programming is a lovely niche, but we don't need to design CS curricula around it.
    - soperj 5y ago
      I would hope you wouldn't be designing cs curricula around javascript, because even javascript frameworks are moving to typescript. This seems like not teaching calculus because you can do it on a calculator. I didn't do a degree that focused on C development, but I still had to know how to do it. God forbid any of your graduates end up working on an operating system at some point.
      - robotresearcher 5y ago
        > I would hope you wouldn't be designing cs curricula around javascript I didn't propose that. I'd expect a good curriculum to expose students to several languages, so that picking up another one is not an ordeal.
  - Jetrel 5y ago
    Someone beat me to the punch, but yeah, at this point, C barely works the way actual computers work under the hood. It works the way a PDP-11 does, and most modern computers have been forced (even at the CPU level) to basically act as PDP-11 emulators. Take, for example, the entire stack-and-heap thing. That's not a bedrock feature of computing; it's merely a thing that was particularly convenient to do on a PDP-11. But if you're working in C, you have to do it - so it stays a "seemingly bedrock" feature even if the hardware has drifted far from the PDP-11. A lot of these features boiled down to the ISA making it fairly convenient to do them that way - there were built-in instructions that made it pretty easy to "color-by-numbers" and get the job done. --- This is similar to how we (societally) did barely any woodworking with screws before we had the industrial processes (like lathes or whatnot) to make them. Nails weren't some magic ground-truth or axiom of woodcrafting - it was just obscenely difficult to craft a screw, so why would anyone in their right mind attempt to build something with them?
    - soperj 5y ago
      Screws are a terrible way to build something still though compared to a properly fitted mortise & tenon.
- solveit 5y ago
  I went through the joint honours degree in mathematics and computer science at Oxford (that's basically a particularly rigid double major for people unfamiliar with the British system). I did not learn C, mostly because I spent a good deal of effort trying to stay as far from actual implementations as possible, but I'm sure it's quite possible for even straight CS students to not learn C. I don't believe that any required courses (which in particular does not include a course on operating systems) use C.
- 908B64B197 5y ago
  The ones that matter do. If a CS/Engineering program doesn't have an OS class with non-trivial labs in C, it's simply not serious and a red flag on a resume.
  - sokoloff 5y ago
    I looked over the degree requirements for an MIT 6-3 (Comp Sci part of EECS) degree and it looks to me like you can get one without taking a course in C. Maybe MIT EECS "doesn't matter", but I doubt that.
    - 908B64B197 5y ago
      Peeking at the course required[0], it's hard to avoid microcontrollers. Furthermore, 6.004[1] looks like it has to involve C at some point. [0] http://catalog.mit.edu/degree-charts/computer-science-engineering-course-6-3/ http://catalog.mit.edu/degree-charts/computer-science-engine... [1] http://catalog.mit.edu/search/?P=6.004 http://catalog.mit.edu/search/?P=6.004
  - soperj 5y ago
    You are probably my least favourite poster on here, but I agree with you here.
mattnewton 5y ago
It was not for me; C wasn’t even taught outside of an elective on operating systems, the main CS course was mostly Java and python with one quarter focused on C++.
- soperj 5y ago
  That's really sad. I mean, we weren't actually taught any programming language, but we had courses that required C, so the Ritchie & Kernighan book was part of the deal.
approxim8ion 5y ago
It wasn't in my program. There was a lousy textbook that is only popular among engineering programs in my country, and only a few offhanded mentions of K&R.
wheelinsupial 5y ago
Depends on the instructor. Some profs where I studied will assign K&R C for reading and others will use King's C Programming: A Modern Approach. King is a much more gentle introduction IMO.

outside1234 5y ago

Really? I mourned Ritchie's passing much more than Jobs. I think perhaps the reason it feeling like that is that Jobs was a figure that consumers knew, but I definitely think folks in engineering mourn Ritchie's passing more.

disneygibson 5y ago

Ritchie’s contribution was so fundamental that it was almost impossible to actually recognize his achievements. It’s like honoring the guy that invented the pencil. Jobs, on the other hand, ran a company that sold products which billions of people knowingly interacted with on a daily basis. No need to compare the two. One built the foundation, the other built the pretty house on top of it.

musicale 5y ago
> One built the foundation, the other built the pretty house on top of it. Though the original Mac didn't use UNIX or C. ;-)

philwelch 5y ago

Steve Jobs was a celebrity. Celebrities are, well, celebrated. People who do important work don't necessarily become celebrities. I used to find that deeply unfair, but I'm not sure being well-known among the common populace is necessarily something to be desired in the first place.

Jetrel 5y ago

The thing that made Jobs consequential was the old Henry Ford-ism of "If I'd asked people what they wanted, they'd have asked for a faster horse." Dennis Ritchie did a damn fine job making what he did, but what he did was essentially just going with the flow; unix and C are like selling sugar to bees. They essentially "sell themselves"; they have qualities that programmers look at and inherently go "I want that!". What Jobs did was going against the flow. I'm going to go ahead and say something outrageous: we wouldn't have gui software without him. Or more accurately; it would be about as common as Lisp or Smalltalk. You'd have these isolated islands of gui development for a few specialist apps, but it would basically be workstation stuff, because only dedicated, specialist machines would be capable of running it. What he understood was that most changes in technology aren't caused by historical inevitabilities or meritocratic ascendence of technology that's ready for prime-time, but are caused by social factors. GUIs had been technologically ready for years, but would only take off with the right social factors. One of these was to have a platform where all machines were guaranteed to have all the necessary ingredients to support GUIs; it was "safe" as a developer to do that, because you knew the entire addressable market could run your stuff. Furthermore, they took the "crazy" additional step of expressly forbidding non-gui ports from other platforms for a few years, and kept it quite difficult to do after that embargo ended. They adamantly wanted people to come up with brand-new, gui-based solutions to common app categories, rather than just porting over some famous app from a command-line paradigm. This was critical - both MS Word, and Excel were born in that environment (yes, as mac programs, first), and it was particularly because Excel didn't get stabbed in the cradle by now-forgotten juggernauts like VisiCalc. If VisiCalc had been ported to the original mac, Excel wouldn't have stood a chance. But that's emblematic of what it actually would have been like: if VisiCalc even could have been ported, that's what 90% of mac software would have been - command-line apps. Even native, non-ported apps are would have been mostly command-line apps, because they're just plain easier to write. At that point, it's not a Mac - it's not even a GUI machine then, and why would you even buy it if it didn't do anything unique? They had to artificially prevent that to "jump-start" us into a world where everything would actually all be gui stuff, across-the-board, no matter what, to allow us to experience what that's actually like. ---- That was the trick; it was a "gateway drug". Once you'd bought a machine to run Excel or Word, suddenly you had the ground conditions that made it possible for something like Photoshop or PageMaker to exist. You couldn't make a business out of apps like these without a large market of people already "forced" to be 100% gui-and-mouse. Spreadsheets are possible on a commandline, if awkward. Drawing apps (not plotting apps, drawing apps) are impossible without a mouse. And without that captive market, the business case to dare making them couldn't be made, nor could the "hey, that's only $100, let's buy that on a lark because I've already got a machine that can run it" rationale be possible. This wasn't an accident. This was planned. Much like a competent city planner; this wasn't a historical accident, but was a deliberate consequence of choices intended to achieve it. Jobs saw exactly what socio-political-economic forces were preventing this from happening, and set up an "artificial greenhouse" where these proverbial plants could take root, and grow big enough to survive outside the greenhouse. ---- Another great example of social forces like this was phone app stores. We've had the tech to do (considerably simpler, but functionally similar) ones as early as 1995. Early Nokia phones easily could have done gameboy-level (or palmpilot-tier) apps on a mobile store, but somehow, nothing like that happened. For decades. It simply was not a technological problem - it was a social and political problem. The phone vendors expressly forbade any app distribution, period. Apps were pre-bundled (and hard-locked) on phones as selling perks to move the hardware, not as a fungible quantity of their own. Only a political deal, an "offer they couldn't refuse", was capable of breaking that logjam. Apple had to play the phone companies against each other, using a new piece of hardware that wouldn't remain novel for more than a few years, and using that as a bargaining chip to demand control-transfer over the software part of the phone. Famously, several of the most successful carriers like Verizon told them to (and I quote) "go f** themselves". Only a back-bench carrier, Cingular (later bought by AT&T) was willing to humor them, but once that Pandora's box was opened, the reluctance of all the other phone vendors quickly caved. After that, because they wanted to ensure Apple wouldn't achieve hegemony over the OS supply, they quickly became favorable towards allowing other phone OSes "with app distributions" to exist. But it's exactly that - goading the phone companies into a position where they were "politically inclined to allow app markets to exist" that was Job's genius. We wouldn't have "not had Android because there wouldn't have been an iPhone to copy". We would have not had Android because the phone carriers would never have allowed it to exist. Nobody would be allowed to sell it - we'd all be stuck on embedded symbian-or-whatever stuff with apps pre-flashed into the firmware. ---- Politics is the greatest barrier to tech innovation. Not "actually creating the tech". Jobs was "the politician we needed". There's an EXTREMELY similar schtick with Elon Musk and SpaceX. Politics are the number one reason NASA and Boeing et al couldn't develop reusable rockets. It's particularly ironic in that case, because those companies had, in many cases, literally the very people who later made the breakthroughs, but those people simply were not allowed to spend their time working on it, at those companies. For almost half a century, in that case. That's how technological stagnation happens.