[Tfug] Language choices

[Stephen Hooper]

On 10/29/06, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi, Stephen,
>
> --- Stephen Hooper <stephen.hooper at gmail.com> wrote:
>
> > > > did you need something that is already ready for
> > > > embedding?  if so, into what other language?  c?
> > > > itself?
> > >
> > > I'm not sure I understand the question.  I want to
> > > be able to write applications (applets?) in this
> > > language that I can bind to threads in my system
> > > and cause to execute.  The application need not
> > > be aware of the environment that invokes it.
> >
> > I think that there is some confusion... I think most
> > people think you are looking for an embeddable
>
> Why is that?
>

Because all the suggestions of Python, and Ruby, and the wikipedia
article, and because of that last statement that you said you didn't
understand :)

> > language.  For example, Jython:  Python running
> > inside a Java program to allow dynamic reworking of
> > that program.  Good uses (for example), are keeping
> > scripts inside a relational database to work on the
> > records so that you can create dynamic rules, and
> > leave it up to the database itself to describe the
> > rules that your program follows to manipulate the
> > records.
>
> By that, I assume you mean those "rules" are just
> records in the database that are queried *by*
> the Java program and applied thereby?  I.e. they
> are NOT "stored (server side) procedures" that
> the DBMS uses *itself*?

Yes.  The scripts are stored in a database record, and the controller
program runs them to provide part of the "view".

>
> > I assumed (maybe from talking to you), that you were
> > looking at "embedded" programming: the programming
> > of machines that do not have the full range of
> > functionality inherent in a PC... (machines that may
> > not have  an MMU, Math Co-processor, Operating
> > System, etc.) and were looking for an interpreter
> > suited for that environment.  In other words "bare"
> > metal programming, in this case targetting the ARM
> > processor.
>
> Yes.  Though the distinction of "embedded" does not
> imply missing some "functionality inherent in a
> desktop PC" -- there are embedded systems that *use*
> PC's "as is" and, thus, have all the PC's
> functionality
> *plus* more (how many PC's can turn a laser on/off
> or cut patterns in a sheet of plywood?).  OTOH, *most*
> embedded systems fit your description well -- the
> mouse in your hand, the processor *inside* your
> CD-ROM drive, the gas pump at your local filling
> station, the cash register at the grocery store
> checkout, the cell phone in your pocket, etc.
>

I didn't mean to imply that all embedded programming would necessarily
lack all of those features, just some of the features.  For example, I
assumed you were dealing without an Operating System.

> My early comment on what I was seeking:
>
>   I'm looking for ideas for a lightweight scripting
>   language to build into a couple of things.  But,
>   I am unsure of the exact criteria I want to
>   impose on my selection  :<
>

Yes.  But on the other hand, the suggestions that people are giving
you as scripting languages, and the choices those are implying are in
no way "lightweight".  Python, Ruby, Perl, etc. all require garbage
collectors, and have very little hope of ever running without an
underlying Operating System (simply because they would require such a
massive development effort).

> Which, I think, is consistent with my other comments.
> I.e. "lightweight" (implying small footprint AND
> reduced complexity/capability) "scripting" (implying
> use merely to tie together larger, existing constructs
> in meaningful ways) "to build into" (a potential
> source of confusion since I consider "things" to
> be "appliances", not "desktop computers").
>
> E.g., you wouldn't use /bin/sh to compute pi!
> You'd, instead, use a more full-featured language
> to do so (e.g., C -- or, cheat and use octave :> )
> And, as a sysadm, you wouldn't write a program in C
> to print a simple message to the console ("Cleaning
> /tmp").  Instead, you'd write a sh one-liner to do
> it for you.
>
> This is the sort of distinction I have been trying to
> highlight in the two classes of applications I need
> to address -- those that really do something
> essential and are built upon by other applications
> (e.g., DBMS server, MP3 player, etc.) in ways where
> performance and resource consumption are important
> considerations (a *slow* MP3 player is not an MP3
> player!  :> ) vs. those that simply glue together
> bigger constructs at a presentation level (like
> building web pages... note that the *browser* is
> not written in Java/perl/etc.!)
>
> Does that make things any clearer (sorry if I've
> *not* been clear enough, previously...)

I wasn't implying that you weren't clear enough before, I just saw
that some confusion may have arisen.  That is not uncommon when
communicating, and figured everyone would benefit more if I explained
to you what I though Takahashi meant.

I will leave the "glue" comment alone, as I am not fully sure I
understand what you are asking about there.  Let me just ask, are you
targetting a UNIX platform?