Yeah, in the same way strings are immutable. You can't change a 12. But even if "immutability" is potentially a matter of perspective, the key feature is referential transparency -- nobody else can change your values.
In a perfect world probably. But have you considered that there's a reason why primitive types are left as primitives even in C# (which had the opportunity to correct the mistakes Java made).
I'm not suggesting that primitive types be implemented using the mechanics of regular objects. I'm just saying that they could be made to appear to the programmer like regular objects. Combined with certain restrictions (e.g. no extending from primitives) and some compiler tricks, this can be made to work efficiently. The fact that Java's primitive types are all immutable makes this even easier -- immutable objects are very well-behaved.
And sure, your performance might suffer if you're not careful, but I don't think that's necessarily worse than having to force people to deal with the primitive/object difference even when they don't particularly care. It's kind of like the autoboxing situation today. If you're not careful you could end up with a bunch of unwanted boxing/unboxing operations. So when I need to be careful, I am. But when I just want to get something done, it's way easier to just let the autoboxing happen.
My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language.
C# started out essentially the same as Java. But at this point it's way better.
- Function types and closures. This alone makes it way better.
- More efficient generics (no boxing/unboxing).
- Local variable type inference.
- Coming in C# 5.0: automatic CPS transformation (async/await).
Any experienced c++ programmer will tell you that "classes if necessary, but not necessarily classes" is the way to go. Class explosion is not pretty, and makes for over-complex stupid implementations.
When trying to design a new, clean, high-level programming language, I probably wouldn't pay much attention to C++ rules of thumb.
Making everything behave like an object can make things much cleaner. It all depends on how exactly this is done, but a lot of complexity in Java comes from the fact that primitive types behave differently. C# did a bit better, but there's still the value-vs-class distinction which can trip you up in subtle ways.
I think you're wrong. From the coverage I've read, it's a method of processing and manipulating XML documents, and they designed an piece of XML editing software around it which they showed to Microsoft and Microsoft then stole the ideas from.
News coverage of technical things is so effing horrible. Most tech articles are written by people who don't understand programming but don't see why that should stop them from broadcasting their misinterpretation of technical information. You should just read the patent; most of it is very clearly-written.
It does not predate XML, and has nothing to do with XML-based standards.
Filed in 1994, it does predate XML. It doesn't predate SGML, though, and since core XML is essentially the same thing, it's probably safe. However, I it does affect XML-based standards -- specifically the ones that separate content from structure/presentation.
It's a way to separate content from structure. So, for example, where and SGML document would store data like "<p>Hi <i>friend</i></p>", they store it as two separate pieces of data. The content piece would be "Hi friend", the structure piece would be "0:p, 3:i, 9:/i, 9:/p" (roughly). So now if you wanted to format that document differently, you could just use a different structure piece; the content piece doesn't change.
This exact technique obvious, so I don't think it should have been awarded a patent. But maybe what's obvious to us in 2009 may not have been obvious to the patent examiner in 1994 and, in any case, it doesn't look like any of the affected parties are going to try and argue obviousness. The important question is how generally will their technique be interpreted?
Taken narrowly, it's a way of putting XML-like tags in a separate file, mapping them back into the content using byte offsets. This is easy enough to work around. Taken broadly, it's a way of separating content from structure. So, any time you augment the content in one file by some kind of annotations in another, you're violating their patent. So HTML and CSS are problematic because the style information is in a separate file, even though the mapping is done using tag and class names and not using byte offsets.
I don't know much about patent litigation, so I don't know how much leeway they give plaintiffs. But I doubt Microsoft Word uses their exact technique; they probably do something similar to HTML+CSS or XSLT. So this victory could indicate that the courts are interpreting the technique broadly. Which sucks. Man, patents like this are killing the industry.
and "colleges" are usually either private religious based high schools or technical/vocational training institutes
Not where I'm from. [long list of "colleges" in the US]
I think marxz was continuing on the "Outside of America" theme of the parent post.