Erik McClure

Language Wars Are Pointless

Sometimes it really amazes me when anyone actually takes language wars seriously. If I casually mention “pointless language wars” and someone leaves a comment ignoring my entire blog post, informing me that language wars are not pointless, I seriously question their priorities (and possibly their sanity).

*As a veteran language warrior, I resent the claim that my efforts are "pointless". There's a lot of terrible software out there, and one of the reasons for this is that inappropriate choices were made on the outset.*

Oh, was I not clear enough before? Language wars are pointless. They are pointless for 2 reasons: You are never actually arguing about the language, only design philosophies, and these language wars invariably disregard context, which makes all results of said war completely meaningless.

In this crazy rant Alex Munroe1 made about PHP being a terrible language, he seems to be confusing “PHP is a bad language” and “PHP adheres to bad design philosophies”, and even then its just design philosophies he doesn’t agree with. This is all well and good, but that doesn’t make PHP a bad language. It’s like saying a hammer is bad because you don’t like the handle - just because its not good for you doesn’t mean its not good for everyone. If you want to prove that PHP is fundamentally a bad language, you have to demonstrate that almost all the philosophies that it follows are bad for everyone. You can’t say a philosophy is good in one language and not good in another without accidentally tripping over yet another philosophy. A good example is his complaint about the ‘@’ operator suppressing errors. You can suppress errors in python too, its just harder. The argument is that its too easy to ignore errors, therefore it encourages bad programming, therefore PHP is the devil. This doesn’t make sense, because you aren’t saying PHP itself is bad, you are saying that you believe a programming language should make writing bad code difficult, which is a philosophy. Consequently, you can’t just say that PHP is bad, you have to say that every single language that does this is at least partially bad. Of course, the guy loves writing code in perl, so I suppose he prefers using a language that makes it hard to do anything.2

Let’s say you actually prove that something is bad for everyone. Have you proven that its bad for everyone in every possible context? You have to do that too. The problem with language wars is that people go “Yo man whatcha using PHP for we got dis new trunk called Django that’s so wicked sick goddamn get with the times homie” without ever actually asking you what you are trying to do and in what context you are doing it in. You cannot critique a language without first specifying what context you are critiquing it in. If you do not specify the context, even if its something vague like “for most non-performance critical applications”, everything you say is an over-generalization and therefore invalid. There is quite literally NOTHING that you can absolutely guarantee any piece of code should do - not even the fact that it should work (for example, testing static code analysis). Because of this, unless you are saying X is a bad language for doing Y, and not simply that a given language is bad, forever, no matter what, you are doing a bad job of critiquing. Even brainfuck is useful for illustrating how a Turing Machine works. As the old saying goes, never say never (or always).

With this said, most of the points Alex Munroe makes against PHP are actually quite valid.3 In fact, if he had instead argued that PHP is a poor choice of language for building a modern, professional website, I’d probably agree …but that doesn’t make it a bad language. Maybe its a bad language for that purpose, but that’s as far as you can go and still hold a legitimate opinion. There is an endless, endless torrent of people insisting that C++ is a terrible language, and it’s not that their reasons are wrong, it’s that they are ignoring the context of what I use C++ for. It just follows design philosophies they don’t agree with in their line of work. It’s fine that they don’t agree with them, but uh, that’s why we have lots of different programming languages and why we need to stop assuming programmers are all the same. What are you going to do, tell Linus Torvalds to code Linux using Lisp instead of C because Performance Doesn’t Matter?

This problem of blindly following idioms like “Performance Doesn’t Matter” and “SHARD EVERYTHING” in the database world is that you are separating the advice from the context it was given in. This makes language wars pointless and causes serious issues with the new wave of databases that are pissing off a lot of people (BUT MONDODB IS WEB SCALE) because fanboys who don’t understand the context those databases were designed for simply assume you should use them for everything and therefore anyone using MySQL or PostgreSQL is a dinosaur. You can’t just forget about Unknown unknowns (things you don’t know that you don’t know). If someone is using a language and you don’t understand why, don’t assume its because they’re an idiot because the language is bad no matter what, assume that its because there is a variable you forgot to account for.

It’s kind of like watching a carpenter yell at a plumber for building a house upside-down, except the plumber actually built a toilet and the carpenter just thinks it looks like an upside-down house.

1 whose name took me almost 2 minutes of digging around his blog, and then his site, until I finally found it buried in the fine print on the footer.


Allen Short

I think Eevee's post is copious evidence that PHP isn't suitable for any purpose. Everything you can do with it can be done better, easier, faster, better looking, <insert positive description here> with some other language/tool. And given the state of the maintainers, it's going to stay that way. So yes, when you have a tool that isn't better than any of your other tools for anything -- that means it's a bad tool.

Allen Short

Oh, and C++ is still the best tool for some purposes, which makes your parallel incomplete. Various people are working on building languages that can successfully compete with C++ in its remaining niches, so in another decade or two that may no longer be true.



  1. 2024
  2. 2023
  3. 2022
  4. 2021
  5. 2020
  6. 2019
  7. 2018
  8. 2017
  9. 2016
  10. 2015
  11. 2014
  12. 2013
  13. 2012
  14. 2011
  15. 2010
  16. 2009