the "it has to be C/C++/C#/PHP" hurts the field.
Yes, but business management won't use Ada solely to help the field of computer science; they use what they think is best for their business, and being able to hire from a large labor pool helps to keep their costs down. If a skill they need is rare, they know they will need to pay more for it. If Ada caught on, the more companies used it the more it would make sense for others to switch to it.
FWIW, IMHO, C# and PHP are like teats on a bull. C#'s purpse is to be M$ monopolySoftware. For me, PHP is unnecessary, but then again I have no problem connecting to a database from C, writing my own data dictionary / toolset, generating HTML, etc., so I can write my own app-building toolset. The last thing I'd want to do is be stuck using someone else's toolset (like PHP) unless someone is paying me to, in which case one works in the client's world and smiles. Not to mention, executing uncompiled source is a security nightmare, let alone the CPU use of run time compiling (significant, of course, on high-volume sites), but everyone is adver-brainwashed into following the herd. Yes, I know there are compiled versions now, precisely to address performance issues (
http://en.wikipedia.org/wiki/HipHop_for_PHP). Which one has to laugh at, it winds up being C++ anyway.
Markup languages? Come on.
They stink, but they are widely known. The whole web architecture is quite riduculous, really. But if you want to make a website, you need HTML. Nowadays, you really have to get CSS in there. If a business has a website that looks like it was made in 1994, they look rinky-tink. These markup languages stink because a) you can't count on features you use being deprecated b) they add tons of new features representing whole new ways of doing things and c) now are becoming enormous and including application logic, when they were first supposed to only be doing presentation. Combining app logic and presentation logic is just plain dumb (for the sophistication we have today). They are a wishy-washing standard that's all over the place and forces application rewrites just to maintain compatibility.
Businesses used to run on indexed files, then they switched to databases, and SQL is how they're accessed. It's funny cuz SQL was touted to be "english-like" and EASY when it first came out - that was the theory - simple and english-like - so idiots could use it ! But today we always see the recruiting search for the super-duper knowledge of SQL, cuz the engine can't magically always execute a statement super fast (hard to see that coming). Bottom line - difficult problems can't be wished away with buzzwords !
My point was that there's whole bodies of knowledge that are discarded (and have to be rediscovered) because of this.
Sad but true.
Where would we be if we accepted "it works" as "it works well"?
Funny, today we're lucky if we get works (see General Electric's race condition in the 2003 Power Blackout). The answer: marginal cost/benefit analysis. Does the programmer's time spent improving the thing cost less than the benefits of the results of his coding ?
Then why in the heck would you list efficiency as a great plus when "performance does not need to be measured in clock cycles."
I didn't say efficiency in this regard, i.e., performance being a great plus. Odd perhaps, because that's what's always heard. Well, actually the deal is, other solutions may be faster but C mostly renders sufficiently fast code. That's what's typically said by unix folks and I concur. To wit, the linux on my desktop. Assembler would often be faster but C code is usually fast enough. If not, usually Assembler is used. Once again - well-written assembler does not have to be unmaintable - Lotus-123 was written in assembler prior to version 3 - and it worked great.
Now for general programming, of say a not-too-high volume CGI-based website, string manipulation was a big part of the design of C and unix from the outset, and one can still make a CGI program in C (or C++) that works fine. Of course, with the performance of today's machines, a whole host of languages perform well enough to be used in this manner.
Of course, for high-volume, carrier-class, high-perf realtime, etc., where you get into all the various specialty fields or "industrial-strength" applications, most often then various specific languages have emerged as what's best for those situations. The differences in those cases are significant enough that developers typically made the same choices.
with what companies want: IMO they're looking for coders, nor software engineers
Yes, I'm talking my personal ideas; I agree, most companies don't feel too comfortable with too much talent or independent thinking in individuals.
Google
I would not work there; google for recent Bilderberg Google article.