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.

> 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.

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)

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-compa...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[3] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Thank you for setting the record straight(er), I appreciated looking at some real benchmarks.

The one for k-nucleotide looked like it pushed JS the hardest for some reason. Interesting to compare how different languages fare:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

In this one, Java was 2.3x slower than C++, and Node.js 6.6x.

Oof, I concede. "JS has been able to do roughly what C did in the 1990's."

True story.

Nope, we moved into Java and .NET stacks.

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

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.

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.

yes! Even in the 90's you could take care of the common cases with a few different flags. I had C apps that built on various Linux distros, FreeBSD, Digital Unix, SunOS 4.x, and Solaris with hardly any changes other than a couple ifdefs. Sure, if you compile your program on a Sequent running DYNIX, circa 1988, you might hit a few snags.

I build embedded software for profit only and I can say with certainty the 98% of all computers out there are not desktops and do not use desktop operating systems. For those systems, the autotools, modern optimizing compilers, and modern tooling like distributed ccache are a godsend. Of course, back in the 1990s similar software was fast to build because your cross-assembler didn't have to worry about on-chip cache or superscalar architectures, but ye gods the code PTSD flashbacks begin.

I run NetBSD on my Mac Quadra 950 as well as MacOS. I usually give up trying to run autoconf on it after a few days.

Compared with Visual C++ it is definitely slow.

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.

I have mixed feelings on this, it did feel like there was a broader choice of compilers back then but on the other side not being able to afford them in my youth was frustrating.

I was just thinking about how I spent hundreds of dollars for Zortech C++ and Borland C++ back in the 90s and was shocked when IBM included a C/C++ compiler for FREE with OS/2 and it even included a visual UI builder tool.

Hence why those of us that are willing to pay get Visual Studio, Qt Creator, C++ Builder,... instead of gcc.

Visual Studio is C++ orientated and the C support is somewhat behind. https://github.com/MicrosoftDocs/cpp-docs/issues/407 (admittedly, 2018)

Realistically the paying subset of users of a language is always going to be a small number of people.

It is called Visual C++ after all.

I am more than happy if on Windows, C gets reduced to the subset required by ISO C++.

Time to move on, C was already outdated in the mid-90, versus C++ARM, Modula-2 and Object Pascal.

Microsoft Security center is quite clear on the damage it has brought to the industry.

> Time to move on, C was already outdated in the mid-90,

Objectively false, given the consistent popularity of C.

Plus, of course, the bad things about C are also bad about C++, in that C++ is more similar to C than different from it.

Web browsers made JavaScript unavoidable, UNIX clones did the same for C.

C's copy paste compatibility in C++ is the Trojan horse that ended up being its security Achilles heel.

However even with that, the C++ community and ISO C++ actually care to improve the language security story.

The same cannot be told for ISO C.

Actually even Microsoft does more for it with its Checked C research and SAL security annotations.

I think that used to apply. It's not so much a thing since C++11.

The compilers in these aren't really any better compared to GCC though.

They surely are, because the overall development experience is much more than the produced executable.

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).

I guess we have to disagree then.

I included QtCreator, because for the full experience you need the commercial Qt offerings as well.

Windows now has a C++ package manager (vcpkg), so you can install libraries as you want.

Actually Clang provides the necessary IDE hooks that GCC doesn't.

I also consider the UI designers (UWP C++/CX is not that bad), graphical debuggers, pre-compiled headers database, incremental compiler, incremental linker, PGO integration, and being able to drive them without memorizing a ton of switches, part of the whole experience.

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.

Which 1.0 though?! They hit 1.0 a few times.

I thought THINK Pascal was better than THINK C.

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.

Have a look at Oberon or SmallTalk. Being sane doesn't really help all that much.

If he hadn't been completely mad he'd never have attempted it in the first place.

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

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.