GeekSpeak Cheat Sheet
jperryl at ecs.fullerton.edu
Sun Oct 24 22:26:42 EDT 2004
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
> 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
> 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
> 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
> Learning curve for those already experienced programmers
> 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
> [ 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
> 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!
More information about the Use-livecode