We have all seen things like the typing system of JavaScript (There is a funny post including a truth table somewhere around here). I consider this one of the main things that makes a programming language bad.

Other things that spring to mind:

  • Bad Error messages (Either obfuscated so you can't figure out whats wrong, not existing or simply too long and red)

  • The language wasn't planned and just grew uncontrolled in all directions (PHP?)

  • The language encourages bad programm(er/ing) habits such as: Global variables everywhere, bad variable names

  • Inconsistent naming conventions inside the language

I can't come up with any more at the moment and would be very happy to read what you think about this.

  • What shouldn't be missing in a language created to be as bad (from the perspectives of the programmer, the company that hires to programmer, the team leader and the customer) as possible?

(I ask this because I'm designing a bad, experimental language at the moment)


Extreme limitations on program size combined with an ability to abbreviate keywords and identifiers to a single character. This combination existed in the MUMPS programming language which encouraged programs such as this from wikipedia:

       N S,N,T,I,K,Q S I="K",S="11",K="l1",Q="R",T="K"
       I I=T D T
       Q:$Q Q Q
T  I I,S&K S S=S+K Q

This language is used by the US military's healthcare databases, and this type of program is common practice and extremely difficult to read.


Don't know if this qualifies as bad, but PHP's function naming inconsistencies (and argument signatures) can be quite annoying.

Doesn't affect me too much, the docs are generally a short mouse's (?) throw away.


It's a bit unfair to blame PHP entirely. The ad hoc nature of the language hasn't helped it's design process. However, I wonder if we are too far gone to ever standardize the language? It would break a lot, but would the end justify the means?

But I still wonder why there is functioname, function_name and functionName. It may have something to do with the fact some functions are light wrappers for C functions (and following their naming convention), whilst others are PHP exclusive (and like to use the underscore to separate words).

I did read here on Stack Overflow someone's suggestion that PHP should use a more OO way to standardise functions (instead of the faux namespacing like array_*). Their suggestion was something like this

$array = range(1, 250);

$length = $array->length;

Of course, there are probably some pitfalls of this I haven't came across yet.


To my mind, what marks a truly bad production programming language is when it rewards bad and obscure programming, especially if it simultaneously makes it difficult to write good code. This is because it's just going to make life hell for some poor maintenance coder for no great benefit.

For example, PHP's "whimsical" approach to function naming and database access qualify it for the accolade. I'm not saying that you can't write good code in it, but time and time again it is at the focus of hacked webservers. Once is happenstance, twice is coincidence, three times is enemy action, and tens of thousands of times across the whole world is just utterly inexcusable. Something must be rotten in the state of Denmark?


Inconsistency in the language syntax and special-cases.

Making good coding habits harder than they should be.


I'd go for extreme verbosity.

Make every single thing you want to do in your language overly verbose (without adding extra functionality).

Note that I'm not making any references to existing languages in use today.


Bad programming languages may have a messy language syntax that isn't expressible easily in a simple grammar. I think early versions of Basic, Fortran suffered from this, and Cobol too. Pascal was one of the first to have a grammar nicely expressible in BNF (Backus-Naur Form) and since then most languages do so.

Another point is the language should not be too ad hoc or idiosyncratic. I think Cobol suffers the most from this.

The language should be powerful and expressive, i.e. able to represent objects, recursive functions, expressions easily. Cobol did not do this, and C didn't have a representation for objects, but then again I view C++ as the improved C with object support :)


Pascal assignment operator := :)


Bad programming language are not tools.

Sometimes they are just toys.


I would say that the "easier" it is for newbies to write bad code, the worst the language is. For example VB, VBA and javascript fall into this category. In the right hands, all of them are powerful tools.

But a lot of tutorial websites and book make it look "easy" to write code, then we get some screwed up javascript all over the place


Encouraging (or even relying on!) the use of gotos.

Unclear difference between literals and variables. Example: goto L

If you're wondering, I was just messing around with TI-Basic (For the TI-84+). And that goto L goes to the label "L", while I would expect it to go to whatever label the variable L holds.

I'd like to add on to the goto part of this answer. If you're going to design a language that relies on gotos, it can still be a good language. After all, as pointed out by commenters, assembly uses the equivalent of gotos. But it should still be capable of everything that an assembly jump can do. You should never force your users to type something as ridiculous as:

:If LBL="LBL1"
  :Goto LBL1
:If LBL="LBL2"
  :Goto LBL2
:If LBL="LBL3"
  :Goto LBL3

As a side-note, does anybody know of any alternatives to TI-Basic (where you can program on your calculator, not program on your computer and upload it to your calculator), such as an on-calc assembler?


I'd say that programming languages that don't support things for no reason (Haskell: variables, PHP: variables beginning with something that isn't $) or don't support things that they really need to (Javascript: static types) for example.

Programming languages need to be practical for purpose above all else, and dynamic typing in a fully object-orientated environment is a BAD idea.