GeekSpeak Cheat Sheet

[Alex Tweedly]

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.