GeekSpeak Cheat Sheet

[Frank D. Engel, Jr.]

This is all well and good, but you might do even better to convince 
your students through a demonstration:

Come up with some "pseudo-substantial" project which would take 
considerable time to build in any of the other tools, and show how 
quickly it can be built in Rev during one of your early classes.

This would also serve as a good overview of the course content; only 
give rough explanations of the features at this point, but use it as a 
kind of "outline" of the course.  Impress them by doing it, rather than 
by going into a deep explanation.

Also realize that there is some truth to the thought that Rev would not 
be particularly useful for some types of programs: for intensive 
calculations, Rev is *extremely* slow (this is yet another reason for 
externals)...   but for building graphical front-ends for those 
intensive calculations, for example (perhaps to an external or a 
command-line tool produced in some other language like C or Ada) it is 
quite excellent.  Note that Transcript process text "in bulk" at very 
good speeds, but its calculation performance (even with all of the 
appropriate speed boosts) is quite slow.  Show them why Rev is 
extremely good for many types of programming tasks, but at the same 
time, don't present it as something it is not.  Different tools and 
languages are useful for different types of things.  I have some 
background in C (which I hate), and in Pascal, Ada, Java, and BASIC, 
and have used FORTRAN and C++ as well (I have a Master's degree in 
Computer Science), but when called on to develop the project I am doing 
right now, I realized that I could never have developed it with any 
amount of quality within a reasonable time span using any of those 
languages.  Rev is a very fast tool to develop in, and one of the most 
important tools for most developers to have in their tool chain, 
depending on the type of software being developed.

And no, I never had a class which even mentioned Rev in college...   
Too bad, they don't know what they're missing.  I'll have to write to 
one of the teachers sometime and tell them.

On Oct 25, 2004, at 9:50 AM, Alex Tweedly wrote:

> At 19:26 24/10/2004 -0700, Judy Perry wrote:
>> >
>> > "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?
>
> It's difficult. You have to make them think (or at least tell you :-) 
> *why* they want to use classes. What advantages are they looking for ? 
>  What's the benefit, or purpose, of classes in their context?
>
> If you can even get them to address the question (doubtful), you've 
> taught them something !
>
> I'd try telling them that classes are an abstraction to allow 
> encapsulation of an item  or entity (carefully avoids saying "object") 
> - an item which can be subjected to various manipulations and 
> transactions, and by defining those, the programmer can ensure the she 
> has covered the set of all things that need to be applicable to that 
> entity. It allow you to consider the set of operations you need, in a 
> localized context, rather than having the entire program as a context.
>
> From a 30,000 foot perspective - programming is a tension between 
> top-down and bottom-up design; the academic world has long preferred 
> and taught top-down design; objects are the politically correct, or 
> politically acceptable, version of bottom-up design.
> ( tongue half in cheek )
>
>
>> --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>
>
> On the basis of getting a camels' nose into the tent - ask them why 
> C++ not Java or C#
> If that gets them to admit there is a choice to be made - maybe 
> they'll then admit there are a whole set of choices possible.  Get 
> them to read http://www.paulgraham.com/hundred.html - even if they do 
> all go off and become LISP programmers, at least you've saved them 
> from C++ :-)
>
>> 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...
>
> Arrays in different languages vary in two major ways - what the 
> content of the array can be, and what the indexes or keys of the array 
> can be.
>
> Trad languages would require you to specify the single type of content 
> that an array would hold (and maybe even a fixed size for the array) : 
> e.g.
>    float array x[10];     // array of floats, with 10 (or 11 ??) 
> members
>
> Trad languages also require that they keys (or indexes) of the array 
> be integers, usually consecutive and sometimes even beginning at 1 (or 
> 0) - see example above.
>
> Transcript removes all these restrictions - no need to pre-specify the 
> size of the array, the content is typeless, and most importantly the 
> keys can be anything.
>
> This allows you to "directly" access information about a named 
> collection of data; you don't need an explicit "lookup" step, you 
> don't need to convert a name to an integral index and keep the two of 
> them synchronized, thereby both eliminating a good source of bugs, and 
> making the code simpler and more obvious.
>
> Associative arrays (by various names) also exist in other modern 
> languages (Lisp, Smalltalk, Perl, Python, Lua, etc.)  Java and 
> Javascript also have them if they need "major" language examples.
>
> BTW - in a different context, such as comparing Transcript with other 
> recent scripting languages, I'd keep quiet about arrays. The arrays in 
> Python, Lua, etc. are significantly more powerful than Transcript, 
> because of their ability to place arrays, lists, sets, objects, etc. 
> into the contents of an array element. But in a discussion comparing 
> Transcript to C, C++, etc. they're a strong point.
>
> Specifically regarding combine / split --- of course you can do the 
> equivalent in 2 or 3 lines and a couple of function calls in other 
> languages - but that takes brain cycles to understand, and is clumsy 
> enough to use in the first place that you often wouldn't do it; split 
> (or combine) is a single "thought" in Transcript - so you use it, and 
> when you read the code later, you understand just what it is doing, 
> without needing to figure it out each time.
>
>> > 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.
>
> That's why I threw in the stuff below about productivity. Simplicity 
> isn't only about beauty, it's about productivity, and productivity is 
> about being finished sooner and getting down the pub for a pint :-)  [ 
> translate into local student terms as needed ]
>
>> > [ 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.
>
> Another good reason to read Paul Graham's Hundred Year Language paper.
>
> OK - I'm probably too old (51) for them to relate to what I've done - 
> but since I finished my CS degree 30 years ago, I've used somewhere 
> around 25 different computer languages professionally.
>
> The chances of getting through the next 5-10 years - never mind a 
> whole career - using only the language(s) they already know, is pretty 
> small *if* they're going to be proper geeks. It's perfectly possible 
> to be "just a programmer", and "just write programs" in one language 
> for year after year. But they should be aiming to be more than that - 
> and to provide themselves with range of options.
>
> In a similar vein (but also something they may not want to hear), 
> they're likely to spend more of their time debugging, maintaining and 
> making minor enhancements to code than they spend doing initial 
> development. And it's as likely to be someone else's code they 
> maintain as their own. That's what makes simplicity of expression 
> important.
>
> And, btw, I agree 100% with Andre's suggestion - show them a list of 
> apps that have been built with Rev (or xTalk's in general). It's hard 
> to argue that Python is a "toy" language since Google; it's hard to 
> argue that Lisp is a toy (or an academic irrelevance) since Viaweb. I 
> don't know of any single, definitive example for Rev - but there ought 
> to be enough good examples to convince them that real things can be 
> built.
>
> -- Alex.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
-----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$



___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com