Bakul Shah wrote:In practice you can get away not knowing a lot of the theory but the parsing theory is not exactly simple. Check out the "Dragon book" on compilers!
I am very familuar with the 'Dragon Book": Principles of Compiler Design
. Two things about your statement:
1) The dragon book presents the therory of parsing going to extremes and making it seem more dificult than it is.
2) The Dragon Book covers a lot more than just parsing.
Once again just because the dogma sais it is dificult does not meen it is.
Have you studied the Structure and Interpretation of Computer Programs) book? It uses Scheme and teaches you a whole lot -- more than virtually any other CS book.
No I can not say as I have. Though its title does not do it justice if it is as complete as you are implying.
Assembly languages are certainly simpler but the second part is not true in general. It has been decades since a single compiler for any high level language has been written entirely in assembly language (an exception may be Forth).
I would hope that most compilers are self compiling, written in the high level language that they work with.
OSes written in assembly languages are either toy ones or become impossible to maintain after a while.
This is a matter of debate. Assembly code can be as maintainable as any other language if not more so. I know many programmers that still work almost exclusively in assembly language (myself included), and maintain and update large projects that are written in assembly regularly. It gives us the opertunity to choose what trade offs we wish to make when we update our projects for a new generation of the CPU. RISC OS is still more than half written in Assembly language, and is still maintainable, and maintained 25 years later.
I do think that every programmer should know assembly language but that is to understand the cost of various high level language features + finding occasional compiler bugs + learning how to do low level optimization when nothing else will help.
What about writing good easily updatable complete projects?
Story time: When the open source BSD was very very young, I speeded up its ip checksumming by a factor of 5 by replacing its inner loop with a 3 line assembly code version -- using gcc's horrible inline syntax. A few years later, processors had gotten more complex and my "optimized" code turned out to be a pessimization compared to an all-C version that was more cache aware!
And you prefer to rely on the compiler being updated? Assembly language programmers do not relly on such things. We update our code and make the trade offs that we feel are apropriate (do we optimize for the next generation CPU at the cost of speed loss on the older generation, etc...).
And BSD is a poor example as it is designed to be completely independant of the underlying CPU and as such is written almost entirely in C.
And this is yet another problem with sticking with assembly code -- such projects don't evolve easily. In fact assembly code *hates* to evolve and even wonderful efforts like the Synthesis Kernel then get abandoned.
Most projects that assembly language programmers create evolve fast and continue to evolve. This is because well documented, correctly formatted Assembly is a lot easier to fallow than a HLL (or even mid level like C), easier to update, and unlimitted in what can be done.