Hacker News Reader

Comment by dw-im-here | Hacker News Reader

I'd rather put my hand in boiling water than develop a compiler in a dynamic weak typed language.

Please don't post unsubstantive and/or flamebait comments to HN. We don't want tedious flamewars here, including programming language flamewars that were tedious 20 years ago.

We detached this subthread from https://news.ycombinator.com/item?id=26604134.

My experience doing both in practice is that the type system helps you with things that aren't really a problem anyway (a compiler doesn't really have complex data structures and you don't often get these basic things wrong) and all but the most sophisticated type systems don't even begin to help you with things you really need help with - maintaining invariants.

Exactly. E.g. remove this line, and incorrect optimizations ensure, so the compiler fails halfway through recompiling itself:

http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/optimi...

The type is fine whether or not the line is present. It's all about that invariant.

None of the hair pulling I've experienced in compiler debugging had anything even remotely to do with type, which is something flushed out by testing.

Whenever doing anything, like an optimization test case, I put in print statements during development to see that it's being called, and what it's doing. You'd never add a new case into a compiler that you never tested. Just from the sheer psychology of it: too much work goes into it to then not bother running it. Plus the curiosity of seeing how often the case happens over a corpus of code.

Write a compiler in a strongly typed language, and then remove all the type annotations. This may come as a shock, but this is what a compiler (or any codebase) could look like when developed in a weakly typed language.

That doesn't work if you're using types for anything beyond correctness-checking. Type-driven dispatch, for example, which tends to be used heavily in big compiler and interpreter projects. And tagged unions (or algebraic datatypes), a natural fit for representing ASTs, become more unwieldy without type-directed features like pattern matching.

Sounds like a double standard and possibly moving the goalposts. There are strongly typed languages that don't have those features, and compiler codebases that don't use that kind of architecture. Do they get a pass or not?

I'm directly responding to the claim that you can "write a compiler in a strongly typed language, and then remove all the type annotations", and that's what compiler architecture looks like in a "weakly typed language". Compiler projects built in languages with richer typing can and do use it for purposes beyond correctness checking, and the idea that you can simply erase all the types and expect the code to work the same is a misconception.

You're pointing to cases to invalidate the claim as if that claim was supposed to be interpreted to be bracketed by a universal quantifier. It wasn't, and arguing in that way is not particularly insightful.

"You can write a compiler in a weakly typed language that resembles a compiler in a strongly typed language." Happy now?

The point, which you have ignored, is that there are strongly typed languages where the features you're relying on are not present. In fact, this is true of a bunch of the compilers that are among the most widely used in the world--ones that people are using to build projects written in C and C++ and things like the language support baked into IDEs for Java, C#, etc. So the relevant factor is not "strong vs. weak?" but rather those features (structural matching, etc) that you are relying on.

And let's be real, the original comment ("I'd rather put my hand in boiling water than develop a compiler in a dynamic weak typed language"; now flagged) was no more than a drive-by insult.

> "You can write a compiler in a weakly typed language that resembles a compiler in a strongly typed language." Happy now?

Sure, that's a better claim.

> The point, which you have ignored, is that there are strongly typed languages where the features you're relying on are not present.

There sure are! I don't think I was ever trying to say otherwise.

> In fact, this is true of a bunch of the compilers that are among the most widely used in the world--ones that people are using to build projects written in C and C++ and things like the language support baked into IDEs for Java, C#, etc.

Sorry, I'm having trouble parsing this. Are you referring to compilers of C/C++ here, or compilers written in those languages? The architectures of compilers I've worked with that were built in C++ were specifically on my mind when I wrote my comment.

> And let's be real, the original comment... was no more than a drive-by insult.

I think you're maybe reading too much into me here? I didn't write that comment you're referring to. I responded very narrowly to a claim in the light of a common misconception about how type systems factor into software architecture (namely, that they're don't do anything as long as your code is "correct"). I'm picking up a lot of hostility that I don't think I've earned.

> Type-driven dispatch

Smalltalk and everything since then would like a word with you.

> And tagged unions (or algebraic datatypes) [...] type-directed features like pattern matching.

Erlang and Prolog would like to have a chat, too.

I'm talking about language implementation, not features of languages implemented.

By type-driven dispatch do you mean dynamic dispatch on more than 1 parameter? Most statically typed languages do not have this and you have to write a bunch of boilerplate to get them to pretend that they do.

No, I'm referring to things like specialization, which you'll see used in any large language runtime built in C++, for example.

So "type driven dispatch" meant only dispatch that can be decided at compile time? Is it even called dispatch at that point?

Yeah, static dispatch.

> Write a compiler in a strongly typed language, and > then remove all the type annotations.

Help! That's what I did. I chose to write the compiler in OCaml, a language that's already ~30 years old by now. But I can not find any type anotations! What should I do? I'm stuck!

No, you're done.

> language that's already ~30 years old by now

Relevance?

ocaml is statically typed, it just uses type inference for 99% of cases. So your're wrong in this case, he got all the advantages from static typing. Errors ade found at compile time.

You're confusing strong and static typing (javascript has neither). In more sophisticated languages such as scala, C# or haskell you can let the compiler infer the types for you, and you can then ask your IDE which type that is. This way you don't need to type out all the boilerplate, you get to see what a functions signature is, and you get compiler errors rather than runtime errors.

Welcome to TypeScript.

Because you prefer to beaten by a stick after work, right? Helps your swollen hand.

Lisp is one of the best compiler implementation languages. Doing the same in C of C++ is about 3-20x more effort.

Extremely beyond the point, but it's not about Lisp, it's about automatic memory management, and to lesser extent lambdas and pattern matching.

There's nothing magical about Lisp that makes it super fit for compiler development.

Right. For compiler development you just need proper tree handling libs, proper generic types and proper macro abstractions. Static langs rarely have these features, besides ocaml and mercury, but most dynamic langs have it. Hence parents comment was being critized.

Javascript is of course torture for other reasons, but lisp, prolog, clojure et al do make sense. Lisp being the language with the most implemented compilers. Prolog probably being the easiest. Prolog compilers are usually much shorter and better than lisp ones. Super fit is only OCaml because it already comes with all the infrastructure, C parsers and such. In lisp you'd need to write 50 lines.

Reply on news.ycombinator.com