Hacker News new | ask | show | jobs
by tovej 1908 days ago
Compiler compilers are great, I love writing DSLs for my projects. I usually use yacc/lex, or write my own compiler (typically in go these days).

However (and this is just me talking), I don't see the point in a javascript-based compiler. Surely any file format/DSL/programming language you write will be parsed server-side?

10 comments

> I don't see the point in a javascript-based compiler

JavaScript is a full programming language. Why wouldn't it be a fine choice to write a compiler in? People have a funny idea that compilers are more complex software or are somehow something low-level? In reality they're conceptually simple - as long as your language lets you write a function from one array of bytes to another array of bytes, then you can write a compiler in it. And for practicalities beyond that you just need basic records or objects or some other kind of structure, and you can have a pleasant experience writing a compiler.

> Surely any file format/DSL/programming language you write will be parsed server-side?

JavaScript can be used user-side, or anywhere else. It's just a regular programming language.

> I don't see the point in a javascript-based compiler

Typescript, sass, jsx... There are a lot of languages running on top of js. Or you might want to do colorizing, autoformating on input in the browser?

Along with all that, there's as mentioned nodejs, deno for running server side.

But at any rate - lots of front-end problems involve various kinds of parsing/validation and transformation (eg: processing.js).

> Why wouldn't it be a fine choice to write a compiler in?

Javascript doesn't seem suited to compiler construction because it lacks lots of features that make compiler construction pleasant (e.g. strong rich types, algebraic data types, etc.)

It might be "fine" but it's not "good".

I interned with the PI behind Ohm (Alex Warth) and one of his reasons for using the browser was simple:

“If I send someone an executable, they will never download it. If I send them a URL, they have no excuse.”

We are talking about a compiler here.

If someone interested in a compiler doesn't download it, it's not a excuse, it's a filter. Or a warning sign.

You know all those jokes that people like Linus make about Real Programmers—the ones who have hair on their chests, etc—you know those are all jokes, right? Jokes in the laughing-at-them sort of way, the way Colbert did it—not something that you're supposed to unironically buy into.

> If someone interested in a compiler doesn't download it, it's not a excuse, it's a filter. Or a warning sign.

You're so invested in gatekeeping that you're confusing the point of research with technofetishism.

Here's what Joe Armstrong had to say in "The Mess We're In":

"I downloaded this program, and I followed the instructions, and it said I didn't have grunt installed! [...Then] I installed grunt, and it said grunt was installed, and then I ran the script that was gonna make my slides... and it said 'Unable to find local grunt'."

Looks like someone needs to go dig up Joe and let him know that the real problem is that there was a mistake in letting him get past the point where he was supposed to be filtered out.

> doesn't download it, it's not a excuse, it's a filter

If it's a decently large project, sure. But if it's a small project with only a couple contributors who I've never heard of? There's the potential for that to be hiding malicious code. Plus the potential complexity of getting a project that's only ever been built on (say) 2 computers to successfully compile and run on my system. Plus figuring out whatever build system and weird flags they happen to use. And potentially wrangling a bunch of dependencies.

All that just to take a quick look at a language that might not actually be of interest to me in the end. The browser offers huge benefits here - follow a link and play around in a text box. It just works. (This is also why I use Godbolt - I don't want to bother with a Windows VM or wrangle ten different versions of Clang and GCC myself.)

Spoken like someone who has never taught real students!
I mean it's JavaScript, I don't think it's intended for you to write C compilers in it - but for compile-to-JS languages, it's a real asset to be able to run it in the browser, although more and more that can be done with WebAssembly as well. However, look at the project listed as using it - it may not even be for web languages, but just projects that need to parse something.
(also just me talking -- here are some potential counterpoints)

The choice of language often matters a lot less than how familiar you are with it (and its ecosystem(s)). I think it's totally reasonable to want to use JS for a compiler in, e.g., a Node project if for no other reason than to not have to learn too many extra things at once to be productive with the new tool.

I also don't think it's fair to assume everything will be parsed, tokenized, etc server-side. Even assuming that data originates server-side (since if it didn't you very well might have a compelling case for handling it client-side if for no other reason than latency), it's moderately popular nowadays to serve a basically static site describing a bunch of dynamic things for the frontend to do. Doing so can make it easier/cheaper to hit any given SLA at the cost of making your site unusable for underpowered clients and pushing those costs to your users, and that tradeoff isn't suitable everywhere, but it does exist.

It's interesting that you seem to implicitly assume the only reason somebody would choose JS is that they're writing frontend code. It's personally not my first choice for most things, but it's not too hard to imagine that some aspect of JS (e.g., npm) might make it a top contender for a particular project despite its other flaws and tradeoffs.

This makes me feel really good. I’m working on my first DSL and I’m writing it in JS. I really don’t know what I’m doing, and it felt like JS wasn’t as good a choice as a more “serious” language like C++.

But I’m standing my ground because I’m not even writing a proper “compiler” - in my case, the output is JSON. So it just kinda feels like it makes sense to stick with JS.

Write software, grow from your experience and - sometimes - mistakes. Worrying and getting caught in analysis paralysis is the best way to stagnate.

Tons of brilliant people and huge companies have made software in X and found out it would have been better in Y. There's always tomorrow, as long as you learned today.

If your ecosystem is JS, having a JS based compiler is pretty convenient. As long as it's just "slower by some constant", rather than by a runtime order, the fact that it's not as fast as yacc/bison etc. is pretty much irrelevant, so being able to keep everything JS is quite powerful for people new to the idea having started their programming career using JS, as well as seasoned devs working in large JS codebases.

(and you can always decide that you need more speed - if you have a grammar defined, it's almost trivial to feed it to some other parser-generator)

>Surely any file format/DSL/programming language you write will be parsed server-side?

Well, Javascript has been used for over a decade heavily on the server side, with Node, WASM and other projects.

And as far as raw speed goes, something like v8 smokes all scripting languages bar maybe LuaJit.

So, there's that...

There’s definitely a use for js based parsing for tooling that runs in the browser (autocomplete, documentation browsing etc). Integration with the Monaco editor is a common use case.
There's a great deal of value to making programming environments available in a browser, especially in the context of creative coding and education. I have built and used many such tools which are purely client-side.

There is a world of difference in accessibility between a tool that requires installation and a tool that you can use by following a hyperlink.

> I don't see the point in a javascript-based compiler

My CC is Javascript based (well it was initially, then TypeScript, now a lot of it is written in itself).

99% of the time I use the actual languages I make in it server side (nodejs), but I am able to develop the languages in my browser using https://jtree.treenotation.org/designer/. It's super easy and fun (at least for me, UX sucks for most people at the moment). There's something somewhat magical about being able to tweak a language from my iPhone and then send the new lang to someone via text. (Warning: Designer is still hard to use and a big refresh is overdue).

Wait, what do you use treenotation for? What are the languages for? I think I'm just a little surprised someone's using treenotation other than to play with it.
Oh yeah I use it everywhere. The ideas are live on prod on a number of sites.

My recent fun public focus now is to power Scroll, (https://scroll.publicdomaincompany.com/). "Scrolldown" now powers my blog (an example post: https://github.com/breck7/breckyunits.com/blob/main/insist-o...). I think from what I'm seeing so far Scrolldown may be one of the first Tree Lang breakouts. Simple but powerful from extensibility.

TreeBase is used extensively at a few moderately successful websites. I think Tree Notation (or 2D langs generally) will be used OOMs more in this domain. It integrates so incredibly seamlessly with Git.

At Our World in Data Tree Notation is used for the researchers to build interactive data visualizations (https://www.youtube.com/watch?v=vn2aJA5ANUc&t=145s). That one uses it's own implementation called "GridLang" because I didn't want to depend on jtree, which is a bit too R&D for a site with that kind of traffic. The 2D lang/Tree Notation ideas are so simple that it's easy to roll your own code and you don't have to use "jtree". I view the "jtree" project in a way as just an experiment to confirm that yes, you can do anything/everything without any visible syntax characters. Space is all you need.

On the contracting side I'm helping a crypto group with a shockingly ambitious 2-D crypto.

In that case, way I ask why you are not a Racket user? Sounds like it'll save you a ton of time and keep your implementations high level.
A ton of front end templating languages/frameworks. They involve compilers to different degrees, don't they?