4 ms·

The AI coding approach is solving the wrong problem. The problem isn't with the low level detailed work. That problem should be solved by building composable,

by blunte 5y ago

The AI coding approach is solving the wrong problem. The problem isn't with the low level detailed work. That problem should be solved by building composable, tested, audited libraries. Legos, if you will. If the problem is trivial enough that you can completely trust the AI coded solution, then you could have either done it yourself very easily or used a premade solution from a good library or toolkit. If the problem is not trivial, then you have the outsourcing challenges (which apply to a lot more scenarios than using AI to help you code). If you are not personally capable of judging the outsourced work, then whether you use AI or type it yourself, you will end up with errors or misfeatures. If you are capable of judging, then you must pay attention and read/review. So your job shifts from defining the problem and programming a solution to defining the problem and reviewing potential solution(s). Either way, you must focus and think. But again, perhaps you would be better off building a solution composed of known good blocks. <- This should be the future of software development... Sadly, I think that open source and freedom to (re)invent has worked against us in the long run. If instead of each of us going off and thinking, "I can make a better language/framework", we had built on existing technologies, I daresay we would be further along. To be fair of course, some level of dissatisfaction and divergence would be necessary or we would still be using assembly. Github does have one thing right though (from a business perspective) - they are making a remedy to a symptom, and in that they can expect longer term revenue than if they actually solved the core problem.

sktrdie 5y ago
I think you’re missing what the problem they’re trying to solve is. They’re solving the problem of “writing code faster” With that in mind I think this problem is totally real and worth solving. If copilot can save me those mundane moments during my day where I have to figure out “how to do this common thing that I already did 100 times” then it’s a win for everyone. It’s not trying to solve the whole of programming. It’s just a nice tool to let you actually concentrate on the non-automated parts of coding such as: actually translating requirements into code.
- zabzonk 5y ago
  > how to do this common thing that I already did 100 times You don't do it 100 times - you do it once, test it thoroughly, and put it in a library.
  - medstrom 5y ago
    Easy to say. Of course you do that when you can. What afflicts me is all the cases when the task is subtly different, with different requirements, but still feels like something I've done before.
    - indigochill 5y ago
      At the code level, that's parameters in a library function. At the infrastructure level, currently my team is using Terraform templates. I feel like we will probably restructure that "soon" to be more about composing infrastructure out of common blocks rather than inheriting from an entire template, but either way, this does seem to be a solvable problem at the infrastructure layer as well. As you imply, it is significantly easier to say than to do effectively, but I've yet to see any situation where it -can't- be done (but I'm curious what one looks like if someone's run into this).
      - medstrom 5y ago
        Keeping in mind I'm a hobbyist, not a professional, but it seems to me much of coding boils down to this process of refactoring, spinning out libraries and restructuring to use Terraform or whatever, and at some point the process itself is what's repetitive.
      - cortesoft 5y ago
        > At the code level, that's parameters in a library function Sure, so you keep adding more parameters to the library function and then pretty soon you can’t remember all the parameters so you have to look them up every time you want to invoke it from your code… which is exactly the perfect use case for AI like this to help you remember the correct parameters to call.
bitwize 5y ago
The thing is, there's already a powerful AI technology we can use to solve the "boilerplate code" problem. It's called Lisp. You know, Lisp, the language for AI written way back when brand-new Cadillac Eldorados with tailfins were still on the road that is self-reflective enough to make writing "programs that write programs" an absolute doddle? :) Good luck getting bigco to sign off on a Lisp project, though. Even if it is of demonstrably profound practical utility. You're right -- we have a huge problem with trying to trowel the new hotness (currently, "AI/ML" aka statistics) instead of taking advantage of tools that are highly suited to purpose. Instead of letting us use those tools, bigcos instead subscribe to the "programmer-clerk" myth in which programming is a menial task of mostly rote coding undertaken by minions in legion strength. And this affects not only the tools we use but our processes and professional values.
- blunte 5y ago
  The underlying language doesn't actually matter as long as you can deliver the toolkit. I do agree that Lisp(y) language(s) may be very well suited, but I don't care. I just want us to stop reinventing the wheel hundreds of times each year. At least paper shuffling and fax sending took long enough that you could get a coffee and have a chat while it was happening. Now instead we toil over configuration files (which ironically Rails, my daily toolbox, aimed to solve a decade ago). I should be able to define a few data models and relationships, processes, and some business rules. The rest absolutely should be generated for me. If cars worked like this, we would still be custom building wooden wheels.
  - bitwize 5y ago
    > The underlying language doesn't actually matter as long as you can deliver the toolkit. I do agree that Lisp(y) language(s) may be very well suited, but I don't care. Languages matter. Lisp offers second-to-none metaprogramming capability and it's metaprogramming, not "libraries", that will bring the boilerplate problem under control. Other languages may be able to do the same, just not as well; Smalltalk and Ruby can "fake it". Metaprogramming lets you put patterns into reusable libraries, not just data and functions. > I should be able to define a few data models and relationships, processes, and some business rules. The rest absolutely should be generated for me. So you want CASE tools from the 80s-90s? Or "autogenerate applications from UML" from the 2000s? Because uh, there are reasons why those failed. Among them: 1) Code that's generated by machine still has to be maintained by humans. I work with one of the low/no code tools that promise to do everything for you. Lately I spend my days toiling over its flowcharts rather than configuration files, trying to figure out what broke when it stops working, because it doesn't have nearly the debugging capability that JavaScript has and even crude tools like "debug by printf" are off limits. 2) Systems that run in the real world are subject to real-world constraints. You have to integrate with other, very specific systems, you are subject to performance and scalability constraints that vary by application, etc. These are constraints that require solutions to be engineered. You're going to still have plenty of work to do after you've defined your data models and business rules, no matter what tools you use. The question really is how much friction the tools impose when completing that work.

by blunte 5y ago

sktrdie 5y ago

I think you’re missing what the problem they’re trying to solve is. They’re solving the problem of “writing code faster” With that in mind I think this problem is totally real and worth solving. If copilot can save me those mundane moments during my day where I have to figure out “how to do this common thing that I already did 100 times” then it’s a win for everyone. It’s not trying to solve the whole of programming. It’s just a nice tool to let you actually concentrate on the non-automated parts of coding such as: actually translating requirements into code.

zabzonk 5y ago
> how to do this common thing that I already did 100 times You don't do it 100 times - you do it once, test it thoroughly, and put it in a library.
- medstrom 5y ago
  Easy to say. Of course you do that when you can. What afflicts me is all the cases when the task is subtly different, with different requirements, but still feels like something I've done before.
  - indigochill 5y ago
    At the code level, that's parameters in a library function. At the infrastructure level, currently my team is using Terraform templates. I feel like we will probably restructure that "soon" to be more about composing infrastructure out of common blocks rather than inheriting from an entire template, but either way, this does seem to be a solvable problem at the infrastructure layer as well. As you imply, it is significantly easier to say than to do effectively, but I've yet to see any situation where it -can't- be done (but I'm curious what one looks like if someone's run into this).
    - medstrom 5y ago
      Keeping in mind I'm a hobbyist, not a professional, but it seems to me much of coding boils down to this process of refactoring, spinning out libraries and restructuring to use Terraform or whatever, and at some point the process itself is what's repetitive.
    - cortesoft 5y ago
      > At the code level, that's parameters in a library function Sure, so you keep adding more parameters to the library function and then pretty soon you can’t remember all the parameters so you have to look them up every time you want to invoke it from your code… which is exactly the perfect use case for AI like this to help you remember the correct parameters to call.

bitwize 5y ago

The thing is, there's already a powerful AI technology we can use to solve the "boilerplate code" problem. It's called Lisp. You know, Lisp, the language for AI written way back when brand-new Cadillac Eldorados with tailfins were still on the road that is self-reflective enough to make writing "programs that write programs" an absolute doddle? :) Good luck getting bigco to sign off on a Lisp project, though. Even if it is of demonstrably profound practical utility. You're right -- we have a huge problem with trying to trowel the new hotness (currently, "AI/ML" aka statistics) instead of taking advantage of tools that are highly suited to purpose. Instead of letting us use those tools, bigcos instead subscribe to the "programmer-clerk" myth in which programming is a menial task of mostly rote coding undertaken by minions in legion strength. And this affects not only the tools we use but our processes and professional values.

blunte 5y ago
The underlying language doesn't actually matter as long as you can deliver the toolkit. I do agree that Lisp(y) language(s) may be very well suited, but I don't care. I just want us to stop reinventing the wheel hundreds of times each year. At least paper shuffling and fax sending took long enough that you could get a coffee and have a chat while it was happening. Now instead we toil over configuration files (which ironically Rails, my daily toolbox, aimed to solve a decade ago). I should be able to define a few data models and relationships, processes, and some business rules. The rest absolutely should be generated for me. If cars worked like this, we would still be custom building wooden wheels.
- bitwize 5y ago
  > The underlying language doesn't actually matter as long as you can deliver the toolkit. I do agree that Lisp(y) language(s) may be very well suited, but I don't care. Languages matter. Lisp offers second-to-none metaprogramming capability and it's metaprogramming, not "libraries", that will bring the boilerplate problem under control. Other languages may be able to do the same, just not as well; Smalltalk and Ruby can "fake it". Metaprogramming lets you put patterns into reusable libraries, not just data and functions. > I should be able to define a few data models and relationships, processes, and some business rules. The rest absolutely should be generated for me. So you want CASE tools from the 80s-90s? Or "autogenerate applications from UML" from the 2000s? Because uh, there are reasons why those failed. Among them: 1) Code that's generated by machine still has to be maintained by humans. I work with one of the low/no code tools that promise to do everything for you. Lately I spend my days toiling over its flowcharts rather than configuration files, trying to figure out what broke when it stops working, because it doesn't have nearly the debugging capability that JavaScript has and even crude tools like "debug by printf" are off limits. 2) Systems that run in the real world are subject to real-world constraints. You have to integrate with other, very specific systems, you are subject to performance and scalability constraints that vary by application, etc. These are constraints that require solutions to be engineered. You're going to still have plenty of work to do after you've defined your data models and business rules, no matter what tools you use. The question really is how much friction the tools impose when completing that work.