There are various weird and wonderful niche languages out there, if you appreciate programming languages as an end in themselves. Two examples: Sentient [0] and Factor [1][2].
> The MiniSat solver is Sentient’s default. It is a version of MiniSat that has been compiled to JavaScript with Emscripten. This means that it can run in a web browser and it does not have any dependencies when run from the command-line.
The simplest case where they prove useful is usually when your regex is longest than 20 characters. Write a parser once, and it'll be readable to people other than yourself (if it isn't your schema is bad)
Seems a pity to throw out the various advantages of the high-level solution just because your regex engine doesn't support a scalable syntax.
Advanced regex systems such as the Ragel parser-generator support a composition-friendly syntax, [0] but the average regex system doesn't, and I guess there's no quick fix for that.
A (not)compiler can be made to look for issues in your codebase that already exists. It would need all the tools of a compiler, just that the target is the same as the source language.
There are various weird and wonderful niche languages out there, if you appreciate programming languages as an end in themselves. Two examples: Sentient [0] and Factor [1][2].
[0] https://sentient-lang.org/
[1] https://factorcode.org/
[2] Factor's home-page does a poor job of presenting examples to give a flavour for the language, so here's one on GitHub: https://github.com/factor/factor/blob/master/basis/roman/rom...
Sentient looks neat! Does it use the same strategies as Prolog under the hood?
Good question, I'm afraid I don't know enough about either language to answer that.
The Sentient pages mention Prolog, for what that's worth: https://sentient-lang.org/intro/declarative
> The MiniSat solver is Sentient’s default. It is a version of MiniSat that has been compiled to JavaScript with Emscripten. This means that it can run in a web browser and it does not have any dependencies when run from the command-line.
The simplest case where they prove useful is usually when your regex is longest than 20 characters. Write a parser once, and it'll be readable to people other than yourself (if it isn't your schema is bad)
Seems a pity to throw out the various advantages of the high-level solution just because your regex engine doesn't support a scalable syntax.
Advanced regex systems such as the Ragel parser-generator support a composition-friendly syntax, [0] but the average regex system doesn't, and I guess there's no quick fix for that.
[0] http://thingsaaronmade.com/blog/a-simple-intro-to-writing-a-...
A (not)compiler can be made to look for issues in your codebase that already exists. It would need all the tools of a compiler, just that the target is the same as the source language.