Kirby -
In any case, if nothing else, I think PyGeo proved a central tenet of this list, which is that Python is a great ladder into higher level programming for people relatively new to the discipline (which you've subsequently developed). You've made this point as well.
I think you once called me a poster boy for Python as a first language. I hope so. I do all this very part-time - and am out there doing some decent Java stuff at this point - the step from Python to Java having been pretty painless. Which is among the reasons I remain devoted to the concept of introducing programming via Python - and despite my (considerable) frustrations on the EDU-SIG list. ART
Which is among the reasons I remain devoted to the concept of introducing programming via Python - and despite my (considerable) frustrations on the EDU-SIG list.
ART
I appreciate your staying with it. Thanks again for alerting me about that O'Reilly write-up of my work at http://www.oreillynet.com/pub/a/python/2000/10/04/pythonnews.html Subsequent to my citing it here on edu-sig, I got email from Shriram Krishnamurthi, one of the chief Schemers (has authored or co-authored a lot of curriculum writing). She wrote, in part: Gee, great. I can never tell how to appropriately applaud your work. In the process of your extremely laudable efforts at educating people about math, you'll end up miseducating people about computer science. But I guess you don't really care about that... Seems there's still some bitterness about Python making any inroads at all into education, which has been the focus of TeachScheme! for much longer (the python.org edu-sig web page has long linked to it [1] -- I haven't found any reciprocal links going the other way though). The "competition" between myself and the Schemers isn't very real however. TeachScheme isn't trying to interest K-12 math teachers in using a command line interface (CLI or REPL) to communicate math concepts. If it were, I'd have seen lots of posts to the Math Forum, e.g. to k12.ed.math or to math-teach. But there's nothing. I sense no real overlap in our efforts. Anyway, I spent some hours since Shriram's email refamiliarizing myself with Scheme (RScheme to be specific) and going further into it. I see some commonalities with Python, in particular the abstraction of thinking of all names as pointers to objects, including names of functions, which may be passed as parameters to other functions. If you master lambda, filter, apply, reduce, zip and map (I may be forgetting some) in Python, you'll have some transferrable understanding I think, as these features inherit from the same "functional programming" background that Scheme does. This ability to make "function factories" will build procedures using lambda and passed parameters is something Python can do as well. So my thinking is learning Python is not going to hurt you when you later tackle Scheme (if you do). Plus it contains a lot more of the conventional imperative language structure, plus a lot of OO, which the various flavors of Schemes don't all implement (having a class hierarchy with inheritance is different from the 'everything a referent to an object' abstraction). So Python is a better waystation to Java (and C++) than is Scheme IMO. I continue to have the impression (I think it's more than a mere prejudice, as I've been doing some studying) that Scheme is more academic and less interested in venturing into the rough and tumble world of writing to sockets, encryption, XML, unicode, working with various kinds of GUI widget, than is Python. There's a difference between being extensible in principle, and actually having all those libraries ready for download *now*. But I haven't studied the Scheme Repository in much detail yet, and am willing to have my mind expanded. The more the merrier. I am not a huge fan of recursion as the greatest way to do anything looping. It's cool, but these recursive-wherever-possible languages feel like one of those situations in which you've taught your dog to roll over, so now you make your dog roll over and over and over -- to the exclusion of all other tricks. How impressed should we be? This is more a prejudice I realize -- shared by many who didn't cut their programming teeth in the LISPish world, where recursion is god. So, I hope I haven't started a language war. I'm still of the opinion that Scheme is a great technology, but that it's not either/or. Scheme isn't very actively competing in the area I'm looking at, and learning Python early isn't going to "ruin you for Scheme" if you decide to tackle that one too, perhaps down the road, when you've decided that computer science is going to be a central focus ("computer programming for everybody" or CP4E involves sharing programming savvy with folks who will _not_ be making that decision). Kirby [1] http://www.python.org/sigs/edu-sig/
From: Kirby Urner <pdx4d@teleport.com>
Anyway, I spent some hours since Shriram's email refamiliarizing myself with Scheme (RScheme to be specific) and going further into it. I see some commonalities with Python, in particular the abstraction of thinking of all names as pointers to objects, including names of functions, which may be passed as parameters to other functions.
I took a very brief look at the TeachScheme! project and the book draft. It is great to see such work being logically developed and articulated. It can surely only have aa good influence.. But something bothers me. As creative person still struggling to attain fluency in programming, I consider myself a useful guinea-pig testcase for some aspects of CP4E. I find myself become more of an instant nutcase than testcase when I look at even this trivial example: (define (area-of-disk r) (* 3.14 (* r r))) A voice inside my head starts saying "No. Stop no!" This just does not look or feel right, but I find it hard to articulate why... But to me this pretty much exemplifies what _is_ wrong with so much computer science. It is not 'natural', and certainly not intuitive to my brain. Okay, yes one can learn the syntax and methodology of this language, adapt to its rules and profit from its true virtues. Many do. I have couple of very bright acquaintances doing wonderful work with Scheme. But they are also already very sophisticated and accomplished programmers with a truckload of languages and major projects behind them who came to it later.. I wonder to how many people react differently from me, and what the real pre-conditions are whereby one says instead "oh yes of course! :-)" Now Python by contrast makes me feel sane.. ..and it did so from day 0 def areaCircle(radius): area = (radius * radius) * 3.14 return area ### I promise you I am not writing this to engage in any language war debate. Rather I am genuinely curious what others feel about this question of common sense, intuition and programming vis-a-vis development, curriculum, CP4E. I think my allergy to some programming languages stem from 2 things: - visual syntax clarity matters to me [Python white space indentation = v. nice] - natural language or object order.. This last one is very tricky I know because English is my mother tongue so I cannot really know how does programming syntax feel to people around the world from different subject-object-verb systems? I get a glimpse only from use and study of other spoken languages and when speaking with non-English speakers. The order of things seems to matter and be important beyond just spoken language but to how we function in this world. Especially when we are very young and learning to recognize core patterns and dvelop skills based on those... Are there consistent universal patterns of recognition and action which are independent from language culture personality? How does learning play into this.. Where does early computer programming belong? I would love to hear about anyone's personal experiences from both the learning and teaching side of this huge question. And if you know any suitable paradigms/ reading / research on this... The last book I read was Andy diSessa's latest: Changing Minds: Computers, Learning, and Literacy by Andrea A. Disessa Hardcover - 320 pages 1st edition (May 15, 2000) MIT Press; ISBN: 0262041804 .. recommended.. your thoughts most welcome - Jason
At 04:15 PM 10/8/00 -0400, you wrote:
I find myself become more of an instant nutcase than testcase when I look at even this trivial example:
(define (area-of-disk r) (* 3.14 (* r r)))
A voice inside my head starts saying "No. Stop no!"
Jason, I've been programming C since 1984, and my reaction is identical to yours. Whatever that thing is, it's not normal C/Python/Perl/fortran syntax, nor is it reverse polish as far as I can see. I cannot *even imagine* how a kid would understand that syntax. Personally, I'd feel much better if it were 3.14*r*r or 3.14*(r**2). Or even 3.14 (r r *)* or 3.14 r * r * would be preferable to the syntax you quote. The syntax you quote is quite unfathomable to me. My opinion only. Steve Steve Litt Webmaster, Troubleshooters.Com http://www.troubleshooters.com slitt@troubleshooters.com
your thoughts most welcome - Jason
I agree that prefix notation (+ 1 1) vs. infix notation (1 + 1) is something of a curve ball for most of us. That's why I'd do some work to introduce it earlier, perhaps by booting DrScheme on a classroom projector. "Look folks," I'd say "we all get used to a = 1 + 1 from our text books, but you should realize that's cultural, and a serious alternative, actually used in some computer languages, would go like this (define a (+ 1 1)). Note that 'define', which plays the role of '=', is likewise a prefix -- very consistent." This comes under the heading of "ET Math" or "Math from Mars" in my book -- a sort of genre I work with. The point is to give insights into math by showing "what could be different, and still be of utility to an intelligent life form".[1] I do something similar with coordinate systems, showing an apparatus that uses 4-tuples of non-negatives to map ordinary volume (similar to XYZ in other words) -- a gizmo I call "the quadrays coordinate system" and have researched with colleagues.[2] Another game is to show how triangles and tetrahedra make fine models of 2nd and 3rd powering respectively, so we could be saying "3 tetrahedroned = 27" instead of "3 cubed = 27".[3] Again, we're brushing up against a whole other paradigm, an "ET Math" if you will. In other words, I think this prefix vs. infix discussion presents a great opportunity to open a door, expand the mind. That being said, we don't necessarily have to go through the door and spend the whole semester there. For kids encountering all this stuff for almost the first time, it's all pretty alien, and too many alternatives all at once can be too disorienting -- so I think we should walk a fine line. Open a lot of doors, but don't try to go through them all. Leave them for later -- you can come back to this stuff. I'm thinking Python might be used to open a door to Scheme. Instead of the usual thing, of putting two languages side-by-side and showing how different they are, we can modify our style of coding in Python to make it appear more Scheme-like. We can write recursively, for example, and do some functional programming kind of things. For example, you can define car and cdr of LISP fame:
def car(mylist): if len(mylist)==0: return [] else: return mylist[0]
def cdr(mylist): if len(mylist)==0: return [] else: return mylist[1:]
Usage:
car([1,2,3,4,5]) 1 cdr([1,2,3,4,5]) [2,3,4,5]
In Scheme:
(define mylist '(1 2 3 4 5)) (car mylist) 1 (cdr mylist) (2 3 4 5)
Then we can do something recursive like this:
from operator import *
def Reduce(operator,mylist): if len(mylist)==1: return car(mylist) else: return apply(operator, (car(mylist), Reduce(operator, cdr(mylist))) )
Reduce(add,[1,2,3,4,5]) # = (+ 1 (+ 2 (+ 3 (+ 4 5)))) 15 Reduce(mul,[1,2,3,4,5]) + = (* 1 (* 2 (* 3 (* 4 5)))) 120
Note that I've named this Reduce, not reduce, which is a built-in, and gives the same results:
reduce(add,[1,2,3,4,5]) 15 reduce(mul,[1,2,3,4,5]) 120
Although Scheme purists might have little patience for such stuff, I think this helps communicate some of the flavor of Scheme to those more familiar with Python. In sum, even if going with Python as a first language, I'd open a door to Scheme via introducing prefix notation, and would lay some groundwork in Python (as per the above example) for latter tackling Scheme and similar languages. Kirby [1] more re "ET Math": http://www.teleport.com/~pdx4d/amtepost2.html [2] http://www.teleport.com/~pdx4d/quadintro.html (links to Python implementation in 'For further reading') [3] http://www.rwgrayprojects.com/synergetics/s09/figs/f9001.html
Thanks for the fast schematics..
I agree that prefix notation (+ 1 1) vs. infix notation (1 + 1) is something of a curve ball for most of us.
Yes interesting isn't it? What I am asking is why do we perceive it as a curve ball ...and then later some of us say wow this is really cool? I grew a little bit studying Forth whose simplicity and elegant philosophy I loved. I used an interactive forth called JForth on Amiga. It was a lot of fun. So at that time I grew used to: 1 1 + in a simplistic way I see this topic reduces: object action object action object object object object action That just about covers what the basic permutations people have open to them right? Python, Scheme, Forth Sort of trigram of approaches..
That's why I'd do some work to introduce it earlier, perhaps by booting DrScheme on a classroom projector. "Look folks," I'd say "we all get used to a = 1 + 1 from our text books, but you should realize that's cultural, and a serious alternative, actually used in some computer languages, would go like this (define a (+ 1 1)). Note that 'define', which plays the role of '=', is likewise a prefix -- very consistent."
Cool. What is still nagging at me how different it feels when we add some spoken meta-language. This harkens to the importance and role of narrative. It is not that one is good bad or netter than any other, but we need symbolic language 'keys' to unlock the magic so it becomes logic. Walk-through, talk-through - 'stories' seem to do this..
This comes under the heading of "ET Math" or "Math from Mars" in my book -- a sort of genre I work with. The point is to give insights into math by showing "what could be different, and still be of utility to an intelligent life form".[1]
This is very nice. I feel better already :-)
I do something similar with coordinate systems, showing an apparatus that uses 4-tuples of non-negatives to map ordinary volume (similar to XYZ in other words) -- a gizmo I call "the quadrays coordinate system" and have researched with colleagues.[2]
Another game is to show how triangles and tetrahedra make fine models of 2nd and 3rd powering respectively, so we could be saying "3 tetrahedroned = 27" instead of "3 cubed = 27".[3] Again, we're brushing up against a whole other paradigm, an "ET Math" if you will.
Nice. [ Did you ever read Kurt Vonnegut's "The Sirens of Titan"?]
In other words, I think this prefix vs. infix discussion presents a great opportunity to open a door, expand the mind.
Excellent. This makes me really want to get to the root what the differences between prefix infix postfix are -- in language in culture and perhaps most importantly in thinking ? Are they just 3 sides of a universal triangle? How far do they reach? Can we map them ?
In sum, even if going with Python as a first language, I'd open a door to Scheme via introducing prefix notation, and would lay some groundwork in Python (as per the above example) for latter tackling Scheme and similar languages.
I like this approach to introducing the comparative potentials of pre- post- in-fix, using Python [or any one, take your pick] to show how to simulate or step into the other. It makes the continuum present and accessible. It introduces the idea of sequence in an important way, not just for mathematics function but any process of thought and action. And of course, our own written symbols, spoken languages, and narratives can help to connect these variations. The parallel between counting in different number bases and programming different object-action bases seems very healthy whole-system way to get close to the core of why programming belongs at the center of new comprehensive literacy. I hope this makes sense.. - Jason
In a previous post I wrote:
For example, you can define car and cdr of LISP fame:
def car(mylist): if len(mylist)==0: return [] else: return mylist[0]
def cdr(mylist): if len(mylist)==0: return [] else: return mylist[1:]
That's clearly not quite right. Here's car and cdr in action in DrScheme: Welcome to DrScheme, version 101. Language: Textual Full Scheme (MzScheme).
(car '()) car: expects argument of type <pair>; given () (car '(1)) 1 (cdr '(1)) ()
In other words, the car of an empty list is undefined. The car of a 1-member list is that member. The cdr of a 1 member list is the empty list (provided it's a proper list of cons pairs -- but that's another story). So... def car(mylist): return mylist[0] # first member def cdr(mylist): if len(mylist)==1: return [] # returns empty list else: return mylist[1:] # else, rest of list
car((1,)) 1 cdr((1,)) []
You get error messages if your argument to either is an empty list. Then: def Reduce(operator,mylist): if len(mylist)==1: return car(mylist) else: return apply(operator, ( car(mylist), Reduce(operator,cdr(mylist)) ) ) Usage:
Reduce(operator.mul,range(1,11)) 3628800 1*2*3*4*5*6*7*8*9*10 3628800
I'm not saying we should customarily program this way, simply that it's possible to communicate some of the flavor of Scheme by bringing analogous features of Python into the foreground. One could go on to define caaaar, cddddr, cdadar, cdar, cadadr -- the whole set of weird (unpronouncable) words for doing "slice arithemetic". http://www.cs.washington.edu/education/courses/341/99su/lectures/scheme/img0 28.GIF shows ([lambda (x y)(+ (* 2 x) y)] 4 5) evaluating to 13. In DrScheme:
([lambda (x y)(+ (* 2 x) y)] 4 5) 13
In Python:
apply(lambda x,y: 2*x + y, (4,5)) 13
Like in Scheme, in Python you can bind the lambda part to a name:
f = lambda x,y: 2*x + y f(4,5) 13
Alternatively:
def f(x,y): return apply(lambda x,y: 2*x + y,(x,y))
f(4,5) 13
Which is just a rather long-winded way of just saying:
def f(x,y): return 2*x + y
http://www.cs.washington.edu/education/courses/341/99su/lectures/scheme/img0 68.GIF shows a "procedure factory": We go
(filter [lambda (x) (>= x 0)] '(-2 -3 -1 3 1 4)) (3 1 4)
i.e. returns x's >= 0 -- this doesn't seem to work in DrScheme (apparently filter is not a primitive).
(filter [lambda (x) (>= x 2)] '(-2 -3 -1 3 1 4)) (3 4)
returns x's >= 2 So we'd like to define a function which creates other functions with n being whatever number we have to be greater than. In Scheme, that looks like: (define (greater-than-n?? n) (lambda (x) (>= x n))) Then you can say: (define greater-than-2 (greater-than-n?? 2)) ^^^^^^^^^^^^^^^^^^^^ returns a pointer to a procedure and get a procedure, i.e.
((greater-than-2) '(-2 -3 -1 3 1 4)) (3 4)
In Python:
def gt_n(n): return eval('lambda x: x>%s' % n)
gt_2 = gt_n(2) ^^^^^^ returns a pointer to a procedure
gt_2(-1) 0 gt_2(3) 1 filter(gt_2,[-3, -2, 1, 3, 1, 4]) [3, 4]
Thanks to Jeff Cogswell for teaching me the above. Thanks to Greg Badros's lecture notes re Scheme at http://www.cs.washington.edu/education/courses/341/99su/lectures/scheme/ for slide GIFs. Thanks to John Clements, Matthias Felleisen, Robby Findler, Cormac Flanagan, Matthew Flatt, Shriram Krishnamurthi, and Paul Steckler et al for the Dr. Scheme software. http://www.npr.org/ramfiles/wesun/19990404.wesun.07.ram to hear Paul Steckler play that Sunday game program on NPR. Also, listen to Matthias on http://www.cs.rice.edu/CS/PLT/Miscellaneous/matthias-kuhf.mp3 Kirby
Got this URL sent to me off-list: http://www.norvig.com/python-lisp.html Seems a useful page (studying it now), worth posting here. Thanks. Wondering if Shriram (TeachScheme Project!) is aware of this page and/or has feedback. Kirby
On Sun, 8 Oct 2000, Jason Cunliffe wrote:
I find myself become more of an instant nutcase than testcase when I look at even this trivial example:
(define (area-of-disk r) (* 3.14 (* r r)))
A voice inside my head starts saying "No. Stop no!"
I wonder to how many people react differently from me, and what the real pre-conditions are whereby one says instead "oh yes of course! :-)"
Do you know about modalities? Kinesthetic/Visual/Auditory and all that? I'd venture that you tend to rely on Auditory-Internal-Digital thinking a lot.. in other words, you think to yourself in words.. (As you demonstrate above.. "voice", "one says", plus you read a lot, etc..) LISPish syntax doesn't really lend itself well to thinking in words. At least not english ones.. Python does. That's why it's "executable psuedocode" :) Now, if you'd grown up speaking lojban ( http://www.lojban.org/ ) you might find programming in scheme much more natural.. LISP/scheme work better thinking visually, at least for me.. But then I'm not a lisp or scheme programmer.. :)
Are there consistent universal patterns of recognition and action which are independent from language culture personality? How does learning play into this.. Where does early computer programming belong?
No clue, but I've got a book on my to-read list that deals with a lot of this.. "The Language Instinct" by Steven Pinker.. Cheers, - Michal ------------------------------------------------------------------------ www.manifestation.com www.sabren.com www.linkwatcher.com www.zike.net ------------------------------------------------------------------------
When learning the German language many years ago, my first language being English, I found it confusing how the verbs tended to end up near the end of sentences -- almost a "postfix" syntax. But it started to seem more natural, or at least comfortable, after a while. Perhaps there are natural languages where the verb tends to come first? Or is the prefix structure really that foreign? (define (square x) (* x x)) Define the "square of x" to be the product of x and x. I've used Lisp and its ilk on and off over many years, and I don't find it that hard to shift gears between "Python mode" and "Lisp mode". It's harder for me to switch amongst Python, Javascript, PHP, Java, etc because I forget details like how to express a false or null value in the particular language. Millions of people use HP calculators with their RPN notation. That doesn't speak directly to prefix notation, but certainly suggests that people can learn another syntax without much problem -- even if there is something about our innate linguistic skills that favors some particular syntax. On Sun, Oct 08, 2000 at 04:15:41PM -0400, Jason Cunliffe wrote:
This last one is very tricky I know because English is my mother tongue so I cannot really know how does programming syntax feel to people around the world from different subject-object-verb systems? I get a glimpse only from use and study of other spoken languages and when speaking with non-English speakers.
-- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
From: Fred Yankowski <fred@ontosys.com>
When learning the German language many years ago, my first language being English, I found it confusing how the verbs tended to end up near the end of sentences -- almost a "postfix" syntax. But it started to seem more natural, or at least comfortable, after a while. Perhaps there are natural languages where the verb tends to come first?
Or is the prefix structure really that foreign?
(define (square x) (* x x))
Define the "square of x" to be the product of x and x.
Yes. Thanks. See when you 'say' it like that I can 'read' it... and it makes perfect sense. Typographically I still choke a little on so many ((())). But hey, compared to a Tibetan Mandala, it is trivial.. This connection between the writing, the reading, and our spoken language is what I want to follow further. It is one of the key differences having a live teacher or not. Books usually don't offer much help in this respect. As I see it there are three language systems at work here:
(define (square x) (* x x))
Define the "square of x" to be the product of x and x.
1 - Scheme 2 - Written mathematics/programming 3 - English word order
Millions of people use HP calculators with their RPN notation. That doesn't speak directly to prefix notation, but certainly suggests that people can learn another syntax without much problem -- even if there is something about our innate linguistic skills that favors some particular syntax.
Let's take cooking as an example.. - gather vegetables - prepare some utensils PUT water in pot heat ADD - wash, chop some vegetables IF water boiling PUT vegetables in steamer basket cover ADD - gather plates WAIT till maximum bright color SERVE immediately = ADD vegetables to plates well. sorry my example is rather clumsy.. Perhasp you can provide a better one. But in many real-life processes RPN is what we do. But not all.. We need vegeratbles in hand before we can cook them. We need to have heat before we can apply it. We need to find the cover before we can put it on the pot. etc. A good distinction of coloquial language is: Is the water boiling ? This can be shortened to <water boiling [now]?> accompanied by various gestures and/or vocal inflections. This is what we must do in a foregin country when we don't speak the language. Speaking with Asians also induces this quickly since there is a much more concise approach to language - anyway compared to English and most European languages, no complicated prepositions. 'a' 'the' etc.. Just go for direct placement of key words. Context will provide the rest.. Young children do the same hmm..I am groping here for something.. some view connecting digital cookery and CP4E [back later] - Jason
Millions of people use HP calculators with their RPN notation. That doesn't speak directly to prefix notation, but certainly suggests that people can learn another syntax without much problem -- even if there is something about our innate linguistic skills that favors some particular syntax.
Right, RPN is another door we should open in K-12. We had a poster awhile back sharing his Python RPN module as I recall. I downloaded it and played with it some. Certainly I was a big fan of HP and using parentheses-free entering the way RPN allows. HP calculators were also what first exposed me to the concept of a stack (RPN goes togther with a stack concept). When minds are young, open, flexible (that's the stereotype anyway -- analogy with bodies) is a good time to keep thowing out alternatives, other ways of thinking. So I'm wholly in favor of early exposure to prefix notation, in a addition to RPN. If a student starts experimenting with an altogether new notation, having learned the less that these are technologies we can just _invent_ (not handed down as eternal practices that weigh us down forever with legacy notions), I'll take that as a very positive sign. Python's ability to override (aka overload) syntactic elements such as + * () [] and give them new meaning provides further encouragement in this direction. As one of the Scheme websites put it, you want your language to be more like the problems you're thinking about, so you do some language customization, vs. always trying to make the problems conform to the strictures of some unalterable given. Kirby
I continue to have the impression (I think it's more than a mere prejudice, as I've been doing some studying) that Scheme is more academic and less interested in venturing into the rough and tumble world of writing to sockets, encryption, XML, unicode, working with various kinds of GUI widget, than is Python.
I find the newest version of DrScheme (from Rice U) goes further into some of these topics. There's a GUI object toolkit (widgets), some XML support, plus a tutorial on how to write CGI programs. Given what appears to be a highly OO flavor to the widgets (similar to Python's), I'm going to have to look again at how to implement objects as instances of classes (organized in a hierarchy) in this flavor of Scheme. Kirby
participants (6)
-
Arthur Siegel -
Fred Yankowski -
Jason Cunliffe -
Kirby Urner -
Michal Wallace -
Steve Litt