Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's easy: the best recognize languages are just a means to an end. Language snobbery, in my experience, tends to be highly correlated with being a "wannabe" rather than "great" and a useful filter.

You will find any number of C/C++ programmers who think you can't write anything in Java. Many Java programmers think you can't write anything (beyond 100 lines) in Python. Many Python programmers think you can't (or simply shouldn't) write anything in PHP. And so on.

Some people are insecure.

Some people can't separate their language from themselves (and see a criticism of their language as a criticism of them as people).

Some people exemplify the Dunning-Kruger effect [1].

Some, like teenagers, are just asserting their identities.

Some simply have biases that are mental blocks.

[1]: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect



That's a well-reasoned but rather lazy response imo.

Ppl who have strong opinions when it comes to language design have strong opinions when it comes to language design. Ppl who think languages are just a means to an end think languages are just a means to an end. These are two differenty species and indicative of their particular worldview, attitude and preferences. To use that as any kind of filter is silly.

Lets not look at CS for a second...If you want to know what a Stieltjes integral is, a probabilist will tell you one thing, a functional analyst another, and a measure theorist will give you yet another more pedantic definition. There's no right or wrong definition here...every one is coming at it with the tools they are more well versed in. The probabilist is the end-user, so to speak. He can't do his day to day work without internalizing it, because his bread and butter, the PDFs and CDFs of all the distributions he deals with, comes from Stieltjes. The functional analyst is going to use Stieltjes when he deals with Banach spaces, but otherwise he has other preoccupations. The measure theorist studies Stieltjes in depth because it goes to the very foundantion of measure theory...but he isn't really an end-user.

Now back to CS...a C++ programmer will think of Java as an interesting toy because you don't get union types and pointers & so forth. The Java guy will think of Python as an interesting toy, and the Python guy thinks PHP is an interesting toy. None of this means any of these people are insecure or being a teenager. If the only goal in life is "languages as means to an end" where end = $$$ in the short term, then yeah, lets just cut to the chase and do PHP. But there are other goals, yeah ?


You have obviously never worked on a million-line codebase.

When you have crap like this in your language:

> E.g., $i = 0; $a[$i] = $i++; makes a different array than $i = 0; $a[$i + 0] = $i++;

you have no hope of making a truly large program work. There are just too many sources of itsy bitsy bugs; you'll never find them all.

(I'm not a PHP user; I have no idea why those are different arrays. Don't bother explaining; I don't want to know.)


I don't use PHP much, but I was curious, so here's the answer you don't want:

You get $a[1] = 0 the first way, and $a[0] = 0 the second way. PHP seems to evaluate the array index before the right hand side if there is something more than a $variable to evaluate; otherwise PHP evaluates the array index after the right hand side, after $i has been incremented.

I haven't used hiphop, but I'm curious if it preserves that disparity between arrays when translating to C++, or if it breaks PHP compatibility by making those two arrays equivalent.


The entire point of my post was that we preserve the semantics of this (and many other) PHP-isms. We have to, because you never can tell which glitches useful code has come to depend on.


I like how people who exemplify the Dunning-Kruger effect are entirely willing to cite it in order to look smart.


Not all languages are equal. (if they are, why not just write everything in assembly?)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: