> Secondly, if you get time, could you give an outline of a roadmap of things I > should learn in an incremental manner to reach your level of knowledge and > proficiency.
Sorry, but you will not reach my level of knowledge by reading books. You need to experiment and learn from your mistakes. Lots of experiments. Lots of mistakes. > At least, what would be the basic areas in which I need to gain solid > understanding? Data structures? Algorithms? Computer Organisation? Math? > Assembly programming? Type theory? Functional programming? All of these don't hurt but it's easy to get lost in them. > I'm sure, if you were advising your younger self, you would have advised to > stay away from learning certain things that are actually irrelevant but > taught in the area of creating programming languages. Irrelevant: Lexer and parser generators. Irrelevant: Code generator generators like Burg. Harmful: OOP for compiler plus the visitor pattern. Harmful: Haskell with its obsession of making mutable state inconvenient to use. Harmful: Erlang for writing a compiler. Harmful: Anything that uses dynamic typing. Harmful: C. If you want to learn about "low level", learn an assembler. It doesn't distract with historical baggage like "C's 50 ways to offer undefined behavior" or "C's flawed operator precedence rules" or "C's header files and preprocessor". > Then, do I need to gain professional systems programming experience before I > embark on a compiler engineer journey? I wrote preprocessors and interpreters for domain specific languages before I wrote compilers and can recommend it. A preprocessor is much simpler than a compiler and can be inherently useful on its own. > And do I need professional experience in C or C++ or Assembly programming? I > was primarily a web developer for most of my short IT career having decent > exposure to JavaScript (and now a bit of Python). I have also learnt the very > basics of C. C and C++ are more harmful than useful and you only need assembler if you want to write a compiler that produces assembler. > Do ADTs, pattern matching etc. make a world of a difference (I've been seeing > this a lot on forums)? Is Nim a suitable good language to use as a > bootstrapping language for a compiler or write an interpreter? Many in the > Programming Languages subreddit does not suggest Nim as a suitable option > (they cite the lack of sum types and patter matching in Nim) and instead > suggest Haskell, OCaml, or Rust. ADTs and pattern matching are awesome so use a Nim macro library that offers them. Yes, use Nim to write a compiler, it works. Forget about OCaml, Haskell and Rust. If you want an alternative to Nim that offers sum types and pattern matching, use F#. Has the much nicer syntax.
