Comments:"Ned Batchelder: Stupid languages"
URL:http://nedbatchelder.com/blog/201301/stupid_languages.html
A popular pastime among programmers is to make fun of programming languages, or at least the one you choose not to use. For example, Gary Bernhardt's 5-minute talk WAT is all about unexpected behavior, mostly in Javascript.
Today brought another example of surprising Javascript behavior:
> ['10', '10', '10', '10', '10'].map(parseInt)[ 10, NaN, 2, 3, 4 ]I looked at this and thought, like most others, "WAT??" I wanted to understand how Javascript produced this result, so I read up on Javascript'smap() function. Once I read the docs, it was clear what was going on.
In most programming languages, the map function accepts a function of one argument, invokes the function for all of the values in an array, and produces the array of results. Javascript doesn't work quite that way.
In Javascript, the map function accepts a function of three arguments. For each element in the array, the function is passed the element, the index of the element, and the entire array. So this map function makes these function calls:
parseInt('10', 0, ['10', '10', '10', '10', '10'])parseInt('10', 1, ['10', '10', '10', '10', '10'])parseInt('10', 2, ['10', '10', '10', '10', '10'])parseInt('10', 3, ['10', '10', '10', '10', '10'])parseInt('10', 4, ['10', '10', '10', '10', '10'])The second argument to parseInt is the base to use when converting the string to an integer. A value of 0 means, "do the right thing," so the first result is 10. A base of 1 makes no sense, so the second result is NaN. And 2, 3, and 4 produce 2, 3, and 4. Javascript silently ignores extra arguments, so the array passed as the third argument has no effect.
So is Javascript's map wrong? It behaves differently than the map found inlots of other languages like Python, Ruby, Lisp, Perl, Haskell, and so on. But it isn't wrong.
Working in more than one language, it's frustrating dealing with their differences. New Python learners chafe at the fact that Python names work differently than C variables. They want to know if function arguments are call by value or call by reference (neither). I saw a person on IRC once who was upset that Python lists were called lists instead of arrays.
Languages are different, that's why we have more than one of them. Language designers have to strike a balance between familiarity and innovation. We'd be pretty suprised by a language that used something other than "+" for adding numbers together, for example. Eventually though, the new language will diverge from the old, or what was the point?
Javascript's map function feels a little clunky: it's focused on integer-based iteration rather than on pure functional construction. But it can do things the other maps can't easily, like create an array of differences between elements, or a running total, and so on. Other languages have other solutions to those problems.
This isn't to say that all languages are equal, there are better andworse, of course. But too often I hear people ranting about a language being stupid for some decision, without bothering to find out why it was done that way, and what benefit they might get from it.
To which, I say: WAT!?
Good post.
Until you ignored your own logic and linked to that discredited PHP "fractal of bad design" post. It has been destroyed, repeatedly (links below) but, more importantly here, the dismissal of PHP as a "worse" language ignores the excellent advice in this post.
Worse when?
Instead of using this comment as part of a language flame war (those links are below, for those who care), I would like to apply this post's excellent critique of ignorant dismissals of languages to this post's ignorant* dismissal of PHP.
Why might someone choose PHP? Let's explore.
Imagine you are about to start building a web application which you hope will be deployed on thousands of servers, by thousands of users. You would do well to make the setup as easy as possible. Perhaps the single most important factor for a large segment of your potential customers will be ease of installation.
With PHP, installation is just SFTP-ing your files. That is it. No server configuration, no anything. An update? Change the file, and FTP it back to the server. No restarting the server. No rebuilding anything. No nothing.
This is one of the killer features in PHP, the language. Ease of use for server "administrators." For the team that creates a (hopefully!) widely deployed web app, these people are referred to as users or customers. If they can install your software easily, it is much more likely they will.
This feature of PHP plays no small part in the success of widely deployed web apps, such as WordPress, WikiMedia, Joomla, Drupal, etc.. In fact, I would go so far as to say that if your goal is a widely deployed web app, then PHP is the best language out there.
PHP has other great features absent in other languages, described in the links below. Worth learning about.
To quote an insightful author:
"Too often I hear people ranting about a language being stupid for some decision, without bothering to find out why it was done that way, and what benefit they might get from it."
Language war stuff
I love Python. I would just never choose it if my goal was a widely deployed web app. FWIW, probably because I don't know it well enough, I actually prefer PHP to Ruby.
I program in many languages, mostly PHP, C++, JavaScript, and, recently, Clojure. I actually (mostly) like all of them. No matter which I am using, I always hit things where I think "this would be so much easier with [fill in the blank]" but they each are best at something. PHP is best for building widely deployed web apps.
* The links, for those who would like to learn about the good parts of PHP, why the fractal article is crap, and the reason PHP is so often chosen (such as for the software that handles this very comment):
http://forums.devshed.com/php-development-5/php-is-a-fractal-of-bad-design-hardly-929746.html
http://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html
http://fabien.potencier.org/article/64/php-is-much-better-than-you-think