C wasn't meant to fully replace low-level languages like Assembly. Context switching still isn't possible in C (nor in Zig).
And most C library calls are actually Unix system calls. Malloc() is an operating system call and not a library call. Yes, they made it a library call later on to facilitate usage in other operating systems but it was originally an integral part of the Unix OS.
Maybe it’s wishful thinking on my behalf, but I am still not convinced that LLMs are on a path to SciFi levels of apocalyptic malicious super intelligence. Rather LLMs at some level are just all of the humanity’s information rendered accessible in an unprecedented way.
In general trying to regulate information access is a losing battle that invites tyranny. So the goal should be minimal restrictions.
At the end of the day, the threats posed by capable AI tools have to be physical. I think the key threats are the following:
- Internet connected infrastructure being crippled
- Creation of WMDs
- Economic collapse (precipitous devaluation of knowledge work and IP).
I personally think the glory days of the wild west, mostly unregulated internet were already over before LLMs; and we need to take a step back to make something structurally secure. This (expensive) change would stop the irresponsible/malicious actor running a tireless hacking agent in a loop threat model. Even a rogue SciFi tier AI would have a much harder time escaping/propagating with a structurally secure internet.
Enabling WMD creation is scaring, but I don’t think it’s really that big of an issue. Anyone with a sophisticated enough supply chain to create AI data centers is leaps and bounds more advanced than what is required to enrich uranium or synthesize bio weapons. The problem is allowing access to untrusted parties. I think it’s fair enough that individual actors shouldn’t have unregulated access to all of human information (private frontier AI companies included).
The last problem is probably the trickiest, but again could probably be solved by regulation. IP protection is already tricky and I don’t think we should try to get more protectionist.
We really need to figure out how to preserve fulfilling careers (if AI does ever get cost effective enough). I don’t think, say accounting, is inherently more fulfilling than building a house. The problem is concentration of wealth and labor dynamics.
Of course all of this gets way harder if it proves that truly dangerous capabilities can be present in models that can be run on consumer hardware.
I don’t think it’s necessarily tyrannical to have a tier of hardware that’s labeled some equivalent of “weapons grade” and requires strict licensing. Restricted computers is a change from the norm. But I can go buy a shotgun with ease and not an F35 jet.
We’d just need to be careful that we can still have lightly to unregulated computing to a certain point and that access to the capable AIs isn’t restricted to just in groups.
Completely unrealistic. We could already be working toward such goals without super intelligent AI. I don’t see any reason to assume that ASI created through an evolutionary process would have a different outcome.
If ASI ended up being align-able and not an evolutionary process, why would we assume folks who already are currently in power would change their behavior?
I couldn’t help but notice the parent commenter’s post history. Account from literally before this was called HN, one comment 6 years later, then 13 years later this comment.
I discovered this recently as I tested an old idea I had to allow a dynamic language to use a C++-like vtable instead of an inline cache (like Objective-C or JavaScript does). It turns out modern CPUs predict an inline cache hit/miss result much better than always incurring the cost of the fetch in a vtable lookup.
You can implement it with templates and people do things like this often. In modern C++, it's even pretty easy to make this type of trick support `constexpr`.
Going back to the technical implementation part, depending on the C++ version, and being able to understand the target at compile time, no need to do it manually and hacky.
There is enough support in constexpr, consteval, concepts, and now compile time reflection, to do it automatically, assuming the dispatch target can be resolved at compile time.
I know it’s a joke, but it does make me wonder if LLMs would even be good at assessing if an idea is “novel”.
I only have a rudimentary understanding of how neural networks work, but I wonder if rather than “understanding” what “novel” really means to humans, an LLM would be most likely to agree that something was novel based on having seen that specifically referred to as novel in its training data.
So that if you give it an example of something that already exists, but which was very recently invented at the point in time when the LLM was trained, and you ask “is this a novel idea?” that because it had several sources in its training data describing that idea as novel, it would say “yes that’s a novel idea”. Whereas what we really meant was to ask it if someone else had already thought of this thing prior to us right now in this later moment.
And then on the other hand, even if something was “novel” at the point in time when the LLM was trained, perhaps we would fare better to ask it “has anyone thought of this?” rather than asking if the idea is “novel”? And that even though it considers the idea novel in a way it would also be able to say that yes this has already been thought of.
I took Claude Code with the prompt copied from GP, and threw it at a repo that's just a collection of ad-hoc narrow-purpose single-page HTML tools, all of them vibecoded on the fly. It found four things "it would show the patent attorney" and three more under liberal interpretation of "novel".
Notable inventions include:
1. Taking well-known math for trilateration, but putting it inside a phone app and making it ergonomic to use. I vibed it so I can survey a plot quickly using a hand laser ranger and a foldable phone for data entry; apparently, the novelty is in combining the live display of how the measurements resolve to a 2D structure, with error residual, and a list of additional measurements to make, priority-sorted by how much error can be removed by making it. Apparently it's "closing the loop from adjustment back to "what should I physically measure next."" (and yes, it in fact does that, and works well).
2. A shader doing "resolution-independent procedural texturing of a hyperbolic ground plane". Basically the result of me asking "I want something like Hyperbolica to play with on my phone, now now now", followed by "cool but it got ugly tessellation artifacts far from origin". I'm not qualified to judge whether this is in any way not obvious, but Claude is framing this as "specific technical solution to a specific floating-point problem, which is exactly the flavor of thing that survives §101 scrutiny best".
3. There's one I'm afraid to even describe because it has to do with UX of VLMs and that could make it novel enough somebody will patent it. But to hell with it: basically, take an image annotator (draw colored rectangles on an image), allow user to label the rectangles in the interface, and then save, alongside the image, a file mapping colors to labels. This was my idea to avoid having to write stuff like "that red thing is XYZ" and "the purple rectangles are VWX". Pretty obvious UX streamlining that's one of many that apparently no major AI provider thought of yet...
--
1. is a shared invention - me pushing for ergonomics, LLM figuring out the "game loop". 2. was Claude Fable all on its own - I just told it it's ugly and looks like the kind of nonsense you get at the poles of a globe made of triangle strips, and it came up with the shader. 3. was my idea from the start.
Question to patent people: are things like this really patentable? I hope not...
I grew up in the 1960's. We lived in a suburb of Detroit where my father was a mechanical engineer who worked on drive trains and suspensions for Cadillac. My mom was a homemaker. We had one car. The house where the six of us lived was 1/3 the size of the one just my wife and I live in today. We had a black and white TV that got the network broadcasts, a single dial phone, a washer, a dryer, a stove, a toaster and a small refrigerator. My mom had a plug-in steam iron. My dad did the lawn with a push rotary mower and trimmed the sidewalks with hand clippers. We kids had bikes and board games. I did not know anybody with air conditioning. The most luxurious things we had were time, leisure and the outdoors that nobody minded us losing ourselves in for hours at a time. This isn't nostalgia by the way. I wouldn't go back. But if you could, somehow, you'd be shocked at how much less of nearly everything material there was.
Levittown-style homes for returning WWII veterans were poor quality -- "little boxes all made of ticky-tack" as the song goes, but even high quality homes of the midcentury were still tiny -- the average size of a US house in 1960 was 1,289 sq ft -- basically apartment sized. And typically only had one bathroom
And even if you "had AC" it typically wasn't central AC. Even when I was growing up in the 1970s our only AC was a window unit in my parents' bedroom. On hot summer nights we would go and sleep on their floor.
Residential units? Or does that include businesses too? Cause 12-15% for residential units sounds high for 1963.
Air conditioning was extremely uncommon in my neighborhood when I was growing up in the 80s. I didn't personally know a single family that had a/c until the 90s. The only places that were air conditioned in my neighborhood in the 80s were businesses. I'm sure it was more common in the South.
That's more like the top decile than the average. The top decile in any era has it pretty good.
Most of the "life is too expensive today" complaints are some flavor of: Grandpa was a 90th percentile income earner and I am a 50th percentile income earner, so even though my life is objectively much better than Grandpa's in many ways (childhood vaccination, clean air, seatbelts, etc) the loss of status is much more salient than the gains in material well-being.
Great for rich people or just not your relative purchasing power being completely eroded. Why work for a 5% raise if it means all your expenses go up 5%?
The situation you're positing already basically exists with housing - who literally ask for proof of your income - and while housing goes up at unreasonable rates due to lack of construction, it clearly doesn't go up at the same rate (and _definitely_ not by the same raw amount) as income does.
Cool. Now we can write bugs in our theorem descriptions instead of source code.
Seriously, please review Curry Howard Isomorphism if you’re getting pulled down this rabbit hole.
Programs are proofs. Proofs are programs.
So if you can formally describe the correct output for every input, you can have an LLM loop automatically fill in the gaps of how to get there. Congrats, that sounds at least as hard as writing the correct program in most cases.
Don’t get me wrong, I do think there are useful tools combining formal methods and llms. Let’s just not get carried away.
It is true that finding the correct specification is a formidable task; knowing what correctness even means is arguably most of the difficulty of programming. However! "Moving bugs up from programs to types" isn't how this shakes out in practice, at all. Another commenter already noted that it's often much easier to communicate your intent through specifications, because you can essentially always say what a computation should do much more simply than you can say exactly how to do it.
I think it's also important not to miss the forest for the trees: even relatively simple specifications like "the compress and decompress functions must be inverses for all inputs" rules out vast classes of bugs in a compression library. This is not a complete specification; for instance, it does not speak about how the decompressor behaves on malicious input. But in my experience, even partial specifications carry the promise of hitting warp speed with LLMs in a way that I haven't seen anywhere else. After a certain level of specification, you have decent guarantees of being able to whole-heartedly forget about the implementation details of the synthesized program. And you get a better-built, more robust program out of it at the end!
The comment at the end of the article about having LLMs directly generate assembly against specifications and letting them rip with finding custom optimizations is the sort of crazy stuff this enables. I really think we're only seeing the tip of the iceberg here. People keep asking what we can do with LLMs that we couldn't before; this is the answer.
> Congrats, that sounds at least as hard as writing the correct program in most cases.
That's not remotely true. Or, more formally speaking since we're in a thread about proof assistants, it's not remotely true, up to extensional equality, plus some choices about which axioms you use.
I can write a formal description of what it means to have property in a way that does have computational content that is equivalent to an algorithm[0], but often the clearest way to express the property is equivalent to an algorithm that literally brute forces the problem, like sorting a thing by checking every permutation until you find one that's sorted.
The magic is that you can write a spec that's clear, then have the LLM write the code and prove the spec, so you know that given the right inputs/state, it will return the right outputs/state. Then the gap is performance-like characteristics, which is a pretty great starting point and a lot easier to be just empirical about than correctness.
[0] in Lean you can also use classical logic or add your own axioms, where it's not even comutational.
> That's not remotely true. Or, more formally speaking since we're in a thread about proof assistants, it's not remotely true, up to extensional equality, plus some choices about which axioms you use.
Really unnecessary levels of snark here.
> often the clearest way to express the property is equivalent to an algorithm that literally brute forces the problem, like sorting a thing by checking every permutation until you find one that's sorted
Have you ever heard of prolog? I’m sure a prolog program can express whatever property you’re attempting to write just as tersely (if that’s your metric for hard). Almost copy/pastable to and from a theorem proofer.
Or are you saying that the program has to be the efficient implementation? Because that’s a different ball game. I’m not even going to get into how you could provably transform brute force propositional logic into efficient algorithms. (At that point we’ll have finally created the fabled “sufficiently smart compiler” and probably solved p=np).
A huge majority of software is simple business rules + CRUD that is trivially verifiable. The entire problem is showing that an efficient/reliable program actually implements those rules.
> The magic is that you can write a spec that's clear
Maybe you can. But I did spend a grad class with rocq (coq at the time) and a decade working with “systems engineers” and am not convinced that this is a realistic expectation.
> I’m not even going to get into how you could provably transform brute force propositional logic into efficient algorithms.
> The entire problem is showing that an efficient/reliable program actually implements those rules.
Reliability is a standard matter of correctness and captured (partly) by specifications. Efficiency tends to be easy to empirically test, but it is also possible to capture at the specification level [1]. Mind that specifications need not be all-consuming.
> But I did spend a grad class with rocq (coq at the time) and a decade working with “systems engineers” and am not convinced that this is a realistic expectation.
Agree! But this stuff just got massively more accessible, and the tooling around it is growing quickly. I think we'll end up growing specification systems specific to various domains which will be palatable to those "systems engineers", but I err on the side of optimism here. There's definitely a lot left to do for practicality.
[1] See the work of https://cs.nyu.edu/~shw8119 for the case of provably-efficient parallelism and garbage collectors
> Really unnecessary levels of snark here. [..] Have you ever heard of prolog?
Why do you look at the speck of sawdust in your brother's eye and pay no attention to the plank in your own?
> I’m sure a prolog program can express whatever property you’re attempting to write just as tersely
No, you won't be able to express the most basic properties in Prolog at all, let alone as tersely as in a proper specification language.
E.g. if you have a language interpreter and a bytecode interpreter, pretty much every specification language will let you express the correctness of a compiler `compile(x)` as
Huh, I wasn't actually going for snark. I was trying to preemptively be over-specific about what I meant. As in, you said "... writing the correct program..." and I meant that I'm talking in terms where functions are equal or distinct only based on extensional equality and with some flexibility on computational interpretation and axioms of the logic.
Like, if you meant "the correct program" in a sense where two pure total functions can be different despite both having the same outputs on the same inputs, then that's not what I'm responding to.
And yeah I know prolog, but proof assistants and logic programming are totally different beasts. Definitely not copy/pastable to/from lean, at least as I've seen and used each.
> Or are you saying that the program has to be the efficient implementation? Because that’s a different ball game. I’m not even going to get into how you could provably transform brute force propositional logic into efficient algorithms. (At that point we’ll have finally created the fabled “sufficiently smart compiler” and probably solved p=np).
I think you're totally misunderstanding. What I'm saying is that in something like Lean (just because I know it best) I can say, "this function takes inputs satisfying Prop1 and returns outputs satisfying Prop2," in ways where I write some brute-force equivalent formalization of Prop1 and Prop2 in the most straightforward way, and then go on to prove that they are true of my program that is not the brute force implementation. Like the wacky famous magical inverse square root implementation from Quake III. You could write a spec that "output = 1/sqrt(input) up to float properties" and the implementation in the famous brainfuckery way. To your comment about how the spec is as hard as the implementation, "output = 1/sqrt(input)" is way easier than the weird efficient implementation, and that class of distinction is super common.
And as you said, the annoying part is showing that the efficient implementation satisfies the spec, but what's magic today is that we have great tools and LLMs can and do fill in the blanks. In practice, I write the spec by hand for the stuff I care about and then prompt the rest and know that my spec is what the LLM implemented.
> > The magic is that you can write a spec that's clear
> Maybe you can. But I did spend a grad class with rocq (coq at the time) and a decade working with “systems engineers” and am not convinced that this is a realistic expectation.
I tried rocq back when it was coq too, and now do most of my work in lean and rust and python with totally normal folks and I'm convinced that the tooling and languages are finally just about Good Enough. If you have any interest in the field, which it sounds like you do, and if you haven't checked out the ecosystem in the last couple years, I'd recommend you check it out again.
A lot of the “high level assembly” parts of C are actually compiler extensions and not from the C spec.
libc is even worse.
reply