Is there such thing as a bad programming language?

I've heard a lot of people complain about some of the older programming languages like Perl.But I don't really know what makes a programming language bad besides syntax. Does anyone here know what constitutes a bad programming language?

Comments

[Dian Fay]

When people say a programming language is "bad", what they mean is that it's difficult for them to do what they want to accomplish with it or that they have aesthetic objections to how programs are written and structured in it. There are some cases where most people agree (MUMPS is nigh-universally abhorred), but it's still fundamentally a matter of opinion.

[Raji Ayinla]

That makes sense. I also feel like trends also may shape a particular view of a language. Now that you have Swift, which was supposed to replace Objective C, you might get blogs that say Objective C is the worst programming language to learn.

But you're right that's just opinion.

[Michael K Gremillion]

I work with a program using MUMPS, and while I don't do any actual development in MUMPS, I'm exposed to some of it through in-app "programming points" and I can't fathom how MUMPS programmers keep their sanity.

[Dustin King]

It's extremely subjective and situational, but there are a lot of metrics that one could apply (though there's not necessarily an objective way to measure them), and if a language scores low on everything, one might call it "bad". But which metrics are important to you is going to vary quite a lot. Here are some I can think of:

• Manipulexity and whipupitude, Larry Wall's terms for what he was trying for with Perl: fine grained control plus the ability to create a useful program quickly.
• Usefulness for large teams or large projects
• Readability
• Succinctness (the ability to express the intent of the program with the fewest number of symbols)
• Performance
• Security
• Backward/forward compatibility (If I write something today, will it run a year from now? Ten years? 10,000 years?)
• Libraries/packages
• Welcoming culture
• Friendliness for beginners
• Ability to illustrate CS or programming concepts
• Ability to hire people who know it or are willing to learn it
• Ease of use for some problem domain (e.g. server-side web programming for PHP)

I'm probably forgetting some. But in general, if something scores low on all these (or at least the ones you care about), then you might be justified in calling it "bad". But then what you care about might not be what the language authors care about.

There are also deliberately "bad" languages like Brainfu*k and Intercal. But maybe they're good for their intended use, which might make them not really bad.

[Raji Ayinla]

Great post! Looking at your list it's easy to see how some may favor friendliness and strong community culture when they're just starting out with a language or programming in general.

On the other hand, more seasoned developers might bash that same language for its "syntactic sugar" and its slow compile time.

[Idan Arye]

The number one problem that makes a bad language is pitfalls. I define pitfalls as potential bugs that tend to get exposed only after they've done some damage. Usually because:

• It makes sense to expect it to work.
• It works in the simple cases.
• It doesn't work in more complex cases.
• Once you found out it doesn't work, you have already integrated it in your code - so you need to do lots of refactoring to fix it.

There are other reasons to not like a language, but most of them are a matter of personal taste. But I think everyone would agree that pitfalls are bad.

[Caleb Winston]

There's definitely a lot more than syntax - allowing objects to be null is a great example of a language design decision that has implications both in the syntax and the semantic.

Something like this in Kotlin...

manager = employee?.department?.head?.name

would look like this in Java...

manager = null;

if (employee != null) {
  if (employee.department != null) {
    if (employee.department.head != null) {
      manager = employee.department.head.name;
    }
  }
}

These examples make it clear that while null safety improves code readability, it can also increase the robustness of your software. A single change in a condition or accidentally using a value outside of its null check in the Java example can easily lead to errors at runtime.

[Thomas Werner]

This is why Java 8 introduced Optionals. It's not syntactic sugar so it's more verbose than the Kotlin example, but it does the same thing:

String manager = Optional.ofNullable(employee)
                         .map(Employee::getDepartment)
                         .map(Department::getHead)
                         .map(Person::getName)
                         .orElse(null);

[Caleb Winston]

Oh nice! I clearly haven't used Java in a while; I do still think the elvis operator looks a bit cleaner though.

[Thomas Werner]

Oh man... now I cannot unsee Elvis in the "Elvis operator" :-D

[Joe Mainwaring]

Programming Languages are tools for the job, no different than a screwdriver or wrench for a mechanic.

Can a tool be bad? Sure. It could be flawed from the start and always do a poor job. It could also do a poor job because it's being used incorrectly. It could also do a poor job because newer tools have come out that are easier to use or perform better.

At the end of the day, it really just comes down to understanding what you're trying to do, and picking the best tool you have at your disposal.

[Michael K Gremillion]

Well, you always have the "joke" programming languages, like Brainf@#$, Chef, etc. Are these languages "bad"?

I figure a language is "good" if it fulfills its intent, and does it well. So is Chef a bad programming language? It might be bad for practical use, but it expertly fulfills its intended niche (making programs that look like recipes).

I know that's a very broad definition, and there's probably nuances inside of it, but that's how I'd define a "bad programming language."

[Lukas Lukac]

Yes, the one developers are lazy to understand and master.