Smalltalk › Squeak › Squeak - Dev

[squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Randal L. Schwartz

[squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

I'm giving a talk in two weeks on the advantages of value typing (aka duck
typing or late binding) vs variable typing (aka compile-time typing or [ugh]
"strong typing"). I'll certainly be drawing on my nearly-four-decade
experience of programming, but if any of you have a favorite paper
or slide deck or anecdote to share in this area, please point me.
I'll make the result available under a generous license. Thanks.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Damien Cassou-3

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

On Fri, Apr 10, 2009 at 12:17 AM, Randal L. Schwartz
<[hidden email]> wrote:
> I'm giving a talk in two weeks on the advantages of value typing (aka duck
> typing or late binding) vs variable typing (aka compile-time typing or [ugh]
> "strong typing"). I'll certainly be drawing on my nearly-four-decade
> experience of programming, but if any of you have a favorite paper
> or slide deck or anecdote to share in this area, please point me.
> I'll make the result available under a generous license. Thanks.

A very interesting article that anyone interested in the topic must
read: "What To Know Before Debating Type Systems"
http://www.pphsg.org/cdsmith/types.html

--
Damien Cassou
http://damiencassou.seasidehosting.st

Ralph Johnson

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

> A very interesting article that anyone interested in the topic must
> read: "What To Know Before Debating Type Systems"
> http://www.pphsg.org/cdsmith/types.html

i disagree that "strong typing" doesn't mean anything. Weak typing
means "has a type system but it is easy to get around it". Strong
typing means "has a type system and you can't get around it easily".
Strong typing certainly does NOT mean compile-time typing.

I agree that "dynamic" (checked at run-time) vs. "static" (checked at
compile-time) is what is important. C and Fortran have weak static
type systems. Java has a strong static type system, but only because
casts are checked at run-time, i.e. the static type system has holes
in it but the run-time system patches those holes. Smalltalk has a
strong dynamic type system; there is no way to run a method on an
object that it doesn't belong to.

I thought that the comments about the relative importance of testing
was interesting. However, I find that it is just as important to do
unit testing in Java as in Smalltalk. I disagree with the assumption
that implicit types (i.e. type inference) makes things easy. I
haven't done any programming in ML or Hascall but I used to share an
office with a couple of ML fans and every so often they would get a
type error that took them a very long time to understand. Type
inference is great when it works, not so great when it doesn't.

The big advantage of dynamic types over static types is that static
type system are conservative, so they will sometimes keep you from
writing programs that would work with a dynamic type system. On the
other hand, languages keep getting more powerful type systems, so this
advantage is shrinking.

-Ralph Johnson

Philippe Marschall

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

2009/4/10 Ralph Johnson <[hidden email]>:

>> A very interesting article that anyone interested in the topic must
>> read: "What To Know Before Debating Type Systems"
>> http://www.pphsg.org/cdsmith/types.html
>
> i disagree that "strong typing" doesn't mean anything. Weak typing
> means "has a type system but it is easy to get around it". Strong
> typing means "has a type system and you can't get around it easily".
> Strong typing certainly does NOT mean compile-time typing.
>
> I agree that "dynamic" (checked at run-time) vs. "static" (checked at
> compile-time) is what is important. C and Fortran have weak static
> type systems. Java has a strong static type system, but only because
> casts are checked at run-time, i.e. the static type system has holes
> in it but the run-time system patches those holes. Smalltalk has a
> strong dynamic type system; there is no way to run a method on an
> object that it doesn't belong to.

#valueWithReceiver:arguments:?

Cheers
Philippe

Igor Stasenko

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

2009/4/10 Philippe Marschall <[hidden email]>:

> 2009/4/10 Ralph Johnson <[hidden email]>:
>>> A very interesting article that anyone interested in the topic must
>>> read: "What To Know Before Debating Type Systems"
>>> http://www.pphsg.org/cdsmith/types.html
>>
>> i disagree that "strong typing" doesn't mean anything. Weak typing
>> means "has a type system but it is easy to get around it". Strong
>> typing means "has a type system and you can't get around it easily".
>> Strong typing certainly does NOT mean compile-time typing.
>>
>> I agree that "dynamic" (checked at run-time) vs. "static" (checked at
>> compile-time) is what is important. C and Fortran have weak static
>> type systems. Java has a strong static type system, but only because
>> casts are checked at run-time, i.e. the static type system has holes
>> in it but the run-time system patches those holes. Smalltalk has a
>> strong dynamic type system; there is no way to run a method on an
>> object that it doesn't belong to.
>
> #valueWithReceiver:arguments:?
>

Right. But. Is given method is part of standard?
IMO this is a dirty hack, which could crash the VM, if primitive
doesn't checking receiver & method class compatibility.

A secure VM could reject implementing primitive at all, and then as a
workaround, all you can do is temporarily compile&install given method
in receiver's class and only then send a message.

There are many cases, when bypassing a message lookup semantics is
undesirable and ignoring the intents of developer. For instance, a
transparent proxy will not function correctly for such cases.
Also squeak already having some optimization, a limited set of
selectors, which are bypassing lookup (#class #== ).
But again, this is implementation detail. IMO, in most standard/pure
form, a language implementation should not provide a ways, how you can
bypass a message lookup semantics.

> Cheers
> Philippe
>
>

--
Best regards,
Igor Stasenko AKA sig.

Stephen Pair

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

In reply to this post by Randal L. Schwartz

On Thu, Apr 9, 2009 at 6:17 PM, Randal L. Schwartz <[hidden email]> wrote:

I'm giving a talk in two weeks on the advantages of value typing (aka duck
typing or late binding) vs variable typing (aka compile-time typing or [ugh]
"strong typing"). I'll certainly be drawing on my nearly-four-decade
experience of programming, but if any of you have a favorite paper
or slide deck or anecdote to share in this area, please point me.
I'll make the result available under a generous license. Thanks.

While not directly addressing the topic of static vs dynamic type checking systems, I think the following paper by Gilad Bracha provides good insight on the subject (and reflects his experience on the subject with Strongtalk):

http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Bracha.pdf

For me, the problem with statically typed languages isn't that they have a type checking system, it's that they have a pathetically inept and inhibiting type checking system.

- Stephen

Philippe Marschall

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

In reply to this post by Igor Stasenko

2009/4/10 Igor Stasenko <[hidden email]>:

> 2009/4/10 Philippe Marschall <[hidden email]>:
>> 2009/4/10 Ralph Johnson <[hidden email]>:
>>>> A very interesting article that anyone interested in the topic must
>>>> read: "What To Know Before Debating Type Systems"
>>>> http://www.pphsg.org/cdsmith/types.html
>>>
>>> i disagree that "strong typing" doesn't mean anything. Weak typing
>>> means "has a type system but it is easy to get around it". Strong
>>> typing means "has a type system and you can't get around it easily".
>>> Strong typing certainly does NOT mean compile-time typing.
>>>
>>> I agree that "dynamic" (checked at run-time) vs. "static" (checked at
>>> compile-time) is what is important. C and Fortran have weak static
>>> type systems. Java has a strong static type system, but only because
>>> casts are checked at run-time, i.e. the static type system has holes
>>> in it but the run-time system patches those holes. Smalltalk has a
>>> strong dynamic type system; there is no way to run a method on an
>>> object that it doesn't belong to.
>>
>> #valueWithReceiver:arguments:?
>>
> Right. But. Is given method is part of standard?

What does that change?

> IMO this is a dirty hack, which could crash the VM, if primitive
> doesn't checking receiver & method class compatibility.

Sounds pretty much like weak typing to me.

> A secure VM could reject implementing primitive at all, and then as a
> workaround, all you can do is temporarily compile&install given method
> in receiver's class and only then send a message.

Right and a multithreaded VM could, ... and an optimizing JIT could ...

Cheers
Philippe

Igor Stasenko

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

2009/4/10 Philippe Marschall <[hidden email]>:

> 2009/4/10 Igor Stasenko <[hidden email]>:
>> 2009/4/10 Philippe Marschall <[hidden email]>:
>>> 2009/4/10 Ralph Johnson <[hidden email]>:
>>>>> A very interesting article that anyone interested in the topic must
>>>>> read: "What To Know Before Debating Type Systems"
>>>>> http://www.pphsg.org/cdsmith/types.html
>>>>
>>>> i disagree that "strong typing" doesn't mean anything. Weak typing
>>>> means "has a type system but it is easy to get around it". Strong
>>>> typing means "has a type system and you can't get around it easily".
>>>> Strong typing certainly does NOT mean compile-time typing.
>>>>
>>>> I agree that "dynamic" (checked at run-time) vs. "static" (checked at
>>>> compile-time) is what is important. C and Fortran have weak static
>>>> type systems. Java has a strong static type system, but only because
>>>> casts are checked at run-time, i.e. the static type system has holes
>>>> in it but the run-time system patches those holes. Smalltalk has a
>>>> strong dynamic type system; there is no way to run a method on an
>>>> object that it doesn't belong to.
>>>
>>> #valueWithReceiver:arguments:?
>>>
>> Right. But. Is given method is part of standard?
>
> What does that change?
>
>> IMO this is a dirty hack, which could crash the VM, if primitive
>> doesn't checking receiver & method class compatibility.
>
> Sounds pretty much like weak typing to me.
>
>> A secure VM could reject implementing primitive at all, and then as a
>> workaround, all you can do is temporarily compile&install given method
>> in receiver's class and only then send a message.
>
> Right and a multithreaded VM could, ... and an optimizing JIT could ...
>

Let's not mix a VM side and language side altogether. If you bury deep
into VM, you will find that there a very small number of primitives
checking which don't have any type checks.
>From your POV, then it would be right to say, that smalltalk is weakly
typed language, because its VM implemented in C.

> Cheers
> Philippe
>
>

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko

Re: [squeak-dev] looking for papers/anecdotes/slide-decks on variable typing vs value typing

2009/4/10 Igor Stasenko <[hidden email]>:

> 2009/4/10 Philippe Marschall <[hidden email]>:
>> 2009/4/10 Igor Stasenko <[hidden email]>:
>>> 2009/4/10 Philippe Marschall <[hidden email]>:
>>>> 2009/4/10 Ralph Johnson <[hidden email]>:
>>>>>> A very interesting article that anyone interested in the topic must
>>>>>> read: "What To Know Before Debating Type Systems"
>>>>>> http://www.pphsg.org/cdsmith/types.html
>>>>>
>>>>> i disagree that "strong typing" doesn't mean anything. Weak typing
>>>>> means "has a type system but it is easy to get around it". Strong
>>>>> typing means "has a type system and you can't get around it easily".
>>>>> Strong typing certainly does NOT mean compile-time typing.
>>>>>
>>>>> I agree that "dynamic" (checked at run-time) vs. "static" (checked at
>>>>> compile-time) is what is important. C and Fortran have weak static
>>>>> type systems. Java has a strong static type system, but only because
>>>>> casts are checked at run-time, i.e. the static type system has holes
>>>>> in it but the run-time system patches those holes. Smalltalk has a
>>>>> strong dynamic type system; there is no way to run a method on an
>>>>> object that it doesn't belong to.
>>>>
>>>> #valueWithReceiver:arguments:?
>>>>
>>> Right. But. Is given method is part of standard?
>>
>> What does that change?
>>
>>> IMO this is a dirty hack, which could crash the VM, if primitive
>>> doesn't checking receiver & method class compatibility.
>>
>> Sounds pretty much like weak typing to me.
>>
>>> A secure VM could reject implementing primitive at all, and then as a
>>> workaround, all you can do is temporarily compile&install given method
>>> in receiver's class and only then send a message.
>>
>> Right and a multithreaded VM could, ... and an optimizing JIT could ...
>>
> Let's not mix a VM side and language side altogether. If you bury deep
> into VM, you will find that there a very small number of primitives
> checking which don't have any type checks.

oops, typing in a hurry..
i meant: there are very small number of primitives which don't have
any type/safety checks.

> From your POV, then it would be right to say, that smalltalk is weakly
> typed language, because its VM implemented in C.
>
>> Cheers
>> Philippe
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

--
Best regards,
Igor Stasenko AKA sig.