Those both sound like specific instances of DRY?

We're still talking about *the 90's*, like Kristoph and Anon Coward were, right? Were you just trolling? The PowerPC-based Power Macintosh 6100 shipped in March of 1994.

According to Wikipedia (and a few other sites I googled), A/UX did not run on PowerPC-based Macs. It may have been promised but was never delivered.

No duh, but Intel's 486 shipped in 1989 and the Pentium shipped in 1993. So you're not comparing the right things.

From a hardware bang-for-buck perspective, it was. This ended up being a good thing when we resold some of our old equipment.

From a software perspective, it didn't start out that way (System 7 was much more pleasant for me to use than Windows 3.1), but NT 4.0 came out in 1996. A/UX only ran on some 68k-based Macs, which were getting long in the tooth by the late 90s.

I read that as "10-dimensional herpes". I'm pretty sure I need to get my eyes checked. Or maybe something else.

My apologies for somehow blanking about Ada and operator overloading! I don't like saying wrong things.
Looks like Ada does support it, even in Ada'83.

I don't currently use Rust or Ada, but I think Rust has enough original useful ideas and tradeoffs -- along with a corresponding need for a lack of baggage a la the "C -> C++" compatibility story -- that it was worth pursuing as a separate language.

I don't think the following necessarily disagrees with your post, but I'd like to elaborate on it.

I get the point that doing something "the C++ way" can be more verbose than "the C way", especially when one is writing a library. Whether it's the pimpl pattern, rule of 3 (now rule of 5), overloading every stupid arithmetic operator for a numeric class, defining const/non-const versions of a method, adding template sugar everywhere to your declarations if you're working on a template class, adding standard iterability to a class ... it all makes for some pretty stupid boilerplate.

That said, while life is more complex for the class implementor, the class user's life is much simpler. C coders shouldn't have to (poorly) reimplement a std::vector subset every time they need a dynamically-sized array of something, nor should they have to sacrifice RAII. Since a class is usually used more often than it is written, it's a net C++ win.

There are other corner cases (like printf() vs iostreams) where the C++ way looks more complex, but works with arbitrary types. I still resent needing to use io manipulators (don't forget to reset your state!) for stream operations when I am really just working with C types. I do understand there are libraries like Boost.Format that help with this; it irks me that they are not standard.

I used Ada circa 1997 for a DoD project.

Ada felt like industrial-strength Pascal. It was generally cool -- why *wouldn't* I want the compiler to range-check array index operations by default, at least for non-critical code paths? This could help me today, on *real problems*. Why *wouldn't* I want an enforced, specified order of initialization for global/static objects? I also strongly preferred the generics and exception syntax over their C++ equivalents. Ada's OS-agnostic task support was ahead of its time (hard for the language to support threads when the underlying OS doesn't).

Going back to C afterwards felt like returning to something ... primitive. But, I develop in C++ today.

Ada had historical issues and feature lags, some of which still plague it today, such as:
-- historically, no free compiler (today, there is FSF GNAT)

-- the object.method() - style syntax didn't show up until 2005; standardized bitwise operations didn't show up until 1995

-- small standard library, which in general has lagged behind even what C++ supports. Containers didn't appear until 2005. Also, AFAIK Ada still has no equivalent of say, C++'s Boost or Rust's crates.io (though there are at least some Ada projects and libraries on Github). Want to call epoll() directly on Linux? In C++ you can use it directly; in Rust you can find a wrapper, in Ada you need to roll your own (to be fair, Ada's C interface support is excellent). Want standardized smart pointers? Maybe in Ada2020. If you want to make Ada more popular, I think this general problem of "I have to write my own version of xyz" is the single most important thing you could tackle.

-- Some things are just relatively awkward to express in Ada, even beyond the normal verbosity of the language (some of which there are good reasons for). Here for example is a comparative look at closures. As another example, C++'s operator overloading is ripe for abuse, but it also enables a nice abstraction of, say, bignums or half-precision floats. AFAIK Ada has nothing like that. To be fair, you can make this criticism about any language for a given feature that might be important to your problem domain.

Did they have "Firework" on repeat?

I've worked (and work) with talented Indian developers, and ones who are frigging hackmasters, not in the good sense.

When you hire a team of developers into a position where you treat, pay, and support them (in terms of infrastructure, equipment, etc.) like cheap drones, the devs you attract (or at least the ones who stick around) will tend to be ... the drones.

Eventually, mining asteroids.

I'm not much better educated than yourself, but here's an attempt (which may be wrong):

The higher the pressure a combustion chamber runs at, the more efficient the combustion tends to be, so your rocket goes higher for a given amount of fuel. To get enough fuel into a high pressure chamber you need a good fuel pump. To drive this fuel pump, a gas turbine is used (the resulting fuel pump is called a "turbopump").

Inside the gas turbine, the turbine proper (the spinning fan-thingy at the back) is driven from a combustion chamber (normally different than the main chamber) that uses the same fuel/oxidizer as the main engine (though the plumbing paths/pressures are different). That turbine pressurizes the fuel for use by the main chamber. (Separate turbopumps are used to pressurize fuel and oxidizer)

Did you have a more specific question?

I don't see the problem with that, since the iMac + Mac Mini are severely space-constrained, just like a laptop. My AOpen MiniPC from 2009 uses what are, effectively, laptop parts.
If you want to go after Apple, look at their soldering of memory and (especially) SSD parts to the chassis.

It depends on what you're trying to do.
As the author of a (crappy) chess engine, if you have a performance-sensitive app, then you just need to build it with both and see which one "wins". In my app's case, clang was a little faster, but YMMV.
Both compilers will sometimes catch warnings that the other won't, so it's a good practice anyway.

In terms of warning/error clarity, clang might be slightly better, but gcc's is perfectly fine (especially if you're used to it). In the rare case that you see an obtuse error from one of them (this happens more often w/C++ obviously) then you build it with the other and hope the error is more decipherable.

Build time wise, I think clang is slightly faster, but if that is a huge deal for you, then you should probably be looking into a dedicated solution (see:meson/ninja, make -j, ElectricAccelerator etc.)

Good luck!

I agree regarding your father's lifestyle. I do think it's sad that your father dutifully stashed away (if I did the math correctly) $96k over the course of 8 years, only to have it sucked away in 6 weeks by cancer and funeral expenses.