One reaction to <url: <url: http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle graphics may be off-putting to some readers because it is associated with children's learning.
Alf P. Steinbach wrote: > One reaction to <url: <url: > http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle > graphics may be off-putting to some readers because it is associated > with children's learning.
> What do you think?
I just started using the module for simple plots. I am not a child. You cannot please everyone.
On Nov 12, 11:31 am, Terry Reedy <tjre...@udel.edu> wrote:
> Alf P. Steinbach wrote: > > One reaction to <url: <url: > >http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle > > graphics may be off-putting to some readers because it is associated > > with children's learning.
> > What do you think?
> I just started using the module for simple plots. > I am not a child. > You cannot please everyone.
I used Turtle back on the Apple in the early 80's... so I personally have very positive feelings towards it ;) To each their own eh?
> One reaction to <url: <url:http://preview.tinyurl.com/ProgrammingBookP3> has > been that turtle graphics may be off-putting to some > readers because it is associated with children's learning.
[I'll be honest and say that I merely glanced at the two pdf files.]
Who is your target audience? The opening Getting Started paragraph would probably put off many beginners right from the get go! You're talking about a 'first language' but throwing 'syntax', 'windows', 'graphics', 'networking', 'file and database access' and 'standard libraries' at them.
The success of 'XXXX for Dummies' is certainly not their accuracy, but rather that they make far fewer assumptions that people already know the subject being tought! That assumption seems almost ingrained in every 'beginner' programming book I've ever seen!
> What do you think?
Whilst everyone knows children tend to think visually more than abstractly, the same is precisely true of adults. However, the ultimate problem with Turtle is that it ends up teaching a 'mathematical' perspective and it's far from intuitive how you map that perspective to tackling more real world issues. It's simply substituting one difficult abstraction with another.
My recollection is that many children struggled with Turtle graphics because they had very little concept of trigonometry. [Why would they? Many wouldn't learn for another 2-10 years.] Adults tend to have even less concept since they almost never use trig (or much else from school ;-) in the real world.
They can see the patterns and understand there's a logic to it, but they struggle replicating it. Get an angle wrong and you end up with a mess where it's not clear whether it's your algorithm or the maths that's at fault.
The visual aspect might pique interest, but may put just as many people off. In any case, it won't relieve the difficulty of having to teach what is fundamentally an abstraction that doesn't have very good parallels with how people approach problems in the real world. Humans simply don't think like mathematicians^W computers. :-)
I've met a lot of mathematics and comp sci teachers who honestly believe that you can't teach these subjects without a mathematical perspective. That stands in contrast to the number of people I see using spreadsheets with a very high proficiency who would never dream of saying they were good at mathematics or programming.
> On Nov 12, 11:31 am, Terry Reedy <tjre...@udel.edu> wrote: >> Alf P. Steinbach wrote: >>> One reaction to <url: <url: >>> http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle >>> graphics may be off-putting to some readers because it is associated >>> with children's learning.
Take a look at Abelson and diSessa's _Turtle Geometry: The Computer as a Medium for Exploring Mathematics_ (MIT Press, 1986). This is most definitely not a kids' book. Chapter titles include `Topology of Turtle Paths', `Piecewise Flat Surfaces', and `Curved Space and General Relativity'.
As well as being a very nice 2D graphics API, turtles let you explore very deep math. Of course, they also let you explore cybernetics and feedback; see some of the old MIT AI Lab reports on LOGO for that (you can find them at MIT's CSAIL lab website). For a lot of that, you actually need a robot turtle, like perhaps a LEGO Mindstorms robot. Seymour Papert (who did a lot of the MIT LOGO work) was, before his terrible motor accident, in research chair endowed by...LEGO. Hmmm... :)
Of course, some people don't like Python itself because they are afraid of snakes.
> I used Turtle back on the Apple in the early 80's... so I personally > have very positive feelings towards it ;) To each their own eh?
I did my master's thesis on LOGO about 10 years before that, and I have VERY warm and fuzzy feelings about turtles :)
On Nov 11, 10:21 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> One reaction to <url: <url:http://preview.tinyurl.com/ProgrammingBookP3> has > been that turtle graphics may be off-putting to some readers because it is > associated with children's learning.
> What do you think?
How about calling it Raptor Graphics that will please everyone ;-)
> My recollection is that many children struggled with Turtle > graphics because they had very little concept of trigonometry. > [Why would they? Many wouldn't learn for another 2-10 years.] > Adults tend to have even less concept since they almost never > use trig (or much else from school ;-) in the real world.
This paragraph is based upon a complete misunderstanding of turtle geometry. You do NOT use trigonometry to teach it, because the goal isn't to replicate cartesian geometry. The whole point about turtle geometry is that the student viscerally imagines him/herself BEING the turtle, and moving around the room according to the succession of FORWARD and TURNRIGHT commands. This is easier to visualize when one has an actual robot that draws pictures on butcher paper, as the second iteration of the MIT/BBN turtle work did (and they worked in middle schools, Grades 4-8, so there was no issue of trigonometry).
> They can see the patterns and understand there's a logic to > it, but they struggle replicating it. Get an angle wrong > and you end up with a mess where it's not clear whether it's > your algorithm or the maths that's at fault.
Kindly explain to me the difference between `algorithm' and `maths' here. I believe you just said that if there's a bug in the design, the program won't work. Hmmm.
This reminds me of a well-known anecdote about the original LOGO study done at Muzzey High in Lexington, MA, in 1968. A group of NSF funding people was doing a tour of the school, and they came across a Grade 5 student who was doing a family tree program. The NSF people were impressed by the complexity of the program. One of them said in a patronizing tone, `I guess this stuff really helps you learn math'. She got quite angry, and responded, `This stuff has NOTHING to do with math!'
> The visual aspect might pique interest, but may put just as > many people off. In any case, it won't relieve the difficulty > of having to teach what is fundamentally an abstraction that > doesn't have very good parallels with how people approach > problems in the real world. Humans simply don't think like > mathematicians^W computers. :-)
Having taught grade 8 math, I can tell you that cartesian geometry is much LESS intuitive to people that are learning it than the relative polar coordinates of turtle geometry are. (`Oh, you want to get to the mall food court? Turn left, and walk past about 10 stores. The food court is right after the Gap.')
> I've met a lot of mathematics and comp sci teachers who > honestly believe that you can't teach these subjects without > a mathematical perspective. That stands in contrast to the > number of people I see using spreadsheets with a very high > proficiency who would never dream of saying they were good > at mathematics or programming.
It is true that you can't teach computer science to children without having a strong understanding of the mathematical foundations. It is also true that when you teach it to children that you very carefully hide the mathematical formalism.
I might point out that the people who had most to do with the invention of turtle geometry were Wally Feurzeig (who was my boss when I worked at BBN in the 1970s) and Seymour Papert. Papert had spent a lot of time working with Jean Piaget in Switzerland. If you read the original LOGO memos, you will see his clear explanations on how this material ought to be taught to people with no math background, including children who are too young to do symbolic thinking (that kicks in in the early teens). That's why the visceral `I am a turtle' approach works well with middle-school kids.
> On Nov 11, 10:21 pm, "Alf P. Steinbach" <al...@start.no> wrote: >> One reaction to <url: <url:http://preview.tinyurl.com/ProgrammingBookP3> has >> been that turtle graphics may be off-putting to some readers because it is >> associated with children's learning.
>> What do you think?
> How about calling it Raptor Graphics that will please everyone ;-)
He he. :-)
import turtle as raptor raptor.shape( "triangle" )
> "Alf P. Steinbach" <al...@start.no> wrote: >> One reaction to <url: <url:http://preview.tinyurl.com/ProgrammingBookP3> has >> been that turtle graphics may be off-putting to some >> readers because it is associated with children's learning.
> [I'll be honest and say that I merely glanced at the two > pdf files.]
> Who is your target audience?
Someone intelligent who doesn't know anything or very much about programming and wants to learn general programming.
> The opening Getting Started > paragraph would probably put off many beginners right from > the get go! You're talking about a 'first language' but > throwing 'syntax', 'windows', 'graphics', 'networking', > 'file and database access' and 'standard libraries' at them.
> The success of 'XXXX for Dummies' is certainly not their > accuracy, but rather that they make far fewer assumptions > that people already know the subject being tought! That > assumption seems almost ingrained in every 'beginner' > programming book I've ever seen!
Yes, I totally agree with not assuming knowledge. However, (without implying that you think so) lack of knowledge is not lack of brains. I assume an intelligent reader, someone who doesn't balk at a few technical terms here and there.
Pedagogically it's a challenge, because a correspondence between knowledge and brains is so often assumed, and the field of knowledge accordingly (but mostly by historical accident) divided up into "basic", "medium level" and "advanced".
And so an explanation of something that's trivial to someone who already knows, something in the "basic" category, might seem (to someone who confuses knowledge with brains) to assume a dumb or childish reader. But in reality the intellectual challenge of something in the traditional "basic" category can be greater than for something conventionally regarded as "advanced". So I strive to not make any distinction between traditional levels of knowledge in the field, but rather to focus on what's relevant and on how hard something would be to grasp for someone without the base knowledge and experience.
> Whilst everyone knows children tend to think visually more > than abstractly, the same is precisely true of adults. > However, the ultimate problem with Turtle is that it ends > up teaching a 'mathematical' perspective and it's far from > intuitive how you map that perspective to tackling more > real world issues. It's simply substituting one difficult > abstraction with another.
> My recollection is that many children struggled with Turtle > graphics because they had very little concept of trigonometry. > [Why would they? Many wouldn't learn for another 2-10 years.] > Adults tend to have even less concept since they almost never > use trig (or much else from school ;-) in the real world.
> They can see the patterns and understand there's a logic to > it, but they struggle replicating it. Get an angle wrong > and you end up with a mess where it's not clear whether it's > your algorithm or the maths that's at fault.
> The visual aspect might pique interest, but may put just as > many people off. In any case, it won't relieve the difficulty > of having to teach what is fundamentally an abstraction that > doesn't have very good parallels with how people approach > problems in the real world. Humans simply don't think like > mathematicians^W computers. :-)
> I've met a lot of mathematics and comp sci teachers who > honestly believe that you can't teach these subjects without > a mathematical perspective. That stands in contrast to the > number of people I see using spreadsheets with a very high > proficiency who would never dream of saying they were good > at mathematics or programming.
Uhm, yes, I agree. I've tried to limit the math to what most anyone can handle. No geometry so far! Although it will have to be discussed for graphics. But although most ch 2 examples are graphical, graphics generation as such is not discussed. It's like the difference between driving a car and designing one. You don't need an engineering degree to drive a car. :-)
In <hdj4aj$7k...@news.eternal-september.org>, Alf P. Steinbach wrote:
> But in reality the intellectual challenge of something in the > traditional "basic" category can be greater than for something > conventionally regarded as "advanced".
And consequently is much harder to teach. I have nothing but admiration for primary school children and their teachers, because children can *actually learn to read*. Once you can read, future learning objectives become much easier to achieve. Same with programming - once you've grokked the core ideas, the rest is more or less window dressing in comparison.
The gap between nought and one is much greater than the gap between one and a thousand.
<snip>
> It's like > the difference between driving a car and designing one. You don't > need an engineering degree to drive a car. :-)
Right. Nowadays, you need a degree in electronics instead.
-- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
> "Alf P. Steinbach" <al...@start.no> wrote: >> One reaction to <url: <url:http://preview.tinyurl.com/ProgrammingBookP3> >> has >> been that turtle graphics may be off-putting to some >> readers because it is associated with children's learning.
> [I'll be honest and say that I merely glanced at the two > pdf files.]
> Who is your target audience? The opening Getting Started > paragraph would probably put off many beginners right from > the get go! You're talking about a 'first language' but > throwing 'syntax', 'windows', 'graphics', 'networking', > 'file and database access' and 'standard libraries' at them.
> The success of 'XXXX for Dummies' is certainly not their > accuracy, but rather that they make far fewer assumptions > that people already know the subject being tought! That > assumption seems almost ingrained in every 'beginner' > programming book I've ever seen!
yep, but I guess it depends some on the type of beginner...
many beginner books take the style of lots of examples and verbosity, and trying to gradually ease the person into the topic, ...
also common is more of a "crash course" style, where topics are introduced and defined, and where the contents tend to be far more categorical (in these books, often the later chapters and/or appendices are long, and often consist largely of definitions and reference material).
there are merits to both styles I think...
I have also seen where they try to fictionalize the topic, or turn it into some huge mass of allegories, but I don't really like this style so much...
it is possible the 'turtle' may hold these sorts of associations...
> Whilst everyone knows children tend to think visually more > than abstractly, the same is precisely true of adults. > However, the ultimate problem with Turtle is that it ends > up teaching a 'mathematical' perspective and it's far from > intuitive how you map that perspective to tackling more > real world issues. It's simply substituting one difficult > abstraction with another.
> My recollection is that many children struggled with Turtle > graphics because they had very little concept of trigonometry. > [Why would they? Many wouldn't learn for another 2-10 years.] > Adults tend to have even less concept since they almost never > use trig (or much else from school ;-) in the real world.
yep, much the same as trying to teach trig in a pseudo-fantasy setting by addressing the relative dimensions of the various parts of Excalibur...
one gets much more amusement out of just watching a sword fight where all they do is whack the swords into each other and pause momentarily, with whoever was doing the mixing unable to get the delay between the swords hitting and the 'clang' much less than about 300ms...
> They can see the patterns and understand there's a logic to > it, but they struggle replicating it. Get an angle wrong > and you end up with a mess where it's not clear whether it's > your algorithm or the maths that's at fault.
yep...
simple, unstructured, thinking is easier. if one screws up somewhere, it is a lot easier to find and correct the problem.
this is probably part of why procedural and OO have traditionally been more popular than functional programming: one does not have to try to bend their mind so much to get things written or figure out just what the hell is going on...
granted, some level of mind-bending in necessary for programming, but IMO it is more of a necessary evil...
> The visual aspect might pique interest, but may put just as > many people off. In any case, it won't relieve the difficulty > of having to teach what is fundamentally an abstraction that > doesn't have very good parallels with how people approach > problems in the real world. Humans simply don't think like > mathematicians^W computers. :-)
> I've met a lot of mathematics and comp sci teachers who > honestly believe that you can't teach these subjects without > a mathematical perspective. That stands in contrast to the > number of people I see using spreadsheets with a very high > proficiency who would never dream of saying they were good > at mathematics or programming.
apparently, I don't even approach math in a mathematical manner...
I had thought I had understood math, and I use it enough, but I am suspecting that the thing I am familiar with is a good deal different than that seen by mathematicians (partly as a result of some interactions with, and observation of, physics teachers...).
or, it could be that my world is severely 'bent' because of my exposure to computers, and almost complete lack of need or desire to write proofs or to expand-out and perform huge amounts of symbolic manipulations by hand...
so, I guess my difficulty curve is rather "unusual" as well...
I live in a world where vectors and matrices are fairly simple, and quaternions would be, apart from my near inability to intuitively understand or visualize their behaviors...
and, in this same world, set theory and predicate logic are evil beasts best avoided at all cost...
and, it seems, traditional math screws me over even with seemingly trivial problems...
and, it does not take long to figure out that, for example, even a trivial operation such as renormalizing a vector becomes a marathon of pain...
and leave it as that, this way we factor out everything leaving mostly abstract operations... (once we know the operation, we no longer need to care what it is or how it works...).
but, other people want to expand everything out and turn it into a big evil-looking mess, bleh...
Alf P. Steinbach wrote: > One reaction to <url: <url: > http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle > graphics may be off-putting to some readers because it is associated > with children's learning.
Incidentally ... something you may wish to consider for inclusion in you book ... games programming and Pygame.
See, e.g.,
Andy Harris, Game Programming (L Line: The Express Line to Learning), John Wiley & Sons, 2007, ISBN-10: 0470068221 or
Will McGugan, Beginning Game Development with Python and Pygame : From Novice to Professional, APRESS, 2007, ISBN-10: 1590598725.
I have the impression that there are many young people who could learn programming via games programming. On the other hand, in languages like C++ or Java, the threshold to games programming is extremely high.
Not so using Pygame.
The additional nice thing about Pygame is that it is based on a Python binding of SDL (Simple DirectMedia Layer) an open-source games API. This could mean easy migration to C++ games programming (using SDL).
> > Who is your target audience? > From: "Alf P. Steinbach" <al...@start.no> > Someone intelligent who doesn't know anything or very much about > programming and wants to learn general programming.
I think of what a computer *does* as data processing, and then programing is simply telling the computer what data processing to do. In calculator mode, you just tell the computer one step at a time and immediately see the result before giving the next command. In program mode, you tell the computer the whole sequences of steps before the computer does even the first, which requires planning the whole sequence in your mind ahead of time. Lisp's REP allows you to use calculator mode when doing a dry run, then just wrap PROG around it and viola you have a program of all the steps together, thus bridging the gap between calculator and program mode painlessly.
The two "hard" things about programming are syntax and planning. REP gets rid of the need to plan in your mind before writing the code, but you're still stuck with the syntax. My proposed no-syntax IDE *also* gets rid of the need to bother with any programming-language syntax. I've been proposing it for years, but nobody has shown any interest, so I'm spending my time on other things, but sometime in the next several months I am very likely to go ahead and implement no-syntax IDE as part of http://TinyURL.Com/NewEco.
> I assume an intelligent reader, someone who doesn't balk at a few > technical terms here and there.
There's a **major** difference between the ability to figure out complex puzzles and the ability to memorize jargon. Case in point: I placed top-five in Putnam math context despite disability whereby it was very difficult for me to memorize vocabulary/jargon. Then I flunked out of graduate school because suddenly I was expected to (but unable to) memorize ten definitions/lemmas to solve each homework problem.
Ideally, with either somebody like me with memorization disability, or a very young child who just naturally by age has trouble learning more than one concept or term simultaneously, you should introduce only one concept or term at a time, and exerecise the person's mind with that concept or term for a while before moving to the next.
> It's like the difference between driving a car and designing one. > You don't need an engineering degree to drive a car. :-)
Sure some humans can be trained like pigeons to do the motions of driving a car through a fixed course without having the slightest concept of what's really happening. But to be able to respond appropriately to new situations, it really helps to understand that the brake pedal does *not* stop the car, it merely pulls a lever that presses a plate against a wheel causing excess friction causing the wheel to gradualy slow down, which is connected to the tires causing *them* to resist motion of car against road, which on non-slippery surfaces and with *gentle* braking results in the car slowing down, but with **sudden** pressure on brake, or on slick surfaces, the wheels stop turning completely and simply slide against the roadway, causing loss of control of both yaw and momentum, so suddenly your whole car is spinning about a vertical axis as well as no longer going around the road-curve but instead veering in a straight line across opposing traffic lanes or over the edge of the "S curve" of the Bay Bridge and then 200 feet down to a rather violent meeting with Yerba Buena Island.
I hate that "CHECK ENGINE" light, because there's usually no way the driver of the vehicle actually *can* check the engine in any meaningful way to determine why the light is on. I think it really means "check" in the sense of a cloak-room, where you "check" your raincoat and umbrella by handing them to a clerk, thus you really do "check" your automobile by handing it over to a mechanic.
<silly>By the way, I don't want Python running on my Macintosh, because it might eat my mouse.</silly>
> My proposed no-syntax > IDE *also* gets rid of the need to bother with any programming-language > syntax. I've been proposing it for years, but nobody has shown any > interest
I'm interested. No-syntax IDE? How is this even possible?
The only way I can think of is some sort of wizard interface. E.g. instead of having to remember the syntax for a slice, you click the "Slice" button and the computer prompts you to enter some combination of start, end, step, then generates the syntax [a:b:c] for you.
> > My proposed no-syntax > > IDE *also* gets rid of the need to bother with any programming-language > > syntax. I've been proposing it for years, but nobody has shown any > > interest > From: Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> > I'm interested. No-syntax IDE? How is this even possible?
I guess you missed what I previously posted. The basic idea is that you start with test data, and you use menus to select appropriate data-processing actions to perform on that data. For example, you manually key in a file name containing test data, or copy and paste that same file name. Then you select "open file by that name" or "load all lines from file by that name" etc. from a menu. If you just opened the file, you now have a stream of input, and you can select to read one line or one s-expression or one character etc. from that file. After loading the whole file or one unit of data, you now have some *real* data to work from. For example, with a line of input, you might break it into words.
Caveat: When I said "no syntax", I mean no programming syntax, no syntax to indicate function calls or variable assignment etc. You still must deal with visual representation of strings and integers and other essential data objects, which in a way may be considered to be syntax. But if you want, you can avoid *all* syntax, even for data, by drawing a *picture* of the individual bits. For some low-level machine-language training, or boolean algebra lessons, this might actually be preferable to Arabic numerals and English letters to represent data values. Seeing a *picture* of something that looks like a paper tape seems more binary-friendly than seeing arabic digits "0" and "1" in rows across a page, when studying operations upon boolean values or bitmasks.
Now if you don't like the burden of navigating the multi-level menus, a search engine can be available, whereby you key in keywords for the name of some data-processing operation you either saw before or a name you can construct in your mind based on naming conventions.
The extreme case of search engine would be if English-language pseudo-code can be automatically converted into a very short menu of most likely data-processing operations. I actually am seriously considering doing NewEco software development by this means. Basically I contract people to brainstorm with me in a Delphi fashion to create the toplevel design of a new computer algorithm, then we do top-down break into pieces, and continue top-down break-down as far as it takes until the search engine recognizes some step as something it already knows how to do.
> The only way I can think of is some sort of wizard interface. > E.g. instead of having to remember the syntax for a slice, you > click the "Slice" button and the computer prompts you to enter > some combination of start, end, step, then generates the syntax > [a:b:c] for you.
Yeah, it'll be vaguely like that in some ways. For major data, we'll have the data first, all parameters to the next function to apply, and *then* we select what function to call on those parameters. But for minor parameters, we might allow you to choose the function before filling in the minor-parameter slots. For example, to select the nth character of string, we might have both the string and the integer N before we select the NTH function, but if N is a constant we might instead have just the string and select the NTH function and fill in the constant N. With the pseudo-code translation, some of the constant parameters might be apparent in the English. For example, we have a string, and we say "select the second word" (actually that's almost HyperTalk, the scripting language of HyperCard on Macintosh computers), at which point the constant parameter 2 would be supplied from the word "second" in the English.
Robert Maas, http://tinyurl.com/uh3t wrote: >>> My proposed no-syntax >>> IDE *also* gets rid of the need to bother with any programming-language >>> syntax. I've been proposing it for years, but nobody has shown any >>> interest
What you describe below is similar to various systems that have been proposed and even implemented, including visual programming systems. And there has been some success with non-programmers. But for most people, it is simply easier to say/write what one means rather than point and click. Point-and-click writing reminds me of point-and-click speaking. Great for those who need it but a hindrance to those who do not.
This is not to say that traditional editors cannot be improved with better backup memory aids. Indeed, even IDLE recognizes function names and pops up a bar listing parameters.
Feel free to develop a Visual Python environment. I might even give it a try.
>> From: Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> >> I'm interested. No-syntax IDE? How is this even possible?
> I guess you missed what I previously posted.
I did too and had the same question.
> The basic idea is that > you start with test data, and you use menus to select appropriate > data-processing actions to perform on that data. For example, you > manually key in a file name containing test data, or copy and paste > that same file name. Then you select "open file by that name" or > "load all lines from file by that name" etc. from a menu. If you > just opened the file, you now have a stream of input, and you can > select to read one line or one s-expression or one character etc. > from that file. After loading the whole file or one unit of data, > you now have some *real* data to work from. For example, with a > line of input, you might break it into words.
Processing a single data file is a common programming task, but not the only general category. A specialized Visual Data Analysis with Python might be a better and more focused project.
When I was doing statistical data analysis on a daily basis for a living, I would have loved to have had a system that would read in the first line and let me define (and name) the fields by point and click. (I usually worked with fixed-width, column-delimited fields.) Instead, I had to write a format statement and some summary analysis code, run it, look at it for sanity, and decide if my format had been correct.
