10 ms·
We should design a specific language to make sure that we can encode the exact requirements that we want. Something that has a limited set of keywords that are
by mycentstoo 2mo ago
We should design a specific language to make sure that we can encode the exact requirements that we want. Something that has a limited set of keywords that are explicit. Wait a minute...
- tomrod 2mo agoThis made me belly laugh.
- amarcheschi 2mo agoSomeone should make a standard for this now there's one standard more
- cwmoore 2mo agothen we can make a frame for it to work
- oblio 2mo agoI've always loved things that grow. Maybe we should name the first frame for work Primavera.
- coip 2mo agofull_circle.exe Complete with all the vaguery, ambiguity, and `undefined`. Who’d’ve thought sycophantic interpreters were what we were building towards up til now lol
- grim_io 2mo agoThe success of LLM's (by usage) tells us that programming languages are still too close to the machine than the actual problem domain as defined by humans. If we truly had the right abstractions, no one would care to use LLM's for programming.
- ACCount37 2mo agoI suspect a lot of "the right abstractions" would be fuzzy and opaque things - more alike to modern AI than to anything from the domain of traditional programming. Because the world is just cursed like that.
- echelon 2mo agoDNA is still too close to molecular biology than the actual problem of harvesting free energy and replicating. I think we see this pattern over and over and it might just be that the problem domain is a weird projection into more dimensions of complexity than it makes sense to directly model.
- vatsachak 2mo agoI disagree. I speak in code to the LLMs. It's just that LLMs are really good at reinventing the wheel that you were supposed to in your codebase. Recent example. struct TensorView<T>{ body: Arc<[T]>, shape: [usize], stride: [usize], offset: usize, } Okay now fill in all the helper methods. And GPT 5.6 Sol did a good job.
- Exoristos 2mo agoThe lengths some of y'all will go to to avoid using JetBrains products.
- vatsachak 2mo agoI doubt anything other than an LLM auto complete could add something like a tensor reshape
- grim_io 2mo agoWith that kind of workflow, you might be faster with AI autocomplete :)
- vatsachak 2mo agoYep! I do use Codex CLI
- andy99 2mo agoI think there’s a kind of laundering that goes on. Like if leadership just told devs to go build something (gave them a prompt) and the devs picked some defaults, leadership wouldn’t like it, they’d want some different interpretation of the prompt, there’d be lots of back and forth. Somehow when it’s the LLM that makes the choices, everyone is impressed with what AI did. It’s really just whatever defaults have been trained in, but somehow we’re ok with this. Part of it is better marketing and communication. Basically the defaults of OpenAI and Anthropic are better than what a random dev will pick. But it’s not really that natural language is a better interface, it’s more that having “AI” for now somehow intermediates responsibility so everyone is ok with what it picked, when they probably wouldn’t accept the same if the internal team came up with it. It’s not too different from hiring consultants.
- PunchyHamster 2mo agoThere is no right abstraction to make runnable human vagueness. At one point someone have to take "what you think it should do" into defined unambiguous spec that is called "code"
- globular-toast 2mo agoBut your job is to write the abstractions. Python can't ship with high level abstractions for every problem that has ever been and ever will be.
- mpweiher 2mo agoYes. Our programming languages are far too low level, and have been for a long time. I've long held this view, LLMs are fairly clear evidence that this is true, because it looks like the much, much more compact prompt(s) have enough information content to create a much larger program in our current languages. So it should be possible to create a non-natural language with the same information density.
- ares623 2mo agoAn LLM Inspired Specification Processing language. Or LISP language for short. Truly this "LISP" language is the language for AI and is the first of its kind in history!
- Zababa 2mo agoMaybe this one will even be successful!
- cfiggers 2mo agoThat really would be a first!
- malloryerik 2mo agoHehe, a good joke, but to be a little boring, Clojure is successful and excellent and LLMs love it in my experience. And it's better in LLM era because there little frictions get agented away so to speak but the benefits mostly remain and are even amplified, like immutability as an example. Parens with overlong functions can be an issue but it's really not such a horror show. And Datomic-flavored Datalog in a Clojure triplestore feels almost made to order for LLMs.
- Zababa 2mo agoInteresting how everyone's favorite language seems to be even better in LLM era, almost like passion, skill level and having LLMs matters more than the language.
- malloryerik 2mo agoYeah great point. In my case I'd dropped Clojure and then returned because of how I could use it with LLMs. Still, the good news is maybe that LLMs don't just kill everything but three languages.
- slashdave 2mo ago
- dataviz1000 2mo agoMy current thinking -- what I've been thinking about a lot yesterday and today -- is not encoding the exact requirements into the prompt and context but rather focus on the verifier and roll back if needed. There are of places in computer science where non-deterministic behavior is optimized. For example, UDP packets which are just ignored and speculative execution in modern CPUs guesses which branch a program will take and rolls back when wrong. Ideally, a cheap verifier checks that the exact requirements are satisfied, rolling back and updating the prompt for another iteration if they aren't. If ten iterations with ten verifications steps at the end of each before the exact requirements are met costs less or in less time than a developer who can accomplish it in one attempt, it is still better.
- MengerSponge 2mo agoWe could write instructions like literature. Maybe we could call it "Literate Programming"? https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming
- moomin 2mo agoI kid you not, I remember writing an example solution with comments explaining how we were approaching the problem. Copilot wrote most of the actual code via autocomplete. And that was a year ago, models have got a lot better since then.
- cyanydeez 2mo agomaybe we should all get specially, local working versions so that when we build our software they're not broken by the whims of multibillion dollar corporations.
- ValentineC 2mo agoCommit Strip seems to be down, so here's the Wayback Machine version: https://web.archive.org/web/20260521130338/https://www.commitstrip.com/en/2016/08/25/a-very-comprehensive-and-precise-spec/ https://web.archive.org/web/20260521130338/https://www.commi...
- jiggawatts 2mo agoI was just thinking of this exact comic, which is etched into my brain for some reason. The obvious counter to this is that we've been going through this evolution of increasing abstraction as developers for nearly a century now. In the 40s and well into the 60s, most code was written either as straight up machine code or an assembly language. MS DOS is almost entirely assembly. UNIX ushered in the era of "high level" portable languages like C, Fortran, and Pascal that some developers hated because they felt like they were losing the fine-grained control that they had with assembly. The compilers just "weren't as good" as humans at optimisation! Then the compilers got better and people started using garbage-collected languages like Perl, Python, Java, JavaScript, and C#. Similarly, many people bemoaned the lack of control over memory allocation, lower efficiency, etc. We're simply stepping up to the next level of abstraction. Look at it this way: decades ago when I first discovered C++ templates, it felt like waving a magic wand in the direction of the computer. It blew my mind that I could simply substitute "float" instead of "double" in between some angle brackets and the compiler would write reams of code for me! We simply have better magic wands and more powerful spells now.
- hmokiguess 2mo agoNow I have the full picture. You're right to push back, and that's on me. The load-bearing seams of language are the smoking gun I should have been aware of.
- triyambakam 2mo agoFair...
- pqdbr 2mo agoFair hit
- Retr0id 2mo agoUntil recently I thought "load-bearing seam" was a satirical exaggeration - I'd seen both claudisms independently but never combined. But a couple of days ago it hit me with "The key structural point first: the only load-bearing seam is [...]"
- knollimar 2mo agothe phrase load-bearing caveat makes me irate
- hmokiguess 2mo agoThis matters. That's the spine of it.
- deleted 2mo ago[deleted]
- pigpop 2mo agoThis is a groaner, especially since we've been writing detailed specifications and whitepapers for decades. The only difference is that we used to write them assuming other humans would create their own implementations to satisfy them but now we write them so AI can create the implementation.
- dcrazy 2mo agoI am using AI to trick my team into writing specs.
- nemo1618 2mo agoI am quite tired of this take, frankly. The implication is that if we continue iterating on prompt optimization, we're going to reinvent what, JavaScript? BASIC? Lisp? English is not a programming language. Yet English is sufficient to communicate requirements to the degree that we actually care about. A programmer's job is to translate English into lower-level machine language. Necessary to this process is "filling in the gaps" -- that is, extrapolating the expressed intent to cover all the little details that were left unspecified. This system works because humans are at least minimally competent at predicting the preferences of other humans. If your prediction turns out to be wrong, you get feedback and iterate. Well, guess what. LLMs are also competent at predicting the preferences of humans. LLMs can "fill in the gaps" like no one's business. LLMs can iterate on requirements like no one's business. Product managers do not speak to programmers in a language that encodes exact requirements, and yet working software somehow gets shipped anyway. LLMs do not need exact requirements either.
- antonymoose 2mo agoMaybe I’m behind the curve here because I work in an SRE/DevOps context as of late - but LLMs routinely shit the bed and fail to solve basic issue for me when I try to use them (Thanks, Management) I don’t need a model to shit out a REST endpoint. I need it to figure out esoteric errors that take hours or days of debugging. They just don’t do well here. Of course, if a diligent engineer refined considerations from a PM and Engineering Manager I wouldn’t have the job I have.
- senderista 2mo agoI dunno, Claude announces it found “the smoking gun” every single time.
- GeorgeTirebiter 2mo agoYes, it IS confident of its weights & biases... but, if you keep at it, Claude WILL find the smoking gun, eventually. Even a broken watch is correct twice a day ( unless it's a digital watch, without a battery, in which case, it's just broken... ) But seriously -- newer Claude (and OpenAI and Google and ???) models DO find the smoking gun, if you let them keep going until they reveal the weird chain of events that leads to a bug. I was seeing the most obscure UART driver bug, where it would work at 1,500,000 baud (!) but fail by only outputting the 1st char at 230.4k and 460.8k -- and it was due to a very narrow race that would check the buffer, if not full, insert a character, and return BUT sometimes the TX Complete interrupt would happen between the check and the insert, and something else would insert, and then - buf overflow. At 1,500,000 the other process didn't have time to do that phantom insert. ANYWAY, Claude found this and proposed a fix -- simpler: spins on IRQ-protected buffer empty checks. I'd hate to think how long it would have taken me to find that. And THAT's the problem -- of course a human CAN find it, with sufficient focus and time; I'm sure you've found a complicated bug pretty easily sometimes, by sheer luck or good engineering instinct. BUT, it seems to me, as human, we are capable of creating potential execution paths that EXCEED our ability to EVER figure it out -- due to not being smart enough, not enough time on the problem, or something makes it economically unfeasible. THIS is where LLMs shine -- let 'em bang at the code for as long as it takes. The recent Mythos bug-finding explosion I think is proof of this conjecture. I think of it like a chessboard, where a machine really can look at all possible execution paths, and locate obscure bugs; a human programer (akin to a chess program) is doing 'alpha-beta pruning' of what's likely, and only after that list is exhausted are the really weird possibilities examined. LLMs are our friends. And, as for "WTF did the LLM just do" when it generates code? I always include the instruction "For this code you just wrote, use Best Practices to document this code, function by function and class by class, and when necessary, line-by-line, so that a junior SW developer can completely understand how this code works, using the documentation standard we use (e.g. Doxygen)." I have also used this technique to learn new languages, or explore ones I only know a little -- it has been a godsend for leveling me up on common lisp, for example. "Give detailed comments explaining what the code is doing, assuming the code reader is fluent in C and Python, and use analogs when possible." Stuff like that.
- avaer 2mo agoThe trend (and what TFA is arguing) is literally the opposite: be more implicit, don't waste time on details, and encode the high level concepts only. Because the rest has a billion examples in the model. You can argue against LLM's, but increasingly (unfortunately) you're not going to do better programming by prompting the LLM with code. The agent can find the interfaces it needs.
- RossBencina 2mo ago> be more implicit The other day I began by asking Claude: "What's the deal with ${current_practice_in_complex_technical_concept}?" and was talked down to like I was an idiot. Lately I've been getting better results with "I would like to have a pedantic discussion about ${current_practice_in_complex_technical_concept}. Please define the main terms of art, then I will ask my questions." Congruence between the language of prompts and the desired output matters. Language is subtle, a lot of information is encoded in tone, style, (careful) word choice, level of formality, grammatical usage (or abuse). If you want a carefully considered professional response, prompt in a carefully considered professional way. Every field has its shibboleths. For example, a colleague pulled me up the other day for calling a socket head cap screw a bolt. Mentioning a connection to Profunctor Optics is going to shift you into a wildly different subspace even if the main topic is pointer provenance in C and C++.
- jerf 2mo agoThe search engines LLMs are the worst. I was reaching for the set of Platonic solids in higher dimensions, and got a lecture about how the Platonic solids are only defined in three dimensions. First of all, wrong anyhow, but also, rude. My search phrase clearly implied that I was aware of it being the uncommon case. I've added into my CLAUDE.md or default user prompts or local equivalents recently something to the effect of "Assume the user is an expert in all fields; while this is clearly logically untrue, the user prefers to get a detailed explanation and dig in to bits he doesn't understand rather than get an inaccurate summary". It seems to help quite a bit with that tone issue you identify. Of course there's nowhere to put that in the search engine default AIs. For something they seem to want to bet their respective companies on, their LLM search seems to be massively stupider than their old-school search engines, which seem to get what I want much more often. There's some coevolution there over some decades, sure, but the search engine AIs make some stupid and socially-inept assumptions quite often.
- butterisgood 2mo agoHuman language is the whole point of a lot of this.
- deleted 2mo ago[deleted]
- usef- 2mo agoThe article is basically saying the opposite: models don't need you to specify as much now. None of it is talking about better or precise language, it's about what you should say to it. (I love how often the highest-voted comment didn't read the article)
- recroad 2mo agoRFC 2119 style requirements have proven to be quite effective for me.
- shhsushs 2mo agoThis is getting tiring. Code is not The Specification. It’s a specification of God knows what. Riddled with irrelevant, non-essential details wrapping The Problem - which in most cases will amount to something the size of a large pebble - in multiple layers of fur jackets, stored in boxes, which themselves are stored in multiple ridiculous moveable warehouse (if you’re lucky). We have a standard for communication, it’s called regular bloody language. Code is an abomination that conflates the shadow with its source.
- dwroberts 2mo ago> Riddled with irrelevant, non-essential details You’re describing natural language too
- ausuusjs 2mo agoActually, no. I can describe the invariants of a complex system quite concisely. Of course skill is an issue. Thing is, “code” does not give me universal building blocks. It gives me coding building blocks out of which I _could_ make a proper language but I could also not. I rather just talk directly in the substrate available to all of us which is “language” instead if some embedded, highly localized idiosyncratic variant that may or may not be able to express my problem.
- bloody_bocker 2mo agoBut then it means what we have now - llm-generated code - is just a dead end, because we are still running an executable built from this "god know what".
- rf15 2mo agoTo piss off architects, managers and linguists all at the same time: language isn't much of a standard at all, it's more the current agreed-ish state of things, quite similar to the current state of a code base. Your inner model of what you like things to be is without direct effect to how things de facto are. In addition: it's not wrapped around a problem, it's wrapped around an attempt at a solution - the problem space is often not even depicted in code, and often only minimally described in documentation.
- mrbnprck 2mo agoYou mean RFC? ;)
- TeMPOraL 2mo agoThis nonsense again? Yes, feel free to write code. It exists. In fact, why did you write your comment in English and not code? It's imprecise and doesn't explicitly state exactly what you wanted to communicate, and is instead full of ambiguity and open to interpretation.
- deadbabe 2mo agoPeople joke about this, but we have actually had LLMs create compilers for our domain specific languages that lets us basically compile a bunch of code in a deterministic way for lots of varied use cases, and it has eliminated the need to always burn tokens when we want some new feature that is just a combination of existing things. I predict this is what future “frameworks” will look like, just very high level specific languages that quickly build out some product in predictable ways every time, but you don’t need to think about complex machine logic, you’re just declaring what you want.
- OzzyB 2mo agoI can help with this. I used to work in an industry that adopted this approach.
- ben_w 2mo agoWhat a pity the customer doesn't know how to do that, and is instead talking directly to the LLM which can write code for them, instead of hiring me to turn their English (or German) into code for them. Of course, if the customer did know how to write code, and encoded their exact requirements that they wanted using it, they'd still not need to hire me…