[pwdisswordfish6]

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.

[rixed]

> 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!

[pwdisswordfish6]

No, you're done.

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

Relevance?

[TsiCClawOfLight]

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.

[dw-im-here]

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.

[emteycz]

Welcome to TypeScript.

[mintplant]

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.

[klibertp]

> 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.

[mintplant]

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

[pwdisswordfish6]

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?

[mintplant]

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.

[pwdisswordfish6]

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.

[mintplant]

> "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.

[anonymoushn]

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.

[mintplant]

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

[anonymoushn]

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

[mintplant]

Yeah, static dispatch.