gary@softway.oz (Gary Corby) (03/21/90)
I may regret asking this, but here goes. I notice that in many comp.lang.forth postings there is a distinct tendency to criticise other languages because of procedure call overhead. Now I would be the first to agree that overhead is to be avoided where possible, but is it not taking things a little too far to say C is too slow? If that's how you feel about C, what do you have to say about Pascal, or Ada? There are still some systems around that need every CPU cycle squeezed from them, but they are now the vast minority. If your application is too slow on a Z80 processor, go buy a 386 box. This doesn't mean I condone sloppy programming, but it does mean I favour clarity of code over efficiency for all but a few time-critical applications. -- Gary Corby (Friend of Elvenkind) Softway Pty Ltd ACSnet: gary@softway.oz UUCP: ...!uunet!softway.oz!gary
wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee) (03/22/90)
In <2747@softway.oz> gary@softway.oz (Gary Corby) writes > ... what do you have to say about Pascal, or Ada? They @#$%, especially ADA. >There are still some systems around that need every CPU >cycle squeezed from them, but they are now the vast >minority. That's not true. I can bet that at least users of MCU and MPU controlled medical, military and space systems want "every CPU cycle squeezed from them". There are tons of these systems out there. Also, in the RISCs, a cycle is to valuable to be wasted. >If your application is too slow on a Z80 >processor, go buy a 386 box. How much is a 386 compare to a Z80? The Z80 is less then a buck in the US in OEM quantity. >This doesn't mean I condone >sloppy programming, but it does mean I favour clarity of >code over efficiency for all but a few time-critical applications. FORTH gives you the efficiency. Clarity is mainly depended on the programmer. I don't find C has any more clarity than FORTH. Wan Ngai Wayne Lee wlee@csd4.csd.uwm.edu
peter@ficc.uu.net (Peter da Silva) (03/22/90)
> FORTH gives you the efficiency. Forth gives you space efficiency. It doesn't give you much in the way of time efficiency. In general, unless you spend a lot of time on micro-optimisation, Forth is a pretty slow beast. Even a good compiled Forth will lose out to a good compiled HLL, simply because you give up too many opportunities for compiler optimisations when you work in such a low level language. Forth is for systems you can't fit a HLL and its bloated runtime into. > Clarity is mainly depended on > the programmer. I don't find C has any more clarity than FORTH. I do. I've worked with some pretty large Forth programs, and unless you're an incredible programmer it's just unmanageable beyond a (fairly low) threshold. Forth is for small systems or brilliant programmers. It's a small systems language. It's bloody great at that. Let's not get carried away by the Forth religion. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
jbaltz@cunixf.cc.columbia.edu (Jerry B. Altzman) (03/23/90)
In article <NPE2VD1ficc@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> FORTH gives you the efficiency. >Forth gives you space efficiency. It doesn't give you much in the way of time >efficiency. In general, unless you spend a lot of time on micro-optimisation, >Forth is a pretty slow beast. Even a good compiled Forth will lose out to a good >compiled HLL, simply because you give up too many opportunities for compiler >optimisations when you work in such a low level language. Well, if you think about the problem well in the first place, you can do a lot of the optimization yourself, if you watch what's going on, and aren't lazy about it. C let's you be lazy about it. >Forth is for systems you can't fit a HLL and its bloated runtime into. Forth is for anything, really. I've programmed it on machines on which there were nice HLL's, and Forth was the language of choice, not because we were controlling real-time devices, but for other reasons (which I don't really want to get into now.) >> Clarity is mainly depended on >> the programmer. I don't find C has any more clarity than FORTH. >I do. I've worked with some pretty large Forth programs, and unless you're an >incredible programmer it's just unmanageable beyond a (fairly low) threshold. I don't. I've worked with some pretty large Forth programs (5k+ "blocks" of code) and the code was pretty well obvious, because the previous programmers took the time to a) prettyprint the code (you'd be surprised how much that helps) b) break the code up into logical modules c) commented (albeit not well: e.g. "Don't muck with this or the machine will crash") >Forth is for small systems or brilliant programmers. I won't comment on this one, Peter :-) > _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. DISCLAIMER: This isn't Columbia. This is me. Columbia is them. //jbaltz jerry b. altzman "We've got to get in to get out" 212 854 8058 jbaltz@cunixf.cc.columbia.edu jauus@cuvmb (bitnet) ...!rutgers!columbia!cunixf!jbaltz (bang!) NEVIS::jbaltz (HEPNET)
wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee) (03/24/90)
In <NPE2VD1ficc@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes >Forth gives you space efficiency. It doesn't give you much in the way of time >efficiency. In general, unless you spend a lot of time on micro-optimisation, >Forth is a pretty slow beast. Even a good compiled Forth will lose out to a >good compiled HLL, simply because you give up too many opportunities for >compiler optimisations when you work in such a low level language. Forth does give you time efficiency. After all, it is the APL & FORTH programmers claim the title of the world's fastest programmer. If you are talking about run-time efficiency, most computer systems aren't optimized for FORTH but HLLs like FORTRAN & PASCAL. If you want run-time efficiency, use a FORTH engine such as SC32, RTXs or at lease get an Zilog Super8. >> Clarity is mainly depended on >> the programmer. I don't find C has any more clarity than FORTH. >I do. I've worked with some pretty large Forth programs, and unless you're an >incredible programmer it's just unmanageable beyond a (fairly low) threshold. Read the source of L&P F83, then tell me what you think. >It's a small systems language. You should try F-PC. A PD FORTH for PC with about 3 MB of source code. It has window, graphics, floating-point, hypertext help & editor, target compiler, and mouse support. In <9003230003.AA15895@jade.berkeley.edu> wmb@MITCH.ENG.SUN.COM writes >The interesting thing is, new Forth programmers tend to write long >procedures too. Then, if somebody yells at them or twists their arm >for long enough, they will eventually start to use shorter and shorter >procedures, and then they are convinced. I didn't write long procedures when I started. Probably because 1) I use blocks 2) everything I read says keep them short >When they go back to programming >in another language (e.g. C), the short procedure style will carry over, >and they will be more willing to pay the syntactic price. When I took my PASCAL and FORTRAN course, I was forced to write short procedures. The TA said procedure better be within one screen, otherwise points off.