DEV Community

Raji Ayinla
Raji Ayinla

Posted on

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?

Top comments (13)

Collapse
 
dmfay profile image
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.

Collapse
 
realrayinla profile image
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.

Collapse
 
mkgremillion profile image
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.

Collapse
 
cathodion profile image
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.

Collapse
 
realrayinla profile image
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.

Collapse
 
idanarye profile image
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.

Collapse
 
calebwin profile image
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.

Collapse
 
tiguchi profile image
Thomas Werner • Edited

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);
Collapse
 
calebwin profile image
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.

Thread Thread
 
tiguchi profile image
Thomas Werner

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

Collapse
 
theaccordance profile image
Joe Mainwaring • Edited

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.

Collapse
 
mkgremillion profile image
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."

Collapse
 
web3coach profile image
Lukas Lukac

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