What one feature would you cut from your favorite language?

Question

It's easy to think of features to add to a language. What feature would you cut from a language, and why?

Douglas Crockford says don't use JavaScript's "with" statement. What are the hazard areas in other computer languages? What features have you seen get in the way of software engineering?

Answer 1

Checked exceptions in Java.

Answer 2

Protected implies package private access in Java.

Answer 3

Magic quotes in PHP (to be deprecated in PHP 6).

Answer 4

goto statement in c/c++

Answer 5

register_globals in PHP

Answer 6

I've heard people say that the ternary if

(exp) ? (exp) : (exp)

may lead to confusing/unreadable code and shouldn't be used.

Answer 7

Overloading of operator comma in C++. Some would say all operator overloads but some overloads are useful. Overloading operator comma is just a nightmare waiting to happen.

Answer 8

In SQL:

select *

Answer 9

Option Strict Off in Visual Basic .NET.

mutable local "variables" in F#.

*See this question

Answer 10

Another vote for checked exceptions in Java. If you include libraries are part of the language, I would have 100,000 more things to say ;)

Answer 11

In C#:

The goto case statements.

Answer 12

In C# and VB.NET :

I would remove XML Comments.

Problem : they are often quite messy on screen and pretty hard to maintain. I know it can be really handy for third-party developers and for Microsoft itself, but for the in-house projects I worked on (banking, insurances), it was really overkill and most comments were anyway useless (as before) or outdated. (Maybe Microsoft and 3rd-part developers could use a special edition ?)

Since it have been widely accepted that XML Comment were good, developers spend a lot of time juggling with XML attributes (and generating cool chm documents that no one ever read) and a little less time writing comments...

We were very happy to get Code Behind to seperate html from code. How could adding XML to code would be a better idea ?

:o)

Answer 13

The "functional" parts of Python, specifically zip/map/reduce/filter/lambda.

They have their uses (and I wouldn't actually suggest they be removed), but always seem to be mis- or over-used, instead of slightly more verbose, Python'ish methods.

Answer 14

In C/C++/Java:

Numbers starting with 0 are assumed to be octal. So 034 means decimal 28. Makes it too easy to specify octal values by mistake, since you might think you want to add a zero to line up a group of numbers.

Also, switch statement flow-through. If a case doesn't terminate with a break statement, it automatically flows through to the next case.

Answer 15

In C#, using.

When I first used it for consuming an ASMX based service, I thought it was great. But then I tried using it to consume a WCF service and discovered that there is a problem if the service throws an exception before it is completely set up in the using() clause, Dispose() still gets called on the invalid object and will throw another exception that masks the original exception.

Here is a good explanation http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx

Answer 16

The "switch" statement in Java. It was copied nearly intact from C, including the break/fallthrough nonsense, and it's just awful.

Answer 17

Array covariance in C# (and in .Net generally).

Answer 18

Silent/Implicit destructive conversions between data types in C/C++.

int i = 5.6; // well-formed

Answer 19

in SQL (especially in PL/SQL): INSERT statement without column list. Breaks when a new column is added to the table.

Answer 20

I hate how JavaScript adds a semicolon to the end of lines if you don't do it.

Answer 21

Bad type systems need to go:

<?php echo (3 == '3 little pigs') ? 'True' : 'False'; ?>

I shake my head when I see this return 'True'.

Answer 22

From C, bitfields, because they aren't endian clean, and technically are even compiler dependent (though in practice, it tends only to be endian differences that you actually run into.)

Answer 23

The C++ export keyword. Because it seems to be of very limited use, and because Herb Sutter says so.

Answer 24

Java, and definitely container managed persistence EJBs.

Answer 25

null pointers/references, in pretty much any language that has them.

Answer 26

In Perl, inconsistent rules on using parenthesis.

When you print, you can use parenthesis or not:

print("Hello, world!\n");

print "Hello, world!\n";

But if you print to a filehandle, you can't use them:

print FILE "Hello, world!\n";

(This also brings up the awkward syntax for printing to files - look, Ma, no comma! - but that's not what this post is about.)

However, flow control statements must have parenthesis:

while(1) {

...unless you use postfix notation:

dosomething() while(1);

dosomething() while 1;

Personally, I'm a fan of dropping the parenthesis altogether, except when you need them to resolve ambiguities (which is what parenthesis are for) and typing:

while 1 {

Because we all know that anything after the while and before the { is the condition.

Answer 27

In .NET, Try / Catch needs a re-think. It's too easy to hide code from yourself and create circumstances where things don't do what you think they should.

Shamelessly stolen from http://www.joelonsoftware.com/articles/Wrong.html , but its stuck with me.

Answer 28

The comma operator in C. Guess what this does:

SomeFunction(1, 2, 3);

Answer 29

Not requiring {}'s for if / for's etc in C / C++

if( true )
{
     dostuff();
     return 1;
}

Without braces:

if( true )
    dostuff():
    return 1;

Will still work, but when you go to add more code below you will run into problems.

Answer 30

Not a true language feature but, I would get rid of /* */ comments in C++ and C# as code in them shows up in searches without an indication that it is not used.

I would also get rid of most conditional compilations within a file in C++ - many times the code can be structured better to get the same effect.

Answer 31

extract() in PHP. A horrible, horrible function.

Answer 32

In C++:

1. local functions declarations (if only one allowed, this will be this one)
2. goto
3. macros

Answer 33

Java: maintaining backwards compatibility at all costs. It would free the designers and implementors from a huge burden and allow the language to evolve more gracefully.