Erik McClure

Your Esoteric Language is Useless

You’d think that programmers would get over these ridiculous language wars. The consensus should be that any one programmer is going to use whatever language they are most comfortable with that gets the job done most efficiently. If someone knows C/C++, C#, and Java, they’re probably going to use C++ to write a console game. You can argue that language [x] is terrible because of [x], but the problem is that ALL languages are terrible for one reason or another. Every aspect of a languages design is a series of trade-offs, and if you try to criticize a language that is useful in one context because it isn’t useful in another, you are ignoring the entire concept of a trade-off.

These arguments go on for hours upon hours, about what exactly is a trade-off and what languages arguably have stupid features and what makes someone a good programer and blah blah blah blah SHUT UP. I don’t care what language you used, if your program is shit, your program is shit. I don’t care if you wrote it in Clojure or used MongoDB or used continuations and closures in whatever esoteric functional language happens to be popular right now. Your program still sucks. If someone else writes a better program in C without any elegant use of anything, and it works better than your program, they’re doing their job better than you.

I don’t care if they aren’t as good a programmer as you are, by whatever stupid, arbitrary standards you’ve invented to make yourself feel better, they’re still doing a better job than you. I don’t care if your haskell editor was written in haskell. Good for you. It sucks. It is terribly designed. It’s workflow is about as conducive as a blob of molasses on a mountain in January. I don’t care if you are using a fantastic stack of professionally designed standard libraries instead of re-inventing the wheel. That guy over there re-invented the wheel the wrong way 10 times and his program is better than yours because it’s designed with the user in mind instead of a bunch of stupid libraries. I don’t care if you’re using Mercurial over SVN or Git on Linux using Emacs with a bunch of extensions that make you super productive. Your program still sucks.

I am sick and tired of people judging programmers on a bunch of rules that don’t matter. Do you know functional programming? Do you know how to implement a LAMP stack? Obviously you don’t use C++ or anything like that, do you?

These programmers have no goddamn idea what they’re talking about. But that isn’t what concerns me. What concerns me is that programmers are so obsessed over what language is best or what tool is best or what library they should use when they should be more concerned about what their program actually DOES. They get so caught up in building whatever elegant crap they’re trying to build they completely forget what the end user experience is, especially when the end user has never used the program before. Just as you are not a slave to your tools, your program is not enslaved to your libraries.

Your program’s design should serve the user, not a bunch of data structures.



You're definitely more right than you are wrong; however, there is definite value in using the "right" (best) tool for the task at hand. People just tend to focus too much on deciding when they're better of picking if they don't inherently know which to use.

Erik McClure

There is value in using a language for what it's designed to do, but if your program ends up being crap anyway, it doesn't matter. If your program is crap, then you should consider using a different language. If your program is really good, it doesn't matter what language you used because your program is *really good*, and critiquing a program based on what language was used to make it rather then the program itself is utter insanity, which is the main point here.


Bad code can be written in any language, of course. And a powerful language might even happily help you precisely express your bad ideas.

But languages are materials, not tools. Programs have a maintenance cycle, and the original author might not be around to maintain it. We'll often want to extend programs, reuse them. Languages are also maintained - new optimizations, bugfixes, portability, updates to libraries.

It is often reasonable to critique a program based on what language was used. But it is also quite reasonable to critique a program based on other qualities, such as end-user experience. Which qualities you'll weigh as most important probably depend on what you're doing with the program.

Erik McClure

I am arguing about someone literally trying to defend a program that is badly coded because it used a pretty language. I'm saying that while you CAN critique a program for being written badly, I have a very hard time taking you seriously if that program still works better than another elegantly written program that runs like shit.


What relevance is this to esoteric programming languages?



  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