4 ms·

How did we end up here, just accepting that some coding tasks require repetitive work, and turning to a probabilistic text synthesizer that requires massive tra

How did we end up here, just accepting that some coding tasks require repetitive work, and turning to a probabilistic text synthesizer that requires massive training data to automate that? We're having this discussion on a site whose founder famously wrote, over 20 years ago, that succinctness is power, and even wrote this site in a programming language that he designed to take that principle as far as he could. Now, two decades later, why have we so completely retreated from that dream? I bear some responsibility for this, since I was one of the people who basically said, in the 2010s, that we should just give up and use popular languages like JavaScript because they're popular. I regret that now.

Aeolun 1y ago
Some things are better with more code. Sets of data in particular (strongly typed). Sometimes you need to modify those sets of data and it doesn’t require enough work to write a whole script for, but you still don’t really want to spend the time manually modifying everything. LLM’s are really nice in those instances.
- klabb3 1y ago
  Plain data in all glory but I’d rather (deterministically) generate and modify it than having big blobs checked in. If I have too much copy pasted data I often forget to modify until the test case runs and I realize it. This creates a false sense of confidence since there could be tests that pass and nobody ever checks they’re wrong. Essentially, minimize the number of human steps to verify it looks right which typically means optimizing for the least amount of code. Flashback to when I committed a suite of tests in Python that were indented one tab too much, resulting in them not running at all. This passed code review (on a FAANG company) and was discovered months later from an unrelated bug. The point is even unit tests have a very human element to them.
jampekka 1y ago
> I some responsibility for this, since I was one of the people who basically said, in the 2010s, that we should just give up and use popular languages like JavaScript because they're popular. I regret that now. In 2010s the move was towards more concise languages and programming techniques in e.g. JavaScript scene too. CoffeeScript is a prime example of this. But then came the enterprise software people pushing their Javaisms and now we have verbose bondage and ceremony mess like TypeScript and ES6 modules. And in a tragicomic turn after we made expressing programmer intent formally so difficult, we are turning into writing bad novels for LLMs in a crapshoot trial and error hoping it writes the pointless boilerplate correctly.
sanderjd 1y ago
We haven't retreated from that dream. We're doing both things in parallel. But I think it will always be the case that some things are repetitive, even as we continuously expand the frontier of eliminating those things. It's good to have tools that help automate repetitive tasks, and it's also good to create more powerful abstractions. There is no contradiction.
wredcoll 1y ago
I cannot wait to see your next webapp written in J.
dwaltrip 1y ago
The ethos that compelled PG to write HN in lisp is what matters, not the actual usage of lisp itself. That ethos lives on, in various forms. I also offer you an old saying we have all heard many times: There are 2 kinds of languages: ones that everyone complains about and ones that nobody uses.

Aeolun 1y ago

Some things are better with more code. Sets of data in particular (strongly typed). Sometimes you need to modify those sets of data and it doesn’t require enough work to write a whole script for, but you still don’t really want to spend the time manually modifying everything. LLM’s are really nice in those instances.

klabb3 1y ago
Plain data in all glory but I’d rather (deterministically) generate and modify it than having big blobs checked in. If I have too much copy pasted data I often forget to modify until the test case runs and I realize it. This creates a false sense of confidence since there could be tests that pass and nobody ever checks they’re wrong. Essentially, minimize the number of human steps to verify it looks right which typically means optimizing for the least amount of code. Flashback to when I committed a suite of tests in Python that were indented one tab too much, resulting in them not running at all. This passed code review (on a FAANG company) and was discovered months later from an unrelated bug. The point is even unit tests have a very human element to them.

jampekka 1y ago

> I some responsibility for this, since I was one of the people who basically said, in the 2010s, that we should just give up and use popular languages like JavaScript because they're popular. I regret that now. In 2010s the move was towards more concise languages and programming techniques in e.g. JavaScript scene too. CoffeeScript is a prime example of this. But then came the enterprise software people pushing their Javaisms and now we have verbose bondage and ceremony mess like TypeScript and ES6 modules. And in a tragicomic turn after we made expressing programmer intent formally so difficult, we are turning into writing bad novels for LLMs in a crapshoot trial and error hoping it writes the pointless boilerplate correctly.

sanderjd 1y ago

We haven't retreated from that dream. We're doing both things in parallel. But I think it will always be the case that some things are repetitive, even as we continuously expand the frontier of eliminating those things. It's good to have tools that help automate repetitive tasks, and it's also good to create more powerful abstractions. There is no contradiction.

wredcoll 1y ago

I cannot wait to see your next webapp written in J.

dwaltrip 1y ago

The ethos that compelled PG to write HN in lisp is what matters, not the actual usage of lisp itself. That ethos lives on, in various forms. I also offer you an old saying we have all heard many times: There are 2 kinds of languages: ones that everyone complains about and ones that nobody uses.