Programming

PyPika

PyPika is a DSL for creating SQL queries. It works by generating SQL from definitions that you create inline rather than by interpreting models or data classes or structures.

It makes it easy to define minimum projections and is also straight-forward to bind data to as you simply provide the values into the query that is generated rather than binding values to a query definition.

Once you have the query object constructed you call str on the object to obtain the actual SQL which you then need to pass to some execution context.

This also means that it is easy to test what SQL you are generating (although really using a DSL like this means you should really be trusting the library).

I have only had one real problem with the statements I have used to date and that is around the Postgres `RETURNING` statement that allows a generated key to be returned to the caller of an INSERT.

Apart from this using Pypika has been better than using a Python template or writing raw SQL.

Standard
Software, Work

The cruel young men and their DSLs

When faced with the question about how people are meant to learn more and more languages some pundits say that perhaps people shouldn’t be programmers if they cannot learn new languages. When you’re young, bright and brilliant that may seem a reasonable answer. However the truth is that no matter how high you try to set the bar on programming, the amount of programming to be done is far in excess of the capacity of the relatively small number of brilliant people in the world who are inclined to do it. Telling the people who make a living trying to answer this demand, with less stellar qualifications perhaps, that they should shape up or ship out isn’t going to win any friends.

It’s also pointlessly antagonistic. Getting to learn many languages should be seen as a chance to broaden and enhance skills. However that is not going to be attractive if organisations continue to provide incentives in terms of pay and opportunities to specialists. To respond negatively to the suggestion that you discard your hard-won investment in your language of choice is both natural and rational if you run the risk of earning less than the single-focus individual. DSLs will die a death unless they can be incorporated within the scope of an existing big beast language or employers adopt a capability rather than knowledge-based metric for pay rewards.

I also think that DSL aficionados often fail to point out to the broader audience of programmers that learning a DSL or even a variety of languages (most probably meaning at least one functional, dynamic and object-orientated language) will not be the same experience as the current depth learning of languages. Since a DSL should be for a specific purpose and have a small syntax or grammar customised to a particular problem or domain it will not be the same as being able to answer trivia such as what the problems with the Date API are in Java and what the Calendar class sets out to address and whether it succeeds or not. Interview questions may have to revolve around applying a new syntax for dealing with a particular problem instead of the usual language pop quiz.

Advocating languages as solutions should also involve advocating changes in employer priorities. If you don’t link the two then threatening someone’s livelihood actually makes it harder to achieve the DSL’ers joyful Babel of languages that matches tool to problem.

Standard