Live data from Hacker News

LLMs pose an interesting problem for DSL designers

kirancodes.me

41–50 of 157 posts

Re: LLMs pose an interesting problem for DSL designers

#41

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.

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.

Re: LLMs pose an interesting problem for DSL designers

#42

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…

Skynet will be run on C

Thank god. A human would have handled malloc failure.

Re: LLMs pose an interesting problem for DSL designers

#43

I think academic programming language research is reeks of fraud and uselessness. Prove me wrong.

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.

Re: LLMs pose an interesting problem for DSL designers

#45
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.

Re: LLMs pose an interesting problem for DSL designers

#46
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.

Re: LLMs pose an interesting problem for DSL designers

#47
post #9
post #8

Earlier quoted context omitted.

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…

Hah, yeah the idea that NoSQL is a better fit for the AI era than SQL is pretty eyebrow-raising.

And AISQL is a thing ...

  https://quickstarts.snowflake.com/guide/getting-started-with-cortex-aisql/index.html
I'm glad i'm retired.

Re: LLMs pose an interesting problem for DSL designers

#48

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.

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…

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.

Re: LLMs pose an interesting problem for DSL designers

#49
post #21

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

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

Re: LLMs pose an interesting problem for DSL designers

#50
post #21

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

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.
Post reply on HN