In my opinion, the "best" programming language is the best tool for the job at hand.
Maybe you're writing high-performance backend software, in which speed is everything. Sure, a functional or, hell, low-level language like assembly is the "right" choice. In this case, it is the 'better' language.
Or, maybe, you're trying to write an easy-to-maintain script to manage log files on your server. Who cares if it's costing you some CPU cycles to interpret? Run Python or Ruby, or, hell, just write a shell script. That would be the 'better' language.
I wholeheartedly agree with what I believe to be pg's intent in this writeup: that good design should be timeless. I don't agree, however, that good design, especially for a programming language, always has to be skill- or performance-oriented.
Quick edit for clarity: Although the example I used for backend software did equate "performance" to "speed," it's important to note that pg addressed this by saying:
> Performance doesn't mean speed; that's taking the metaphor too literally. Speed counts, but a programming language is first of all a tool for thinking in.
My point is that clear thinking can be equally applied to easy-to-read code working at a high level as it can be to any functional language designed to induce algorithmic thought.
This is so true, but it's more than just cpu speed vs programmer speed. There are philosophies that are built in to the language and you can see them in decisions made about the language, the kinds of patterns baked in, the libraries and the greater community.
Say you need high reliability. Erlang has fault tolerance model & hot code reloading, it was built for telephone systems. Say you need tons of statistical features: R. Infinite Recursion: Stackless Python. Mixins Galore: _why's potion. Run a bunch of commands with little/no logic: Tcl. html generation: php. Manipulate a flash canvas: Actionscript. Manipulate html dom: javascript.
Be honest, your language isn't going to stick around forever. I say make a language for a purpose with a specific problem space in mind, read papers and implement surrounding philosophies that nail down that problem well. Then it will become popular and overused to the point where it's used for things it wasn't meant for.
Maybe you're writing high-performance backend software, in which speed is everything. Sure, a functional or, hell, low-level language like assembly is the "right" choice. In this case, it is the 'better' language.
Or, maybe, you're trying to write an easy-to-maintain script to manage log files on your server. Who cares if it's costing you some CPU cycles to interpret? Run Python or Ruby, or, hell, just write a shell script. That would be the 'better' language.
I wholeheartedly agree with what I believe to be pg's intent in this writeup: that good design should be timeless. I don't agree, however, that good design, especially for a programming language, always has to be skill- or performance-oriented.
Quick edit for clarity: Although the example I used for backend software did equate "performance" to "speed," it's important to note that pg addressed this by saying:
> Performance doesn't mean speed; that's taking the metaphor too literally. Speed counts, but a programming language is first of all a tool for thinking in.
My point is that clear thinking can be equally applied to easy-to-read code working at a high level as it can be to any functional language designed to induce algorithmic thought.