LLMs pose an interesting problem for DSL designers
kirancodes.me
LLMs pose an interesting problem for DSL designers
1–10 of 157 posts
Re: LLMs pose an interesting problem for DSL designers
#2I 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.
Re: LLMs pose an interesting problem for DSL designers
#3Python increase in Tiobe index is scary:
https://www.tiobe.com/tiobe-index/
Re: LLMs pose an interesting problem for DSL designers
#4In 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.
Re: LLMs pose an interesting problem for DSL designers
#5I 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 th…
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).
Re: LLMs pose an interesting problem for DSL designers
#6Python increase in Tiobe index is scary: https://www.tiobe.com/tiobe-index/
[deleted]
Re: LLMs pose an interesting problem for DSL designers
#7FWIW, 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.
Re: LLMs pose an interesting problem for DSL designers
#8Python increase in Tiobe index is scary: https://www.tiobe.com/tiobe-index/
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. """
Re: LLMs pose an interesting problem for DSL designers
#9Python increase in Tiobe index is scary: https://www.tiobe.com/tiobe-index/
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.
Re: LLMs pose an interesting problem for DSL designers
#10Python increase in Tiobe index is scary: https://www.tiobe.com/tiobe-index/
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.