Skip to main content

AI has killed the DSL. Long live the DSL!

(This article is pure opinion and is not based on any facts what so ever...)

At present (in April 2026) not only are most programmers not writing code directly, we are not writing Domain Specific Languages directly either. A domain specific language, unlike a general programming language, is a language written to solve a specific problem. Often a DSL is translated into a general purpose language (either by interpreter or compiler) and exists to help a programmer read code and reason about a problem in a more readable way.

One example that comes to mind is a Arel which is a DSL for writing SQL queries. While SQL is already quite user friendly on the surface, queries can become complex quite easily after a few joins. Also, there are slight differences in SQL depending on which database you use (e.g. Postgres vs MySQL vs Oracle) so having a DSL smooths over these changes as well.

However, sometimes achieving what you want to do in Arel can be harder than doing it in raw SQL and also Arel doesn't always write the most efficient code in the world. Arel also assumes you are using models with standard inheritance and you might not be. Overall though, Arel is designed to make life easier for you.

Enter AI.

With AI you can describe the queries you want (rather than having to specify everything exactly) and it can write them directly in SQL. You can also point it to an existing query (or group of queries) and have it explain to you what it does. On top of that you can ask AI to redesign the existing queries for performance if needed.

If you can do that, why would you need to write anything in Arel anymore?

As there are existing DSLs and a lot of code written using them (which AI is also capable of writing) they will not be going away anytime soon. However I would think twice before making a new DSL today. There are probably fewer reasons to do so than there were in the past.

Labels:

Comments

Post a Comment

Popular posts from this blog

Freezing Gems

What is a gem and why would you want to freeze it? In Ruby, there are times when you want to access pieces of functionality that other people of written (3rd party libraries) and you normally have 2 options. You can install a plug in or install a gem. Normally the method you use is determined by which ever is made available by the author. Gems are installed on the host machine and are pretty handy when you want to run things in the command line or else across lots of projects, but their downside is that if you use a gem in a Rails project there is no automatic publishing mechanism when you deploy your site. You will need to log onto the remote host machine and install the gem manually. Plugins are specific to Rails and are similar to gems in that they are also 3rd party libraries. However they are associated with your Rails project as opposed to your machine so they will get posted to the server on a regular deploy. Freezing a gem is the process of transforming a gem into a plug in. Es...
22 comments
Read more

Unit/Functional Testing RubyAMF

One of my current projects is using RubyAMF to communicate with Flash (http://rubyforge.org/projects/rubyamf/). On the whole this is really nice because it allows you to transfer Ruby objects directly to ActionScript ones (as opposed to translating the object into XML, sending the XML and then recreating the object in ActionScript). However, Rails does not provide a built in transport mechanism for AMF, so we cannot run functional testing directly on the data call (as we could for an XML or HTML transport layer). This is a show stopper for a lot of people (Rails w/o Unit testing = a big mess of trouble when something goes wrong). We can though serve both the HTML and the AMF formats depending on the request format. This means that we can test the object instantiation logic and make sure there are no errors in the controllers (though we cannot check the actual format of the data being served). In the controller, instead of rendering AMF alone, do the following respond_to do |format| ...
22 comments
Read more

CSS Back to basics: Here comes TRBL

So I guess CSS is not obvious to everyone. One of my coworkers asked today why you sometimes had 1 value after a "padding" attribute and sometimes you had 2 or 4 values. Basically, padding: 5px; Puts a 5 pixel padding on an element. padding: 5px 3px; Means you have 5 pixels of padding on the top and bottom and 3 pixels on the sides padding: 3px 4px 5px 10px; Means you have 3 pixels of padding on top, 4 on the right, 5 on the bottom and 10 on the left. A good way to remember this is the acronym TRBL (like "trouble"). The same applies to "margin". As well as this, you also have extra attributes which can specify the top, bottom, right and left paddings on their own i.e. padding-left: 10px; Sometimes, if only one side is unique, it's better to refer to it in the following way (for readability). padding:5px; padding-left: 10px; The "padding-left" of 10px will override the "padding" of 5px, but only on the left side of the element. paddi...
6 comments
Read more