Many good points [LWN.net]

Many good points

Posted Nov 4, 2007 7:28 UTC (Sun) by drag (guest, #31333)
In reply to: Many good points by njs
Parent article: Daniel Bernstein: ten years of qmail security

Hrm. My experience is severely limited:

"Dynamicly typed" always ment to me that the type is determined when the variable is created,
based on various rules. That is variable types do not have to be declared before you can use
them. (although they can be if you prefer it)

The opposite is "staticly typed" were you have to declare variables types before using them.

The opposite of that is "weakly typed" were a int can be a string can be a float based on the
context in which it's used. That is if you make a 'int' you can use as a string if you feel
like it. The type is not enforced by the language.

So...

C == staticly, weakly typed
Perl == dynamicly, weakly typed
Java == staticly, strongly typed
Python == dynamicly, strongly typed

For example this is not legal in python:

a = "1" + 1

The "" is your way of declaring that value as a string, otherwise numbers by themselves are
always interpreted as int, hex, float, and other numeric types.

But, of course, none of this is hard and fast. Between numeric operators it'll do type
coercion.

a = 0x45 + 1.0 + 12
(so that is a hex + a float + a int)
And the result would 'a' be a float.

Or this could be a bit of a illusion as all these things support the 'add' function. I don't
know.

Maybe this is because my knowledge of all this stuff is purely from a python perspective and
the language that is used is to try to help programmers understand the differences between
other common languages.

But otherwise thanks for the clarification on the "But isn't that example of 'dynamicly
typed'?" That makes a lot of sense.

to post comments

Many good points

Posted Nov 4, 2007 9:30 UTC (Sun) by elanthis (guest, #6227) [Link] (2 responses)

To be blunt: nobody really cares what you think those terms mean.  They already have
well-defined meanings.  Look them up.

Many good points

Posted Nov 4, 2007 12:40 UTC (Sun) by drag (guest, #31333) [Link] (1 responses)

I did. That was my understanding.

Many good points

Posted Nov 5, 2007 0:09 UTC (Mon) by k8to (guest, #15413) [Link]

Dynimcally typed does not have anything to do with "when the variable is created"  it has to
do with the type of the variable being known at runtime, rather than at compile time.

Some corrections

Posted Nov 5, 2007 9:03 UTC (Mon) by flewellyn (subscriber, #5047) [Link] (3 responses)

"Dynamicly typed" always ment to me that the type is determined when the variable is created, based on various rules. That is variable types do not have to be declared before you can use them. (although they can be if you prefer it)

The opposite is "staticly typed" were you have to declare variables types before using them.

No. The "dynamic" verus "static" in the typing terms mean solely this: at what time is the type of this variable known? If it's known at compile-time, the variable is statically typed. If it can't necessarily be known until runtime, that variable is dynamically typed. Whether or not you have to declare types ahead of time is mostly irrelevant. I say "mostly" because some languages that are statically typed have facilities for dynamic typing if you want it, and some dynamically typed languages can do static typing if you ask for it.

A number of languages, like Haskell and Boo, have static typing, but by default use "type inference" to determine the type of a variable. So you can declare (using Boo here):

x = 1

And the variable x is determined to be numeric, and an integer. You can't thereafter assign a string, a float, or a value or object of some other type to x, since it's been determined that the type of x is integer.

You can, in Boo at least, declare a type, in case you need to do something special, so if I had said:

x as float = 1

Then x would be a float, and the 1 would be interpreted as 1.0. Also, Boo has optional "duck typing" that you can use to defer type resolution for a specific variable until runtime. This is a good idea if you are assigning user input to a value, and don't necessarily know what type that input will be. (If you DO know, it's a good idea to declare the type, so that the compiler knows what to do with it.)

On the other hand, some languages that are dynamically typed by default, such as Common Lisp, have optional type declarations; when you declare a variable's type, that variable becomes statically typed, and the compiler is free to leave out the usual type checks, which can improve performance. Some CL implementations will also treat type declarations as assertions if you set the compiler's optimization settings a certain way, so that you can get the benefit of static type checking if you want and need it. (Strictly speaking, a CL implementation is free to ignore type declarations altogether according to the spec, so this behavior is entirely implementation- dependent.)

But the crucial point here is that "static" versus "dynamic" typing has everything to do with WHEN a type is known, and nothing really to do with HOW it's known.

And "Strongly Typed" has always ment, to me, that once the variable is created then it can't be changed. That is if you create a variable as a int you can only use it as a int. If you want to use the int's value as a string you have to create a second string variable. The type is enforced by the language.

The opposite of that is "weakly typed" were a int can be a string can be a float based on the context in which it's used. That is if you make a 'int' you can use as a string if you feel like it. The type is not enforced by the language.

This is closer to correct, but still off. "Strongly typed" means that the VALUE'S type is strongly enforced: you can't add a string to an integer, or an integer to a character, without explicit casts, which may not work in any case (how do you coerce "Ich bin ein Berliner" to a numeric type?). You can have a strongly-typed dynamic language (Common Lisp), or a weakly typed static language (C).

The business of whether or not a variable can be rebound to a different type is a matter of static versus dynamic typing, not strong versus weak type safety. You can, in Common Lisp, bind a variable to a string value, then rebind it to a number, or a structure or class object, for that matter; just don't try to use string functions on the number. THAT'S strongly typed. (On the other hand, C will not let you assign a string value to an integer variable, but you could treat the int as a char.)

Some corrections

Posted Nov 6, 2007 10:09 UTC (Tue) by ekj (guest, #1524) [Link] (2 responses)

"Strongly typed" means that the VALUE'S type is strongly enforced: you can't add a string to an integer, or an integer to a character, without explicit casts, which may not work in any case

Well, that depends, now doesn't it ? If your strongly typed language comes with method overloading there's nothing stopping you from defining several add-functions, like say an "string add(int,string)" method. What, exactly, that'd do would be up to you. In some contexts it could make sense.

In python you can do: mystring = 10 * "-" + "Hello World" + 10 * "-", the very same thing would be perfectly possible in say C++, any language with operator overloading basically, regardless of if the language is statically or dynamically typed.

Some corrections

Posted Nov 7, 2007 0:16 UTC (Wed) by flewellyn (subscriber, #5047) [Link] (1 responses)

That doesn't really change what I said, actually. While in some languages you can use "+" to mean string concatenation as well as addition, if the language is strongly typed, it will choose which operation to do based on the types of the arguments. And you may need to cast things anyway, such as if you want to concatenate a number's string representation with a string. I've had to do such casts in Python.

Some corrections

Posted Nov 8, 2007 9:24 UTC (Thu) by ekj (guest, #1524) [Link]

Sure. You're running completely different functions for int+int and int+string, it just so
happens that the two functions have the same name. They don't need to have anything in common
other than the name.