8 ms·

>Surely graduates of MIT, of all places, would be the ones building the libraries that ordinary programmers are stitching together and would still need the abil

>Surely graduates of MIT, of all places, would be the ones building the libraries that ordinary programmers are stitching together and would still need the ability to build complex systems from fundamental CS abstractions? What's going on over there? Ordinary programmers everywhere are building those libraries, just like your assumed wunderkind are building programs out other people's libraries. The nature of programming has changed for >everyone<.

lisper 11y ago
Yes, but the reason it has changed for everyone is that no one understands the fundamentals any more, because they aren't being taught to anyone. The ecosystem is thus becoming infested by horrible hacks which kinda-sorta work, and which everyone uses, because they kinda sorta work, and there is nothing else. The idea that programmers need to understand how to "program by poking" thus becomes a self-fulfilling prophecy. [UPDATE:] One of the symptoms of no one understanding the fundamentals is how excited people get about things like XML and JSON, both of which are just (bad) re-inventions of S-expressions.
- Scramblejams 11y ago
  I'm not sure that it's because no one understands the fundamentals any more. (Which, BTW, the latter part I agree with.) I think it's because everything's gotten too large. You need to use too many frameworks and too many libraries just to get anything done today, and there's simply too much code there (assuming you're even allowed to look at the source!) to comprehend it. I don't like it, but I think it's an unavoidable consequence of computing's evolution into ubiquity.
  - TheOtherHobbes 11y ago
    That's because at some point the industry lost the plot. The fundamentals are fundamental. They don't change very fast. Applications change all the time. So do frameworks. But there's very little genuinely new in most frameworks, or in most languages for that matter. They're mostly repackagings of the same few ideas. Which is why it's a lot easier to pick up applications and do a good job with them if you know the fundamentals than if you're hacking away without any contextual or historical understanding. Meanwhile someone is going to have to do the next generation of pure research, and it's a lot harder to do something creative and interesting in CS if all you've ever known is js, Python, and Ruby. The reality is that software quality is decreasing. Never mind maintainability or even documentation - applications are becoming increasingly buggy and unreliable. It's common in the UK now for bank systems to crash. Ten years ago it was incredibly rare, and twenty years ago it was practically unthinkable. Software is too important to be left to improvisation and busking. So "just learn to make applications from other applications" is not a welcome move.
    - jdjb 11y ago
      I wonder how much of this is due to the idea: 1) non-technical users need to be able to use our software. How much code today is about preventing users from doing something they should know better? 2) we're less and less able to say "no, that goes way beyond the project's scope" to our bosses. Our bosses will quickly reply "yeah well Google's ______ does it, so why can't we?".
      - shitgoose 11y ago
        this is due to the idea that modern sw developers do not care what they do, but care a lot about how they do things. They pay no attention to the business problem at hand (in my experience they get very upset when I try to draw their attention to the business requirements) but spend all their time discussing what *-pad framework is the best candidate.
- mindcrime 11y ago
  The ecosystem is thus becoming infested by horrible hacks which kinda-sorta work, and which everyone uses, because they kinda sorta work, and there is nothing else. Yes, but the reason it has changed for everyone is that no one understands the fundamentals any more, because they aren't being taught to anyone. I mostly agree with both of these statements, but with a slight twist. To some extent, I feel like the reason that "no one understands the fundamentals any more" is simply because the stack has gotten too deep (or the field has gotten too large if you'd rather visualize it that way). That is, no one has time to learn everything all the way from NAND and NOR gates, up to 7400 series IC's, to microprocessors, to assembly language, to C (portable assembly), to operating systems internals, to TCP/IP, HTTP internals, to HTML, and ultimately to Javascript, and also including a side order of databases, filesystems, machine learning/AI, etc. As some point people just have to start treating some lower layers as black box abstractions, so they can actually work. Of course it is always beneficial to try and learn some of the lower level fundamentals, but I just don't see any that for everybody to have full knowledge of an entire application stack from end to end. To me, the best you can do is include fundamentals in an "always keep learning" mindset. That is why, for example, I am still working on learning assembly language (x86/x64) in idle bits of spare time here and there, at the age of 42 and after 20+ years of programming. And why I still go the hackerspace and build circuits from discrete components and low level IC's for fun. But as it happens, for most of my career, not knowing assembly or how to assemble a microcomputer from individual ICs has not prevented me from getting useful stuff done.
  - jff 11y ago
    > learn everything all the way from NAND and NOR gates, up to 7400 series IC's, to microprocessors, to assembly language, to C (portable assembly), to operating systems internals, to TCP/IP, HTTP internals, to HTML, and ultimately to Javascript, and also including a side order of databases, filesystems, machine learning/AI, etc. It's called a Computer Engineering degree, sometimes called EECS (as at MIT). I did it and you can too. The Javascript and HTML were self-taught, admittedly, because they're the easiest parts of that list.
    - mindcrime 11y ago
- deepaksurti 11y ago
  Formally, I think this to be a good list of fudamentals: programing paradigms, algorithms, data structures, compilers, operating systems, networking, math for CS. What else would you recommend adding to the fundamentals list?
  - mac01021 11y ago
    Digital logic and computer architecture.
- taneq 11y ago
  It's not because no-one understands the fundamentals, it's that we require so much functionality to be built in such a short space of time and can afford so much processor time for it, that there's no time to build everything from fundamentals. Thirty years ago you'd build a text editor or modem control interface into your program. Today you need to embed an entire web browser, SQL database, AAA-level game engine etc. Most 'trivial' stitch-some-libraries-together software built today would take decades to create from scratch.
- wmil 11y ago
  People were excited about JSON because there was a desperate need for a data format that wasn't overly complex and/or unsafe to parse. S-expressions just weren't up to snuff because there's no standard way to do key-value mapping.
  - lisper 11y ago
    Sigh. This is exactly the kind of lack of understanding that I'm talking about. > S-expressions just weren't up to snuff because there's no standard way to do key-value mapping. That's not true. There are two standard ways to do this: a-lists and p-lists.
    - djur 11y ago
      "Two standards" isn't much different from "no standard" in this context. JSON was successful because it had a simple spec that almost anyone could implement for any language with virtually no ambiguity. It's not ubiquitous because it's good, it's good because it's ubiquitous. It's another episode in the long history of "worse-is-better".
- Shorel 11y ago
  Heh, it is also a consequence of the web limitations (can't easily replace javascript, or anything else without breaking backwards compatibility) and its associated technologies. You can only poke the browser, not understand it. I find funny that only last year with MVC scaffolding generators I can do forms to access a database just as easily as I was doing them in Foxpro 20 years ago. Yes, now it is client server, safe against common hacking attacks, responsive, etc. But it's been 20 years ! And the productivity valley between both points is abysmal.

lisper 11y ago

Yes, but the reason it has changed for everyone is that no one understands the fundamentals any more, because they aren't being taught to anyone. The ecosystem is thus becoming infested by horrible hacks which kinda-sorta work, and which everyone uses, because they kinda sorta work, and there is nothing else. The idea that programmers need to understand how to "program by poking" thus becomes a self-fulfilling prophecy. [UPDATE:] One of the symptoms of no one understanding the fundamentals is how excited people get about things like XML and JSON, both of which are just (bad) re-inventions of S-expressions.

Scramblejams 11y ago
I'm not sure that it's because no one understands the fundamentals any more. (Which, BTW, the latter part I agree with.) I think it's because everything's gotten too large. You need to use too many frameworks and too many libraries just to get anything done today, and there's simply too much code there (assuming you're even allowed to look at the source!) to comprehend it. I don't like it, but I think it's an unavoidable consequence of computing's evolution into ubiquity.
- TheOtherHobbes 11y ago
  That's because at some point the industry lost the plot. The fundamentals are fundamental. They don't change very fast. Applications change all the time. So do frameworks. But there's very little genuinely new in most frameworks, or in most languages for that matter. They're mostly repackagings of the same few ideas. Which is why it's a lot easier to pick up applications and do a good job with them if you know the fundamentals than if you're hacking away without any contextual or historical understanding. Meanwhile someone is going to have to do the next generation of pure research, and it's a lot harder to do something creative and interesting in CS if all you've ever known is js, Python, and Ruby. The reality is that software quality is decreasing. Never mind maintainability or even documentation - applications are becoming increasingly buggy and unreliable. It's common in the UK now for bank systems to crash. Ten years ago it was incredibly rare, and twenty years ago it was practically unthinkable. Software is too important to be left to improvisation and busking. So "just learn to make applications from other applications" is not a welcome move.
  - jdjb 11y ago
    I wonder how much of this is due to the idea: 1) non-technical users need to be able to use our software. How much code today is about preventing users from doing something they should know better? 2) we're less and less able to say "no, that goes way beyond the project's scope" to our bosses. Our bosses will quickly reply "yeah well Google's ______ does it, so why can't we?".
    - shitgoose 11y ago
      this is due to the idea that modern sw developers do not care what they do, but care a lot about how they do things. They pay no attention to the business problem at hand (in my experience they get very upset when I try to draw their attention to the business requirements) but spend all their time discussing what *-pad framework is the best candidate.
mindcrime 11y ago
The ecosystem is thus becoming infested by horrible hacks which kinda-sorta work, and which everyone uses, because they kinda sorta work, and there is nothing else. Yes, but the reason it has changed for everyone is that no one understands the fundamentals any more, because they aren't being taught to anyone. I mostly agree with both of these statements, but with a slight twist. To some extent, I feel like the reason that "no one understands the fundamentals any more" is simply because the stack has gotten too deep (or the field has gotten too large if you'd rather visualize it that way). That is, no one has time to learn everything all the way from NAND and NOR gates, up to 7400 series IC's, to microprocessors, to assembly language, to C (portable assembly), to operating systems internals, to TCP/IP, HTTP internals, to HTML, and ultimately to Javascript, and also including a side order of databases, filesystems, machine learning/AI, etc. As some point people just have to start treating some lower layers as black box abstractions, so they can actually work. Of course it is always beneficial to try and learn some of the lower level fundamentals, but I just don't see any that for everybody to have full knowledge of an entire application stack from end to end. To me, the best you can do is include fundamentals in an "always keep learning" mindset. That is why, for example, I am still working on learning assembly language (x86/x64) in idle bits of spare time here and there, at the age of 42 and after 20+ years of programming. And why I still go the hackerspace and build circuits from discrete components and low level IC's for fun. But as it happens, for most of my career, not knowing assembly or how to assemble a microcomputer from individual ICs has not prevented me from getting useful stuff done.
- jff 11y ago
  > learn everything all the way from NAND and NOR gates, up to 7400 series IC's, to microprocessors, to assembly language, to C (portable assembly), to operating systems internals, to TCP/IP, HTTP internals, to HTML, and ultimately to Javascript, and also including a side order of databases, filesystems, machine learning/AI, etc. It's called a Computer Engineering degree, sometimes called EECS (as at MIT). I did it and you can too. The Javascript and HTML were self-taught, admittedly, because they're the easiest parts of that list.
  - mindcrime 11y ago
deepaksurti 11y ago
Formally, I think this to be a good list of fudamentals: programing paradigms, algorithms, data structures, compilers, operating systems, networking, math for CS. What else would you recommend adding to the fundamentals list?
- mac01021 11y ago
  Digital logic and computer architecture.
taneq 11y ago
It's not because no-one understands the fundamentals, it's that we require so much functionality to be built in such a short space of time and can afford so much processor time for it, that there's no time to build everything from fundamentals. Thirty years ago you'd build a text editor or modem control interface into your program. Today you need to embed an entire web browser, SQL database, AAA-level game engine etc. Most 'trivial' stitch-some-libraries-together software built today would take decades to create from scratch.
wmil 11y ago
People were excited about JSON because there was a desperate need for a data format that wasn't overly complex and/or unsafe to parse. S-expressions just weren't up to snuff because there's no standard way to do key-value mapping.
- lisper 11y ago
  Sigh. This is exactly the kind of lack of understanding that I'm talking about. > S-expressions just weren't up to snuff because there's no standard way to do key-value mapping. That's not true. There are two standard ways to do this: a-lists and p-lists.
  - djur 11y ago
    "Two standards" isn't much different from "no standard" in this context. JSON was successful because it had a simple spec that almost anyone could implement for any language with virtually no ambiguity. It's not ubiquitous because it's good, it's good because it's ubiquitous. It's another episode in the long history of "worse-is-better".
Shorel 11y ago
Heh, it is also a consequence of the web limitations (can't easily replace javascript, or anything else without breaking backwards compatibility) and its associated technologies. You can only poke the browser, not understand it. I find funny that only last year with MVC scaffolding generators I can do forms to access a database just as easily as I was doing them in Foxpro 20 years ago. Yes, now it is client server, safe against common hacking attacks, responsive, etc. But it's been 20 years ! And the productivity valley between both points is abysmal.