<foghorn leghorn> It was a joke, son...I say, a JOKE! ;) </foghorn leghorn>
On Aug 30, 2007, at 1:29 AM, Samuel A. Falvo II 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 -- Dave McGuire Port Charlotte, FL Farewell Ophelia, 9/22/1991 - 7/25/2007 _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user