Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Next Abstraction

substack.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: The Next Abstraction

#11

Post by leecommamichael »

It's just better-search. You'll spend less time searching for things. Searching for "why this is broken", searching for "how can this be better", searching for "is it possible to..."

You still have agency when that's the usage pattern. You have the problem, you use the tool to find the solution. Who cares if the one it spits out isn't character-for-character what you're looking for. Seeing the wrong solution sometimes helps you identify the right one _for you_.

If we _must compare them_ in this case, I see AI as a more useful tool than garbage collection. One that is far less invasive.

Re: The Next Abstraction

#12

Post by ahmadtbk »

NAHWheatCracker wrote: post #9

I don't feel much inspired by the metaphor of garbage collection and AI. Garbage collection makes thinking about memory irrelevant 99% of the time. Time saved with AI is spent figuring out what the AI did. The garbage collector rarely makes itself a problem. AI almost always makes itself a problem. Developers can go years without thinking about memory if they aren't in a complex environment. AI can't go a day without…

This predictability problem is something no one seems to realize. You can't replace an individual that can master things to a relatively high level of accuracy. Everyone is obsessing over speed but driving fast gets you killed.

Re: The Next Abstraction

#13

Post by skydhash »

tikhonj wrote: post #8

> AI isn’t replacing us. It’s relieving us - of repetition, boilerplate, tedium. My problem with current AI is that it isn't relieving us of boilerplate, it's making boilerplate cheaper to write . And when you make something cheaper, you get more of it! We already struggle as an industry with an overabundance of bad code. A fast bad-code generator might be a step towards a higher level of abstraction... but in the me…

Lisp is a good example of boilerplate elimination. Simple data structure, versatile functions, you're often just one or two layer up in terms of abstractions. Most libraries are lateral instead of foundational to your use cases. Like you don't build on top of a web framework, you mesh with it.

Re: The Next Abstraction

#14

Post by chr15m »

Yep, we have a new tool and it's making us more productive when we learn how to use it properly. The malloc/GC example is a good analogy.

One thing to note: understanding memory management as a Java programmer makes you a better programmer. Having used malloc in bare metal mode helps you understand issues like memory leaks more clearly. It gives you a model of what is going on grounded in experience.

So that knowledge and experience of the old ways isn't useless. It's very useful and makes you a better developer. This is true of many advancements in tech, including AI.

Knowing how to build software without AI makes you a better developer when building with AI.

Re: The Next Abstraction

#15

Post by pron »

ChrisMarshallNY wrote: post #3

I think of Java as one of the earliest widely-accepted languages that introduced a lot of design patterns and language idioms that have become pretty much par for the course, since. I never really liked it, but I see its influence in Swift, every day, and I do like Swift. I think that we are at the "unlikable Java" stage of AI, right now. In a few years, we'll be seeing the next generation of tools, and they will be…

The funny thing is that, on a purely technical level, LLMs are more likely to do a better job at replacing upper management than replacing developers. If companies really want to save money, they should let AI replace the CEO.

Re: The Next Abstraction

#16

Post by 0x445442 »

The JVM and Garbage collector were good but were already present with Lisp and Smalltalk. I've been developing professionally since '94 and the first two years of my career were with C++. In '97 I had the opportunity to move to a green field project using Java. The most useful thing for young me was not the Garbage collector, it was no header files and Javadoc.

Re: The Next Abstraction

#17

Post by delifue »

NAHWheatCracker wrote: post #9

I don't feel much inspired by the metaphor of garbage collection and AI. Garbage collection makes thinking about memory irrelevant 99% of the time. Time saved with AI is spent figuring out what the AI did. The garbage collector rarely makes itself a problem. AI almost always makes itself a problem. Developers can go years without thinking about memory if they aren't in a complex environment. AI can't go a day without…

Vibe coding is easy. Vibe debugging is hard.

Re: The Next Abstraction

#18

Post by jrvieira »

skydhash wrote: post #13
tikhonj wrote: post #8

> AI isn’t replacing us. It’s relieving us - of repetition, boilerplate, tedium. My problem with current AI is that it isn't relieving us of boilerplate, it's making boilerplate cheaper to write . And when you make something cheaper, you get more of it! We already struggle as an industry with an overabundance of bad code. A fast bad-code generator might be a step towards a higher level of abstraction... but in the me…

Lisp is a good example of boilerplate elimination. Simple data structure, versatile functions, you're often just one or two layer up in terms of abstractions. Most libraries are lateral instead of foundational to your use cases. Like you don't build on top of a web framework, you mesh with it.

i feel like lisp owes more to compositionality than it owes to abstraction per se, as an antidote to complexity

Re: The Next Abstraction

#19

Post by skydhash »

jrvieira wrote: post #18
skydhash wrote: post #13

Earlier quoted context omitted.

Lisp is a good example of boilerplate elimination. Simple data structure, versatile functions, you're often just one or two layer up in terms of abstractions. Most libraries are lateral instead of foundational to your use cases. Like you don't build on top of a web framework, you mesh with it.

i feel like lisp owes more to compositionality than it owes to abstraction per se, as an antidote to complexity

I would say both. The list and its children (associated list and property list) are quite versatile. Struct in a typed language gave you benefits too, but the issue is loss of flexibility even if you have protocols like Swift or implicit interface like Go. With lisp you think in terms of data instead of bothering with names and interfaces. Most lisp functions are projections or builders.

Something similar, dx wise, could be achieved with using immutable maps, lists, and sets. But most languages relies on being able to mutate blob of memories.

Re: The Next Abstraction

#20

Post by yencabulator »

pron wrote: post #15
ChrisMarshallNY wrote: post #3

I think of Java as one of the earliest widely-accepted languages that introduced a lot of design patterns and language idioms that have become pretty much par for the course, since. I never really liked it, but I see its influence in Swift, every day, and I do like Swift. I think that we are at the "unlikable Java" stage of AI, right now. In a few years, we'll be seeing the next generation of tools, and they will be…

The funny thing is that, on a purely technical level, LLMs are more likely to do a better job at replacing upper management than replacing developers. If companies really want to save money, they should let AI replace the CEO.

Management output can be vague and shift arbitrarily from day to day. It would make sense LLM slop fits in better there. We'll circle back to this action item.
Post reply on HN