Hi Judy, Your points are all well taken and true - for kids. But if you read Alejandro's original post, you will see that he is designing a course outline for his fellow teachers who already program in more traditional language(s), which one or ones I don't know, and he is wanting to "convert" them over to rev. This is the issue I was addressing and why I talked about the importance of addressing the paradigm shift first.
Aloha from Hawaii, Jim Bufalini > > On Thu, 19 Nov 2009, Jim Bufalini wrote: > > It seems to me that your are trying to lead horses to water, who are > neither > > thirsty nor want to drink. ;-) > > But the staggering amount of public funds that have been dumped into > computers in the classroom requires that they really ought to either > get > thirsty really quickly or be force-fed the water. > > Here's a sad, sobering read: > > http://www.hull.ac.uk/php/edskas/Cuban%20article%20-%20oversold.pdf > > Yes, it was written some time ago, but I've not really seen any studies > that indicate that things have changed for the better. In my > children's 4 > years in the public school system, there were a number of computers > present in each classroom. Mostly they never got used. Or, if they > did > get used, it was for something completely stupid, like reading a story > online. My niece and nephew, in the third grade, were required to use > PowerPoint to present their vocabulary and spelling words. Yet another > stupid use of computers in education. I've seen school district > technology implementation plans for using computers to teach math -- > how? > Have the students type up word problems and type up the answers. DUMB > DUMB DUMB! > > Or, in the case of I believe it may have been LA Unified, they > forced the kids to use math education software that was SO BAD that > hundreds of math educators and mathematicians signed an online petition > saying that it was the worst educational software they'd ever seen. > So, > why was the school using it? It had been somebody's pet project and > the > district was threatened with the loss of NSF funds if they didn't use > the > software, which the NSF had underwritten. > > My children's first grade teacher, when I asked her about the computers > (she's the one who had them reading stories online), and I made a joke > about PowerPoint, her response was "gee, I wish I knew how to do that > in > class!" I wanted to weep. PowerPoint. For 6 year olds. When there > was > so much more that was possible to do with computers in education MORE > THAN > TWENTY YEARS AGO. > > > But you raise an interesting point. We talk about the world embracing > > revTalk and revlets because the language is so easy. And, indeed it > is. But, > > when I think back to when I first found rev, the major paradigm shift > was > > not the language, but the concept of stacks and cards and how this > equated > > to a windowed GUI. And, had I not had 15 years of extensive > programming > > experience in another rev, called Revelation, which is PICK on the PC > and > > which is very, very similar to rev in that it is a scripting language > with > > chunks, no variable typing, compiling is at the individual script > level, so > > you run and program at the same time, and many, many other > similarities, I > > would have also probably had to go through a paradigm shift with the > concept > > of chunks and where to put or organize scripts. > > --And, of course, this is exactly why it is perhaps a better audience > for > using this particular program, because cards and stacks of cards are > things they already understand from the real world whereas typed data > and > where to put your semi-colons and how to indent your curlicue brackets > are > not. They have no pre-existing models by which to be confounded. > > > The leap is in the structure and not the language. So while I think > your > > "course outline" rightfully starts out with stacks and cards, I > think, more > > than how to create, the focus in the beginning needs to be on the > "theory" > > of stacks and cards and how these equate to the structures they are > already > > familiar with. > > --That would be none. And none is a good thing ;-) > > > Next, needs to be the theory of chunks and variables and then > followed by > > theory of scripting and where to place blocks of code and what makes > this > > all work or ties it all together, which is the message path. Also, > before > > you get into objects you need o cover the theory behind commands and > > functions and how, in general, scripts are organized. > > --At this point, they've either run screaming to the hills to fire up > PowerPoint or their eyes are glazed over or they're asleep. > Guaranteed. > They need short, sweet project-based learning that allows them to > immediately begin using whatever little they've learned to date. > > > I think without making this paradigm shift first, a programmer used > to top > > down or OOP programming will just feel like a stranger in a strange > land and > > will not "hear" your lessons on buttons and fields because he will be > > sitting there still trying to get his bearings. So, I think you need > focus > > on the lay of the land first. Once a programmer has this down pat, > the rest > > is easy and almost doesn't have to be taught because there is so much > > documentation that can easily be looked up for syntax and details. > > --Here's the problem: Teachers do not want to be turned into > programmers. > Who cares if they do in 15 lines what you'd do in 3? Admire your > elegantly-crafted 3 lines, certainly. Laugh at my 20, certainly (well, > okay, laugh discretely). But, at the end of the day, I'm pleased that > I > *can* make little things that help my children. They don't care how > many > lines it took ;-) And there's no reason why kids in the classroom > should > care either, as long as it works and meets some need. > > Judy > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
