Hacker News Reader

Comment by js8 | Hacker News Reader

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.

View on HN

I 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.

> 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.

Good point. But I think current approach of large scale generative AI models is not sufficient for this.

I 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.

This 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.

I 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.

> 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?

I 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.)

I 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.

I 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

Compilers 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.

Sometimes it is just the syntax of your language. We can't all be writing lisp where the syntax is just another abstraction.

> 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.)

The boilerplate makes it readable by humans.

Reply on news.ycombinator.com