Live data from Hacker News

Let's compile like it's 1992 (2014)

fabiensanglard.net

41–50 of 84 posts

Re: Let's compile like it's 1992 (2014)

#41

Earlier quoted context omitted.

> The compiler is part of the IDE, not some external process that needs to start from a blank state for each file, needing to read the same files over and over... I suspect the difference is negligible in practice. In both cases, the files are likely to be cached in memory after they're read the first time, so you're not really reading it over and over.

Probably, but it can be a convenience to make some small modifications to try out things without saving them. From a performance standpoint the win comes from not having the compiler start from a blank state for each file but keep the compiled objects in memory and only update the changed files. I suppose a modern reimplementation of that idea (that has more memory to spare, after all the official BC++5 requirements…

> Probably, but it can be a convenience to make some small modifications to try out things without saving them.

Yes, I remember it being very pleasant when borland C++ crashed after running your application, losing your unsaved work.

edit: that was on windows 95/98 time; so it is more likely that the application crashed the whole OS.

Re: Let's compile like it's 1992 (2014)

#42
post #5

No mention of how much time it took to compile? I don't know if my memory is faulty but I remember Turbo C++ to be much much faster than today's C++ compilers.

That is an understatement. That is a full build of my 3D engine - http://i.imgur.com/3ApRyuQ.png (C not C++ but the linked article is also about a C codebase) on my current computer (4770K i7) under Borland C++ 5.0. Partial builds (modify a file and run) are instant, which is basically why i'm using it for a lot of my C code (the code also compiles in other compilers, like OpenWatcom, GCC, Clang, Visual Studio, Digit…

> The compiler is part of the IDE, not some external process that needs to start from a blank state for each file

I'm pretty sure Borland used to separate out the IDE executables from the compilers and a couple of other tools tool. I don't have a copy to hand to prove this but I'm sure I used to occasionally invoke Turbo Pascal's compiler from the command line outside of the IDE (due to it being a separate .exe / .com) and I vaguely recall Turbo C++ having a similar design.

I also don't recall build times being that much faster then than they are now. But maybe that's more a symptom of myself compiling on budget hardware previously where as I can now afford better spec'ed dev machines (compared to the market average).

Re: Let's compile like it's 1992 (2014)

#44
Wow, that Borland IDE UI certainly brings back memories.

Turbo Pascal 6.0 (for DOS) was my first real exposure to programming (not counting the various BASICs and a short stint learning 6502 assembly) and led to my teenage self writing a bunch of "IGMs" for Legend of the Red Dragon [0], a BBS game. Unfortunately, just as I started teaching myself C, I scored a copy of Visual Basic 3.0 and it was all downhill from there.

It's really cool to see this game I played 20+ years ago and think about how technology has come. I can't imagine what the next 20 years will bring.

[0]: https://en.wikipedia.org/wiki/Legend_of_the_Red_Dragon

Re: Let's compile like it's 1992 (2014)

#45
post #42

Earlier quoted context omitted.

That is an understatement. That is a full build of my 3D engine - http://i.imgur.com/3ApRyuQ.png (C not C++ but the linked article is also about a C codebase) on my current computer (4770K i7) under Borland C++ 5.0. Partial builds (modify a file and run) are instant, which is basically why i'm using it for a lot of my C code (the code also compiles in other compilers, like OpenWatcom, GCC, Clang, Visual Studio, Digit…

> The compiler is part of the IDE, not some external process that needs to start from a blank state for each file I'm pretty sure Borland used to separate out the IDE executables from the compilers and a couple of other tools tool. I don't have a copy to hand to prove this but I'm sure I used to occasionally invoke Turbo Pascal's compiler from the command line outside of the IDE (due to it being a separate .exe / .co…

You are correct. You could fire off a build from inside the IDE or from the command line itself. I remember it quite well.

Re: Let's compile like it's 1992 (2014)

#46

There was something about the visceral nature of the tc environment and editor and toolset that just felt like you were very mentally close to the code you were writing. Perhaps something about the bare simplicity. I can't help but feel i've been chasing it ever since in emacs.

Recently I had to do something I always avoided since it was platform specific a huge unknown space to me - code something in C#.

It was one of the most pleasurable experiences with "programming" since those Pascal times, and gave that feeling of being close to the code. I attribute it to fast compiles, no need for context switching (due to superb autocompletion), and everything just working well inside the tool. Documentation was also very good, and the huge API you're exposed gives a feeling of power (like I felt as a teen with computers, that I could do so much).

(My recent experience was Python, C (embedded too), Golang, and JS in the browser.)

Re: Let's compile like it's 1992 (2014)

#48
post #11

Earlier quoted context omitted.

Used both. TP was a lot faster but TC was no slouch. A Few years ago I managed to copy an old DOS diskette onto DOS VM and compiled and run a space invaders game I wrote. TC said it compiled but just kept returning me to the IDE when it executed! I eventually tweeked the VM speed down by about 100 at which point I saw the very fast invaders move to the bottom in about 2 seconds and kill my defender!

> TP was a lot faster Not surprising. As far as I know, Pascal doesn't have anything remotely as hostile to efficient compilation as the C preprocessor (oh look, changing that one constant in a header file rendered your entire project out-of-date because the compiler can't prove that it doesn't make arbitrary memory layout and AST changes in every file that indirectly #includes it).

Absolutely. Basically any Wirth-based language is designed so it is possible to compile each unit in a single forward pass. With those languages he did that has proper module support, and with most non-Wirth extensions to languages like Pascal, they tend to use very well constrained formats to cleanly delineate the type information and function signatures that is exported to retain that.

Wirth-style compilers also often don't even build an AST. Wirths own compilers called functions in the code generator module directly from the parser. Which again was something he could easily do because the languages were designed for single pass compilation.

Re: Let's compile like it's 1992 (2014)

#49
post #46

There was something about the visceral nature of the tc environment and editor and toolset that just felt like you were very mentally close to the code you were writing. Perhaps something about the bare simplicity. I can't help but feel i've been chasing it ever since in emacs.

Recently I had to do something I always avoided since it was platform specific a huge unknown space to me - code something in C#. It was one of the most pleasurable experiences with "programming" since those Pascal times, and gave that feeling of being close to the code. I attribute it to fast compiles, no need for context switching (due to superb autocompletion), and everything just working well inside the tool. Doc…

> Documentation was also very good, and the huge API you're exposed gives a feeling of power (like I felt as a teen with computers, that I could do so much).

That’s the reason why C#, or the language it was copied from (Java) are still popular when performance doesn’t have to be 100% perfect. Easy to use, very well documented and powerful, and reasonably fast.

Re: Let's compile like it's 1992 (2014)

#50

Wow, that Borland IDE UI certainly brings back memories. Turbo Pascal 6.0 (for DOS) was my first real exposure to programming (not counting the various BASICs and a short stint learning 6502 assembly) and led to my teenage self writing a bunch of "IGMs" for Legend of the Red Dragon [0], a BBS game. Unfortunately, just as I started teaching myself C, I scored a copy of Visual Basic 3.0 and it was all downhill from the…

Visual Basic paid my bills for quite some time. Funny I had to get smacked on the head a couple times (with Dataflex, VB, Python/Zope) to realise what @paulg articulates so well in "Beating the Averages".
Post reply on HN