Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLMs pose an interesting problem for DSL designers

kirancodes.me

Post reply on HN
Print view View original

131–140 of 157 posts

Re: LLMs pose an interesting problem for DSL designers

#131

Post by efitz »

I am not a fan of DSLs. Perhaps there are use cases where they are the best tool, but in general they impose a significant learning burden on those who join a project that uses a DSL. I’ve seen several DSL projects wither and die because no one wanted to learn the DSL because the knowledge and time investment did not transfer forward to anything else they would do in the future. My personal opinion is that DSLs are vanity projects; one can usually come very close to DSL clarity and simplicity by adding appropriate methods or functions. You just don’t get fancy syntactic sugar.

Maybe DSLs are “write-only” languages for humans.

I don’t wish ill or sadness on anyone but it doesn’t bother me at all if LLMs drive DSLs into extinction.

Re: LLMs pose an interesting problem for DSL designers

#132

Post by cogman10 »

efitz wrote: post #131

I am not a fan of DSLs. Perhaps there are use cases where they are the best tool, but in general they impose a significant learning burden on those who join a project that uses a DSL. I’ve seen several DSL projects wither and die because no one wanted to learn the DSL because the knowledge and time investment did not transfer forward to anything else they would do in the future. My personal opinion is that DSLs are v…

IMO, the best way to approach a DSL is simply using existing languages with a fairly flexible syntax. We've done this with groovy and it's worked quiet well. If I were to do it again I'd probably pick something like kotlin or ruby instead just because they both seem to have more industry relevance.

The beauty of picking an existing language as the base is you often get an expansive standard library from the get-go. That means your job as a "DSL" writer is more based on making sure you provide the value adds that make sense for the writers of that DSL.

It's worked particularly well for us because we have a data intake pipeline that has to parse and handle all sorts of random garbage (emails, excel docs, csv files, pdfs, etc).

A language like groovy, ruby, and kotlin all work well because it's trivial to add extensions to the syntax in a way that makes sense for your domain problem. Typescript also wouldn't be a bad choice for similar reasons, the only reason I wouldn't consider it is we run a JVM backend and parsing typescript for the JVM is somewhat of a PITA.

Re: LLMs pose an interesting problem for DSL designers

#133

Post by zero_shift »

NathanKP wrote: post #12

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…

> To be honest I don't think this is necessarily a bad thing,

I do. Would you really argue we discovered perfection in the first sixty years of computer science? In the first sixty years of chemistry we still believed in phlogiston

Re: LLMs pose an interesting problem for DSL designers

#134

Post by waffletower »

Hopefully, this will be an interim concern. While currently vapor, a future LLM might propose and implement effective DSLs when requested. Context windows are increasing and perhaps contemporary LLMs could code for niche languages better with appropriate prompting. However, the cultural, network effects described here are concerning.

Re: LLMs pose an interesting problem for DSL designers

#135

Post by kibwen »

noobermin wrote: post #104
kibwen wrote: post #96

Earlier quoted context omitted.

> Assembly is tied to the system you target and it can't really be "improved". Of course it can. There's no reason for modern extensions to keep pumping out instructions named things like "VCTTPS2DQ" other than an adherence to cryptic tradition and a confidence that the people who read assembly code are poor saps who don't matter in the grand scheme of the industry, which is precisely my point. And even if x86 was se…

>poor saps who don't matter in the grand scheme of the industry Someone is mad. Just because you don't have the patience for it doesn't mean everyone has the same preferences as you do. Anyway, one could argue macros in assembly are part and parcel of the process if you develop things in assembly of significant complexity. If you don't like a particular instruction name, you could always relabel it in a macro to some…

>> poor saps who don't matter in the grand scheme of the industry

> Someone is mad

You're completely misunderstanding me. This isn't my personal opinion, it's simply an observation of the utter indifference of ISA designers to any consideration of ergonomics or developer experience. The rest of your comment aptly explains ways to work around this fact while failing to understand that the whole point of this thread is that it didn't have to be this way. For example, there's no reason that an assembly language couldn't have basic syntactical affodances like namespaced identifiers or pseudo-structural elements like basic if, while, and switch. Hell, in the 80s we had chips that executed Lisp, and today we might still have some brave souls making chips that execute Forth. There's no law of the universe that says that assembly has to be jank and primitive.

Re: LLMs pose an interesting problem for DSL designers

#137

Post by fragmede »

emiliobumachar wrote: post #136

Okay, I'm more then halfway through and still don't get what DSL is an acronym for. Any light?

Domain Specific Language. It's when you invent a tiny programming language with nouns and verbs that are appropriate for some niche. Like maybe for eg wedding planning you wouldn't use json or yaml, but some custom format that lets users define people and who has to sit where and where they can't sit without being professional programmers.

Re: LLMs pose an interesting problem for DSL designers

#138

Post by daxfohl »

seanmcdirmid wrote: post #103
daxfohl wrote: post #62

Earlier quoted context omitted.

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

If LLMs can ever produce implementation and tests opaquely, then perhaps we can instruct at the level of requirements. They will never be good enough at the beginning and we will just provide feedback over the working prototype the LLM generates and demonstrates? I haven’t seen technology move this fast before, so I wouldn’t make any hard predictions about how long actual code written by humans survives. We don’t rea…

I won't say "never", but I guess I left out the caveat that I tried this for a hack week demo once. Working in compliance and onboarding, there's a whole lot of logic around what you have to collect and check, what you have to do around user experience, what steps you can fall back to if something fails, etc. I tried to take all our code and translate it to English to feed to an LLM and see what it would do. But the final result was that, even if it worked perfectly, the English description was longer and more convoluted than the code, would've been harder to make changes to, yada yada, so even if it worked perfectly, it would be a worse option than code.

But maybe there's a future where a "best of both worlds" that intermingles structured code with unstructured verbal instructions, so that you can ensure that the important aspects of your requirements are explicit and deterministic, and the filler parts can be in English descriptions. It'd compile, and you get red squigglies in your editor if something doesn't make sense, maybe even type hints on the English somehow. I think that'd be a pretty good "best of both worlds" because it'd really let you separate the signal from the noise, which is the problem you have when using either English or programming languages distinctly.

Re: LLMs pose an interesting problem for DSL designers

#139

Post by nottorp »

cap11235 wrote: post #127
gylterud wrote: post #120

Earlier quoted context omitted.

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.

But do users care that your code is boring?

If the end result is, and you’re doing games, they might

Edit to add to my sibling comment:

> But some abstractions which makes standard stuff easy, makes non-standard stuff impossible.

I swear that at some point i could tell a game was made in Unity based on the overall look of the screenshots. I didn't know it's the fault of the default shaders, but they all looked samey.

Re: LLMs pose an interesting problem for DSL designers

#140

Post by ackfoobar »

freedomben wrote: post #78
ackfoobar wrote: post #49

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?

Haven't played with either. I don't think OCaml needs a new syntax. Maybe Reason need it for JSX but I don't really do frontend.
Post reply on HN