10 ms·

This resonates strongly with me. I don't want to describe the painting, I want to paint it. If this is indeed where we end up, I don't know that I'll change pro

This resonates strongly with me. I don't want to describe the painting, I want to paint it. If this is indeed where we end up, I don't know that I'll change professions (I'm 30+ years into it), but the joy will be gone. It will truly become "just a job".

sanity 3y ago
I remember back in the 80s I had friends who enjoyed coding in assembly and felt that using higher-level languages was "cheating" - isn't this just a continuation of that?
- xandrius 3y ago
  Great point. I think this will weed out the people doing tech purely for the sake of tech and will bring more creative minds who see the technology as a tool to achieve a goal.
  - brailsafe 3y ago
    Indeed, can't wait for the day when technical people can stop relishing in the moments of intimate problem solving between stamping out widgets, and instead spend all day constantly stamping out widgets while thinking about the incredible bullshit they'll be producing for pennies. Thanks boss!
    - xandrius 3y ago
      It feels that people commenting on this post are forgetting that tools have evolved since the times of punch cards or writing only in pure assembly. I personally wouldn't have enjoyed being that kind of programmer as it was a tedious and very slow process, where the creativity of the developer was rather low as the complexities of development would not allow for just anyone to be part of it (my own assumption). Today we have IDEs, autocomplete, quick visual feedback (inspectors, advanced debuggers, etc.) which allow people who enjoy creating and seeing the results of their work as opposed to purely be typing code for someone else. So, I don't get why people jump straight to thinking that adding yet another efficiency tool would destroy everything. To me it seems to make developing simpler applications something which doesn't require a computer science degree, that's all.
      - jimbokun 3y ago
        That’s like saying Shakespeare couldn’t be productive as a writer because he didn’t have a word processor.
        xandrius 3y ago
        So are you saying that you would rather live in a society where only lucky people could participate in a given field than making it accessible to more people?
        copperx 3y ago
        The few people at the rightmost edge of the bell curve shouldn't be used as an example in this case The average attorney became much more productive after the introduction of the word processor.
      - JohnFen 3y ago
        > I personally wouldn't have enjoyed being that kind of programmer as it was a tedious and very slow process, where the creativity of the developer was rather low as the complexities of development would not allow for just anyone to be part of it (my own assumption). I think your assumption is incorrect. I remember programming using punched cards and low-level languages, and the amount of creativity involved was no less than is involved now.
- falcor84 3y ago
  Yeah, that's a good way of looking at it. We gradually remove technical constraints and move to a higher level of abstraction, much closer to the level of the user and the business rather than the individual machine. But what's the endpoint of this? There will probably always be a need for expert-level troubleshooters and optimizers who understand all the layers, but for the rest of us, I'm wondering if the job wouldn't generally become more product management than engineering.
  - rented_mule 3y ago
    I'm not sure that there is an endpoint, only a continuation of the transitions we've always been making. What we've seen as we transitioned to higher and higher level languages (e.g., machine code → macro assembly → C → Java → Python) on unimaginably more powerful machines (and clusters of machines) is that we took on more complex applications and got much more work done faster. The complexity we manage shifts from the language and optimizing for machine constraints (speed, memory, etc.) to the application domain and optimizing for broader constraints (profit, user happiness, etc.). I think LLMs also revive hope that natural languages (e.g., English) are the future of software development (COBOL's dream finally be realized!). But a core problem with that has always been that natural languages are too ambiguous. To the extent we're just writing prompts and the models are the implementers, I suspect we'll come up with more precise "prompt languages". At that point, it's just the next generation of even higher level languages. So, I think you're right that we'll spend more of our time thinking like product managers. But also more of our time thinking about higher level, hard, technical problems (e.g., how do we use math to build a system that dynamically optimizes itself for whatever metric we care about?). I don't think these are new trends, but continuing (maybe accelerating?) ones.
    - nopinsight 3y ago
      > But also more of our time thinking about higher level, hard, technical problems (e.g., how do we use math to build a system that dynamically optimizes itself for whatever metric we care about?). It’s likely that a near-future AI system can suggest suitable math and implement it in an algorithm for the problem the user wants solved. An expert who understands it might be able to critique and ask for a better solution, but many users could be satisfied with it. Professionals who can deliver added value are those who understand the user better than the user themselves.
- elicksaur 3y ago
  The difference is that your friend has a negative view of others than the OP is not presenting. They’re just stating their subjective enjoyment of an activity.
- MisterTea 3y ago
  Boiler plate being eliminated by syntactic sugar or runtime is not the same thing. Sure that made diving in easier but it didn't abstract away the logic design part - the actual programming part. Now the AI spits out code for you without thinking about the logic.
- tejohnso 3y ago
  Seems so. Those friends did have to contend with the enjoyable part of their job disappearing. Whether they called it cheating or not is doesn't diminish their loss.
  - jjmarr 3y ago
    It didn't; there are still many roles for skilled assembly programmers in performance-critical or embedded systems. It's just their market share in the overall world of programming has decreased due to high-level programming languages; although better technology has increased the size of the market that might have demands for assembly.
    - bugbuddy 3y ago
      I am not skilled in these areas so I am very scared. I am going to go back to school to get a nursing degree because it is guaranteed to not be disrupted by the disrupters like now where the disrupters are disrupting themselves. Despite the personal risks of a healthcare job, it will bring me so much more peace of mind.
      - wyclif 3y ago
        I'm afraid it's naive to think that nursing is not going to get disrupted by AI. Seems like robotics is going to massively impact medical caregiving in the near future.
        grugagag 3y ago
        > robotics is going to massively impact medical caregiving in the near future Not in the near near future. Do you know anything about nursing? The field will require some hard changes for robots to replace nurses, and the robots will need licenses
        xnx 3y ago
        Even without robotics, many jobs like nursing (or construction) that require training will be able to be accomplished with much less training + a live computer coach that can give context-specific directions.
- __loam 3y ago
  I think it's a fundamentally different thing, because AI is a leaky abstraction. I know how to write c code but I actually don't know how to write assembly at all. I don't really need to know about assembly to do my job. On the other hand, if I need to inspect the output of the AI to know that it worked, I still need to have a strong understanding of the underlying thing it's generating. That is fundamentally not true of deterministic tools like compilers.
- spit2wind 3y ago
  David Parnas has a great take on this: "Automatic programming always has been a euphemism for programming with a higher level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level languages. Of course automatic programming is feasible. We have known for years that we can implement higher-level programming languages. The only real question was the efficiency of the resulting programs. Usually, if the input 'specification' is not a description of an algorithm, the resulting program is woefully inefficient. I do not believe that the use of nonalgorithmic specifications as a programming language will prove practical for systems with limited computer capacity and hard real-time deadlines. When the input specification is a description of an algorithm, writing the specification is really writing a program. There will be no substantial change from out present capacity. The use of improved languages has led to a reduction in the amount of detail that a programmer must handle and hence to an improvement in reliability. However, extant programming languages, while far from perfect, are not that bad. Unless we move to nonalgorithmic specifications as an input to those systems, I do not expect a drastic improvement to result from this research. On the other hand, our experience in writing nonalgorithmic specifications has shown that people make mistakes in writing them just as they do in writing algorithms." Programming with AI, so far, tries to specify something precise, algorithms, in a less precise language than what we have. If AI programming can find a better way to express the problems we're trying to solve, then yes, it could work. It would become a matter of "how well the compiler works". The current proposals, with AI and prompting, is to use natural language as the notation. That's not better than what we have. It's the difference between Euclid and modern notation, with AI programming being like Euclidean notation and current programming languages being the modern notation: "if a first magnitude and a third are equal multiples of a second and a fourth, and a fifth and a sixth are equal multiples of the second and fourth, then the first magnitude and fifth, being added together, and the third and sixth, being added together, will also be equal multiples of the second and the fourth, respectively." a(x + y) = ax + by You can't make something simpler by making it more complex. https://web.stanford.edu/class/cs99r/readings/parnas1.pdf https://web.stanford.edu/class/cs99r/readings/parnas1.pdf
- nonethewiser 3y ago
  I do think it’s basically the same. Its further on the same continuum of: Natural language/Machine code.
  - jgwil2 3y ago
    I don't really think it's a continuum. There is a continuum of abstraction among programming languages, from machine code to Java/Python/Haskell or whatever, but natural language is fundamentally different: it's ambiguous, ill-defined. Even if LLMs generate a lot of our code in the future, somebody is going to have to understand it, verify its correctness, and maintain it.
    - nonethewiser 3y ago
      Natural language, python, c, assembly The distance isn’t the same between them, but each one is more abstracted than the next. Natural language can be ambiguous and ill defined. Because the compiler is smarter. Just like you don’t have to manage memory in Python, except it abstracts a lot more. The fact is that this very instant you can compile from natural language.
      - jimbokun 3y ago
        There is a vast gulf between natural language and the other 3, which are fundamentally very similar to each other.
      - goatlover 3y ago
        LLMs can generate code, but they still need to be prompted correctly, which requires someone who knows how to program beyond toy examples, since the code is going to have to be tested and integrated into running code. The person will need to understand what kind of code they're trying to generate, and whether that meets the business requirements. Python is closer to C (third generation programming language). Excel is a higher level example. It still takes someone who knows how to use Excel to do anything meaningful.
- temporarely 3y ago
  Not commenting on the mindset of earlier programmers, rather the analogy you offer: language level abstraction is entirely unlike process specialization. For example, when moving up to C from assembler, the task of the "programmer" remains invariant and the language tool affords broader accessibility to the profession since not everyone likes to flip bytes. There is no subdivision of overall task of "coding a software product". With AI coders, there is task specialization, and, as pointed out, what's left on the table is the least appetizing of the software tasks: being a patch monkey. This is the issue.
Aperocky 3y ago
Except that's what low code is today. You'll have to describe it in such detail that you might as well as paint it yourself. Maybe it will abstract away setting up the paint and brush and the canvas, that part I'm fine with though.
- hnick 3y ago
  From the perspective of the programmer, true. Not necessarily from the perspective of the manager/customer, who can say in broad terms what needs to be done, and the programmer-black-box spits something out.
  - PlunderBunny 3y ago
    The manager/customer is going to be very disappointed that the computer can't just "do what I ask it to".
karmakaze 3y ago
Funny you should phrase it this way. I know you mean prompts as description, but I would currently prefer declaring/describing what I want in a higher-level functional way rather than doing all the stateful nitty-gritty iterations to get it done. Some folks want to do manual memory management, or even work with a borrow checker, I'm good for most purposes with gc. The question is always what's your 'description' language and what's your 'painting' language? I see the same in music: DJ's mix and apply effects to pre-recorded tracks, others resample on-the fly, while some produce new music from samples, and others form a collage from generated soundscapes, etc. It's all shades of gray.
the_arun 3y ago
Agreed. But isn't this what is happening over a period for all manual jobs? I mean people used to carve wood. Now, machines do that with more precision & speed. The same goes for laying roads, construction & other professions. All niche jobs will become mundane chores. I don't know if it is good or bad. Because humans always find a way to cultivate something new.
- jimbokun 3y ago
  Only until machines are better at everything humans can do.
- diego_sandoval 3y ago
  Yeah, but those were boring jobs. Programming is fun. I'm only half joking.

sanity 3y ago

I remember back in the 80s I had friends who enjoyed coding in assembly and felt that using higher-level languages was "cheating" - isn't this just a continuation of that?

xandrius 3y ago
Great point. I think this will weed out the people doing tech purely for the sake of tech and will bring more creative minds who see the technology as a tool to achieve a goal.
- brailsafe 3y ago
  Indeed, can't wait for the day when technical people can stop relishing in the moments of intimate problem solving between stamping out widgets, and instead spend all day constantly stamping out widgets while thinking about the incredible bullshit they'll be producing for pennies. Thanks boss!
  - xandrius 3y ago
    It feels that people commenting on this post are forgetting that tools have evolved since the times of punch cards or writing only in pure assembly. I personally wouldn't have enjoyed being that kind of programmer as it was a tedious and very slow process, where the creativity of the developer was rather low as the complexities of development would not allow for just anyone to be part of it (my own assumption). Today we have IDEs, autocomplete, quick visual feedback (inspectors, advanced debuggers, etc.) which allow people who enjoy creating and seeing the results of their work as opposed to purely be typing code for someone else. So, I don't get why people jump straight to thinking that adding yet another efficiency tool would destroy everything. To me it seems to make developing simpler applications something which doesn't require a computer science degree, that's all.
    - jimbokun 3y ago
      That’s like saying Shakespeare couldn’t be productive as a writer because he didn’t have a word processor.
      - xandrius 3y ago
        So are you saying that you would rather live in a society where only lucky people could participate in a given field than making it accessible to more people?
      - copperx 3y ago
        The few people at the rightmost edge of the bell curve shouldn't be used as an example in this case The average attorney became much more productive after the introduction of the word processor.
    - JohnFen 3y ago
      > I personally wouldn't have enjoyed being that kind of programmer as it was a tedious and very slow process, where the creativity of the developer was rather low as the complexities of development would not allow for just anyone to be part of it (my own assumption). I think your assumption is incorrect. I remember programming using punched cards and low-level languages, and the amount of creativity involved was no less than is involved now.
falcor84 3y ago
Yeah, that's a good way of looking at it. We gradually remove technical constraints and move to a higher level of abstraction, much closer to the level of the user and the business rather than the individual machine. But what's the endpoint of this? There will probably always be a need for expert-level troubleshooters and optimizers who understand all the layers, but for the rest of us, I'm wondering if the job wouldn't generally become more product management than engineering.
- rented_mule 3y ago
  I'm not sure that there is an endpoint, only a continuation of the transitions we've always been making. What we've seen as we transitioned to higher and higher level languages (e.g., machine code → macro assembly → C → Java → Python) on unimaginably more powerful machines (and clusters of machines) is that we took on more complex applications and got much more work done faster. The complexity we manage shifts from the language and optimizing for machine constraints (speed, memory, etc.) to the application domain and optimizing for broader constraints (profit, user happiness, etc.). I think LLMs also revive hope that natural languages (e.g., English) are the future of software development (COBOL's dream finally be realized!). But a core problem with that has always been that natural languages are too ambiguous. To the extent we're just writing prompts and the models are the implementers, I suspect we'll come up with more precise "prompt languages". At that point, it's just the next generation of even higher level languages. So, I think you're right that we'll spend more of our time thinking like product managers. But also more of our time thinking about higher level, hard, technical problems (e.g., how do we use math to build a system that dynamically optimizes itself for whatever metric we care about?). I don't think these are new trends, but continuing (maybe accelerating?) ones.
  - nopinsight 3y ago
    > But also more of our time thinking about higher level, hard, technical problems (e.g., how do we use math to build a system that dynamically optimizes itself for whatever metric we care about?). It’s likely that a near-future AI system can suggest suitable math and implement it in an algorithm for the problem the user wants solved. An expert who understands it might be able to critique and ask for a better solution, but many users could be satisfied with it. Professionals who can deliver added value are those who understand the user better than the user themselves.
elicksaur 3y ago
The difference is that your friend has a negative view of others than the OP is not presenting. They’re just stating their subjective enjoyment of an activity.
MisterTea 3y ago
Boiler plate being eliminated by syntactic sugar or runtime is not the same thing. Sure that made diving in easier but it didn't abstract away the logic design part - the actual programming part. Now the AI spits out code for you without thinking about the logic.
tejohnso 3y ago
Seems so. Those friends did have to contend with the enjoyable part of their job disappearing. Whether they called it cheating or not is doesn't diminish their loss.
- jjmarr 3y ago
  It didn't; there are still many roles for skilled assembly programmers in performance-critical or embedded systems. It's just their market share in the overall world of programming has decreased due to high-level programming languages; although better technology has increased the size of the market that might have demands for assembly.
  - bugbuddy 3y ago
    I am not skilled in these areas so I am very scared. I am going to go back to school to get a nursing degree because it is guaranteed to not be disrupted by the disrupters like now where the disrupters are disrupting themselves. Despite the personal risks of a healthcare job, it will bring me so much more peace of mind.
    - wyclif 3y ago
      I'm afraid it's naive to think that nursing is not going to get disrupted by AI. Seems like robotics is going to massively impact medical caregiving in the near future.
      - grugagag 3y ago
        > robotics is going to massively impact medical caregiving in the near future Not in the near near future. Do you know anything about nursing? The field will require some hard changes for robots to replace nurses, and the robots will need licenses
      - xnx 3y ago
        Even without robotics, many jobs like nursing (or construction) that require training will be able to be accomplished with much less training + a live computer coach that can give context-specific directions.
__loam 3y ago
I think it's a fundamentally different thing, because AI is a leaky abstraction. I know how to write c code but I actually don't know how to write assembly at all. I don't really need to know about assembly to do my job. On the other hand, if I need to inspect the output of the AI to know that it worked, I still need to have a strong understanding of the underlying thing it's generating. That is fundamentally not true of deterministic tools like compilers.
spit2wind 3y ago
David Parnas has a great take on this: "Automatic programming always has been a euphemism for programming with a higher level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level languages. Of course automatic programming is feasible. We have known for years that we can implement higher-level programming languages. The only real question was the efficiency of the resulting programs. Usually, if the input 'specification' is not a description of an algorithm, the resulting program is woefully inefficient. I do not believe that the use of nonalgorithmic specifications as a programming language will prove practical for systems with limited computer capacity and hard real-time deadlines. When the input specification is a description of an algorithm, writing the specification is really writing a program. There will be no substantial change from out present capacity. The use of improved languages has led to a reduction in the amount of detail that a programmer must handle and hence to an improvement in reliability. However, extant programming languages, while far from perfect, are not that bad. Unless we move to nonalgorithmic specifications as an input to those systems, I do not expect a drastic improvement to result from this research. On the other hand, our experience in writing nonalgorithmic specifications has shown that people make mistakes in writing them just as they do in writing algorithms." Programming with AI, so far, tries to specify something precise, algorithms, in a less precise language than what we have. If AI programming can find a better way to express the problems we're trying to solve, then yes, it could work. It would become a matter of "how well the compiler works". The current proposals, with AI and prompting, is to use natural language as the notation. That's not better than what we have. It's the difference between Euclid and modern notation, with AI programming being like Euclidean notation and current programming languages being the modern notation: "if a first magnitude and a third are equal multiples of a second and a fourth, and a fifth and a sixth are equal multiples of the second and fourth, then the first magnitude and fifth, being added together, and the third and sixth, being added together, will also be equal multiples of the second and the fourth, respectively." a(x + y) = ax + by You can't make something simpler by making it more complex. https://web.stanford.edu/class/cs99r/readings/parnas1.pdf https://web.stanford.edu/class/cs99r/readings/parnas1.pdf
nonethewiser 3y ago
I do think it’s basically the same. Its further on the same continuum of: Natural language/Machine code.
- jgwil2 3y ago
  I don't really think it's a continuum. There is a continuum of abstraction among programming languages, from machine code to Java/Python/Haskell or whatever, but natural language is fundamentally different: it's ambiguous, ill-defined. Even if LLMs generate a lot of our code in the future, somebody is going to have to understand it, verify its correctness, and maintain it.
  - nonethewiser 3y ago
    Natural language, python, c, assembly The distance isn’t the same between them, but each one is more abstracted than the next. Natural language can be ambiguous and ill defined. Because the compiler is smarter. Just like you don’t have to manage memory in Python, except it abstracts a lot more. The fact is that this very instant you can compile from natural language.
    - jimbokun 3y ago
      There is a vast gulf between natural language and the other 3, which are fundamentally very similar to each other.
    - goatlover 3y ago
      LLMs can generate code, but they still need to be prompted correctly, which requires someone who knows how to program beyond toy examples, since the code is going to have to be tested and integrated into running code. The person will need to understand what kind of code they're trying to generate, and whether that meets the business requirements. Python is closer to C (third generation programming language). Excel is a higher level example. It still takes someone who knows how to use Excel to do anything meaningful.
temporarely 3y ago
Not commenting on the mindset of earlier programmers, rather the analogy you offer: language level abstraction is entirely unlike process specialization. For example, when moving up to C from assembler, the task of the "programmer" remains invariant and the language tool affords broader accessibility to the profession since not everyone likes to flip bytes. There is no subdivision of overall task of "coding a software product". With AI coders, there is task specialization, and, as pointed out, what's left on the table is the least appetizing of the software tasks: being a patch monkey. This is the issue.

Aperocky 3y ago

Except that's what low code is today. You'll have to describe it in such detail that you might as well as paint it yourself. Maybe it will abstract away setting up the paint and brush and the canvas, that part I'm fine with though.

hnick 3y ago
From the perspective of the programmer, true. Not necessarily from the perspective of the manager/customer, who can say in broad terms what needs to be done, and the programmer-black-box spits something out.
- PlunderBunny 3y ago
  The manager/customer is going to be very disappointed that the computer can't just "do what I ask it to".

karmakaze 3y ago

Funny you should phrase it this way. I know you mean prompts as description, but I would currently prefer declaring/describing what I want in a higher-level functional way rather than doing all the stateful nitty-gritty iterations to get it done. Some folks want to do manual memory management, or even work with a borrow checker, I'm good for most purposes with gc. The question is always what's your 'description' language and what's your 'painting' language? I see the same in music: DJ's mix and apply effects to pre-recorded tracks, others resample on-the fly, while some produce new music from samples, and others form a collage from generated soundscapes, etc. It's all shades of gray.

the_arun 3y ago

Agreed. But isn't this what is happening over a period for all manual jobs? I mean people used to carve wood. Now, machines do that with more precision & speed. The same goes for laying roads, construction & other professions. All niche jobs will become mundane chores. I don't know if it is good or bad. Because humans always find a way to cultivate something new.

jimbokun 3y ago
Only until machines are better at everything humans can do.
diego_sandoval 3y ago
Yeah, but those were boring jobs. Programming is fun. I'm only half joking.