5 ms·
The real question is, why we need to write "trivial" code? I think people have lost the plot there. We should be writing better compilers and libraries, instead
by js8 4y ago
The real question is, why we need to write "trivial" code? I think people have lost the plot there. We should be writing better compilers and libraries, instead of using AI that will write more code to deal with.
The obsession with code generation instead of creating proper abstractions is a scourge of today's programming. It's a regression in software engineering.
- layer8 4y agoI agree to some extent. But there are redundancies that are inherently beneficial and make code more robust and readable, like separating interface from implementation (where some declarative elements have to be repeated), or explicit type annotations instead of full-program type inference. There are also strictly necessary redundancies, like when you pattern-match an ADT, you repeat its declared structure. For desirable or necessary redundancies like that, AI code completion can still save time. Intelligent unit test creation (if it is indeed intelligent) is also a good use-case. Not to relieve the programmer from thinking, but to save typing and to point out potentially useful tests that you might not have thought of.
- nine_k 4y agoThis is trivial stuff which is handled well by any competent IDE from 2015, and even a well enough-working set of editor templates. I don't see where "AI" is required for stuff like this.
- js8 4y agoI agree, but also, this is actually where AI (whatever it is) would be helpful. Suggesting actual abstractions that could replace boilerplate. Of course, these can build on existing abstractions.
- lupire 4y agoThe boilerplate makes it readable by humans.
- never_inline 4y agoI have made the same point elsewhere to AI enthusiasts friends of mine. The fact that defining the same task in natural language to an AI is easier than writing it in formal language, means the formal language lacks expressiveness [0], vocabulary, or more likely, both. But if they are both at same level of expressiveness and vocabulary, formal language wins, because it can spot and prevent ambiguity. The question is how scalable it is to implement such vocabulary into formal language. [0] - The line is often blury. How many languages allow to straightforwardly express `clamp m between 1.0 and 2.0`? You can argue this is vocabulary, or this is expressiveness.
- js8 4y ago> How many languages allow to straightforwardly express `clamp m between 1.0 and 2.0`? You can argue this is vocabulary, or this is expressiveness. And I think it would be a great place for AI in programming - automated refactoring. For example, it would see a code that clamps the value and could be replaced with a library function call clamp(m,1,2). (And it would also, presumably, made sure that the code is indeed the same.) So it could help you understand the vocabulary. Or, if it sees you are doing this frequently, and it's not in the standard library, it would create the function. But instead, this AI (more like artificial stupidity) will just suggest you the same thing you wrote because you don't know any better in your code base. That's not helping.
- never_inline 4y agoGood point. But I think current approach of large scale generative AI models is not sufficient for this.
- serpix 4y agoSometimes it is just the syntax of your language. We can't all be writing lisp where the syntax is just another abstraction.
- js8 4y ago> We can't all be writing lisp Why not? Isn't it easier to learn new syntax than to figure out a correct prompting for AI? (Although actually, Haskell syntax would be something I would prefer to write in.)
- harriet1 4y ago[dead]
- bananapub 4y ago> We should be writing better compilers and libraries this is a bizarre claim to make and just completely ignores reality. people ARE trying to make better compilers and libraries, and have been for decades. we are we are now after person-millennia of effort, and that still means the optima we're at requires writing some repetitive web template rendering code in JSX or whatever, which Copilot can automate. why didn't some homomorphic-monoid-transformer-auto-renderer win instead?
- js8 4y agoI think the reality is that "if you build it they will come" is simply not always true, and worse is sometimes better. I don't think we are climbing to an optimum, at least unless it is culturally perceived that good abstractions are more valuable than just generating code. The auto-renderers did actually win. There were GUI building tools at the end of 90s (like Visual Basic) that still put most web frameworks to shame. But, for various business reasons (mostly pricing, really) they were replaced with "web technology" - something open source but worse. (And I am not dissing OSS, either. For example, Qt/KDE had some great abstractions that could serve as a basis for building applications. But the urge to reinvent the wheel has won.)
- circuit10 4y agoI guess one difference is that Copilot can guess things that it’s not sure about and have you check over it, but a compiler can’t just guess what you want it it would be very unreliable
- js8 4y agoCompilers do however guess that you don't want something - it's called compiler warnings. Linters do that as well. To me what you describe is more about how we communicate with compilers than an inherent limitation.
- tasuki 4y agoI couldn't agree more with everything you wrote. The problem with repetition is not that it's hard to generate, the problem is it's hard to maintain! I've used ChatGPT to find libraries and to help me line up types. It was very helpful.