Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

All programming languages are having their design flaws simply because not a single language can be perfect, just as with most (all?) other things. That aside, which design fault in a programming language has annoyed you the most through your history as a programmer?

Note that if a language is "bad" just because it isn't designed for a specific thing isn't a design flaw, but a feature of design, so don't list such annoyances of languages. If a language is illsuited for what it is designed for, that is of course a flaw in the design. Implementation specific things and under the hood things do not count either.


locked by World Engineer Mar 31 '13 at 15:35

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Mark Trapp Oct 7 '11 at 20:50

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Note that this is constructive for language designers (mistakes to avoid), if someone would like to question how constructive this question is. – Anto Mar 5 '11 at 16:08
Obvious dupe of… – greyfade Mar 5 '11 at 16:33
@greyfade: Not really, this are about flaws in the actual language, that seems to be about things which lower adoption of a language, which could include bad standard library or just a bad website for the language. Some answers list e.g. bad syntax, but that isn't a specific design flaw – Anto Mar 5 '11 at 16:54
Greatest flaw in any programming language? Humans. – Joel Etherton Mar 7 '11 at 12:42
If these answers are the greatest flaws, then I'm really impressed by programming languages. – Tom Hawtin - tackline Mar 12 '11 at 19:27

49 Answers 49

Mine has to be UMTA Specification Language, a macro language that translated into ANSI Fortran. USL use of blanks was hideous.

USL would allow a blank in a name. So instead of "LASTTANGO" you could name your macro "LAST TANGO". But this could also mean a macro "LAST" followed by another macro named "TANGO". Read code like "LAST TANGO IN PARIS" and the combinatorial possibilities are horrid.

USL did not use begin/end or {} to indicate subsidiary code, it used spacing. Following an IF statement, all lines that were indented more than the IF statement were conditional upon that IF. Sounds easy, eh? But try tracking conditionals through several pages; try adding an ELSE with exactly the right indentation.

USL was born and died in a U.S. government agency back around 1980.

Python seems to be doing quite well with indenting that represents block structure. But thankfully it doesn't allow spaces in identifiers! – Greg Hewgill Mar 6 '11 at 2:40
Side note: the possibilities aren't combinatorially horrid, they're just exponentially horrid. – Jon Purdy Mar 8 '11 at 0:13
@Jon: Andy said that "the combinatorial possibilities are horrid", where "combinatorial" is an adjective modifying the noun "possibilities". He didn't say that "the possibilities are combinatorially horrid", where "combinatorially" is an adverb modifying the adjective "horrid". (Firefox is saying that "combinatorially" is spelled wrong.) He didn't say anything about how horrid the possibilities were. – compman Mar 9 '11 at 23:52
@user9521: You're right, but I wasn't correcting, just adding more information. – Jon Purdy Mar 10 '11 at 4:35
Time flies like an arrow. – Ed Staub Oct 7 '11 at 16:48

Perl's flattening of lists... Conversely, it's also one of it's best features.


In old Ultima Online/sphere server scripting...there was no divide at all or decimal points, though the game itself obviously used them. You could make a somewhat crude divide function but just barely.

It is difficult to say how much of a train wreck that one flaw made the whole language extremely cumbersome.


C++'s making objects value types instead of reference types, and thereby ruining the chance to implement object-oriented programming in any sane way. (Inheritance and polymorphism simply don't mix with statically-allocated, fixed-size, pass-by-value data structures.)

Plus, all the concern about correctly implementing copy constructors, operator=, and std::swap specializations just doesn't exist in a reference semantics language. – dan04 Mar 6 '11 at 19:05
@dan04: Wrong; the same issues are there (except for swap). They're just approached differently, with issues like assignment vs. cloning. The difference between having two pointers to the same thing and two pointers to two different but identical things doesn't go away by changing the language. – David Thornley Mar 7 '11 at 19:16
@David: In a reference-semantics language, a lot of objects just don't need to be copied. This includes any immutable type. – dan04 Mar 8 '11 at 0:43
@dan04: Correct: "a lot of objects". As long as you can use immutable types only (and C++ is not really a functional language), you're in great shape, and you don't have to worry about C++ copy constructors or assignment operators because the compiler-generated ones will work fine. The reason to write your own is normally that the object manages some sort of resource, and in that case there will be a difference between two pointers to the same thing and two pointers to different things. – David Thornley Mar 8 '11 at 15:53
"Reference types everywhere" and "systems programming language, garbage collection may not be available" don't mix. (It's not a coincidence that almost all languages that follow your prescription rely on garbage collection.) There would have been a much better case for omitting inheritance (an overrated feature) from C++. – rwallace Aug 25 '11 at 15:54

Java, PHP, C#, Delphi, Vala: mixing "pointers to objects" versus "plain objects", what is usually called "references". In C++, and Object Pascal, you can create objects as static variables, and objects as dynamic variables, using pointer syntax.

Example (C++) :

x = new XClass();   
x->y = "something";
if (x == null) {

Example (Java / C#) :

x = new XClass();
x.y = "something";
if (x == null) {

In non-Java like languages. The concept of "GOTO" or Jumping. Being able to jump around the code in a non-linear way is perhaps the most ill-logical feature in any written language.

This has been the most misused and irrelevant concept. Once I see one of these in a 300 line function I know I'm in for a cooking lesson for spaghetti. The exception is error handling. This is the only acceptable use of the concept of jumping

It breaks good modern programming practices. Goto's are only acceptable for the purpose of error trapping. Not a lazy way to terminate loops or skip code.

Writing code is an art form that should is oriented for readability. Among many aspects for readability is linear execution. One entry point, one exit for any function, and it must flow down the page, no jumps or goto's.

Not only does this make the code more readable, it also by it's very nature helps you write higher quality code. One hack begets another and another. You'll generally find that once goto's are misued, you also get multiple exit statements out of functions. Tracing conditions and logic for testing becomes infinitely more difficult and immediately reduces the robustness of any code you may produce.

I wish Goto's would be banished forever, they were used in Assembly coding years ago, and that is where they should remain.

@SK-logic Generally speaking, would a GOTO be better replaced by a function call? – Mark C Mar 13 '11 at 16:06
@Mark C, no, of course not! See the state machine example - it will be severely obscured, and a potential for optimisation will be damaged. Also, it will make it even harder for higher level languages compilers to target a language that way. – SK-logic Mar 13 '11 at 16:49
@SK-logic Yes, but in the cases that GOTOs call reusable code, it is a function call with only slightly different syntax, right? I do not completely understand your example (FSM), but I understand intuitively that sometimes a lack of GOTOs could obscure program flow. I think you mean the case where the called block has GOTOs to other parts of the program. (Could you get equivalent functionality if function calls optionally did not return program control to the caller?) It seems GOTOs have two uses---function calls and control flow. – Mark C Mar 13 '11 at 20:12
@Mark C, in order to simulate goto behaviour with function calls, you'd have to translate the code into an SSA-form, then transform all the basic blocks into tiny functions with numerous parameters, each performing a tail-call of another basic block function. Firstly, it is a mess, and secondly, tail calls are not supported by many languages and runtimes. Actually, this transform is a great tool for reasoning about an imperative code with goto-s or any other control flow constructions (which should be lowered to goto first). – SK-logic Mar 13 '11 at 20:53
@SK-logic I want to say this without being critical of people: Not everyone has the same standard or background when they write programs. – Mark C Mar 14 '11 at 2:38

The biggest flaw often seen in many programming languages is inability to 'bootstrap' - often it's not possible or practical to implement the language and its libraries using only that language itself.

When this is the case, language designers (and implementors) are skipping the hard part of making the language useful for really interesting and challenging tasks.

I remember seeing an ad campaign for a COBOL compiler, claiming it was written in itself. I thought that a bit excessive. – David Thornley Mar 11 '11 at 21:04
@DavidT DEFINITION COBOL. ARRAY OF CHARACTERS: {'C', 'O', 'B', 'O', 'L'}. (mostly-made-up syntax) – Mark C Mar 13 '11 at 20:18

Cramming array, list and dictionary into one abomination called PHP's "associative arrays".

Why do you consider this combo an abomination? – rwallace Aug 25 '11 at 15:57
because they are completely different data structures of distinct characteristics. – vartec Aug 25 '11 at 21:58
If you don't like this then you should probably avoid Lua as well. – finnw Nov 21 '11 at 3:00

I have two things which I dislike in C++,

Implicit conversion to bool (this is made worse by the fact that you can implement conversion operators for types such as operator int() const {...})

Default parameters, yes it aids backward compatibility of interfaces when adding new stuff, but then so does overloading - so why do this?

Now combine the two together you have a recipe for disaster.

+1 for implicit conversion to bool. It allows to write a class A with a conversion operator to bool, a function foo() with return type; and then if (foo()). When I found an example of this in some legacy code I thought foo() were just testing a condition. Instead it was constructing an object and was being misused to test if that object could be constructed or not. Very hard to read! – Giorgio Oct 7 '11 at 17:25

In C, and inherited by C++, Java, and C#:

You cannot parse the language without building a symbol table. Because code like this:

Foo Bar();

could be declaring a variable Bar of type Foo and calling the default constructor, or could be declaring a function Bar that returns a Foo and takes no arguments. (In C++, anyway. The others have similar flaws.)

This means you can't parse these languages without building a symbol table, making analysis tools much harder to write.

(Javascript and Go manage to avoid this problem.)


The m4 macro language lacks a loop construct. Instead, the documentation recommends that you create your own using recursion. That kept me from bothering with the language, pretty much for ever.


Probably not the greatest design flaw but a flaw nonetheless in my opinion...

The keyword final in the context of variables is Java.

I wish there was a non-final / mutable / rassignable keyword instead to indicate that the reference to a variable can be changed.

Good practices suggest that you should use the keyword final liberally in all cases especially when you are writing multi-threaded applications.

I follow this advice and use the final keyword whenever I can. It is very rare that I need a variable to be non-final. This makes my source code a lot more cluttered and forces me to type more than I really should have to.


The decision to implement the goto operator in PHP 5.3.
What reason could there possibly be to encourage bad programming practices that were -wisely- not implemented in previous versions?

Overzealous goto bashing amuses me. It is not a bad programming practice, it is an essential form of control flow. PHP code is often generated rather than hand-written, and for a compilation target language goto is a must-have. – SK-logic Mar 7 '11 at 11:56
goto is only essential in languages that lack exceptions, and very essential in languages that lack while, else, switch, etc. (like old line-numbered BASIC). – dan04 Mar 7 '11 at 14:45
@dan04, exceptions are not a substitute for a goto. Think of implementing a state machine efficiently with no goto. And it is quite a common pattern when compiling from some higher level language. Many other thigs are also much easier to compile if your target language provides a proper goto, and can be a hell if only a structural control flow is available. – SK-logic Mar 7 '11 at 15:07

Lack of array handling for input variables in SQL. Even when a database vendor has added on a feature to support this (I'm looking at you, SQL Server), it can be poorly designed and awkward to use.


Delphi / Pascal language don't allow multiline strings without using concatenation.


Javascript's omission of many of the date formatting and manipulation functions that almost every other language (including most SQL implementations) have has been a source of frustration for me recently.


Optional paramaters in VB. When adding features to code is is too easy to do it as an optional parameter, then another, then another, so you end up with all these parameters that are only used in newer cases that were added after the initial code was written, and probably aren't called at all by older code.

Thankfully this was solved for me by switching to C# and using overloads.


RoboCom, whose assembly language lack for bitwise operations.

While it hardly counts as any productive language with any real value other than learning and entertainment, RoboCom is a game where you are programming virtual robots to participate in a code battles. Programmers have to make most use of clock cycles to make their move before their opponent do.

If a language is illsuited for what it is designed for, that is of course a flaw in the design.

I found it quite irritating for a language to lack bitwise operations, especially when the goal of the game is elimination by optimization. That in my books, is a real design flaw, since many optimizations can be made using bitwise operations.

Wish I could have contributed something slightly more useful. :)


Coldfusion's nested CFLoop behavior.


protected by Adam Lear Mar 8 '11 at 3:28

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.