[dead]
LLMs pose an interesting problem for DSL designers
81–90 of 157 posts
Re: LLMs pose an interesting problem for DSL designers
#82Good to see more people talking about this. I wrote about this about 6 months ago, when I first noticed how LLM usage is pushing a lot of people back towards older programming languages, older frameworks, and more basic designs: https://nathanpeck.com/how-llms-of-today-are-secretly-shapin... To be honest I don't think this is necessarily a bad thing, but it does mean that there is a stifling effect on fresh new DSL's…
Skynet will be run on C
We need to ensure humans can still find buffer overflows in order to win the war!
Re: LLMs pose an interesting problem for DSL designers
#83Why care what others are doing? Just do what makes sense for your domain and don't worry about what is hot. Who cares?
If something is useful people will use it. Just because it seems like llms are everywhere, not everyone cares. I wouldn't want vibe coders to be my target audience anyway.
Re: LLMs pose an interesting problem for DSL designers
#84People often use the analogy of LLMs being to high-level languages what compilers were for assembly languages, and despite being a terrible analogy there's no guarantee it won't eventually be largely true in practice. And if it does come true, consider how the advent of the compiler completely eliminated any incentive to improve the ergonomics or usability of assembly code, which has been and continues to be absolute…
An ignorant perspective, from someone likely hasn't coded assembly ever. Assembly is tied to the system you target and it can't really be "improved". You can however improve ergonomics greatly via macros and everyone does this.
Re: LLMs pose an interesting problem for DSL designers
#85People often use the analogy of LLMs being to high-level languages what compilers were for assembly languages, and despite being a terrible analogy there's no guarantee it won't eventually be largely true in practice. And if it does come true, consider how the advent of the compiler completely eliminated any incentive to improve the ergonomics or usability of assembly code, which has been and continues to be absolute…
We got LLVM IIR which is sort of like… similar-ish to assembly but better and more portable, right? Maybe some observation could be made there—it is something that does a similar job, but does it in a way that is better for the job that actually remains.
Re: LLMs pose an interesting problem for DSL designers
#86We're making a prompting DSL (BAML https://github.com/BoundaryML/baml ) and what we've found is that all the syntax rules can easily be encoded into a Cursor Rules file, which we find LLMs can follow nicely. DSLs are simple by nature so there's not too many rules to define. Here's the cursor rules file we give folks: gist.github.com/aaronvg/b4f590f59b13dcfd79721239128ec208
Anecdotally, Cursor's tab complete model learns BAML incredibly quickly
Re: LLMs pose an interesting problem for DSL designers
#87Coincidentally, I released a DSL last week called Hypershell [1], a Rust-based domain-specific language for shell scripting at the type level. While writing the blog post, I found myself wondering: will this kind of DSL be easier for LLMs to use than for humans? In an initial experiment, I found that LLMs could translate familiar shell scripting concepts into Hypershell syntax reasonably well. More interestingly, the…
Your experience with Hypershell points to an interesting possibility: LLMs as DSL translators rather than replacements. This could actually democratize DSLs by lowering the learning curve while preserving their domain-specific benefits. The real opportunity might be DSLs optimized for both human semantics and machine translation.
Re: LLMs pose an interesting problem for DSL designers
#88It's it just me or does the graph of LLM language performance versus training set size show the opposite of what they are saying? To me it looks flat, implying training set size has little influence on LLM performance in the language. For instance some niche languages appear to out-perform better known languages (with more variance in the niche language performance).
Re: LLMs pose an interesting problem for DSL designers
#89Replace “DSL” with “languages” in general - the same issues apply. I’m not sure that in a hypothetical timeline where Rust was released today, it would have gotten any traction.
Re: LLMs pose an interesting problem for DSL designers
#90I do not use LLM and I continue to work in the older way. Also, domain-specific stuff can still be useful sometimes, and other stuff involved with designing a programming language.
If someone's not using LLMs yet in 2025 to write code they're basically Amish. They're riding a horse in the age of automobiles, just because they think they're more comfortable on horseback, while they've never been in a car even once.
AI bros sound like NFT bros.