Microsoft Bashing

Java generics can generalize over object types, only. They can't generalize over primitives (they handle that case by autoboxing primitives to objects) and they can't generalize over value types, because java doesn't have value types.

So in Java, you can never define a "struct foo" and an array of struct foo, and have that array be stored as a linear list of struct foos all inline, it has to be an array of pointers to object foo instead. My understanding is that C# can do that... and the collection classes can also do this in a generic fashion. The memory overhead can be a rather large constant multiplier. Collection traversal is also quite a bit slower..


So, C# can do this because it preserves the type information at runtime, which allows it to basically treat generic classes as templates if it decides that it's necessary.

Aug 5 2010 2:39am from dothebart @uncnsrd
Subject: Re:
I remember the see-carpet pet-shop being 1/3rd loc of the java
petshop.

probably mostly because of properties vs setters/getters.

So, C# can do this because it preserves the type information at
runtime, which allows it to basically treat generic classes as
templates if it decides that it's necessary.

C# can do that as a result of the fact that java doesn't have value types. Forget the generics for a second, I gather C# can also line up an array of whatever objects in memory, and java can't simply because java was not designed to allow for that. The generics just make doing that with random types possible, but the actual flaw (limitation whatever) is in the everything-is-an-object-except-for-the-primitive-types-hack design of java.

That's true enough, as far as it goes. In Java, though, it would be nice to have a generics that was capable of representing primitive types, to make numeric computation faster... (Not that this is a use case that I care about, but it would really help the number crunching guys.)

I think the primitive types should be objects, and the syntax should be simple enough that you can use objects like you can use primitives so that you won't need a separate hack for primitives just to make the language usable.

Heh, I suppose you could do that with operator overloading. :-)))

That's the way Scala does it, on both counts.

Without having 2 paragraphs to read, is scala's syntax easy?
Oh, but it's a sloppy language right? not big on types?

The syntax will probably take some getting used to. The fundamental idea is: (a) every construct should be as general as possible; (b) everything is an expression.

(a) requires some meditation and long explanation, but
(b) allows you to do things like this:


val myvariable =
if (something) then
1
else
2

or even:

val transformedList =
for (x <- someOtherList)
yield x.someProperty

It's not a sloppy language, it's a strong/static type system that closely resembles Java's, with a few differences. They have added a form of structural typing (aka duck typing) for classes that is statically checked at compile time. In other words, you can declare "this parameter accepts any object that defines fields named x and y", and this will be statically checked at compile time (not to be confused with Objective-C/Smalltalk like systems where all such checking is at runtime.)

Function types are also structural types (as opposed to nominal types as in C# with its delegate types.) Function types don't have names, they just declare a matching signature, and are statically type checked.

You might look at "val myvariable" above and think "that looks like a sloppy language." But behind the scenes, the compiler knows the type of "myvariable" at compile time, via type inference. (There are several situations where you must declare the type when the compiler can't figure it out on its own.)

The IDE has a mouse hover to indicate the type of a variable.

You might look at "val myvariable" above and think "that looks like a

sloppy language." But behind the scenes, the compiler knows the type of

"myvariable" at compile time, via type inference. (There are several

That's fair. As long as that's what actually happening, and later in the function the compiler can bitch when you assign something of the wrong type to it. I'm not such a nazi that everything has to be spelled out, just that the Right Thing is going on in the Right Places.

The IDE has a mouse hover to indicate the type of a variable.

Speaking of... So I've been watching eclipse trying to figure out how much of what it knows when.
I've noticed that it can hot replace a class while debugging if you change the contents of a function, but you can't for example change function signatures (or maybe it's just public function signatures) without requiring a restart.

Today I noticed it can't hot replace a class if you've changed the constructor... which I don't see why not, there could be some badly constructed object, but that's true for any class that you change the innards of functions, it doesn't change the definition of the class itself.
Sure when you add or remove a member variable it has to restart because the object no longer matches, but I don't get the constructor thing.

Just an interesting thing I noticed today.

I have xp sp3 and if I go to a cmd.exe window and type dir *.doc I get not only *.doc files, but I also get *.docx files.
bad bad bad microsoft.

It's running in "what you really wanted" mode. (It probably uses the same code that causes Bing to return a bunch of pages called "Why Windows rulez and Linux sux0rs" when you search for "Linux")

Haha. In the real world, people who are working on contextual matching are very concerned about matching Alice's competitor Bob's product on an Alice-related keyword. More often than not, it's something to be avoided, at least in the context of auto-placing banner ads etc.

Doesn't XP use NTFS? Does NTFS still maintain 8.3 filenames somewhere for some weird level of compatibility?

I thought that went out with 95/me.
I haven't seen a 8.3 compatible filename in years.