Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Is it just me or does this seem like a very bad idea?

It's not just you. As you say this can only truly be used by people you understand regular expressions; and they would most likely prefer not to use this stuff.

It seems the whole IT industry is obsessed with helping us do all sorts of things, even simple things, which in the end often makes things more complex. Different query languages that translate to SQL to help us out, which often create super-complex SQL. All sorts of wrappers to avoid us having to deal with all sorts of formats (JSON/XML..). Hopefully those wrappers do something useful with those date-objects you know you have in there somewhere...



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...


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.


> 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.


> 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.


>It's not just you. As you say this can only truly be used by people you understand regular expressions; and they would most likely prefer not to use this stuff.

I know regex and I hate writing it. It's unreadable and I need to spend time remembering/googling/checking the exact syntax. And, of course, the syntax differs from implementation to implementation in subtle but important ways (ie: need to double escape in python, etc.).


Perl and Ruby don't need to escape regex metacharacters so why do Python and Java? It's just archaic.


> It's not just you. As you say this can only truly be used by people you understand regular expressions; and they would most likely prefer not to use this stuff.

There's a niche where this might be useful, but by definition it's small. I understand regexes a moderate amount, and can construct arbitrarily complex ones when necessary. But I do it just infrequently enough that it can be painful and halting above a certain level of complexity, with lots of testing and reference-checking. It'd be nice to use something sane like this, and I think I fall squarely into the category of "people who understand regexes but would prefer to use stuff like this". Though as I said, this niche is almost by definition small, and on top of that I can't remember the last time I used Java.

Completely independently, in any non-trivial engineering system, readability is important, and this helps a lot there.


A lot of IT is the parsing and mapping of one kind of language (whether markup, DSL, Turing complete) on to another.

Doing it right is a delicate balancing act of being just powerful enough to express everything the user needs without devolving into an unreadable or repetitive mess. Some people manage to achieve neither.


> Different query languages that translate to SQL to help us out

That and UI SQL builders. What I want is typeahead column names, not a dropdown for the column, the operator, etc.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: