You can't have dynamic and strong typing at the same time. Unless of course your actually referring to the fact that Python supports expando objects by implementing IDispatchEx.
"readability" isn't even a concern- for most languages it depends on how much you know it, and more precisely how it's written.
Exception being regular expressions... and since they dominate perl, it can be difficult to make extremely readable perl code, unless you dump using regular expressions to begin with... but that is it's most powerful feature.
Regarding Object orientation- Python is not Object oriented. It's code doesn't reside in Classes. You write a Python code file- but it's not a class- and if it is, how do you define such things as inheritance, implemented interfaces and aggregate classes? These are all a requirement of Object orientation, and I see none of them in Python.
Visual Basic 6 only lacks inheritance- this is because it's based on the Component Object Model (COM)... (this oddly enough allows it to interface even with .NET classes... which is a bit disorienting, to be honest.).
saying VB6 isn't efficient and saying Python is is a bit stupid and obviously not backed up with anything substantial. Python is a interpreted language. VB6 can be compiled to Native code. (although P-code is only about 5% slower on average). Python by design (same with VBScript, Javascript, Perl, and any number of languages) is limited by it's interpreter.
a small bit of Python:
def translate(str,dict):
words = string.split(string.lower(str))
keys = dict.keys();
for i in range(0,len(words)):
if words[i] in keys:
words[i] = dict[words[i]]
return string.join(words)
equivalent VB6:
Public Function Translate(ByVal Str As String, Dict As Scripting.Dictionary) As String
Dim words() As String, i As Long
words = Split(Str, " ")
For i = 0 To UBound(words)
If Dict.Exists(words(i)) Then
words(i) = Dict(words(i))
End If
Next i
Translate = Join(words, " ")
End Function
Problems with Python: whitespace is important. this is probably one of the stupidest and most restricting ideas ever conceived of for a language, but it does have the advantage of forcing what should be done anyway. Also neat is what appears to be the usage of a loop construct that is "set" so to speak:
For <variable> = <start> to <finish> step <step>
it takes the approach of:
for <variable> in <array>
This is very cool. So cool in fact that VB has it.(heh)
For Each <variable> in <array>
works just fine. The added advantage is that for basic iterating through an array, you don't need to create an array with the "range" function, or any other function, for that matter.
Note that in this specific instance, the VB6 version will have significantly reduced memory usage, since the dictionary is a object, just like in the python version. In this case, however, we can see that from the header, since it is a strongly-typed early-bound reference to a Dictionary object. Calling this routine with, say, an array or a reference to a control, or a array, you'll get a type mismatch error. With python, well, who knows. your claims about strong typing seem to be over-emphasized, I see no evidence of any types whatsoever, and the lack of types is the single-biggest cause of bugs in programming languages that support it. (this includes VB, which allows loose typing with the use of the Variant type introduced in VB2)
Flexiblility:
Visual Basic allows for the use of the "implements" keyword in the declarations section of a form or class module. this will alow that object to be used polymorphically as an instance of that interface. For example, I have used it with my Expression Parser to allow the creation of "Plugin" objects that can handle operators, functions, and even add new previously undefined behaviour, like the on-the-fly interpretation of Environment variables. (this is in fact used for the Core as well). I imagine this type of behaviour must also be supported by python?
The only addition Python can possibly add to the Object abilities of VB6 is Implementation inheritance (akin to the "inherits" keyword in VB.NET). However, VB6 can do Implementation inheritance, via the use of it's current ability to inherit Interfaces combined with the use of an aggregate class of the inherited type. For example:
cSuperclass.cls:
Option Explicit
Public Function Add(Numbers() as Variant) as Variant
Dim Total as Variant
Dim CurrVal as Variant
For Each CurrVal in Numbers
Total = Total + currVal
Next
Add = Total
End Function
subclass.cls, which Inherits the implementation of superclass.cls:
Option Explicit
Implements cSuperClass
Private mvarSuper as superclass
Private Sub Class_Initialize()
set mvarSuper = New cSuperClass
End Sub
Private Function cSuperClass_Add(Numbers() as Variant) as Variant
cSuperClass_Add = mvarSuper.Add(Numbers)
End Sub
Public Function Add(Numbers() as Variant) as Variant
Add = mvarSuper.Add(copy)
End Function
it is, however, kind of messy. Besides, the entire concept of inheriting an entire implementation is flawed, since it requires knowledge about that implementation- (is it safe to override method "X"?). It would have been possible for the fluff used in the VB above to be made "behind the scenes" so to speak, and create an "inherits" keyword. However cooler heads prevailed.
Implementation Inheritance is purely part of the domain of weak object heirarchies, and is just as easily created using Interfaces and specific Pre and Post conditions. the main problem with Implementation Inheritance is it is used simply because it is there. I have seen entire java applets written with three classes, all different versions of the applet, each version extending from the previous. This type of use of the feature is stupid. the functionality could have been added right into the "version one" class. the main use of Implementation inheritance is to allow default behaviour for any method that the implementor does not wish to change. But I proclaim that the problem is the changing of the implementation at all- as I said before, without knowing how it works, how can one know it is safe to change?
and now I'm rambling about Object oriented design principles. Oh well.
Anyway, to summarize, your evaluation is biassed and therefore wrong. Python is a great language but is no better overall then most others.
