[Tfug] Language choices

[Bexley Hall]

Hi, Stephen,

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

> Why don't you look at Forth?
> 
> It is a dead language, but it is supposedly fairly
> easy to create an "interpreter" for, is quite
> powerful (ala OpenPROM), and requires
> little punctuation.

Yes, but it is a "klunky" language.  And, there are
very few "checks" that the "compiler" can apply to
help the user write good (bug free) code.

The *big* advantage it has is that it is quite
small!

> The IPC thing would be a little more complicated,
> because it doesn't really work that way... still
> maybe it would be useful for you...

I suspect I could build some "custom words" that
provided this mechanism.  It's nice if the language
itself supports it, though (i.e., Limbo, REXX, etc.)
as the syntax can be cleaner.

> I know there are a few companies that still use it
> for embedded programming purposes.

Yes, I have a friend who makes his living doing
*only* that.  :>

Here's the "sample" application I use to evaluate
language candidates (i.e., it's big enough to
be considered non-trivial, uses IPC/automation
in a realistic context, has a straightforward
user interface and, yet, doesn't split hairs
on performance issues...):

Write a "units of measurement" converter.
I.e. something that allows the user to convert
inches to angstroms, or Newton-meters to
pound-feet, etc.

Conceptually, this is easy:
- parse "units" database to see what units you
  know about (invoking a database service to do so)
- build menus organizing these units for presentation
  to the user (e.g., put all "length" units in one
  menu, all "mass" units in another, etc.)
- get 'from' and 'to' units from user (invoking
  a display service to do so)
- get 'quantity' from user
- do the conversion using formulae stored in database
- present result to user

It's a trivial program but it draws on lots of
features
that I want the language to have available.   E.g.,
IPC to the various services running alongside it
(user i/f, database, etc.); variable precision math
(so developer doesn't have to sit and wonder how best
to preserve all significant digits when converting
parsecs/second to angstroms/fortnight); text
processing
to hack together menus; complex decision logic (to
sort through the various conversion factors available
to come up with the appropriate scheme for the
conversion requested -- e.g., seconds->minutes,
minutes->hours; hours->days; days->fortnight).

(It's actually a fun little problem to solve.  And,
it points out lots of drawbacks in most languages
in the process!)

Imagine trying to write something in FORTH that does
this?  And, trying to figure out how it works three
days AFTER you've finished...  :-(

--don


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