[Tutor] Python and Tcl/Tk/more

[Magnus Lycka]

At 11:17 2003-01-29 +0000, alan.gauld@bt.com wrote:
> > I think that one sells onself short if one focuses
> > on one and only one programming language.
>
>I totally agree (and I suspect Magnus does too!).

Sure!

But I have to admit that I have done very little in
other languages that Python the last two years, and
when I have to, I typically get disappointed about the
other tools.

For instance I had to do some Perl. Great I though, I
did Perl before I  found Python, but it used to be fun.
It's not such a different bird compared to Python, just
more arcane syntax etc...

Unfortunately I wasn't wearing the Camel book, and after
five years of absence, I didn't have a clue about how to
dereference values in a list of lists. :( None of the Perl
"hackers" at that location had ever done such "magic"
either. They just stared at me.

For those who haven't done Perl, I just wanted to do
something like:

l = [ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]

for m in l:
     for n in m:
         print n

This involves some special incantations called dereferencing
in Perl. The "Camel Book" by Larry Wall spends three pages
explaining the common mistakes in such an advanced feat.
Seriously! These pages are full of this-that-seems-correct-
won't-work-but-that-dangerous-looking-code-works-and-is-
more-efficient... There is no way you can guess how to do
this right based on simple Perl experience where you have used
lists, but never nested them inside each other. I'm not joking!

Some time ago, I help a physician with an Excel application.
Some VBA ought to be trivial. After all, the big "secret" is
that you use the macro recording feature of Excel to produce
most of the code for you, and then you just modify what you
need, and tie things together, calling functions from buttons
etc. The problem is that a lot of code ran once, and then
choked on the second attempt! In some cases this was probably
because of contexts issues. A piece of code might work in
Excel 2000 every time, but in Excel 97 it will only work if
a certain worksheet in the workbook is active, even though
the worksheet is explicitly addressed in the code, and the
docs make no mention of activating the sheet, and even though
it worked regardless of what sheet was active, when you replay
the recorded macro (that was just moved to another function).

There are also glaring differences between the docs and how things
works in real life. The docs consitently use Worksheets("Sheet 1"),
but if you type that, Excel doesn't know what you are after, you
have to type Sheets("Sheet 1"). Also, in the middle of typing, if
you leave the line unfinshed to copy some text from another line,
you will get a captive dialog that tells you that your code is in
error. Doh!

For some problems, the error message alternated between two
completely different and both unhelpful messages on every other
run. Sometimes, VBA complained that it couldn't find the methods
I wanted in range objects. Have you heard about classes suddenly
dropping methods in other languages? Maybe it actually failed to
find the right object, but it said things like "The Range object
doesn't have a Sort attribute".

When I run into these things I feel so happy about Python.

I certanly don't hesitate to use C, C++ or SQL where it's
useful, and some Java at times. I don't worry about editing
shell scripts, but if I have to write new script I will write
them in Python almost all the time.

PHP has really boomed, and become much bigger than Python,
but I must admit, that if I find an interesting applications
that is implemented in PHP (or Perl) I will take another look
to see if there is something good enough implemented in Python.

I might do some more MS Office / VBA work, but it's not a
preference.

I had a look at Ruby, but left it alone. I'm thinking about
trying to learn OCaml, partly because I use an application
called GeneWeb written in that language.

Hm... I guess I'll have a look at Rebol. I've been put off
by the fact that it's proprietary, but taking a peek can't
hurt, can it?

>I have never worked on a paying project that was implemented
>in only one language. Most have at least 3,

Really? Well, if you do relational databases you will at least
have SQL and one more I guess. C++, Java and SQL is a fairly
common trio I guess. And if you integrate with an old system,
some COBOL is likely to be involved as well I guess...

>and one
>had 12 different programming languages being used
>across a team of >150 developers located in 6 cities
>in 3 countries...

How convenient... ;)


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se