Hacker News new | past | comments | ask | show | jobs | submit login
Why Programming Language X Is Unambiguously Better than Programming Language Y (joelgrus.com)
81 points by joelgrus on Dec 24, 2013 | hide | past | web | favorite | 30 comments

There once were two guys who had completely different opinions about programming languages:

First guy: I love studying programming languages and compare them all the time. I think about different features they have and how that impacts me as a developer. I have a very strong opinion about different languages, because I have invested a ton of time researching them. I love to use the newest languages around, because they excite me and keep me motivated.

Other guy: I hate all programming languages, and I'm sure they're all pretty much the same. It's just Narcissism of small differences [1]. I just do a little research and pick the most obvious candidate. Then I Get Shit Done. Programming languages need to be stable, predictable and maintainable. I avoid hipster languages at all costs. That's just good engineering.

I am both of these guys.


For most people, it's good to be both but leaning towards "the other guy" and focus on Getting Shit Done.

Most people are seeking success in their business. You become a detriment to yourself/company if you are constantly studying programming languages and always throwing away yesterdays code with [Y]'s new hotness. Yesterday's code become stale, no one wants to maintain or fix it because they have deemed it unworthy, "ugh who decided to write this in [X], terrible, this is career suicide to waste time on [X] when [Y] was about to be released"

Soon we are throwing away [Y] because [Z] just came out and it will solve all of our problems. There will be no end to "First guy"'s pursuit of the holy grail.

I value Get Shit Done more than any [X,Y,Z]. Nights and weekends are when I get to experiment and try new stuff to satisfy my learning needs, however I look to see what problems [Y] or [Z] is attempting to solve and how I might apply that to [X] and continue to Get Shit Done and focus on business success.

As coders we are similar to craftsmen. You can continue to make furniture with your tools you have now, or you can buy that new machine which will do it faster/better. You are going to take a $$$ hit purchasing that machine but eventually you should break even and return to profit. Now a new machine comes out doing it even faster/better than before. At some point you need to stop investing time/money in trying to become faster/better and realize some profits on what you have learned and are currently using. Likewise there is a time and place for introducing a new language to your company, but you need to make sure you can cash in on that investment or you will never Get Shit Done.

Yes, this is the economized vision of programming (as a trade). I'm sure it plays well in the Bay area. I'm sure its very "realistic" (that is, plays well within the current Standard Assumptions and Expectations).

I personally wish to emphasize the creative aspect of all human activity, esp. programming. The vast majority of worthwhile and lasting contributions to society (, etc.) are creatively, not financially motivated. Financial motivation is the death of creativity and intellectual progress in general.

Think about these statements for a moment, in particular the first which places a slash casually between "yourself" and "company" as though these were twin aspects of the same entity.

> You become a detriment to yourself/company

> Most people are seeking success in their business

> focus on business success

> you need to make sure you can cash in on that investment

"Get Shit Done", that is, accomplishing projects is not a matter of equating your interests to the pure financial motivations of a hypothetical business.

" If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. "

This seems too profound to too grand for everyday matters, but it is precisely about a (then) every day matter: building a ship.

When a researcher spends 20 years of their life on a single problem is it not their University they are thinking of, nor of the "business success".

When might we again write programs for the sake of something? And when might we take the writing of programs as an end in itself? The two ethical and aesthetic questions which this monetization of motivation completely obscures.

> I have a very strong opinion about different languages, because I have invested a ton of time researching them.

This doesn't follow? I mean, research leads to knowledge, which is about facts and facts are not opinions? Or am I missing something?

Facts ... can still be subjective.

Ok. Just skimmed the wiki page on "fact" and discovered that the word doesn't mean what I thought it means. :)

Oh, for heaven's sake. Now that he's gone and written this template, what the hell are we going to talk about on HN?

Everything is ruined.

The way people talk about it is hopefully ruined for some - if this makes a couple people stop to think that their reasons for championing a language are flawed then this is one awesome post. (yes, I know you're being sarcastic)

However, the discussion on issues such as type-safe vs not are still going to come up because they really are useful discussions because there isn't a right or wrong answer. It's like arguing if you should take the train or a car. In a general sense it's not a useful question, but in a specific sense it is very useful. Should I take the train or a car when going between specific X and Y is actually still a useful discussion and an important decision.

On the first glance this seems like a complete list of "language wars fallacies", but I'm 100% sure people will still come up with many variations on those and call them arguments. Just as they did for the past... half a century? So no need to worry, next time there is some PHP thread you'll see exactly the same thing you're used to.

Anyway, it's very well written and it provides a framework for selecting threads and comments to ignore. While I had a vague idea how to recognize unproductive flames now I have a solid template, which can be a great time saver.

Now I wish for someone to write this for "editor wars" as well!

The algorithm can easily be rewritten as:

    [barely understandable one-liner version of X code sample]
So the entire premise of flawed. Author should really learn about [X] before bashing it. Besides, [Y] doesn't even have [feature].

This is true for debates like Java vs C# or Python vs Ruby, but some languages are unambiguously better than others.

Usually this happens because the languages were never actually designed; they were nasty hacks thrown together in a few days by amateurs that happened to strike it lucky and become embedded in a technology stack that then took off, e.g. Javascript and PHP. Of course they are unambiguously worse than any language that was actually designed.

Sometimes there is a case where a language was explicitly designed to fix the problems of an earlier language. For example languages like Coffeescript and Dart were designed to fill exactly the same niche as Javascript but they had the benefit of being developed later, so it's not surprise if they are better than their inspiration.

Occasionally there is the slightly ambiguous case where a language is a superset of another language. For instance C++ is (almost) a superset of C, and Scala can be used as simply a better Java. So obviously C++ can do everything C can do, and more. The only ambiguity over their superiority comes because you can't trust programmers not to use the many new complex features of C++ and Scala, so there is a risk of the results being too complicated.

Deciding on a 'best' language often comes down to IDE support and library availability, rather than just the merits of the languages. Also there is strength in numbers - I would love to use Scala on Android, but I would fear that number of users of that combination is so low that I could hit an obscure compiler error that affects no one else and so doesn't get fixed. (I saw reports of this on mailing lists a couple of years ago, when users were fewer than they are now.) Also if you are choosing a language but hiring someone else to do the programming for you you have to consider that it's ten times easier to replace a Javascript monkey than a Lisp hacker.

> This is true for debates like Java vs C# or Python vs Ruby, but some languages are unambiguously better than others.

I strongly agree with that. What I find ridiculous is fanboyism, people that don't want to recognize the draft level of thisthose language/s.

> Deciding on a 'best' language often comes down to IDE support and library availability, rather than just the merits of the languages.

The Best Tool For The Job. True. But don't think business and practical use or usage of the language for a minute. There must be an absolute in languages and its implementation. I mean theoretically some languages are better than others. For instance take D, it does more and better than C, C++ (and Java?).

I think this debate has been implicitly solved, basically there is the scientific side dedicated to solve piratical dev issues, implementation details, math theory. In this area we can find Scheme, LISP and ML languages.

The other side is the business, engineering and fanboism where focus is on real world problems, where pragmatism beats theory and whether it's cool or not. Here there is almost only imperatives and compiled languages. Why? Winners write History and Thruth.

> The only ambiguity over their superiority comes because you can't trust programmers not to use the many new complex features of C++ and Scala, so there is a risk of the results being too complicated.

And AFAIK that's what killed Scheme and LISP, because the syntax is too powerful. And what still kills dynamic languages in general.

Generally valid, but it'd be better to qualify that assessment by saying that "some languages are better than others at certain things."

e.g. for a PHP one could fairly state "it's great if you're new to programming and want to spend a few hours figuring out how to get a web page up and running. But don't spend any more time than that with it, please."

or for JS: "yes it has serious flaws, but overall it's not as bad as you first think, especially if you read Crockford's book. The bigger point is that it's welded to the browser platform for the time being, and most likely will be for quite some time. So if you want to do frontend stuff, you have to at least be OK with it."

You see, it's all about context.

But even in such cases, there is often no unambiguous X is better than Y argument, because the question isn't exactly clear (There are many dimensions to this. How large is the project, which people are available to work on it, what is the maintainance schedule, which players are involved and will have to look at it, what kind of things do you intend to do, and do you envision hiring people in the future who will work on this?). These then add the a bunch of possibly conflicting dimensions to the right answer, and many of these can be better for X than for Y, even if Y is, from a language design standpoint, 'unambiguously better':

* Dev stacks

* # of developers you have or can reliably hire for it

* The general 'vibe' of the community. Some amazing languages have communities that are nasty, or tend to like overly verbose catering-to-ridiculous-generality libraries, just have way too many conflicting libraries for the same thing, don't have ANY libraries, prefer writing academic 'look at how fancy I can make this code look!' over just getting things done, and so many more unfortunate habits. A great many things that need doing are so simple, the benefit of a strictly better designed language often just don't weigh up to burdening yourself with the nasty habits of the community. You can try and go against the community, but now every time you search, the examples won't 'feel' right, most libraries will clash with your programming styles, when hiring new folks you need to retrain them significantly, and so on and so forth.

Even PHP has benefits. I admit the language is badly designed, extremely inconsistent, dev tooling sucks and the language by design isn't helping in that department either, and the community has an unbelievably nasty habit of mixing up a complete disdain and cluelessness about even basic security and a love of 'hey, it works for me' mentality.

But.. PHP's deploy stack is easy to understand, very widespread, the model pretty much forces you into writing your apps in a way that throwing money at the problem will pretty often work to solve scaling issues, there are a bajillion examples out there, programmers are easy to find, and that 'hey it works for me' attitude can actually come in handy if you're developing in-house.

I love to get on my high horse and shout trite things such as '... but PHP rots the brains of your programmers!', and I do, but if I have to be perfectly honest, I can foresee scenarios where it makes sense for a company to go with PHP.

And, hey, if PHP can sometimes be the right answer, clearly there is no room for the concept of 'X is unambiguously better than Y'.

Whatever language I am learning next is clearly better. It can't possibly be my fault the last language was to difficult, or too slow. I was just getting started and didn't know how much that last language sucked.


Clearly LISP is the language of the Gods, but sometimes I have to work in C because there isn't a good LISP port for certain embedded systems.


Node.JS is the best because you only have to learn one language, and everyone has to know JavaScript so that makes it the best.


I write everything in Assembly, it takes longer, but it is the purest programming.


I speak Python because that's what Harry Potter speaks and he is the coolest.


PERL is the best because you can do so much in a single line of code.


Objective C is the best because why would you want to develop for anything other than an Apple Device?


RPG was how my grandad did it, and so that's how I'm going to do it.

Freenode's ##programming could do well to understand the point of this post...

Unrelated, but linking to a specific HN post from your blog may not do what you think it does in terms of the story's voting.

Specifically, I believe the referrer header is checked, and if many votes come from the same place, those votes are... devalued? Something like that. I don't even think votes from the comments section for a submission are counted at all.

I'm not actually sure what the official HN admin stance is.

I link to HN discussions in my own posts, but I don't give a damn about the ranking algorithm, I just want to direct readers to a place where they can have a discussion.

If HN is ignoring votes from them, or penalizing my pages, or what-have-you, that's their business. I like to write, I don;t want to have to spend a lot of time trying to reverse engineer every social media site's ranking algorithm to figure out when to post it, what to call it, and what types of links are acceptable.

If HN really doesn't want people sending traffic their way, I hope they would put that in their guidelines.

HN isn't really a company in the sense that they don't have the same goals as a monetized website has - specifically, there isn't really a "drive" for users, or traffic. In fact there are many things HN does to actively discourage "general" users from joining/remaining part of the community.

I offer no value judgement, I just wanted to be clear what is happening when a blog links to its HN submission directly like in this case, and even moreso to your latest point - HN doesn't give a hoot if you send traffic its way or not.

It's very non-intuitive, I understand your confusion.

I'm not confused, and I don't expect them to have any desire for traffic. That's why I link to it even though there's more than a few people who believe it hurts the way my posts are ranked. They do their thing without giving a damn what I do, and I do my thing without giving a damn what they do.

If they really don't want people linking to HN discussions, they'll ask people not to do that. They aren't shy about asking people not to flood the new queue, for example. If they're penalizing the votes or comments of people who come through direct links, well, that's their business and I presume they know what they're doing.

I'm a writer, not a SEO consultant.

Disappointing. I was hoping for some sort of matrix.

Well done, Joel. It would have been unambiguously better if had been an interactive Madlibs implemented in Clojurescript though.

Why are we even comparing these languages in the first place? [Z] has been around for decades, it does the job, and everyone already knows it. It would be silly not to continue with [Z].

It's totally true, but I have already years of experience in Y and it is used by everybody around me. :-)

echoes in the echochamber

Because I Say So (TM).

And the point of this post was... What exactly?

The point was to highlight, in an amusing fashion (because the specifics were omitted), some of the silly ways in which people compare languages. By being aware of the silly ways in which we can argue about languages we can, hopefully, find some meaningful ways to compare programming languages instead. It was amusing and it was educational.

Oh, okay then.

Satire on the past few days of HN. Flowing loosely from Math vs. Lisp, Lisp vs. Scala, Clojure vs. Scala ...

Applications are open for YC Summer 2019

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