←back to thread

84 points mkalioby | 1 comments | | HN request time: 0.201s | source
Show context
maweki ◴[] No.42192775[source]
Embedding functionality into strings prevents any kind of static analysis. The same issue as embedding plain SQL, plain regexes, etc..

I am always in favor of declarative approaches where applicable. But whenever they are embedded in this way, you get this static analysis barrier and a possible mismatch between the imperative and declarative code, where you change a return type or field declaratively and it doesn't come up as an error in the surrounding code.

A positive example is VerbalExpressions in Java, which only allow expressing valid regular expressions and every invalid regular expression is inexpressible in valid java code. Jooq is another example, which makes incorrect (even incorrectly typed) SQL code inexpressible in Java.

I know python is a bit different, as there is no extensive static analysis in the compiler, but we do indeed have a lot of static analysis tools for python that could be valuable. A statically type-safe query is a wonderful thing for safety and maintainability and we do have good type-checkers for python.

replies(4): >>42193389 #>>42194000 #>>42194121 #>>42196401 #
eddd-ddde ◴[] No.42194121[source]
I disagree. You'll be surprised to hear this, but source code... is just a very big string...

If you can run static analysis on that you can run static analysis on string literals. Much like how C will give you warnings for mismatched printf arguments.

replies(1): >>42194391 #
maweki ◴[] No.42194391[source]
You might be surprised to hear that most compilers and static analysis tools in general do not inspect (string and other) literals, while they do indeed inspect all the other parts and structure of the abstract syntax tree.
replies(1): >>42195260 #
eddd-ddde ◴[] No.42195260[source]
I know, but that's the point, if you can get a string into an AST you can just do the same thing with the string literals. It's not magic.
replies(3): >>42195362 #>>42196090 #>>42196502 #
1. jerf ◴[] No.42196502[source]
This is one of those ideas that I've seen kicking around for at least a decade now, but manifesting it in real code is easier said than done. And that isn't even the real challenge, the real challeng is keeping it working over time.

I've seen some stuff based on treesitter that seems to be prompting a revival of the idea, but it still has fundamental issues, e.g., if I'm embedding in python:

    sql = "SELECT * FROM table "
    if arbitrarilyComplicatedCondition:
        sql += "INNER JOIN a AS joined ON table.thing = a.id "
    else:
        sql += "INNER JOIN b AS joined ON table.thing = b.id "
    sql += "WHERE joined.
and if you imagine trying to write something to autocomplete at the point I leave off, you're fundamentally stuck on not knowing which table to autocomplete with. It doesn't matter what tech you swing at the problem, since trying to analyze "arbitrarilyComplicatedCondition" is basically Turing Complete (which I will prove by vigorous handwave here because turning that into a really solid statement would be much larger than this entire post, but, it can be done). And that's just a simple and quick example, it's not just "autocomplete", it's any analysis you may want to do on the embedded content.

This is just a simple example; they get arbitrarily complicated, quickly. This is one of those things that when you think of the simple case it seems so easy but when you try to bring it into the real world it immediately explodes with all the complexity your mind's eye was ignoring.