Andre Roberge wrote: > There are *so many* interesting packages written in Python that it > would be presumptuous, imo, to think that any individual or team of > individuals could provide a learning environment powerful enough to > satisfy all potential users of the various python modules that are > available.
Thanks for the thoughtful reply with many good points. I'll agree you have a good point I need to think more on from an educational point of view seeing Python as a broad platform and as people learn more about it they move from using one sort of library to another (or one sort of editing environment to another). It's a coherent way to look at Python and learning (both about Python itself and about things Python helps you simulate). Thanks for outlining it. Having said that, I still think there is a tension between two approaches. One is getting people to invest a modicum of effort up from to learn a small set of good tools like Smalltalk had even 30 years ago (browser, inspector, debugger and transcript being the core ones) to give a consistent experience to working with a well thought out core library. The other approach is learning one simple tool, and then another fancier one, and then another, etc, each perhaps easy to learn as a next step but missing some essential feature, and moving from simple libraries to more complex libraries as needs change. I don't want to sound too complaining, but perhaps there are a lot of Python libraries or tools sometimes because they are *all* missing essential features or built with limited time and attention and experience? Obviously, one hopes the reason is instead that they are all good for different things or they are coming at a problem from different points of view. :-) Most likely, it is a mix of both reasons. Still, in the case of Python development tools, and not having sampled them *all* myself, of the ones I've tried (Eclipse & PyDev, Eclipse & RedRobin, Idle, Boa Constructor, Scite, and a couple others) they do lack core features that any Smalltalker takes for granted -- for example always having an integrated restartable debugger available during development, or there usually being two levels of naming for methods and classes (i.e. an organization "protocol" or "category" level above the actual object or method level; almost all Smalltalks support this). And there are several other core missing features. Not to say Python doesn't have its own advantages, but the commercial Smalltalk libraries I've seen for all sorts of core things are just more complete than Python's (for example, all the stuff you can do with streams). [Python may win on breadth of free stuff, especially web related.] Granted there are also drawbacks to some of Smalltalk's approaches to things, and some of the libraries can require abstract thinking to use them, but, when working on large projects, in my mind there is little comparison, a good Smalltalk like VisualWorks (though maybe not always Squeak) wins over Python (for large projects) because it is easier to manage complexity in it usign those features. There may be lots of good reasons for using Python anyway, including being free-as-in-freedom, or being easy to learn for C programmers, but one should be realistic about its relative weaknesses so one knows where improvement can be done. So, does that mean a beginner should be overwhelmed by all this at the start (either tools or libraries)? Are "keyholes" sometimes good then? That's an interesting question. And Smalltalk has always suffered from a steep initial learning curve -- although I think webcasts like Francois Schnell did for PataPata (thanks again) could help a lot with that. So, one can still try to make an argument that a simple editor with a small program is enough to learn the syntax and core library of a language (as with a web based tool), and from then they can more onto other tools. I'm still not sure I buy that argument, :-) but I'm just trying to make explicit the assumptions underling it versus an alternative more monolithic conventional Smalltalk approach. I think part of this also depends whether you learn a system on your own (prhaps from a book or on the web) versus whether you learn it in a computer lab or through video demonstrations. Again, I've now seen from Francois' webcast and now others as I look around at, say, ShowMeDo, http://showmedo.com/ that watching even a five minute webcast may potentially make more complex GUIs much more accessible to novices (or at least, motivate them enough to push past the learning curve). Having mentored people learning Smalltalk in industry and taught C to Bio majors at a university, I know Smalltalk is the sort of thing most people do much better with when given a little hand holding up front -- much more so that something like VB or C++ (those those also benefit some of course). I think the difference is that in Smalltalk so much of a typical system is accessible within the environment (rarely meeting a compiled library brick wall) that helping people come to see that is much more important than in other systems (including sometimes Python) where one does rely on the documentation much more than the code. (Actually in Smalltalk, one usually relies on finding a real *example* of usage of an class of interest within the system...) So -- a lot of variables in choosing how to present Python programming to "everybody". How much hand holding is available? Do the learners have access to video presentations or other ways of seeing complex tools being used as in a classroom or computer lab? How motivated are the learners? Or how much are they willing to invest of their time relative to what benefits they expect? Or, from another perspective, how much time are the learners willing to "risk" before they see a payoff? Conventional Smalltalk tools often require you to be willing to risk a higher amount of time before seeing any significant payoff, whereas you can type " print 'hello' " on the Python command line and you are going. (Strictly speaking that isn't quite a fair comparison because in Smalltalk you can type something like " Transcript show: 'hello' " in almost any text pane and click "do it" from a menu, but most Smalltalkers don't consider that programming, which may be a flaw in how Smalltalk is typically taught. :-) And, obviously, the Squeak Team led by Alan Kay has been moving more in a simplified interface direction. They now have eToys, and beyond that Croquet with some other tools, plus there were predecessors also in Squeak. Now there is LogoWiki. So, they have made several attempts to put simpler (or different) interfaces on top of Squeak or, for LogoWiki, in front of people on the web (Squeak powered or not). Or in effect, creating "keyholes" in front of Smalltalk. (Although, Smalltalk always remains easily available at least in the Squeak powered examples). So that is a vote even by the inventors of Smalltalk for such simpler interfaces. Personally, I remain uneasy about those directions. While I am all for tools to help making programming easier or even sometimes doing some of it graphically, I think (as Kirby perhaps does?) that something big is missing if there is no textual representation, or if the text representation, as in eToys, is somehow, how to say this, somewhat fragmented? And I can wonder if the eToys and such are really as easy to use (for novices) as they look in demos (or even webcasts :-). I know from the history of Smalltalk that young kids, when given some hand holding, really can do stuff with textual Smalltalk representations. I presume that extends to Python, even though Python is a harder language to learn and use in some ways than Smalltalk -- if you don't already know C or something like it. Anyway, I'm mainly trying to think through some of these issues for myself, including for how PataPata proceeds, so thanks again for your comment (and thanks to Kirby for his too). Perhaps ultimately there is just a cultural issue (influenced perhaps by technological choices). With excellent modules from the start, and always being free and originating at a university, Python has a modular culture with quite a bit of diversity, and that is reflected in the philosophy you outline of learning how to navigate within that community with all its choices. Smalltalk, on the other hand, even though supposedly made for kids, was born in chains in the heart of Silicon Valley, inspiring the Macintosh, and (unfortunately?) aspiring later for a while to be the successor to COBOL in the financial world, and was highly polished for decades by a relatively larger team of well paid technologists some of whom went on to create publicly traded companies around it, and that shows a very different cultural legacy -- more monolithic, less focus on modularity, a requirement applications be packages without the compiler/interpreter, and until Squeak (and a few lesser known others) the language had little of the scent of freedom around it. So, some big cultural divides are there historically in how the communities and technologies were created and evolved -- each with some good points and bad points. So, one could also argue that your stepping stone approach (or "learning steps" and "shallow curves") is also as much an introduction to a Python community and related philosophies of freedom underlying the diversity of tools and libraries as it is learning to program. :-) Still, I still don't want to let Python off the hook for missing some good features Smalltalk had thirty years ago (though I've made some small efforts at adding some such things to Python. :-) [Well, need to wind this down and I'll be traveling for a week, so maybe not much more follow up, sorry.] --Paul Fernhout _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
