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.
Slashdot videos: Now with more Slashdot!
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.
Man, the BetaNews article is horrible. Practically everything — except for the direct quotes from the Google blog post — is incorrect. I somehow expect more from someone who goes by "Scott M. Fulton, III".
Google's public documentation shows Protocol Buffers (which has yet to be formally abbreviated) is indeed conceptually different from XML, in that it's rooted more in procedural logic than structural declaration. In XML, there's a schema which defines the structures of tables and recordsets, which is separate from the document that relates the contents of records in that structure.
Nope, they're conceptually the same. The ".proto" files are like DTD or XSD. The actual document data is stored in a binary format (though there's also a text representation). The data manipulation API is similar what you get from Castor or JAX-B.
But here, in an unusual departure from the norm, the default values for these members are set to digits (for strings or literals) or values (for numerals) that define their place in a sequence -- where they fall within a record. Imagine if data were streamed onto recording tape, the way it used to be in the late 1960s and '70s. It's that streaming of the data sequence, without all the fenceposts, that differentiates XML from Protocol Buffers, by taking out all those markups that say when an entry or a record starts and stops.
The "= number" at the end of a field definition is not a "default value". It is a numeric tag that identifies that field. That said, "= number" is quite unintuitive syntax; maybe something like "@number" would have been less confusing.
Looking at some of the documentation, I don't think the aforementioned numbers directly index the field's location in the record. They lay down the present fields one after another, probably putting each field's tag number before the field data. This also allows them to avoid sending fields that use the default value. So they still need to specify how long each record is — either with "fenceposts" between records or a "length" specifier before each record.