Static typing is needed when.. 
Author Message
 Static typing is needed when..

.. Your using a language without method selectors.

After reading this thread for a few days and watching the arguments for one
over the other fly by each other this AM I was wondering why I haven't had a
type error in over a year using Smalltalk.  Then it occurred to me, between
method selectors and the IDE you'd have to be an idiot to send the wrong class
of argument.

In languages where the arguments to a function are positional the programmer
has to remember the order and types of arguments.  As good as they get (and
I'd like to think I'm a fairly decent C programmer) I always forget the order
of arguments of fprintf().  Does the stream handle go at the front or the
beginning?  I think write() uses the handle at the beginning doesn't it?
(thoughts to myself while coding).

That process doesn't exist in Smalltalk.  If I ever try to invoke a method
with the wrong selectors Smalltalk tells me, "Warning: there are no methods
with the selectors.. proceed?"  Whoops!  Better browse "Implementors of ..."
to see the correct way to do it.

If you always knew what arguments a function needed, and new exactly in what
order to provide them, no language would need to check such things.  In
Smalltalk, the need just doesn't exist.

Sure, a couple times I've omitted a parenthese and the wrong message was sent
to the wrong object, but that was an error of mine in precedence, not of
typing.  Static typing wouldn't have helped.

--
.tom



Mon, 08 Sep 2003 21:15:25 GMT  
 Static typing is needed when..


Quote:

>I'd like to think I'm a fairly decent C programmer) I always forget the order
>of arguments of fprintf().  Does the stream handle go at the front or the
>beginning?

Or both!

--
--
Patrick Doyle



Mon, 08 Sep 2003 23:29:47 GMT  
 Static typing is needed when..
Quote:

> .. Your using a language without method selectors.

> After reading this thread for a few days and watching the arguments for one
> over the other fly by each other this AM I was wondering why I haven't had a
> type error in over a year using Smalltalk.  Then it occurred to me, between
> method selectors and the IDE you'd have to be an idiot to send the wrong class
> of argument.

TG> In languages where the arguments to a function are positional the
TG> programmer has to remember the order and types of arguments.  As
TG> good as they get (and I'd like to think I'm a fairly decent C
TG> programmer) I always forget the order of arguments of fprintf().
TG> Does the stream handle go at the front or the beginning?  I think
TG> write() uses the handle at the beginning doesn't it? (thoughts to
TG> myself while coding).

This is beside the point but IMO if someone does not remember the
arguments to fprintf() one is not an experienced C programmer.  FYI
while fprintf() takes _streams_ as arguemnts; write() takes _file_
_descriptors_.  The two are quite different animals.

TG> That process doesn't exist in Smalltalk.  If I ever try to invoke
TG> a method with the wrong selectors Smalltalk tells me, "Warning:
TG> there are no methods with the selectors.. proceed?"  Whoops!
TG> Better browse "Implementors of ..." to see the correct way to do
TG> it.

Right, when you try to "invoke" it.  Thus if you write a piece of
code that contains a mistake but it (the piece of code) is never
invoked during unit-test, you will never catch it during unit-test.

On the other hand, a compiler will catch all type errors (that
the compiler is designed to catch) regardless of how the unit-test
(if any) is written.

I am not saying that one is better than the other but do you
see the difference in terms of coverage?

Tak
-----------------------------------------------------------+----------

--------------------------------------------------------------------^^
 [taode takto 陶德]      NB: trim the .- to get my real email addr



Mon, 08 Sep 2003 23:49:30 GMT  
 Static typing is needed when..

Quote:
> .. Your using a language without method selectors.

It is certainly true that a lot of the 'documentation' aspect
of static types is covered by method selectors. Not necessarily
*all* of it: there are still things like local variables and
members to consider. But good naming practices and
very small methods can help with these.

There is, as always, more than one way to skin a cat.

[snip]

Quote:
> That process doesn't exist in Smalltalk.  If I ever try to invoke a method
> with the wrong selectors Smalltalk tells me, "Warning: there are no
> methods with the selectors.. proceed?"  Whoops!  Better browse
> "Implementors of..." to see the correct way to do it.

This is a static type check, you know.

It's not nearly as elaborate as the ones in C++, but verifying before
executing that there is at least one class with the mentioned method
is a static type correctness check.

And here you thought Smalltalk was dynamic. :P

[snip]

Quote:
> Sure, a couple times I've omitted a parenthese and the wrong message was
> sent to the wrong object, but that was an error of mine in precedence, not
of
> typing.  Static typing wouldn't have helped.

Really?

Personally I find that I also make mistakes of this kind, and that
static checking seems to detect them.

Mind you, I'd expect other mechanisms, like unit tests, to also
be able to detect such errors with fair-ta-middling reliability. :D



Tue, 09 Sep 2003 00:44:16 GMT  
 Static typing is needed when..

Quote:


> > .. Your using a language without method selectors.

> > After reading this thread for a few days and watching the arguments for
> one
> > over the other fly by each other this AM I was wondering why I haven't had
> a
> > type error in over a year using Smalltalk.  Then it occurred to me,
> between
> > method selectors and the IDE you'd have to be an idiot to send the wrong
> class
> > of argument.

> TG> In languages where the arguments to a function are positional the
> TG> programmer has to remember the order and types of arguments.  As
> TG> good as they get (and I'd like to think I'm a fairly decent C
> TG> programmer) I always forget the order of arguments of fprintf().
> TG> Does the stream handle go at the front or the beginning?  I think
> TG> write() uses the handle at the beginning doesn't it? (thoughts to
> TG> myself while coding).

> This is beside the point but IMO if someone does not remember the
> arguments to fprintf() one is not an experienced C programmer.  FYI
> while fprintf() takes _streams_ as arguemnts; write() takes _file_
> _descriptors_.  The two are quite different animals.

I disagree, but it's not real important.  Some people remember minutia but can
fathom elegant algorithms for solving problems.  Other people hack their way
to a solution but can remember all the details of every API they've ever
used.  I won't venture to say I'm the former, but I'm certainly not the
latter.  Which reminds me, in calloc(), which argument is the number of
elements and which is the size of the elements?  I can never remember that one
either.

Quote:
> TG> That process doesn't exist in Smalltalk.  If I ever try to invoke
> TG> a method with the wrong selectors Smalltalk tells me, "Warning:
> TG> there are no methods with the selectors.. proceed?"  Whoops!
> TG> Better browse "Implementors of ..." to see the correct way to do
> TG> it.

> Right, when you try to "invoke" it.  Thus if you write a piece of
> code that contains a mistake but it (the piece of code) is never
> invoked during unit-test, you will never catch it during unit-test.

Actually, it's not when you invoke it, but when you compile it.  After coding
the method you have to "accept" it.  It's after you "accept" the method the
error appears--so you don't have to wait until you run the method.  I think
what you may be thinking of is the messageNotUnderstood exception which
happens when you send a valid method to an object that doesn't implement it.

Quote:
> On the other hand, a compiler will catch all type errors (that
> the compiler is designed to catch) regardless of how the unit-test
> (if any) is written.

> I am not saying that one is better than the other but do you
> see the difference in terms of coverage?

Yea.  But I think the static method is valuable to the environments that
implement it because they don't have a Smalltalk-like dependency mechanism or
an equivalent IDE.

One other thing I forgot earlier (see how I am?) is include files.  Smalltalk
doesn't have them because the entire environment is available at all times.
One of the frustrating things about statically types languages is having to
know which files to include, and sometimes in which order.  This goes for
Python's import statements as well.  I don't miss not having those in
Smalltalk.
--
.tom

--
.tom



Tue, 09 Sep 2003 02:19:46 GMT  
 Static typing is needed when..

Quote:
> If I ever try to invoke a method with the wrong selectors Smalltalk
> tells me, "Warning: there are no methods with the selectors.. proceed?"

Yes! And this is a static check, agreed? It is a cheap and simple one,
and crude, but it is clearly static in that it does not rely on executing
the checked code. Here you are arguing in favour of static checking.

When static checking can be made cheap and unobtrusive, it's good. Sane
programmers embrace it, whatever their persuasion. Smalltalkers are not
against static checking in general, but only certain kinds of obtrusive
checks.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,

                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



Tue, 09 Sep 2003 04:07:00 GMT  
 Static typing is needed when..
Eiffel is statically typed but has no requirement for include files.
(Not taking part in the overall argument, just this point)

Regards
Chris Saunders


Quote:

> One other thing I forgot earlier (see how I am?) is include files.
Smalltalk
> doesn't have them because the entire environment is available at all
times.
> One of the frustrating things about statically types languages is having
to
> know which files to include, and sometimes in which order.  This goes for
> Python's import statements as well.  I don't miss not having those in
> Smalltalk.
> --
> .tom

> --
> .tom



Tue, 09 Sep 2003 05:44:18 GMT  
 Static typing is needed when..


Quote:

>This is beside the point but IMO if someone does not remember the
>arguments to fprintf() one is not an experienced C programmer.

Besides the fact that this is bull, it also appears to imply that
inexperienced C programmers are not worth considering.  Surely you
don't believe that?  What about someone experienced with Java who
finds himself in the position of having to write some C code?

--
--
Patrick Doyle



Tue, 09 Sep 2003 05:50:32 GMT  
 Static typing is needed when..

Quote:

> TG> That process doesn't exist in Smalltalk.  If I ever try to invoke
> TG> a method with the wrong selectors Smalltalk tells me, "Warning:
> TG> there are no methods with the selectors.. proceed?"  Whoops!
> TG> Better browse "Implementors of ..." to see the correct way to do
> TG> it.

> Right, when you try to "invoke" it.

Not necessarily. In my Smalltalk IDE (VisualAge), misspelled method
selectors, references to missing methods and a variety of other syntactical
problems are highlighted in red immediately as I type. I don't have to
invoke the code or even save the method to become aware of the problem. A
misspelled selector can be fixed by right-clicking on it and selecting
"Correct Spelling". This is just another form of static type check (although
a very unobtrusive one). I don't remember the last time I encountered a type
error doing VA Smalltalk development once that IDE feature was in place.

-Eric



Tue, 09 Sep 2003 11:55:04 GMT  
 Static typing is needed when..

Quote:

> In languages where the arguments to a function are positional the programmer
> has to remember the order and types of arguments.  As good as they get (and
> I'd like to think I'm a fairly decent C programmer) I always forget the order
> of arguments of fprintf().

Static typing doesn't address this particular problem at all.

For example, consider a function that scans a string `haystack' for a
substring `needle' and returns the index where it found it. Both
arguments are of type string, so you can call

   has_substring(haystack, needle)

or

   has_substring(needle, hackstack)

and the compiler will accept it.

In the theory of human error, this is "description error", resulting
from an insufficient specification for the action to perform. Of
course, you can obtain more specification by looking up the docs (or
contracts in case of Eiffel), but this is time consuming, and there is
no guarantee that the developer will do it.

The general solution for this type of error is to enforce a more exact
specification. Nobody cares about the types in the first place, rather
than the meaning. The actual meaning of an argument is assigned by the
name. So, enforce that the name has to be specified in the call, for
example:

   has_substring(haystack = .., neddle = ..)

For a sample implementation, take a look at Ada (though I think it's
just an option, and not enforced as soon arguments have the same type.
So there is still room for improvement.)

Of course, you can also solve this particular problem using OO
notation like

   haystack.has_substring(needle)

but it's easy to think of an example with more parameters of the same
type, for instance was it line(x1,x2,y1,y2) or line(x1,y1,x2,y2)?
                                  ^^                      ^^
Regards, Thomas.



Tue, 09 Sep 2003 14:06:23 GMT  
 Static typing is needed when..

Quote:

>For example, consider a function that scans a string `haystack' for a
>substring `needle' and returns the index where it found it. Both
>arguments are of type string, so you can call
>   has_substring(haystack, needle)
>or
>   has_substring(needle, hackstack)
>and the compiler will accept it.

Of course, this *can* be addressed with static typing.  You just
need to introduce the types "searchable string" and "search string"...

;-)

Marcel
--

Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS.
                                          - Alan Kay -



Tue, 09 Sep 2003 16:04:53 GMT  
 Static typing is needed when..

Quote:


> > In languages where the arguments to a function are positional the programmer
> > has to remember the order and types of arguments.  As good as they get (and
> > I'd like to think I'm a fairly decent C programmer) I always forget the order
> > of arguments of fprintf().

> Static typing doesn't address this particular problem at all.

> For example, consider a function that scans a string `haystack' for a
> substring `needle' and returns the index where it found it. Both
> arguments are of type string, so you can call

>    has_substring(haystack, needle)

> or

>    has_substring(needle, hackstack)

> and the compiler will accept it.

Good point.  That will get past the compiler.

- Show quoted text -

Quote:
> In the theory of human error, this is "description error", resulting
> from an insufficient specification for the action to perform. Of
> course, you can obtain more specification by looking up the docs (or
> contracts in case of Eiffel), but this is time consuming, and there is
> no guarantee that the developer will do it.

> The general solution for this type of error is to enforce a more exact
> specification. Nobody cares about the types in the first place, rather
> than the meaning. The actual meaning of an argument is assigned by the
> name. So, enforce that the name has to be specified in the call, for
> example:

>    has_substring(haystack = .., neddle = ..)

> For a sample implementation, take a look at Ada (though I think it's
> just an option, and not enforced as soon arguments have the same type.
> So there is still room for improvement.)

> Of course, you can also solve this particular problem using OO
> notation like

>    haystack.has_substring(needle)

> but it's easy to think of an example with more parameters of the same
> type, for instance was it line(x1,x2,y1,y2) or line(x1,y1,x2,y2)?
>                                   ^^                      ^^
> Regards, Thomas.

Another good point.

--
.tom



Tue, 09 Sep 2003 19:42:00 GMT  
 Static typing is needed when..
In reply to Patrick Doyle:


TT> This is beside the point but IMO if someone does not remember
TT> the arguments to fprintf() one is not an experienced C
TT> programmer.

PD> Besides the fact that this is bull,

How so?

Let me just give a couple of my reasons:

 - an experienced C programmer should have written enough trace
   statements for debugging to know the prototype of fprintf();

 - an experienced C programmer should have long recognized the
   similarity between the prototypes of printf(), fprintf()
   and sprintf();

What is your reason for saying that it is bull?

PD> it also appears to imply that inexperienced C programmers
PD> are not worth considering.

I am not sure I understand what you are saying: considering
the programmer? (And for what?) Or considering his opinion on
C vs Smalltalk?  In any case I don't think I have implied
anything as strong as "not worth considering".

PD> Surely you don't believe that?  What about someone
PD> experienced with Java who finds himself in the position
PD> of having to write some C code?

Does he claim to be a "fairly decent C programmer"? :-)

Tak
-----------------------------------------------------------+----------

--------------------------------------------------------------------^^
 [taode takto 陶德]      NB: trim the .- to get my real email addr



Tue, 09 Sep 2003 23:50:04 GMT  
 Static typing is needed when..

Quote:
>This is beside the point but IMO if someone does not remember the
>arguments to fprintf() one is not an experienced C programmer.

Nah.  Expertise in minutia isn't nearly as important as large-scale
problem-solving ability.  If I was forced to develop an application in C, I'd
want a few folks with broad architectural experience in software design and
implementation than a few experts in C who know the details of the standard
library.  Language and library expertise can be picked up faster; after all,
that's what reference books are for.

Related: I'm a "senior pilot" in the Huey, with over 2000 hours, and have been
an instructor for several years.  And as a rule, when instructing a student, I
*never ever* rely on my memory as the sole source of information; I pull out the
reference manual.  I don't have the hubris to declare myself an expert; humans
are fallible.  So when I'm developing, with all my reference material close by,
I'm sure as heck not going to rely on my fallible memory then either!

I think a better solution to the problem of mismatched arguments is the use of
keyword arguments *as part of the method signature*, as implemented by smalltalk
(although I'd rather have the arguments completely separated from the method
name, ie instead of "MoveToX: 42 y: 13", I'd rather see "MoveTo X:42 Y:13",
which is a very minor change).  It's a simple and effective change, and really
improves readability.  Yes, it takes longer to code, but heck, as early as the
late '70s, folks like Yourdon and Constantine were noting that coding is about
1/6th of the effort in a project (or less), while testing is more like half.
Readability is important!  Makes me wish ObjectiveC had become the standard
instead of C++...

-->VPutz



Wed, 10 Sep 2003 00:20:47 GMT  
 Static typing is needed when..


Quote:
>In reply to Patrick Doyle:


>TT> This is beside the point but IMO if someone does not remember
>TT> the arguments to fprintf() one is not an experienced C
>TT> programmer.


>PD> Besides the fact that this is bull,

>How so?

Well, this is not a very important issue, so it probably doesn't
deserve much more thought from either of us.  However, I guess
I started this, so you deserve an explanation.  :-)

In general, I don't think it's reasonable to expect programmers
of a language to memorize its standard libraries.  Language features: yes,
but libraries: no.

In particular, is it logical that the file descriptor comes before
the format string?  Why not after it?  If I can't remember which
is right, does that mean I'm not an experienced C programmer?

Quote:
>PD> it also appears to imply that inexperienced C programmers
>PD> are not worth considering.

>I am not sure I understand what you are saying: considering
>the programmer? (And for what?) Or considering his opinion on
>C vs Smalltalk?  In any case I don't think I have implied
>anything as strong as "not worth considering".

Ok, I take that back.  It's really not worth discussing.
Please accept my appologies for saying it in the first place.

--
--
Patrick Doyle



Wed, 10 Sep 2003 01:50:09 GMT  
 
 [ 63 post ]  Go to page: [1] [2] [3] [4] [5]

 Relevant Pages 

1. Types, types: static vs. dynamic -- classification

2. Types, types: static vs. dynamic --

3. Types, types: static vs. dynamic -- classification

4. x/0 as a type error [Extremely static typing]

5. opacity and static typing (Re: Type checkers for scheme)

6. Types, types: static vs. dynamic -- classification

7. Provide an option: static typing + type inference ?

8. Flying With Python (Strong versus Weak Typing) [actually, Static vs Dynamic typing]

9. Static vs Dynamic Typing: Effects on Productivity?

10. static/dynamic typing, or stability?

11. Why the emphasis on static typing?

 

 
Powered by phpBB® Forum Software