Strength of Type Checking: "Java is the SUV of programming tools" 
Author Message
 Strength of Type Checking: "Java is the SUV of programming tools"


Quote:
> Buffer overflows, integer overflows, divide by zero errors, and improper
> dereferencing of null pointers can all be detected at compile time with
> an appropriate compiler and static type system.  See my article:

> http://www.*-*-*.com/

> If static typing improves code quality by eliminating a class of runtime
> errors, why don't we all use type systems that can detect these
> problems?  It should lead to much better software quality.  Why don't we
> use type systems like that to do all of our development?

The article seems stupid.  You can't *really* eliminate array bounds
overflow problems at compile time.  Your article suggests transforming
them into either runtime cast problems, runtime overflow problems, or
"wraparound" errors.

That is not *really* a solution.  You are just moving the problem
around - and then claiming it is not on your patch anymore.

Detecting array bounds overflows at compile time is ultimately an
insoluble problem - much like Turing's halting problem.  You can't
deal with the general case - only a few simple instances.

So the premise of your argument is wrong - you can't *really* detect
array bounds overflows at compile time - not all of them anyway - not
while you are dealing with a Turing complete programming language.
--
__________



Thu, 23 Mar 2006 19:33:38 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"


Quote:

> i, personally, find it butt-ugly if "defaultBackgroundColor" is part of
the
> Object class, and would like to avoid using or producing software that
> involves things like that.

Why? While you would be unlikely to see a method like that in the base
definition of Object in any Smalltalk dialect, it wouldn't be surprising to
see that method added to Object as a class extension by some framework. If I
were writing some graphical application - maybe a visual programming tool -
where any object could be displayed graphically on a canvas, it would seem
reasonable - even desirable - for every object to respond with its default
background color.

Most commercial Smalltalk environments are highly modular and allow
extension through subclassing as well as by class extension. In my VisualAge
Smalltalk environment, the core Object class only defines 28 methods. If I
select the core definition of Object, that is all that I see. That said,
their are dozens of sets of class extensions defining hundreds of additional
methods (none of them are "defaultBackgroundColor" though). If I don't use
any of the frameworks that define those additional methods, none of them
become part of my packaged application. In fact, I don't even see any of
those additional methods in the browser unless I actually select one of
class extensions that define them.

The ability to add domain-specific behavior to core classes is a very
powerful feature of most Smalltalk environments and one of the things that I
miss most when working in Java. In Java, I get an explosion of domain
specific "helper" and "utility" classes that only exist to add the needed
domain specific behavior to various existing classes.

-Eric



Thu, 23 Mar 2006 22:21:10 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"


Quote:


> > i, personally, find it butt-ugly if "defaultBackgroundColor" is part of
> the
> > Object class, and would like to avoid using or producing software that
> > involves things like that.

> Why?

i have explained this a few times here already---this in particular is
primarily an esthetic issue. i find it conceptually displeasing to associate
the Object *concept* (which would be a superconcept of, say, List or
Integer) with facilities to determine its defaultBackgroundColor. i just
feel the latter does not belong to the former.

DISCLAIMER:
i am expressing and explaining *my* personal preference here. i have no
inclination or intention to try to convince you or anybody else of it.
(it seems this sort of thing is necessary when discussing stuff like this in
this community. sorry.)

Quote:
> While you would be unlikely to see a method like that in the base
> definition of Object in any Smalltalk dialect,

afaict it used to be part of squeak. maybe they took it out?

Quote:
> it wouldn't be surprising to
> see that method added to Object as a class extension by some framework. If
I
> were writing some graphical application - maybe a visual programming
tool -
> where any object could be displayed graphically on a canvas, it would seem
> reasonable - even desirable - for every object to respond with its default
> background color.

it wouldn't seem reasonable or desirable to me. but then i also feel that
not every object should be put onto a canvas.

Quote:
> Most commercial Smalltalk environments are highly modular and allow
> extension through subclassing as well as by class extension. In my
VisualAge
> Smalltalk environment, the core Object class only defines 28 methods. If I
> select the core definition of Object, that is all that I see. That said,
> their are dozens of sets of class extensions defining hundreds of
additional
> methods (none of them are "defaultBackgroundColor" though). If I don't use
> any of the frameworks that define those additional methods, none of them
> become part of my packaged application. In fact, I don't even see any of
> those additional methods in the browser unless I actually select one of
> class extensions that define them.

> The ability to add domain-specific behavior to core classes is a very
> powerful feature of most Smalltalk environments and one of the things that
I
> miss most when working in Java. In Java, I get an explosion of domain
> specific "helper" and "utility" classes that only exist to add the needed
> domain specific behavior to various existing classes.

that was what this discussion was about. for example, i have written a lot
of code in java, and quite a bit in smalltalk. i never had the urge to
extend the Object class in java, and i never extended smalltalk's Object
class. i used isKindOf instead of the common isXYZ methods whenever
possible, but the strict tree-structure of smalltalk's type system sometimes
made me grudgingly put isXYZ methods in some more specialized classes. these
circular dependencies between superclass and its subclasses (or rather
concept and subconcept) seem very ugly to me, it would seem an obvious issue
to be resolved by a slightly "richer" meta-structure. incidentally, this
would get rid of a good portion of the Object interface, which is usually
riddled with these methods.

as to "modular": the way i apply the term to programming languages the
"modules" are the lexical units what interact with each other whenever
feasible through explicit contracts.[*] in an object-oriented languages i
want to use, these units correspond to conceptual entities, usually classes,
which would imply that modules cannot be modified, since two distinct
lexical units would correspond to two distinct classes. what precisely are
the modules in smalltalk? it's certainly not the classes. parcels perhaps?
how explicit is their interaction with each other? what happens if their
modifications to the global class tree clash? when is this detected and how
is it fixed? the answers i have had from smalltalk on these and related
issues so far seem to suggest to me that at least my idea of "modularity" is
not very well supported there.

again, i am just trying to illustrate my preferences, since you asked me
"why". this is some of the why.

-- j

[*] java, for example, also violates that principle. while for the most part
it does use explicit contracts (even though they are quite lame contracts),
it fails to do so in the interaction between superclass and subclass---which
is a very sad design flaw. C# does a slightly better, but still not
sufficient job. i'd prefer explicit inheritance declaration as in, e.g.,
eiffel. in java, two overlapping interfaces that are implemented by the same
class also lead to undeclared interaction between lexical units, and can
create quite a surprise.



Fri, 24 Mar 2006 02:49:05 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"

says...

Quote:
> that was what this discussion was about. for example, i have written a lot
> of code in java, and quite a bit in smalltalk. i never had the urge to
> extend the Object class in java, and i never extended smalltalk's Object
> class. i used isKindOf instead of the common isXYZ methods whenever
> possible, but the strict tree-structure of smalltalk's type system sometimes
> made me grudgingly put isXYZ methods in some more specialized classes. these
> circular dependencies between superclass and its subclasses (or rather
> concept and subconcept) seem very ugly to me, it would seem an obvious issue
> to be resolved by a slightly "richer" meta-structure. incidentally, this
> would get rid of a good portion of the Object interface, which is usually
> riddled with these methods.

I've been working in Smalltalk professionally for ten years, and I've
never had the urge to use #isKindOf: or #isXYZ.  You're sending a
message to an object.  The object should know how to respond to that
message, or you're sending the message to the wrong object.  If I wanted
to introduce behavior that depended on the type of the object, I'd
introduce a double-dispatch mechanism rather than a bunch of #if
statements to do type checking.
--
============================================================
Thomas Koschate [|]

For PGP Key, see
http://keys.pgp.com:11371/pks/lookup?op=get&search=0xF45280AD



Fri, 24 Mar 2006 06:32:31 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"



Quote:

> says...
> > that was what this discussion was about. for example, i have written a
lot
> > of code in java, and quite a bit in smalltalk. i never had the urge to
> > extend the Object class in java, and i never extended smalltalk's Object
> > class. i used isKindOf instead of the common isXYZ methods whenever
> > possible, but the strict tree-structure of smalltalk's type system
sometimes
> > made me grudgingly put isXYZ methods in some more specialized classes.
these
> > circular dependencies between superclass and its subclasses (or rather
> > concept and subconcept) seem very ugly to me, it would seem an obvious
issue
> > to be resolved by a slightly "richer" meta-structure. incidentally, this
> > would get rid of a good portion of the Object interface, which is
usually
> > riddled with these methods.

> I've been working in Smalltalk professionally for ten years, and I've
> never had the urge to use #isKindOf: or #isXYZ.  You're sending a
> message to an object.  The object should know how to respond to that
> message, or you're sending the message to the wrong object.  If I wanted
> to introduce behavior that depended on the type of the object, I'd
> introduce a double-dispatch mechanism rather than a bunch of #if
> statements to do type checking.

that's the way it should be, but at least i found that it was sometimes
appropriate to check whether i could send some message to a given object. i
will try to dig out a concrete example, but i am not sure those things are
still around.

in any event, smalltalk vendors seem to see the need for this sort of
operation---there are about 20 such methods in squeak's Object class alone.

eliot miranda espouses a similar view in this post:
http://groups.google.com/groups?q=g:thl819845991d&dq=&hl=en&lr=&ie=UT...

his post admittedly compares isXYZ to isKindOf, but it is in reply to andy
bower raising the concerns you just raised, so it is reasonable to assume
that miranda sees at least some value in these testing methods. the
follow-ups to his post also contain some interesting angles on this point.

-- j



Fri, 24 Mar 2006 09:09:52 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"

Quote:


>> i, personally, find it butt-ugly if "defaultBackgroundColor" is part of
> the
>> Object class, and would like to avoid using or producing software that
>> involves things like that.

I've had people say the exact same thing about the number 3 being an
object.  It's just an integer, they say.  It should be something
"smaller" than an object.  It doesn't need to be able to get stuck in
generic arrays and it certianly doesn't need to have messages sent to
it.  It just doesn't "feel" right for integers to be objects.  It's
"ugly".

IMHO, it's important to use a tool, well, the way it's meant to be
used.  If you are religiously avoiding adding methods to Object, then
you are handicapping yourself.  Enjoy the difference between the
languages -- it gives some variety to life!

One big difference between the Java and Smalltalk programs is that
Java environments treat classes as units to be read and understood one
by one, while Smalltalk tends to work with cross-cutting packages.  A
Smalltalk package can include individual methods from various classes,
or from the other point of view, a Smalltalk class can be assembled
from multiple packages.

Object>>defaultBackgroundColor is a good example.  If you don't care
about this method and find it distasteful, then don't think about it.
Why are you thinking about it, anyway?  If you are working with the
framework that uses this method, *then* you will need to worry about
the method.  Otherwise, just leave it be and concentrate on your own
concerns.

-Lex



Fri, 24 Mar 2006 12:08:06 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"


Quote:


> >> i, personally, find it butt-ugly if "defaultBackgroundColor" is part of
> > the
> >> Object class, and would like to avoid using or producing software that
> >> involves things like that.

> I've had people say the exact same thing about the number 3 being an
> object.  It's just an integer, they say.  It should be something
> "smaller" than an object.  It doesn't need to be able to get stuck in
> generic arrays and it certianly doesn't need to have messages sent to
> it.  It just doesn't "feel" right for integers to be objects.  It's
> "ugly".

fine. it is not what *i* am saying, however, and it is also not "the exact
same thing" i am saying, because it is about something completely different.

Quote:
> IMHO, it's important to use a tool, well, the way it's meant to be
> used.

first of all, it is important to figure out *whether* you want to use the
tool in the first place. in doing so, people are (or at least, i am) guided
by their preferences, which are preferences about how they'd like to work,
the kinds of products they'd like to produce, and also and related to this,
what tools they'd like to use for this.

that is what my statement was about.

Quote:
> If you are religiously avoiding adding methods to Object, then
> you are handicapping yourself.  Enjoy the difference between the
> languages -- it gives some variety to life!

so you are saying one should not have preferences and act accordingly, but
should take every difference as a source of positive variety that has to be
enjoyed, even if you actually don't like it? is that what you are doing? how
do you ever make a choice?

Quote:
> One big difference between the Java and Smalltalk programs is that
> Java environments treat classes as units to be read and understood one
> by one, while Smalltalk tends to work with cross-cutting packages.  A
> Smalltalk package can include individual methods from various classes,
> or from the other point of view, a Smalltalk class can be assembled
> from multiple packages.

precisely. and one of those packaging units is a proper "module", while the
other is, well, a "package". for most of my software construction needs, i
tend to go with modules, although occasionally i feel all packagy, and then
i might use a language that allows more ad hoc freedom. embracing variety
right there!

Quote:
> Object>>defaultBackgroundColor is a good example.  If you don't care
> about this method and find it distasteful, then don't think about it.

i don't, as a rule. in fact, i had to dig it out of memory when asked why i
do not prefer smalltalk.

Quote:
> Why are you thinking about it, anyway?  If you are working with the
> framework that uses this method, *then* you will need to worry about
> the method.  Otherwise, just leave it be and concentrate on your own
> concerns.

oh sure. indeed, i leave it be in a big way, by using tools that make really
really sure that i won't find this method inadvertently at the root of my
class hierarchy. to me, it beats trying to not click on the wrong (among the
two or three dozen) protocol whenever i look at the Object class. ymmv.

-- j

[snip]



Fri, 24 Mar 2006 12:54:43 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"

...In my VisualAge

Quote:
> Smalltalk environment, the core Object class only defines 28 methods.

Right. I don't see the point of why these 28 methods should
be the (only) God-given methods that any Object must support.

We should have pretty strong *faith* in our vendor, for us
to be certain that they are the Ancient Ones who came up
with the eternally unchanging correct set of 28 methods
which every object must support - but no more.

(28 goes beyond string-theory!)

Naturally conflicts between the Gods - about which methods
are allowed in Object - are an issue on its own, but there
package-extensions and selector-namespaces can help.

Regards
-Panu Viljamaa



Sun, 26 Mar 2006 11:28:01 GMT  
 Strength of Type Checking: "Java is the SUV of programming tools"

Quote:
>> IMHO, it's important to use a tool, well, the way it's meant to be
>> used.

> first of all, it is important to figure out *whether* you want to use the
> tool in the first place. in doing so, people are (or at least, i am) guided
> by their preferences, which are preferences about how they'd like to work,
> the kinds of products they'd like to produce, and also and related to this,
> what tools they'd like to use for this.

> that is what my statement was about.

Yes, I understand.  But if you consider Smalltalk as a whole, then you
might have a different taste.  *My* point is that you can't always
evaluate individual details like this without taking them in the
context of the whole system.

For example, it would indeed be ugly to hack java.lang.Object to add
isFoo() methods.  Java has an interfaces mechanism that works for
this, and further it's {*filter*} your tools if you change the system
classes.  The situation is quite different in Smalltalk.

-Lex



Tue, 28 Mar 2006 03:04:23 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. "like Current" and static type checking

2. type checking/inferencing for "beginners"

3. No Boolean type in "types"

4. Type checking strength

5. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

6. about utility program named "Winteracter "...i need any information about the program..^^

7. programs in "Effective Tcl programming"

8. Setting "checked" property on menu item

9. Check Characters "cc"

10. Interesting change in "bounds checking"

11. Conditional "checking"

12. "Annoying" subscript checking

 

 
Powered by phpBB® Forum Software