LLMs just add another reason to this list.
LLMs pose an interesting problem for DSL designers
111–120 of 157 posts
Re: LLMs pose an interesting problem for DSL designers
#112I'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 fro…
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
I'm taking a lot of inspiration from Python in the syntax and I'm actually worried it will trip up any LLM I train on my language since I think it will risk probabilistically just reverting to Python mid-answer Time will tell
Re: LLMs pose an interesting problem for DSL designers
#113It'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).
What the graph shows is that LLMs struggle with "hard" languages (Rust, Go, C#) with the exception of Ruby.
Re: LLMs pose an interesting problem for DSL designers
#114DSL proliferation is a problem. I know this is not something many people care to hear, and I symphasize with that. Smart people are drawn to complexity and elegance, smart people like building solutions, and DSLs are complex and elegant solutions. I get it.
Problem is: Too many solutions create complexity, and complexity is the eternal enemy of [Grug][1]
Not every other problem domain needs its own language, and existing languages are designed to be adapted for many different problem domains. If LLMs help to stifle the wild growth of at least some DSLs that would otherwise be, then I am reasonably okay with that.
Re: LLMs pose an interesting problem for DSL designers
#115Good 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…
I think it's healthy, because it creates an undercurrent against building a higher abstraction tower. That's been a major issue: we make the stack deeper and build more of a "Swiss Army Knife" language because it lets us address something local to us, and in exchange it creates a Conway's Law problem for someone else later when they have to decipher generational "lava layers" as the trends of the marketplace shift an…
This article starts with "gaming" examples. Simplified to hell but "gaming".
How many games still look like they're done on a Gameboy because that's what the engine supports and it's too high level to customize?
How about the "big" engines, Unity and Unreal? Don't the games made with them kinda look similar?
Re: LLMs pose an interesting problem for DSL designers
#116Good 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…
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?
Re: LLMs pose an interesting problem for DSL designers
#117Earlier quoted context omitted.
> 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.
Do you have any opinions on elixir? Have you played around with reasonML?
Re: LLMs pose an interesting problem for DSL designers
#118FWIW, 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 i…
Re: LLMs pose an interesting problem for DSL designers
#119Good. I'll chalk that up as one of the positive effects LLMs have on the software development environment (god knows there are few enough). DSL proliferation is a problem. I know this is not something many people care to hear, and I symphasize with that. Smart people are drawn to complexity and elegance, smart people like building solutions, and DSLs are complex and elegant solutions. I get it. Problem is: Too many s…
Would you say the same about a parallel universe where LLMs were introduced in 1960?
Re: LLMs pose an interesting problem for DSL designers
#120Earlier quoted context omitted.
I think it's healthy, because it creates an undercurrent against building a higher abstraction tower. That's been a major issue: we make the stack deeper and build more of a "Swiss Army Knife" language because it lets us address something local to us, and in exchange it creates a Conway's Law problem for someone else later when they have to decipher generational "lava layers" as the trends of the marketplace shift an…
Not only that. This article starts with "gaming" examples. Simplified to hell but "gaming". How many games still look like they're done on a Gameboy because that's what the engine supports and it's too high level to customize? How about the "big" engines, Unity and Unreal? Don't the games made with them kinda look similar?
But is that the direction LLM coding goes? My experience is that LLM produces code which is much more generic and boring than what skilled programmers make.