[Tfug] Language choices

[Bexley Hall]

Hi, Stephen,

--- Stephen Hooper <stephen.hooper at gmail.com> wrote:

["embedding" language]

> > <grin>  Point made.  But, *my* point was "what
> > have I said/asked that would have led people to
> > think that?
> 
> How about:
> 
> ===
> I am thinking I am going to have to implement an
> interpreter.  The

(But I am not confining myself to an interpreted
solution...)

> reason I have to do this is because I am trying to
> program for machine
> where non-technical users are going to be asked to
> help me fix/program

More like "extend/customize"...

> the computer (not because I am insane), and because
> I am writing for
> architectures which have no good substitute language
> interpreters that
> would be suitable for the tasks I need to perform.
> 
> I have narrowed my choices down to two languages I
> like X, and Y.   I

(Hmmm... I didn't think I said that.  Rather, that
I was *interested* in those two languages and
was looking for feedback from people with firsthand
knowledge of their *real* assets/liabilities

> realize that both X, and Y are not normal choices,
> but languages like
> A, B, or C won't work because they would require too
> much development,
> too much memory, or would not meet the above
> requirement of readability.

OK.  I had assumed stating the requirements would
lead folks to come to that conclusion.  But, I
can see that these are subjective criteria so
can't fault others for not having the same
"cutoffs" as I do  :<

> Has anyone used X, or Y before?  If you have, please
> let me know your
> experiences with it... taking into consideration
> that I will probably
> end up having to implement it differently than it is
> implemented in
> most other places, so I am especially interested in
> any syntactical problems you had with it.
> 
> ===
> 
> Hindsight is twenty/twenty though.  And, of course,
> C works for everything :)

Yeah, but C doesn't work for everyONE!  :<

>>> 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.
>>
>> No, I have a "real" Operating System.  I suspect
>> much more capable than most desktop operating
>> systems 
>> :>
> 
> Those are some big huevos... did you get those from
> an ostrich?

<grin>  No, that wasnt intended as arrogant.
"Real" in the sense that many embedded systems
have no defined OS, per se.  Many are very small
and "single purpose" so the overhead of an OS
is often just wasted.  Or, they are "toy" OS's
that leave a good deal of responsibility up to
the programmer.  This lets them be very lightweight.
(e.g., I have a multitasking executive that does
a context switch in 8us on a Z80 -- but it does
very little *else* for you!  :>  )

"More capable" in the sense that it has the sorts of
features that are needed in a real-time environment
*and* the features that I need for the protection
and communication models that I want (e.g., I can
add N processors without changing my code -- *or*
recompiling the "kernel", etc.).  These aren't
the sorts of features you tend to find in a
desktop OS (you can't stuff N processors in a
"PC"; you don't have real-time guarantees on
services in a desktop environment, etc)

> > <frown>  Have I not been explicit enough in my
> > question, then?
> 
> Hindsight is twenty/twenty... maybe you were, maybe
> you weren't.  I can say I haven't learned much about
> REXX I didn't already know, but

Sadly, nor I!  So, I guess my original question is
largely unanswered...

> more about what people on this list like to program
> in than I thought I would ever know.

<grin>

> > E.g., when you are scripting something like a
> > web page, you don't usually *do* much in that
> > script.  Instead, you rely on other mechanisms
> > to do the real work and you just tie things
> > together.
> 
> I guess this is where it gets confusing... what do
> you mean "scripting" a web page?

If you aren't just writing static HTML but, instead,
have a cgi "program" (avoiding the term "script")
running behind the page.  E.g., any page written
in Java, perl, etc.

It's hard to think of those things as "programs"
(though some can get large and complex... but
they still tend to have a lighterweight *feel*
about them -- when contrasted with something like
the implementation of the Java VM itself, etc.)

Just like hacking together a shell script has a
different "feel"/weight than writing a piece of
code in C, etc.

> I would go on to say that your examples are a 
> little strange, and, if I were a lawyer, I would
> object based on facts not being evidence :)

(sigh)  Sorry, the examples that come to my mind
are in such odd application domains that I figured
they would be too cumbersome to explain.  So, it
was "a stretch" for me to come up with something
that would be more universally understandable
(given my *assumptions* of most folks' backgrounds).

I've since hacked together a set of "real" examples
re: a tablet press (another message) that may put
some clothes on the mannequin...

>> I'm developing under NetBSD and Solaris; running
>> under Jaluna and Inferno (currently) but,
>> ultimately, this runs on an RTOS of my own
creation. 
>> It's the only way to get the features and
>> performance that I want/need.  Though one of it's
>> personalities is UN*X-ish enough to support things
>> like PostgreSQL (which is what I use for my RDBMS).
>
> No need to justify your obvious hate for all things
> UNIX related }:)

<frown>  I have no such bias.  It just doesn't fit
with the applications that I develop (though I
use it heavily on my desktop).  I suspect there
are very few UN*X gurus (for whatever flavor!)
that are intimate enough with their actual
implementations to be able to *know* what's going
on under the hood for each system trap, etc.
And, in my case, I can't just add memory or
increase the clock to fix any "bad guesses".

> I am surprised you were able to get enough calls
> working to get UNIX software to compile on it.
> Even IBM has problems doing that on their
> mainframes UNIX personality (whatever it's called,
> and not Linux) :)

It is VERY painful.  So much so that I will only
upgrade those ports just prior to release -- there
is a lot of manual work that needs to be done to 
do the port.  My OS is not self-hosting so I have
to cross-develop everything.  Things like
./configure don't work out-of-the-box for my
environment so I have to wade through all of the
configuration stuff by hand.  :<  Another reason
that I am not eager to "just try it" when it comes
to <some_language>!

<shrug>  Thankfully, it's not a high frequency task!

--don


 
__________________________________________________________________________________________
Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. 
(http://advision.webevents.yahoo.com/mailbeta)