Re: gEDA-user: interesting links

["Samuel A. Falvo II" <sam.falvo@xxxxxxxxx>]

On 8/29/07, Dave McGuire <mcguire@xxxxxxxxxxxxx> wrote:
>    FORTH FORTH FORTH!!

Forth lacks a consistent library mechanism, and for that matter,
consistency across implementations.  ANSI Forth compilers addressed
the latter issue, but GForth is still *the* Forth environment to use
if you want full ANSI compliance.  No other Forth compares.

However, as a person who is fluent in both Forth and Haskell, I have
to cast my vote for OCaml or Haskell.  Forth is a VERY capable
language, but because it's a programmer amplifier of unprecedented
degree, you can believe that the code base will be rendered
inscrutible almost as soon as people start to contribute back to the
code base.  This is particularly true as programmers today are more
familiar with record-based abstract data types, rather than
array-based ADTs (think row-major storage versus column-major
storage), and this lack of experience will inevitably lead to horrible
code.  Unless, that is, you want to institute a strict policy of code
reviews (and a corresponding coding conventions guideline document to
back the review approval process) before CLs are accepted.  Ahh, but
now you run the risk of politicizing the CL approval process, which
might be a big turn-off to new submitters.

Additionally, OCaml and Haskell have quite a bit more foreign function
interfaces than Forth does.  GForth supports FFI through the ffcall
library, which is nice, but you'll be re-inventing the wheel for
things like GTK and so forth (again, this boils down to lack of
portable library support, primarily, but also has the side effect of
mandating GForth on POSIX-based systems).  Moreover, no other Forth
for Posix-based systems, that I'm aware of, supports ffcall using the
same wordset that GForth does.  And, I positively know that SwiftForth
is totally different still.

I find Haskell (in particular, since I'm familiar with it) to be as
expressive as Forth in most applications I've written with it.  I
don't see any reason why OCaml would be less so, since it too is a
functional programming language.  Since you can work with a very high
level, functional language and still get code that is on par with
optimized C (or even better in some cases), supports garbage
collection, simply does not possess the concept of the null pointer
(since all structures are initialized from component values, there is
no concept of a null), et. al., to me it is a total no-brainer.

However, if the project is already written in C(++), you'll be better
off keeping it in the same language until a "total rewrite" is called
for.  I'd rather have working software, even if it is developed using
a 40-year old language.  We live in the age of the jet-engine, but we
still ship the bulk of our goods via ocean transport; there's a good
reason for this.  :)

-- 
Samuel A. Falvo II


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user