Implementing a new Base Library is hard, I've gotten a tiny subset working on my own to see just what is involved. I wouldn't recommend writing the full thing unless you have a burning desire to do it.
Contrast with implementing the C++ base libraries (such as the STL) and you'll quickly see which is simpler. The real difference is that C++ already has more implementations for more platforms. I agree with your conclusion - availability can make its use for your project a non-starter. However, unless we're talking about pretty weird embedded stuff or some weird OS platform like Haiku or something, GNUstep has been already been ported to lots and lots of platforms (including most of the major *nixes and Windows).
Dynamic binding and loading is ugly and clunky.
So dynamic binding and loading is ugly and clunky. Remember this boys and girls...
It's much more touchy about types and is geared toward catching as much as it can at compile time.
And the reason for that is because it's statically bound (well, for the most part, apart from "virtual" methods). It has dick-all to do with "correctness" or whatever. It's simply because even if a subclass has its own implementation of a parent's method, it'll still call the parent method - this goes against one of the core principles of OO: polymorphism. This means that even *if* you wanted to override a method from a parent class in your subclass, unless the parent has it marked as virtual, you're SOL. In Objective-C, meanwhile, it'll work exactly as you'd expect - the child method will get called. Also don't assume that simply because Objective-C is dynamically bound that it doesn't watch your fingers. If you aren't a stupid programmer and have warnings turned on, it'll warn you of weird stuff, such as sending a message to an object of a class which is not known to have it declared. I've written a fair amount of Objective-C code and only encountered sending an incorrect message to an object a few times. Now allocation-related stuff, that's the killer! But it's the same in both languages (in fact, one could argue that ObjC is a bit better, as it at least gives you a ref-count garbage collector, whereas in C++ you're on your own).
[C++ is] big and clunky, has a lot of rules to memorize and its error messages are hideous.
And so now C++ is the clunky one? TBH, it really comes down to personal preference. I like dynamically bound languages, because it fits my style of thinking. If you're writing complex interactions between objects, it cuts down on the amount of code needed to write quite a bit and if you follow the suggestions of the compiler, you're very unlikely to shoot yourself in the foot. OTOH, I understand that if you're after 100% valid programs where static analysis gives you a lot of confidence ahead of time, then C++ is probably the way to go (although I'd prefer C in that case). It's really about style and personal preference. Neither is more or less clunky, it depends on what you want to do with and how you want to do it.
ancient discredited NERVA/ROVER program which began in 1956 and dragged on to a miserable failed end in 1973
You mean the discredited program that produced working engines and test-fired them on vacuum stands, proving they are practical and work? You might also note another program that was terminated in 1972: Apollo. Oh my, what an abominable failure that one was...
the fact that any rocket has to carry and throw away a vast load of reaction mass
And how else would you propose to move in space? Mr Newton might have something to say here.
But the actual raw energy needed to lift 118 tonnes to 200 km is...
If you think the difficulty in achieving orbit is just lifting something sufficiently high up, you're more dense than I thought... Here's an idea, first learn about something, then start lecturing about it.
No other mode of transportation has to carry its own reaction mass and throw it away. Not bicycles, cars, trains, ships, submarines, or airplanes.
Please note that all of the above modes of transportation have one thing in common: they only work on the Earth. Or when was the last time you last saw a car drive through outer space?
I agree: Lua is absolutely one of the best things to be teaching high school students. You can either sit entirely in the Lua language itself, or you can learn to extend the capabilities of the VM and interface with outside libraries and frameworks.
And now you don't have an audible trail: I can't be sure my ballot was counted correctly. The first comment above still holds.
Does the U.S. version of Netflix really use a library model, where they strive to keep content available indefinitely? Video streaming services here in Germany continually change the content they are offering, so it's more like a TV with very many channels and random access, and not really a replacement for a collection of your favorite movies and shows.
I don't how great a source it is
Apparently not a very good one. Google maps says that the optimal driving distance from SF to BOS is about 3000 miles, which, on a 30mpg car, results in 100 gallons of fuel burn. Gasoline is typically around 0.75kg/L, so that comes to 284kg of fuel. Unless your vehicle manages to break the laws of physics somehow, you're never going to emit 930 kg of just greenhouse gases per vehicle. Now the same trip using a plane is about 2700 miles (from a real flight plan). A typical Airbus A320 or Boeing 737 comes to about 0.03L/km/seat, and given that Jet-A is typically around 0.82kg/L, this comes to ~100kg per seat.
So it really comes down to occupancy. A nearly fully-booked plane wins over a single-occupancy car hands down easily. The break even point is at about 2-3 passengers per car, so a car can be more efficient, assuming you car pool. One thing frequently forgotten in these comparisons, though, is the cost of time. The flight is 6 hours. The drive is 4 days of non-stop driving. In any case, just wanted to let your know that the source you cited is quite off.
Also Brother MFC-8480DN, prints PDF fine from USB drives that originate from many different programs. Only print I ever had fail used Adobe DRM to protect one of the layers, had to print that from Windows, because the bits needed to remain secret before being reproduced on a piece of paper. (sigh)
Byte your tongue.