6 ms·

the next leap in developer productivity won’t arrive from reducing the drudgery of typing. that wasn’t ever the problem, nor source of bugs or damper on product

the next leap in developer productivity won’t arrive from reducing the drudgery of typing. that wasn’t ever the problem, nor source of bugs or damper on productivity. so long as we still evaluate code in our heads (or pay the expensive compile-run-observe cost) we’re generations behind what architecture has achieved with computers. so long as i can’t evaluate the consequences of any line of code as i write it, dumping lines in industrial quantities is searching under the streetlight.

nextworddev 4y ago
The future of coding is LLMs coding, debugging, and refactoring in a loop. Our job will be mostly design, and intervening occasionally.
- FpUser 4y ago
  New programmers who did not have chance to learn "properly" might not be able of "intervening".
  - Bishonen88 4y ago
    Having no knowledge about assembly doesn’t stop me intervening with my JavaScript apps :) Intervening can be done via LLM in some way I reckon
    - tinkertamper 4y ago
      That’s not really a fair comparison here — A more fitting metaphor would be whether or not you could intervene on assembly code not knowing assembly.
    - FpUser 4y ago
      Who said you need to know assembly. >"Intervening can be done via LLM in some way I reckon" This inspires much confidence
  - manojlds 4y ago
    That's probably what every generation of "older" programmers said - new programmers who did not do assembly will never be able to code etc.
    - WalterBright 4y ago
      > new programmers who did not do assembly will never be able to code etc I see the results from programmers who never learned assembly. Just like repairing and building cars from the ground up makes me a better driver. For example, the clutch in my car lasts a lot longer than it does for other drivers.
      - nolok 4y ago
        Then again, there is no clutch in an EV
        WalterBright 4y ago
        I'm sure batteries and electric motors have their own quirks. For example, battery performance is dependent on temperature.
        manojlds 4y ago
        You are arguing against your point. Everything has its own quirks and no one has it easy or tough.
        wiseowise 4y ago
        It doesn’t have it because it doesn’t need it, not because it somehow built abstraction around it. That’s not the case with modern computers, anything is built on top of everything.
    - FpUser 4y ago
      1) false equivalence. 2) I am an old fart and had never said anything even remotely approaching "who did not do assembly will never be able to code". One can learn programming using any language. However some experience with the languages of multiple level definitely does not hurt. In order to evaluate generated code you have to know how to program.
- yawboakye 4y ago
  i’d rather be the detective of my own murder than another’s. i already struggle to figure out people’s thoughts from the strictures of whatever programming language they express it in. programming languages aren’t symbols of thought, neither do they enjoy the ubiquity of, for example, math notations, unfortunately.
- jghn 4y ago
  Sorta like how in the 90s UML & all the new modeling tools were going to replace the need for actual coding!
- ctoth 4y ago
  Thank you, you're the first person seeming to understand this in this whole darn section. Why does a human need a model of the program in their head when the LLM will be able to fire off 1500 test/debug/fix loops and wait for them to all resolve, then vote on the best answer? For years we've been saying "computer time is cheaper than developer time." Well, that's about to come back to bite us, in a big way.
  - nextworddev 4y ago
    Yes. Like it or not, the days of “typing code” is coming to an end. In fact, may be cheaper for companies to just nuke all existing software and start over
  - dgroshev 4y ago
    Test/debug/fix against what? Writing code is fundamentally not about tests or debugging, it's about formalising informal requirements into hard constraints. To do that, you need to understand business, human, and technical contexts. Without that understanding, you get over engineering, Google Cloud Console, and poor code lacking mechanical sympathy respectively. What's more, often those contexts have competing/incompatible requirements that you need to either evaluate using your idea of your team's values, or escalate, being aware of your own limitations. None of those problems are amenable to modern LLMs. The moment you try to be formal enough to be unambiguous, you start writing code.
pedrosorio 4y ago
Speaking as someone who knows architects working with computers, architecture hasn’t achieved as much with computers as you think.
- jrockway 4y ago
  It goes beyond computing. The way that humans simplify systems is to treat components as black boxes, even though lots of internal details are actually coupled together. When you see a codebase that does this, you think "ewww separation of concerns". But the real world violates this all the time. You want to buy a car. Some company you've never heard of in China makes the chips that detect whether or not your windshield wiper fluid reservoir has fluid. A shipment to the car manufacturer is ready to go out. But, there are no shipping containers. Until the windshield wiper sensor chips arrive, the car factory can't make any cars, and don't have room to unpack the shipping containers with unneeded parts that are piled up outside. So there is no container that can go back to China to bring the chips to the factory. While all that is worked out, SV venture capitalists print some money to give to a used car startup, making it super easy to get the best price on your used car. With no new cars available and flashy discounts to get the market kickstarted, the used car market shoots up, meaning that even though you want a new $60,000 electric car, all you can do is buy a used 1988 Yugo for $150,000. You walk to work, even though you have the money for the car you want. If it's software, this is what we call a pageable event and the postmortem whines about "separation of concerns". But in the real world... well, we don't have those. We LOVE thinking we do, but when shit blows up, it's clear that we don't. So are we really surprised that software works the same way? It's how the Universe works, not bad architecture. The Universe has terrible architecture. Adjust some of those constants and try again!
- yawboakye 4y ago
  architecture has a long history, of course. even if we start from since drafting became standard practice, recent advances like 3d modeling (due to computers) and analyses (satisfying/resolving building code constraints, structural forces, etc) are quantum leaps. in programming, perhaps the type systems (static) and debugger (post-production) gives a similar feeling but not quite. these two aside, the concerns of a c programmer today largely overlaps with those of dennis ritchie & brian kernighan.
AbsoluteCabbage 4y ago
We are still going to evaluate code in our heads. If anything, we need to enhance our capacity to do so. That is where AI can assist. A simple overview or graphical representation of a codebase will be a good start.
- ethbr0 4y ago
  UML is dead! Long live UML!
RoyGBivCap 4y ago
Reminds me of other tools from the past that "allow development with out a developer". With fancy drag and drop UIs that look like circuit diagrams. In trying one you very quickly find out that you still need a developer. Because the easy happy path that the biz analyst thinks of is like 1-10% of what we do. 90% of our job is the plethora of edge cases and sad paths. The retrying. The when not to retry case within the retry case. Does these language model bots help a little? Sure! But my worry of being replaced is currently sitting at like a 3% out of 100%. I expect to still have a job right up until we have AGIs, and quite probably for long after, as not everyone will be able to afford them. That is assuming we have any meaningful control over them.
- emodendroket 4y ago
  I think this is more of a developer productivity tool than a replacement. Like an IDE.
divbzero 4y ago
Are there IDEs that can display compile-run-observe results in real time? A feature where you can set the inputs for a certain function and view the result of each statement in-line as you edit the function?
- skibz 4y ago
  Light Table, which I presume to be defunct, comes to mind. (http://lighttable.com/#features http://lighttable.com/#features) But if you're willing to do without the "as you edit" requirement, then what you're left with is a plain old breakpoint debugger. Certainly, there are many IDEs that have those builtin.
- bo-tato 4y ago
  it's a normal way to develop in clojure. The primitive no-IDE support needed trick is to just define variables with the names of your function inputs, as in: https://blog.michielborkent.nl/inline-def-debugging.html https://blog.michielborkent.nl/inline-def-debugging.html and then you can just evaluate expressions within the function. The fancy way with editor support is: https://github.com/vvvvalvalval/scope-capture-nrepl https://github.com/vvvvalvalval/scope-capture-nrepl you make snapshots of the local variables at any point, and later evaluate code in the context of that snapshot. So you do some action in your program that results in that function being called, it'll save the input, you select that snapshot, and now you evaluate in the context of those function arguments as you edit and eval expressions in the function. And while clojure supports interactive development at a level beyond other mainstream languages, Smalltalk and Common Lisp have support for it on another level, for example: https://malisper.me/category/debugging-common-lisp/ https://malisper.me/category/debugging-common-lisp/ There's some study where Smalltalk came out as the most productive language, I don't know whether it's more productive but that kind of interactive development where you build up your program evaluating it the whole time, without ever restarting, is a lot of fun. Why it went out of style I don't know
  - Qem 4y ago
    > There's some study where Smalltalk came out as the most productive language, I don't know whether it's more productive but that kind of interactive development where you build up your program evaluating it the whole time, without ever restarting, is a lot of fun. I think it's this paper: https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirt...
emodendroket 4y ago
My experience with this type of tool is it does help with some types of very repetitive code (wordy idioms, test code, etc.) or with using unfamiliar libraries. But yeah it's limited in other contexts.

nextworddev 4y ago

The future of coding is LLMs coding, debugging, and refactoring in a loop. Our job will be mostly design, and intervening occasionally.

FpUser 4y ago
New programmers who did not have chance to learn "properly" might not be able of "intervening".
- Bishonen88 4y ago
  Having no knowledge about assembly doesn’t stop me intervening with my JavaScript apps :) Intervening can be done via LLM in some way I reckon
  - tinkertamper 4y ago
    That’s not really a fair comparison here — A more fitting metaphor would be whether or not you could intervene on assembly code not knowing assembly.
  - FpUser 4y ago
    Who said you need to know assembly. >"Intervening can be done via LLM in some way I reckon" This inspires much confidence
- manojlds 4y ago
  That's probably what every generation of "older" programmers said - new programmers who did not do assembly will never be able to code etc.
  - WalterBright 4y ago
    > new programmers who did not do assembly will never be able to code etc I see the results from programmers who never learned assembly. Just like repairing and building cars from the ground up makes me a better driver. For example, the clutch in my car lasts a lot longer than it does for other drivers.
    - nolok 4y ago
      Then again, there is no clutch in an EV
      - WalterBright 4y ago
        I'm sure batteries and electric motors have their own quirks. For example, battery performance is dependent on temperature.
        manojlds 4y ago
        You are arguing against your point. Everything has its own quirks and no one has it easy or tough.
      - wiseowise 4y ago
        It doesn’t have it because it doesn’t need it, not because it somehow built abstraction around it. That’s not the case with modern computers, anything is built on top of everything.
  - FpUser 4y ago
    1) false equivalence. 2) I am an old fart and had never said anything even remotely approaching "who did not do assembly will never be able to code". One can learn programming using any language. However some experience with the languages of multiple level definitely does not hurt. In order to evaluate generated code you have to know how to program.
yawboakye 4y ago
i’d rather be the detective of my own murder than another’s. i already struggle to figure out people’s thoughts from the strictures of whatever programming language they express it in. programming languages aren’t symbols of thought, neither do they enjoy the ubiquity of, for example, math notations, unfortunately.
jghn 4y ago
Sorta like how in the 90s UML & all the new modeling tools were going to replace the need for actual coding!
ctoth 4y ago
Thank you, you're the first person seeming to understand this in this whole darn section. Why does a human need a model of the program in their head when the LLM will be able to fire off 1500 test/debug/fix loops and wait for them to all resolve, then vote on the best answer? For years we've been saying "computer time is cheaper than developer time." Well, that's about to come back to bite us, in a big way.
- nextworddev 4y ago
  Yes. Like it or not, the days of “typing code” is coming to an end. In fact, may be cheaper for companies to just nuke all existing software and start over
- dgroshev 4y ago
  Test/debug/fix against what? Writing code is fundamentally not about tests or debugging, it's about formalising informal requirements into hard constraints. To do that, you need to understand business, human, and technical contexts. Without that understanding, you get over engineering, Google Cloud Console, and poor code lacking mechanical sympathy respectively. What's more, often those contexts have competing/incompatible requirements that you need to either evaluate using your idea of your team's values, or escalate, being aware of your own limitations. None of those problems are amenable to modern LLMs. The moment you try to be formal enough to be unambiguous, you start writing code.

pedrosorio 4y ago

Speaking as someone who knows architects working with computers, architecture hasn’t achieved as much with computers as you think.

jrockway 4y ago
It goes beyond computing. The way that humans simplify systems is to treat components as black boxes, even though lots of internal details are actually coupled together. When you see a codebase that does this, you think "ewww separation of concerns". But the real world violates this all the time. You want to buy a car. Some company you've never heard of in China makes the chips that detect whether or not your windshield wiper fluid reservoir has fluid. A shipment to the car manufacturer is ready to go out. But, there are no shipping containers. Until the windshield wiper sensor chips arrive, the car factory can't make any cars, and don't have room to unpack the shipping containers with unneeded parts that are piled up outside. So there is no container that can go back to China to bring the chips to the factory. While all that is worked out, SV venture capitalists print some money to give to a used car startup, making it super easy to get the best price on your used car. With no new cars available and flashy discounts to get the market kickstarted, the used car market shoots up, meaning that even though you want a new $60,000 electric car, all you can do is buy a used 1988 Yugo for $150,000. You walk to work, even though you have the money for the car you want. If it's software, this is what we call a pageable event and the postmortem whines about "separation of concerns". But in the real world... well, we don't have those. We LOVE thinking we do, but when shit blows up, it's clear that we don't. So are we really surprised that software works the same way? It's how the Universe works, not bad architecture. The Universe has terrible architecture. Adjust some of those constants and try again!
yawboakye 4y ago
architecture has a long history, of course. even if we start from since drafting became standard practice, recent advances like 3d modeling (due to computers) and analyses (satisfying/resolving building code constraints, structural forces, etc) are quantum leaps. in programming, perhaps the type systems (static) and debugger (post-production) gives a similar feeling but not quite. these two aside, the concerns of a c programmer today largely overlaps with those of dennis ritchie & brian kernighan.

AbsoluteCabbage 4y ago

We are still going to evaluate code in our heads. If anything, we need to enhance our capacity to do so. That is where AI can assist. A simple overview or graphical representation of a codebase will be a good start.

ethbr0 4y ago
UML is dead! Long live UML!

RoyGBivCap 4y ago

Reminds me of other tools from the past that "allow development with out a developer". With fancy drag and drop UIs that look like circuit diagrams. In trying one you very quickly find out that you still need a developer. Because the easy happy path that the biz analyst thinks of is like 1-10% of what we do. 90% of our job is the plethora of edge cases and sad paths. The retrying. The when not to retry case within the retry case. Does these language model bots help a little? Sure! But my worry of being replaced is currently sitting at like a 3% out of 100%. I expect to still have a job right up until we have AGIs, and quite probably for long after, as not everyone will be able to afford them. That is assuming we have any meaningful control over them.

emodendroket 4y ago
I think this is more of a developer productivity tool than a replacement. Like an IDE.

divbzero 4y ago

Are there IDEs that can display compile-run-observe results in real time? A feature where you can set the inputs for a certain function and view the result of each statement in-line as you edit the function?

skibz 4y ago
Light Table, which I presume to be defunct, comes to mind. (http://lighttable.com/#features http://lighttable.com/#features) But if you're willing to do without the "as you edit" requirement, then what you're left with is a plain old breakpoint debugger. Certainly, there are many IDEs that have those builtin.
bo-tato 4y ago
it's a normal way to develop in clojure. The primitive no-IDE support needed trick is to just define variables with the names of your function inputs, as in: https://blog.michielborkent.nl/inline-def-debugging.html https://blog.michielborkent.nl/inline-def-debugging.html and then you can just evaluate expressions within the function. The fancy way with editor support is: https://github.com/vvvvalvalval/scope-capture-nrepl https://github.com/vvvvalvalval/scope-capture-nrepl you make snapshots of the local variables at any point, and later evaluate code in the context of that snapshot. So you do some action in your program that results in that function being called, it'll save the input, you select that snapshot, and now you evaluate in the context of those function arguments as you edit and eval expressions in the function. And while clojure supports interactive development at a level beyond other mainstream languages, Smalltalk and Common Lisp have support for it on another level, for example: https://malisper.me/category/debugging-common-lisp/ https://malisper.me/category/debugging-common-lisp/ There's some study where Smalltalk came out as the most productive language, I don't know whether it's more productive but that kind of interactive development where you build up your program evaluating it the whole time, without ever restarting, is a lot of fun. Why it went out of style I don't know
- Qem 4y ago
  > There's some study where Smalltalk came out as the most productive language, I don't know whether it's more productive but that kind of interactive development where you build up your program evaluating it the whole time, without ever restarting, is a lot of fun. I think it's this paper: https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirt...

emodendroket 4y ago

My experience with this type of tool is it does help with some types of very repetitive code (wordy idioms, test code, etc.) or with using unfamiliar libraries. But yeah it's limited in other contexts.