Hacker News Reader

Comment by throwawaygh | Hacker News Reader

> This is trivial code, like adding a button to a screen.

UX is probably the most important aspect of most software products. Every software product is either "smart code" or "smart ux". No one pays much for "dumb code with bad UX" except in dysfunctional markets.

Adding a button to a screen should be trivial, and if it's not you need better tools. (As in "a not-horribly-misdesigned language and framework", not as in "giant transformer".)

Deciding where to add the button, its shape, its size, what happens when it's clicked, the text on the button, ... is anything but trivial.

View on HN

But everyone does pay for dumb code. Even in the best-written and most efficient codebases, there's still going to be some amount of tedious glue code and boilerplate that you have to write in order to create a functioning product. It definitely would be better to have better languages and frameworks instead of a giant transformer, but the better languages and frameworks don't exist yet while the giant transformer does.

> there's still going to be some amount of tedious glue code and boilerplate that you have to write in order to create a functioning product.

This is true, but actually tedious glue code is often non-trivial. For example, in one of my hobby projects I have a repo where I have to write a lot of glue code to schlepp data from a CSV file format into an existing database. Doing this correctly requires reading through the (lengthy) documentation for the format of both the CSV data and also the system that ingests the database, since there are a bunch invariants about the key tables and columns that aren't enforceable in SQL (and obviously not enforceable in the CSV).

This is the sort of glue code/boilerplate where a synthesizer that can understand natural language would be actually helpful.

> but the better languages and frameworks don't exist yet

There are certainly some languages that are less verbose than others.

Java and Go are very boilerplate-y languages. Python is also pretty verbose and inexpressive for certain types of code.

The typescript example on the copilot page right now is a prefect example of "ugh just use a better language".

The examples of boilerplate where copilot shines seem like situations where really simply using "snippets" would work better. E.g., everything on the copilot homepage right now.

>Java and Go are very boilerplate-y languages.

And because of the nature of boilerplate, Java has IDEs that will both generate and modify this boilerplate without thought, no AI required.

I don't remember the last time I typed the text 'class' for example. Instead I type "new Foo(someStringVar)", and then hit Alt-Enter and my IDE creates the file, the `class Foo` along with a ctor that takes a String.

Even in different versions of the same project, the glue may change. E.g. my boilerplate functions for making ajax calls have changed half a dozen times since 2005, been gutted and rewritten to be promosified, upgrade to websockets, and all sorts of other options, but I still have projects deployed that use several previous versions. And my typical PHP or Node executor has evolved, too. I myself find it confusing when working new bits into older projects where I'll occasionally match the wrong gateway code with the wrong frontend.

In other words, a machine looking at only my own glue would be more likely to mismatch or use the wrong version in any given situation.

And once you decide all that, you still have to write:

    <Button ...

or whatever.

Code should be 90% thinking and 10% typing. I don’t need to over optimize the typing part

Yeah well until I get that job I suppose I'll just keep typing.

I'm mostly curious how much overlap there is in use cases for Snippets with parameters, possibly even snippets with conditional parameters vs Copilot.

I imagine there's some situations where Snippets do better, and where Copilot does better, but the more complex the situation the less i trust Snippets... but _also_ the less i trust Copilot.

It seems my trust in Copilot is very similar to that of use cases for Snippets. To throw out fake numbers, it makes me feel like Snippets (and tools like them) cover ~%70 of Copilot's use case. So i'm really curious on knowing what that %30 is, and if it is ever useful.

Yes I agree, I don't use a snippets feature/plugin, but that's what I thought of when it launched - 'why wouldn't I just'.

I suppose there's a (supposed) advantage that it's automatically finding and suggesting the snippet for you, rather than relying on you to think of it and recall the key binding, or know that it's there to such for.

Do you actually, though? I don't type out much HTML these days.

Reply on news.ycombinator.com