GeekSpeak Cheat Sheet

[Judy Perry]

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