3 ms·

Yep, and SQL-builders are the first thing I thought of, too. These tools are great for letting someone build something they don't understand, and leaves them c

by _jal 6y ago

Yep, and SQL-builders are the first thing I thought of, too. These tools are great for letting someone build something they don't understand, and leaves them completely adrift when something goes wrong. The next step is they bring this nonstandard thing to "the expert", who has to figure out their tool before they can figure out what's going wrong...

simias 6y ago
I don't think SQL builders are a good comparison because: - SQL can already be made fairly readable by default, it's not just a long series of cryptic tokens. The main point of SQL builders is not to make SQL more readable, it's to make SQL approachable by people who don't know SQL. - There can be several ways of achieving the same result in SQL, with sometimes deep performance implications, so it's really important to understand what is being executed and in what order. Regular languages are much simpler and while the string representation of the regex might end up longer than the handcrafted equivalent, the runtime performance should end up being the same since in the end it's all deterministic finite automatons. - SQL builders have to be at least a little bit opinionated to be really useful, in general they make it easy to create simple queries but can quickly become limiting for complex queries, especially if you already know SQL. These "verbal expressions" on the other hand can easily map 1:1 with raw regex constructs, allowing somebody who already knows regex to express exactly the same logic, just in a more verbose and human readable way. This verbose syntax operates at exactly the same level of abstraction as normal regex, it's just a syntactical transform effectively. It's like JSON vs. CBOR or something like that.
- _jal 6y ago
  > There can be several ways of achieving the same result in SQL, with sometimes deep performance implications Which is also very true of regexes, especially the more feature-rich ones variants. And the existence of variants was a large part of what I was getting at. > it's just a syntactical transform effectively Yes, it is tooling that helps people do things they don't understand.
bjarneh 6y ago
> These tools are great for letting someone build something they don't understand Exactly, how can the same concept re-appear in all sorts of forms in this industry? Another thing I though of was Mule, which I used a few years ago (it's hopefully better now). A horrid mess of an Eclipse-plugin that drew boxes with arrows between them, where "standard plugins" etc. could be plugged in to transform data and move it from here to there. The problem Mule solved (in our case) was comical, the complexity of the solution was also comical, or tragic; or maybe it was both.

by _jal 6y ago

simias 6y ago

I don't think SQL builders are a good comparison because: - SQL can already be made fairly readable by default, it's not just a long series of cryptic tokens. The main point of SQL builders is not to make SQL more readable, it's to make SQL approachable by people who don't know SQL. - There can be several ways of achieving the same result in SQL, with sometimes deep performance implications, so it's really important to understand what is being executed and in what order. Regular languages are much simpler and while the string representation of the regex might end up longer than the handcrafted equivalent, the runtime performance should end up being the same since in the end it's all deterministic finite automatons. - SQL builders have to be at least a little bit opinionated to be really useful, in general they make it easy to create simple queries but can quickly become limiting for complex queries, especially if you already know SQL. These "verbal expressions" on the other hand can easily map 1:1 with raw regex constructs, allowing somebody who already knows regex to express exactly the same logic, just in a more verbose and human readable way. This verbose syntax operates at exactly the same level of abstraction as normal regex, it's just a syntactical transform effectively. It's like JSON vs. CBOR or something like that.

_jal 6y ago
> There can be several ways of achieving the same result in SQL, with sometimes deep performance implications Which is also very true of regexes, especially the more feature-rich ones variants. And the existence of variants was a large part of what I was getting at. > it's just a syntactical transform effectively Yes, it is tooling that helps people do things they don't understand.

bjarneh 6y ago

> These tools are great for letting someone build something they don't understand Exactly, how can the same concept re-appear in all sorts of forms in this industry? Another thing I though of was Mule, which I used a few years ago (it's hopefully better now). A horrid mess of an Eclipse-plugin that drew boxes with arrows between them, where "standard plugins" etc. could be plugged in to transform data and move it from here to there. The problem Mule solved (in our case) was comical, the complexity of the solution was also comical, or tragic; or maybe it was both.