Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!ucbvax!brahms!desj From: desj@brahms.BERKELEY.EDU (David desJardins) Newsgroups: net.micro,net.micro.pc,net.lang.c,net.lang.pascal,net.lang.forth Subject: Re: FORTH, PASCAL, and C--- which one would you choose (it depends ?) Message-ID: <11321@ucbvax.BERKELEY.EDU> Date: Mon, 30-Dec-85 21:01:37 EST Article-I.D.: ucbvax.11321 Posted: Mon Dec 30 21:01:37 1985 Date-Received: Wed, 1-Jan-86 00:25:53 EST References: <1191@princeton.UUCP> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: desj@brahms.UUCP (David desJardins) Distribution: net Organization: University of California, Berkeley Lines: 101 Xref: watmath net.micro:13324 net.micro.pc:6370 net.lang.c:7476 net.lang.pascal:414 net.lang.forth:330 In article <1191@princeton.UUCP> wei@princeton.UUCP (P Wei) writes: >I compared the Eratosthenes sieve benchmark for Lattice C, Microsoft C, >TURBO Pascal and HS/Forth for IBMPC. For 10 iterations, the execution looks >like : >Microsoft C : 13.2 sec (from pc-tech Jan 1986, p91) > 8.1 sec (using register) >Lattice C : 10.5 sec (from the same place as above) >TURBO Pascal: 14.1 sec (from an ad for ZBASIC) >HS/Forth : 47.0 sec in interpreter (data from ad) > 7.0 sec using code optimizer and improved program >Assembler : 5.0 sec Note that TURBO Pascal is a "quick and dirty" compiler which does no real optimization. Also, range checking and other slowdowns were probably left on; this invalidates the comparison with versions of C which (I believe) do not include these as defaults. Further, the point of benchmarks is _not_ to improve the program, nor to optimize the code... The meaning of these numbers is certainly open to question. Let us assume that Forth can indeed produce somewhat faster results than C or Pascal. >Now, the question is : >It seems that Forth is as extensible and structured as C and Pascal (to my >understanding), and generates more compact and faster execution program. A structured language is one which imposes structure on the programmer; i.e. forces programs into a pattern. Forth is the antithesis of structure. I like Forth, but in the same way that I like assembly language--it is fast and efficient. It might even be a reasonable alternative to C for some purposes, since in either language the programmer is largely responsible for the integrity of his data structures. (I don't like C much, I'm afraid...) Forth is also _not_ as extensible as Pascal, in that Pascal maintains the integrity of user extensions, whereas Forth leaves the programmer with this responsibility. >Its interpreter being far more faster than BASIC's makes developement time of a >project much less than when using 'edit-compile-link-test' type of language. This is not really true on large projects (large enough to be broken into separate modules). The extent to which it is true is also dependent on programming style. >I wonder why Forth is still less popular (to my impression) than C and Pascal. >Is it because [of]: >--its somewhat 'awkward' syntax ? (Pascal is closer to human language) I like Forth syntax a lot; certainly I would not choose one language over another for its syntax in any case. >--its lack of predefined data structure ? I think this is the main point. Modern programming does involve complicated data abstractions, and while I can believe that structures to represent these can be constructed in Forth, all of the burden of both the construction and the segregation of types falls on the programmer. Maintaining the distinction between data types is half of the purpose of a programming language (especially if you consider the program itself as a data type!). >--its putting great responsibilty on the programmer ? (the kernel is so compact > and simple that you must first extend the system and create many things which > in C and Pascal are taken care of by the compiler-writer.) In this sense, > if I compare the simplicity and primitiveness I get: > Assembly > Forth > C > Pascal (where > means simpler than). > We know power comes from simplicity, however we must pay price for it. I strongly disagree that power comes from simplicity. Power comes from having complex tools in place to support the tasks you wish done, rather than having to do everything by hand. For driving nails a fist is simple; a hammer is powerful. >For C-lovers, do you think UNIX-like (or operating system in the general sense) >can be written in FORTH and possibly has better performance? This seems quite possible. Unfortunately, the tools needed for this do not yet exist (compiler compilers, code generators, etc.). If the same effort is put into developing Forth that was put into C, I believe it is quite possible. With hardware Forth machines, the result could be impressive. But work on the system would still largely be done in high-level languages and perhaps compiled into Forth. (Disclaimer: I perhaps am not qualified to comment on this, as I am not a C-lover.) >For Pascal-lovers, is the 'visually' readability and strongly type the primary >advantage ? and a must ? As I said before, syntax is irrelevant... Strong typing, on the other hand, is invaluable. I don't suppose I'm going to persuade anyone who doesn't already agree, so I'll just say that I see the weak (lack of?) typing in Forth as perhaps its biggest problem, especially as I see no easy solution without substantial changes in the language. >For Forth-lovers, do you think Forth is suitable for being used as a >general purpose language instead of the one 'exclusively' designed >for use in the lab and industry to control the machine... >HP Wei (wei@princeton) As I said, I think it is quite possible Forth or Forth-like languages have a place as system programming languages, provided the proper development tools are created. I don't believe they have a place as general-purpose languages though; I think if anything high-level languages are moving in the opposite direction (Ada...). But then I don't know what people see in C... -- David desJardins (desj@brahms.UUCP)