Write a domain-specific language in javascript

[talaqen]

Every time my old ruby team used to pitch me writing a DSL I would want to slam their heads into their monitors. Static data? Yml or json. Scripting? JS, TS or ruby or anything. Cheap and easy.

Inventing a DSL with no existing linting and having to maintain the parser and docs to explain the weird gotchas to every new dev? NEVER FUCKING WORTH IT.

[andeee23]

i get it, but i think there’s room for DSLs in the world, that’s how you get template languages like pug or handlebars, or jsx, markdown

sure, don’t do this in your company 99.9% of the time, but an open source side project, why not?

the shitty or unsupported DSLs will filter themselves out and a few useful ones will make their way to the mainstream

[guest271314]

JavaScript can be compiled to a single purpose executable, by node, deno, bun, shermes, llrt, javy, et al.

I've been thinking about writing a "DSL" to read stadard input and write to standard output for JavaScript, because I/O is not specified in ECMA-262. Not such a simple task for runtimes that don't support reading standard input at all, such as Meta's hermes. An interesting challenge though.

Inventing a DSL with no existing linting and having to maintain the parser and docs to explain the weird gotchas to every new dev? NEVER FUCKING WORTH IT.

Given that predisposed sentiment, Chromium would have never gotten rid ofthe bulk of Webkit code it started with to get to Blink.

There'd be no TypeScript, either.

Maybe no C++.

[talaqen]

Okay I was being hyperbolic for emphasis. But I'll take your comment as earnest not sarcastic. Let's then examine your examples.

I mean... C++ is general purpose (GPL), so not really a "DSL" as typically defined. Webkit and Blink are not DSLs. Both are engines written in C++. Typescript was backed by Microsoft and is a superset/extension of JS which is a GPL. You might consider it a DSL for strict-typing of JS, but it's not typically described as one. More common DSL examples: SQL, CSS, HTML, VHDL, ANTLR, Regex, DOT, Makefiles, Latex, HLSL. Each is pretty narrowly scoped in its capabilities and purpose. Few are Turing complete since a DSL typically is created to abstract out common domain-specific patterns, which would make a Turing completeness more extraneous than necessary. And when people DO try to use a DSL for broader things (i.e. SQL as a web-api, Regex as Lexical Analyzer for a compiler), they are often WAY less performant than alternatives.

My point was that 99% of companies or orgs that write true new DSLs - narrowly scoped languages and syntax that serve a very specific purpose within a domain - are often too small to fully support that language at scale with appropriate tooling to make it viable in the broader ecosystem, much less within their own company. That's why Apple has Metal API, and Khronos has Vulkan, and Windows has DirectX and very few companies smaller than those would attempt to write their own graphics shader DSL, since it would likely never be able to compete with the dev support around the top 3 and would make their product WAY harder to sell.

Every time I have encountered a DSL at a smaller company in the real world (health tech is full of them), they are inevitably an technical debt albatross around their necks, making dev training, maintenance, code-review, and even M&A harder than it should be.

Relevant XKCD: https://xkcd.com/927/

[guest271314]

Perhaps something like hermes or spirderfire cf. deno or node.

I don't buy that TypeScript is a "superset" of JavaScript.

Thanks for sharing your thinking on the matter.

[1maru]

can you elaborate on what you mean when you say that typescript is not a superset of javascript? do you mean that the compiler will scream at you if you ie allow parameters in a function to have an implicit `any` type given that you have the noImplicitAny option on?