On Wed, 19 Apr 2000 04:26:07 GMT, Ian Upright <········@upright.net>
wrote:
>"Patrick D. Logan" <·············@home.com> wrote:
>
>>Common Lisp and Dylan are two languages that have optional static
>>types. Common Lisp is complex for its historical baggage, not
>>really for its optional static types. Dylan is not really complex
>>relative to Common Lisp or Java.
>
>Doesn't Objective-C count as one too? I'm sure there are several others.
Are there any war stories about mixing typing paradigms?
The question here is: can anyone talk about an experience in a project
where both static and dynamic typing were in use at the same time?
Why were both paradigms in use? What were the advantages and
disadvantages of each? Were there any difficulties inherent to having
both in the same project?
This is not meant as fodder for a flame war. Rather, I think that
communication will serve to dissipate a lot of misconceptions and
prejudices.
--
Peter Kwangjun Suk
Cincom Systems, Inc.
···@pobox.com http://ostudio.swiki.net
(comp.lang.java.advocacy killfile poster-child -- Scene, not Herd!)
Peter Kwangjun Suk wrote:
>
> Are there any war stories about mixing typing paradigms?
>
> The question here is: can anyone talk about an experience in a project
> where both static and dynamic typing were in use at the same time?
Anybody who has done NeXTSTEP development has had that experience.
Every NeXTSTEP program I looked at, or wrote, or assisted in writing,
used both, although every one of them relied predominantly on dynamic
typing.
> Why were both paradigms in use? What were the advantages and
> disadvantages of each?
One disadvantage of using static typing was that the compiler needed
some information on the type before you could use it in variable
declarations, and this occasionally resulted in "catch-22" cycles that
complicated the makefile (remember, Objective-C uses the
"edit/compile/link/test" development methodology, and NeXTSTEP also used
a 'makefile' as is common in C-based work, although it's use was pretty
well hid in the ProjectBuilder application).
Back when I used to do NeXTSTEP development, I wasn't as "anti-static
typing" as I am now, and I have to admit I occasionally used it. I
thought at the time that it made it easier to bullet-proof service code
that was intended to be used by many clients because I could constrain
the types of the arguments.
> Were there any difficulties inherent to having
> both in the same project?
No, not for a typical "edit/compile/link/test" declarative environment
(if that is the kind of environment a person likes, which I don't like
any longer). In such an environment, it was pretty-much transparent
during debugging, because you couldn't even get to that stage unless it
passed the compiler. And, during development you got from the compiler
what I considered at the time to be rapid feedback as well (but I
wouldn't think the same now), so at the time I didn't think it was a big
deal.
In fact, prior to that experience, I came from the static-typing camp,
so the ability to use dynamic typing was the thing that was a novelty
for me. Coming from that background, your question would translate to
"where there any difficulties inherent in introducing the addition of
dynamic typing into a typical static-typing project?", and my answer is
'no'. It didn't take long to see the advantages of dynamic typing, and
it didn't take long at all before that is what I predominantly used.
Nevin Pratt
Nevin Pratt wrote in message <·················@mail.xmission.com>...
>> The question here is: can anyone talk about an experience in a project
>> where both static and dynamic typing were in use at the same time?
>
>Anybody who has done NeXTSTEP development has had that experience.
>Every NeXTSTEP program I looked at, or wrote, or assisted in writing,
>used both, although every one of them relied predominantly on dynamic
>typing.
But NeXT itself changed from dynamic to static typing. In their old code you'd see a lot of
id window;
and in the new code
NSWindow window.
Also the method signatures used to use 'id' but now use a type, including the return type. They also suggest you use static typing instead of dynamic typing.
Maurice.
Peter Kwangjun Suk wrote:
> Are there any war stories about mixing typing paradigms?
>
> The question here is: can anyone talk about an experience in a project
> where both static and dynamic typing were in use at the same time?
Yes, my current project.
Accounting system being written in C++. All the system-level stuff uses
static typing, but the actual application-level code is on top of a
framework that effectively allows dynamic typing to be used.
> Why were both paradigms in use? What were the advantages and
> disadvantages of each?
The system-level code uses static typing because - well, I'm writing it
in C++, the language provides static typing, so I might as well make use
of it, the convenience of having the compiler catch errors for me is
worth the effort of keying in the type declarations.
The application code uses dynamic typing for the sake of automation. I
want to be able to say things like "from table Account, display Account
No, Name, Address and Balance", and have it work correctly even though
Balance is a numeric field whereas the others are strings. That means
the system needs to be able to look up the fields, figure out what types
they are and take action accordingly; dynamic typing.
> Were there any difficulties inherent to having
> both in the same project?
I haven't come across any, apart from the fairly trivial effort of
implementing the dynamic type system.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@iol.ie
····@cincom.com (Peter Kwangjun Suk) writes:
>The question here is: can anyone talk about an experience in a project
>where both static and dynamic typing were in use at the same time?
Well, almost any software produced as part of or with Cocoa, Apple's
OO toolkit for MacOS-X (former NeXTStep) uses both.
>Why were both paradigms in use? What were the advantages and
>disadvantages of each? Were there any difficulties inherent to having
>both in the same project?
Dynamic typing is typicaly used initially, static types (interfaces
or actualy classes) are added when you are certain about objects
that will be used. This is typically easy when the object in
question is an instance variable that you yourself initialize.
Often enough, this is going to be exactly one kind of object, and
you might as well say that as it does make the code easier to read
and understand.
Another way is defining significant protocols. For example the
interface between my PS interpreter and consumers of graphical
objects is defined by a protocol. This makes it easy to specify
and document important interactions between the objects in you
system.
Other less important interactions do not require this documentation
or are still more volatile. Being able to say "I don't care" in
specific circumstance is valuable, as is being able to deal with
relationships that the static type-checker can't deal with.
Overall, it is about being able to use a tool such as static
type-checking where appropriate, and it not getting in the
way where it is not.
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 -