Slashdot Mirror
Why We Need More Programming Languages
snydeq writes "Fatal Exception's Neil McAllister writes in favor of new programming languages, given the difficulty of upgrading existing, popular languages. 'Whenever a new programming language is announced, a certain segment of the developer population always rolls its eyes and groans that we have quite enough to choose from already,' McAllister writes. 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 — 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.'"
The Saturn V was designed by many committees.
And for the time Ada is not a bad language at all, especially if you're mature enough to know that the quality of the result is more important than you.
C is like Oil Paints. Python is like water-soluble markers.
You can make artwork with both. you can also make a complete mess with both. This argument is silly.
For system-level native tasks, C is better.
Just because you're using C++ doesn't mean you need to write some glorious object-oriented dynamically-dispatched exception-throwing operator-overloading dynamically-dispatching self-reflecting monstrosity. C++ provides several very fundamental features which make it hugely superior to C: inline functions, better const semantics, reference types, and templates. If you don't want to write enterprisey crap, don't. But don't chuck out the baby with the bath water.
Performance doesn't matter any more.
Of course it does. Every programming task has to care about performance. What's changed is that the most important type of "performance" is different for every task. Most of us aren't doing large-scale numeric simulations.
If you're programming desktop GUI applications, responsiveness is usually more important than throughput. If you're programming mobile devices, battery efficiency is more important than any other consideration.
I think it was P.J. Plauger who pointed out that if the program to process the monthly payroll takes three months to run, it's useless.
What I think you meant to say is that for most programs, whether or not they meet their performance criteria is not limited by CPU cycles. That's certainly true. Most programming tasks can afford to spend some cycles if in return for correctness, programmer productivity or ease of maintenance.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});