4 ms·

> but it saved me from a bunch of tedious work that I don’t enjoy anyway. I play music and find practicing scales and learning music theory much more tedious a

> but it saved me from a bunch of tedious work that I don’t enjoy anyway. I play music and find practicing scales and learning music theory much more tedious and less enjoyable. I'd much rather be playing actual songs and having that flow where it is like the music is just coming out of me. But the reason I do the tedious stuff is because I don't get the latter stuff without the former. I can still learn to play songs without learning scales and just practice the lines. This is much more enjoyable and feels much faster. I'd even argue it is much faster if we're only measuring how fast I learn a single song. But when we talk about learning multiple songs, it is overall slower. Doing the tedious stuff helps me learn the foundation of everything. Without doing the tedious things I'd never develop the skills to sight read or learn to play a song by ear. I don't think this is different with any other skill. I see the same effect in programming. I even see the same effect in writing a single program. I think this is totally a fine strategy for "smaller" programs because the "gap" is small. But as the complexity increases then that gap widens. Most of my time isn't spent writing lines of code, most of my time is spent planning and understanding. Complexity often comes from how a bunch of really simple things interact. The complexity of music is not the literal notes, it is how everything fits together. Personally, I'll take a bit more time to write those lines if it makes me quicker at solving the harder problem. I still write notes on pen and paper even if I never look at them afterwards because the act of writing does a lot to help make those things stick.

tptacek 1y ago
I'm having trouble with this sentiment, because most progress in programming environments involves eliminating and automating away drudgery. The analogy you're making to playing scales and learning music theory applies just as much --- maybe even more so --- to automated memory management!
- PlunderBunny 1y ago
  Not necessarily disagreeing with your points, or the general argument, but I think the trade-offs and consequences of choosing a language with automated memory management are reasonably well understood, and manageable, but can we say the same about vast amounts of AI written code?
  - tptacek 1y ago
    Automated memory management was fiercely debated at the time. So were high-level programming languages, so much so that Paul Graham was moved to write "Beating the Averages".
    - PlunderBunny 1y ago
      Fair enough - I wasn't there at the time. Perhaps (obviously?) we're still at the debating stage of AI assisted coding. But I think we can say we now understand the trade-offs etc around memory managed languages.
      - tptacek 1y ago
        I don't agree, but all of this misses the point I'm making, which is that the stuff AI automates away from you is no more depriving you of practice time than automated memory management, which also wholesale eliminated a huge part of the actual practice of programming. You could literally draw the same analogy to practicing scales with manually writing arena allocators.
    - godelski 1y ago
      I'm a bit surprised that you're surprised by my argument given your awareness of a similar argument in history (which happened quite a few times). It is true that the high-level languages "won out", and now even maybe scripting languages (Python is incredibly popular), but that also doesn't mean the concerns of the time were unwarranted. Many of those concerns did come true. Which, honestly, I don't think anyone was arguing that we couldn't continue moving forward with high level languages, but rather than we'll be able to write code faster but at the expense of hardware and that this can lead to enshitification. Though no one used that exact term. I'm not convinced most professional software isn't extremely resource inefficient and there isn't a lot of enshitification. > Paul Graham was moved to write "Beating the Averages" I mean look at the article This is the same argument you tend to hear for learning Latin. It won't get you a job... but it will improve your mind, and make you a better writer in languages you do want to use, like English. The reason learning Latin helps with English is because you start to learn underlying structures. It would still benefit your English skills even if people spoke it regularly. These are orthogonal properties. It benefited Graham because it was so powerful. But that power is getting you to think with lambda calculus. I know Lisp is a high level language, but there is more to all of this than such a simple reduction. I mean C and C++ are high level programming languages. Even Python was mentioned in that article! So if your takeaway from it was that high level languages are the winners then I think you've missed most of the story. Though I find his article starts to lose coherence as it moves into The Blub Paradox. There's no real definition of "power" and he weirdly is conflating it with how high level a language is. Which plenty of scripting languages like Python and Perl were available at that time. So if he's saying that Lisp was the most powerful, then it isn't about how "high" level the language is, which is the metaphor he moves into. It's so weird to hear his argument about the Blub programmer looking "up" the power continuum and thinking those languages are just as powerful. I think a lot of people think other languages are more powerful than the ones they usually write it (or even know). Hell, it is usually the driving feature to learn a language. The real reason no one writes in Lisp was already answered. No one understands it. And people will make compromises to ensure they can understand one another. This also is a self-reinforcing paradigm though...
fluidcruft 1y ago
I don't find this analogy compelling because practicing scales is an exercise to trains up the cerebellum so that you no longer have to pay close attention to fine motor control and can shift the focus of your attention to higher levels.
- godelski 1y ago
  Music practice does a lot of things, including that. But also, when I'm in a flow state I can often just churn out code the same way. Practice helps take what is system 2 and allow it to be system 1.
avalys 1y ago
Your point is quite valid for people who are new to software engineering, and learning things for the first time. But in this regard I don’t see AI as any different from other tools that have exceeded human capabilities in one way or another. Even though calculators and Mathematica exist, a mathematics student should learn to do arithmetic, long division, calculus, etc. by hand. Even though AI tools (and for that matter, standard libraries) exist that can do it better and faster, a computer science student should still learn to implement a linked list, etc. from scratch. But a professional software engineer will use AI and standard libraries, just like a professional physicist will use a calculator and Mathematica. Calculators existed when I was a kid. I still learned arithmetic without cheating. I’m sure educators will figure out how to teach students software engineering (and writing, and thinking) without cheating.
wglb 1y ago
I don't think the analogy holds. If one thinks of the history of programming, think about the IBM 1401. The first programming was done without the advantage of assembler. Once SPS was introduced, labels for locations were introduced, saving having to learn how to do this. Did one need to learn how to do it the old way to be a good programmer? Certainly not. When Fortran and Cobol were invented, there were those that said you couldn't be a good programmer unless you first mastered machine language. Mastering programming requires managing and overcoming complexity. Building the complex systems that we do today involves many levels of abstractions that few have mastered the totality of. Nor is it necessary. Unless you are Donald Knuth. There was an exchange of opinions between Knuth and Dijkstra about the Goto following the letter titled "Goto Considered harmful". Knuth suggested that some of Dijkstra's later advice and opinions diverged from how Dijkstra himself had learned and practiced programming. I think this is a very common occurrence. We don't remember specifically how we learned to program, and recommend newcomers learn. I think there are far more levels of abstractions in programming than are in music.

tptacek 1y ago

I'm having trouble with this sentiment, because most progress in programming environments involves eliminating and automating away drudgery. The analogy you're making to playing scales and learning music theory applies just as much --- maybe even more so --- to automated memory management!

PlunderBunny 1y ago
Not necessarily disagreeing with your points, or the general argument, but I think the trade-offs and consequences of choosing a language with automated memory management are reasonably well understood, and manageable, but can we say the same about vast amounts of AI written code?
- tptacek 1y ago
  Automated memory management was fiercely debated at the time. So were high-level programming languages, so much so that Paul Graham was moved to write "Beating the Averages".
  - PlunderBunny 1y ago
    Fair enough - I wasn't there at the time. Perhaps (obviously?) we're still at the debating stage of AI assisted coding. But I think we can say we now understand the trade-offs etc around memory managed languages.
    - tptacek 1y ago
      I don't agree, but all of this misses the point I'm making, which is that the stuff AI automates away from you is no more depriving you of practice time than automated memory management, which also wholesale eliminated a huge part of the actual practice of programming. You could literally draw the same analogy to practicing scales with manually writing arena allocators.
  - godelski 1y ago
    I'm a bit surprised that you're surprised by my argument given your awareness of a similar argument in history (which happened quite a few times). It is true that the high-level languages "won out", and now even maybe scripting languages (Python is incredibly popular), but that also doesn't mean the concerns of the time were unwarranted. Many of those concerns did come true. Which, honestly, I don't think anyone was arguing that we couldn't continue moving forward with high level languages, but rather than we'll be able to write code faster but at the expense of hardware and that this can lead to enshitification. Though no one used that exact term. I'm not convinced most professional software isn't extremely resource inefficient and there isn't a lot of enshitification. > Paul Graham was moved to write "Beating the Averages" I mean look at the article This is the same argument you tend to hear for learning Latin. It won't get you a job... but it will improve your mind, and make you a better writer in languages you do want to use, like English. The reason learning Latin helps with English is because you start to learn underlying structures. It would still benefit your English skills even if people spoke it regularly. These are orthogonal properties. It benefited Graham because it was so powerful. But that power is getting you to think with lambda calculus. I know Lisp is a high level language, but there is more to all of this than such a simple reduction. I mean C and C++ are high level programming languages. Even Python was mentioned in that article! So if your takeaway from it was that high level languages are the winners then I think you've missed most of the story. Though I find his article starts to lose coherence as it moves into The Blub Paradox. There's no real definition of "power" and he weirdly is conflating it with how high level a language is. Which plenty of scripting languages like Python and Perl were available at that time. So if he's saying that Lisp was the most powerful, then it isn't about how "high" level the language is, which is the metaphor he moves into. It's so weird to hear his argument about the Blub programmer looking "up" the power continuum and thinking those languages are just as powerful. I think a lot of people think other languages are more powerful than the ones they usually write it (or even know). Hell, it is usually the driving feature to learn a language. The real reason no one writes in Lisp was already answered. No one understands it. And people will make compromises to ensure they can understand one another. This also is a self-reinforcing paradigm though...

fluidcruft 1y ago

I don't find this analogy compelling because practicing scales is an exercise to trains up the cerebellum so that you no longer have to pay close attention to fine motor control and can shift the focus of your attention to higher levels.

godelski 1y ago
Music practice does a lot of things, including that. But also, when I'm in a flow state I can often just churn out code the same way. Practice helps take what is system 2 and allow it to be system 1.

avalys 1y ago

Your point is quite valid for people who are new to software engineering, and learning things for the first time. But in this regard I don’t see AI as any different from other tools that have exceeded human capabilities in one way or another. Even though calculators and Mathematica exist, a mathematics student should learn to do arithmetic, long division, calculus, etc. by hand. Even though AI tools (and for that matter, standard libraries) exist that can do it better and faster, a computer science student should still learn to implement a linked list, etc. from scratch. But a professional software engineer will use AI and standard libraries, just like a professional physicist will use a calculator and Mathematica. Calculators existed when I was a kid. I still learned arithmetic without cheating. I’m sure educators will figure out how to teach students software engineering (and writing, and thinking) without cheating.

wglb 1y ago

I don't think the analogy holds. If one thinks of the history of programming, think about the IBM 1401. The first programming was done without the advantage of assembler. Once SPS was introduced, labels for locations were introduced, saving having to learn how to do this. Did one need to learn how to do it the old way to be a good programmer? Certainly not. When Fortran and Cobol were invented, there were those that said you couldn't be a good programmer unless you first mastered machine language. Mastering programming requires managing and overcoming complexity. Building the complex systems that we do today involves many levels of abstractions that few have mastered the totality of. Nor is it necessary. Unless you are Donald Knuth. There was an exchange of opinions between Knuth and Dijkstra about the Goto following the letter titled "Goto Considered harmful". Knuth suggested that some of Dijkstra's later advice and opinions diverged from how Dijkstra himself had learned and practiced programming. I think this is a very common occurrence. We don't remember specifically how we learned to program, and recommend newcomers learn. I think there are far more levels of abstractions in programming than are in music.