Chewing one's arm off to avoid VBScript (was RE: Serious privacy leak in Python for Windows)

[Alex Martelli]

"Mark McEahern" <marklists at mceahern.com> wrote in message
news:mailman.1011278548.26416.python-list at python.org...
    ...
> (http://www.markmceahern.com/2001_12_30_archive#8352000):
>
>   i want to share my joy in python with the following trivia:
>
>     # let's create a dictionary
>     dict = {'a': 'first letter', 'b': 'second letter'}
>     for key in dict.keys():
>       print "%s = %s" % (key, dict[key])

So far so good.

>   compare that to vbscript:
>
>     ' let's create a dictionary
>     set dict = createobject("scripting.dictionary")
>     dict.add "a", "first letter"
>     dict.add "b", "second letter"
>     k = dict.keys()
>     s = ""
>     for i = 0 to ubound(k)
>       s = s & "k = " & dict.item(k(i)) & vbCrLf
>     next
>     msgbox s ' or response.write s for asp

Unfair!  If you want to use VBScript, use GOOD VBScript:

     ' let's create a dictionary
     set dict = createobject("scripting.dictionary")
     dict.add "a", "first letter"
     dict.add "b", "second letter"
     for each key in dict
         WScript.Echo key & " = " & dict(key)
     next

Here we can see the differences more precisely:

1. Python has dictionaries and their initialization as built-ins, while
   VBScript uses what Python would call "a module" (actually a COM object)
   and thus needs separate creation and initialization calls

This is similar to the Python vs Perl distinction on RE's: Perl has
RE's built-in, while Python uses a module and thus needs explicit
import and calls (re.search etc, where Perl would just use /.../).

I don't think Python is worse than Perl because it doesn't bundle
RE's inside the core language: I think it's better because of this.
I also agree with the design decision to have dictionaries in the
core language, _because_ they're so widely used internally too.  But
it's clearly not a black-and-white issue, either way.

Of course a language may show up better if you choose an example
where it uses a built-in feature while another language must
import a module, create an external object, and suchlike.  But
it's not an intrinsically fair comparison.  If having stuff built
in was always a win, the most-bloated language would be best...:-).

2. Python has "output to standard-output" as built-in, while VBScript
   uses external objects for that purpose.  Given how marginal the
   use of standard-output is in most Windows cases, that's quite a
   reasonable design choice, too.  Note that I'm using WScript.Echo
   for the output, as the WSH is a typical way to run VBScript; if
   you run this with cscript.exe, WScript.Echo calls will go to the
   console, if with wscript.exe, to message-boxes instead.

Basically these points 1 and 2 tell us that VBScript is a lighter,
more-"glue" language than Python, having less built-in stuff.  In
general, that is not necessarily a bad thing, just as it isn't for
Python to be lighter, more-glue, and with less built-in than Perl.

3. the syntax -- "for key in dict.keys():" vs "for each key in dict".
Who's more readable here?  Fortunately, Python 2.2 gets one better
by enabling "for key in dict:" and reaches parity.

But in neither language does it make much sense to extract the
keys as array/list and then loop over INDICES inside that, when
both languages let you loop directly over the dictionary!


>   btw, this is an example of what people mean when they say vb is verbose.
>
> in python, if you want a dictionary, you can just write it.  not so in
> vbscript.  likewise, consider this abomination of syntax for accessing an
> item:
>
> dict.item(k(i))
>
> i mean, what the f*** is that?  ;-)  compare that to:
>
> dict[key]

Better compare it to dict(key), which is the normal and idiomatic way
to index into dict in VBScript -- otherwise you might have to compare
with (2.2) dict.__getitem__(ks.__getitem__(i)) in Python:-).


There ARE serious points of inferiority with VBScript when compared
to Python, such as the PITIFUL "error handling" in VBScript (just not
in the same league with Python's try/except), the horrid "assignment
is a copy and the set verb cancels that" VB model (versus Python's
clean and consistent "assignment is always about references"), and
many more.  But your example doesn't cut the mustard, IMHO, since
the way it uses VBScript is seriously unidiomatic and suboptimal.

Pragmatically, VBScript's greatest issue is that it's dead: Microsoft
has announced quite a while ago that there will never be another
"Visual basic scripting edition" -- rather, the scripting abilities
will be rolled into the for-$$$ professional VB product.  Python, on
the other hand, is VERY much alive -- bugs will keep getting fixed,
new platforms supported as they become important, and so on.


Alex