Hacker News Reader

Comment by norir | Hacker News Reader

> Also, writing a compiler in its own language, while simultaneously developing the language, tends to result in a language that is good for writing compilers, but that was not the kind of language we were after.

I have seen this sentiment a few times recently. First of all, it raises the question is a language that is not compiled in itself a bad language for writing compilers? My intuition is usually yes. Secondly, the implication is that a good language for compilers will not be good for other applications. I really don't understand this because a compiler will use most of the same building blocks that are used for other programs.

I would really like more context into what the author is trying to say though.

View on HN

For what it's worth, Dart's intended domain (client UI apps) is much farther from compilers than Go's intended domain (servers and "systems programming") but we write almost all of our tools and compilers in Dart.

Dart isn't always the best language for compilers (we have a lot of Visitor patterns floating around, which are always tedious), but it's plenty good enough and it keeps the whole team working in our own language eight hours a day, which I think is invaluable.

Also, it means that when we make our implementations or compilers faster, we get a compounding effect because our tools get faster too.

Dart evolved into a nice language with null-safety and exhaustive patterns.

Hopefully in Go 3, we could see these features added as well.

The ideal set of building blocks depends on the problem.

If the building blocks make it easy to write concurrent code (Go, Erlang), then it becomes easier to write a server. If they make it easy to represent "A or B or C" and pattern match on trees (ML-like languages), then it becomes easier to write a compiler.

Add to that: if you are trying to make an easy to onboard language, you want to look at how beginners use it, not experts. Someone writing a compiler for language X is certainly an expert in X.

To me, being able to represent "A or B or C" is a bare minimum of a type system.

Writing compilers is mostly aided by having a robust type-system and elegant tooling for parsers and AST transformation and so on.

Writing a compiler requires computer science knowledge, requires thought.

Haskell I think is a perfect example. It is a language that is well suited for writing compilers, but also very well suited for building services, backend applications, really anything if your developers are of average intelligence.

Go, however, wants to optimize for developers who think a for loop is easier to understand than an applicative functor, who think that generics are unnecessarily complex.

If you're trying to build a language for "the lowest common denominator, the average googler", that's the opposite of building a language for compiler writers, so in that case building a language that can represent such a hard CS problem well is counter productive.

Reply on news.ycombinator.com