From: Sean Middleditch <elanthis@...>
Date: 2001-08-25T12:43:30+09:00
Subject: [ruby-talk:20349] Re: Backwards language

On 25 Aug 2001 12:12:50 +0900, Todd Gillespie wrote:
> Sean Middleditch <elanthis@users.sourceforge.net> wrote:
> :> runtime.  In reference to the joke they called it Parrot, but the project
> :> is very real.
> 
> : Ah.  Well, again, that runtime I'm sure is still a lot larger and such
> : than I'm looking for.   ^,^
> 
> Yes.  But still quite exciting to see happen.  It will be quite a
> formidable standard.
> 

Yes, it will.  It will certainly make a lot of things easier.
Especially if, for example, Perl modules would then be available in
Python (I most definitely prefer Python over Perl), or even Ruby, for
that matter.

> :> I really can't follow your flow of argument through that paragraph.
> :> Tcl was designed for use by non-programmers scripting together larger
> :> elements.  It sounds exactly like what you are looking for.  What bothers
> :> you about it?  Prefix notation?
> 
> : Stick a programming novice in front of it with nothing but a couple of
> : README's and such that would likely come with a commercially produced
> : app embedding the language.
> 
> I just couldn't parse that.  Could you try again?
> 

Take someone who's very new to programming.  When game module
programming, most people learn over whatever sparse documents the game
vendor suppliers, be it on thier distribution media or website.  Chances
are, they will be utterly confused, as I doubt the vendor would supply
documentation fully covering the TCL language.

Granted, C-like languages seem to be very popular, but they are very
common.  Many people who are learning programming learn C or C++, or at
least Java.  I've yet to meet in person anyone who's ever done any real
programming TCL.  even if a languages syntax is superior, or even easier
than a popular language like C, it will fall aside in regards to
familiarity.  I for one would rather program in Ruby like syntax than
C++ for scripting, while another person on my project does indeed prefer
TCL (asked for it, at least, when we were deciding on languages), while
my friend wanted something closer to BASIC, which he was taught in high
school.  I have, in my project (AweMUD) created a generic scripting
language wrapper and a plugin system to allow different languages, but I
need to wrap multiple backends to support all those languages.  Some of
them require quite a bit of work to get embedded (I don't know of any
decently embeddable BASIC interpreters, for example).  Having a unified
backend plugged into my application, with a couple of different
compilers that can be easily generated with lex/yacc is a lot easier on
my part.

> :> I dislike Tcl for a few reasons, but it is very simple for beginners, and
> 
> : Beginners to TCL or beginners to programming?  ~,^
> 
> Beginners to programming.  Again, that was only its design goal -- I make
> no argument in any direction as to its effectiveness.
> 

Well, I definitely will be taking a look at it again.  Sometime this
weekend, hopefully...

> :> as I said, it is the easiest to embed languages out there.  The
> :> documentation for embedding Tcl in any conceivable environment is
> :> extensive to say the least.  The runtime is extremely simple, the
> :> message-passing is transparent, memory usage is small.
> 
> : Hmm, I've never looked into the internals of TCL, the syntax has always
> : been to my severe disliking.  I'll have to take a look at it, perhaps I
> : can learn a thing or twenty.  ^,^
> 
> I hate the lack of uniformity in Tcl, where sometimes you will pass a
> function the contents of a variable and sometimes the name of a
> variable.  It is also rooted in the concept of 'everything is a string',
> which works for 90% of integration tasks, but might be totally
> inappropriate for game scripting.  But I can prove a point here, it might
> be that while competing language designers bickered about language
> features Tcl developers were writing documents with titles like "How to
> compile the Tcl interpreter into your C program".  And that really made
> the difference.

Ew, see now, right there that would annoy the heck out of me.  Having
inconsistancy in the API.  Even some of Ruby weirder looking API calls
(rb_strnew2 for example) bother me to no end.  I tend to develope C
API's to look a lot like GTK+/GLib's - object oriented, function calls
are prepended by object's name, first argument is always an instance of
object, it's really easy to figure out a function name if you know what
functionality you want, or vice versa.

> 
>