With the recent Sun talk which mentioned dynamically-typed languages, the Ruby-on-Rails article on Slashdot, and my recent interest in C#, I've come to think about the things that I take for granted in my strongly typed languages.
I came up with a lot of questions.
Do I need checked exceptions?
The only (relevant) language to have them is Java. They were heralded as forcing people to handle exceptions, but in reality, they just pissed people off and people started throwing them away. I can see the use of runtime exceptions - they're required, especially for things like casting, nulls, and the VM error conditions that would be infeasible to check in every method. But how often does anyone catch those anyways? Really, there's not a lot you can determine from a null reference; it's a bug! On the other hand, will you really check for an exception you CAN handle if you're not forced to?
Lots of people have opinions, some even well-informed. You can Google them. Google Scholar doesn't turn up much though: has the SE community not addressed this scientifically?
Do I need strong types?
Yes. GOD YES! This weak typing hippie crap is really pissing me off. We need STRONGER types in fact: I want compile-time constraints on values! Why should I be allowed to pass a null to a method when clearly the method can't accept it? Why can't the compiler force that? More to the point, it'd be more efficient! How often does one datum get null-checked on the way up a call stack? If the code is solid, I bet pretty damned often. If I could just make a type != null, it would only need to be checked before it first entered the method, and assumed not null the rest of the way up.
(note: yes, I know you can do this with classes. But it's a ridiculously heavyweight solution considering that you'd need a class for each individual combination of constraints.)
Plus these dynamic types really screw things up, because they go hand in hand with auto-conversion. Because you NEVER KNOW WHAT A VARIABLE IS! Is it a string? An integer? An integer interpretation of a string? A string interpretation of an integer? A string interpretation of an integer interpretation of a boolean? It's a black art, requiring you to know far too much about how the language interprets expressions. Even C had that wrong; promotion/demotions of primitive types were nuts and required a zillion casts to get simple cross-type math right. Bringing me to my next rant.
Primitive types?
GO HOME! It's already painfully obvious they're outmoded. Strings are a prime example: is it a class? An object? A primitive? A value? We don't know! Autoboxing is just meant to hide this because nobody has the courage to say STOP! A primitive, in my mind should merely be another type, except the compiler can generate instances of them from literals. That's all. It'd be trivial to optimize them out behind the scenes. Get rid of them!
Compiled languages?
Please. How can you do compile-time checks if there's no compiler? With classloaders like Java, there's no "huge rebuild" for every change. In fact, Eclipse compiles whenever you save, and even builds a loadable class if you have errors (replacing bugged code with exceptions). The compile overhead is truly marginal, and certainly not so huge as to make scripting languages a good idea. Plus, with a scripting language, there's no way to hide your code. As open-source-friendly as I am, some people need to distribute as binary.
Of course, .NET has it wrong - we (okay, *I*) don't want assemblies, we want CLASSES! Not in DLLs, not in EXEs. Java's JARs were a good step, and with only minor enhancements, would be the ideal tool for this.
I'm done. That's my rant. Go. Make languages for me now. I'm sick of your silly languages. Make me a good one.
What? Not done yet? *sigh*
No comments:
Post a Comment