Weblogs Forum - Implicit versus Explicit Dynamic Typing

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

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

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 95 replies on 7 pages [ « | 1 2 3 4 5 6 7 | » ]

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Well trodden path

Posted: Sep 19, 2005 3:45 PM

> you've described there and it leads straight to generics
> hell.
>
> This is exactly the line of reasoning we got in C++, then
> Java, and it always leads to the same place as you
> struggle to reconcile the static type of the variable with
> the concrete type of the value it references.
>
> > Static typing
> > eliminates the need for type testing.
>
> Until you support inheritance in the language, and then it
> doesn't. Because the static type of the variable may
> disagree with the concrete type of the object. Wrong
> information is much more confusing than missing
> information in my experience.

I'm trying to understand your reasoning, here. What's the problem with inheritance and static typing? It'll check that the dynamic type is (derived from) a certain class, specified as the static type of the variable. Thus, it's still type-safe.

However, what we _are_ somewhat struggling with in C++ - but where I see the same problem in dynamically typed languages - is the support for "duck typing" (Python fans knows what this is :) ). At the moment (without fancy "metaprogramming magic" á la boost::enable_if), we can, e.g. in a function declaration, only specify a concrete type (or a type related by inheritance, in the case of pointer/reference), or more or less "everything goes" (in the case of templates). That is, "template<class T> void f(T)" will accept any type, leading to cryptic error messages from deep within the implementation code, remniscent of an untyped language...

What would be better is to be able to specify "constraints" on the template paramters, as in the existing C++ formal proposals about support for "concepts".

Regards,

Terje

art src

Posts: 33
Nickname: articulate
Registered: Sep, 2005

Testing Types

Posted: Sep 19, 2005 4:03 PM

Testing costs. Bugs cost too. However, once there are tests for all functional cases, how many type test cases are left? How does it this cost compare to the cost of variable type declarations?

What is your experience? I use Java. In Java collections are untyped. I have never written a test case to test type behavior once functional tests are written. I have never discovered a type bug caused by a corner case.

In terms of errors what is the difference between:

unsupported operand type(s) for +: 'int' and 'str'

The operator * is undefined for the argument type(s) int, String

What good first languages are there? Which have variable type declarations?

Peter Mechlenborg

Posts: 8
Nickname: pmech
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 4:09 AM

> I find it a bit of a paradox (and would _love_ to be enlightened on
> this...) that several proponents of agile development also advocate
> dynamical typing. Agile development is not at least about rapid
> feedback - catching errors as early as possible, and adjusting the
> design according to early feedback. Then, prey tell, why not get the
> compiler to help you, by giving you error reports even before you run
> your tests?!

If you judge dynamically typed languages from your experiences with PHP, then I'll judge all statically types languages from my experience with C.

Agile development is also about TDD. With TDD I would argue that errors found by a test is as easy to fix, as errors found by a compiler. You seem to believe that running first the compiler and then the tests takes much longer than just running the compiler. In my current project the longest method I have takes about 0.2 sec. to compile, and my tests takes about 0.1 sec. to run. I think that's a fine turn-around time, and I don't need earlier feedback than that.

Dynamically types languages have a tradition of being able to compile very small pieces of code, like a single method. Statically typed languages normally compile hole files. So if for example ones experiences with compilers comes mainly from C++, then these will be very hard to use to reason about a Smalltalk or Lisp environment.

The hole discussion is too narrow. Typing is just one of many aspects that makes development in Smalltalk, Lisp and Python very different from development in C++, Java and C#, and many experiences gained on one side, does not apply in the other. The only way to find out if one side is better than the other, is to try to use both for some serious programming. I think that the same applies to discussions on mainstream vs. functional languages, and "normal" development methodologies vs, agile.

> Some IDEs even highlight errors before the compiler is
> even run, for another thing.

The IDE runs a compiler (at least the front-end and the type checker) to make error highlights.

> Curious minds wants to know... :)

Did that help, or did I just add fuel to the fire.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 4:38 AM

> > I find it a bit of a paradox (and would _love_ to be
> enlightened on
> > this...) that several proponents of agile development
> also advocate
> > dynamical typing. Agile development is not at least
> about rapid
> > feedback - catching errors as early as possible, and
> adjusting the
> > design according to early feedback. Then, prey tell, why
> not get the
> > compiler to help you, by giving you error reports even
> before you run
> > your tests?!
>
> If you judge dynamically typed languages from your
> experiences with PHP, then I'll judge all statically types
> languages from my experience with C.

Sure; at least C doesn't have an implicit conversion from an empty string to 0. :) (although I admit it's not that far off.)

Seriously, I don't "judge all dynamically typed languages" from my experience with PHP; it was an example of a popular one (and increasing in popularity, it seems).

> Agile development is also about TDD. With TDD I would
> argue that errors found by a test is as easy to fix, as
> errors found by a compiler. You seem to believe that
> running first the compiler and then the tests takes much
> longer than just running the compiler. In my current
> project the longest method I have takes about 0.2 sec. to
> compile, and my tests takes about 0.1 sec. to run. I think
> that's a fine turn-around time, and I don't need earlier
> feedback than that.

Yes, with that rapid compile/run cycles, I can understand it.

> Dynamically types languages have a tradition of being able
> to compile very small pieces of code, like a single
> method. Statically typed languages normally compile hole
> files. So if for example ones experiences with compilers
> comes mainly from C++, then these will be very hard to use
> to reason about a Smalltalk or Lisp environment.
>
> The hole discussion is too narrow. Typing is just one of
> many aspects that makes development in Smalltalk, Lisp and
> Python very different from development in C++, Java and
> C#, and many experiences gained on one side, does not
> apply in the other. The only way to find out if one side
> is better than the other, is to try to use both for some
> serious programming.

Maybe someone out there has done just this, and can report back?

> I think that the same applies to
> discussions on mainstream vs. functional languages, and
> "normal" development methodologies vs, agile.

Yep.

> > Some IDEs even highlight errors before the compiler is
> > even run, for another thing.
>
> The IDE runs a compiler (at least the front-end and the
> type checker) to make error highlights.

That may be.

> > Curious minds wants to know... :)
>
> Did that help, or did I just add fuel to the fire.

It certainly didn't add fire. :)

However, on the concept of tests, are you (or anyone here) saying that if your tests test the functionality, then "type-testing" typically isn't needed (being implicitly done by the test for functionality), or do you also include "type-testing" in your tests? If the latter, wouldn't it lead to less need for test writing, if the compiler could statically check the types?

You say that "Typing is just one of many aspects that makes development in Smalltalk, Lisp and Python very different from development in C++, Java and C#". I guess what I'm looking for is: Why would lack of static type checking be an advantage? (leaving aside the discussion of whether or not the types should be declared or inferred)?

Regards,

Terje

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 5:39 AM

> That said, there may be something said for being explicit
> in the code: for stating what is expected, and what is
> guaranteed. A declaration like "int f(int)" clearly states
> that the function takes an int, and returns an int. No
> ambiguity, there. Thus, inside the function, there's no
> need to explicitly check the type, so you won't have to
> write unit tests for something the compiler can very well
> check itself! Also, you're again guaranteed by the
> compiler that the type of the returned value is int, as
> well. So you may instead write tests for higher-level
> stuff.
>
> I find it a bit of a paradox (and would _love_ to be
> enlightened on this...) that several proponents of agile
> development also advocate dynamical typing. Agile
> development is not at least about rapid feedback -
> catching errors as early as possible, and adjusting the
> design according to early feedback. Then, prey tell, why
> not get the compiler to help you, by giving you error
> reports even before you run your tests?! Some IDEs even
> highlight errors before the compiler is even run, for
> another thing.
>
> Curious minds wants to know... :)

A lot of it has to do with ease of change. Unless you have very good extensive refactoring tools (and the ones for Java are only now getting close to that) your code base is less agile with static typing than it is with dynamic typing and tests. What I mean by that is that it isn't as easy to make changes because of ripple effects through declarations in the code. When code is hard to change, people don't do it as often and entropy wins.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 6:12 AM

> > I find it a bit of a paradox (and would _love_ to be
> > enlightened on this...) that several proponents of
> agile
> > development also advocate dynamical typing. Agile
> > development is not at least about rapid feedback -
> > catching errors as early as possible, and adjusting the
> > design according to early feedback. Then, prey tell,
> why
> > not get the compiler to help you, by giving you error
> > reports even before you run your tests?! Some IDEs even
> > highlight errors before the compiler is even run, for
> > another thing.
> >
> > Curious minds wants to know... :)
>
> A lot of it has to do with ease of change. Unless you
> have very good extensive refactoring tools (and the ones
> for Java are only now getting close to that) your code
> base is less agile with static typing than it is with
> dynamic typing and tests. What I mean by that is that it
> isn't as easy to make changes because of ripple effects
> through declarations in the code. When code is hard to
> change, people don't do it as often and entropy wins.

Have you also considered static type checking using type inference (as I said in that posting)? I can't see what kind of ripple effects that would case (if you mean having to change declarations).

Indeed, as I touched on in my posting, modern C++ tend to use templates quite a lot, which tend to reduce the amount of explicit type declarations needed (relying on type inference). Well-written generic code typically have little explicit type declarations, thus getting the "agility" of dynamic typing, while retaining static type checking.

Regards,

Terje

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 8:37 AM

> [...] your code base is less agile with static typing than it is with
> dynamic typing and tests. What I mean by that is that it isn't as easy
> to make changes because of ripple effects through declarations in the
> code. [...]

I can see a flame war coming, but I'm not entirely convinced by this line of argument. What you need to understand is that there are (at least) two kinds of declarations. The undesirable declarations are the ones you write just because the language forces you to write them, but serve no other purpose than to keep the compiler happy (e.g. in Java, every variable declaration must be annotated by a type). The desirable kinds of declarations are the ones that you use to specify abstractions so that you can write modular programs. From another point of view, the desirable kinds of declarations are the ones you use to hide implementation details.

The desirable declarations are there to catch errors. The type errors that you get when you change declarations of abstractions are extremely helpful. In a dynamically checked language, those errors are delayed until runtime and errors caused by changes to abstractions can easily go unnoticed for a long time. When you change an abstraction, you need to test all clients of the abstraction. Dynamically checked languages do not help you in identifying the clients of an abstraction.

Manifestly typed languages (which includes basically all mainstream statically typed languages including Java and C++) force you to write both kinds of declarations. The undesirable declarations are a major cause of verbosity and are usually a hindrance rather than a help. What is even worse, many of the statically typed mainstream languages actually do not provide good mechanisms for writing the desirable kinds of declarations. For example, you can not express "concepts" in C++. Another example is the lack of any means of abstracting over primitive types in Java. If you change between int and long in an interface, you'll get a nasty ripple effect.

Type inferred languages (many functional programming languages including Standard ML, Ocaml, and Haskell among the best known) allow you to omit the undesirable declarations while permitting you to actually specify abstractions. Except for a few exceptions (and the definition of new datatypes) you can essentially write your entire program without any type annotations or declarations. Doing so would be naive, however. Large scale programs in those languages include specifications of abstractions in the form of signatures of modules (and type classes in Haskell). A signature in SML and Ocaml specifies the visible properties of a module. You seal a module with a signature to hide implementation details. You use functors to implement modules with respect to an unspecified module that matches a specified signature.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 8:42 AM

> Related problems comes from all type-checking being done
> at run-time, so if a branch of the code is executed only
> in rare circumstances, you may never know of a bug lurking
> there...

Chances are that this argument remains valid for statically
typed code too ;)

> I find it a bit of a paradox (and would _love_ to be
> enlightened on this...) that several proponents of agile
> development also advocate dynamical typing. Agile
> development is not at least about rapid feedback -
> catching errors as early as possible, and adjusting the
> design according to early feedback.

No, attempts on finding errors early are orthogonal to any development methodology. People who advocate code inspections or formal specifications are clearly aware about this issue too. But since agilists favour both TDD and flexibility ( simpler to write, easier to change )dynamic languages are a natural fit.

Kay

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 9:44 AM

Kay But since agilists favour both TDD and flexibility ( simpler to write, easier to change ) dynamic languages are a natural fit.

Let's remember that many of those promoting XP and TDD have a long prior history with Smalltalk.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 9:57 AM

object o(42);
int i = o; // runtime type check

> I'm not sure that there would be many uses for that
> construct (except for the "I don't feel like bothering
> with types today so stuff it" one).

In certain circumstances a Universal Type can help to improve modularity. For example, you can use an association list whose range is a Universal Type to attach "properties" to objects without requiring every client of the properties to know about each other. (Some type systems may offer other, more type safe, ways to make such property lists without completely destroying modularity.) See the page http://mlton.org/UniversalType for how to implement a Universal Type in Standard ML and the page http://mlton.org/PropertyList for how to implement property lists.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 10:04 AM

> Manifestly typed languages (which includes basically all
> mainstream statically typed languages including Java and
> C++) force you to write both kinds of declarations. The
> undesirable declarations are a major cause of verbosity
> and are usually a hindrance rather than a help.

What is with this irrational fear of verbosity? Verbosity is a Good Thing. Explicit type annotations serve as a form of automated documentation. It makes code easier to maintain and read and understand. One of the purposes of code is to make explicit a programmer's intentions to other programmers, not to save keystrokes. Programmers seem to forget that in the it is more important for code to be easy to read than easy to write.

> What is even worse, many of the statically typed
> mainstream languages actually do not provide good
> mechanisms for writing the desirable kinds of
> declarations.

This has nothing to do with being statically typed, but are simply examples of languages with insufficient type systems.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 10:11 AM

> A lot of it has to do with ease of change. Unless you
> have very good extensive refactoring tools (and the ones
> for Java are only now getting close to that) your code
> base is less agile with static typing than it is with
> dynamic typing and tests. What I mean by that is that it
> isn't as easy to make changes because of ripple effects
> through declarations in the code. When code is hard to
> change, people don't do it as often and entropy wins.

The ripple of change to declarations represent the propogation of change of behaviour. Where those declarations need to be changed in a statically typed language, test cases in a dynamically typed language will need changing. If the tests don't need changing, then probably the wrong type was being used or the test coverage was incomplete.

Peter Mechlenborg

Posts: 8
Nickname: pmech
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 10:24 AM

> You say that "Typing is just one of many aspects that makes
> development in Smalltalk, Lisp and Python very different from
> development in C++, Java and C#". I guess what I'm looking for is: Why
> would lack of static type checking be an advantage? (leaving aside the
> discussion of whether or not the types should be declared or
> inferred)?

I would like all the static typing I could get, but it does not have very high priority, that is, I would like static typing, but not if I have to sacrifice things I value more. Many of these things i value more, could properly work in a statically typed context, but I haven't seen this so far (at least not enough to make me shift language).

Some of the things I value high are: easy-to-use top level loop, fine grained compilation, a live image with good reflective capabilities, being able to run/test code that has holes (ex. missing function declarations) and keyword arguments.

I strongly believe that programming languages should restrict the programmer as little as possible. I don't find languages that force one mindset like OO or static typing to be optimal. A language should give the programmer the option to model some or all of an application using OO, and give the option to verify some or all of an application statically, if the programmer feel it is needed.

A complex problem consists of many subproblems, that each, in my eyes, are best expressed in its own terms. This could be done with for example SQL, regular expressions, a markup language, OO, logic programming, and unique domain specific extensions/languages.

My impression of programming languages are that the dynamic ones, and in particular Common Lisp, are much more flexible in this regard than the static ones.

The above is a bit off topic, but hopefully it gives an idea of why I'm not particular interested in static typing.

By the way. If you have met the term "Language Oriented Programming", this resembles my view on programming very closely.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 10:28 AM

> > Related problems comes from all type-checking being
> done
> > at run-time, so if a branch of the code is executed
> only
> > in rare circumstances, you may never know of a bug
> lurking
> > there...
>
> Chances are that this argument remains valid for
> statically typed code too ;)

Yes, if the bug is not type-related, for example a bug in logic (although strong type checking can prevent much of this, as well, by preventing meaningless operations).

What I'm getting at is that even if static type checking may not catch all errors, it doesn't mean that it's not a good thing. The same argument can be said about unit tests! I prefer not having to write tests to catch stupid errors that the compiler could very well have caught, thank you very much.

As bot Vesa and I have been talking about, we need to differentiate between the role of the type declarations (such as specifying interfaces), as well as whether or not you have to declare types to begin with.

> > I find it a bit of a paradox (and would _love_ to be
> > enlightened on this...) that several proponents of
> agile
> > development also advocate dynamical typing. Agile
> > development is not at least about rapid feedback -
> > catching errors as early as possible, and adjusting the
> > design according to early feedback.
>
> No, attempts on finding errors early are orthogonal to any
> development methodology. People who advocate code
> inspections or formal specifications are clearly aware
> about this issue too.

Feedback through unit tests, or type checking, is much quicker than these alternatives, so I still think people would generally agree that agile development places a particularly strong emphasis on feedback (and early feedback). Not at least in the case of TDD, where you get feedback even before a single line of code is written.

> But since agilists

"agilists", now that's a new term. :)

> favour both TDD
> and flexibility ( simpler to write, easier to change
> )dynamic languages are a natural fit.

Well, saving writing a few type declarations may instead give you hours of wasteful debugging, so I don't think this necessarily holds. In particular, the language (and the axes I mentioned in my first posting) is a big factor.

Regards,

Terje

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Implicit versus Explicit Dynamic Typing

Posted: Sep 20, 2005 10:49 AM

> What I'm getting at is that even if static type checking
> may not catch all errors, it doesn't mean that it's not a
> good thing. The same argument can be said about unit
> tests! I prefer not having to write tests to catch stupid
> errors that the compiler could very well have caught,
> thank you very much.

Here's the trick though: typical UTs test values and types come along for the ride. It's "two for the price of one."

Type systems tell us we have the correct types, but they don't go down to the computation level.

Flat View: This topic has 95 replies on 7 pages [ « | 1 2 3 4 5 6 7 | » ]

Previous Topic

Next Topic