Congratulations to having a very intelligent wife.

I have been saying that for years: If you know how to lie you get laid.

The fundamental question is: Can the truth be sexism?

The fact, which political correctness advocates don't like to hear about, is that both sexes have fundamental behaviour patterns bred into them in the approx. 80'000 years the human race exists.

So is it sexism to speak about those?

And yes, there are exceptions. Just as there are men who like to date men, women who like to date women, men who like to where women clothing, women who ... wait ... you would not be able to spot women wearing mens clothing any more as there is no typical mens clothing any more.

Anyway: they are just that: exceptions.

You really think that works? I sell Android Open Source by the GPL rules: legitimate customers can request the source code — but nobody ever does. I do mention it. It is not a hidden secrete. Still no one is interested.

And on the other side I don't expect donation to flow in if I used that site. Once the average user has his App he is not interested either in source or donations.

I for one continue to use the GPL allowance to sell the binary and only give away bare source for fee.

That is the theory you are talking about. But the girlintraining was talking about what happens in real live. Very different things.

It is a JavaScript problem.

It is not even close or similar.

More the spirit of Java. I have worked with other OO languages which did a better job of it. Either by not having primitives in the first place (true OO) or having more thought out concept of primitives (hybrid OO).

So maybe the problem arise by Java trying to be pure OO but still having primitives. Which a pure OO language should not have.

Good point. But then you should not have primitives outside a java.jni package anyway. Just like Smalltalk or Scala. That would then be truly OO.

That seems wrong to me. In fact it seem the wrong way around for me.

For signed binary arithmetic there are two option:

One-Complement: Where we have symmetric positive and negative ranges. Including a negative zero. Seldom used.

Two-Comlement: Where we have asymmetric positive and negative ranges. With the negative range having one extra number.

But for unsigned binary arithmetic I only know one way of doing it. 30 years of experience in the field. More then a dozen programming languages learned. Degree in computer science. I am hard pressed to even think of a different way to do unsigned binary arithmetic. Even on a purely abstract and academic level.

But one is never to old to learn something new and I a the curious type: Please enlighten me!

Actually those where UTF-8 characters. slashdot.org converts the UTF+8 characters to HTML entities. Does a good job on it. But then put them out literately. Maybe I have another look at the option.

“sane subtraction 3 - 7 = -4.”

That is only sane in the centre of the valid range. But how about: X = MIN_BYTE + 3; y = x - 7;

The problem was just moved elsewhere where it is not so notable. My main critic on Java is that whenever the investors of Java encountered a difficult to implement possible feature; instead of thinking it through; finding the proper solution; the investors of Java shied away and declared it “unnecessary” or “dangerous”.

I don't blame them. AFAIK Sun what breathing down there Necks telling them to finish by X. Probably also the reason why the few difficult features which did make in (like clone ()) tuned out to be a pigs ear.

True. CPUs do roll over.

And thinking of it (and correcting myself): Ada does for unsigned typed as well. Not for signed. There a RANGE_ERROR is raised. Strange but sometimes useful asymmetry.

But that does not invalidate my statement. All CPU I know of (there might be others, more exotic CPUs of course) set a carry and/or overflow flag on signed and unsigned roll-overs as well. One does not exclude the other here.

In 8 bit times those flags where extremely important to do 16 bit operation with only an 8 bit arithmetic logic unit. That is why it is called carry flag. And of course you can branch on the carry flag set or unset.

Not good enough because Java is missing another important OO Feature: operator overloading. If I may expand the title of the Article “Love for the JVM and Hate For Java”.

Also: Arithmetic contains great potential for optimisation. But for this the compiler need to know what kind of type he is dealing with:

x + 1 + 2 should be optimized to x + 3
MAX_FOO + 4 should be evaluated at compile time
x < y ||&#160;x = y should be optimized to x <= y

You can still have a library in background to be used by the compiler but the type must be part of the language. The SmallTalk approach that would be.

Anyway: For me the solution was to use Scala when ever I can.

Ada gives a access to CPU unsigned types without &ldquo;implementation defined&rdquo;. Mind you Ada prescribes RANGE_ERROR on for overflows in signed types and modulo operations on unsigned types. Either way it is well defined.

Scala hides the difference between class Integer and primitive int behind a new type Int. The compiler decides automaticly if a class or primitive should be used. The quite old language SmallTalk does so as well. Primitives are only interesting when you JNI work. Worse case scenario: array of unsigned byte or short in to our out of a JNI call.

Also it should have been build into the compiler. A library is not good enough because Java has no operator overloading. Ada has, Scala has. Almost all other OO Languages have. But not Java.

Spot on. And that is the reason I prefer Scala &mdash; which has operator overloading.