GeekSpeak Cheat Sheet
Frank D. Engel, Jr.
fde101 at fjrhome.net
Mon Oct 25 14:28:27 EDT 2004
> On Mon, 25 Oct 2004, Alex Tweedly wrote:
>> 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
>> then admit there are a whole set of choices possible. Get them to
>> http://www.paulgraham.com/hundred.html - even if they do all go off
>> become LISP programmers, at least you've saved them from C++ :-)
Them and everyone else -- them from the hassles of that (ick) language,
and us from the bugs and bloat typically introduced by programs written
in that language.
> --Thanks; I'll include it as reading material for them. BTW, I highly
> doubt they'll all go off and become LISP programmers ;-)
As do I.
>> 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 ??)
>> Trad languages also require that they keys (or indexes) of the array
>> integers, usually consecutive and sometimes even beginning at 1 (or
>> 0) -
>> see example above.
Not all "Traditional" languages! In Pascal and Ada, you can use any
ordinal type. For a Pascal example:
VAR ch : CHAR;
FOR ch := 'A' to 'Z' DO
WRITE(ch, ' ');
>> 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
>> 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
>> thereby both eliminating a good source of bugs, and making the code
>> and more obvious.
> --Okay, thanks; I'd forgotten about what little I knew about this.
Yeah, this is a VERY nice feature.
>> 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,
>> 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.
> --None of them are scripting language people AFAIK. A few maybe have
>> OK - I'm probably too old (51) for them to relate to what I've done -
>> since I finished my CS degree 30 years ago, I've used somewhere
>> around 25
>> different computer languages professionally.
> --Yes, I think it is the, ahem, mature perspective that makes one
> appreciate the opportunity of choice. When they are obtaining the
> it is strongly implied that all you really need to know in order to
> get a
> job is Fortran/Basic/Pascal/C/Java/WhateverIsFlavorOfMonth. It never
> occurs to most that you won't be doing 10 years from now exactly what
> are doing today.
>> The chances of getting through the next 5-10 years - never mind a
>> 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
>> programmer", and "just write programs" in one language for year after
>> But they should be aiming to be more than that - and to provide
>> with range of options.
> --ESPECIALLY given the state of employment for CS majors here in the
> States currently.
>> In a similar vein (but also something they may not want to hear),
>> likely to spend more of their time debugging, maintaining and making
>> 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
>> makes simplicity of expression important.
> --Reality_Bites 101
Unless they program in Ada, which substantially reduces debug time by
catching a huge percentage of what would be runtime errors in other
languages at compile time. Fussy syntax = fewer headaches during
>> And, btw, I agree 100% with Andre's suggestion - show them a list of
>> that have been built with Rev (or xTalk's in general). It's hard to
>> that Python is a "toy" language since Google; it's hard to argue that
>> is a toy (or an academic irrelevance) since Viaweb. I don't know of
>> single, definitive example for Rev - but there ought to be enough good
>> examples to convince them that real things can be built.
> --Yes, you are both right; these are valuable examples (although I once
> had a couple of students note they'd never consider buying a Renault
> they found out that the company used Hypercard for I forget what it was
> they used it for). The Novell example recently mentioned might be
> especially potent...
Much like I'd be very hesitant to buy a server tied to running
Microsoft products (or any other computer for that matter)?
Different tools are well suited to different tasks. Each has strong
points and weak points. It is a good idea to be familiar with a range
of tools in order to be prepared to perform different tasks. Much as
one would never write an embedded operating system in Transcript,
writing a large GUI application in something like LISP would be highly
undesirable as well. I wouldn't use a screwdriver to cut wood, or a
saw to drive a nail.
> Thanks again!
> use-revolution mailing list
> use-revolution at lists.runrev.com
Frank D. Engel, Jr. <fde101 at fjrhome.net>
$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten
Son, that whosoever believeth in him should not perish, but have
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com
More information about the Use-livecode