On 8/29/07, Dave McGuire <[EMAIL PROTECTED]> 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user