Leo Lipelis
Posts: 111
Nickname: aeoo
Registered: Apr, 2006
|
|
Re: A Type System is a Set of Tests
|
Posted: Apr 17, 2006 4:07 PM
|
|
Why is there a desire to "decouple" types from the program? Like I said before: not all things should be decoupled.
Many people agree that every good thing has its degenerate case. For example, a trees can degenerate into a list. Desire for compact functions degenerates into meaningless 1 line functions. Desire for abstraction can degenerate into an inheritance hierarchy of interfaces and classes that each contain only one method, and so on. Desire to produce modular and pluggable systems degenerates into a compiler, or worse, an assembler! I mean, if you want the ultimate spreadsheet application that is super-hyper-duper-extensible, what you want is a C compiler.
Now, with this in mind, I think it's good to examine your idea. I realize that it's a cool and clever idea, and so it's not going to be easy to let go of it. :) But, try to step back and dispassionately see if it really benefits anything?
Just because something restricts something else, does it mean it's beneficial? Think about it, please. If I make it so that C compiler can only be used to compile spreadsheets, then I eliminate ALL the errors inherent in kernels, web servers, word processors and so on. Of course narrowing the expressible domain can reduce the possibility of some errors. But have you considered that purposefully ALLOWING certain errors can be a good thing if it enhances the scope of your domain?
If you "decouple" types, why not "decouple" variable names too? Why not "decouple" arithmetic operators like this: ---file.a f1: a b c ---
---file.b f1: + + ---
so that compiler can read file.a and file.b and understand that f1 line is addition of a, b and c? I mean, you can "decouple" anything from anything, but is that good? Surely it is good, because you can then make pluggable arithmentic expressions, right? I mean, file.b could also be:
---file.b f1: add add ---
or ---file.b f1: addall ---
isn't that great? ;) Just think of all this flexibility.
Like I said before, "decoupling" static types is a horrible idea. First, you can no longer see type information at a glance without a fancy GUI. Second, you cannot change type information willy nilly without breaking other things (even with so-called "pluggable" type systems), so it can't even rightly be called decoupling! If I decouple List interface from its implementation, then I can change the implementation of List without breaking any of the code that uses it. On the other hand, if a make a change to a "decoupled" static type file, I WILL break all kinds of things (unless all your variables are global in scope and you only need to change one file, but this is horrible, we're back to bad old days of globals).
It's just not right to call what you're proposing here "decoupling."
Secondly, let me make a prediction regarding these so-called "pluggable" type systems. What will happen is one of these systems will become popular and will dominate. So what's the point of adding complexity? Personally there is no way I'm going to be editing 2 files if I can edit just 1. In fact, when people compare Python to Java, the fact that you can group many Python classes in one file is considered an advantage (that I have seen). Proliferating file counts and KLOCs are bad. I think it's better to think how to reduce both KLOCs and file counts, instead of thinking how to make it so flexible that we end up back at assembly level with billions of KLOC and 10 files just to get a simple 3 class program with static typing going.
It's cool to provide hooks for pluggable type systems. But this in no way should burden or even be apparent to the developer. When someone comes up with a better type system to plug in -- it's a new language and should be treated as such. Just like c++ is a new language, even though it plugs into the same backend as c in gcc suite.
|
|