GeekSpeak Cheat Sheet

[Alex Tweedly]

At 10:43 21/10/2004 -0700, Judy Perry wrote:

>Hi,
>
>I am attempting to put together a GeekSpeak Cheat Sheet on Rev for my lazy
>CS majors (largely so that they'll stop whining about how they can't do
>anything 'real' in Rev).
>
>But, not being a real geek myself, I find myself at an impasse.  I have
>Coulouris & Thimbleby's "HyperProgramming" which has a few pages on Pascal
><-> HyperTalk.
>
>What would you all additionally suggest?  For example, one student asked
>about classes. Besides just telling him that there aren't any, what should
>I suggest as an analogue?  I know I should have a section on typeless
>data, but what else?
>
>Thanks for any suggestions you can offer!

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.

It's that latest in a fairly long line of proposed magic bullets to make 
software development into a science. Those that had little or no value have 
faded from memory - those that had value remain in our toolkits and have 
been built upon by later tools.

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.

(top-down design, functional decomposition, data-driven programming, 
Jackson Structured programming, waterfall design, Extreme programming, Pair 
programming, genetic algorithms --- pick your own set of "fads" for the 
last few, or next few, decades.)

Things you should put on your "cheat sheet" ?

I'd be fairly explicit in dividing this into two lists - things that are 
easy for geeks to appreciate, and things that aren't.

Geek items.

1. Associative arrays.
    a.  just in themselves
    b.  pseudo-multidimensional arrays
    c.  power of split and combine

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

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).

4. Blurred line between routines and event handlers.
    power of send, send in x milliseconds, etc.

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.
[ 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.]

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.


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 ...

-- Alex.