[HN Gopher] LLMs pose an interesting problem for DSL designers
___________________________________________________________________
LLMs pose an interesting problem for DSL designers
Author : gopiandcode
Score : 78 points
Date : 2025-06-17 19:17 UTC (3 hours ago)
(HTM) web link (kirancodes.me)
(TXT) w3m dump (kirancodes.me)
| darepublic wrote:
| I recently had to work with the robot framework DSL. Not a fan. I
| hardly think it's any more readable to a business user than
| imperative code either. Every DSL is another API to learn and
| usually full of gotchas. Intuitiveness is in the eye of the
| beholder . The approach I would take is transpiling from
| imperative code to a natural language explanation of what is
| being tested, with configuration around aliases and the like.
| TimTheTinker wrote:
| DSLs are not all created equal.
|
| Consider MiniZinc. This DSL is super cool and useful for
| writing constraint-solving problems once and running them
| through any number of different backend solvers.
|
| A lot of intermediate languages and bytecode (including LLVM
| itself) are very useful DSLs for representing low-level
| operations using a well-defined set of primitives.
|
| Codegen DSLs are also amazing for some applications, especially
| for creating custom boilerplate -- write what's unique to the
| scenario at hand in the DSL and have the template-based codegen
| use the provided data to generate code in the target language.
| This can be a highly flexible approach, and is just one of
| several types of language-oriented programming (LOP).
| Lerc wrote:
| I think Sturgeon's law might be the problem for DSLs.
| Enabling a proliferation of languages targeted at a specific
| purpose creates a lot of new things with a 50% chance of the
| quality being below the median. Using a general purpose
| language involves selecting (or more usually relying on
| someone else's earlier selection) one of many, that selection
| process is inherently biased towards the better languages.
|
| Put differently, The languages people actually use had people
| who decided to use them, they picked the best ones. Making
| something new, you compete against the best, not the average.
| That's not to say that it can't be done, but it's not easy.
| iguessthislldo wrote:
| I'm not skeptical about DSLs in general, but I agree with you
| on robot framework. I think it has a few good points like how
| it formats its HTML output is mostly nice, but how I'm not
| happy with how tags on test cases work and actually writing
| anything that's non-trivial is frustrating. It's easy to write
| Python extensions though so that's where I ended put basically
| all of logic that wasn't the "business logic" of the tests. I
| think that's generally what you're supposed to do, but at that
| point, it seems better to write it all in Python or the
| language of your choice.
| averkepasa wrote:
| Python increase in Tiobe index is scary:
| https://www.tiobe.com/tiobe-index/
| qsort wrote:
| I'm sorry, I simply refuse to take seriously an outlet that
| publishes the following:
|
| """ Remarkably, SQL has started dropping slowly recently. This
| month it is at position #12, which is its lowest position in
| the TIOBE index ever. SQL will remain the backbone and lingua
| franca of databases for decades to come. However, in the
| booming field of AI, where data is usually unstructured, NoSQL
| databases are often a better fit. NoSQL (which uses data
| interchange formats such as JSON and XML) has become a serious
| threat for the well-defined but rather static SQL approach.
| NoSQL's popularity is comparable to the rise of dynamically
| typed languages such as Python if compared to well-defined
| statically typed programming languages such as C++ and Java.
| """
| simonw wrote:
| Hah, yeah the idea that NoSQL is a better fit for the AI era
| than SQL is pretty eyebrow-raising.
| _old_dude_ wrote:
| And AISQL is a thing ...
| https://quickstarts.snowflake.com/guide/getting-started-
| with-cortex-aisql/index.html
|
| I'm glad i'm retired.
| arciini wrote:
| I was pretty convinced by this article to not use TIOBE as a
| mark of a language's popularity:
| https://nindalf.com/posts/stop-citing-tiobe/
|
| Its primary point is that TIOBE is based on *number* of search
| results on a weighted list of search engines, not actual usage
| in Github, search volume, job listings, or any of the other
| number of signals you'd expect a popularity index to use.
|
| It could easily be indicating that Python articles are being
| generated by LLMs more than any other class of articles.
| duskwuff wrote:
| It's even worse than "Stop Citing TIOBE" makes it sound. The
| TIOBE rank is based on the number of hits reported from "25
| search engines", which amount to: 1) Google,
| on nine different TLDs 2) Amazon, on seven TLDs
| 3) EBay, on two TLDs 4) wikipedia.org (which ends up
| defaulting to the English Wikipedia) 5) microsoft.com
| (which only searches Microsoft documentation) 6)
| sharepoint.com (similarly, Microsoft 365 documentation)
| 7) rakuten.co.jp 8) walmart.com
|
| Only one of these is actually a web search engine; there are
| actually more shopping web sites included than search
| engines. Bing, and its various mirrors, were apparently all
| excluded because they don't display the number of hits on the
| result page.
|
| And yes, this only adds up to 23. The TIOBE web site doesn't
| explain the discrepancy.
| jayd16 wrote:
| In the same way LLVM is used to forward port low level
| optimizations to new languages, I wonder if LLMs can interpret
| new DSLs through the LLVM (or similar) lens and provide value.
|
| I suppose this could be done now for all the existing languages
| that target LLVM and unify the training set across languages.
| ajross wrote:
| FWIW, the core assertion here isn't even LLM-specific. DSL design
| leans heavily on the idea of an expert author who understands the
| underlying data model well already. That is no less true in the
| meatspace world than it is for an AI.
|
| DSLs look great if they let you write the code you already know
| how to write faster. DSLs look like noise to _everyone else_ ,
| including Gemini and Claude.
|
| I used to be a big DSL booster in my youth. No longer. Once you
| need to stop what you're doing and figure out your ninth or
| eleventh oddball syntax, you realize that (as per the article)
| Everything is Easier in Python.
| quantadev wrote:
| > DSLs look like noise
|
| Exactly right. Now that we're in the era of LLMs and Coding
| Agents it's never been more clear that DSLs should be avoided;
| because LLMs cannot reason about them as well as popular
| languages, and that's just a fact. You don't need to dig any
| further, to think about pros and cons, imo.
|
| The fewer languages there are in the world (as a general rule)
| the better off everyone is. We do need a low level language
| like C++ to exist and a high level one like TypeScript, but we
| don't _need_ multiple of each. The fact that there _are_
| already multiple of each is a challenge to be dealt with, and
| not a goal what we reached on purpose.
| jbellis wrote:
| I guess if you love writing DSLs this is an unfortunate
| development, but for me it's more of a glass half full: I can
| have the AI spit out boilerplate I need to solve a problem
| instead of spending a week building a one-off DSL compiler.
| mplanchard wrote:
| The benefit of (some) DSLs is that they make invalid states
| unrepresentable, which isn't possible with the entire surface-
| area of a programming language at your (or the LLM's) disposal.
| NathanKP wrote:
| Good 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
| and frameworks. It isn't an unsolvable problem, particularly now
| that all the most popular coding agents have MCP support that
| allows you to bring in custom documentation context. However,
| there will always be a strong force in LLM's pushing users
| towards the runtimes and frameworks that have the most training
| data in the LLM.
| gopiandcode wrote:
| Oh that's a great blog post and a very interesting point. Yep,
| I hadn't considered how LLMs would affect frameworks in
| existing languages, but it makes sense that there's a very
| similar effect of reinforcing the incumbents and stifling
| innovation.
|
| I'd argue that the problem of solving this effect in DSLs might
| be a bit harder than for frameworks, because DSLs can have
| wildly different semantics (imagine for example a logic
| programming DSL a la prolog, vs a functional DSL a la haskell),
| so these don't fit as nicely into the framework of MCPs maybe.
| I agree that it's not unsolvable though, but it definitely
| needs more research into.
| NathanKP wrote:
| I think there is a lot of overlap between DSL's and
| frameworks, and most frameworks contain some form of DSL in
| them.
|
| What matters most of all is whether the DSL is written in
| semantically meaningful tokens. Two extremes as examples:
|
| Regex is a DSL that is not written in tokens that have
| inherent semantic meaning. LLM's can only understand Regex by
| virtue of the fact that it has been around for a long time
| and there are millions of examples for the LLM to work from.
| And even then LLM's still struggle with reading and writing
| Regex.
|
| Tailwind is an example of a DSL is that is very semantically
| rich. When an LLM sees: `class="text-3xl font-bold
| underline"` it pretty much knows what that means out of the
| box, just like a human does.
|
| Basically, a fresh new DSL can succeed much faster if it is
| closer to Tailwind than it is to Regex. The other side of
| DSL's is that they tend to be concise, and that can actually
| be a great thing for LLM's: more concise, equals less tokens,
| equals faster coding agents and faster responses from
| prompts. But too much conciseness (in the manner of Regex),
| leads to semantically confusing syntax, and then LLM's
| struggle.
| TimTheTinker wrote:
| > there is a lot of overlap between DSL's and frameworks
|
| Not just frameworks, but libraries also. Interacting with
| some of the most expressive libraries is often akin to
| working with a DSL.
|
| In fact, the paradigms of some libraries required such
| expressiveness that they spawned their own in-language
| DSLs, like JSX for React, or LINQ expressions in C#.
| librasteve wrote:
| i saw a good post on this earlier today ...
| https://nurturethevibe.com/blog/teach-llm-to-write-new-progr...
| scelerat wrote:
| Linguistics and history of language folk: isn't there an
| observed slowdown of evolution of spoken language as the
| printing press becomes widespread? Also, "international
| english"?
|
| Is this an observation of a similar phenomenon?
| guywithahat wrote:
| Skynet will be run on C
| shakna wrote:
| Thank god. A human would have handled malloc failure.
| NathanKP wrote:
| This is an interesting idea actually, if we assume a couple
| things:
|
| - There likely won't be one Skynet, but rather multiple AI's,
| produced by various sponsors, starting out as relatively
| harmless autonomous agents in corporate competition with each
| other
|
| - AI agents can only inference, then read and write output
| tokens at a limited rate based on how fast the infrastructure
| that powers the agent can run
|
| In this scenario a "Skynet" AI writing code in C might lose
| to an AI writing code in a higher level language, just
| because of the lost time spent writing the tokens for all
| that verbose C boilerplate and memory management bits for C.
| The AI agent that is capable of "thinking" in a higher level
| DSL is able to take shortcuts that let it implement things
| faster, with fewer tokens.
| guywithahat wrote:
| But then we return to the premise of the article, which is
| that LLM's struggle with higher level code that has fewer
| examples. C is much more repetitive and has millions of
| examples from decades of use.
|
| Plus if we assume the bottle neck on skynet is physical
| materials and not processing power, a system written in C
| can theoretically always be superior to a system written in
| another language if we assume infinite time can be spent
| building it.
| winter_blue wrote:
| I think perhaps automatic translators might help mitigate some
| of this.
|
| Even perhaps training a separate new neural network to
| translate from Python/Java/etc to your new language.
| Mathnerd314 wrote:
| Python is just a beautiful, well-designed language - in an era
| where LLM's generate code, it is kind of reassuring that they
| mostly generate beautiful code and Python has risen to the top.
| If you look at the graph, Julia and Lua also do incredibly well,
| despite being a minuscule fraction of the training data.
|
| But Python/Julia/Lua are by no means the most natural languages -
| what is natural is what people write before the LLM, the stuff
| that the LLM translates into Python. And it is hard to get a good
| look at these "raw prompts" as the LLM companies are keeping
| these datasets closely guarded, but from HumanEval and MBPP+ and
| YouTube videos of people vibe coding and such, it is clear that
| it is mostly English prose, with occasional formulas and code
| snippets thrown in, and also it is not "ugly" text but generally
| pre-processed through an LLM. So from my perspective the next
| step is to switch from Python as the source language to prompts
| as the source language - integrating LLM's into the compilation
| pipeline is a logical step. But, currently, they are too
| expensive to use consistently, so this is blocked by hardware
| development economics.
| gopiandcode wrote:
| mhhm yes yes. There's a thread of discussion that I didn't
| quite chose to delve into in the post, but there is something
| interesting to be found in the observation that languages that
| are close to natural language (Python being famous for being
| almost executable pseudo-code for a while) being easier for
| LLMs to generate.
|
| Maybe designing new languages to be close to pseudo-code might
| lead to better results in terms of asking LLMs to generate
| them? but there's also a fear that maybe prose-like syntax
| might not be the most appropriate for some problem domains.
| dack wrote:
| personally i think DSLs could be helpful if they are really good
| at: 1. explaining the syntax clearly 2. providing a fast checker
| that provides good error messages 3. prevents errors
|
| LLMs seem pretty good at figuring out these things when given a
| good feedback loop, and if the DSL truly makes complex programs
| easier to express, then LLMs could benefit from it too. Fewer
| lines of code can mean less context to write the program and
| understand it. But it has to be a good DSL and I wouldn't be
| surprised if many are just not worth it.
| quantadev wrote:
| Since DSLs are necessarily niche, you're never going to have
| much training data in that language to feed into LLM training.
| Sure this problem can be overcome, but you're just creating
| more work than the time saved by having humans code in DSLs.
| MoonGhost wrote:
| Me thinking, is it time for a new 'programming' language for LLM
| to use instead of tools API calls? Something high level with
| loose grammar, in between natural language and strict
| programming. Then the backend, may be another smaller model,
| translates it in API calls. With this approach backend can be
| improved and updated much faster and cheaper then LLM model.
| zzo38computer wrote:
| I 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.
| quantadev wrote:
| 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.
| bluehatbrit wrote:
| I'd be interested to hear how you find staying away from them
| as the years progress.
|
| My experience so far is that they write mediocre code which is
| very often correct, and is relatively easy to review and
| improve. Of course I work with languages like elixir, python,
| typescript, and SQL - all of which LLMs are very good at.
|
| Without a doubt I've seen a significant increase in the amount
| of work I can produce. As far as I can tell the defect rate in
| my work hasn't changed. But the way I work has, I'm now
| reviewing and refactoring significantly more than before and
| hand writing a lot less.
|
| To be honest, I'd worry about someone's ability to compete in
| the job market if they resisted for much longer. With the
| obvious exceptions of spaces where LLMs can't be used, or have
| very poor performance.
| shakna wrote:
| In my experience, its harder to review.
|
| It'll dump you three classes and a thousand lines of code,
| where it should use a simple for loop to iterate.
|
| The code Claude, Gemini and Cursor produces still is not
| enough to pass half-decent quality checks. If you're in
| "compile=ship", sure.
|
| If you care about performance, or security, or
| maintainability, no. It's wasting your time, and the review
| team's time.
| api wrote:
| One of my big concerns (a little tangential) is that LLMs will
| have the effect of fixing programming language design and the
| current language landscape into stone. This could occur in
| proportion to their use by programmers. The languages that LLMs
| do the best and have in their training data will be the languages
| programmers use, and getting any new language into LLM data sets
| will be very hard.
| jp57 wrote:
| Programming languages researchers and designers labor under the
| mistaken assumption that programming practitioners--people who
| are writing programs to solve problems--actually _want_ "a
| language with a syntax and semantics tailored for a specific
| domain", or any really fancy language features at all.
|
| I say this from the perspective of someone who nearly became a PL
| researcher myself. I could easily have decided to study
| programming languages for my PhD. Back then I was delighted by
| learning about cool new languages and language features.
|
| But I did didn't study PL but rather ML, and then I went into
| industry and became a programming practitioner, rather than a PL
| researcher. I don't want a custom-designed ML programming
| language. I want a simple general-purpose language with good
| libraries that lets me quickly build the things I need to build.
| ( _cough_ Python _coughcough_ )
|
| Now that I have reached an age where I am aware of the finiteness
| of my time left in this universe, my reaction when I encounter
| cool new languages and language features now my is to wonder if
| they will be worth learning. Will the promised productivity gains
| allow me to recoup the cost of the time spent learning. My usual
| assessment is "probably not" (although now and then something
| worthwhile does come along).
|
| I think that there is a very real chance that the idea of
| specialized programming languages will indeed disappear in the
| LLM era, as well as the need for various "ergonomic" features of
| general purpose languages that exist only to make it possible to
| express complex things in fewer lines of code. Will any of that
| be needed if the LLM can just write the code with what it has?
| ackfoobar wrote:
| > Will the promised productivity gains allow me to recoup the
| cost of the time spent learning.
|
| Some deep PL stuff I doubt there is productivity gain to begin
| with. But many ideas in the ML language family are simple and
| reduce debugging pain. Time lost from one encounter with muddy
| JS/Python semantics is more than the time learning about sum
| types.
| izabera wrote:
| 30 lines are always going to be easier to read/write/debug than
| 3000 lines, so it'll probably remain easier (for both humans
| and machines) to write correct code in languages that make it
| possible to express ideas concisely and elegantly.
| tptacek wrote:
| From elsewhere on the front page: "given choice between
| complexity or one on one against t-rex, grug take t-rex: at
| least grug see t-rex".
| AnimalMuppet wrote:
| Hmm. Go was written to be easier for junior developers to use,
| and to be maintainable "in the large".
|
| I wonder if we need a language designed to be easier for an AI
| to reason about, or easier for a human to see the AI's
| mistakes.
| username223 wrote:
| That sounds grim, but not implausible. Domain-specific
| languages seemed like a significant improvement over general-
| purpose languages plus libraries. But now that we have a tool
| that lets you make Jazz Hands at your computer and have it spit
| out something that does most of what you want, do they really
| help?
|
| Maybe some boring, kind-of-consistent language like C, Python,
| or Go is good enough. An LLM spits out a pile of code in one or
| more of them that does most of what you want, and you can fix
| it because it's less opaque than assembly. It doesn't sound
| like a job I'd want, but maybe that's just the way things will
| go.
| TeMPOraL wrote:
| On the one hand, this sucks. On the other hand, we're already
| vacillating along the Pareto frontier of how much we can stuff
| into code; in fact, most of the criticisms of DSLs are indirectly
| stating just that.
|
| So with LLMs making it easier to project back and forth between
| how programmer sees the task at hand, and the underlying
| dumb/straightforward code they ain't gonna read anyway, maybe
| we'll finally get to the point of addressing the actual problem
| of programming language design, which is that _you cannot
| optimize for every task and cross-cutting concern at the same
| time and expect improvement across the board_ - we 're already at
| the limit, we're just changing which time of day/part of the
| project will be more frustrating.
| guelo wrote:
| This sounds insightful but I can't make heads or tails of "you
| cannot optimize for every task and cross-cutting concern at the
| same time and expect improvement across the board".
|
| Can someone help me out?
| boznz wrote:
| Unfortunately, English-as-a-programming-language * is now a thing
| and there will be a lot of bad/dangerous/untested code being used
| in real situations going forward.
|
| * Not just English, substitute any other human language into the
| above
| diimdeep wrote:
| I think academic programming language research is reeks of fraud
| and uselessness. Prove me wrong.
| kccqzy wrote:
| A lot of features you take granted in new languages come from
| academic programming language research. Generics in Java for
| example came from GJ, an academic programming language research
| project headed by academics including Philip Wadler.
| munificent wrote:
| Since I work on a language professionally, I think about this all
| the time.
|
| As someone who loves a wide diversity of actively evolving
| programming languages, it makes me sad to think those days of
| innovation may be ending. But I hope that's not going to happen.
|
| It has always been the case that anyone designing a new language
| or adding features to an existing one is acutely mindful of what
| programming language knowledge is already in the heads of their
| users. The reason so many languages, say, use `;` for statement
| terminators is not because that syntax is particularly beautiful.
| It's just familiar.
|
| At the same time, designers assume that giving users a _better_
| way to express something may be worth the cost of asking them to
| learn and adapt to the new way.
|
| In theory, that should be true of LLMs as well. Yes, a new
| language feature may be hard to get the LLM to auto-complete. But
| if human users find that feature makes their code easier to read
| and maintain, they still want to use it. They will, and
| eventually it will percolate out into the ecosystem to get picked
| up the next time the LLMs are trained, in the same way that human
| users learn new language features by stumbling onto it in code in
| the wild.
|
| So I'd like to believe that we'll continue to be able to push
| languages forward even in a world where a large fraction of code
| is written by machines. I also hope that LLM training cost goes
| down and frequency goes up, so that the lag behind what's out
| there in the world and what the LLMs know gets smaller over time.
|
| But it's definitely possible that instead of that, we'll get a
| feedback loop where human users don't know a language feature
| even exists because the LLMs never generate code using it, and
| the LLMs never learn the feature exists because humans aren't
| writing it.
|
| I have this same fear about, well, basically everything with
| LLMs: an endless feedback loop where humans get their
| "information" from LLMs and churn out content which the LLMs
| train on and the whole world wanders off into a hallucinatory
| bubble no longer grounded in reality. I don't know how to get
| people and/or the LLMs to touch grass to avoid that.
|
| I do hope I get to work on making languages great for humans
| first, and for LLMs second. I'm way more excited to go to work
| making something that actual living breathing people use than as
| input data for a giant soulless matrix of floats.
| oleks wrote:
| Using an LLM to generate code is not an easily traceable and
| explainable process. Using a DSL to same ends is. PL research has
| yet to meet explainability in AI head on.
| prats226 wrote:
| For LLMs, programming languages are basically additional
| languages that we speak. So how it handles low-resource
| programming languages is same as how it handles speaking
| languages with less contribution in training data?
|
| DSL's would be even harder for LLM's to get right in that case
| compared to the low-resource language itself
| rramon wrote:
| Sooner or later languages are going to become 3d diagram to code
| IDEs where you just zoom in to get to lower levels of detail.
| keybored wrote:
| Articles in the era of LLMs: assume endless torrent of LLM code
| generation forever, insert how will this affect X now that we
| have our foregone conclusion.
| kccqzy wrote:
| Python is an acceptable though not perfect substrate for
| developing embedded DSLs. It's dynamic enough that you can do a
| lot of things. Besides operator overloading which is commonly
| used in C++ for eDSLs, you can even write decorators that take
| the AST, completely regenerate new code via LLVM or something
| similar. This is the approach used by numba for JIT for example.
|
| In the end I think mentioning Python is a red herring. You can
| produce an eDSL in Python that's not in LLM training data so
| difficult for LLMs to grok, and yet still perfectly valid Python.
| The deeper issue here is that even if you use Python, LLMs are
| restricting people to use a small subset of what Python is even
| capable of.
| kibwen wrote:
| People 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 crap, because
| who cares? That could be the grim future for high-level
| languages; this may be the end of the line.
| Terr_ wrote:
| I suspect the important sticking point will be reliability. The
| "incentive" exists because of an high degree of trust, so much
| so that "junior dev thinks it's a compiler bug" is a kind of
| joke.
|
| If compilers had significant non-deterministic error rates with
| no reliable fix, that would probably be a rather different
| timeline.
| kibwen wrote:
| Yes, that's why I say it's a terrible analogy, but we live in
| a crap world with a fetish for waste and no incentive for
| quality, so I fear for a future where every night we just
| have the server farm spin up a thousand batch jobs to
| regenerate the entire codebase from scratch and pick out the
| first candidate that passes today's test suite.
| daxfohl wrote:
| A big difference is that compilers are deterministic, and
| coders generally don't review and patch the generated assembly.
| There's little reason to expect that LLMs will ever function
| like that. It's always going to be a back-and-forth of, "hey
| LLM code this up", "no, function f isn't quite right; do this
| instead", etc.
|
| This mimics what you see in, say, Photoshop. You can edit
| pixels manually, you can use deterministic tools, and you can
| use AI. If you care about the final result, you're probably
| going to use all three together.
|
| I don't think we'll ever get to the point where we a-priori
| present a spec to an LLM and then not even look at the code,
| i.e. "English as a higher-level coding language". The reason
| is, code is simply more concise and explicit than trying to
| explain the logic in English in totality up-front.
|
| For some things where you truly don't care about the details
| and have lots of flexibility, maybe English-as-code could be
| used like that, similar to image generation from a description.
| But I expect for most business-related use cases, the world is
| going to revolve around actual code for a long time.
| kkukshtel wrote:
| I've been drafting a blog post on this as well. My take is that
| programming langauges largely evolve around "human" ergonomics
| and solve for "humans writing the code", but that can result in
| code that is too abstract and non-performant. I think where LLMs
| will succeed (more) is in writing _very dumb verbose code_ that
| can be easily optimized by the compiler.
|
| What humans look at and what an AI looks at right now are similar
| only by circumstance, and what I sort of expect is that you start
| seeing something more like a "structure editor" that expresses
| underlying "dumb" code in a more abstract way such that humans
| can refactor it effectively, but what the human sees/edits isn't
| literally what the code "is".
|
| IDK it's not written yet but when it is it will be here:
| https://kylekukshtel.com/llms-programming-language-design
| maybevoid wrote:
| Coincidentally, 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, they were able to _fix_
| common issues like type mismatches, especially when given light
| guidance or examples. That's a big deal, because, like many
| embedded DSLs, Hypershell produces verbose and noisy compiler
| errors. Surprisingly, the LLM could often identify the underlying
| cause hidden in that mess and make the right correction.
|
| This opens up a compelling possibility: LLMs could help bridge
| the usability gap that often prevents embedded DSLs from being
| more widely adopted. Debuggability is often the Achilles' heel of
| such languages, and LLMs seem capable of mitigating that, at
| least in simple cases.
|
| More broadly, I think DSLs are poised to play a much larger role
| in AI-assisted development. They can be designed to sit closer to
| natural language while retaining strong domain-specific
| semantics. And LLMs appear to pick them up quickly, as long as
| they're given the right examples or docs to work with.
|
| [1] https://contextgeneric.dev/blog/hypershell-release/
| amterp wrote:
| I've been working on a programming language for about a year
| which aims to replace Bash for scripting but is far closer to
| Python. It's something I hope to see used by many other people in
| the future, but a very common objection I hear from people I
| pitch it to is "yeah but an LLM could just generate me a Python
| script to do this, sure it might be uglier, twice as long, and
| not work quite as well, but it saved me from learning a new
| language and is probably _fine_ ", to which I have lots of
| counters on why that's a flawed argument, but it still
| demonstrates what I think is an increase in people's skepticism
| towards new languages which will contribute to the stagnation the
| author is talking about. If you're writing a new language, it's
| demotivating to see people's receptiveness to something new
| diminish.
|
| I don't blame anyone in the picture, I don't disagree that time
| saved with LLMs can be well worth it, but it still is a topic I
| think we in the PL community need to wrestle more with.
| nylonstrung wrote:
| I love your idea.
|
| LLMs are surprisingly bad at bash and apparently very bad at
| Powershell
|
| Pythonic shell scripting is well suited to their language
| biases right now
| furyofantares wrote:
| I notice I am confused.
|
| > Suddenly the opportunity cost for a DSL has just doubled: in
| the land of LLMs, a DSL requires not only the investment of build
| and design the language and tooling itself, but the end users
| will have to sacrifice the use of LLMs to generate any code for
| your DSL.
|
| I don't think they will. Provide a concise description + examples
| for your DSL and the LLM will excel at writing within your DSL.
| Agents even moreso if you can provide errors. I mean, I guess the
| article kinda goes in that direction.
|
| But also authoring DSLs is something LLMs can assist with better
| than most programming tasks. LLMs are pretty great at producing
| code that's largely just a data pipeline.
| gopiandcode wrote:
| Arguably it really depends on your DSL right? If it has a
| semantics that already lies close to existing programming
| languages, then I'd agree that a few examples might be
| sufficient, but what if your particular domain doesn't match as
| closely?
|
| Examples of domains that might be more challenging to design
| DSLs for: languages for knitting, non-deterministic languages
| to represent streaming etc. (i.e
| https://pldi25.sigplan.org/details/pldi-2025-papers/50/Funct...
| )
|
| My main concern is that LLMs might excel at the mundane tasks,
| but struggle at the more exciting advances, and so now the
| activation energy for coming up with advances DSLs is going to
| increase and as a result, the field might stagnate.
| daxfohl wrote:
| This is somewhat my take too. The way most vibe coding happens
| right now does create a lot of duplication because it's cheap
| and easy for LLMs to do. But eventually as the things we do
| with coding assistants become more complex, they're not
| necessarily going to be able to deal with huge swaths of
| duplicate code any better than humans are. Given their limited
| context size, having a DSL that allows them to fit more logic
| into their context with fewer tokens, we could conceivably see
| the importance of DSLs start to increase rather than decrease.
| neilv wrote:
| I was about to paste the same sentence, and say much the same
| thing in response.
|
| One limitation of LLM for a new DSL is that the LLM may be less
| likely to directly plagiarize from open source code. That could
| be a feature.
|
| Another feature could be users doing their own work, and doing
| a better job of it, instead of "cheating on their homework"
| with AI slop and plagiarism, whether for school or in the
| workplace.
| outofpaper wrote:
| Depending on the size of a DSL all the more recent LLMs can be
| employed to work with them. LoRA/Finetuning are a heavier option,
| followed by RAG, and just setting them up as a big system prompt
| and caching. And once a model is able to work with a DSL tokens
| used in valuable code creation can dramatically drop.
___________________________________________________________________
(page generated 2025-06-17 23:00 UTC)