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 2 3 4 5 6 ... 7  | » ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Implicit versus Explicit Dynamic Typing (View in Weblogs)
Posted: Sep 18, 2005 10:15 AM
Reply to this message Reply
Summary
In Python variables are never explicitly typed. I consider this a Very Bad Thing.
Advertisement
There is a belief floating around that implicit typing makes programming easier to do and learn. I think this is rubbish. In order to explain why the following Python code is bad to a beginner you still have to explain the concept of types:
>>> x = 12
>>> y = "13"
>>> x + y
TypeError: cannot concatenate 'str' and 'int' objects
The error message is hard for a new programmer to understand because str and int aren't tangible. My next beef is that accidental type conversions is one of the most common error I see programmers make while developing code in implicitly typed languages like VBScript and Python. It is inefficient to have to track these down by first running the program, and having to test every single corner of the code. Static typing eliminates the need for type testing. In the end I see absolutely no advantage circumventing the few keystrokes it takes to explicitly write:
string x = "12"
int y = 13

Now when the programmer writes: x + y the inevitable type-error message that results is no longer something cryptic.

In the relatively rare case a programmer truly needs a variant type, it is easy enough to just use something like the object type in Heron, the cdiggins::any type in C++, and so on.

Anyway that forms the basis for my justification for explicit typing in HeronScript, and why I wouldn't teach an implicitly typed Python as a first language.


Girts Kalnins

Posts: 23
Nickname: smejmoon
Registered: May, 2003

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 11:04 AM
Reply to this message Reply
"My next beef is that accidental implicit type conversions is one of the most common error I see in production code in implicitly typed languages like VBScript and Python."

Do you have an Python example?

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 11:05 AM
Reply to this message Reply
Thing is that "x" and "y" are not typed themselves, they're merely references to typed variables. Technically, 12 and "13" have a type, "x" and "y" don't.

Having to specify each and every type doesn't sound very dynamic to me, and that's basically what you're doing in heronscript isn't it? (and having an "any" type where you can fit anything sounds like a horrible hack to me, especially since you probably have to cast it to the desired type it's supposed to hold/supposed to be interpreted as, don't you?)

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 11:08 AM
Reply to this message Reply
Oh, and I forgot to ask where you had ever found any kind of implicit type conversion in Python.

The only one I can think of is the automatic promotion from "int" (= C's 'long', >=32bits precision) to "long" (unlimited precision), and since both types are fully compatible it's not much of a cast...

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 11:48 AM
Reply to this message Reply
> "My next beef is that accidental implicit type conversions
> is one of the most common error I see in production code
> in implicitly typed languages like VBScript and Python."
>
> Do you have an Python example?

Thank you for correcting me. It is true that this error doesn't find it way into "production code" in Python. This is rather more common in VBScript with code which mixes ints, floats and money. I have rephrased my statement to:

"My next beef is that accidental type conversions is one of the most common error I see programmers make while developing code in implicitly typed languages like VBScript and Python. It is inefficient to have to track these down by first running the program, and having to test every single corner of the code. Static typing eliminates the need for type testing."

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 11:58 AM
Reply to this message Reply
> Thing is that "x" and "y" are not typed themselves,
> they're merely references to typed variables. Technically,
> 12 and "13" have a type, "x" and "y" don't.

Yes you are correct. Still supports my point that the concept of type is confusing when it isn't stated explicitly.

> Having to specify each and every type doesn't sound very
> dynamic to me,

It sounds like you mean "convenient" when you say "dynamic". That is a separate debate. I will however say this: what is convenient for a developer may not be the same as what is considered convenient for the programmer who has to make changes or debug a significantly large program in the future.

> and that's basically what you're doing in
> heronscript isn't it? (and having an "any" type where you
> can fit anything sounds like a horrible hack to me,

Why is it a hack? What is so horrible about it?

> especially since you probably have to cast it to the
> desired type it's supposed to hold/supposed to be
> interpreted as, don't you?)

You don't have to explicitly cast it.

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

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 2:09 PM
Reply to this message Reply
> > Having to specify each and every type doesn't sound
> very
> > dynamic to me,
>
> It sounds like you mean "convenient" when you say
> "dynamic". That is a separate debate. I will however say
> this:
>

I don't, specifying the type of a variable (and not a value, as it's done in Python or Ruby) means that you attribute a specific (and static) type to the variable.

Unless you can re-type your variables later on or something and I didn't grasp it, that is.

> what is convenient for a developer may not be the
> same as what is considered convenient for the programmer
> who has to make changes or debug a significantly large
> program in the future.
>
I am aware of that, and nor is it necessarily convenient for the implementation of the compiler/interpreter itself, or language's performances tweaking.
And therefore get static typing.

> > and that's basically what you're doing in
> > heronscript isn't it? (and having an "any" type where
> you
> > can fit anything sounds like a horrible hack to me,
>
> Why is it a hack? What is so horrible about it?
>
I don't know, it sounds like "Ok the whole language is statically typed but I'll keep some dynamism for the times when I feel a bit dorky and don't want to bother with said types"

> > especially since you probably have to cast it to the
> > desired type it's supposed to hold/supposed to be
> > interpreted as, don't you?)
>
> You don't have to explicitly cast it.
>
>
> object o(42);
> int i = o; // runtime type check
> 

mmm ok.

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).

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 3:20 PM
Reply to this message Reply
> There is a belief floating around that implicit typing
> makes programming easier to do and learn. I think this is
> rubbish. In order to explain why the following Python code
> is bad to a beginner you still have to explain the concept
> of types:
> ...
>
> <pre>
> >>> x = 12
> >>> y = "13"
> >>> x + y
> TypeError: cannot concatenate 'str' and 'int' objects
> </pre>
>
> The error message is hard for a new programmer to
> understand because <tt>str</tt> and <tt>int</tt> aren't
> tangible.

I'm not buying that argument. If it were true, non-programmers wouldn't be able to use Excel. ;)

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 7:50 PM
Reply to this message Reply
> > The error message is hard for a new programmer to
> > understand because <tt>str</tt> and <tt>int</tt> aren't
> > tangible.
>
> I'm not buying that argument. If it were true,
> non-programmers wouldn't be able to use Excel. ;)

This is a good point. Here is a counterpoint: databases. Guess where more errors occur ;)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 18, 2005 11:17 PM
Reply to this message Reply
> > > The error message is hard for a new programmer to
> > > understand because <tt>str</tt> and <tt>int</tt>
> aren't
> > > tangible.
> >
> > I'm not buying that argument. If it were true,
> > non-programmers wouldn't be able to use Excel. ;)
>
> This is a good point. Here is a counterpoint: databases.
> Guess where more errors occur ;)


You have data that in some way allows comparison of error rates between Excel and "databases"?

Peter Mechlenborg

Posts: 8
Nickname: pmech
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 19, 2005 3:51 AM
Reply to this message Reply
> There is a belief floating around that implicit typing
> makes programming easier to do and learn. I think this is
> rubbish. In order to explain why the following Python code
> is bad to a beginner you still have to explain the concept
> of types:
>

I agree. Types are also very important in dynamically typed languages.

> <pre>
> >>> x = 12
> >>> y = "13"
> >>> x + y
> TypeError: cannot concatenate 'str' and 'int' objects
> </pre>
>
> The error message is hard for a new programmer to
> understand because <tt>str</tt> and <tt>int</tt> aren't
> tangible.

Most error messages are difficult the first time you see them. You can find bad error messages in any language if the compiler is not geared towards this. I don't think this has any thing to do with typing.

Dynamic languages often gives you a stack trace when an error happens. Values on the stack can be inspected, and you can jump to the source code the corresponding to a stack frame. I find this very helpful and I assume that a newbie would too.

> My next beef is that accidental type conversions
> is one of the most common error I see programmers make
> while developing code in implicitly typed languages like
> VBScript and Python.

I don't think accidental type conversions happens in trongly typed languages, neither static nor dynamic. I thought that Python was a strongly type language so this surprises me, but maybe I'm misunderstanding you.

Can you give a concrete example.

> It is inefficient to have to track
> these down by first running the program, and having to
> test every single corner of the code. Static typing
> eliminates the need for type testing. In the end I see
> absolutely no advantage circumventing the few keystrokes
> it takes to explicitly write:
>
> <pre>
> string x = "12"
> int y = 13
> </pre>

I have used SML over a period of time. It is implicitly typed, through type inference. This I really liked, and I can't recall having any problems with types being implicit, actually I think this was a bonus.

>
> <p>
> Now when the programmer writes: <tt>x + y</tt> the
> inevitable type-error message that results is no longer
> something cryptic.

I don't have the impression that type errors in a dynamically typed language are cryptic.

> <p>
> In the relatively rare case a programmer truly needs a
> variant type, it is easy enough to just use something like
> the <tt>object</tt> type in Heron, the <a
&gt; href="http://www.codeproject.com/cpp/dynamic_typing.asp">cd
> iggins::any</a> type in C++, and so on.
> <p>
> Anyway that forms the basis for my justification for
> explicit typing in HeronScript, and why I wouldn't teach
> an implicitly typed Python as a first language.

I don't know Python very well, but I think that SML or Scheme would qualify as very good first languages.

Peter Mechlenborg

Posts: 8
Nickname: pmech
Registered: Sep, 2005

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 19, 2005 4:07 AM
Reply to this message Reply
> I agree. Types are also very important in dynamically typed languages.
The above should be read as: "I agree that types are also very important in dynamycally typed languages"

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 19, 2005 10:15 AM
Reply to this message Reply
Here is a transcript of trying the equivalent code on SML/NJ:


Standard ML of New Jersey v110.42 [FLINT v1.5], October 16, 2002
- val x = 12 ;
val x = 12 : int
- val y = "13" ;
val y = "13" : string
- x + y ;
stdIn:3.1-3.6 Error: operator and operand don't agree [tycon mismatch]
operator domain: int * int
operand: int * string
in expression:
x + y

uncaught exception Error
raised at: ../compiler/TopLevel/interact/evalloop.sml:52.48-52.56
../compiler/TopLevel/interact/evalloop.sml:35.55


As you can see, the compiler infers the types of expressions and responds with the result of the inference. The type error is quite clear. (Admittedly there are cases where Hindley-Milner style type-infering can yield rather difficult to understand errors, because the cause of the type error and the place where the error is detected may be far away. You can limit such problems by using type ascriptions.)

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Well trodden path Posted: Sep 19, 2005 1:05 PM
Reply to this message Reply
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.

> The error message is hard for a new programmer to
> understand because <tt>str</tt> and <tt>int</tt> aren't
> tangible.

Huh? Of course they are tangible. They are types in the system. Forcing the developer to write them down as part of the variable declaration doesn't make them any more tangible.

> My next beef is that accidental type conversions
> is one of the most common error I see programmers make
> while developing code in implicitly typed languages like
> VBScript and Python.

On this one, I'd have to argue that its the practice of allowing automatic type conversions that is the problem, not that the variables aren't typed.

> 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.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Implicit versus Explicit Dynamic Typing Posted: Sep 19, 2005 3:26 PM
Reply to this message Reply
Thanks again for an interesting blog/article, Christopher. I'm glad to find there are other people who "rant" against the "freedom" of dynamic/weak typing, as well. I've never bought the "freedom to make type-related errors"-argument (ok, that may be a straw man, but that's much of my experience with dynamically/weakly typed languages). I've "ranted" about this in the context of PHP in a couple of letters to the Editor of an ACCU journal ("Overload"), where I also got a reply from a more pro-dynamical typing person.

As I said in my letters, this discussion is easily muddled by ill-defined terms, as there are several axes involved when it comes to type checking and type safety, such as:

- Statically/dynamically typed (whether the checking happens at compile-time or run-time).
- Declared/implicit typing (whether the type is explicitly declared, or inferred)
- Strong/weak type checking (how "eager" the conversions are)

"Type safety" is typically defined as guarantees against undefined behaviour (i.e. if you write the bit-pattern of an "int" into a "double", you most likely will _not_ get the equivalent floating-point value - you'll get undefined behaviour). I think it may also be argued that type safety is a measure of how well you may avoid type-related errors, as in silent cenversions hiding errors. A "prominent" example in PHP is that an empty string - "" - or even "null" may be silently converted to integer 0. I mean, come on... :) I've had no end of "fun" chasing down stupid bugs due to this "eager" conversion, that could have been trivially - and much earlier - been found had the rules of conversion been more strict.

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...

So far, I've talked about statical/dynamical checking, and eager/strict conversions. The last axis: implicit/explicit typing, is also interesting: Haskell is an example of a statically typed language, with optional type declaration. If a type is not declared, it's inferred. With quite strict conversion rules, even if you don't declare types, this may be a quite safe way of doing it. Type inference gives static checking, without having to declare the types.

In C++, types are mostly declared, but we also have some type inference in the form of function templates, and a couple of standards proposals ("auto" and "decltype") would allow type inference also in non-deduced contexts.

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... :)

Regards,

Terje

Flat View: This topic has 95 replies on 7 pages [ 1  2  3  4  5  6 | » ]
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-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use