Live data from Hacker News

LLMs pose an interesting problem for DSL designers

kirancodes.me

111–120 of 157 posts

Re: LLMs pose an interesting problem for DSL designers

#111
I've been thinking about the impact on visual programming. I've believed for a long time that any visual programming environment should have flawless round-tripping with a human readable/writable text representation (for many reasons - version control, automation, leveraging decades of tooling around text files, the fact that some tasks are just easier with text)

LLMs just add another reason to this list.

Re: LLMs pose an interesting problem for DSL designers

#112
post #55

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 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

Thanks! :) Yeah in my experience they're okay at Bash but I'm never happy with the scripts it makes, I feel like the ceiling is pretty low on how good Bash scripts can get without a disproportionate amount of effort.

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

#113
post #88

It'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).

It is not only you, but I think it is only you and me. I've also skimmed through the comments and wondering if they are AI generated; or the people even read the article. The author essentially took a graph, and then claimed a different interpretation to reality.

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

#114
Good. 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 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.

[1]: https://grugbrain.dev

Re: LLMs pose an interesting problem for DSL designers

#115
post #71

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…

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?

Re: LLMs pose an interesting problem for DSL designers

#116

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…

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?

I don't think this is necessarily true. Sure, languages are dying out to standard prestige languages, but at the same time, innovations today from more teenage girls evolving English now spread like wildfire across more eyeballs.

Re: LLMs pose an interesting problem for DSL designers

#117

Earlier 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?

neither of those have a realistic payoff in the real world. talking money coming into an account in exchange for jira points available. It's different in SV but elsewhere in the world it's not a realistic proposition.

Re: LLMs pose an interesting problem for DSL designers

#118
post #7

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 i…

yep, im still mad pg SOLD US A LIE (use a secret weapon ancient language in an unmaintainable way that no one wants in the workplace and become a gazillionaire). But gullible people are easily misled (see cults etc).

Re: LLMs pose an interesting problem for DSL designers

#119

Good. 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…

This feels like survivorship bias. Many of those older tools seem like they were once fancy new DSLs. We just respect them now as established, because they've been around for so long. But for every one thousand awkward DSLs that didn't make it, one new tool emerged which lifts software development to a new level.

Would you say the same about a parallel universe where LLMs were introduced in 1960?

Re: LLMs pose an interesting problem for DSL designers

#120
post #71

Earlier 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?

I love writing shaders and manually shovelling arrays into the graphics card as much as anyone, and I know first hand how this will give the game very much your own style.

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.

Post reply on HN