

Your Ignorance Does Not Make a Programming Language Suck - edw519
http://coffeeghost.net/2008/03/19/your-ignorance-does-not-make-a-programming-language-suck/

======
astine
I disagree with this. The argument seems to be that the only valid reasons to
discredit a language are extrinsic to the language itself. Granted, one should
always take into account the language's problem domain and design principles
before criticizing for lacking X or having X, but this doesn't mean that the
language itself can be poorly designed or have issues.

Java really is verbose. Perl really does have an inconsistent syntax. C++
really does lend itself to memory errors.

Do each of these languages solve the problem that they were meant to solve? I
think so. Do each of them still have issues that deserve criticism? Of course.

I think that there is nothing wrong with criticizing a language. If we didn't
criticize nothing would improve and there's always room for improvement.

~~~
sah
The author seems to want to say that _language features_ are invalid criteria
on which to judge the quality of a language (instead, he suggests that you
should look at the quality of the documentation, the libraries, the community,
and perhaps the syntax).

It's true that there are some language features, like type checking and memory
management, on which reasonable people disagree. I think that those represent
opportunities for innovation. Type inference, for example, seems to be
changing the terms of the debate about static vs. dynamic typing.

~~~
derefr
I think of it more like this: a programming language's features are like its
genetic code. A dog is not a "bad" cat, it is just a dog. Nothing more,
nothing less. A cat is badly suited for some dog-like tasks (dogsled racing),
while a dog is likewise badly suited for some cat-like tasks (hairball
production).

However, there are some ways in which a dog can be badly designed. It can be
prone to cancer or congenital diseases. It may be blind from birth. Such
things are not features of dogs, but rather extrinsic properties, just as the
ones listed in the article.

Or, to put it simply: it is not what you do, but how you do it.

~~~
sah
I think it's fair to look at language features as benefits and drawbacks in
languages, as long as you're aware of what those features have to offer, and
what the costs are.

It makes sense to want a way to judge languages not on the presence or absence
of particular features, but on their ability to achieve some goal. But what
should the goal be? Popularity? Lowest time required to write programs, or to
read them? Approachability for new users, or convenience for experts? Utility
for writing fast programs, or for writing programs fast?

You can specialize languages down to the point where there's a different best
answer for every possible goal, but because I don't want to maintain fluency
in 50 different languages, I'm most interested in languages that do very well
in a wide variety of ways. If you want to get down to figuring out where the
trade-offs really are, and which goals can be achieved simultaneously, you
can't take the attitude that every language is just great at being itself. You
have to allow for the possibility that some languages really would be better
all around with the addition or alteration of certain features.

------
dreish
Lack of closures is hardly an "invalid" reason to dislike a language,
especially if the reason for lacking closures is that they're too confusing
for less-skilled programmers.

