Re: SPAM-MED: Re: Time to upgrade my technique...
Well, there is one advantage of using fields and not variables - your users can see those fields chuntering through and incrementing before their very eyes. Never underestimate the value of cognitive dissonance. Its working hard, so it must be worthwhile. The variable is not nearly so satisfying, it just happens. Richmond Mathewson wrote: Is there anything INTRINSICALLY wrong with using fields instead of variables ? -- View this message in context: http://www.nabble.com/SPAM-MED%3A-Re%3A-Time-to-upgrade-my-technique...-tp17760588p17772384.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
I tend toward the paper and pencil analogy for variables, paper and pen for constants. It's like the machine has a note pad, pen and pencil inside. That's something they readily use and are familiar with. Cheers, Luis. On 10 Jun 2008, at 20:15, Richmond Mathewson wrote: Richard Gaskin wrote: I would agree that what you teach should depend on where the learner is on Piaget's scale of cognitive function. But for adult learners, I usually teach fields for display and variables for computation. Variables play a central role in the art of programming. One could argue that it would be a disservice not to explain how to use them well. This isn't a very nice thing to say, but (you know me by now): Experience has taught me that quite a few adults who perceive themselves as would-be programmers don't seem to have got beyond the 'concrete operational stage' (Paiget: http://en.wikipedia.org/wiki/Jean_Piaget ), at least as coping with variables goes. I usually start with the buckets image, move onto fields (visible buckets) and then try variables (invisible buckets). The main problem seems to be that, in RR/Metacard/xTalk as one does not explicitly define variables people often say something like the following: When I put a number in a field that is easy because I have already made the field and I can see it on the VDU, but I don't see how I can put a number in an invisible thing that doesn't exist. Explaining that by naming a variable one calls it into existence (c.f. Hindu creation and Lord Brahma breathing things into existence) doesn't seem to click with many people. Personally I don't find it a problem because I was 14 when I moved from Fortran 4 to BASIC; i.e. while I was still in the 'formal operational stage' and had not yet lapsed/rotted/reverted (choose which ever verb takes your fancy) back to the sort of proto-Neanderthal mentality I now exhibit. Admittedly the LET statement (oddly enough) helped me visualise variable 'containers' popping out of nowhere. I will spend some time this summer with some Bulgarian kids (who have been taught English by me) on a very basic exercise to make a simple calculator in RR; as their age range will be between 8 and 12 it will be very interesting to see who gets it re variables. I am not really doing this to teach then programming as such, but as a way to speed up their cognitive development (something that happens anyway with children who learn a foreign language fairly intensively). sincerely, Richmond Mathewson ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
Ah... The good old days of 70 hour weeks when we were young and stupid and we just got our first IBM S360... Jim On 10-Jun-08, at 2:49 PM, Phil Davis wrote: Wow - another former PL/1 programmer! I thought I was the only one left, except at the Rev conference I learned that Robert Cailliau also used it in earlier days. Phil Davis Jim Carwardine wrote: Thanks, guys... Shame on me for using fields instead of variables. I knew that one. That is an original 1987 HC self-learning (that reflects my PL1 days in the early 70's believe it or not) that I have fought ever since. Now, to rewrite and relearn... Jim On 10-Jun-08, at 12:55 PM, Jim Ault wrote: Here are some skeleton techniques that can be applied to your set of tasks. full listing of original appears below my code Jim Ault Las Vegas - start code - on doJimsTasks --Jim Ault6.10.08forJim Cowardine --partial script to show techniques --will not run, but shows example techniques --this is not the only way to build a fast Rev routine put fld 1 into mainList --use variables in RAM put 0 into i put 1 into j put empty into eventOutputList --final listing put empty into currentEvent -- each line we want to fill --this is added to eventOutputList at the end of the loop --then eventOutputList is put into field 2 at the finish --set up a comma listing of keywords for later put Dartmouth,Burnside,Bedford,Sackville,Kentville, into cityList put Port Hawksbury,Truro,Bridgewater,Tantallon, after cityList put Glen Haven,Hubbards,Bayers Lake,Cole Harbour after cityList --now create a list of only those lines that qualify filter mainList with *BEGIN:VEVENT* --now the only lines remaining are the ones we want put mainList into keepers --this is a better name, but optional -- I use LNN to be the unmodifiable variable to read repeat for each line LNN in keepers add 1 to i if LNN contains SUMMARY then end if if LNN contains LOCATION then end if if LNN contains DSTART then end if if LNN contains END:VEVENT then end if if holdLine is 1 then put eventDate into item 2 of currentEvent put locationName into item 5 of currentEvent set the itemDel to comma if item 5 of currentEvent is among the items of cityList then put item 5 of currentEvent into item 6 of currentEvent end if put currentEvent into line j of eventOuputList end repeat put eventOuputList into field 2 set the itemdelimiter to , sort lines of field 2 by item 7 of each sort lines of field 2 dateTime by item 2 of each end doJimsTasks end code - On 6/10/08 7:53 AM, Jim Carwardine [EMAIL PROTECTED] wrote: Hi Folks... I hope this isn't asking too much. I have found using the docs to be less than satisfying when trying an alternative coding technique. I guess I fall into the old dog, actually the old Hypercard dog, trying to learn the new Rev tricks. I just wrote a quick and dirty script to parse out an iCal calendar saved as a text file to feed my car expense calculator which was published a few months ago in a Rev newsletter. The script is very slow and I was intrigued to know how to speed it up as I am aware that I am using very archaic scripting techniques. Here is my script. It's relatively short and contains almost all of my favourite coding patterns. If anyone has the inclination, perhaps you could point out how I might make use of Revs improvements over Hypercard... It has to do with better ways to handle repeating actions and better ways to handle lists... Thanks in advance... Jim -- all handlers on mouseUp put 0 into eventMark -- didn't end up using this for anything by a switch put 1 into j put empty into eventLine put empty into field 2 repeat with i = 1 to the number of lines of field 1 if line i of field 1 contains BEGIN:VEVENT then -- found an event put 1 into eventMark next repeat end if if eventMark 0 then -- we are parsing an event now breakpoint if line i of field 1 contains SUMMARY: then -- found the event name put 2 into eventMark set the itemdelimiter to : put item 2 of line i of field 1 into eventName -- hold event name next repeat end if if line i of field 1 contains LOCATION: then -- found the event location put 3 into eventMark if line i of field 1 contains \, then replace \, with in line i of field 1 set the itemdelimiter to : put item 2 of line i of field 1 into locationName -- hold event location next repeat end if if line i of field 1 contains DTSTART; then -- found the event location put 4 into eventMark set the itemdelimiter to : put char 1 to 4 of item 2 of line i of field 1 into
Re: SPAM-MED: Re: Time to upgrade my technique...
Le 11 juin 08 à 10:13, Peter Alcibiades a écrit : Well, there is one advantage of using fields and not variables - your users can see those fields chuntering through and incrementing before their very eyes. Never underestimate the value of cognitive dissonance. Its working hard, so it must be worthwhile. The variable is not nearly so satisfying, it just happens. I agree. I see fields as the poor man's debugger: it let you see what happens inside the script. François ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
Richmond, We should all be so fortunate as to have such a rewarding environment. Unlike you, I'm mired in one in which Building Officials, aware that we can now do much more than in the past, are requiring the most inane documentation for things just because they can easily do so - without scratching their chiny-chin-chins! Continue having fun with real work - teaching and learning! Joe Wilkins On Jun 11, 2008, at 7:12 AM, Richmond Mathewson wrote: Oddly enough a slightly confused 15 year old came to see me today, ostensibly about English but really about programming; worried that a friend of his was strutting his funky stuff with some 'orrible command-line language. Showed him how to knock something together that worked in RR; his self-esteem went through the roof as I demythologised programming in 3 easy steps all thanks to Runtime Revolution! If only schools could pull their fingers out of 1975 and start using some sort of Object-based RAD such as RR we would not all go around with humps on our backs about being inferior because we cannot program. sincerely, Richmond Mathewson. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
at least as coping with variables goes. I usually start with the buckets image, move onto fields (visible buckets) and then try variables (invisible buckets). For kids (and anyone else, I'd imagine), I've found that it's best to use real-world metaphors that mean something to them. Perhaps it's a cultural thing, but sometimes I'll use video games as an example, since most of the kids I've encountered have wanted to learn programming because they'd like to create their own video games. I ask them to imagine their favorite first person shooter game, and imagine that as they progress through the game they get to pick up new weapons. As they gather weapons, the game needs to keep track of all the weapons they've gathered. But if it were to display everything they pick up, the screen would be overly cluttered and confusing, so it only displays their active weapon and all the other weapons are hidden from view, but you know they are there because you picked them up in your travels. Also, you can pause the game and go to a screen where you see your weapon inventory. Well, fields are like the weapon that's displayed on screen, variables are the weapons in inventory that you can't see during normal game play, and the debugger lets you see your inventory of variables while you're programming. In addition to this being an a-ha! moment, it also begins to connect them with the programming consciousness around video game development. People are more receptive when (a) they are invested in the conversation in some way, and (b) are spoken to with concepts that are relevant to their current frame of reference. So the first step is trying to find a common frame of reference for the students (whether they be adult or not), and then tailor the conversation from there. Or at least that's what's worked for me... Ken Ray Sons of Thunder Software, Inc. Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
On Thu, Jun 12, 2008 at 1:11 AM, Ken Ray [EMAIL PROTECTED] wrote: People are more receptive when (a) they are invested in the conversation in some way, and (b) are spoken to with concepts that are relevant to their current frame of reference. So the first step is trying to find a common frame of reference for the students (whether they be adult or not), and then tailor the conversation from there. Or at least that's what's worked for me... Couldn't agree more. I find a mobile phone analogy works for kids. Fields are like, accessing the address book, finding the person, opening their entry, then selecting dial. Variables are like speed dial. You know what you put in, and with only two key presses you get the same result as above but much quicker. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
On Wed, Jun 11, 2008 at 10:12 PM, Richmond Mathewson his self-esteem went through the roof as I demythologised programming in 3 easy steps all thanks to Runtime Revolution! If I remember correctly, someone saw red when Runtime offered to Teach Programming in a Day and that Learn The Salient Central Points to Runtime Revolution Programming in 1 Day may have been more accurate. Are you now suggesting: Demythologised Programming in 3 easy steps all thanks to Runtime Revolution! as the banner headline for beginners at the next Rev Conference ;-) (all very much in jest:-) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
Thanks, guys... Shame on me for using fields instead of variables. I knew that one. That is an original 1987 HC self-learning (that reflects my PL1 days in the early 70's believe it or not) that I have fought ever since. Now, to rewrite and relearn... Jim On 10-Jun-08, at 12:55 PM, Jim Ault wrote: Here are some skeleton techniques that can be applied to your set of tasks. full listing of original appears below my code Jim Ault Las Vegas - start code - on doJimsTasks --Jim Ault6.10.08forJim Cowardine --partial script to show techniques --will not run, but shows example techniques --this is not the only way to build a fast Rev routine put fld 1 into mainList --use variables in RAM put 0 into i put 1 into j put empty into eventOutputList --final listing put empty into currentEvent -- each line we want to fill --this is added to eventOutputList at the end of the loop --then eventOutputList is put into field 2 at the finish --set up a comma listing of keywords for later put Dartmouth,Burnside,Bedford,Sackville,Kentville, into cityList put Port Hawksbury,Truro,Bridgewater,Tantallon, after cityList put Glen Haven,Hubbards,Bayers Lake,Cole Harbour after cityList --now create a list of only those lines that qualify filter mainList with *BEGIN:VEVENT* --now the only lines remaining are the ones we want put mainList into keepers --this is a better name, but optional -- I use LNN to be the unmodifiable variable to read repeat for each line LNN in keepers add 1 to i if LNN contains SUMMARY then end if if LNN contains LOCATION then end if if LNN contains DSTART then end if if LNN contains END:VEVENT then end if if holdLine is 1 then put eventDate into item 2 of currentEvent put locationName into item 5 of currentEvent set the itemDel to comma if item 5 of currentEvent is among the items of cityList then put item 5 of currentEvent into item 6 of currentEvent end if put currentEvent into line j of eventOuputList end repeat put eventOuputList into field 2 set the itemdelimiter to , sort lines of field 2 by item 7 of each sort lines of field 2 dateTime by item 2 of each end doJimsTasks end code - On 6/10/08 7:53 AM, Jim Carwardine [EMAIL PROTECTED] wrote: Hi Folks... I hope this isn't asking too much. I have found using the docs to be less than satisfying when trying an alternative coding technique. I guess I fall into the old dog, actually the old Hypercard dog, trying to learn the new Rev tricks. I just wrote a quick and dirty script to parse out an iCal calendar saved as a text file to feed my car expense calculator which was published a few months ago in a Rev newsletter. The script is very slow and I was intrigued to know how to speed it up as I am aware that I am using very archaic scripting techniques. Here is my script. It's relatively short and contains almost all of my favourite coding patterns. If anyone has the inclination, perhaps you could point out how I might make use of Revs improvements over Hypercard... It has to do with better ways to handle repeating actions and better ways to handle lists... Thanks in advance... Jim -- all handlers on mouseUp put 0 into eventMark -- didn't end up using this for anything by a switch put 1 into j put empty into eventLine put empty into field 2 repeat with i = 1 to the number of lines of field 1 if line i of field 1 contains BEGIN:VEVENT then -- found an event put 1 into eventMark next repeat end if if eventMark 0 then -- we are parsing an event now breakpoint if line i of field 1 contains SUMMARY: then -- found the event name put 2 into eventMark set the itemdelimiter to : put item 2 of line i of field 1 into eventName -- hold event name next repeat end if if line i of field 1 contains LOCATION: then -- found the event location put 3 into eventMark if line i of field 1 contains \, then replace \, with in line i of field 1 set the itemdelimiter to : put item 2 of line i of field 1 into locationName -- hold event location next repeat end if if line i of field 1 contains DTSTART; then -- found the event location put 4 into eventMark set the itemdelimiter to : put char 1 to 4 of item 2 of line i of field 1 into eventYear -- hold event year - mmdd put char 5 to 6 of item 2 of line i of field 1 into eventMonth -- hold event month - mmdd put char 7 to 8 of item 2 of line i of field 1 into eventDay -- hold event day - mmdd put char 10 to 13 of item 2 of line i of
Re: SPAM-MED: Re: Time to upgrade my technique...
Richmond Mathewson wrote: Is there anything INTRINSICALLY wrong with using fields instead of variables ? This looks like whether one wants to eat one's dinner the British way (i.e. with an upside-down fork and cut it up as you go along) or the North-American way (cut everything up first and then eat it with the fork). Admittedly using variable results in quicker programs than using fields, but surely this is not a shibboleth? Teaching kids RR it is easier to use fields because the kids can see them (i.e. they resemble the cups with buttons in that I start with); most pre-teens are not terribly hot with abstract ideas. I would agree that what you teach should depend on where the learner is on Piaget's scale of cognitive function. But for adult learners, I usually teach fields for display and variables for computation. Variables play a central role in the art of programming. One could argue that it would be a disservice not to explain how to use them well. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
Hi Richmond, With the speed we have today, I think I can safely say that there is no caveat against using fields; particularly with very simple references to them; but, when you start parsing their contents, then you'll probably want to be doing it using vars. IMHO, Joe Wilkins On Jun 10, 2008, at 10:24 AM, Richmond Mathewson wrote: Is there anything INTRINSICALLY wrong with using fields instead of variables ? This looks like whether one wants to eat one's dinner the British way (i.e. with an upside-down fork and cut it up as you go along) or the North-American way (cut everything up first and then eat it with the fork). Admittedly using variable results in quicker programs than using fields, but surely this is not a shibboleth? Teaching kids RR it is easier to use fields because the kids can see them (i.e. they resemble the cups with buttons in that I start with); most pre-teens are not terribly hot with abstract ideas. sincerely, Richmond Mathewson (who loves using fields as he has an HC self-taught ancestry). ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
Wow - another former PL/1 programmer! I thought I was the only one left, except at the Rev conference I learned that Robert Cailliau also used it in earlier days. Phil Davis Jim Carwardine wrote: Thanks, guys... Shame on me for using fields instead of variables. I knew that one. That is an original 1987 HC self-learning (that reflects my PL1 days in the early 70's believe it or not) that I have fought ever since. Now, to rewrite and relearn... Jim On 10-Jun-08, at 12:55 PM, Jim Ault wrote: Here are some skeleton techniques that can be applied to your set of tasks. full listing of original appears below my code Jim Ault Las Vegas - start code - on doJimsTasks --Jim Ault6.10.08forJim Cowardine --partial script to show techniques --will not run, but shows example techniques --this is not the only way to build a fast Rev routine put fld 1 into mainList --use variables in RAM put 0 into i put 1 into j put empty into eventOutputList --final listing put empty into currentEvent -- each line we want to fill --this is added to eventOutputList at the end of the loop --then eventOutputList is put into field 2 at the finish --set up a comma listing of keywords for later put Dartmouth,Burnside,Bedford,Sackville,Kentville, into cityList put Port Hawksbury,Truro,Bridgewater,Tantallon, after cityList put Glen Haven,Hubbards,Bayers Lake,Cole Harbour after cityList --now create a list of only those lines that qualify filter mainList with *BEGIN:VEVENT* --now the only lines remaining are the ones we want put mainList into keepers --this is a better name, but optional -- I use LNN to be the unmodifiable variable to read repeat for each line LNN in keepers add 1 to i if LNN contains SUMMARY then end if if LNN contains LOCATION then end if if LNN contains DSTART then end if if LNN contains END:VEVENT then end if if holdLine is 1 then put eventDate into item 2 of currentEvent put locationName into item 5 of currentEvent set the itemDel to comma if item 5 of currentEvent is among the items of cityList then put item 5 of currentEvent into item 6 of currentEvent end if put currentEvent into line j of eventOuputList end repeat put eventOuputList into field 2 set the itemdelimiter to , sort lines of field 2 by item 7 of each sort lines of field 2 dateTime by item 2 of each end doJimsTasks end code - On 6/10/08 7:53 AM, Jim Carwardine [EMAIL PROTECTED] wrote: Hi Folks... I hope this isn't asking too much. I have found using the docs to be less than satisfying when trying an alternative coding technique. I guess I fall into the old dog, actually the old Hypercard dog, trying to learn the new Rev tricks. I just wrote a quick and dirty script to parse out an iCal calendar saved as a text file to feed my car expense calculator which was published a few months ago in a Rev newsletter. The script is very slow and I was intrigued to know how to speed it up as I am aware that I am using very archaic scripting techniques. Here is my script. It's relatively short and contains almost all of my favourite coding patterns. If anyone has the inclination, perhaps you could point out how I might make use of Revs improvements over Hypercard... It has to do with better ways to handle repeating actions and better ways to handle lists... Thanks in advance... Jim -- all handlers on mouseUp put 0 into eventMark -- didn't end up using this for anything by a switch put 1 into j put empty into eventLine put empty into field 2 repeat with i = 1 to the number of lines of field 1 if line i of field 1 contains BEGIN:VEVENT then -- found an event put 1 into eventMark next repeat end if if eventMark 0 then -- we are parsing an event now breakpoint if line i of field 1 contains SUMMARY: then -- found the event name put 2 into eventMark set the itemdelimiter to : put item 2 of line i of field 1 into eventName -- hold event name next repeat end if if line i of field 1 contains LOCATION: then -- found the event location put 3 into eventMark if line i of field 1 contains \, then replace \, with in line i of field 1 set the itemdelimiter to : put item 2 of line i of field 1 into locationName -- hold event location next repeat end if if line i of field 1 contains DTSTART; then -- found the event location put 4 into eventMark set the itemdelimiter to : put char 1 to 4 of item 2 of line i of field 1 into eventYear -- hold event year - mmdd put char 5 to 6 of item 2 of line i of field 1 into eventMonth --
Re: SPAM-MED: Re: Time to upgrade my technique...
Richmond Mathewson: Richard Gaskin wrote: I would agree that what you teach should depend on where the learner is on Piaget's scale of cognitive function. But for adult learners, I usually teach fields for display and variables for computation. Variables play a central role in the art of programming. One could argue that it would be a disservice not to explain how to use them well. This isn't a very nice thing to say, but (you know me by now): Experience has taught me that quite a few adults who perceive themselves as would-be programmers don't seem to have got beyond the 'concrete operational stage' (Paiget: http://en.wikipedia.org/wiki/Jean_Piaget ), at least as coping with variables goes. That was perhaps somewhat insensitive of me, but in all fairness Paiget describes his highest stage of cognitive development as something that most adults possess. While that may not be true for everyone, for the relatively narrow subset who are likely to enjoy programming I'd say it's a pretty safe bet. In fact, I would go so far as to suggest that if it isn't true, much of learning the art of programming will be more of a frustration than a joy, not necessarily because of teaching or learning styles, but simply that it is, by nature, a relatively complex task of symbolic reasoning. I usually start with the buckets image, move onto fields (visible buckets) and then try variables (invisible buckets). I like the buckets metaphor too. Back in Pascal class my teacher was having a tough time explaining the difference between pass-by-value and pass-by-reference, so I drew some cartoons for the class using buckets to illustrate the idea. I made some copies and before the next class I passed those around, and I heard a lot of a ha!s -- and the teacher did too. He asked, Who did this? and a couple people pointed at me. I wasn't sure if he was annoyed, but then he said, I like this. Mind if I use it? :) The main problem seems to be that, in RR/Metacard/xTalk as one does not explicitly define variables people often say something like the following: When I put a number in a field that is easy because I have already made the field and I can see it on the VDU, but I don't see how I can put a number in an invisible thing that doesn't exist. Explaining that by naming a variable one calls it into existence (c.f. Hindu creation and Lord Brahma breathing things into existence) doesn't seem to click with many people. Maybe it's the Brahma metaphor that confuses them. :) If it's easier, Rev supports the option of explicitly declaring them. When teaching Rev as a second language I often start with that because it's more familiar. I haven't yet had a learner stumble with automatic declaration. Then again, I have to admit that I haven't taught complete newcomers in many, many years. Most folks I've worked with over the last decade have at least poked around a bit on their own, at least enough to become familiar with the basics of variables. So I can't speak authoritatively about teaching someone with zero experience And most of the folks I work with have aspirations of professional software development, so adopting performance-driving habits early on can be more useful than it would for a hobbyist. If teaching with fields works, by all means keep doing it. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
Richard Gaskin wrote: If teaching with fields works, by all means keep doing it. I think I'd start with teaching fields so they can get the concepts down, but then move pretty quickly to using variables so they learn to program efficiently. There's no good reason to teach poor programming practices. Moving data in and out of fields is one of the slowest, most inefficient things you can do in Rev, so it's good practice to do as little of it as possible. While it is true that today's computers are fast, parsing a large field by repeatedly accessing and replacing its contents will be very slow if there is any substantial text in it. Richard, you wrote a great explanation of this on the list some time ago. I wonder if you still have it. Something about moving things around in the janitor's closet every time you needed to get the cleaning fluid or something. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
J. Landman Gay wrote: Moving data in and out of fields is one of the slowest, most inefficient things you can do in Rev, so it's good practice to do as little of it as possible. While it is true that today's computers are fast, parsing a large field by repeatedly accessing and replacing its contents will be very slow if there is any substantial text in it. Richard, you wrote a great explanation of this on the list some time ago. I wonder if you still have it. Something about moving things around in the janitor's closet every time you needed to get the cleaning fluid or something. Of all the metaphors I've ever written, I felt that was one of the few accurate ones. But you're the only person who remembers it at all. Maybe it's only funny to folks who've played around with the Mac Toolbox in C. Maybe it's only funny to me. For your amusement, from the May 2005 thread, why are custom properties so fast?: - Compared to a field nearly anything else will be faster because of the overhead associated with all the other things fields have to do to display text in addition to storing it. I wrote this a while back in response to a related question: To get data in and out of a field, given the various style run mechanisms and other special considerations, the process is a lot more work under the hood than using a custom property. For the benefit of anyone who's never had to deal with the tedium of low-level languages, you can visualize what's happening by imagining needing to alter the contents of two buckets: 1. PROPERTY: This bucket is on the floor right in front of you. 2. FIELD: This bucket is in a room down the hall and around the corner, turn left, then go through the first door, turn right, go through the double-doors, then take the hall on the left to the staircase, go downstairs, and on your right you'll find a storage bin -- the bucket is in the bin, behind a mop. Before you can pick up the bucket you'll need to move the mop, but the mop is wet so you'll need to put some rags on the floor in front of you to catch the moisture so it doesn't make the floor unsafe. You'll find some rags in the next room through the door on the right, inside a metal box. Be sure to put the lid back on the box after retrieving the rags so you don't let mice nest there. Back in the storage room spread the rags out sufficiently to catch the moisture but not so many that you trip over them, then put the mop on them, and then get the bucket. After changing the bucket's contents you'll want to put it back first, then the mop, then collect all of the rags and put them in the laundry hamper in the room on the left. To make sure the cleaning crew knows to wash the rags you'll need to fill out the laundry request form you'll find on a clipboard hanging on the wall next to the light switch. After it's filled out be sure to turn off the light in the laundry room and the one in the storage room, and then return to where you started. In terms of the number of instructions to access the contents of a property vs. a field, this comparison with buckets is probably missing a few steps in #2. And if there's a scrollbar attached to the field then double the number of steps. :) - -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: SPAM-MED: Re: Time to upgrade my technique...
Richard Gaskin wrote: J. Landman Gay wrote: Richard, you wrote a great explanation of this on the list some time ago. I wonder if you still have it. Something about moving things around in the janitor's closet every time you needed to get the cleaning fluid or something. Of all the metaphors I've ever written, I felt that was one of the few accurate ones. But you're the only person who remembers it at all. Who knows, maybe everyone remembers it and wishes they didn't. :) It makes me feel guilty every time I have to use a field. 1. PROPERTY: This bucket is on the floor right in front of you. 2. FIELD: This bucket is in a room down the hall and around the corner, turn left, then go through the first door, turn right, go through the double-doors, then take the hall on the left to the staircase, go downstairs, and on your right you'll find a storage bin -- the bucket is in the bin, behind a mop... That was it. Even though I have never played around with the Mac toolbox, I still think it's funny. And spooky accurate. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution