5 ms·
I’m not on board with using a language that only has a single implementation and is complex enough that implementing others is difficult. Please use a language
by nsm 5y ago
I’m not on board with using a language that only has a single implementation and is complex enough that implementing others is difficult.
Please use a language designed for configuration, but still sane. There are several if we leave the JSON-inspired family. Starlark, pystachio, Dhall. All are restricted, but allow functions and code reuse. All are simple enough to write a new interpreter for.
- pbalau 5y agoIf you can afford to wear only one hat, then sure, use one special language for configuration. But I can't, I am the entire infra department and I still need to do product and framework work. Not having to switch context, language wise, is a very nice thing to have.
- tn890 5y agoHonorable mention for Cue[0]. [0] https://cuelang.org/ https://cuelang.org/
- Kinrany 5y agoCUE does look simple enough to be implemented in every language. I wonder if there's anything preventing that. Perhaps there's space for a CUE-like language with an even simpler spec.
- throwaway894345 5y agoTypeScript has at least 2 implementations: tsc and Deno, but I take your point and agree. That said, most languages probably have a JS runtime, so a basic implementation would be ts->js->interpreter. The ts->js is presumably pretty easy.
- junon 5y agoI don't think Deno actually re-implements typescript, does it? Seems like a lot of wasted effort. They don't even use Typescript internally.
- Soremwar 5y agoReimplement in the way that they change certain rules to accommodate a more "modern JS" feel And they absolutely use TS for the std library, just not in the runtime itself
- junon 5y ago> Reimplement in the way that they change certain rules to accommodate a more "modern JS" feel What exactly do you mean by this? > And they absolutely use TS for the std library, just not in the runtime itself Yes, internally. The code that actually makes up deno itself is just plain Javascript.
- dangoor 5y agoI'm pretty sure Deno just uses the open source TypeScript compiler: https://github.com/denoland/deno/tree/main/cli/tsc https://github.com/denoland/deno/tree/main/cli/tsc
- remorses 5y agoThey use swc for transpilation and bundling but, yes, for checking the only solution available now is tsc
- deleted 5y ago[deleted]
- lpapez 5y agoGeniuenly curious, what downsides do you see with a single, reference implementation? I come from C++ world where we have several competing compilers, each slightly different from the other, and all this incurs a non-negligible maintenance cost while providing very little benefit in my eyes.
- Zababa 5y agoThe problem is not a single, reference implementation, the problem is how hard it is to implement another one. "Implementing" JSON is relatively easy, most languages have a JSON library. Most people could probably write a JSON library, not a perfect one, but that would mostly work. And probably do it in a reasonable amount of time. All of that isn't true for Typescript.
- kortex 5y agoIgnoring S-expr based configs for a moment, of the configuration languages, JSON parsing is probably the most straightforward. YAML is a superset of JSON, TOML is probably on par, TS and JS are obviously more complex than JSON, and XML is...XML. All of that is to say, I'd rather write a JSON parser than any of the above. And JSON parsing is a minefield. http://seriot.ch/projects/parsing_json.html http://seriot.ch/projects/parsing_json.html I don't know of any notable S-expr based config languages, probably because they are so easy to parse, people just roll their own, leading to balkanization.
- deckard1 5y agoWindows INI format is going to be easier than any of those. You can parse it in a couple lines in a bash script. I personally find it silly to need more than that. YAML, JSON, etc. What are we even doing here, besides trying to make life more difficult? Are we doing configuration or are we doing plugins and calling it configuration? We'd all be better off if we just admitted we really want an extension language and went with embedded Lua or Scheme. With Dockerfile and others you have to run a separate lint program, assuming anyone even bothers doing that. At least with a proper language you would have built-in robustness. Most of these configuration formats/DSLs are half-assed and unnecessary anyway.
- slmjkdbtl 5y agoWhy use language designed for configuration? Is it the size concern or something else, cuz I think small langs like Lua make great config language.