I don't want to learn your query language (2018)

&gt; I just want my SQL back. It&#x27;s a language everyone understands, it&#x27;s been around since the seventies, and it&#x27;s reasonably standardized. It&#x27;s easy to read, and can be used by anyone, from business people to engineers.<p>I rely a lot on SQL and in general advocate for it, but that’s too simplistic of a view IMHO. SQL makes it easy to write and read simple queries, and ridiculously complicated and arcane to write slightly more complex logic.<p>More than once I’ve been asked to help fix giant SQL queries written by a business or analytics team and that’s a terrible experience.<p>Also, the tooling around SQL is often terrible and almost didn’t evolve during the past 15+ years. SQL queries from another programming language without an ORM means that you do everything by manipulating strings by hand, with zero type safety.<p>Edit: My favorite library in Go is reform, a generator that generates types and implement the Scanner&#x2F;Valuer interfaces. You annotate your structs, generate the types, add the generates files to git, done. That way you have very limited ORM magic but gain some type safety. And you still have complete control over your SQL queries (which is often frustrating to do with classic ORMs).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;go-reform&#x2F;reform" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;go-reform&#x2F;reform</a><p>Edit 2: the most promising ORM I’ve seen is Prisma, <a href="https:&#x2F;&#x2F;www.prisma.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.prisma.io&#x2F;</a>. I haven’t tried yet, I’m still quite attached to writing most of my SQL by hand because that’s what I know well, but their pitch seems good to me.

A long time ago, I designed and created an ORM for Java. I brought it to a startup and we made some money selling it. One of the key features was that it went a long way to solving the N+1 problem, which was a unique feature at the time.<p>Obviously, I bought into the whole ORM concept, but I did have doubts in the back of my mind, some of which showed up in this article. You have to retrieve all of the columns needed to constitute an object. There is no subtlety in controlling the SELECT clause. Getting object identity right is hard, (e.g. you don&#x27;t want to distinct Customer objects representing the same real-world Customer just because you ran two queries that happened to identify the same Customer). Caching is hard, especially when there are stored procedures doing updates and your ORM has no insight into them. Sometimes it would be nice to just write the damned SQL. Schema and&#x2F;or object model changes are difficult, because you need to keep the two in sync. When I wrote my own database applications, I didn&#x27;t want an ORM, not even mine. I wanted to write SQL. Having some tools to manage PreparedStatements and Connections would have been nice, but for my own work, I really preferred writing my own SQL.<p>But what finally changed my mind completely about ORMs was a hallway conversation with a developer at a prospect on Wall Street. (I think it was one of the firms to go under in the 2008 crash.) She told me that her resume looks a lot better with &quot;5 years Oracle experience&quot;, than with &quot;5 years XYZ ORM experience&quot;. This, combined with the doubts that were accumulating in my mind, finally pushed me over the edge.<p>In later years, playing with various web development frameworks, I dreaded dealing with ORMs. It&#x27;s as the article said: I don&#x27;t want to learn yet another query language, only to have that translated, badly, into SQL. Just let me write the damned SQL, it isn&#x27;t that hard. I know exactly what SQL I want to run. Why should I create work for myself in convincing the ORM to do what I already know how to do?

It is a bit falicous to imply SQL is the same everywhere. If you move from postgres to sql server to mysql to oracle you&#x27;ll see there are major differences in how things are done.<p>Sure, your select and join is mostly the same, maybe with a few different commas here or there. Once you get into complex large data operations though it&#x27;s a whole new ballgame.<p>Imports happen in wildly different ways, temp tables, choices of inserts vs. updates is a per-platform choice in some cases.<p>On top of all that, an ORM like entity framework (C#) handles things like making sure the statements are prepared in a way that &quot;handles&quot; major security issues like dependency injection out of the box.<p>If you make your team use an ORM you don&#x27;t have to worry quite as much about someone named &#x27;;DROP tables <i>&#x27; signing up to your system. (Or whatever)<p>ORM has it&#x27;s place. SQL isn&#x27;t a monolith that </i>everyone* knows.<p>The discussion is worth having, but I think the OP&#x27;s argument lacks nuance.

I never get the ORM hate for CRUD apps.<p>It gives a centralized place to understand what data is in play in the application and adding a new column to the database means updating a class &#x2F; struct &#x2F; type in one location and checking the use of that within the code base.<p>Without an ORM and with poor discipline I end up having to go find every query in the app referencing that table and check if I need to update the query which usually means changing the columns, the ? value placeholder and putting the correct value in the associated values container.<p>It all seems like a lot of tedium and ripe for simple typos in the queries that is easily avoided by using beneficial tooling.

I&#x27;m a &quot;hardcore&quot; SQL developer, but still deem ORMs [commonly] necessary. Importantly:<p>&gt; Their alleged benefit is they cut down development time<p>&gt; Let&#x27;s dispel with the myth that ORMs make code cleaner<p>This is very narrow view of what ORMs do; without them, access to the DB layer becomes a black box.<p>Actually, not even the black box definition is appropriate - APIs to access the DB layer are needed in one way or another, so one ends up writing their own ORM.<p>ORM APIs do a lot more than just executing queries. The first thing that pop into my mind is persistence&#x2F;state management, but also, composing queries is much more than bashing together a series of strings.<p>EDIT: elaborated on ORM APIs role.

And while we&#x27;re at it, I don&#x27;t want to learn your programming language. Everyone should just use Java for everything, FFS. &#x2F;s<p>Seriously, the idea that everything maps well onto relational databases is incredibly misplaced. Not everything is tables, tuples, and relationships. Most RDBMSs graft a million slightly incompatible features onto SQL to attempt to handle all the things SQL doesn&#x27;t understand, like GIS and full text search.

The bigger problem with ORMs is not that they require you to learn a new language, but that they are abstractions and very leaky ones at that. Typically they add a lot of complexity, caching (which seems like a great idea until you have a lot of fast updating data), make it harder to scale horizontally and so on. They also usually do not have a good impedance match with the underlying storage layers resulting in a lot of tricks to do stuff that would have been easier done by bypassing the ORM, but that then gives you inconsistent data because now you are also bypassing the cache of objects.

Old discussion on HN (2018) for the same article here: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17890760" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17890760</a>

An ORM is a tool. They have their place: They aren&#x27;t a replacement for knowing how to use a database; and you need to understand the performance &#x2F; development time tradeoffs.<p>I had to fight a battle to remove a very slow ORM that was used for a SQLite database with 4 tables. After I removed the ORM from a critical code path, startup went from 24 hours to about 2 minutes. Raw SQL was &quot;worth it&quot; because the schema was brain-dead simple.<p>I more recently optimized some C# Entity Framework code that took minutes to run and brought it down to seconds. In this case, there were many tables and many joins, so going down to raw SQL wasn&#x27;t &quot;worth it.&quot; All I had to do was recognize that the code was relying on lazy-loading, and then I just pre-loaded the entities.<p>BUT: I should point out that ORMs can be extremely powerful. Using a tool like Linqpad with C# and Entity Framework, you can write ad-hoc queries much more easily than SQL.

ORMs and SQL at least have the same goal which is to join datasets and perform operations on them.<p>SaaS platforms build _filter languages_ that are (sometimes vaguely) inspired by SQL. I really wish there was a standard among filter languages that was optimized for interactive search. Interactive search is different from application search because in interactive search you don&#x27;t know what fields there are so you are mostly counting on substring matches. But you still want to be able to include multiple substring matches (AND) and exclude things as you find them that aren&#x27;t what you&#x27;re looking for (AND NOT).<p>I think Google&#x27;s search language is one of the best filter languages out there in terms of simplicity&#x2F;effectiveness. Splunk&#x27;s language is good as well (but maybe they&#x27;re just making up for it in good typeahead support).<p>I&#x27;d like a standard for Google&#x27;s search language with implementations for in-memory filtering in every major programming language and implementations for generating SQL from the filter for every major programming language.<p>Until this happens there&#x27;s not really much hope for standardizing on filters across applications.

When I work with non-OO languages, an ORM isn&#x27;t missed. Rather, flexible language-native data structures are gained. When I first stepped outside the OO world after years in, I couldn&#x27;t help but notice how much &quot;technology&quot; was just compensating for problems imposed by OO languages.

I understand wanting to stick with a tried and true query language, but it doesn&#x27;t surprise me at all that a new database technology has a new language. Sometimes things are just not going to work the same.<p>ORMs, though... I tried to get on board with those, and it&#x27;s done nothing but bite me. As the article says, I end up spending more time in the documentation, and then my boss ends up questioning the choice as well when things (like in the article) happen.<p>In the end, I think the ORM has been as much pain as help, and I&#x27;d have been better off just not bothering.

I recently installed ClickHouse (part of my self-hosted Plausible setup) and had to modify a record inside the database. At this point my only knowledge of ClickHouse was that it comes with an SQL interface. So I opened up a client and typed &quot;SHOW DATABASES&quot; and guess what - it showed me a list of all databases. Then I typed &quot;USE mydatabase&quot; and I was connected to my database. I typed &quot;SHOW TABLES&quot; and got a list of tables, followed by &quot;DESCRIBE TABLE users&quot; and &quot;UPDATE users SET email_verified = true&quot; (FYI I was trying to avoid having to set up SMTP credentials for Plausible). I was able to use ClickHouse without any prior knowledge because the authors decided to based it on a well-known and fairly simple standard instead of inventing their own.<p>It felt as good as building Ikea furniture without checking the manual and it&#x27;s what user&#x2F;developer experience should be about.

I would actually applaud the proposal to have the EU mandate that SaaS products must expose all my data in a &quot;plug-and-play thing&quot; (in a format queryable using SQL?). I can already download it on most services, but usually get some collection of JSON files...

What about Elasticsearch that invents and deprecates features for it&#x27;s query language on every major release. Then you have several ways of doing the same query with all kind of filters, all of them which can&#x27;t tell you if a certain field is NULL.

It’s probably just a function of the apps I happen to have worked on, but I have rarely (maybe never?) seen ORMs pay for themselves by the end. The classic joke about the business is that they see all of the costs and none of the value. But the developers tend to see all of the value and none of the costs. And the costs of ORM on a project have a very long tail. For most projects, if you really want to control what and how the developers interact with the database, a better approach is to have one or more separate db developers who create an API for the data via stored procedures.

There are three fairly independent points being made here:<p>1) ORMs (which are used in cases where you have control over the DB) are bad and you should just use SQL<p>2) DSLs (in non-SQL DBs) are bad and the devs should have just exposed SQL<p>3) DSLs (in opaque services) are bad and the devs should have just exposed SQL<p>I tend to agree with #1, though it&#x27;s complicated and there&#x27;s lots to be said on both sides.<p>#2 seems semi-reasonable, if the semantics are close enough to those of a SQL DB, but the problem is that DBs like Mongo have wildly different semantics from SQL.<p>#3 is harder because an opaque service usually <i>specifically wants</i> to insulate users from its implementation details. The great majority will not want to give you direct access to a SQL database. So the only alternative would be to &quot;fake it&quot; and pretty much base their DSL on SQL, which may or may not line up with the semantics of their service.<p>For both #2 and #3, exposing SQL when the underlying semantics may or may not be a good match for the query language seems questionable at best. It encourages assumptions to be carried over that may not hold, especially around performance characteristics (which the OP specifically mentions as an advantage, surprisingly). I just don&#x27;t see how this is tractable in the general case.

&gt; What&#x27;s worse than data silos? Data silos that invent their own query language.<p>I can&#x27;t agree more. Bespoke query languages and back-ends are generally only good for two groups: the vendors and consultants. SaaS apps with their own query languages and NoSQL flavored back-ends end up being nothing but headaches for the poor FTEs that have to spend their days in the drudgery of having to figure out anything beyond a basic query.

I like SQL. The problem with SQL is that it is a string and simple errors, like an extra comma, are not caught by the compiler&#x2F;interpreter. Are there good well-thought out libraries that are isomorphic to SQL but can be used with a language like Python or Clojure?<p>For example, I want to write simple SQL queries this way:<p><pre><code> (-&gt; &quot;table&quot; (cols col1 col2 col3) (where (= col1 10)) (order-by col3 :desc))</code></pre>

Author seems to take for granted that not everyone knows sql. A friend of mine recently hired a couple devs and asked them to build a web component. They didnt know html. But they were proficient with react.

&gt; I just want my SQL back.<p>Which of them? There are as many SQLs as there are implementations. You can&#x27;t take an SQL schema from one DBMS and drop it into a different one, without conversion. Also you can&#x27;t take a query written for particular SQL implementation and expect it to work and return the same results, except for very simple queries.

This can be abstracted to a general critique with frameworks overall.<p>On smaller scale projects, cut out as many frameworks as possible. Stick with the bare minimum of tools. Pure Ruby, versus Rails. Pure Javascript versus jQuery. SQL queries versus ORM. Etc. It&#x27;s less to maintain, less to learn, AND it forces you to learn the underlying technology.<p>On larger-scale and longer-term projects where you expect to work with others and&#x2F;or will need to hop back into the code on a regular basis for years, <i>cautiously</i> introduce frameworks (and ORMs). In those cases, frameworks solve more problems in the long run. I&#x27;m usually annoyed early on, as frameworks force you to learn their DSLs (etc). But there&#x27;s always a point where the benefits start to outweigh the initial negatives.

It is very high time for a successor on sql that solves sql problems. Verbosity, local functions, reversed order table&#x2F;field select, reusability and other big problems should be solved by sql itself. A newer better version, perhaps compiling to backward compatible sql.

Spark lets users query via regular SQL or DSL (Scala, PySpark).<p>The DSLs are generally better to work with. Complex queries can be broken up into composable functions that can be mixed and matched to perform different analyses. Functions are easier to unit test, document, deal with quoting better, can be type safe, etc.<p>Some super-complex queries are still better to write with regular SQL.<p>New query DSLs don&#x27;t need to reinvent the wheel. They can implement their query capabilities using the Row &#x2F; Column &#x2F; DataFrame abstractions that are elegant and familiar in popular projects like Spark. We need an ANSI query engine DSL.

I am not sure if this is a case against DSLs in general?<p>Eg. the security rules and query lang around Firestore locks down what the develop can ask for in a way that keeps queries run fast. Not doing so could pose a security risk. However, for an on premise setup with just a limited number of trained people it seems reasonable that they should have full power.<p>Ie. I am pro DSLs as they allow to mitigate other concerns.

One thing that ORMs shine in is query composition. For example, starting from a base definition for retrieving a list of entities, you can _dynamically_ compose orthogonal operators that modify the base query, e.g. projection, filtering, sorting, grouping, joins, etc. without having to manually write SQL for every combination of those operators; the ORM takes care of generating the SQL code for you.<p>That being said, ORMs still don&#x27;t enjoy the level of trust that optimizing compilers have enjoyed for decades. That&#x27;s always going to be a barrier for wide adoption, especially from folks who are experienced in SQL. It&#x27;s similar to how in the 1950s (and maybe somewhat 1960s) there was resistance for &quot;automatic coding&quot; by compilers; those who were experienced in assembly thought that compilers will always produce sub-optimal code. But it&#x27;s clear that high-level languages have won (at least outside embedded&#x2F;low-level drivers).<p>The point is: any form of code generation will always find resistance until it proves itself.

I understand the author&#x27;s frustration, but his railing against ORMs is misplaced. First, if you don&#x27;t want to use an ORM or your application doesn&#x27;t warrant one, then don&#x27;t use one. Also, all ORMs let you do raw SQL because there will be times where the ORM abstraction will be too cumbersome.<p>But to be clear, either you use an ORM or you&#x27;re going to invent a new ORM because your app doesn&#x27;t talk in SQL, it talks in Objects - so whatever you do, there will be some mapping between the SQL query response, and objects that you will need to create to pass around in your app. If your app is expected to work with different databases, each with their own SQL flavor, you&#x27;re going to have abstract that as well.<p>And of course, ORMs tend to have good sets of defaults built in (like proper escapes). So whatever ORM-like framework you build, you&#x27;ll have to take care to cover that case, otherwise you&#x27;re back in the bad old world of SQL injection.

I sympathize with the author -- I also choose plain old SQL whenever possible. But SQL is not a good option. It is the least bad option. I even worked on my own alternate query language, Plisqin: <a href="https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;plisqin&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;plisqin&#x2F;index.html</a> I was never expecting it to gain adoption. But if any SQL alternative ever does gain adoption (in the same way Typescript has for JS), I really hope it looks at least a little bit like Plisqin. Specifically, when joins are values and not language constructs, things get a lot better. Also, please satisfy these 3 rules: <a href="https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;plisqin&#x2F;research-language.html#%28part._.My_.Ideal_.Query_.Language%29" rel="nofollow">https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;plisqin&#x2F;research-language.html#...</a>

A response to this article, <i>I Don&#x27;t Want to Teach my Garbage DSL, either</i>, was discussed here on HN almost two years ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20059029" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20059029</a><p>In that discussion, I made this comment¹, which I still stand by:<p>If you’re developing a DSL which is just a query language, you are reinventing the wheel, and you should ask yourself if any benefit of your language over SQL is worth the effort of all your users to learn your new query language. It may be worth it of your data can not be usefully be modeled by tables; e.g. document query languages like XQuery and even simple XPath are useful and can not be easily replaced with SQL.<p>1) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20059337" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20059337</a>

So this article is muddy.<p>The author has a beef with two things and claims to have a problem with a third. The author seems to dislike ORMs for their abstractness and general inefficiency when interacting with a SQL database (this is the nature of an ORM, either stop writing OOP code and as a result stop requiring an ORM, or use a graph database for your graph data (object state)). The author also seems to dislike SaaS query languages or something like that, a topic I don&#x27;t know much about.<p>This gets all rounded up under the topic of &quot;Query DSLs&quot;.<p>When I hear &quot;Query DSL&quot; I think SQLAlchemy Core. A library designed to provide an API to a SQL database which looks like you&#x27;re writing python (implemented through overloading tricks and some fancy OOP metaprogramming tricks). SQLAlchemy Core is great, the author would not hate it because you&#x27;re effectively writing SQL without all the footguns.<p>SELECT * FROM user; -&gt; select(m.user)<p>SELECT * FROM user WHERE name == &#x27;test&#x27; ORDER BY surname; -&gt; select(m.user).where(m.user.c.name == &#x27;test&#x27;).order_by(m.user.c.surname)<p>By having python native code you can generate SQL statements using idiomatic python. If you do some kind of coverage tests (no idea what the kids these days call these but the idea is to run all the python code to ensure there isn&#x27;t a low hanging fruit which would get caught at runtime) you can find &#x27;select&#x27; typoed as &#x27;slect&#x27; early on in development rather than it ruining your Friday when such a bug gets into production. This also makes parametrized queries painless which prevents many potential security issues with generating SQL.<p>If you want to you can also use the generic subset of SQL this way and SQLAlchemy Core will iron out the creases. But personally I think it&#x27;s pointless to make a choice of SQL database if you&#x27;re then going to not use all its special features. It&#x27;s like writing some kind of polyglot-lang which can be translated to C, Java, Pascal, prolog, Lua, scheme and rust. You pick a language for the task, pick a database for the task too.<p>So it&#x27;s important to isolate these features mentioned above from &quot;ORM&quot; and whatever the other thing the author was talking about. People use ORMs and they realise they suck and it&#x27;s important to remember that although the core concept of an ORM is flawed, not all the features which come bundled with an ORM are bad ideas (or at least it doesn&#x27;t mean that those ideas can&#x27;t be done well when you are not trying to implement an ORM).

This article would have a lot more impact if it was an unveil for a solution

I totally agree with the views of the author. That is basically why I started to build an ORM that does not include a query builder. Best of both worlds.<p>Now the design was far from easy, and keeping things reasonably simple without abstracting the SQL part was my biggest challenge. And this would not have been possible without the template-string tagging feature of modern JS, so it wouldn&#x27;t be doable for many other languages.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Seb-C&#x2F;kiss-orm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Seb-C&#x2F;kiss-orm</a>

I don&#x27;t care if other people use ORMs or not, if they don&#x27;t force me, but yes please on this: &#x27;Every SaaS product should offer a plug-and-play thing so that I can copy all the data back into my own SQL-based database.&#x27; Some nice way to incrementally copy&#x2F;sync my data from some saas into my database would be great. Even a full data dump from some JSON endpoint is good enough if it has stable unique keys on all entities, thanks to UPSERT being pretty good for this kind of data syncing.

there are so many intersecting problems here, that I feel like we argue about different ones at the same time.<p>Are you a human and want to query a database? SQL is probably it. (a SQL of some sort, but a pretty good shared understanding) Even if it&#x27;s not relational exactly, it probably comes with some project with things like records&#x2F;rows and columns&#x2F;fields.<p>Do you have some kind of relational model that needs accessing? SQL sounds pretty good, and you know it from writing queries as a human...<p>But should you construct queries with string concatenation? No! Absolutely not.<p>Do you have to write the queries yourself? Like what if you want to stick an object in a database? Can&#x27;t it write the query for you? It&#x27;s appealing, but leads to sadness and anger at some point. (Joins? Conditions of more than 2 degrees? lots of dark corners very close by)<p>AND whatever model objects are used become a defacto database schema, so you can&#x27;t really refactor them in the same way you would other models. So you better not expose them past whatever datastore touching interface you have. So why not just define them in SQL DDL in the first place?<p>What if you want to write the query (or need to to be sure you&#x27;re getting exactly what you expect) but type-safely? LINQ? Absolutely! jOOQ? Sounds good! Arel? Sure! And maybe you get some amount of programmatic composability as well with any of these. Thankfully they&#x27;re not really ORMs or extremely thin ones at that.

The author notes that SQL has been around since, roughly, 1974 - but MultiValue Query Language&#x2F;ENGLISH has been around since the the 60s. The choice is clear. &#x2F;s

I enjoy using the SQLAlchemy ORM. It makes it trivial to divide a query in several parts that you can mix and match.<p>In my experience, features such as a search engine that supports many filters are much easier to maintain if they are written with an ORM rather than with raw SQL. I don&#x27;t have a preference for simple queries.<p>On the other hand, I find MongoDB&#x27;s query language and its popular Python ORMs (Pymongo and Mongoengine) painful to work with.

For what it’s worth YQL was pretty neat back when Yahoo still had some decent engineering going on. Single SQL-like query language for accessing <i>all</i> of their services. Way way underutilized for how amazingly powerful it was.<p>I actually still had a little bit of code in production using it when they shut down.

I don&#x27;t see this anywhere in this thread: <a href="http:&#x2F;&#x2F;blogs.tedneward.com&#x2F;post&#x2F;the-vietnam-of-computer-science&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blogs.tedneward.com&#x2F;post&#x2F;the-vietnam-of-computer-scie...</a><p>That is essential reading for anyone arguing against or for ORMs.

I found that Rails&#x27; way of doing data access -- which completely hides the SQL from you -- to be really confusing, but people seem to absolutely love it once they get it under their feet. I prefer to write SQL&#x2F;sprocs. What&#x27;s the consensus these days?

&quot;There should be a 30 year moratorium on inventing new query languages.&quot;<p>That! Totally agree!

SaaS providers who come up with their own unique query languages are evil. I’m looking at you, New Relic, with your NRQL bullshit.<p>Seriously, what is so ambiguous with “GROUP BY” that you had to invent your own keyword for it?

“Maybe European Union can mandate this” tongue-in-cheek? Maybe not but either way, NO! Keep the government out of my computer pls. Oh almost forgot to ask, do you agree to accept all of my cookies?

DSLs are modern day version of language explosions in a niche ecosystem (CS) in a short period.<p>Interested in how DLS like expression evolving on other industries like Music, Science, etc

What about this: <a href="http:&#x2F;&#x2F;root.rupy.se" rel="nofollow">http:&#x2F;&#x2F;root.rupy.se</a><p>You can view source to see the HTTP parameters or just WireShark it.

Nobody seems to have posted Stuart Halloway&#x27;s Narcissistic Design yet, so I&#x27;ll just leave this here.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=LEZv-kQUSi4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=LEZv-kQUSi4</a><p>Has some great insights and quips. &quot;Nothing says &#x27;screw you&#x27; like a DSL&quot;

This is an essay version of xkcd &#x27;standards&#x27;. It&#x27;s not wrong, but it&#x27;s not the entire picture.<p>The author is correct, sql does everything they need, cause it&#x27;s so expressive. (Mysql8 is turing complete with it&#x27;s domain specific syntax duh-duh-daah...) But that power comes at the cost of scrutiny and composition.<p>ORMS are fish in a barrel--they fail because they are the wrong abstraction. Queries shouldn&#x27;t be the language, they should be the verbs in the language.<p>With a very restricted query AST, introspection and composition are possible. If queries point to the same table, you can combine them into a new query whose result cells are union or intersection of the input result cells. You can automate joins and subquery indexing. You can recover from a dropped column by replacing references to it with null, and limp by with partial results instead of no results.<p>I agree with the author&#x27;s hate on DSLs as a substitute for sql... when they have the same level of abstraction. But if you want queries to be lego bricks that snap together, the bricks can&#x27;t have NP hard surface area. DSLs fill that need.

heck, what if we just make the database an immutable graph, and use functional programming on it in our language of choice? oh wait, that&#x27;s Datomic. Except, Java is quite lame. Let&#x27;s rewrite Datomic in Rust please!

Abstraction is useful though. Don&#x27;t tie yourself to specific database system.

I agree with this so much omg.

More apt: Can we agree on a simple, modern query language that is better than SQL, which is fine but a little antiquated? Because the issue is standardisation more than anything.

I was sure this post would be about SPARQL; the web as a distributed DB is genius, but a new query language with tuples and specialized servers weren’t the answer I’d imagined.