I don't believe that every feature is good because some features are 'forced', or are mutually exclusive with other features. Case insensitivity is an example I gave of one such feature that has advantages at some times, and disadvantages at others. If there's a large project, knowing how to take advantage of Perl's features gives me an edge over someone who does not know how to take advantage of those features. So if the large project is something like a system administration front-end that is heavy on the regular expression parsing (see the Cobalt RaQ's backend system), Perl would indeed be a good choice. If the large project is very performance intensive, then Perl would probably not be. It's all about choosing the right tool for the job; I will never blindly advocate that one language is the best for all purposes.
This is a fair judgement. My experiences have been mixed: I've had to debug C programs written to control PLC-enabled conveyor systems while talking to an Informix database. Problem ended up being a bug in the linked list structure that the previous programmer (now long gone) had rolled. In my business (basically an employed software consultant), I get to talk to a *lot* of software development houses, and I almost always end up wondering how in the world these people stay afloat with their limited knowledge. I would not be so quick to trust their code with any language.
If you're having problems with people not reading and following coding standards in a professional environment, something's not right. This is one of the easier things for the coders to grasp; all they need to do is consult a list.
Just to make sure that you're not arguing for this: Language designers, to an extent, should not be responsible for these problems. They arise mostly from user-error; to remove it would be like removing 'dd' from unix systems because it's possible to destroy the hard drive with it. There are certain things they could do to reduce the desirability of goto, such as using named breaks to take care of the issues that shadowfyr raised, and these are things that language designers rightly should be concerned with.
As languages get higher and higher level, and people are able to express more and more constructs in them, it will indeed be difficult for programmers to learn the subtleties of an entire language. But I don't see this as a bad thing; if one absolutely requires that there be no subtleties at all, one should then use a language with no subtleties. But if one wants to make use of higher-level features such as closures and polymorphism, one will have to accept this complexity. Complexity at the language level here leads to simplicity at the algorithmic level. The right tool for the job is what should be chosen. We don't communicate with grunts and gestures, even though they would be totally unambiguous, with absolutely no side-effects, than the higher-level languages that we all speak.
Yes, I do believe that will work. This is what humanity has been spiraling towards ever since the concept of 'specialization' has been discovered. To understand the complexities of nature one has used abstraction and specialization. I see nothing wrong with it, and if today's generation of programmers can't handle it (but they can ;)), then the next generation will replace them. Designing to the least-common-denominator is a sure-fire way to encourage mediocrity rather than excellence.
However you may define 'cleaner', it has already been shown (and gone uncontested) that C++ is cleaner than C in some cases. It would be more correct to say, "I'm using a simpler language that is cleaner than C++ in some cases". Remember that absolutes are absolutely horrid things; their scope is so grand that they are nearly impossible to prove, but they are ridiculously simple to disprove.
|