The Daily WTF: Curious Perversions in Information Technology

2005-10-21 Reply Admin

kipthegreat:

Now that I think about it, Integer.parseInt("3").toString() would never compile... Integer.parseInt("3") is an int, which is primitive, so .toString() couldn't compile....

Autoboxing in Java (1.)5 would fix that, I think :D

masklinn · 2005-10-21 Reply Admin

llxx:
"Magic numbers"? This example looks a bit too artificial.

Regarding hard-coded values, what I do is just hard-code them in when they aren't likely to be changed and use defines when they are. Converting a string to an int? I hardly see the advantages of this scheme.

Yup, and when another coder comes to maintain your code and has no idea what those fucking magic numbers mean he's fucked to the core.

Oh, the fun

ray:
Anyway as I said, this is the reason we have the .equals() funtion in java, as it allows us to compare the contents of an object as opposed to "= =" that will compare the objects themselves to see if they are in fact the same object.

No, your have the ".equals" method because

Java sucks
Java has no operator redefinition (which is part of point 1)
Java claims to be a high level language but its abstractions leak all over the place (ah well, part of point 1 too, but worth noting)

2005-10-21 Reply Admin

And as we do in .Net ...

masklinn · 2005-10-21 Reply Admin

Anonymous:
kipthegreat:

Now that I think about it, Integer.parseInt("3").toString() would never compile... Integer.parseInt("3") is an int, which is primitive, so .toString() couldn't compile....

Autoboxing in Java (1.)5 would fix that, I think :D

No, and there is no reason to, autoboxing will box a primitive type in it's object for argument passing, it won't even try for methods accessing.

>javac -version
javac 1.5.0_02
class Dummy {
static public void main(String[] args) {
System.out.println(Integer.parseInt("3").toString());
}
}

javac -Xlint Dummy.java
Dummy.java:3: int cannot be dereferenced
System.out.println(Integer.parseInt("3").toString());
^
1 error

class Dummy {
static public void main(String[] args) {
System.out.println(new Integer(Integer.parseInt("3")).toString());
}
}

javac -Xlint Dummy.java

Autoboxing in action (same compiler):

class Dummy {
    static public void test(Integer thing) {
        System.out.println(thing.toString());
    }
    static public void main(String[] args) {
        int testInt = Integer.parseInt("3");
        Dummy.test(testInt);
    }
}

javac -Xlint Dummy.java


java Dummy
3

ray · 2005-10-21 Reply Admin

masklinn:
llxx:
"Magic numbers"? This example looks a bit too artificial.

Regarding hard-coded values, what I do is just hard-code them in when they aren't likely to be changed and use defines when they are. Converting a string to an int? I hardly see the advantages of this scheme.

Yup, and when another coder comes to maintain your code and has no idea what those fucking magic numbers mean he's fucked to the core.

Oh, the fun

ray:
Anyway as I said, this is the reason we have the .equals() funtion in java, as it allows us to compare the contents of an object as opposed to "= =" that will compare the objects themselves to see if they are in fact the same object.

No, your have the ".equals" method because

Java sucks

Java has no operator redefinition (which is part of point 1)

Java claims to be a high level language but its abstractions leak all over the place (ah well, part of point 1 too, but worth noting)

lol, if only everyone was as passionate, perhaps we wouldnt need this site.....
(*slips into quiet contemplation*)

ray · 2005-10-21 Reply Admin

masklinn:

Anonymous:
kipthegreat:

Now that I think about it, Integer.parseInt("3").toString() would never compile... Integer.parseInt("3") is an int, which is primitive, so .toString() couldn't compile....

Autoboxing in Java (1.)5 would fix that, I think :D

No, and there is no reason to, autoboxing will box a primitive type in it's object for argument passing, it won't even try for methods accessing.

>javac -version
javac 1.5.0_02

class Dummy {
    static public void main(String[] args) {
        System.out.println(Integer.parseInt("3").toString());
    }
}

>javac -Xlint Dummy.java
Dummy.java:3: int cannot be dereferenced
        System.out.println(Integer.parseInt("3").toString());
                                           ^
1 error


class Dummy {
    static public void main(String[] args) {
        System.out.println(new Integer(Integer.parseInt("3")).toString());
    }
}

>javac -Xlint Dummy.java
>

Autoboxing in action (same compiler):

class Dummy {
    static public void test(Integer thing) {
        System.out.println(thing.toString());
    }
    static public void main(String[] args) {
        int testInt = Integer.parseInt("3");
        Dummy.test(testInt);
    }
}

>javac -Xlint Dummy.java

>java Dummy
3

>

I do need to agree:

C:\test.java:5: int cannot be dereferenced

System.out.print(Integer.parseInt("3").toString());
^

1 error

Which leads me to believe that todays post is entirely finctional, that is to say that the following makes no sense: 'John was maintaining a client management system written a few years before his time ..' as the code could never have compiled in the first place.

2005-10-21 Reply Admin

While I cannot confirm this particular example, I'm know programmers who have comparable habits. For example, they say "global variables are bad" and the build incredible complex constructs to imitate the semantics of global variables (but of course it's not better at all, since it is the semantic that makes global variables bad)

And the things people come up with to avoid using a goto.

wtijsma · 2005-10-21 Reply Admin

masklinn:

Yup, and when another coder comes to maintain your code and has no idea what those fucking magic numbers mean he's fucked to the core.

Oh, the fun
ray:
Anyway as I said, this is the reason we have the .equals() funtion in java, as it allows us to compare the contents of an object as opposed to "= =" that will compare the objects themselves to see if they are in fact the same object.

No, your have the ".equals" method because

Java sucks
Java has no operator redefinition (which is part of point 1)
Java claims to be a high level language but its abstractions leak all over the place (ah well, part of point 1 too, but worth noting)

Ahhh finally Microsoft developers can say something back to the Java people...

They had keep it in for sooo long, but now they don't have to take it anymore! they're fed up with being toyed around and their names smuthered!

Mwohahahaaaahhaaaaarrrgh

[:P]

masklinn · 2005-10-21 Reply Admin

ray:
masklinn:
Anonymous:
kipthegreat:

Now that I think about it, Integer.parseInt("3").toString() would never compile... Integer.parseInt("3") is an int, which is primitive, so .toString() couldn't compile....

Autoboxing in Java (1.)5 would fix that, I think :D

No, and there is no reason to, autoboxing will box a primitive type in it's object for argument passing, it won't even try for methods accessing.
>javac -version
javac 1.5.0_02

class Dummy {
    static public void main(String[] args) {
        System.out.println(Integer.parseInt("3").toString());
    }
}

>javac -Xlint Dummy.java
Dummy.java:3: int cannot be dereferenced
        System.out.println(Integer.parseInt("3").toString());
                                           ^
1 error


class Dummy {
    static public void main(String[] args) {
        System.out.println(new Integer(Integer.parseInt("3")).toString());
    }
}

>javac -Xlint Dummy.java
>
Autoboxing in action (same compiler):
class Dummy {
    static public void test(Integer thing) {
        System.out.println(thing.toString());
    }
    static public void main(String[] args) {
        int testInt = Integer.parseInt("3");
        Dummy.test(testInt);
    }
}

>javac -Xlint Dummy.java

>java Dummy
3

>
I do need to agree:

C:\test.java:5: int cannot be dereferenced

System.out.print(Integer.parseInt("3").toString());
^

1 error

Which leads me to believe that todays post is entirely finctional, that is to say that the following makes no sense: 'John was maintaining a client management system written a few years before his time ..' as the code could never have compiled in the first place.

You failed for not reading the code

Original code never tries to send the "toString" message to the result of Integer.parseInt

caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString())</style>;

2nd version in case my l33t syntax highlighting has been borked up by the forum

caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString());

The result of Integer.parseInt is the argument of the elementAt method, and the toString message is in fact sent to the output of result.getResults().elementAt() which is an arbitrary object and therefore does feature a toString method.

ammoQ · 2005-10-21 Reply Admin

ray:

Which leads me to believe that todays post is entirely finctional, that is to say that the following makes no sense: 'John was maintaining a client management system written a few years before his time ..' as the code could never have compiled in the first place.

Better look again... the post is not parseInt("3").toString(), but result.getResults().elementAt(parseInt("3")).toString() - mind the parentheses

masklinn · 2005-10-21 Reply Admin

wtijsma:
Ahhh finally Microsoft developers can say something back to the Java people...

They had keep it in for sooo long, but now they don't have to take it anymore! they're fed up with being toyed around and their names smuthered!

Mwohahahaaaahhaaaaarrrgh

[:P]

I'm not even a MS dev ;)

masklinn:
You failed for not reading the code

Original code never tries to send the "toString" message to the result of Integer.parseInt
caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString());
2nd version in case my l33t syntax highlighting has been borked up by the forum
caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString());
The result of Integer.parseInt is the argument of the elementAt method, and the toString message is in fact sent to the output of result.getResults().elementAt() which is an arbitrary object and therefore does feature a toString method.

Yay, I don't even need the forum, managed to bork my post by myself.

Was supposed to be:

You failed for not reading the code

Original code never tries to send the "toString" message to the result of Integer.parseInt

caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString());

2nd version in case my l33t syntax highlighting has been borked up by the forum

caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString());

The result of Integer.parseInt is the argument of the elementAt method, and the toString message is in fact sent to the output of result.getResults().elementAt() which is an arbitrary object and therefore does feature a toString method.

brazzy · 2005-10-21 Reply Admin

Anonymous:
This is not true.

Yes, it is.

Anonymous:

The J2SE API Specification does not guarantee that an object is created for this method, nor does it guarantee that an object is not created. The argument that is passed to the method is taken from the constant pool (see VM Spec 4) and an "object is created" (it is indeed created - JLS 3.10.5 iirc)

That part of the JLS defines String literals. It has no bearing on this discussion at all.

Anonymous:

in the same way that one is created for all other String literals - simply, both code samples create an object at class load time (the class containing that constant pool), not one or the other.

No. The constant pool is created at class load time for Strings that consist of compile-time constants. These are defined in JLS (3rd edition) 15.28. Note that that list does NOT include method or constructor calls, but of it did, the constant folding would occur at compile time, not at class load time. So the "3" that occurs on both sides of the == will certainly be two references to the same object, which is created at class loading. The constructor and method call is executed at class loading if and only if it is part of a static initializer. Not if it is part of a constructor / instance initializer or method body. But what this discussion was about (as I understood it) was whether the return value of the toString() call would be the same object or a different one. It is not; try it out. The only way for it to be the same object would be if the toString() method used intern() on its result. This is, I have to admit, not explicitly forbidden by the JLS or the API spec, but I cannot imagine that any sane implementation does it, since it would lose a lot of performance for little or no gain.

Anonymous:

You may have been confusing that Integer.parseInt returns "something else" (an int) that is not the instance representing the passed String literal itself.

No, though it is embarassing that I did not notice that calling parseInteger() returns a primitive, which does not have a toString() method. Let's assume for further discussion that we are talking about

Integer.valueOf("3").toString()

instead.

Anonymous:

Here is a related topic to the one I believe was attempting to be highlighted.
http://jqa.tmorris.net/GetQAndA.action?qids=68&showAnswers=true

That is about the possibility of constant pool strings getting garbage collected and, again, has no bearing on this discussion.

Anonymous:

Oh, and if you want to argue, I implement the spec. as my day job :) but I'm always up for a constructive debate.

If you are really implementing the spec, I suggest you read it more carefully.

brazzy · 2005-10-21 Reply Admin

Anonymous:

I have nothing constructive to say. I simply want to note that this proves that it is one fscked-up language.

Nope. Quite the opposite, in fact. One of the great things about Java is that its specification is very complete (no undefined behaviour all over the place as in C/C++, google for "nasal demons") AND quite readable (compared to other language specs).

brazzy · 2005-10-21 Reply Admin

masklinn:

No, your have the ".equals" method because

Java sucks

Java has no operator redefinition (which is part of point 1)

Java claims to be a high level language but its abstractions leak all over the place (ah well, part of point 1 too, but worth noting)

No, this proves nothing whatsoever except that you personall dislike Java. Operator overloading is useless syntactic sugar that mainly serves to obfuscate code. And the difference between object value and identity is an important concept that a language hides to the programmer's detriment.

2005-10-21 Reply Admin

masklinn:

No, your have the ".equals" method because

Java sucks
Java has no operator redefinition (which is part of point 1)
Java claims to be a high level language but its abstractions leak all over the place (ah well, part of point 1 too, but worth noting)

brazzy:

No, this proves nothing whatsoever except that you personall dislike Java.

Try writing an OS in Java. hmmm...

brazzy:

Operator overloading is useless syntactic sugar that mainly serves to obfuscate code.

So, the STL is relies extremely heavy on an syntatic sugar. hmmm....

brazzy:

And the difference between object value and identity is an important concept that a language hides to the programmer's detriment.

Well yes, maybe Alternatively, you could be full of self-oppinionated shit

2005-10-21 Reply Admin

brazzy:
masklinn:

No, your have the ".equals" method because

Java sucks

Java has no operator redefinition (which is part of point 1)

Java claims to be a high level language but its abstractions leak all over the place (ah well, part of point 1 too, but worth noting)

No, this proves nothing whatsoever except that you personall dislike Java. Operator overloading is useless syntactic sugar that mainly serves to obfuscate code. And the difference between object value and identity is an important concept that a language hides to the programmer's detriment.

It is one thing to assert that a certain person merely hates the language, it is quite another to defend the lack of some feature merely because you have to in the face of rants against your pet language.

Operator overloading does NOT obfuscate code and is NOT useless syntactic sugar. Your statements are just as brazen and rash as the person you are quoting.

So get a life. Grow up and acknowledge the good in other languages like C# because it does not and will not devalue the worth and value of Java nor your job.

masklinn · 2005-10-21 Reply Admin

brazzy:
And the difference between object value and identity is an important concept that a language hides to the programmer's detriment.

The issue here is that rougly 95% of the time you'll want to test an object value, and Java gives you and object identity because they have "removed the pointers from the language, but in fact not and they'll come around to fsck your ass".

I'm sorry mate, but having to use a specific method to test if two string have the same value is not only not quite sane sane, but more or less specific to Java, I don't think that I've ever seen any other language with a standard, native string type (this means that C and assemblies are excluded, as they do NOT have native string types) behave that way.

There is no programmer detriment as long as the language behaves logically and follows the damn Principle Of Least Surprise that the Java devs seem to have forgotten quite a while ago, especially when you can still get (and test) object identity in the few cases you need to, once again with something a bit logical if you could.

masklinn · 2005-10-21 Reply Admin

Anonymous:
Try writing an OS in Java. hmmm...

Well Java has not been created to write OSes... And there actually is an OS-like thing in Java surprisingly called JavaOS

masklinn · 2005-10-21 Reply Admin

Oh, and BTW the fact that the language has an awful lot of specifications everywhere does not mean that it's not fucked up. There is no relation whatsoever between them.

brazzy · 2005-10-21 Reply Admin

masklinn:
Oh, and BTW the fact that the language has an awful lot of specifications everywhere does not mean that it's not fucked up. There is no relation whatsoever between them.

Your first sentence is correct, but the second is not. Undefined behaviour is the source of a lot of fuckups, so I'd certainly say that a language that has lots of undefined behaviour is in itself fucked up.

brazzy · 2005-10-21 Reply Admin

Anonymous:
brazzy:

No, this proves nothing whatsoever except that you personall dislike Java.

Try writing an OS in Java. hmmm...

And what does that have to do with anything?

Anonymous:
brazzy:

Operator overloading is useless syntactic sugar that mainly serves to obfuscate code.

So, the STL is relies extremely heavy on an syntatic sugar. hmmm....

It would work just fine (if not better) and be just as useful if it used methods instead of all overloaded operators.

brazzy · 2005-10-21 Reply Admin

masklinn:
brazzy:
And the difference between object value and identity is an important concept that a language hides to the programmer's detriment.

The issue here is that rougly 95% of the time you'll want to test an object value, and Java gives you and object identity because they have "removed the pointers from the language, but in fact not and they'll come around to fsck your ass".

Nobody remotely competent ever claimed that Java had no pointers - one of the most common errors you see isn't called NullPointerException for nothing. What it does not have is pointer arithmetic - and good riddance.

masklinn:

I'm sorry mate, but having to use a specific method to test if two string have the same value is not only not quite sane sane, but more or less specific to Java, I don't think that I've ever seen any other language with a standard, native string type (this means that C and assemblies are excluded, as they do NOT have native string types) behave that way.

There is no programmer detriment as long as the language behaves logically and follows the damn Principle Of Least Surprise that the Java devs seem to have forgotten quite a while ago

Actually I'd say that Java does exactly that (behave logically and follow the principle of least surprise) in exactly this point. == compares identity for all objects and Strings are objects. And you won't be surprised by an innocent-looking overator resulting in a potentially very costly value comparison.

brazzy · 2005-10-21 Reply Admin

Anonymous:

It is one thing to assert that a certain person merely hates the language, it is quite another to defend the lack of some feature merely because you have to in the face of rants against your pet language.

Operator overloading does NOT obfuscate code and is NOT useless syntactic sugar.

Yes, it is. Let's look at it in detail:

1. it's syntatctic sugar - simple fact.

2. it is useless - Not 100% true, but 95%. The only advantage it offers is terser code, but this is actually a grave DISadvantage (see 3.) unless the operator's meaning is ovbious and/or well-known to everyone who reads the code. This is the case only for mathematics, and only for the small subset of mathematics where ASCII symbols are used. There's a reason why nearly everyone arguing the usefulness of operator overloading will use the same example (complex numbers).

3. it obfuscates code - operators are less descriptive than method names in nearly all cases, and implicity operator precedence is a minefield. Yes, it allows you to cram more mode on one line. No, that's not a good thing.

RevMike · 2005-10-21 Reply Admin

brazzy:

Actually I'd say that Java does exactly that (behave logically and follow the principle of least surprise) in exactly this point. == compares identity for all objects and Strings are objects. And you won't be surprised by an innocent-looking overator resulting in a potentially very costly value comparison.

Brazzy is right on the money here. The == operator always compares the equality of the primitive values on its left and right. Those primitive values may be traditional primitive data types such as int and char, or they may be Object References, something akin to pointers. Why should anyone expect anything different? The people that don't understand this probably never grasped that C and C like languages only support pass by value, and never do pass by reference.

The fact that other languages allow a programmer to redefine an equality operator between two pointers is a definite wtf.

masklinn · 2005-10-21 Reply Admin

RevMike:
The fact that other languages allow a programmer to redefine an equality operator between two pointers is a definite wtf.

Other languages usually don't let you use pointers, you only get references (which are definitely not pointers), and in dynamic languages a reference is meaningless and the object is the value (pointed to by the reference)

Oh, and most high level languages do not give you access to primitive types, ever.

2005-10-21 Reply Admin

OneFactor:
Anonymous:
If I close my eyes and count to Integer.parseInt("10")).toString(), maybe it will go away. ;^)

But keep in mind that counting to Integer.parseInt("010") is not the same as counting to 010. [H]

But is your 010 a big endian or a little endian?

TheRider · 2005-10-21 Reply Admin

masklinn:
Oh, and most high level languages do not give you access to primitivetypes, ever.

Righto. One of the greatest problems of the Java language (and I am using it for several years now) is the fact that it distinguishes between primitive types (such as 'int') and and their object counterparts (i.e. 'Integer'). The latter are only needed to wrap primitive types to be able to store them in Vectors and Hashmaps and the like. The former are needed to do calculations on them. Thus requiring constant type casting back and forth. The new autoboxing feature actually aggravates the situation, for now what's happening behind the scenes becomes more opaque.

The primitive types lift the need for objects to know about operators. But that 'advantage' comes in at a very high cost, boy! I would much rather have Integer objects know how to calculate, instead of all the hassle with casting back and forth between objects and primitive types.

OneFactor · 2005-10-21 Reply Admin

Anonymous:
brazzy:
masklinn:

No, your have the ".equals" method because

Java sucks
Java has no operator redefinition (which is part of point 1)
Java claims to be a high level language but its abstractions leak all over the place (ah well, part of point 1 too, but worth noting)

No, this proves nothing whatsoever except that you personall dislike Java. Operator overloading is useless syntactic sugar that mainly serves to obfuscate code. And the difference between object value and identity is an important concept that a language hides to the programmer's detriment.

It is one thing to assert that a certain person merely hates the language, it is quite another to defend the lack of some feature merely because you have to in the face of rants against your pet language.

Operator overloading does NOT obfuscate code and is NOT useless syntactic sugar. Your statements are just as brazen and rash as the person you are quoting.

So get a life. Grow up and acknowledge the good in other languages like C# because it does not and will not devalue the worth and value of Java nor your job.

I love java for many reasons but the .equals operator is a major pain in the @$$ because it yaks on nulls. The == operator in C# behaves correctly for nulls. I don't mind writing good old:

public static boolean isEqual(Object o1, Object o2) {
return o1 == null ? o2 == null : o1.equals(o2);
}

But what I do mind is going through gobs of other people's code and making it call this method which should be part of the basic syntax of the java language.

Maurits · 2005-10-21 Reply Admin

OneFactor:

public static boolean isEqual(Object o1, Object o2) {
return o1 == null ? o2 == null : o1.equals(o2);
}

Hmmm... the SQL programmer in me wants to rewrite this as:
public static boolean isEqual(Object o1, Object o2) {
return o1 == null ? false : o1.equals(o2);

}

But the C programmer in me wants to rewrite this as:
public static boolean isEqual(Object o1, Object o2) {
return o1 == o2 ? true : o1.equals(o2);

}

Maurits · 2005-10-21 Reply Admin

Maurits:

But the C programmer in me wants to rewrite this as:
public static boolean isEqual(Object o1, Object o2) {
return o1 == o2 ? true : o1.equals(o2);

}

The C programmer in me is an idiot.
public static boolean isEqual(Object o1, Object o2) {
    if (o1 == o2) { return true; } // null == null is true, dammit
    if (o1 == null) { return false; } // null == anything-else is false; null != ""
    return o1.equals(o2);

}

2005-10-21 Reply Admin

brazzy:
Anonymous:
This is not true.

Yes, it is.

Anonymous:

The J2SE API Specification does not guarantee that an object is created for this method, nor does it guarantee that an object is not created. The argument that is passed to the method is taken from the constant pool (see VM Spec 4) and an "object is created" (it is indeed created - JLS 3.10.5 iirc)

That part of the JLS defines String literals. It has no bearing on this discussion at all.

Anonymous:

in the same way that one is created for all other String literals - simply, both code samples create an object at class load time (the class containing that constant pool), not one or the other.

No. The constant pool is created at class load time for Strings that consist of compile-time constants. These are defined in JLS (3rd edition) 15.28. Note that that list does NOT include method or constructor calls, but of it did, the constant folding would occur at compile time, not at class load time. So the "3" that occurs on both sides of the == will certainly be two references to the same object, which is created at class loading. The constructor and method call is executed at class loading if and only if it is part of a static initializer. Not if it is part of a constructor / instance initializer or method body. But what this discussion was about (as I understood it) was whether the return value of the toString() call would be the same object or a different one. It is not; try it out. The only way for it to be the same object would be if the toString() method used intern() on its result. This is, I have to admit, not explicitly forbidden by the JLS or the API spec, but I cannot imagine that any sane implementation does it, since it would lose a lot of performance for little or no gain.

Anonymous:

You may have been confusing that Integer.parseInt returns "something else" (an int) that is not the instance representing the passed String literal itself.

No, though it is embarassing that I did not notice that calling parseInteger() returns a primitive, which does not have a toString() method. Let's assume for further discussion that we are talking about

Integer.valueOf("3").toString()

instead.

Anonymous:

Here is a related topic to the one I believe was attempting to be highlighted.
http://jqa.tmorris.net/GetQAndA.action?qids=68&showAnswers=true

That is about the possibility of constant pool strings getting garbage collected and, again, has no bearing on this discussion.

Anonymous:

Oh, and if you want to argue, I implement the spec. as my day job :) but I'm always up for a constructive debate.

If you are really implementing the spec, I suggest you read it more carefully.

I was referring to the statement: "Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:"
This is indeed untrue. No "object is created" in one and not the other [refer to J2SE API Specification java.lang.Integer.parseInt(java.lang.String)] unless of course, you're referring to object created at class load time, which is created in both (whichever way you look at it, the statement is false).
The remained of your ranting appears to be a paraphrase of the spec., which is close enough to correct to bother about.
For those interested, here is some fun related to constants:
http://jqa.tmorris.net/GetQAndA.action?qids=13

2005-10-21 Reply Admin

Not if it is part of a constructor / instance initializer or method body. But what this discussion was about (as I understood it) was whether the return value of the toString() call would be the same object or a different one. It is not; try it out. The only way for it to be the same object would be if the toString() method used intern() on its result. This is, I have to admit, not explicitly forbidden by the JLS or the API spec, but I cannot imagine that any sane implementation does it, since it would lose a lot of performance for little or no gain.

This is true to some extent. I'll bet that "you're" implementation indeed returns false for Integer.parseInt("3").toString() == "3".
As you noted, this behaviour is not guaranteed by the specification.
However, to suggest that there is a performance penalty in doing so is blatantly false.
In fact, that is exactly what the "autoboxing within the range of a byte" hack does, only in a different context.
Specifically, keys a value (the primitive) to an object (the wrapping type) with O(1) lookup - an attempt to prevent redundant objects - simply, all Integer instances with the same underlying int representation need not be replicated (this is ultimately a result of the constructor semantics of the language guaranteeing a new instance - an implicit requirement defect).

Related fun: http://jqa.tmorris.net/GetQAndA.action?qids=7

2005-10-21 Reply Admin

brazzy:
Anonymous:

It is one thing to assert that a certain person merely hates the language, it is quite another to defend the lack of some feature merely because you have to in the face of rants against your pet language.

Operator overloading does NOT obfuscate code and is NOT useless syntactic sugar.

Yes, it is. Let's look at it in detail:

1. it's syntatctic sugar - simple fact.

2. it is useless - Not 100% true, but 95%. The only advantage it offers is terser code, but this is actually a grave DISadvantage (see 3.) unless the operator's meaning is ovbious and/or well-known to everyone who reads the code. This is the case only for mathematics, and only for the small subset of mathematics where ASCII symbols are used. There's a reason why nearly everyone arguing the usefulness of operator overloading will use the same example (complex numbers).

3. it obfuscates code - operators are less descriptive than method names in nearly all cases, and implicity operator precedence is a minefield. Yes, it allows you to cram more mode on one line. No, that's not a good thing.

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

2. Again a rigmarole of sweeping and unsupported statements. Any application with insufficient comments or documentation is going to be a nightmare to be maintained. That more than anything else makes for obfuscation in any application. NOT operator overloading. Your argument is considerably a very specious one.

3. Self describing methods (with descriptive names) is not half as useful as proper application of patterns and juducious commenting and documentation. The argument that operator overload obfuscates code is just as valid as any argument that posits that any code can and will introduce bugs, so no code is better.

In short, there is nothing that you are asserting about operator overloading that is correct or relevant.

Richard Nixon · 2005-10-22 Reply Admin

Anonymous:

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

Why can't people make arguments without insulting the intelligence of those they are arguing with? There is no need to say something like, "which I doubt you could do" - is there? As soon as I saw that nonsense, I stopped reading your post, firm in my decision that you were wrong in everything that you were saying. I appreciate that you may have a need to insult others on the Internet but try to temper that just a little bit if you want to be taken seriously.

Sincerely,

Richard Nixon

jeremydwill · 2005-10-22 Reply Admin

Richard Nixon:
Anonymous:

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

Why can't people make arguments without insulting the intelligence of those they are arguing with? There is no need to say something like, "which I doubt you could do" - is there? As soon as I saw that nonsense, I stopped reading your post, firm in my decision that you were wrong in everything that you were saying. I appreciate that you may have a need to insult others on the Internet but try to temper that just a little bit if you want to be taken seriously.

Sincerely,

Richard Nixon

Interesting tactic - You point out that Anonymous did not need to insult the intelligence of the person with which he/she was arguing, then immediately follow that by claiming that Anonymous's statement was "nonsense", and that you were "firm in my decision that you were wrong in everything that you were saying".

Hello pot - you are just as black as the kettle http://www.goenglish.com/ThePotCallingTheKettleBlack.asp

ammoQ · 2005-10-22 Reply Admin

Anonymous:

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

And the VB.net guys didn't think they need operator overloading. IMO C# has it to appeal to C++ developers. In fact, MS is susceptible to featuritis, so just because they do something does not necessarily mean it's necessary or even a good idea.

2. Again a rigmarole of sweeping and unsupported statements. Any application with insufficient comments or documentation is going to be a nightmare to be maintained. That more than anything else makes for obfuscation in any application. NOT operator overloading. Your argument is considerably a very specious one.

So you are going to look up comments or documentation for every single operator in the application?

Self describing methods (with descriptive names) is not half as useful as proper application of patterns and juducious commenting and documentation. The argument that operator overload obfuscates code is just as valid as any argument that posits that any code can and will introduce bugs, so no code is better.

Comments and documentation are necessary, but so are descriptive names. There is a reason why most programmers don't call their method e.g. "add" when the method does not at all add something.

2005-10-23 Reply Admin

ammoQ:
Anonymous:

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

And the VB.net guys didn't think they need operator overloading. IMO C# has it to appeal to C++ developers. In fact, MS is susceptible to featuritis, so just because they do something does not necessarily mean it's necessary or even a good idea.

2. Again a rigmarole of sweeping and unsupported statements. Any application with insufficient comments or documentation is going to be a nightmare to be maintained. That more than anything else makes for obfuscation in any application. NOT operator overloading. Your argument is considerably a very specious one.

So you are going to look up comments or documentation for every single operator in the application?

Self describing methods (with descriptive names) is not half as useful as proper application of patterns and juducious commenting and documentation. The argument that operator overload obfuscates code is just as valid as any argument that posits that any code can and will introduce bugs, so no code is better.

Comments and documentation are necessary, but so are descriptive names. There is a reason why most programmers don't call their method e.g. "add" when the method does not at all add something.

#1 As for ther classic VB.NET against C#, if I may, the current VB.NET implementation is behind that of C#. Operator overloading will be introduced in VB.NET 2.0. That does say something about the fact that operator overloading is sufficiently important that it is to be included in the newer release of VB.NET. Of course, if we start to write in IL, then we would have all the features that the IL platform offers if we can stomach the obvious coding differences in IL (tongue-in-cheek)

#2 I think you miss the point entirely, and I suspect deliberately as well. If there is obfuscation in any application, it has more to do with the lack fo comments, and proper documentation (as well as use cases where applicable) rather than the implementation of operator overloading. Like any feature in .NET, it is to be used judiciously and after due consideration. Just because it is not available in one's pet language does not necessarily indicate it is a wise or unwise decision.

#3 There is no argument about descriptive names. However, descriptive names can also be quite deceptive if you do everything else but what the name implies. Hence, the "proper application of patterns and judicious commenting and documentation". Having come into a number of projects mid-stream, I have had the opportunity to see a lot of so-called decriptive names having 10% to do with what it implies and more with other stuff.

2005-10-23 Reply Admin

I am honoured that you have found it necessary to reply to me with such vitriol considering that there are a lot of your posts here in this august site (re: with a touch of sarcasm!) that have provided ample examples of you sinking your teeth in other with very personal and rather unprofessional comments.

I am honoured indeed. And by the way, I never do take your posts seriously. You have, you must admit, quite a following of people against your point of view.

2005-10-23 Reply Admin

Richard Nixon:
Anonymous:

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

Why can't people make arguments without insulting the intelligence of those they are arguing with? There is no need to say something like, "which I doubt you could do" - is there? As soon as I saw that nonsense, I stopped reading your post, firm in my decision that you were wrong in everything that you were saying. I appreciate that you may have a need to insult others on the Internet but try to temper that just a little bit if you want to be taken seriously.

Sincerely,

Richard Nixon

Forgot the quote button

I am honoured that you have found it necessary to reply to me with such vitriol considering that there are a lot of your posts here in this august site (re: with a touch of sarcasm!) that have provided ample examples of you sinking your teeth in other with very personal and rather unprofessional comments.

I am honoured indeed. And by the way, I never do take your posts seriously. You have, you must admit, quite a following of people against your point of view.

														</span><br>

Spigot · 2005-10-23 Reply Admin

While, technically speaking, operator overloading IS nothing but syntactic sugar, it's sugar i'll gladly take. As fun as myArrayLikeObject.itemAt(5) is, I'm much more fond of myArrayLikeObject[5]. I've yet to be confused by overloaded methods in Python. Having done a few moderate-sized numeric projects in Java, I can't tell you how sick I was of .add() versus +. While it can be abused, is it really so horrid as some make it out to be?

Schol-R-LEA · 2005-10-23 Reply Admin

ray:
Anyway as I said, this is the reason we have the .equals() funtion in java, as it allows us to compare the contents of an object as opposed to "= =" that will compare the objects themselves to see if they are in fact the same object.

No, your have the ".equals" method because

Java sucks

You're correct, of course. Everyone knows that the obvious, correct, universal syntax for object value equality is

(eqv? foo bar)

ammoQ · 2005-10-23 Reply Admin

Anonymous:

#1 As for ther classic VB.NET against C#, if I may, the current VB.NET implementation is behind that of C#. Operator overloading will be introduced in VB.NET 2.0. That does say something about the fact that operator overloading is sufficiently important that it is to be included in the newer release of VB.NET. Of course, if we start to write in IL, then we would have all the features that the IL platform offers if we can stomach the obvious coding differences in IL (tongue-in-cheek)

IMO the VB guys had to add operator overloading, because otherwise, VB programmers could not use some classes (written in C#) that offer certain features only through overloaded operators, not normal methods.

#2 I think you miss the point entirely, and I suspect deliberately as well. If there is obfuscation in any application, it has more to do with the lack fo comments, and proper documentation (as well as use cases where applicable) rather than the implementation of operator overloading. Like any feature in .NET, it is to be used judiciously and after due consideration. Just because it is not available in one's pet language does not necessarily indicate it is a wise or unwise decision.

The problem is that operators look harmless and there is just a limited set of them; but since they save some typing, programmers are tempted to abuse them. Compared to methods, IDEs cannot help you that much finding the right operator. But don't get me wrong, I see some cases where operator overloading is justified and probably a good thing. Unfortunately, "hello-world" in C++ is an example of abused operator overloading.

#3 There is no argument about descriptive names. However, descriptive names can also be quite deceptive if you do everything else but what the name implies. Hence, the "proper application of patterns and judicious commenting and documentation". Having come into a number of projects mid-stream, I have had the opportunity to see a lot of so-called decriptive names having 10% to do with what it implies and more with other stuff.

Deceptive names are a problem with bad programmers, not an implicit problem with descriptive names. On the other hands, there is only a very limited number of overloadable operators, and their default semantic often does not match the semantic after overloading.

2005-10-23 Reply Admin

Flammable, and common, topic. Operator overloading wouldn't have survived if it was just artificial sweetener. Yes, technically it can be considered sugar, but given correct application sugar makes the difference between flat cookies and savory pastries. Strictly speaking, it might not be absolutely necessary but it do makes a great difference.

Good code is good code, good programmers are good programmers. Obfuscation is not a consequence of language features but the misapplication of language features.

ammoQ:
Anonymous:

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

And the VB.net guys didn't think they need operator overloading. IMO C# has it to appeal to C++ developers. In fact, MS is susceptible to featuritis, so just because they do something does not necessarily mean it's necessary or even a good idea.

This makes me think you consider VB > C#. I think many would consider that a strange claim... It seems to me that certain feature are missing from VB does not constitute a good authority for that features redundancy in other languages.

ammoQ:

2. Again a rigmarole of sweeping and unsupported statements. Any application with insufficient comments or documentation is going to be a nightmare to be maintained. That more than anything else makes for obfuscation in any application. NOT operator overloading. Your argument is considerably a very specious one.

So you are going to look up comments or documentation for every single operator in the application?

Irrelevant, both of you. Methods or operators can both be clear or enigmatic. Comments help provide insight into code but this is in addition to, and beyond, methods/operators/whathaveyou.

ammoQ:
3. Self describing methods (with descriptive names) is not half as useful as proper application of patterns and juducious commenting and documentation. The argument that operator overload obfuscates code is just as valid as any argument that posits that any code can and will introduce bugs, so no code is better.

Comments and documentation are necessary, but so are descriptive names. There is a reason why most programmers don't call their method e.g. "add" when the method does not at all add something.

Here we have the core. Operator overloading is best used when performing "natural" operations, f.i. analogous to mathematics, set management, etc. Just as the good Java programmer would (hopefully) not make an "add" method that downloads sitcoms, neither would the good C++/C# programmer write such a "+" operator.

But there is one thing where operator overloading DO provide functionality beyond methods, and which Java thus cannot provide. Remember that you can overload stand-alone binary operators in C++, f.i., you can overload the global + operator. I did (mathematical) vector and matrix classes, for which I overloaded the relevant binary arithmetic operators. This allowes me to write code like

vector v;
matrix m;
double scalar;
...
m = m2 + m3 * v * scalar;

Highly natural syntax. Clear, concise. Immediately understandable. And would be very messy in a language devoid of operator overloading. Of course, this is the canonical example, but it is relatively easy to produce other, non-mathematical ones.

All here should agree to that this adheres closly to some of the Grail pieces of Good Programming Practices. Code minimisation, transparancy, compartamentalisation. A similar functionality would probably be possible to obtain in, f.i., Java, but would entail much more code, more distributed code, redundant code, and less aesthetic code.

Richard Nixon · 2005-10-23 Reply Admin

Brandon Driesen:
I am honoured that you have found it necessary to reply to me with such vitriol considering that there are a lot of your posts here in this august site (re: with a touch of sarcasm!) that have provided ample examples of you sinking your teeth in other with very personal and rather unprofessional comments.

I am honoured indeed. And by the way, I never do take your posts seriously. You have, you must admit, quite a following of people against your point of view.

</span><br></div></BLOCKQUOTE><br>

I was merely giving you some friendly and constructive criticism so that you may better do battle on these boards and win arguments. If you stick to discussing the actual issue instead of discussing the debater's personal attributes, you have a much more solid argument. When your argument relies on some aspect of the person you are debating with, your argument is then not universal since it relies on a specific target. Also, if someone accuses you of being a murderer - a valid defense is not, "You're a murderer too!"

I'd like to think those people are simply friends that I am still winning over with personality and charm. Some day they'll come around.

Sincerely,

Richard Nixon

Richard Nixon · 2005-10-23 Reply Admin

jeremydwill:
Richard Nixon:
Anonymous:

1. The more experienced developers who wrote the C# engine which I doubt you could do did not think so. You are just regurgitating sweeping statements with no established references.

Why can't people make arguments without insulting the intelligence of those they are arguing with? There is no need to say something like, "which I doubt you could do" - is there? As soon as I saw that nonsense, I stopped reading your post, firm in my decision that you were wrong in everything that you were saying. I appreciate that you may have a need to insult others on the Internet but try to temper that just a little bit if you want to be taken seriously.

Sincerely,

Richard Nixon

Interesting tactic - You point out that Anonymous did not need to insult the intelligence of the person with which he/she was arguing, then immediately follow that by claiming that Anonymous's statement was "nonsense", and that you were "firm in my decision that you were wrong in everything that you were saying".

Hello pot - you are just as black as the kettle http://www.goenglish.com/ThePotCallingTheKettleBlack.asp

Thank you for your insightful commentary! You fail to notice the difference between insulting someone in the manner that I was replying to and the act of informing someone how they are perceived based on their behavior. I am sorry that you were not able to deduce the difference. Better luck in the future and God Bless!

Sincerely,

Richard Nixon

2005-10-23 Reply Admin

Why does every second thread on this board has to end with evangelizing/bashing a programming language, comparing virtual d*ck sizes, or a combination of both?

I can tell you, you will not find self-affirmation in the internet.

ammoQ · 2005-10-23 Reply Admin

Anonymous:

This makes me think you consider VB > C#. I think many would consider that a strange claim... It seems to me that certain feature are missing from VB does not constitute a good authority for that features redundancy in other languages.

I was just refering to the "experience C# team" part of the previous post. I guess the VB team is just as experienced... and so is the Java team... since operator overloading is not difficult to implement in technical terms, there must be reasons why some languages don't include this features while other do.

Here we have the core. Operator overloading is best used when performing "natural" operations, f.i. analogous to mathematics, set management, etc. Just as the good Java programmer would (hopefully) not make an "add" method that downloads sitcoms, neither would the good C++/C# programmer write such a "+" operator.

But there is one thing where operator overloading DO provide functionality beyond methods, and which Java thus cannot provide. Remember that you can overload stand-alone binary operators in C++, f.i., you can overload the global + operator. I did (mathematical) vector and matrix classes, for which I overloaded the relevant binary arithmetic operators. This allowes me to write code like

vector v;
matrix m;
double scalar;
...
m = m2 + m3 * v * scalar;

Highly natural syntax. Clear, concise. Immediately understandable. And would be very messy in a language devoid of operator overloading. Of course, this is the canonical example, but it is relatively easy to produce other, non-mathematical ones.

This is without doubt one example where operator overloading is used in a good and intuitive way. Unfortunately, at least for me, the first example of operator overloading was this:

int main() {
   cout << "Hello, World!" << endl;
}

Highly unnatural IMO.

All here should agree to that this adheres closly to some of the Grail pieces of Good Programming Practices. Code minimisation, transparancy, compartamentalisation. A similar functionality would probably be possible to obtain in, f.i., Java, but would entail much more code, more distributed code, redundant code, and less aesthetic code.

Agreed; but IMO java is not a good choice for that kind of program anyway.

2005-10-23 Reply Admin

ammoQ:
This is without doubt one example where operator overloading is used in a good and intuitive way. Unfortunately, at least for me, the first example of operator overloading was this:
int main() {
   cout << "Hello, World!" << endl;
}
Highly unnatural IMO.

I agree to an extent; the fist time I saw STL C++ code I too wondered what they'd been smoking - it is not the most immediately intuitive or newbie-friendly syntax imaginable. However, they needed to overload operators for stream inserts and extracts, and in my opinion there are no better ones suited for the purpose.

As programmers we sometimes think too much about the rigidly formalistic aspects of our work. While we like to apply the term "aesthetic" about code we tend to have a very conservative and formal, in a mathematical sense, understanding of the concept. I hold that from a pictoral and symbolic perspective the stream input and extact operators << and >> are in fact very apt and aesthetic -as everyone upon using them immediately gathers they are arrows pointing at the source or target stream- and this is proven by the fact that almost everyone takes to their use quite fast and in fact quite intuitively.

I can't imagine what stream-akin code complete with manipulators etc would look like in a language without operator overloading... *shivers*

ammoQ · 2005-10-23 Reply Admin

Anonymous:

As programmers we sometimes think too much about the rigidly formalistic aspects of our work. While we like to apply the term "aesthetic" about code we tend to have a very conservative and formal, in a mathematical sense, understanding of the concept. I hold that from a pictoral and symbolic perspective the stream input and extact operators << and >> are in fact very apt and aesthetic -as everyone upon using them immediately gathers they are arrows pointing at the source or target stream- and this is proven by the fact that almost everyone takes to their use quite fast and in fact quite intuitively.

I don't think

std:cout<<1<<2<<(3<<4)<<5
is easy to take or intuitively.

I can't imagine what stream-akin code complete with manipulators etc would look like in a language without operator overloading... *shivers*

What kind of program would make extensive use of that?

2005-10-23 Reply Admin

ammoQ:
I don't think

std:cout<<1<<2<<(3<<4)<<5

is easy to take or intuitively.

Well, that artificial bit-shift operation (3<<4) makes it somewhat less readable, but I'd say that a more real-world-like snippet, like

    using namespace std;

    int a = 0xbaadc00de, b = 0xdeadc0de, c = 65535;

    cout << hex << a << " -- " << b << ": " << dec << c << endl;

is quite intuitive.

I can't imagine what stream-akin code complete with manipulators etc would look like in a language without operator overloading... *shivers*

What kind of program would make extensive use of that?

Hopefully none. But in a language where you can't do output like above you will instead be forrced to multi-line behemoths or class/function multiplication hell. The STL stream operators is a good example of the entire discussion: they are easy to make into both good examples on the benefits of operator overloading and anti-examples of the horrors of operator overloading. Again, we come down to that good programmers are capable of making judicious use of language features. But it is poor languages-or a poor language philosophy- that restricts the programmer's toolset .Toolset restriction might preempt b0rked coders from shooting themselves in the foot in certain ways (though they will always find other means to that) but it will also limit and restrain the good programers.

Magic Number Superstition

Leave a comment on “Magic Number Superstition”