GeekSpeak Cheat Sheet
alex at tweedly.net
Mon Oct 25 08:50:17 CDT 2004
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
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
> > 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...
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; // 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
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
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
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]
> > 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.
More information about the use-livecode