The Artima Developer Community
Sponsored Link

Weblogs Forum
Implicit versus Explicit Dynamic Typing

95 replies on 7 pages. Most recent reply: Apr 17, 2006 11:09 AM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 95 replies on 7 pages [ « | 1 ... 3 4 5 6 7 | » ]
Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Method Names reveal the type Posted: Sep 23, 2005 1:29 PM
Reply to this message Reply
Advertisement
> Or like a large bandaid on a hairy arm. You have to pull
> it off slooooowly. :-)

You convinced me, you are mad. ;-)

> True, not everyone has them, but in a way aren't tests
> more flexible than type systems?

How about being more specific?

Your argument is also quite meaningless. Nothing prevents you from using both types and tests.

> If we looked at it from an a priori software engineering
> point of view, isn't it odd to couple the structure of
> code to its semantic constraints?

Are you familiar with the main programming language semantic styles: operational, denotational, and axiomatic semantics? The semantics of a programming language are given with respect to the structure (AST) of programs. It makes perfect sense and there is nothing "odd" about it.

> Yes, type systems give us universal quantification: "for
> all class X"

That's not the whole picture. Type system also give us existential quantification. In fact, and this is actually quite important, existential quantification is the key to modularity. A type specification in an ML signature tells that there is a type, but it doesn't (usually) tell which specific type it is. This makes it possible to write programs that don't depend on the (hidden) structure.

> but there are constraints which don't tie to all.

In such cases you can use tests. In some cases it is also possible to introduce a new abstract type whose constructors and operators do not let you build "bad" values. Look at the Direction examples I wrote in ML. The sealed modules do not let you build bad values, so there is no point in testing what happens with such values.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 23, 2005 3:50 PM
Reply to this message Reply
And here I was thinking this discussion had wound down.

I'm not a fan of naming systems. Yes, they can be useful (http://www.joelonsoftware.com/articles/Wrong.html), but they still rely on human enforcement. I'd rather overload a function or operator on the type.

Using Joel's example and C++, I'd rather create stream classes representing various sources (such as safe database sources and unsafe HTTP sources) and then overload operators << and >> (because it is C++) to do any necessary encoding/decoding based on the type of stream in use. Then I can code free of Hungarian notation.

Yes, Hungarian notation works around this. Do what floats your boat. However, in my short experience programming every time I needed a list of things, they all had something similar. I've never felt a need to put a part number, web address, and car simulation into an internal queue. I may make a printing queue, and put different kinds of documents in it, but they will all be printable documents. I might simulate cars getting ripped off at the gas station, but they will all be automobiles.

And I've never had the need to drastically change the type of an object after creating it. Can anybody give me an example of what I've been missing?

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 23, 2005 3:52 PM
Reply to this message Reply
Aargh!

Please add "And I can use encoding/decoding schemes relevant to the streams without having to remember which ones pair up." to that paragraph.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 23, 2005 9:23 PM
Reply to this message Reply
> I'm not a fan of naming systems.

I'm not either. I'm in favor of code that says what it does in an obvious way.

My point has been completely missed and this will be my last try to make it. The problem with type annotations is I invariably come up with some case where I want to violate them for a good reason.

Types produce sets, sets are seldom crisp and often have exceptions (like the penguin in a set of birds).

I have been doing a lot of interviewing of prospective employees lately and one of my interview questions is "what is an abstract base class in C++ and why would I want one?"

They usually manage to mutter something about a class that can't be instantiated, but the reason for creating an ABC is never properly stated.

To put it simply, the driving reason to create an abstract base class in C++ is to enable substitutability. This is the most important feature of loosely coupled systems and is the hardest thing to ensure in statically typed languages.

Static typing is the enemy of casual code reuse and adds to system rigidity. It also doesn't seem to benefit me sufficiently to put up with the loss of flexibility so I avoid languages that use it. So far (15 years on), it has not been a problem for me.

Tapan kumar Rath

Posts: 18
Nickname: papuni
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 24, 2005 12:59 AM
Reply to this message Reply
At work palce I use php while I love java.In my opinion if a language doesn't require explicit dynamic typing then at one point of time or another you fall in to a trap believing that it is ok to do this but while it is not.So usually you have to write longer validations for implicit typing based languages.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 24, 2005 1:20 AM
Reply to this message Reply
> The problem with type annotations is I invariably come up with some case
> where I want to violate them for a good reason.

How about a concrete example (program code)? If you invariably come up with such cases, you must have some specific examples drawn from the actual code you were working with.

Do you have significant experience with any statically typed language that provide type inference? Did you experience the same problems then? Concrete examples?

> Types produce sets, sets are seldom crisp and often have exceptions
> (like the penguin in a set of birds).

That isn't a concrete example. The above sounds to me like the debates I've seen on newsgroups like comp.object (which I don't read regularly) about the merits of deep inheritance hierarchies or "modelling the real-world".

> I have been doing a lot of interviewing of prospective employees lately
> and one of my interview questions is "what is an abstract base class in
> C++ and why would I want one?"

I would most likely have passed that question (OCP, LSP, DIP, ... these are all old news to me). I added the "most likely", because the way you framed the question might distract me (in an interview situation) to explain the mechanics of C++ and I can see why it might distract others, too. I would recommend that you drop the word "C++" from your question or break your question into two: "what is an abstract base class in C++?" and "why would I want to use an abstract base class?". This makes it clearer that the latter question isn't about C++ in particular, but about OOD in general.

> To put it simply, the driving reason to create an abstract base class in
> C++ is to enable substitutability. This is the most important feature of
> loosely coupled systems and is the hardest thing to ensure in statically
> typed languages.

Actually, well designed type (and module) systems allow you to specify the interfaces of program modules in program code. The specifications allow a compiler to ensure that they are not violated.

> Static typing is the enemy of casual code reuse and adds to system
> rigidity.

Again, concrete examples are better than colorful statements without any kind of proof.

> It also doesn't seem to benefit me sufficiently to put up with the loss
> of flexibility so I avoid languages that use it. So far (15 years on),
> it has not been a problem for me.

I also don't recall having major type related problems while programming in safe dynamically checked languages like Scheme. On the other hand, I also like programming in statically typed languages with type inference and the problems you have been describing just aren't there (at least not in a significant way).

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Well trodden path Posted: Sep 24, 2005 2:54 AM
Reply to this message Reply
> > I think Todd is correct in saying that C++ templates
> use
> > duck typing, and you just described what it's about: :)
>
> I understand duck typing to be a pattern to make calling
> methods that have the same signature (i.e., return the
> same type, take the same number and kind of arguments)
> easy, even if the classes in question are not related to
> each other.

Yes, and you can do this with templates, of course:

template<class T>
void f(T t)
{
t.g();
}

Here, the type T is only required to have a member function g(), taking no arguments. The type of T doesn't matter.

> Perhaps my counterexample was poorly picked. However,
> std::swap relies on templates to do much more than what
> duck typing offers.

Could you give an example of something it offers that's not part of the concept of "duck typing"?

> AND, other uses of policy classes
> permit far more than that
> http://www.boost.org/libs/concept_check/concept_check.htm)

I think we basically agree. :) I think the problem is the lack of definition of "duck typing". I just understand it the way you define it above. But that's the mechanism; you describe ways to use this mechanism (such as policies).

The "Concept Traits Library" that I gave a link to in an earlier posting goes beyond the Boost Concept Check Library, in that it enables overloading on concepts, something BCCL doesn't provide. Still, we need language support to get the full benefit of concepts.

Regards,

Terje

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Well trodden path Posted: Sep 24, 2005 3:48 AM
Reply to this message Reply
> > I understand duck typing to be a pattern to make
> calling
> > methods that have the same signature (i.e., return the
> > same type, take the same number and kind of arguments)
> > easy, even if the classes in question are not related
> to
> > each other.
> >
> > Perhaps my counterexample was poorly picked. However,
> > std::swap relies on templates to do much more than what
> > duck typing offers. AND, other uses of policy classes
> > permit far more than that
> (http://www.boost.org/libs/concept_check/concept_check.htm)
>
> After reading that, I get the idea that concept checking
> is basically a trick to validate some type against a set
> of operations at compile time by forcing instantiation of
> a type parameterized checking function.

Yes, that's the BCCL library he links to, but that's basically a library to give some of the benefits of support for concepts. Concepts in the language would be very different, and there exists two formal proposals for it (which were presented at the last C++ standards meeting at Lillehammer):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1758.pdf

What you describe above is the workings of the library, not language support for concepts.

> A bit like a unit
> test but at compile time. Sort of a poor man's compile
> time [object conformsToProtocol: someProtocol] to borrow a
> line from ObjectiveC.

Or poor man's support for concepts. :)

> That's fine, but what if the operation I'm performing only
> requires part of the protocol? I guess I have to create a
> special sub concept checker?

With language support for concepts, it should be much easier to define new concepts, maybe even at the point of use. One way to think of concepts is as "types for types", or perhaps better as a "set of types". Consider:

// This accepts _only_ values of type int, or types convertible to int

void f(int);

// This accepts values of type SomeBase, or any type derived from it

void f(SomeBase);

// This accepts a value of _any_ type... Bjarne Stroustrup has said that templates model the mathematical concept "for all T...". However, in maths, you can typically constrain the values: "for all T, where...". And this is what concept checking is about - giving that "where" clause.

template<class T>
void f(T);

// This accepts a pointer to any type

template<class T>
void f(T *);

// This accepts a reference to any type

template<class T>
void f(T &);

// This accepts an array of any size of any type (variations may be used, such as fixing the type or size)

template<class T, size_t N>
void f(T (&)[N]);

And so on. As you can see, we have some "wiggle room"; some way of specifying some of the desired type properties in templates (pointer, reference, array, ...). However, we currently have no way of specifying arbitrary constraints (without "simulating" it with BCCL or the mentioned CTL), such that a type should support the basic arithmetic operations (+, -, *, /). If we had, we could do this (syntax from one of the concept proposals mentioned above):

template<Arithmetic T>
void f(T);

You'd be able to call function with any type conforming to the concept "Arithmetic" (or "modelling the concept", in generic programming terminology), such as int, float, double, ArbitraryPrecisionNumber, etc.

As you hopefully can see, support for concepts would fill a "hole" in the type system, as you now can only check for concrete, specific types (like int, etc.), or types related by inheritance, or pointer/reference/array, or allow anything, but not something inbetween "anything" and the mentioned ones.

> Seems like a lot of extra work for dubious benefit. I'd
> rather have a system that just runs and when something
> goes wrong it helps me diagnose the problem.

Some big advantages with support for concepts are:

1) You get to know about any problem at compile-time; no tests are needed to check for conformance. Also, the compiler can type-check the templates, and the client code _independently_ of each other, a key benefit of "separate compilation" of templates.

2) The errors are reported where they exist, according to the concept specification (such as in the function, or in the function call).

Without this, it can be very hard to determine the actual problem, because then the actual error may be in an entirely different part of the program, than where you get the error message (try calling std::sort() with types not supporting "<", and you'll see what I mean: it "bombs out" somewhere deep into the implementation, rather than saying "Your type doesn't support "<"".

Support for concepts are really about giving "duck typing" the same type checking (and ability to overload) as ordinary function signatures.

> It seems to me that C++ has an over-reliance on compile
> time checking because of an unhealthy obsession with
> avoiding the cost of maintaining useful meta information.

I think you're way out on a limb, here, and risk making opinions based on erroneous or missing information. It's not about avoiding storing meta information: that may actually be useful, and given your remark, you're probably not aware of the work going on in giving C++ considerable reflection information (such as Bjarne Stroustrup's project, or Daveed Vandevoorde's "Metacode" proposal).

You see, it's not an either-or: Being able to check things, and act on type information, both at compile-time, and at run-time, complements each other (see also the "Design by Contract" proposal, which deals with the run-time checking).

> In the end, C++ ends up being ever more bloated as
> s endless instantiation of templates produces dozens of
> copies of the same binary. For instance:
>
> List<A*>
> List<B*>
> List<C*>
> etc, all of which are probably identical binary but have
> different copies just because they are different "types".

As someone else pointed out, this problem can be "trivially" avoided with partial specialisation, and hoisting type-invariant code out of the template:

// General version

template<class T>
List
{
// ...
};

// Partial specialisation for pointers

template<class T>
List<T *> : ListImpl {};

Support for concepts might provide even further ways of doing code sharing.

> The very picture of penny wise and pound foolish.

You may want to reconsider your opinion, given that your argument is based in large part on incorrect or incomplete information, making the conclusion erroneous.

Regards,

Terje

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Well trodden path Posted: Sep 24, 2005 4:06 AM
Reply to this message Reply
> > I've several years of experience with developing
> > applications in PHP, and my experience (as well as my
> > coworkers), is that type-related errors stand for a
> large
> > part of our bugs, as well as the difficulty in finding
> the
> > correct place the error originates.
> >
> Sorry, PHP can't be accepted in a discussion about strong
> dynamic typing Vs strong static typing

Who says the discussion is about "strong dynamic typing Vs strong static typing"? Judging from the blog title, it's neither about that, nor about strong/weak typing, but both the latter have still been part of the discussion, and are therefore "legetimate" discussion subjects. What this thread not at least is about, is "real-world languages" (at least, it matters most for them), and PHP and Perl are two of the more popular languages around, both being "weakly typed".

>, since it barely
> has any concept of type, and that it's typing system is at
> best weak.

Every value in PHP has a specific type (such as int, double, string, array, SomeClass, etc.), but it has very "liberal" conversion rules, which may be understandable, given the domain in which it's typically used (where everything you get from a browser, and typically the database, is in the form of strings).

> > > Yes, but usually you get the stack. For instance, in
> > > Smalltalk, you get a walkback (debugger) on the
> program
> > > that usually shows you right where your error is.
> > These
> > > problems are easy to find and fix.
> >
> > Not in our experience. Yes, you may walk the
> stacktrace,
> > and inspect each function call and parameters up to
> > main(), but it would be much easier if the error
> message
> > pointe to the actual error (as in the function call,
> not
> > inside the function).
> >
> In the sort example, the stacktrace of "modern languages"
> (where modern stands for "not PHP or anything even
> remotely close to it)

That's a strange way to define "modern", given that PHP is one of the newest languages around...

> will point to the test itself,
> saying that there is an incompatibility with the tested
> values (Operator not implemented, incompatible operator,
> or whatever).

Yes, and so it does in PHP, as well. However, especially if the error manifests itself in the code itself (not in a test), you may have a hard time tracking down the actual source of the bug, if the function signatures perform no type checking on the parameters (which, as I understand, is pretty common for dynamically typed languages).

Regards,

Terje

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 24, 2005 4:35 AM
Reply to this message Reply
> > I'm not a fan of naming systems.
>
> I'm not either. I'm in favor of code that says what it
> does in an obvious way.
>
> My point has been completely missed and this will be my
> last try to make it. The problem with type annotations is
> I invariably come up with some case where I want to
> violate them for a good reason.
>
> Types produce sets, sets are seldom crisp and often have
> exceptions (like the penguin in a set of birds).

Just to comment on this: This is what overloading and specialisation is about: dealing with the exceptions.

> I have been doing a lot of interviewing of prospective
> employees lately and one of my interview questions is
> "what is an abstract base class in C++ and why would I
> want one?"
>
> They usually manage to mutter something about a class that
> can't be instantiated, but the reason for creating an ABC
> is never properly stated.
>
> To put it simply, the driving reason to create an abstract
> base class in C++ is to enable substitutability. This is
> the most important feature of loosely coupled systems and
> is the hardest thing to ensure in statically typed
> languages.
>
> Static typing is the enemy of casual code reuse and adds
> to system rigidity.

You should be careful about what you mean with "static typing" (and not by it mean _one_ particular instance of it). Again, with support for concepts, you can provide static type checking based on syntax and semantics, rather than specific types, enabling your mentioned "casual code reuse" (any type satisfying the constraints of the function, can be used, regardless of its actual type, and preventing non-compatible types from being used), and avoiding "system rigidity".

> It also doesn't seem to benefit me
> sufficiently to put up with the loss of flexibility so I
> avoid languages that use it. So far (15 years on), it has
> not been a problem for me.

There are ways of getting the benefits of static typing, without loosing the flexibility of dynamic typing (and avoiding its problems), as has been discussed in this thread.

Regards,

Terje

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 24, 2005 10:52 AM
Reply to this message Reply
> > The problem with type annotations is I invariably come
> up with some case
> > where I want to violate them for a good reason.
>
> How about a concrete example (program code)? If you
> invariably come up with such cases, you must have some
> specific examples drawn from the actual code you were
> working with.

OK, I just added a Mac GUI to a system that was command line driven. The command line based system has its own concept of IO streams. I wanted the stuff normaill written to stdout to be written to a text field in a window so I added a couple methods from the output stream protocol and now hand the window to the system as the output stream. NSWindow isn't an output stream and I can't change the inheritance hierarchy, so I subclassed it and implemented a couple methods and voila - I can substutute the window for the ouput stream.

If you read the documentation for Cocoa on Mac OS X you'll come across a concept called 'delegates'. A delegate is any object, If the object implements certain methods, then the object using the delegate will give the delegate a chance to handle an event or action before the default action occurs. This is tremendously powerful but only makes sense because objectiveC is a dynamically typed language.

The java interface to Cocoa has been dropped because delegation required additional definitions of all these interfaces and the overhead made everything take six times longer to do.

> Do you have significant experience with any statically
> typed language that provide type inference?

No, my experience is with C++ (awful), Java (slightly less awful but still mighty sucky), ObjectiveC (decent), and Smalltalk (nirvana). Interestingly, system stability/reliability runs in about this order as well from worst to best.

>>"what is an
> >abstract base class in
> > C++ and why would I want one?"
>
> the way you framed the question
> might distract me (in an interview situation) to explain
> the mechanics of C++ and I can see why it might distract
> others, too.

C++ was simply his best language and thus the context for discussion. I didn't actually say "in C++". I'd expect to get the same answer from a Java developer but different answers from ObjectiveC/Smalltalkers.

> Actually, well designed type (and module) systems allow
> you to specify the interfaces of program modules in
> program code. The specifications allow a compiler to
> ensure that they are not violated.

I have never used or seen such as system.

> I also don't recall having major type related problems
> while programming in safe dynamically checked languages
> like Scheme.

I wouldn't expect to see them there either - duck typing

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Well trodden path Posted: Sep 26, 2005 4:29 PM
Reply to this message Reply
> > Perhaps my counterexample was poorly picked. However,
> > std::swap relies on templates to do much more than what
> > duck typing offers.
>
> Could you give an example of something it offers that's
> not part of the concept of "duck typing"?

Simply, the entire STL permits somebody to use STL containers, which embed different policy issues in the definition (something like std::vector::iterator::xxx where "xxx" somehow refers to getting the next element, or dereferenceing an element, etc.). But somebody can specialize a template such that given an array of pointers the template will know the various policies, *even though they are not embedded in the class*. That, to me at least, is different than duck typing.

When I made the statement regarding std::swap, I was thinking more of statements made in the Standard that suggest that a swap does not always require copying the objects involved. For instance, if I'm swapping the first two elements of a vector, std::swap's implementation is allowed to recognize this (probably through template specialization) and only swap the iterators, or to take some implementation-dependant action, so long as it takes no longer than making the copies in memory and so long as the end result looks like a swap.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Well trodden path Posted: Sep 26, 2005 4:36 PM
Reply to this message Reply
/* [me]: AND, other uses of policy classes permit far more than that

(http://www.boost.org/libs/concept_check/concept_check.htm)

...

[response referring to my post]: Yes, that's the BCCL library he links to, but that's basically a library to give some of the benefits of support for concepts. Concepts in the language would be very different, and there exists two formal proposals for it (which were presented at the last C++ standards meeting at Lillehammer):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1758.pdf
*/

Yes, I recognize the difference. My point is only that empty policy classes, such as those provided by BCCL, can be passed to template functions that are specialized based on those particular classes. Since those classes are empty, by definition there isn't duck typing involved. Instead a different algorithm is picked based on those (empty) classes.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 26, 2005 5:21 PM
Reply to this message Reply
/* My point has been completely missed and this will be my last try to make it.
*/

I appologise, and I understand your frustration. However, you're probably doing a better job of saying what you're trying to say than I am.

/* The problem with type annotations is I invariably come up with some case where I want to violate them for a good reason.

[from another post]:
NSWindow isn't an output stream and I can't change the inheritance hierarchy, so I subclassed it and implemented a couple methods and voila - I can substutute the window for the ouput stream.
*/

Perhaps this is inexperience, but it seems to me that BECAUSE NSWindow is not an output stream, subclassing it from an output stream is asking for trouble. My understanding is that you have a window, and that window has (compared to is) an output stream. As such, giving the window an output stream member (with delegates, what the heck) accessible by win::out_stream::write_to() would make much more sense.

But that's just me.

/* Types produce sets, sets are seldom crisp and often have exceptions (like the penguin in a set of birds).
*/

Yes, I agree. However, you're usually interested in the aspects of a set that make it a set. For instance, when dealing with an email inbox, I have a sneaky suspicion I (as a programmer) will be more interested in the fact that each message is (a) an email and (b) addressed to the inbox in question. Perhaps some emails are from the Prime Minister of Finland, and that's unusual as the rest are spam, but those differences aren't important to me.

/* Static typing is the enemy of casual code reuse and adds to system rigidity. It also doesn't seem to benefit me sufficiently to put up with the loss of flexibility so I avoid languages that use it. So far (15 years on), it has not been a problem for me.
*/

I see your point, however static typing should only be used in situations it makes sense. I believe Java's single inheritance idea is bad, but it does have the side effect of getting rid of designs that derive houses from walls, carpets and plumbing fixtures. A house may have walls, carpets, and plumbing fixtures, but that's "has a" not "is a."

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

A few concessions Posted: Sep 27, 2005 6:28 AM
Reply to this message Reply
Thinking things over, I believe we agree far more than we realize. So let me concede a few points:

First, I concede that typing systems introduce a certain rigidity. The question is whether that rigidity is good overall or bad. Although I understand Python requires a certain amount of rigidity (http://discuss.joelonsoftware.com/default.asp?design.4.198142.39).

Second, I concede that object hierarchies are hard to re-use. Part of this is from the typing system, part of it is a fact of design.

Third, I concede that typing systems cannot solve every problem under the sun.

So, let's get into the details.

Regarding rigidity, I can't shake my Perl roots. Perl is designed to make it easy to write short sloppy scripts, and to later add any rigidity required. It's interesting that Perl's ability to handle very long scripts is closely tied to the amount of rigidity that can be added -- http://www.theassayer.org/cgi-bin/asbook.cgi?book=200 (reviewing Eric Raymond's claim that "At about 3300 lines, [a certain application] is probably pushing the size and complexity limit of what one should attempt in a single Perl program." -- "I've written a 4000-line Perl project and an 8000-line one. In neither case did I feel that I was running into a brick wall in terms of Perl's ability to scale. In some ways, the book feels out of date. For instance, the remarks about Perl's unsuitability for large programs may date back to the time when object-oriented programming in Perl wasn't common, or even possible.").

While we apparently draw the line differently, I will even concede that I'm no fan of incredibly super-duper strong typing like what's found in Ada. My concern about dynamic typing in languages like Perl and Python is the simple fact that I've never had the overriding need to change a variable's type partway through a program. So while I know it's possible to clobber the value in $a, and by so doing change the type of $a, I haven't yet seen a reason to do so.

Second, regarding re-use, I partly conced your point. However, I'm not sure how much of this can be blamed on the typing system (although much of it can -- again look at the fits Ada gives programmers). Some of the difficulty of code re-use is that the design of a type must ignore certain details that aren't important to the task at hand. Just as the design of a function must ignore certain details. The C standard library pow() function, for instance, may not be re-usable to somebody working in interval arithmetic (http://www.boost.org/libs/numeric/interval/doc/interval.htm). Regarding the example of penguins, I can think of many cases where penguins fit the class of birds (they have wings, feathers and beaks, they lay egss, etc.), and as such any simulation that relies solely on those attributes can re-use the penguin type without modifiction. OTOH, as you pointed out, a simulation that makes a big deal about the penguin's (and emu's and ostrich's, etc.) inability to fly may need to modify the type. I'm not conviced this is a problem with the typing system. It sounds more like a question about being at the same level of absraction.

Or, going back to the house, functions that look at the number of nails and the number of bricks, and the area of glass probably won't be very useful when dealing with where to place the furniture. Don't blame it on the house. Blame it on the level of abstraction.

And, third, typing systems do not solve everything. Which, btw, is why I prefer Perl and C++ as "multi-paradigm languages" over Java and other as "single paradigm" ones. Yes, I know Java now has generic programming and the ability to add AOP through AspectJ. And, I would point out that there's a reason real programmers wanted those features.

Flat View: This topic has 95 replies on 7 pages [ « | 3  4  5  6  7 | » ]
Topic: Bridging Static and Dynamic Typing Previous Topic   Next Topic Topic: Where Did All the Beautiful Code Go?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us