>>The compiler is your friend, Dragan, not your enemy. It tries to help you
>
>I've been through this same discussion on strongly typed vs untyped back when 200MHz was fast. Turbo Pascal compiler was blazingly fast, because it was a single-pass compiler. Before compiling code, it had to know everything about any possible variables that may pop up in it, so you had to strongly type them. And it would compile a nice chunk of code in a second on a 2MHz Z80. Back then interpreted code was deemed to be slow, just because some flavors of interpreted Basic were slow. However, difference between speed of P-code and full compile into machine code was negligible; P-code would call runtime routines which can be, and often are, optimized. Fox was actually the strongest argument in favor of P-code+runtime. Somehow, VB guys thought of themselves as "compiled", while distributing runtimes everywhere :). And, nowadays, CLR is runtime too.

Just a side note about Borland Turbo Pascal:

I, too, ran Turbo Pascal on a Z80 and CP/M. As I recall it, the big wins had little to do with it being a single-pass compiler (if indeed it was, which I'm not sure of), but more that:

- primarily, it was SMALL. Everything fit comfortably on a 240K 8" floppy and ran comfortably in 64K RAM without too much floppy I/O. In those days, small == fast.

- it compiled and linked in a single operation

In those days I had a buddy with a similar system. Somehow he got hold of a copy of the Microsoft Pascal Compiler for CP/M. This must have been extraordinarily rare, and was probably never released because I've never heard tell of another copy. But, I watched him compile programs with it often enough that I know it was real ;)

Anyways, it was a horror show to compile anything with the MS compiler. It was on multiple floppies and required a lot of floppy swapping. And that was just for the compile step; then there were multiple swaps for the link step too. He was quite used to doing this and thought it was completely normal, which it was, prior to Turbo Pascal.

I bought Turbo Pascal mail-order, sight-unseen from Borland. My buddy dismissed it as a toy. That is, until the first time he saw me compile one of my programs with it. One of those shocked-in-a-good-way experiences that were not uncommon in those early days, and which are few and far between today.

I do recall some people saying Turbo Pascal was fast because it was a "single-pass compiler". When discussing it with them, what they meant for that particular product was that it compiled and linked in a single step, and it didn't require multiple floppy swaps i.e. single step, and one pass through a single floppy diskette.

A single-pass compiler is not necessarily a panacea for speed, either - although it could well have been back in the primitive days of Turbo Pascal and helped contribute to its win. One of the first significant FoxBASE+ jobs I had was maintaining a parser that translated streams of scanned barcodes into a hierarchy of "transactions". The original author was quite skilled and had implemented it as a single-pass parser. As is often the case, it was so successful he was asked to enhance it, which he did, but which made it rapidly turn into pasta. Bugs started to creep in and it was so complex even he lost the gist; he eventually declined to work on it any further.

I was asked to address the bugs and make some enhancements. After staring at the code for a few days, I could see where some bugs could be creeping in, but to reliably fix them, and even generate test cases for the fixes was pretty unpalatable. Basically, the code had a high WTF/min count, which was only going to get worse.

The client agreed to bite the bullet, and I rewrote the parser as a 2-pass parser. The code was a fraction of the size, ran several times faster and was fairly easy to enhance.

It wasn't that the original code was bad - for that particular application, forcing the code into the single-pass paradigm meant it had to be complex. I couldn't see how to make it simpler and easier to maintain; even if I'd rewritten it all as my own attempt at a single-pass parser it probably would have ended up just as ugly. It's just that for this particular application, a 2-pass parser was the right choice - the smaller code size, increased speed and enhanced maintainability were just side benefits, although arguably the result/proof of the 2-pass architecture being the right choice.