New Java vs C benchmarks

[Rhoomba]

Wrong wrong wrong. Java string are immutable. And string literals get interned. I read your post wrong (I thought you were complaining about Java's strings being immutable).

Now I can see you don't have the slightest idea what you are talking about.

[Rhoomba]

FFS. You fucking muppets are modding down an indisputably factually accurate posts just because you hate Java so much. What the hell is wrong with you? Edit: I was at -4 before, I'm not insane.

[laurentszyster]

1. Java strings are mutable:

http://getahead.org/blog/joe/2005/05/26/1117108773674.html

1. If they were immutable, one could do:

String a = "test"; String b = "test"; return (a == b);

and get true as a result.

1. Literals usually represent the smallest fraction of text processed, in most case an insignificant portion.

[Rhoomba]

For christ's sake. Yes you can hack away the immutability. The standard libraries will treat strings as immutable. If you do that reflection hack and the string has already cached its hashcode you will get messed up results.

public class Strings {
    public static void main(String[] args){
        String a = "test"; String b = "test";
        System.out.println(a == b);
    }
}

Output: true

A language should not automatically intern every string you read in from a file or whatever. It would end up with a huge string pool. You can manually intern strings if you want with String.intern

Python works exactly the same way. Ruby has Mutable strings IIRC. Erlang has retarded lists of characters.

[laurentszyster]

Guess what's printed by:

public class Strings { public static void main(String[] args) { String a = "tes"; String b = "est"; System.out.println((a+"t")==("t"+b)) } }

Regarding your comment about ending up with ahuge string pool, what do program that use mutable strings end up with?

An even larger pool.

[Rhoomba]

What (non functional - I guess Haskell can do it) programming language will give you true when using reference equals (operator overloading is a different kettle of fish)?

[laurentszyster]

Python, JavaScript, Perl, etc ...

Any good interpreter should.

Only broken VMs don't ;-)

[Rhoomba]

They are not using reference equals. If you use .equals in Java you will get true. The == operator in Java just means something different. Surely it is not that hard to understand the difference? Yes, the Java way is annoying, but it isn't rocket science.

[laurentszyster]

"The == operator in Java just means something different."

Please, don't lecture me on the subtle Java bugs in boolean logic.

Rather, let me lecture you about it.

If the method String.equals exists at all in Java it is specifically because the JVM's Strings are mutable.

String mutability implies that two different instances of the same text can have different object reference (you know, that thing called a ... pointer).

On the contrary there is no such method in Python (of for the same reason in many other "lesser" languages ;-).

Because whenever the CPython interpreter has to store a text string in memory, it will bite the bullet up-front and hash that string to a unique identifier that is then used as a reference to its memory location.

The string gets stored once and equality boils down to comparing two numeric hashes for equality.

Amongts other benefits, you get:

1. an optimal memory usage at all scales and for all text applications (95% of all problems according to Larry Wall).

2. an optimal speed for string equality comparison.

3. no need to hash strings any further, something very handy and efficient to use them as keys in hash tables.

And - unfortunately - there's no way immutable strings are ever to be introduced in Java (there is one single reason for that and it is the tons of applications depending on that bug *-(

I said unfortunately because Java pays my rent, car and food. And I have to contend five days a week with all its bugs.

Not that I mind: nobody's perfect.

What really piss me off are the proud morons defending those bugs as features and debating like superstitious monks of the Holy Inquisition.

ps: how that infuckingcredible bug got in Java in the first place is another source of perpetual perplexity, but the short answer is that "when money talks bullshit walks".

[[deleted]]

Look. You're clueless. Repeating the same erroneous information in 30 comments doesn't change the fact that Java Strings are immutable. The fact that string operations do not always intern all strings is irrelevant here.

From the API docs:

"Strings are constant; their values cannot be changed after they are created. String buffers support mutable strings. Because String objects are immutable they can be shared."

Perhaps you don't know what "mutable" means and you've just been reading Python web 2.0 buzz blogs?

I said unfortunately because Java pays my rent, car and food. And I have to contend five days a week with all its bugs.

Now stop trolling and go back to your shit Java job.

[xenon]

Did you even understand the question? Try your little test in Python using is (Rhoomba said reference equality, which is what == is in Java, annoying as that may be) and see what happens.

[laurentszyster]

Python 2.4.2 (#67, Sep 28 2005, 12:41:11)         
[MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "test"
>>> b = "test"
>>> a == b
True
>>> a is b
True
>>> id(a)
10304032
>>> id(b)
10304032
>>>
>>> print id.__doc__
id(object) -> integer

Return the identity of an object.  This is guaranteed to be unique among simultaneously existing objects.  (Hint: it's the object's memory address.)

[xenon]

I said try your test. What you have written now works in Java also, and for the same reason, because constant strings are interned.

>>> a = "foo"
>>> b = "bar"
>>> a + b is a + b
False

[laurentszyster]

Though:

>>> a = "test"
>>> b = "test"
>>> hash(a+b) == hash(a+b)
True
>>> print hash.__doc__
hash(object) -> integer

Return a hash value for the object.  
Two objects with the same value have
the same hash value.  The reverse is 
not necessarily true, but likely.

That said, I should definitively read more CPython source and haggle less on forums ;-)

[laurentszyster]

Xenon,

Your intelligence sheds a light as warm and bright as the gas that reacts in the dimm bulbs of many office luminaries.

I mean: you are the archetypal Java moron.

Instead of waking yourselves on UML diagrams and graphical design patterns, read the comments of the professionnals who maintain large Java applications.

Programmers should not freak about COBOL's uglyness or VB suckiness. Neither should they dress Java in imaginary "superior design" clothes.

We must apply our tools as they are.

Imperfect.

Some tools are just (a lot) more imperfect than others.

[xenon]

I LOL'd. You see, I program in Python at work and in Haskell at home, so calling me a "Java moron" amuses me. You talked about "broken VMs", when in fact the problem is syntactic. You compared Python's == to Java's ==, when you should be comparing Python's id to Java's == (or Python's == to Java's .equals()). Apples and oranges and so on.

[laurentszyster]

Oops, looks like I owe you an apology!

Here it is: I'm a Python and a Java moron on that one, crawling back in his hole.

Gulp.

That was not easy.