Why weakly typed?
Author
I noticed that pratically all scripting languages have weakly typed variables: Lua, javascript, Python. Although functions provided by the "standard library" or by your program can have speficic argument types, user-written functions might fail miserably because there is no check for compatible types. What's wrong with using strongly typed variables, with a simplified object-oriented inheritance system where everything derives from an "object" type? That would still allow you to make some functions as general as you wish, but you'd catch many errors at "interpret-time" rather than during some rare case at run-time.
I was thinking of using javascript (the Rhino engine from Mozilla) to script a Java game, and it seems very good for the task (clear syntax, really easy bindings with Java, JIT-compilation to Java bytecode), except for this little detail of type safety.
Python is not weakly typed. Python is a strongly and dynamically typed languages.
Typing seems to confuse many people. There are two things about typing: when and how.
When:
* Compile-time: static
* Run-time: dynamic
How:
* Can't mismatch types: strong
* Can mismatch types: weak
PHP and Perl are dynamic and weak, C is static and weak, C# is static and strong, Smalltalk is dynamic and strong.
Typing seems to confuse many people. There are two things about typing: when and how.
When:
* Compile-time: static
* Run-time: dynamic
How:
* Can't mismatch types: strong
* Can mismatch types: weak
PHP and Perl are dynamic and weak, C is static and weak, C# is static and strong, Smalltalk is dynamic and strong.
Author
Maybe I'm not using the right terminology, but I mean a script like this:
AFAIK, this is valid Python, and the error doesn't get caught unless the script actually reaches f("hello"). In C++ or Java, you can't do something like this without explicitly casting "hello" to a number in either f or the else statement.
import randomfrom random import randintdef f(x): print x-1if(randint(0,1)): f(43)else: f("hello")AFAIK, this is valid Python, and the error doesn't get caught unless the script actually reaches f("hello"). In C++ or Java, you can't do something like this without explicitly casting "hello" to a number in either f or the else statement.
Testing will tend to reveal that error, and how often does that sort of problem happen in real code? I find that the static typing issue is something that is mentioned a lot by many programmers as a possible problem but which never seems to be an actual problem.
Quote:Original post by Matei
In C++ or Java, you can't do something like this without explicitly casting "hello" to a number in either f or the else statement.
Actually, you can!
template<class T> void f(T x){ std::cout << x-1 << std::endl;}int main(){ if( rand() % 2 ) f(43); else f("hello");}In python, you wouldn't be able to use a string as an int without a 'cast' either (actually, constructing an int object out of the string). This is what it means to be strongly typed.
The only difference here between C++ and Python is that in C++ the type is associated with the variable, while in python it is associated with the value.
difference: weak typing is no typing. That is, if you put an int in the place of a string, the program just carries on and assumes that the int is a pointer to the first character of the string - imagine if every C function took void pointers, and that's what weak typing means.
Python is strong, dynamic typing - that means that the typing is handled at run-time. This exists because typing is a big PITA in many programming languages, and scripting languages are meant to be fast. Plus, casting is risky, and can create errors much worse than the "unsupported operation" errors you get in scripting languages. Whats worse - a nicely caught dynamic type error, or a buffer overrun? So dynamic type information becomes necessary. In that case, the error catching is already there, so the syntactic sugar needed for static typechecking would be just that - painful syntax, nothing more.
Python is strong, dynamic typing - that means that the typing is handled at run-time. This exists because typing is a big PITA in many programming languages, and scripting languages are meant to be fast. Plus, casting is risky, and can create errors much worse than the "unsupported operation" errors you get in scripting languages. Whats worse - a nicely caught dynamic type error, or a buffer overrun? So dynamic type information becomes necessary. In that case, the error catching is already there, so the syntactic sugar needed for static typechecking would be just that - painful syntax, nothing more.
Quote:Original post by Matei
Maybe I'm not using the right terminology, but I mean a script like this:import randomfrom random import randintdef f(x): print x-1if(randint(0,1)): f(43)else: f("hello")
AFAIK, this is valid Python, and the error doesn't get caught unless the script actually reaches f("hello"). In C++ or Java, you can't do something like this without explicitly casting "hello" to a number in either f or the else statement.
Yeah, that's what is called dynamic typing or run-time typing.
Author
Quote:Original post by Fruny
Actually, you can!
*** Source Snippet Removed ***
That snippet won't compile I think, since string doesn't support the '-' operator. But anyway, everyone else seems to be comfortable with dynamic typing, so it probably doesn't lead to as many errors as it seems it might. I'll just go with it. Thanks for your explanations everybody.
One thing is that static typing is faster. It allows for compile-time optimizations. The problem is that today, the choice seems to be C (or its nephew, C#) or dynamic-typed languages. I'd like to see a modern, static-typed language, like a static-typed version of Ruby (syntactically my personal fave of the myriad dynamic-type languages). When I think about all those hash lookups in Python, my head spins.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
