Hugh Aguilar <hugoagui...@rosycrew.com> wrote: > largely because it supports mixed-precision arithmetic. Even in the 1980s > when Forth was compiling to threaded code and C was compiling to > machine-code, Forth still beat C in speed when used in applications that > involved a lot of arithmetic (nowadays most Forth systems compile to > machine-code and often beat C on all manner of applications).
Most of the benchmarks the Forth compiler vendors post don't make that claim. Usually they claim to produce a more maintainable system while still achieving high speed and extremely small image size. > I said in the book that Factor makes an excellent prototyping language for > Forth. The programmer can get a prototype working in Factor, and only > concern himself with the integer-overflow issue when he is porting it to > Forth for the production version. This is better than trying to write a > program from scratch, which involves a lot of high-level thinking, while > simultaneously dealing with a lot of low-level issues --- as done in Forth > right now. Now, that's an interesting perspective. When doing that, one should be aware of two things: first, that's not what Chuck Moore would do, and second, that's not what Slava would do. Slava doesn't really have a Forth background, so Factor often has some very primitive differences which would make a port painful. Chuck, of course, would practice what he calls "thoughtful programming"; one of the first practices is to use your programming language as a notation system, both to clarify your thought and to clarify your notation. Switching languages in mid-problem doesn't seem like a strong practice in that respect. Aside from that, it's risky to port from a language with garbage collection to a language that prefers static memory structures (and that's only the start of the differences). > It seems to me that Factor is tied to Forth because you decided to use a > Forth-like syntax (rather than a Lisp-like or Java-like syntax) --- and the > only reason for using Forth-like syntax was to support Factor/Forth ports. I'm certain you're mistaken here. Slava wasn't imitating Forth. He did not use a Forth-like syntax; if anything, he used a Joy-like one. > When Factor diverges too far from Forth syntax however, then Factor betrays > the very purpose of Factor. Factor can be a super-Forth, that supports > dynamic-OOP and garbage-collection and other niceties that Forth doesn't > provide (because they would be too slow), but it should still continue to be > a Forth. As a Forth programmer FAR more than a Factor programmer, I know that this is not an accurate or useful characterization. Factor is NOT a super-Forth; it's not even a superset of a partial Forth. It's a completely different language running on a completely different machine model. The only thing it shares in common with Forth is the general idea of a concatenative language, and at that, Forth was never meant to be a concatenative language. > Even if you like Joy, with its DIP and all that, this is immaterial > to the main purpose of programming, which is to write hella-fast programs. > That is what the customer wants. There's more than "hella fast" to a programming language; if that were all, we'd never have left assemblers. Heck, my customer wants Java (sigh). -Wm ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
