Ummm, you mean that overwhelming, "Yes, Virginia, there IS a Santa Claus"-type of voluminous replies? Surely you jest ;-)
On Sun, 24 Oct 2004, Alex Tweedly wrote: > I haven't seen other replies, so I'll take a shot at this .... > > "classes" - unimportant. They're only significant as a representative of > the general topic of Object Oriented design and OO programming. OO is > sometimes treated as though it were the magic bullet that will save us all, > but it's not. It's just another tool in our repertoire. --Okay, but what do I tell them then? How do I translate whatever it is that they wish to do with classes into doing the same/comparable thing in Transcript? <snip> > The important thing to understand about OO is which problems it solves, how > it attempts to solve them, and how OO programming languages help by making > those solutions more natural and easy to write (and the problem easy to > avoid). A CS student who understands that (and understand the same issues > for other "magic bullets" in CS history) will be much further along the > road to being an Uber-geek than one who learns yet another OO language. And > they'll be better positioned to choose the right tool in the right > circumstances - and when (not if) they choose a non-OO language to > implement something, they'll know how to avoid or solve the problems using > their own intelligence - not the crutch of a language that gives some help. --Unfortunately, this business of 'choosing their own tool' -- intelligently or not -- isn't even remotely on their collective radar. C++ and M$-stuff -- that's all they really need to know, right?? </rant> Anyways, I have found a little article (part 1 only, though??) that Dan Shafer did on comparing OOP to using Rev on RevJournal or RevNet.. uploaded that little dude to the class environment; can't make 'em read it, though... <snip> > Geek items. > > 1. Associative arrays. > a. just in themselves > b. pseudo-multidimensional arrays > c. power of split and combine --Umm, ipsem lorem blahdy-blahdy-blah... ama me fideliter, fidem meam nota... > 2. Text processing > (parallel with Perl's origins) > power of chunk expression, etc. > use of string expressions where other languages use other techniques > chunks instead of lists, tuples and sets --Yup, gotcha on that one. > 3. (G)UI is natural to Rev, not a bolt-on as it is to most languages. > You just say "Rev" - unlike Python w/ wxPython and Pythoncard, or Perl w/ > GTK+, or Java w/ Swing (or whatever the latest ones are). --And, unfortunately, they don't give a rat's posterior about that, but that's a rant for a different day... > 4. Blurred line between routines and event handlers. > power of send, send in x milliseconds, etc. --Ummmmm, okay, I'll have to send a bunch of 1-4 out to a geek translation service ;-) I vaguelly get the text/data processing capabilities; will be clueless on how arrays differ in Rev vs. how they are implemented in other languages... > non-geek items (or anti-geek items) > 1. "english" like language > against: > Learning curve for those already experienced programmers > Verbosity > for: > Simplicity of expression of concepts. --Yeah, I've got stuff on this; the minors (non-geeks) love it; the geeks either (a) roll their eyes; or (b) get this glazed-over/nearly comatose expression. > [ There's an argument that productivity in a programing language can be > measured in how many "items" of programming you can write/debug in a day; > "items" isn't "lines of code", and it isn't "number of characters" - it's > more like how many decision points are needed - and hence is somewhat > related to number of lines / characters. Transcript takes advantage of our > years of experience of parsing and reading and writing English (or other > natural human language - they're more alike than they are dis-alike) to > reduce the number of such "decision points" needed. > "the second word of line N" > might mean the same as > line[N][2] > but I think you use less brain power reading it.] --I seriously wish that they cared about these things, but they don't. For them, productivity = using a language they already know. > 2. The live environment. > It's not "run-time", it's not an IDE - it's the THE environment. > Powerful, subtle and may take a while before you learn to take advantage of it. --Preaching to the choir ;-) > > Sorry Judy - there's more I want to write, but I'm running out of time > today. I'll send off what I've written so far, and try to get back to this > during the week ... --That's okay, Alex. Thank you so much for taking the time to respond at all! I would greatly appreciate anything else you could offer! Judy _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
