Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #21494

Re: Which scripting for embedded automation?

From Paul Rubin <no.email@nospam.invalid>
Newsgroups comp.arch.embedded, comp.lang.forth
Subject Re: Which scripting for embedded automation?
Date 2015-07-24 10:15 -0700
Organization A noiseless patient Spider
Message-ID <87lhe5sciz.fsf@jester.gateway.sonic.net> (permalink)
References <0e930740-22d8-4e2b-833f-bb5843437d0d@googlegroups.com> <87y4i6rvyc.fsf@jester.gateway.sonic.net> <motoev$eeu$1@dont-email.me>

Cross-posted to 2 groups.

Show all headers | View raw


rickman <gnuarm@gmail.com> writes:
[Ok, replying to your crosspost even though my own earlier post was only
on comp.arch.embedded where the original question was.  The question
regards scripting home automation stuff on an embedded Linux system].

>> Forth is likely to be too low level for this sort of programming.
>> It's virtue is being able to run in very small memory space, like
>> under 10K of code space and a few hundred ram bytes in an MCU.  
> I find your analysis of Forth to be very naive.  Much the same as
> other languages like C, Forth provides a basic capability with more
> advanced capabilities provided through libraries.  

Sure, I'd consider C to also be low level though.  I'd have to add that
Forth doesn't have nearly as many available libraries, because of the
smaller userbase, but I think partly from a minimalist "do everything
yourself" spirit in Forth culture.  

> Suggesting that Forth is only useful where the entire development
> system needs to reside in 10 KB of code is a red herring. 

I didn't mean to suggest a 10K maximum.  I meant Forth had the
capability of running in such small space and that this is IMHO a big
achievement and advantage that it has, but it dictated a lot of Forth's
design decisions.  Historically Forth was most successful in the era of
16-bit systems with up to 64k ram, or maybe on MSDOS PC's with up to
640k.  Once you have tens of MB available the tradeoffs in scripting
become a lot different.

Other Forth advantages include pauseless operation (necessary for
real-time programs), higher cpu efficiency than Python even in simple
interpreters, and very high efficiency (comparable to C) if you use an
optimizing compiler.  But, in the context of scripting, these are
usually not important.  Python burns more machine resources, but in
return it takes care of a lot of issues for you that you'd have to spend
your own time looking after in Forth or C.

> Otherwise Forth can be used to advantage in the same environments
> where you would use C, Python or any others.  

I didn't say anything about C and I'd consider it comparable to Forth in
most regards.  C would IMHO be a poor choice of scripting language in
this situation too.

Have you actually used Python?  It's not anything like C or Forth.
Lumping Python with C seems to miss the distinction.  If you haven't
actually used both, then making comparisons between them isn't
convincing.

> It typically comes with exactly the sort of capabilities needed for
> this project.  A parser is built in with full capability of being used
> in the application and most Forths running under an OS support
> networking.

If the OP has control over the network protocol then using the Forth
parser can be a simple and efficient solution, especially if the network
devices are all trusted.  If there are devices speaking protocols like
XML (some home automation stuff is like that) then Forth starts to be
painful.  I don't know if a Forth TLS stack even exists.

> Referring to Forth as being "like assembler" just shows how little you
> understand the language and appreciate its features.

I understand Forth pretty well at a technical level, though I'm not a
very fluent user in terms of being used to the idioms it takes to use it
productively.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Which scripting for embedded automation? abhishekkumardwivedi@gmail.com - 2015-07-23 02:24 -0700
  Re: Which scripting for embedded automation? Les Cargill <lcargill99@comcast.com> - 2015-07-23 12:18 -0500
  Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-23 10:42 -0700
  Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-23 15:08 -0400
    Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 18:44 -0400
  Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-23 22:00 -0700
    Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 12:19 -0400
      Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:15 -0700
        Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-07-24 23:06 +0000
          Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-24 17:00 -0700
            Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 20:52 -0400
          Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-11-28 18:06 +0000
        Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-29 02:45 -0500
          Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-11-29 23:02 -0800
            Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-30 02:55 -0500

csiph-web