I find it amusing how many people dismiss Java's static typing as a waste of time and stupid. I image that most of the people saying this are fairly ignorant of java. Static typing might be a pain because you have to do explicit cast. But it greatly speeds up developement time because it catches a lot of errors at compile time that would be very hard to track down when they happen as runtime errors in perl. Just because johnnywant doesn't know how to use typing doesn't make it useless.

That might be true of some people, but it's certainly not true of all. Many people are criticising the typing model of Java and similar languages because they use them a great deal, they get in the way and they make the code harder to understand.

They criticise it because they try using languages like Ruby, Python and Perl and discover that all those nasty things they think will happen without static typing don't.

Take a look at what Bruce Eckel's (hardly somebody who knows nothing about Java) has written about these issues in Strong Typing vs. Strong Testing and Type Checking and Techie Control.

They criticise it because languages like Haskell have been doing compile-time typing in much more interesting and productive ways for years. Good god, Java has only just got around to implementing generics!

(Please note: Adrian may be more grumpy than normal due to having to get his head around possibly the most obscene use of C++ templates he has ever seen. I do not need to see compile time recursion for no good reason before I've finished my first coffee of the day :-)

Thank you, no need for me to reply with a little less carefully worded reply along the lines that you just did. I couldn't agree more on this post...

I wonder what abuse of C++ templates you are looking at, as for myself I find the ATL library particulary abusing of C++ templates.

I wonder what abuse of C++ templates you are looking at, as for myself I find the ATL library particulary abusing of C++ templates.

The author of the atrocity had obviously heard that templates were "efficient", so they implemented their little (little - hah!) stream reading class with templates.

Except there was a bunch of different behaviour depending on the object so they were continually checking objects typeid() to decide what to do in an massive evil switch statement, which triggered off what looked (after considerable pondering) like the guts of some kind of expression template. Which would be fair enough if there were any chains of expression to optimise out. Since there aren't it's a couple of hundred lines of fardling no-op.

The most annoying thing is that it's a massive case of the first law of optimisation (i.e. "don't"). The stuff this monstrosity deals with doesn't happen often, it's running on a machine with oodles of memory, it's taking data of the net and a database so the bottleneck is definitely not the code, etc.

Not to mention the fact they invented there own string class! Twice! Use templates badly and then ignore the STL. Fantastic.

If they'd just written it as plain C++ classes with sensible use of the STL it would be a quarter the size, work just as well and be perfectly obvious code.

I'm going to go write some Ruby so I can feel clean again :-)

For the first time, I consciouly took note of how much time I spent converting types, e.g., the number 100, some wants it to be long, some String, some Long, and then the dreaded "List/Vector of Long" to long[], or Long[].

  List list = getList(); // from somewhere, say a list of Person
  Iterator it = list.iterator();
  while(it.hasNext()){
     // the following line makes perfect sense to me,
     // but it causes a compiler error, I'm supposed to write:
     //     Person p = (Person)it.next();
     // my question: Is the compiler helping me or I'm helping the com
+piler?
     Person p = it.next();


     // now call some method on p.

   }
[download]

     // the following line makes perfect sense to me,
     // but it causes a compiler error, I'm supposed to write:
     //     Person p = (Person)it.next();
[download]



-- which says it all about the myph of "Java is more safe than C++, because... it doesn't have pointers"...:-))).

Well, the problem is that it's supposed to catch those loads of errors but doesn't because it forced you to typecast to get anything at all done. If I have to typecast everything to void* (sorry, object) whenever I store it in a generic datastructure and then typecast it "back" whenever I access it I effectively turned off compile time type checking.

And no I don't think Java's (or C#'s) type "system" should look like Perl's. But something closer to ML, Clean or Haskel would definitely make things much better. You'd get the same kind of compiletype checking, but without having to typecast all the time and without the runtime typing errors caused by errorneous typecasting.

And no I don't think Java's (or C#'s) type "system" should look like Perl's. But something closer to ML, Clean or Haskel would definitely make things much better. You'd get the same kind of compiletype checking, but without having to typecast all the time and without the runtime typing errors caused by errorneous typecasting.

But Haskell/ML don't magically coerece Ints to Strings for you. That just goes to show that the real problem here has nothing to do with static typing, and everything to do with poorly designed libraries and/or poor coding in general. If you have to jump through hoops to get your code to work, you're probably doing something sub-optimal. That's applicable whether you're using Perl, Java, Haskell, whatever.

I don't want it to coerce Ints to Strings. Far from that. What I do want is to be able to implement a generic datastructure for objects of type 'a, where 'a is any type and then be able to write functions/methods that take this structure with any type of objects and another that only takes structures of Ints. I want to be able to write a function that takes a list of 'a, a function of type 'a -> 'b and returns a list of 'b.

What I end up doing is either having to "reimplement" this very same function for each list type or implement one that takes a list of void pointers (sorry, objects), a function that accepts a void pointer and returns a void pointer and produce a list of void pointers. Which I will then typecast to whatever I think I've received. Either suffers the safety or the convenience. And why? Just because the excuse for a type system of Java/C# doesn't undestand the concept of type variables. Polymorphism? My foot, they don't even understand what does that mean!

Jenda


We'd like to help you learn to help yourself Look around you, all you see are sympathetic eyes Stroll around the grounds until you feel at home    -- P. Simon in Mrs. Robinson