[OT] If programming languages were religions...

Randall Reetz randall at randallreetz.com
Mon Dec 22 20:00:10 EST 2008


Wow, i just think xtalk is a point of pride.  This thead started with "what should we  call it?" and morphed to an apologetic on how we should explain why we use it?  And i argue that both ?s are solved when you honor its lineage. 

-----Original Message-----
From: "Brian Yennie" <briany at qldlearning.com>
To: "How to use Revolution" <use-revolution at lists.runrev.com>
Sent: 12/22/2008 3:10 PM
Subject: Re: [OT] If programming languages were religions...

> This is not true.  You can call Revolution by its name all day  
> long... in reference to the product.  But if you are setting up a  
> comparison between major categories of languages, Rev's scripting  
> language certainly doesn't rank its own spot along side the likes of  
> C, Lisp, and SmallTalk.

Well sure, IF we are talking about some sort of high level, arbitrary  
taxonomy then you are right. But I still don't know who besides you is  
trying to create one. I guess everyone who works in C++ should be very  
careful to put it under "C" and not mention it on its own. What's the  
point? OK, Revolution didn't invent xTalk syntax. We get it. Very few  
languages have their own unique syntax.

> If I go to amazon to purchase a programming system, I will ask for a  
> product by name.  If I am comparing language families it would be  
> ridiculous to list Rev next to C.  If I was to mention Rev, I would  
> have to then refer to CodeWarrior and such instead of C.
>
> xTalk is to C as Revolution is to CodeWarrior.

No, it's not. CodeWarrior is just a C IDE + compiler in this context.  
Revolution is NOT just an IDE for an already existing language. It's  
not a HyperTalk compiler.

> My original post was not in direct relation to this silly religion  
> thread.  The religion thread is a sub-thread to a larger discussion  
> about what to call the scripting language within the Revolution  
> product.
> In this larger discussion, I saw a disturbing lack of historical and  
> genealogical reference to the origin of the language upon which Rev  
> is based.  Again, there is much about Rev that is unique within the  
> xTalk development tool category... the scripting language itself is  
> not significantly unique to this same degree.  In point of fact, it  
> is upon the strength of this borrowed (event driven, message  
> passing, object centered, english syntax) language that Rev is based.

OK, that's fine in theory, even though the list of major improvements  
to the language is enormous. Yes, one could argue that the true power  
lives in the english-like syntax and message passing model. Perhaps  
it's just your choice of words which are condescending. You call the  
thread silly, say people are drinking "Kool-Aid", that things  
"disturb" you and that people are lacking respect for the origins of  
the language. C'mon. You obviously have no clue what group of people  
you are addressing, and call people names when they respectfully  
disagree with you.

> That is how I describe Rev when I am asked.  There are better and  
> worse IDEs in every language category.  For many reasons, Rev is one  
> of the best in the xTalk category.  But what really makes Rev great  
> is the same thing that makes SuperCard great... the friendly  
> underlying xTalk language and simple object hierarchy within which  
> it is situated.

Not how I would put it, but surely a fair point of view.

> In my opinion, the best way to brag up the Rev product is to call  
> out its strengths.  Naming Rev's scripting language anything that  
> does not directly reference this key attribute (xTalk) would ignore  
> the goodwill inherent in the structure and heritage that was  
> intentionally designed into the original SmallTalk and HyperTalk  
> languages and the philosophy that drove those original design  
> decisions.
>
> As good as the Rev IDE is, if you wrapped it around C instead of  
> xTalk, you would be left with C... most of us would abandon the  


[truncated by sender]



More information about the use-livecode mailing list