[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
> >>> language.
> >>
> >> 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 :)
>
> <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
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
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
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.

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

>
> >>> I assumed (maybe from talking to you), that you
> >>> were looking at "embedded" programming:
>
> [snip]
>
> >> Yes.  Though the distinction of "embedded" does not
> >> imply missing some "functionality inherent in a
> >> desktop PC"...
>
> [snip]
>
> > 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?

>
> > > 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).
>
> <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
more about what people on this list like to program in than I thought
I would ever know.

> [snip]
>
> >> 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.
>
> Thanks!  *I* clearly didn't realize we were talking
> on different wavelengths   :<
>
> > I will leave the "glue" comment alone, as I am not
> > fully sure I understand what you are asking about
>
> 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?

>
> You may send a query to a DBMS for some data that
> you need to display; you let a widget class implement
> all of the UI devices; you let the browser handle
> the presentation; the HTTP server handles getting
> your page back to the user and input *from* the user;
> etc.

I guess...

>
> When you are crafting a shell script, you may call
> upon tar to examine the contents of a tarball,
> awk to process the file list from that tarball,
> shell builtins to print summaries of the data
> in question, etc.
>

(Again) I guess ...

These examples seem to me to assume linearity in a process that is
more dimensional.

> I.e. the script just patches things together -- like
> calling functions/procedures in a "regular" program
> and arranging for results from one subsystem into
> the next, etc.
>
> (sorry, a bad explanation but perhaps you can see
> what I mean?)
>

Hopefully, but I think that is the less refined point of this whole
discussion.

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 :)
Maybe you should give a *generic example of how you would use this
hypothetical language*?

> > there.  Let me just ask, are you targetting a UNIX
> > platform?
>
> 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).
>

So you are not targetting UNIX.  Maybe that will help some people
understand why you can't just grab Python, and start indenting your
way to nirvana.

No need to justify your obvious hate for all things UNIX related }:)

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

> [have I clarified anything?  Or, just made matters
> worse?? :< ]

Don't know... we will see ;)