10 ms·

THINK C was the straight successor of Lightspeed C, and I came from there, and before that from Turbo/TML Pascal on the IIgs. Whatever people will say, I still

THINK C was the straight successor of Lightspeed C, and I came from there, and before that from Turbo/TML Pascal on the IIgs. Whatever people will say, I still miss these "one pass" compilers, they were amazing and peaked with CodeWarrior, the best development suite, ever, in my nearly 40 years experience. Nowadays we see autoshit "configure" stuff and compilers like gcc (some) or clang (oh my frigging GOD!!) trawl their way slowly and painfully thru the most simple projects without even support for plain basic stuff like automatic precompiled headers. Wow look, we've NEARLY got Link Time Optimization working (took decades), in 2020 whoohoo, I'm so delighted. I could compile hundred of thousands of lines of light C++ or (better) plain C 25 years ago on a much, MUCH slower machine, with an simple editor that used the compiler lexer output so you had highlighting, real indexing it was 'just there' and always right, and always blinding fast. I'm pretty sure we are way worse than we were 20 years ago for tooling. I'm sure some people will disagree, these people haven't seen CodeWarrior chew thru hundreds and hundreds of files in seconds.

setpatchaddress 7y ago
I'll do you one better and say that CodeWarrior 1.x was the high water mark. 2.0 and later were slower. Xcode is not bad now, though, and I think I'd miss the extremely robust autocomplete.
- mevdev 7y ago
  Which 1.0 though?! They hit 1.0 a few times.
destitude 7y ago
My CodeWarrior T-shirt looks pretty ratty now.. Think Pascal was just as amazing.
bluedino 7y ago
We had Think C about ten years past it's time on the Mac LC in school. I would have taken Visual C++ that I had at home over that, any day. Heck, Turbo C for DOS would have been more productive.
kohtatsu 7y ago
I feel like if Terry Davis could have maintained a bit more of a grip on reality, he would have picked up the combined torch of Wozniak and Jobs. Rest in peace. Edit: not that TempleOS isn't beautiful, and I'm glad it exists and believe he achieved what he set out to do. I was just selfishly musing that if he hadn't lost his mind the way he did, maybe he would his ideas would have been adopted more in the mainstream. I'm also glad TempleOS exists in its incarnation, so it's conflicting.
- mhd 7y ago
  Have a look at Oberon or SmallTalk. Being sane doesn't really help all that much.
- bmn__ 7y ago
  https://www.youtube.com/watch?v=DFab1dN9GXs https://www.youtube.com/watch?v=DFab1dN9GXs
- pjc50 7y ago
  If he hadn't been completely mad he'd never have attempted it in the first place.
mntmoss 7y ago
I think what happened is that the developers that figuratively jumped up and down screaming about compile times all shifted towards interpreted languages. JS has been able to do roughly what C did in the 1990's, in terms of raw performance, for some time now. The folks that need typechecking can pick up Typescript or Haxe or whatever else is attractive. It's the bottom of the stack that really suffers - all the folks that want to work on stuff touching I/O and low level resources directly - and that is hardest to justify investing in. Unix and its baggage remain "untouchable", as these things go, and there are only some hints of promising developments otherwise.
- Koshkin 7y ago
  > JS has been able to do roughly what C did in the 1990's Basically, what you are saying is that JS slows modern computers down to the speed comparable to 90's computers.
  - sigzero 7y ago
    True story.
  - lioeters 7y ago
    I laughed, but really, the V8 JavaScript engine has come leaps and bounds in terms of performance. I recall a benchmark that found JS about 25% slower than C++, but 20% faster than Java. (citation needed)
    - hackingthenews 7y ago
      That really depends on what was benchmarked, so much so that dropping random benchmark results is meaningless. A benchmark like this [1] (showing c++ < js < java) is absolutely useless as the person writing it has no idea what they are doing, e.g. using vector in java. Looking at most benchmarks java beats js more often than not, but they are often neck in neck.[2] C++ always beats both, often by a huge margin (when written well).[3] [1] https://www.linkedin.com/pulse/algorithmic-performance-comparison-c-javascript-java-malyshev https://www.linkedin.com/pulse/algorithmic-performance-compa... [2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [3] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Hello71 7y ago
this deliberately ignores the new features we've gotten in the meantime. gcc is slow when you turn on all the optimizations. when computers were run by SysOps and every program needed to be recompiled from scratch for each slightly-different machine, it wasn't worth making the compiler ten times slower to make the program five percent faster. today, when browsers are compiled once and then run by millions of users for billions of hours a day, the tradeoff is different. sure, autoconf is bad, particularly today when it's used completely wrong, but is it really worse than when programs had to be completely manually ported between different Unix versions, in a day when "package manager" had yet to be a twinkle in anybody's eye? is everything great now? no, of course not. but you're grasping at the completely wrong straws here.
- buserror 7y ago
  It's still slow on -O0, it's slow because it doesn't approach the problem of compiling a complete program the right way, like these old compilers did. The fact that everything is a file, the fact that every single header needs to /searched for/ then /compiled/ millions of times, and optimized later on, without context; that is the problem. I wrote applications that were shipped on millions of computers in the 90s and I didn't have to make hard choices for building, the debug version were quicker to build sure, but the Release versions weren't a chore to make, and I was often building PPC/68k/debug/release in one go. Also, this is a ridiculous defence of autoshit stuff. It hasn't been needed for well over 20 years, it's only purpose is self propagation where "oh I need autoconf blah because otherwise I can't build everywhere" where there is so much standardisation these days that there are MOSTLY TWO choices for nix systems. Not only that but it fails* all the time, on embedded for example; it doesn't 'save' and give you portability, it just gives you a false assurance that you are doing 'the right thing' by using it, while it's broken is many other ways. More often than not, you can replace all that garbage with a 1/2 page Makefile. Who the hell needs to check wether the compiler /works/ or strdup /exists/ and all that idiocy. Or add dependencies for stuff while 'pkg-config' exists anyway. Who the hell actually /needs/ 'libtool' when there's about (perhaps) 3 ways of making a shared library on a unix system? And who the hell want or have the time to go and debug some stupid arcane 'm4' file to fix the weird problems that comes up? Disclaimer: I build embedded distros for fun and profit, I deal with that stuff /all the time/ and most of my 'compile time' for distros is not even spent actually 'compiling' stuff, it's spent in the 'configure' stage, and 90% of my time fixing portability problem isn't in the code, it's in the autoshit stuff that somehow breaks in some new, interesting way.
perl4ever 7y ago
I thought THINK Pascal was better than THINK C.
kristianp 7y ago
People aren't willing to pay for compilers any more, hence you get gcc, which isn't built for the convenience of the user, but for standards compliance and performance of its output.
- pjmlp 7y ago
  Hence why those of us that are willing to pay get Visual Studio, Qt Creator, C++ Builder,... instead of gcc.
  - badsectoracula 7y ago
    The compilers in these aren't really any better compared to GCC though.
    - pjmlp 7y ago
      They surely are, because the overall development experience is much more than the produced executable.
      - badsectoracula 7y ago
        I refer to that overall development experience too, they aren't any easier to use (Qt Creator and C++ Builder use Clang which is basically as easy as GCC) nor any faster and AFAIK VC++ compiler messages aren't even as good as those in GCC and Clang. Note that i refer to the compilers specifically, but even the IDEs you mentioned aren't that great. Visual C++ has went mostly downhill since VC6, becoming slower and even removing features (e.g. last time i tried it i couldn't use a bitmap font) or obfuscating them (installing a library "system-wide" is trivial in older versions of VS, but after 2008 or 2010 i think that feature was removed). C++ Builder's UI/IDE also went downhill after they got rid of the Delphi 7 interface and tried to become Eclipse and it also has became too unstable and slow. It does have a few niceties (i like that when you save your project it automatically updates the header file includes at the top), but nothing that makes it worth the negatives (though TBH i haven't spent much time with it because i refuse to rely on anything with DRM so i might be missing some gem covered under that bloat). Qt Creator is neat, but i could never get used to its interface (also it is free, so i'm not sure why you included it in a list of paid products). Also IMO all the above do not hold a candle to the older Borland C++ Builder when it came to development experience. I do not think there is any C++ development environment that comes close nor i think it is possible to make one by stitching together a frankenstein of a product out of otherwise independent bits and pieces that are oblivious about each other (in other words anyone who thinks that something "based on" Clang or GCC or whatever, stitched together with LLDB, GDB or whatever and some GUI framework thrown in - usually Qt - would fit the bill is totally missing the point).
tgv 7y ago
Ah, good memories. CodeWarrior was great. Switching to XCode was a bit of a disappointment.
sproketboy 7y ago
C# is an 18 pass compiler because of partial types and xml compiling etc.

setpatchaddress 7y ago

I'll do you one better and say that CodeWarrior 1.x was the high water mark. 2.0 and later were slower. Xcode is not bad now, though, and I think I'd miss the extremely robust autocomplete.

mevdev 7y ago
Which 1.0 though?! They hit 1.0 a few times.

destitude 7y ago

My CodeWarrior T-shirt looks pretty ratty now.. Think Pascal was just as amazing.

bluedino 7y ago

We had Think C about ten years past it's time on the Mac LC in school. I would have taken Visual C++ that I had at home over that, any day. Heck, Turbo C for DOS would have been more productive.

kohtatsu 7y ago

I feel like if Terry Davis could have maintained a bit more of a grip on reality, he would have picked up the combined torch of Wozniak and Jobs. Rest in peace. Edit: not that TempleOS isn't beautiful, and I'm glad it exists and believe he achieved what he set out to do. I was just selfishly musing that if he hadn't lost his mind the way he did, maybe he would his ideas would have been adopted more in the mainstream. I'm also glad TempleOS exists in its incarnation, so it's conflicting.

mhd 7y ago
Have a look at Oberon or SmallTalk. Being sane doesn't really help all that much.
bmn__ 7y ago
https://www.youtube.com/watch?v=DFab1dN9GXs https://www.youtube.com/watch?v=DFab1dN9GXs
pjc50 7y ago
If he hadn't been completely mad he'd never have attempted it in the first place.

mntmoss 7y ago

I think what happened is that the developers that figuratively jumped up and down screaming about compile times all shifted towards interpreted languages. JS has been able to do roughly what C did in the 1990's, in terms of raw performance, for some time now. The folks that need typechecking can pick up Typescript or Haxe or whatever else is attractive. It's the bottom of the stack that really suffers - all the folks that want to work on stuff touching I/O and low level resources directly - and that is hardest to justify investing in. Unix and its baggage remain "untouchable", as these things go, and there are only some hints of promising developments otherwise.

Koshkin 7y ago
> JS has been able to do roughly what C did in the 1990's Basically, what you are saying is that JS slows modern computers down to the speed comparable to 90's computers.
- sigzero 7y ago
  True story.
- lioeters 7y ago
  I laughed, but really, the V8 JavaScript engine has come leaps and bounds in terms of performance. I recall a benchmark that found JS about 25% slower than C++, but 20% faster than Java. (citation needed)
  - hackingthenews 7y ago
    That really depends on what was benchmarked, so much so that dropping random benchmark results is meaningless. A benchmark like this [1] (showing c++ < js < java) is absolutely useless as the person writing it has no idea what they are doing, e.g. using vector in java. Looking at most benchmarks java beats js more often than not, but they are often neck in neck.[2] C++ always beats both, often by a huge margin (when written well).[3] [1] https://www.linkedin.com/pulse/algorithmic-performance-comparison-c-javascript-java-malyshev https://www.linkedin.com/pulse/algorithmic-performance-compa... [2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [3] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Hello71 7y ago

this deliberately ignores the new features we've gotten in the meantime. gcc is slow when you turn on all the optimizations. when computers were run by SysOps and every program needed to be recompiled from scratch for each slightly-different machine, it wasn't worth making the compiler ten times slower to make the program five percent faster. today, when browsers are compiled once and then run by millions of users for billions of hours a day, the tradeoff is different. sure, autoconf is bad, particularly today when it's used completely wrong, but is it really worse than when programs had to be completely manually ported between different Unix versions, in a day when "package manager" had yet to be a twinkle in anybody's eye? is everything great now? no, of course not. but you're grasping at the completely wrong straws here.

buserror 7y ago
It's still slow on -O0, it's slow because it doesn't approach the problem of compiling a complete program the right way, like these old compilers did. The fact that everything is a file, the fact that every single header needs to /searched for/ then /compiled/ millions of times, and optimized later on, without context; that is the problem. I wrote applications that were shipped on millions of computers in the 90s and I didn't have to make hard choices for building, the debug version were quicker to build sure, but the Release versions weren't a chore to make, and I was often building PPC/68k/debug/release in one go. Also, this is a ridiculous defence of autoshit stuff. It hasn't been needed for well over 20 years, it's only purpose is self propagation where "oh I need autoconf blah because otherwise I can't build everywhere" where there is so much standardisation these days that there are MOSTLY TWO choices for nix systems. Not only that but it fails* all the time, on embedded for example; it doesn't 'save' and give you portability, it just gives you a false assurance that you are doing 'the right thing' by using it, while it's broken is many other ways. More often than not, you can replace all that garbage with a 1/2 page Makefile. Who the hell needs to check wether the compiler /works/ or strdup /exists/ and all that idiocy. Or add dependencies for stuff while 'pkg-config' exists anyway. Who the hell actually /needs/ 'libtool' when there's about (perhaps) 3 ways of making a shared library on a unix system? And who the hell want or have the time to go and debug some stupid arcane 'm4' file to fix the weird problems that comes up? Disclaimer: I build embedded distros for fun and profit, I deal with that stuff /all the time/ and most of my 'compile time' for distros is not even spent actually 'compiling' stuff, it's spent in the 'configure' stage, and 90% of my time fixing portability problem isn't in the code, it's in the autoshit stuff that somehow breaks in some new, interesting way.

perl4ever 7y ago

I thought THINK Pascal was better than THINK C.

kristianp 7y ago

People aren't willing to pay for compilers any more, hence you get gcc, which isn't built for the convenience of the user, but for standards compliance and performance of its output.

pjmlp 7y ago
Hence why those of us that are willing to pay get Visual Studio, Qt Creator, C++ Builder,... instead of gcc.
- badsectoracula 7y ago
  The compilers in these aren't really any better compared to GCC though.
  - pjmlp 7y ago
    They surely are, because the overall development experience is much more than the produced executable.
    - badsectoracula 7y ago
      I refer to that overall development experience too, they aren't any easier to use (Qt Creator and C++ Builder use Clang which is basically as easy as GCC) nor any faster and AFAIK VC++ compiler messages aren't even as good as those in GCC and Clang. Note that i refer to the compilers specifically, but even the IDEs you mentioned aren't that great. Visual C++ has went mostly downhill since VC6, becoming slower and even removing features (e.g. last time i tried it i couldn't use a bitmap font) or obfuscating them (installing a library "system-wide" is trivial in older versions of VS, but after 2008 or 2010 i think that feature was removed). C++ Builder's UI/IDE also went downhill after they got rid of the Delphi 7 interface and tried to become Eclipse and it also has became too unstable and slow. It does have a few niceties (i like that when you save your project it automatically updates the header file includes at the top), but nothing that makes it worth the negatives (though TBH i haven't spent much time with it because i refuse to rely on anything with DRM so i might be missing some gem covered under that bloat). Qt Creator is neat, but i could never get used to its interface (also it is free, so i'm not sure why you included it in a list of paid products). Also IMO all the above do not hold a candle to the older Borland C++ Builder when it came to development experience. I do not think there is any C++ development environment that comes close nor i think it is possible to make one by stitching together a frankenstein of a product out of otherwise independent bits and pieces that are oblivious about each other (in other words anyone who thinks that something "based on" Clang or GCC or whatever, stitched together with LLDB, GDB or whatever and some GUI framework thrown in - usually Qt - would fit the bill is totally missing the point).

tgv 7y ago

Ah, good memories. CodeWarrior was great. Switching to XCode was a bit of a disappointment.

sproketboy 7y ago

C# is an 18 pass compiler because of partial types and xml compiling etc.