[Tfug] Language choices

[Bexley Hall]

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?

> 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*?

> 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.

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  :<

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...)

--don


 
____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups 
(http://groups.yahoo.com)