[Tutor] Re: [Tutor] Re: Sorting a dictionary in one line?

[Magnus Lycka]

At 18:06 2003-01-20 -0700, Poor Yorick wrote:
>It's actually very inspiring to see that people like you and Danny make 
>mistakes and express things like, "...code gets much harder to understand 
>if I can't keep all the relevant parts in my primary field of vision at 
>the same time."

What ever qualities I might have, or have had, a photographic
memory was never one of them... Even if I *can* remember things
now and then, there's certainly less risk of making mistakes if
I can view all the relevant factors at once.

Imagine a car where there was no wind shield, visible mirrors or
instrumentation. All we saw was a CRT. In that CRT we could watch
all instruments, a forward view, a left view, a right view and a
rear view. Since they all fill up the screen, you have to scroll it
so that the forward view disappears when you look at the left view
or at the instrumentation. I don't think you'd like to drive such a
car.

Ok, it's not quite the same thing--you will hardly collide head on
with another computer program and die if you scroll away that piece
of code that you tried to debug, but to understand and solve problems
efficiently, it certainly helps to have all the relevant facts
available at the same time. In this way, python is much more helpful
than Java or C++ etc. (And without nasty side effects of obscurity as
in Perl.)

I'm an electronics engineer by education, and I've designed electronics
some years. There is a reason that CAE stations typically have large screens.
There is a reason circuit diagrams are often printed on large sheets of
paper and not on a pile of letter size sheets. (The alternative is if
blocks of circuits can easily be abstracted into a unit, then we can
sometimes apply a modular approach and use several smaller sheets.)

But there is a difference between hardware and software here. On a schematic
diagram you can zoom out to see more of an overview and navigate between
parts of the design. Then you can zoom in to see details. And typically,
there is little coupling between things that are located far away in the
diagram. There are practical and physical reasons for this. This zooming
works on scren, but it really works better when you have the paper sheet
pinned to a wall in front of you. (On the other hand, changing the schematic
in a pretty way is easier on the screen.)

Software is different. Software has no shape. Zooming out from the source
code won't give you an overview, it will just give hundreds of lines of
text that is so small that it can't be read. UI experts have been struggling
for many years to find better ways of changing perspectives in large
documents, but the old unix editors vi and emacs are still the best tools for
programming according to many. Some prefer IDE's but there is certainly no
revolutionary difference.

Diagramming tools etc are useful to solve a *bit* of this software problem.
That might aid in giving a better understanding of the basic structure of the
program, but it's often of limited aid in debugging and other tasks where you
work with tiny details.

>Because of the mountain of things I still have to learn and the slow pace 
>of my progress, I often think that programming is not for mere mortals 
>like me, and consider giving up the endeavor.

I started programming about 20 years ago, and began with python
in 1997. It takes time to learn, and that's nice, because learning
things is a fun thing to do, and it would be boring if we would
eventually have nothing more to learn...both individually and as
a collective.

>  But then I think something like, "That guy Magnus Lycka seems to be 
> human enough, and HE got through all this.  Keep going."

I'm certainly not flawless. Ask my wife! ;)

I'm sure my IQ peaked a number of years ago, but I'm still getting
wiser I hope. And learning new things. Besides, how ever clever we
are at these things, there are always higher mountains to claim,
so I think we all have to follow the same basic steps, about
being careful in what we do, trying to keep things as simple as
possible (but no simpler) and so on. Admitting ones fallability,
to oneself and to others, and to behave accordingly, is certainly
important for code quality. Don't forget about doing proper tests
of all your code. The unittest module is your friend. Testing
before coding is not a bad idea...


-- 
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