NukeFUD will never be overcome in the world, the threshold for self-sustaining fear reaction was reached back in the 70's, as long as there are new generations of people taught to fear anything with the word "nuclear" in it. Changing the name of "MRI" machines from "NMRI" was pure marketing to avoid having to call them "nuclear magnetic resonance imaging" which would have terrified the masses and led to mass protests against the "horrible consequences" of its use.

Too many people are too terrified for this to ever catch on. Most would rather "freeze to death in the dark" than to have anything to do with nuclear power.

I once had 6 months of expenses in savings. Then I was unemployed (contractor, no UI for me) for 12 months.

Couldn't they have contacted the parent and expressed concern from adult to adult rather than from adult to 4 year old? Perhaps offered the parent the opportunity to supplement the kid's lunch through school-provided food?

That's not how bureaucracies work. The rules are there in order to prevent the bad consequences of lower-level bureaucrats or implementers thinking for themselves and possibly acting in ways that go against the direction the top-level bureaucrats have decided upon.

Apparently not, it's important for people to accept what government representatives tell us, for our own good. They must know better than us, or else they wouldn't be in positions of authority. "Shut up", Slashdot explained.

I learned early on as a junior developer to be paranoid when it came time to code the design. There are a few rules that I learned to keep in mind that have allowed me to pass more unit and system tests.

One, don't trust the data that comes into your method/function/subroutine.

Two, don't trust the data that comes back from methods/functions/subroutines that you call.

Three, assume that other users will not trust the data that you modify and/or return from the function/method/subroutine that you're writing, and therefore accurately report to them anything that goes wrong.

I've noticed a trend in the past few years in younger developers, that they tend to develop with the best case scenarios in mind, believe that users will always enter valid data, that functions are always correctly documented and always require and return exactly what their documentation states, and that therefore the developers' code will never break unexpectedly. There is the idea that error checking isn't needed anymore because it's a waste of effort and time, that Java will always throw exceptions when something really bad happens, and rebooting/restarting the software will fix everything. I have to tell them that Java can't report failures caused by violating the business rules behind the design, that it's important to check for valid data and valid execution.

Of course, since I'm old and "unable to keep up" I'm now working maintenance on a big system, but I've found several show-stopper bugs that would not have shown up had the developers been just a bit more paranoid in the design stage. It would also have been cheaper to find the bugs before deployment, but the testing staff is overworked and understaffed, and stuff gets through, and so we have to get the trouble tickets from senior management in the customer's organization (USGov) when critical things break. People who when they are unhappy enough, take contracts away from the developers who make them unhappy.

Not to mention self-repairing as well, and even able to create multiple replacement copies. Well, given certain parts were not removed beforehand, of course.

It's not "moving the code from C to python", it's "solving the users' problem" that matters. I've used FORTRAN in satellite data analysis, Smalltalk in an AI support application, C in dozens of large and small commercial and DARPA projects, C++ in document management and in network allocation apps, Perl in a photo database app, Cold Fusion in an online timecard app (in-house), currently AJAX in a large system for ICE/DHS. The few times that a language was chosen before design work began were less than successful. I know how to learn and use languages to their fullest, taking advantage of each ones' strengths while working around their weaknesses. I did object-oriented programming in C back when C++ was just a glorified pre-processor, which led me to realize that there was nothing special about C++, since it could be reduced to C and then to Assembly and finally opcodes. All languages at the human level are still reduced to the same thing at the computer's level.

I will grant that there will be some types of syntax that will allow, say, object-oriented designs to be implemented easier than others, but nothing in the languages themselves is inherently more appropriate to solving the users' problems.

If you can't solve the problem, it doesn't matter how "pythonic" your solution is. That's the bottom line.

Good lord, talk about deja vu. I literally (not figuratively) have heard this same song with different lyrics for over 25 years. I first heard it from a Smalltalker who was denigrating the ability of a FORTRAN programmer to write "good" Smalltalk code. The perception is that there is some magical ability of a hip, new language to do things that the "outdated" language doesn't have, despite both being based on the same Von Neumann architecture underneath. Syntaxes change, some language may make a particular design easier, but all languages can implement the same patterns, they just require different levels of effort.

The main issue which is outside of any language is, "can I solve the user's problem in software?" Ease of development, ease of maintenance, and ease of re-design are important, but they are orthogonal to the decision of which language to implement a system in. Choosing Ruby instead of C, for example, shouldn't be made based on the age of the language, but on whether the software that comes out first meets the users' needs. If you can't solve the problem that they need software for, it doesn't matter how "pure" the Ruby code you write ends up being.

Are you working in a position in a company as an MBA? Have you worked in companies and seen what the typical business-school manager does? You sound too young to have experienced the downside of your profession, but just wait. And yes, that's unapologetically "ageist" of me to say.

Exactly. We're dealing with Von Neumann architecture, which means that (unless you're using Haskell or one of the other "weird" languages) you're going to be doing the exact same things at the lower level, regardless of the semantic sugar you spin over it all. Understanding how the architecture works means that you can ramp up in far less time than someone coming in fresh, even if they were stellar students in college. You don't really have an appreciation or understanding of a system unless you've been spending all your time on it, found all the ways to break it, and then spending the hours and effort to fix it.