And that's why you ask for a high level plan for something like that before you let the agent write any code. Then you review the plan for flaws, revise it, and prompt the system to fill out more details for each step. Repeat as necessary. Yes it's slow, but it's the best way of using this "glorified autocomplete" to ease and speed up real work.
Bridging software with domain-specific needs of its professional users is nothing new: that is how domain-specific professional software gets built. What is new is that the people doing this are being referred to hysterically as "class traitors", when the improvements they're working on will bring massive and widely available benefits to professionals the world over.
The relevant programming paradigm is string/term rewriting, which is featured in other programming languages such as Pure. It seems to have few direct applications outside of symbolic computing itself, compilers and related fields such as PL theory. (Formal calculi and languages are often specified in PL theory as rewrite rules, even though the practical implementation may ultimately differ.)
For a simple classification task you generally want to prioritize regularization over more sophisticated behavior, so fewer parameters with larger quantization makes sense. For more generic chat-like purposes, Q2 of a larger model may often be preferable to Q4 of a smaller one.
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.
I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC), as well as the program will simply crash on arbitrary memory reinterpretation, use-after-free, and reading uninitialized memory. This is certainly better than it continuing, but certainly not as good as it could be.
CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.
In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.
So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).
* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.
> I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC)
Yeah this is where I stand with it. Fil-C seems to be the worst of all worlds. It combines the performance of an immature GC language, with the primitive syntax and ecosystem of C. (Eg nullability, void*, no generics, no collection types, a bad standard library, header files, no good build system, bad cross-OS portability, BYO strings, etc).
I don't choose C for its wonderful syntax. I choose it because its small, light and performant. If I was happy to use a garbage collector, I'd much prefer to go all the way and grab Typescript, C# or Go.
The only use case I can see for Fil-C is running legacy code that you can't be bothered porting to a better language.
Really what I'm getting at is that people are not done innovating on C ergonomics and safety and that there is potential there. Not that there is a new shivel-ready paradigm shift that has arrived to C. I'm only saying that that may happen and that it is more likely than most people credit.
Fil-C is actually not very low-level efficient, Golang probably has better efficiency (being built from the ground up for lightweight concurrent GC) and a hypothetical support within Rust for "pluggable" GC heaps might be even more clearly preferable.
> It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.
This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.
> Rust has nothing new (even the lifetime stuff is copied) really.
Rust has nothing new by academic standards, and this is an explicit goal of the project. (And that's why it has yet to support e.g. Haskell-like higher-kinded types; or dependent types for compile-time programming: the interaction with its low-level featureset is very much an open question.) It's incredibly novel as a production language, of course.
"End of human-based value creation" is tantamount to post-scarcity. It "breaks" capitalism because it supposedly obviates the resource allocation problem that the free-market economy is the answer to. It's what Karl Marx actually pointed to as his utopian "fully realized communism". Most people would think of that as a pipe dream, but if you actually think it's viable, why wouldn't you want it?
Right now, their wiki page on device support [0] lists zero actual devices as "fully supported":
> These are the most supported devices, maintained by at least 2 people and have the functions you expect from the device running its normal OS, such as calling on a phone, working audio, and a functional UI.
> Besides QEMU devices, this is currently empty. The ports we had here earlier weren't as reliable as we would have liked. We plan to add new devices here with a higher standard.
The most recent smartphone in the Community section of that page is the Fairphone 4, released half a decade ago, in 2021. Pixel devices can trivially be bootloader unlocked, but that doesn't make the work that goes into supporting them much easier: the latest device in Testing is the 6a/6 Pro, from 2022, and its device page lists all the features but the most basic (touchscreen, flash, internal storage) as "Untested".
reply