4 ms·

I used to work in Common Lisp (SBCL). The ecosystem problem meant something different to me than most. Sure, when new tech came out (Kafka to pick a random exa

I used to work in Common Lisp (SBCL). The ecosystem problem meant something different to me than most. Sure, when new tech came out (Kafka to pick a random example) there wouldn’t be an open source library ready for me. But I had stable infrastructure so I didn’t really care much about that. The ecosystem problem for me meant that if something went wrong I was on my own. It’s a pretty unfortunate feeling to search for a bug and find nothing on Stack Overflow.

kazinator 6y ago
> It’s a pretty unfortunate feeling to search for a bug and find nothing on Stack Overflow. Par for the course in embedded. So isn't going to tell you why the kernel driver for the ABC123 chip is locking up on the XYZ15 eval board from Such-and-Such vendor. You debug it yourself, whipping out JTAG debuggers and oscilloscopes, if necessary. Because I work in embedded, I don't understand the whole ecosystem fuss. I mean, joy of joys, you have the darned source to almost everything nowadays. That makes everything so easy, that all else is a footnote.
- snazz 6y ago
  I'm coming at this from the opposite side. Currently, it feels like most of my programming skills are really just Googling skills and remembering what a particular error message means. The market emphasizes this kind of programming by combining existing libraries and hoping things work, so it's really hard for me to break away from doing that and start to learn the way that stuff works internally. I think that this was the reason that they stopped teaching SICP in Scheme [0]. I can read source code (I do some security research for fun) and use a debugger, but I still feel like I'm programming by poking. What would you recommend to younger programmers to get out of this rut? 0: In this talk at the NYC Lisp meetup, Gerry Sussman was asked why MIT stopped teaching the legendary 6.001 course, which was based on Sussman and Abelson’s classic text The Structure and Interpretation of Computer Programs (SICP). Sussman’s answer was that: (1) he and Hal Abelson got tired of teaching it (having done it since the 1980s). So in 1997, they walked into the department head’s office and said: “We quit. Figure out what to do.” And more importantly, (2) that they felt that the SICP curriculum no longer prepared engineers for what engineering is like today. Sussman said that in the 80s and 90s, engineers built complex systems by combining simple and well-understood parts. The goal of SICP was to provide the abstraction language for reasoning about such systems. Today, this is no longer the case. Sussman pointed out that engineers now routinely write code for complicated hardware that they don’t fully understand (and often can’t understand because of trade secrecy.) The same is true at the software level, since programming environments consist of gigantic libraries with enormous functionality. According to Sussman, his students spend most of their time reading manuals for these libraries to figure out how to stitch them together to get a job done. He said that programming today is “More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?'”. The “analysis-by-synthesis” view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant. Nowadays, we do programming by poking.
  - neutronicus 6y ago
    Edit-[optionally compile]-Run-[optionally step in Debugger] is addictive because the feedback loop is so tight, and it always feels like work. The way to break the addiction is to start working in a domain where there's significant friction to that process. Work on a heavy-ass C++ GUI application that takes forever to load, with a big-ass code base that takes forever to compile, and you'll be thinking deeply about code in no time, because you can't program that sucker by poking when poking takes 40 minutes.
- ashtonkem 6y ago
  I think it’s about alternatives and expectations. In the embedded world you don’t have an alternative, so you expect that pulling out the JTAG debugger will be necessary. On the application side I have tons of alternatives that are extremely well supported, setting the expectation that most of the time I can focus on my application and not something weird like debugging my Postgres driver.

kazinator 6y ago

> It’s a pretty unfortunate feeling to search for a bug and find nothing on Stack Overflow. Par for the course in embedded. So isn't going to tell you why the kernel driver for the ABC123 chip is locking up on the XYZ15 eval board from Such-and-Such vendor. You debug it yourself, whipping out JTAG debuggers and oscilloscopes, if necessary. Because I work in embedded, I don't understand the whole ecosystem fuss. I mean, joy of joys, you have the darned source to almost everything nowadays. That makes everything so easy, that all else is a footnote.

snazz 6y ago
I'm coming at this from the opposite side. Currently, it feels like most of my programming skills are really just Googling skills and remembering what a particular error message means. The market emphasizes this kind of programming by combining existing libraries and hoping things work, so it's really hard for me to break away from doing that and start to learn the way that stuff works internally. I think that this was the reason that they stopped teaching SICP in Scheme [0]. I can read source code (I do some security research for fun) and use a debugger, but I still feel like I'm programming by poking. What would you recommend to younger programmers to get out of this rut? 0: In this talk at the NYC Lisp meetup, Gerry Sussman was asked why MIT stopped teaching the legendary 6.001 course, which was based on Sussman and Abelson’s classic text The Structure and Interpretation of Computer Programs (SICP). Sussman’s answer was that: (1) he and Hal Abelson got tired of teaching it (having done it since the 1980s). So in 1997, they walked into the department head’s office and said: “We quit. Figure out what to do.” And more importantly, (2) that they felt that the SICP curriculum no longer prepared engineers for what engineering is like today. Sussman said that in the 80s and 90s, engineers built complex systems by combining simple and well-understood parts. The goal of SICP was to provide the abstraction language for reasoning about such systems. Today, this is no longer the case. Sussman pointed out that engineers now routinely write code for complicated hardware that they don’t fully understand (and often can’t understand because of trade secrecy.) The same is true at the software level, since programming environments consist of gigantic libraries with enormous functionality. According to Sussman, his students spend most of their time reading manuals for these libraries to figure out how to stitch them together to get a job done. He said that programming today is “More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?'”. The “analysis-by-synthesis” view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant. Nowadays, we do programming by poking.
- neutronicus 6y ago
  Edit-[optionally compile]-Run-[optionally step in Debugger] is addictive because the feedback loop is so tight, and it always feels like work. The way to break the addiction is to start working in a domain where there's significant friction to that process. Work on a heavy-ass C++ GUI application that takes forever to load, with a big-ass code base that takes forever to compile, and you'll be thinking deeply about code in no time, because you can't program that sucker by poking when poking takes 40 minutes.
ashtonkem 6y ago
I think it’s about alternatives and expectations. In the embedded world you don’t have an alternative, so you expect that pulling out the JTAG debugger will be necessary. On the application side I have tons of alternatives that are extremely well supported, setting the expectation that most of the time I can focus on my application and not something weird like debugging my Postgres driver.