What is the greatest design flaw you have faced in any programming language? [closed]

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.)

Answer 5

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) {
  x->doSomething();
}

Example (Java / C#) :

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

Answer 6

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.

Answer 7

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.

Answer 8

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

Answer 9

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.

Answer 10

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.)

Answer 11

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.

Answer 12

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.

Answer 13

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?

Answer 14

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.

Answer 15

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

Answer 16

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.

Answer 17

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.

Answer 18

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. :)

Answer 19

Coldfusion's nested CFLoop behavior.