Good hardware, poor software

E.g., in my current environment, I'd *really* benefit from a syntax like: thing=>method or thing=>member (note: NOT '->') but languages don't support that additional level of indirection :<

I shipped a client of mine a quick one-off prototype last year, built on through-hole protoboard. The USPS took it. Shipped the guy an empty box.

They really did! They sent it along with a "damaged in shipping" form letter. The box was pristine and had been neatly opened from the flap with the contents removed.

I guess someone does watch the X-ray machines they use.

This is *nothing* like what you said before, "do the up-front work before jumping into coding and debug." Deadlines are imposed by various factors, methods are hard to dictate.

Of course. We used to do it all the time in IBM. At the end of the quarter and particularly in December, trucks lined up all around the property to get the product out in that quarter. Tax laws are nuts.

Yep. We used to buy complete boards to scavenge microprocessors because we were proscribed from buying them. PHBs can be nuts.

It's not so much "scared of", but the suspicion that the new emperor has no better clothes than the old emperor.. :-)

I have PVR from Rogers Cable. Recently there was a cable outage. You'd think that we could watch the recorded programs. No such luck.

That's done intentionally. Perhaps even contractually.

What people don't get about strong typing is that it isn't as much to tell the compiler what the type is as to clarify it for the programmer. Or maybe I should say it is to make the programmer consider the type so they don't make typing mistakes.

It can't stop active malice (or extreme stupidity.) With C++ if you're determined you can often find a way to cast things to get something to take a value or type that it shouldn't.

Even with "auto" scattered everywhere instead of a function that returns const std::vector

No computer language will do that. My one paid experience with Ada involved finding bugs in someone else's code. The reason that I found the bug was because they didn't look, and the reason they didn't look is because they refused to believe that the bug could be in an Ada- programmed box that was talking to a C-programmed box.

Z & VDM come close but they are languages for specification of a problem rather than a compilable solution.

If you want extreme safety critical reliability cost no object you end up on a SPARK subset of Ada of the sort that Praxis made popular and is almost as fast as C when compiled these days.

Trouble is the learning curve is quite steep. ISTR a lot of effort in the original work went into proving that the compiler subset did what it was supposed to against all fence post boundary conditions.

Even so you can't prevent people allowing fly by wire jets to retract their landing gear or eject pilots whilst still on the ground.

You can ALWAYS convert ANY type to any OTHER type. Or, implicitly treat one as another:

char multiply(long multiplier, float *multiplicand) aardvark_t divide(banana_t dividend, automobile_t divisor)

etc. What strongly typed languages do is make it "less easy" to do this without "conscious thought".

If a developer can silence a compiler error/warning just by throwing in a cast operator (a handful of keystrokes), then he is probably more likely to resort to that "fix" instead of trying to understand WHY what he has done up to that point

Its a tough balancing act as a language designer; you want to make a language that is *useful* and allows "real work" to be done -- and efficiently! And, you want to discourage harmful practices that can result in poorer quality code.

Yet, at the same time, don't want to force people to take extraordinary measures to work around the "protections" you've placed in the language as those "extraordinary measures" then become riskier to code correctly and maintain. Wanna write an OS in COBOL?

Yup. Things like Ada or SPARK may make it easier to write safety- critical software, but there's no power like the Power of Idiocy.

Autotyping was a convenience. A good compiler would have an option to list the variables and their types, and proof-reading that listing was an important step in debugging. It wasn't part of the standard for FORTRAN, but it was very useful.