| The responses to this comment seem to miss a vital point that the comment is making: languages executed within a different primary language are usually opaque to the tools in use. Those tools are usually aimed purely at the primary language, not any secondary languages used within it. Tools for the secondary language are now much harder to use because they (usually) have to be invoked and used via the primary language. If I’m working on a Python script which has some jq embedded in it, then these problems probably exist: - My editor will only syntax colour the Python, and treat jq code as a uniform string with no structure - My linter will only consider Python problems, not jq problems - My compiler, which is able to show parsing errors at compile time rather than runtime, will not give me any parsing errors for jq until execution hits it (yes, Python has a compilation step) - jq error messages that show a line number will give me a relative line number for the jq code, rather than the real line number for where that code lives in the Python file - My debugger will only let me pause and inspect Python, and treat the jq execution as a black box of I/O I’m discussing this as a jq problem, but this happens far more commonly with SQL inside any host language. No wonder ORMs are so popular: their value isn’t just about hiding/abstracting SQL, it’s about wrangling SQL as a secondary language inside a different primary one. - Microsoft’s LINQ for C# - Webdev-focused IDEs which aim to correctly handle HTML and Javascript inside server-side languages (e.g. PHP) - what else? |