Hacker Newsnew | past | comments | ask | show | jobs | submit | gspr's commentslogin

This is actually my biggest gripe with vibecoding. The single best feature of any programming language is that it is precise. And that is what we throw out?! I favor of natural language, of all things?! We're insane!

It turns out an awful lot of precision (plenty for many things) lives in library and web APIs, documentation, header files and dependency manifests. Language can literally just point at it without repeating it all. Avoidance of mistake through elimination of manual copying in things like actuarial and ballistics tables was what the original computers were built for.

Custom written code can also point at those APIs and libraries without repeating it all? Or am I missing your point?

API Glue is the easy and boring part in programming. Nobody really enjoys wiring API A to API B, combining the results and using API C to push it forwards.

Any semi-competent AI Agent can do that with a plan you've written in 5 minutes.


I would love to see an AI try to make sense of GTK API.

I may be wrong, but it seems when people are talking about easy glue code, they’re talking about web services API, not OS API, not graphics or sound API, not file formats libraries,…


I used Sonnet 3.5 over a year ago to decrypt a notoriously shitty local government API to get data out of meetings, votes and discussions.

I know it's a piece of shit API done in the worst possible way on purpose (they don't want openness, but had to fulfill a law that mandates "openness") because I had previously tried to do it manually - twice. I ran out of whisky before I got anything done.

Sonnet _3.5_ almost one-shotted it with just the API "documentation" they had and access to Python and curl.

People have also hooked stuff into proprietary APIs on "smart" devices with zero documentation, just by having an Agent tirelessly run through thousands of permutations to figure it out.


Even with web services it usually shits the bed if you ask it to maintain something with tech debt.

Historically we almost entirely moved from ASM to C, a language with lots of undefined behavior, because precision is not the most valued feature of languages.

UB is about edge cases that a compiler should not be enforced to check against and an occurrence is always a bug. You don't necessarily need a precise description of the actual faulty behavior.

Right. The language has well-formed expressions with no defined meaning in terms of machine instructions. My claim is that this is a reduction in precision compared to assembly language.

Grandparent said:

> The single best feature of any programming language is that it is precise.

C overtook a more precise language family because it has features other than precision that people cared about. Perhaps a better tradeoff of expressiveness and readability with precision.

Grandparent could be correct, and precision is the best feature of C, despite being less precise than ASM. And its better expressiveness nets out to a better overall programmer experience. I just wanted to point out that precision is something we do trade away for other things we want.


Could you please explain why you feel that having UB makes C less precise than asm?

To me, the notion of precision isn't in any way related to whether any given statement is sound. It's about the behavior of the language for sound programs.


When I say "best part of any programming language" I obviously mean "best part of the in-spec defined parts of any programming language".

Your suggestion that because languages have specified undefined behaviour, they are somehow not precise, makes little sense.


That's because very often the precision is just common sense that can be derived, either from general knowledge, or from your existing code.

If you had to give precise instructions to someone so they could get anything done you'd call them a junior.

Are you seriously suggesting that that's a feasible, go-to solution for a problem in your country? For most normal, well-adjusted people?

Plenty of people leave countries all the time.

In fact, voting with your feet and leaving is far more effective at fixing political issues than the democratic voting process.


> Plenty of people leave countries all the time.

Yes. I've done so myself. The fact that people do this all the time doesn't mean it's the best thing to do when your country has problems.

People also move houses all the time. It's a big undertaking. Not the default solution whenever your kitchen needs renovations.

> In fact, voting with your feet and leaving is far more effective at fixing political issues than the democratic voting process.

Citation needed. Sounds very defeatist.


I _love_ Rust and use it whenever I can. I still find the comments in here to be quite appropriate. Async Rust leaves me with a (subjective!) feeling that something isn't quite right. Not that I know how it _should_ be, but that feeling is very different from the non-async parts of the language that almost always leaves me with a warm fuzzy feeling of joy.

I don't know enough about the domain to be objectively helpful, so it's all wishy-washy feelings on my part. I keep reaching for orchestrating things with threads in Rust where most people would probably reach for async these days. The only language where I've felt fine embracing the blessed async system is Haskell and its green threads (which I understand come with their own host of problems).


Somewhat unrelated anecdotal praise of Noctua: due to various life factors, I hadn't built a PC since maybe 2010 or thereabouts - something I did relatively often before then and had quite a bit of experience with. Then a few months ago I finally did it again. Forgetting about the absurdity of the RAM situation, I gotta say my biggest surprise was cooling. I wanted a quiet media center machine. The internet and friends kept recommending Noctua. While researching, I got a bit of a cult vibe, and their prices seemed a bit stiff. But I went for it, with some hesitation.

Goddamn was I wrong! Their CPU coolers are the most well-designed, thoughtfully planned, amazingly performing consumer product I've seen in a while. 10/10, highly recommend! I'll use them for all PC cooling needs going forward.


I agree! For case fans there are cheaper, good enough alternatives for most use cases, but their coolers definitely are worth the premium. The design, manuals and specifications online are just so good compared to competitors, plus they give away free upgrade kits when new CPU sockets come available, so you could probably use same cooler for decades as you upgrade the system.

> Disregarding the article for a second, has anyone else had the pattern that "parse don't validate" makes sense in object oriented style, but less sense in functional style programming?

Parse, don't validate was written around Haskell!


What I tried and apparently failed to express with "parsing and validating blurs into each other." was that parsing more easily becomes "just what you do" in functional style of programming. To the point that nowadays I can no longer really remember what I did back when I tried to "validate" things instead of parsing them.

Let me get this straight: Since there are only so many ways to write a for loop, you doubt that for loops are copyrightable. From this you conclude that code, in general isn't copyrightable?

That's like saying "there's only so many ways to greet your neighbor, so any text that simply greets your neighbor isn't copyrightable – and therefore no text is copyrightable".


> What should matter is intent, the human that gives the orders.

I'd like to hear more nuance with regards to this line of reasoning. Can you conceive of a model that contains highly non-trivial representations of IP owned by others than yourself? Can you conceive that you might "order" the model to "produce" that IP? What happens then?

Try this both for "open source code" as the IP, and "the novel I wrote", and "latest Hollywood movie". The model does not have to be a real model currently available. It's just a thought experiment.

Try also to elaborate on the sliding scale between "an AI model" and "a compression system".


> When I write code, what I write and how I write it is informed by having read countless source code files over my education and my career. Just as I ingest all that experience to fine-tune how my later code is written, so does the LLM from the code it's seen.

You are presumably human. We have granted humans specific exemptions in copyright law. We have not granted that to LLMs. Why are we so eager to?


Ok, so I use the LLM. I use the tool. Can I now apply the exemption to me?

Are you telling me that I can use the thing, but I can't use it if I process it through an LLM? It get slippery, fast.


What's special about LLMs in your argument? When I was an edgy teenager in the 90s, I'd argue that it's not piracy because the DivX representation of the movie isn't bit-for-bit identical to the Hollywood master or whatever. If your reasoning works for LLMs as the tools, surely it also works for video compression.

No, that's how copyright normally works.

If I write a story, I can put it online. That doesn't mean it's ok to take that story and publish it in an anthology.


I'm not sure where in our lawbooks there are laws that specifically target humans to the exclusion of human-operated tools.

There's also a TON of irony here. What an about face it is, for the community at large* to switch from "information wants to be free, we support copyleft and FOSS" to leaning so heavily on an incredibly conservative reading of IP law.


> I'm not sure where in our lawbooks there are laws that specifically target humans to the exclusion of human-operated tools.

If we take the point of view that LLMs are tools (I agree), then people need to be absolutely certain that these tools don't contain (compressed) representations of copyrighted works.

People seem not to want to do that. And they argue that the LLMs have "learned" or "been inspired" by the copyrighted works, which is OK for humans.

This is the problem. People can't even agree on which of two mutually exclusive defenses to appeal to! Are LLMs tools which we have to ensure aren't used to reproduce copyrighted work without permission, or are they entities that can be granted exemptions like humans can? It can't be both!

> There's also a TON of irony here. What an about face it is, for the community at large* to switch from "information wants to be free, we support copyleft and FOSS" to leaning so heavily on an incredibly conservative reading of IP law.

True. While IP-owning companies like Microsoft now say "it's online, so we can use it".

It's bizarre.

I'll tell you what: I'll drop my conservative stance in defense if FOSS when Windows and the latest Hollywood movie are "fair use" for consumption by whatever LLM I cook up.


If we take the point of view that LLMs are tools (I agree), then people need to be absolutely certain that these tools don't contain (compressed) representations of copyrighted works.

I've pointed out elsewhere in this thread that this is the opposite of how the real world works.

In actual fact, people who need software built hire a tool (e.g., a software developer like me) to build it for them. That tool - me or you - has inside it a tremendous library of copyrighted works represented. I've worked on enough different projects over the decades that the next CRUD function, or rule-driven data-entry tool, or whatever, that I build is going to draw very significantly from the last ones I built. And those last ones were copyrighted, with those rights held by my employer at the time, and maybe even protected by NDA or defense-style classifications.

Is your position that this is OK so long as it's stuff that I can keep in my squishy brain, but the moment that mechanism moves to silicon, it somehow becomes fundamentally different?

The other major argument I see in this thread is that for LLMs it's different because there's a third party who is aggregating the data, and selling me (or my employer) use of that tool. But this doesn't change the overall picture at all. It just adds one more layer of dereferencing into it. The addition of that middleman hasn't altered the moral landscape: how is hiring me, along with what's in my memory, different from hiring the combination of me plus a helper to supplement my memory? There's an aspect of scale, I suppose. With that helper I can achieve greater quantities, but it's not changing the story in a qualitative way.


> In actual fact, people who need software built hire a tool (e.g., a software developer like me) to build it for them. That tool - me or you - has inside it a tremendous library of copyrighted works represented.

Humans are distinct from tools, both ethically (to most people) and legally. You may not see it this way, but it is the majority opinion and the stance of the law in most jurisdictions. The rest of your paragraph falls apart without considering humans as tools.

(Incidentally: you can own tools. I don't think you want to open that door…)

> Is your position that this is OK so long as it's stuff that I can keep in my squishy brain, but the moment that mechanism moves to silicon, it somehow becomes fundamentally different?

Yes. We, humans, structured our laws because we consider ourselves and our squishy brains special.

This is, for example, why you don't get charged with murder for terminating a computer program. We, the humans, have decided that the right not to be terminated only applies to humans (and other animals, but then because we grant them that protection).


> I'm not sure where in our lawbooks there are laws that specifically target humans to the exclusion of human-operated tools.

It doesn't need to. Laws are for humans.

Laws don't give rights to chainsaws. Or lawnmowers. Or kitchen knives, hammers, screwdrivers, and spades.

You can't use any of those to commit a crime and then claim that the law specifically did not exclude those tools.

Why are you seemingly in favour of carving out an exemption for LLMs?

Laws are for humans.

Arguing that the law did not specifically address "intentionally killing a person by tickling them till they died" means that you found a loophole which can be used to kill people is...

well, it's in the "not even wrong" category...


Because that allows us to create useful tools that we didn't have before. For me it feels like a carpenter going from a hand-saw to an electrical saw. Still requires the skills of a good carpenter, but faster and easier.

… so a bunch of people just decided that rights we granted to humans also apply to their tools? Without any discussion? This isn't how anything is supposed to work when it comes to common rules!

The common rules are so because we agree on them. On principle, in this case, we do not agree what the rule should be here and it's in a way unprecedented. We'll soon converge to a societal agreement. I hope society abstaining itself from tools will not be the answer.

And the process by which we agree is lawmaking.

We did not grant human exemptions in copyright law.

We gave certain temporary monopoly on certain uses to humans under rules little understood by laymen even if their livelihood depends on it.


... and from that temporary monopoly humans have exemptions (critique, inspiration, etc.)

It's generally less an exemption and more a constraint on the monopoly, at least in spirit of the law

I'm still flabbergasted that people – and big, visible companies with big targets on their backs – choose to keep on using the output of LLMs without having an answer to these questions.

And I'm worried that once that has been sufficiently normalized, laws and interpretations of them will adapt to whatever best suits those users. Which will mean copyrightwashing of FOSS. My only hope then is that surely if free software can be copyright-washed by the big guys, then so can the little guy copyright-wash the big guys' blockbuster movies or whatever, which might lead to some sort of reckoning.


The same way you can get weak if you don't use your muscles.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: