Dynamic vs Static Languages

Article - Are Dynamic Languages Going to Replace Static Languages?

Having looked at the possiblity of using Python for developing simple applications on a S60-based mobile phone I realised how close "classic Blitz" is compared to Python

Python is a dynamic language which means you don't have to declare the variables to be a specific type. The variables are objects and in that sense, have been unchained and free to be whatever they like:

abc=45
abc='help'

Languages like C++ force you to tell the compiler every minute detail of your programming intentions. This, it could be argued, kills creativity and increases development time since you are constantly trying to keep the compiler happy. The big plus though is that everything is water-tight and you have dotted the I's and crossed the T's

Is 'superstrict' programming merely a touch paranoid?
Or, does dynamic programming allow for your creative juices to flow (an possibly overspill)?

'superstrict' also optimizes the code a bit, and allows for faster execution since it doesn't have to do as much error checking and trying to second guess what you were probably trying to do.

The computer doesn't magically know what you want, after all.

This definition is misleading. The real meat of it is that all references can point ot any object.
Blitz was already staticly typed, it just happens that it defaulted variables to of type int.
Some staticly typed languages go further by using type inference: you can omit explicit typing, but variables as still staticly typed, it is simply inferred by the compiler.
Not being forced to explicitly type variables doesn't always imply a dynamicly typed language.

being paranoid is an effective way to be more effective when it comes to bug hunting. However it's true that dynamicly typed languages have some advantages, particularly in "exporative programming" (as it's easier to go forward with no particular design or planning).

The issue of "static typing" vs "duck typing" is an old one, and many people lately have somewhat rediscovered some virtues of "duck typing". However I feel that there might be some middle road, ala "static duck typing" this might sound totally stupid and/or impossible, but it's not. That's really a programming language theory thinigie though.

Having used dynamic languages alot, I really believe that having at least the option of strictness is essential for serious development. The potential for error is so much higher in dynamic languages and you usually end up chucking in tons of type error checking, which you can quickly avoid with strictness. I'd rather avoid the extra work. :)

Duck Typing is brilliant.

I once saw a PC mouse being crudely operated by a lesser spotted grebe. With its beak and left claw.

That was verging on amazing, too.

I once saw a tie-pin in the shape of a duck.

..I saw aliens..

I saw myself in the mirror once..

> Having used dynamic languages alot, I really believe that having at least the option of strictness is essential for serious development. The potential for error is so much higher in dynamic languages and you usually end up chucking in tons of type error checking, which you can quickly avoid with strictness

yep .. good point

So, 'dynamic' is better for off-the-cuff prototyping and 'static' when you want to nail the code down to a final master(?)
Actually, In BlitzMax I use SuperStrict from the start. This saves hundreds of nags I would get if I instead left it until the end

Still, I really like the overall cleanliness of Python

Coming from B2D/B3D I didn't see the point in Superstrict. It just seemed to be more typing and I was getting errors everywhere. However, after a few weeks I began to declare variables by habit and now I wouldn't code without it.
Jim, if anything, I set superstrict and then take it out of frozen code so it doesn't mess when being included/imported etc.
As for 'dynamically typed' I have only messed with it in Perl. At the moment I can't say I like it but I haven't used it/them enough to make it feel natural.

abc=45
abc='help'

How useful is this, really? How often have you wanted an integer to hold text? If you have, wouldn't a second text variable be more appropriate?

Not very. What's that got to do with duck typing and/or dynamic languages?

The benefit, IIRC, is you can pass either to a function as long as the function can operate on that object.

function add10(in)
  print in+10
end function
add10(abc)

would print 55 or help10 depending on what you passed.
You would be able to do the same with types without having to inherit. Imagine you had a rename function . As long as the object you passed had a rename method then it would be used. If it didn't it would return an error... I think
<edit>
Like this :

Type ttest
    Field name:String="Jim"
    Method rename(newname:String)
		name=newname
		Print name
    End Method
End Type 
Function rename(inobject:Object,name:String)
    inobject.rename(name)
End Function
Local mytest:ttest=New ttest
rename(mytest,"Bob")

Also it allows for cool things like monkey patching, and solves a lot of the headaches you get with statically typed, late binding languages (Google J2EE ClassLoader for example).