You completely missed the point: it wasn't about "C vs. Ada" (except as a concrete example), but about how the "it has to be C/C++/C#/PHP" hurts the field.
The "language wars" ended quite a few years ago. Languages are what they are. C is a widely-known language, which makes it easier - and cheaper - to find C programmers than many other languages. There are other popular languages as well, i.e., the markup languages, web-based scripting languages, the legacy business languages, SQL, etc. They are not perfect, but they are widely known.
One of these is not like the others: Markup languages? Come on. That's almost lumping "file format" into 'programming language'. There are languages geared toward display (PostScript), but markup? // Just because it's popular (and "everybody knows" or "has a standard") doesn't mean it's right, or good, or even desirable; in the legal world you can take the Raich or Kelo rulings for an example: in the former the court declared that non-commerce, because such commerce is illegal, impacts the market that doesn't exist and therefore could be regulated by the interstate commerce clause; in the latter the court held that imaginary numbers (projections) that increase tax-revenue count as "public use" for the purposes of eminent domain... despite that the land taken never was developed and was dropped from that company's development-plan (i.e. it doesn't matter if the cause of the projection ever materializes, just that there's a projection).
My point was that there's whole bodies of knowledge that are discarded (and have to be rediscovered) because of this. Take Just-In-Time compilation: it was likely pioneered by Niklaus Wirth in the 80s (under the name "delayed emission"), yet has been rediscovered [and hyped] in more recent years. Or take DOTNET, with it's "program in any language" idea/marketing -- recycled from VMS's Common Language Environment... even the name "Common Language Runtime" is similar. (ie. "Runtime Environment")
Where would we be if we accepted "it works" as "it works well"? -- I mean bubble-sort works, it gets things sorted, so why don't we use that all the time. The answer is "because it doesn't work well in many of the places we need to sort" [because of the time constraint]. So what about QuickSort, it's great, right? Well, some studies have shown that in parallel environments Shell Sort is faster than QuickSort. -- But if we applied the same reasoning to the tools [language included] we use to build systems we'd still be using Bubblesort... because it's easy and ubiquitous!
Most of the programming that is done in the world is simple garden-variety business apps, websites, etc., where performance does not need to be measured in clock cycles and for most businesses it's just as important to be able to find programmers who are at least somewhat familiar with the languages they use as it is to have a language feature set that is optimal.
Then why in the heck would you list efficiency as a great plus when "performance does not need to be measured in clock cycles."
Are we talking about systems-programming here, or general programming, the listing you give says "general" -- and what the heck is an "optimal feature set"? We're talking languages here, so let's discard all libraries not mandated by the standard. *arg!*
Not at you, but at the idea that 'syntax style' would be considered a portion of 'feature set'. -- I like Ada's Pascal-like syntax, that's a personal preference (and recognized as such) for an attribute of the language, but that's not a feature (except in the very generalized sense): features of Ada would be "generalized loop construct [with the ability to test in the middle of the loop]", "localized index of the for-loop", "tasks", "standard specified library of containers" [dependent on implementation, but with certain minimal requirements for, say, searching], "strong type-checking", etc. [Again, I'm not using Ada because "Ada is great!", but because: I know it, I like it, & it serves as a concrete example (of a different style/approach in the same paradigm {imperative/procedural}).]
To each their own. Well, until I write my language. It will be the ultimate language, and everyone will have to write all their programs in it. How do I write /sarc in Ada ?
I think I'd use:
Ada.Text_IO.Put_Line( "/sarc" );... ;)
re: Narrow experience criteria
I'd take a newbie programmer who had never seen the language I needed them to work in - if I thought they exhibited the qualities of a future excellent programmer - over a person with exactly the right experience who was a dolt. I'd also take an "excellent programmer", (right ethic, not lazy, good insight, etc.) who had worked as a programmer for 40 years in some ancient, irrelevant language over, once again, the dolt whose skills happen to be a "perfect fit" to the job. The person's resume does not write the code, the person does.
As far as C being "sufficient", there are bazillion unix systems all over the world (including the one I'm looking at) and most of the systems programs running on them are written in C. So, while C may not be the Holy Grail of computing, systems programs have long been successfully written in C. On the other hand, the fly-by-wire system of the Beoing 777 is written in Ada; the decision makers on that project chose Ada, and hey - more power to them.
Not just the fly-by-wire; IIRC, the entire software system (aside from some small segment[s] of assembly) of the 777 is written in Ada. IIRC same with the Apache [helicopter] and most of the F-22 (F-22 link). {Like I said, I like Ada; so I did a little research on what its used for/in.} I honestly think that it's a better language, in general, to program in than C/C++ or Pascal/Delphi... but that's another talk altogether.
As far as "exhibited the qualities of a future excellent programmer" goes this seems at odds with what companies want: IMO they're looking for coders, nor software engineers. [Again, that's based on my limited personal experience.]
re: Employee/employer, work for hire:
If you owned a business and hired me to write a complete sofware package for you, and then I went out and competed against you with well-funded backers, by bringing all the code I wrote to them, that would be the other side of copyright (ouch!).
Of course, if I wrote something on my own time that was NOT competitive with your product, you'd probably rightly feel that I had every right to do so, and I agree.
IMHO, for software developers who are key employees, whose work product value gets into the tens and hundreds of millions, having equity in the firm is the best route for all concerned, as it can much farther than plain salary and bonus on aligning goals and creating a shared risk/reward situation.
You're probably right about the equity-thing, but the fact still remains that there's a lot of bad-faith in intellectual property; like the given example about Google laying claim to all their employee's works. (Not a joke, I have a friend who was a S/W developer there who had developed a image-analyzer algorithm to detect breast-cancer [originally he developed it for Parkinson's MRIs] that, as he put it, would have been taken under the new contract's intellectual property clauses if he didn't have documentation backing up that he'd been developing this procedure for years before he came on-board.) Also, I got an email from Google about an application I'd put in (a long time ago) and when I expressed concern about it [I have interests in systems-programming, particularly OS] they broke off communication and that was it. What does that indicate? That they either were not serious enough to address valid legal-concerns, OR that they intended to lay claim to whatever I developed if they could. (Do I seriously think they'd get much from the latter: no. I'll admit I'm not a super-genius-- hell, some days weeks I question my own general-competency --but I would like to have the ability to own my own work.)
I failed to copy you to #63. I shared an experience with OneWingedShark. Enjoy if you have time. Otherwise, carry on. :)