Hi Arthur

The article seems to position Leo as a serious production programmers tool. A learning curve it seems to me worth tackling after one has become a serious enough programmer.

Yes. But but besides the exisiting professsional needs of large coding projects, I do believe Leo offers a valuable emerging new paradigm, one which may find its best home with beginners and people in small collaborative groups. Actually it is not a so new.. StorySpace, Hypercard, Smalltalk.. etc As you know I am easily enthused. But I was not trying insist or impose a meta-tool like this on beginners, though some may love it. Nor on people happy and productive with reliable flat text files. KISS works. One of he strongest arguements against LEO is that is makes files main dependant on the application, or at least noe wihdih wknows what to do with the format. It is not restricted to that, as you will see if you sue. You can 'flatten', import adn export in a variety ofways. Just like Photoshop from a multi-layered image complete with masks, paths, and macros. 1. I was thinking towards the needs of embedding code within other structured con-text. Like a good textbook, web how-to article, and so on. All of those could now be managed in a way which pemits lineaer flat files but also allows incremental versions to be run dynamically within the surrounding text. 2. It might make collaboration easier. 3. It might help the transition from concept to pseudocoide to source code easier. 4. It might encourage people to more freely step out and into their code. That's usful for both analytic and creative parts of programming. There's a good reason why many people love text-folding and colored syntax highlighting. It makes it easier for them, though not perhaps everyone. Mathemtica's revolutionary 'Notebook' interface is a good example of how one can combine hands-on programming with document structure and publishing/presentation needs. Blogs are contemporary example of similar trend. Distrubuited publishing via RSS and XML-PRC mechanisms. Expandable code cia short form presetation of articles with "more..." and "comments.." links. Better separation [and integration] of form and content. XML, CSS, theme, author, style/idnetity, calendar-based sequences of related and un-related content provide a ean way for people to follow the progression. 5. XML for better and worse is here to stay for at least a generation. The need to handle that alone is good argument for tools like LEO. Suppose you want to start discussing a pprblem and then build data model with your class. You can start with simple needs adn observations, collect several versions from stuents, merge adn improve the best candidates, write parser code and methods for handling the models etc.. Tedious and hard to do with regualar editors. Perhaps not solo, but in a group class siutatnio wher you want ot build up the workabee able to review it, pehaps extend with anouth school or class. You could use CVS, but here is a tool in Python for Python. sweet and manageable.

Can't help using myself as an example. My position has been that time that might be spent learning programming tools is much better spent, at my stage of things, learning programming. And I am pretty well convinced that the type, cut, paste and run text editor with which I have become somewhat facile is all the tool I need at this point.

I do not doubt that. Once one can type even modestly well on a QWERTY keyboard, all other keyboards layouts are a painful distraction even if they are theoretically much better! But there is often great value in approaching problems from several perspectives. That's what my favorite Math teacher was good at when I was 14. If you were starting out without the habits you have now, you might be very appreciate of a tool which lets you go smoothly from high level to low level and back. Like the Zoom in a graphics app. Unthinkable now without it. Or resize on for windows, scrollbars, etc. What about indentation in Python. Expressly to clarify and simplify the code while imposing a consistent structure. Ditto docstrings. LEO appears to be a healthy product of those initial design decisions. The best argument I can make for LEO-like interfaces is that in the *right* hands they can improve thinking, design, understanding and presentation. It will take time to get these tools into a really good balance netween power and simplicity. The fist adn 2nd generation of Web development has sadly sold people on an extremely chaotic model where linsk typically take you *away* from the context. The rapid growth of Community Wikis alongside individual Blogs show people want better management of gathering and sharing their ideas, discoveries and work. I consdier the 3rd gernation of the Web now playing out. I think it much healthier than what came before.

Nor will I let myself buy new golf clubs til I break 90 with some consistency. Because I know the clubs ain't the problem, and only when I become better will I be able to take advantage of what is better about better clubs.

Granted. But remember, LEO is free btw, unlike those shiny new gold-plated titanium tipped, dayglo golf clubs you don't really need! ./Jason

We, on the surface, at least, seem to have a tempermental difference. I guess I need to feel that I have outgrown the old paradigms before I go searching for new ones with too much vigor. Don't give myself that much credit.

Yes. Point taken. I bit my tongue even as I typed those hazylazy words "new paradigm". Let me re-phrase.. This looks like a good idea, and I hope is progress.

Geometry is about as old a paradigm as there gets. It seems to have kept me busy enough for a good stretch now. I espouse a paradigm of sitting down with compass and ruler and doing Euclid - soup to nuts. As a start.

I love a good compass - especially the older ones, with nibs for ink.

mmm yes. Let's go Egyptian string sand and sea shells :-) For years I treasured a little second hand Russian pamphlet I found on the Charing Cross road. 'Geometry with [only] rulers and compass' - meaning straighedge no measurements or protractors. A similar epiphany, but a lot more complex+expensive, was seeing Tom Davis's 'Geometer' running on an SGI for the first time about 10 years ago. http://www.sgi.com/fun/freeware/software.html [A cousin/ancestor of Geometer's Sketchpad] He's now involved in Math circles: http://www.geometer.org/mathcircles/index.html ...which perhaps proves that this stuff really goes to your head! ./Jason

I taught Algorithmics to mathematicians, and I had, of course, the same problems. But it seems to me that mathematicians have to be conscious of this difference between object and value of this object, which in is more precise than the dichotomy variable and value of this variable, but not contradictory. On another side it seems to me easier to explain to mathematician the notion of mutable-immutable objects than to explain pointers... In your example, if I change the position of the statement "rec = [0]*n" as in def do_process1(LL): n=len(LL[0]) Res=[] for row in LL: rec = [0]*n rec[0] = row[0] # further code - modifying rec # lots of conditional processing and such... # ... Res += [rec] return Res the result of: do_process1(L_L) is evidently [[1, 0, 0], [2, 0, 0], [3, 0, 0]] And even for mathematicians, it is evident that functions do_process and do_process1 are not automatically equivalent. Marc Keller #§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§§ Michal Kaukic wrote:

Hi,

we like Python - I use it (with Numeric and SciPy modules) for teaching of Numerical analysis and my colleague is doing some research in discrete optimization in Python. And he often surprises me with non-conformal use of language :-)

We are mathematicians, not programmers. I suppose, he believes that Python "thinks" like Mathematician. Yesterday, he was struggling with the code shown below (somewhat simplified):

L_L=[[1,2,3], [2,3,4], [3,4,5]]

def do_process(LL): n=len(LL[0]) rec = [0]*n Res=[]

for row in LL: rec[0] = row[0] # further code - modifying rec # lots of conditional processing and such... # ... Res += [rec]

return Res

---------------------------------------------

After calling do_process(L_L), the "expected" result should be

[[1, 0, 0], [2, 0, 0], [3, 0, 0]]

but the true result is

[[3, 0, 0], [3, 0, 0], [3, 0, 0]].

Yes, this is fully in accordance with how the Python language should behave: Res += [rec] inserts references to list object rec, which are further modified... (he should use copy(rec) instead).

But there is nothing to make this behaviour clearly VISIBLE in code. If I work with pointers in C/C++ I know and see they are pointers. You can say - we also know that rec is list object and so be careful with it. Yes, but consider the complex code where the similar constructs are very easy to overlook. And debugging of such code can be frustrating.

My colleague was in state of despair and made thoughtful remarks about FORTRAN and Python similarity. He believes that Python is corrupting his (computer) memory...

So what is the point? I wrote this message in hope that there are more people with similar experience. My question is - how to explain to novice non-programmer users (maybe mathematically "infected") the quirks of Python sequence objects? Which methodology to use in programs so we can clearly see we work with "pointers"? Or maybe someone can propose the changes to the Language to overcome this (psychological) barrier? I feel this as a serious obstacle in using Python (my students experienced it too).

Thanks, Mike

_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig

So what is the point? I wrote this message in hope that there are more people with similar experience. My question is - how to explain to novice non-programmer users (maybe mathematically "infected") the quirks of Python sequence objects? Which methodology to use in programs so we can clearly see we work with "pointers"? Or maybe someone can propose the changes to the Language to overcome this (psychological) barrier? I feel this as a serious obstacle in using Python (my students experienced it too).

I usually draw a picture containing a few objects as boxes and a container as a separate box with arrows representing references to those boxes. I do this as early on in the tutorial as possible -- basically as soon as lists are covered. See e.g. page 16 of http://www.python.org/doc/essays/ppt/lwnyc2002/intro22.pdf (this discusses a slightly different guise of the same problem -- but it's really the same problem). --Guido van Rossum (home page: http://www.python.org/~guido/)