Hi Elizabeth,

Indeed, I do subscribe to SwiftForth already. And I appreciate your =
points about small consumer-grade embedded processors. I wholeheartedly =
agree that those would be perfect platforms for Forth. We tend to deal =
with heftier embedded products, typically offering one or two PowerPC =
cores in addition to specialized ASIC and FPGA's. Those are the systems =
where minimum memory sizes are measured in megabytes.

Sorry for touching on some sensitive nerves in that post. There was a =
time in my life, when for many years all I did was live, eat, and =
breathe Forth. And it served me very well, as it did the engineers =
building equipment in IBM, freeing them of the tyranny of IT Programming =
Staff.

But there are certain problem domains where Forth is most applicable, =
and others where it is not. The height of compiler technology has been =
achieved in languages like OCaml and Haskell. For moderately complex =
languages you could certainly slog your way through and come up with a =
passable system all written in Forth, but the time it would take would =
be orders of magnitude longer, except in very narrow niches -- such as =
when writing an Assembler for a foreign machine where you want to =
Meta-Compile Forth for it. I have never seen shorter Assemblers than =
those developed in Forth.

Forth graduated partway toward Lisp in the HP-28 / HP-48 series of =
calculators where they invented RPL (Reverse Polish Lisp). It is Forth =
in almost every respect except that you don't have to manage any memory, =
and you can deal with arbitrary data items on the stack, such as =
numbers, strings, lists, arrays, graphic objects, etc.

So please don't take my comments as disparaging of Forth. I long =
sentimentally for the perfect application for it again in my own work.

- DM

On Jan 30, 2010, at 19:06 PM, Elizabeth D Rather wrote:

> David McClain wrote:
>> ...
>> But back to small, and fast. By choosing to do this work in Forth, =
you =20
>> are trading off speed of development for speed of implementation. =
Size =20
>> apart. Today, all machines that I work with, even embedded =
processors, =20
>> have many GB of storage space, so size should no longer be a =20
>> determining factor the way it was when all we had were KIM-1's, =20
>> AIM-65's, PDP-11/35's and Nova 800's (typically memory sizes between =
1 =20
>> KB and 32 KW).
>>=20
> Indeed, there are many microcontrollers that support lots of memory. =20=

> But there are also low-end MCUs with extremely limited memory: =
sometimes=20
> small amounts of ROM but large RAMs, sometimes limitations on code =
space=20
> rather than data space, etc. Applications for devices which will be=20=

> sold in very large volumes care very, very much about reducing unit=20
> costs, and using devices with small memories can save a lot.
>=20
> I do not necessarily agree, either, that Forth *necessitates* "trading=20=

> off speed of development for speed of implementation." I have seen =
too=20
> many instances of big wins in both, although I understand such=20
> situations are possible.
>=20
>> There is no question that you can develop a small and highly tuned =
app =20
>> in Forth to do what you want. But what you are finding is that for =
the =20
>> barest support of language design tasks, e.g., symbols -- there are =
no =20
>> such things inherent to the language Forth. So you have to roll your =20=

>> own. Lists do not exist as a native data type, so you have to roll =20=

>> your own, and so on.
>>=20
> I'm not familiar enough with Lisp to know exactly what you mean by=20
> "symbols" (which I assume is some specific technical concept), but I=20=

> have certainly worked a lot with lists of various kinds in Forth. My=20=

> major point here is that generating application-specific objects is so=20=

> easy in Forth that most of the people I work with find "rolling their=20=

> own" data structures to be a matter of minutes, not hours, and the=20
> result is exactly what they need, and not some generic approximation.
>=20
> You indicate that your experience with Forth is from some years ago. =
I=20
> urge you to try some contemporary Forths. Forth has advanced quite a=20=

> lot in recent years. You'll find that most widely-used commercial and=20=

> free systems include some form of OOP support, for example, even =
though=20
> this hasn't been standardized.
>=20
> ...
>>=20
>> I still keep a keen eye open for the right place to use Forth in our =20=

>> embedded systems. But with all the memory available, and the =20
>> increasing sophistication of embedded algorithms -- e.g., dynamic =20
>> adaptive channel equalization in 10 Gbps radio links, it becomes ever =
=20
>> more important to have higher levels of abstract reasoning. And all =20=

>> those low level details in Forth derail such efforts. But I'm sure =20=

>> Chuck would be the first to disagree with me, as usual... Heh!
>>=20
> In the meantime, I encourage you to pick up a free evaluation version=20=

> (full capabilities, just no facility to make a turnkey for =
distribution)=20
> from FORTH, Inc. and/or MPE and familiarize yourself with the current=20=

> state of Forth technology. Be sure to look through the manuals to see=20=

> all the new stuff you may not be expecting!
>=20
> Cheers,
> Elizabeth
>=20
> --=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310.999.6784
> 5959 West Century Blvd. Suite 700 =20
> Los Angeles, CA 90045
> http://www.forth.com
>=20
> "Forth-based products and Services for real-time
> applications since 1973."
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=20
>=20
> ----------------------------------------------------------------------
> sftalk_at_forth.com The SwiftForth programming discussion email list
> To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
> For list command help, send subject "help" to sftalk-request_at_forth.com
> Message archives are located at http://www.forth.com/archive/sftalk
> ----------------------------------------------------------------------
> This list is a forum for SwiftForth users. For product support and
> bug reports, please send email to support_at_forth.com
> ----------------------------------------------------------------------
>=20
>=20

Dr. David McClain
dbm_at_refined-audiometrics.com

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and
bug reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Sat Jan 30 2010 - 20:47:09 PST