ZMLEB@SCFVM.BITNET (Lee Brotzman) (08/13/88)
Fraser Orr wondered why we Forth programmers don't use infix operators. Well, we could if we wanted to. I am following this message with another that shows how to define infix operators in Forth. It takes only three very short Forth words, plus a series of redefinitions of the words you would like to "infixize". Now, I guess the question is, "Why don't we want to use infix?" I can speak for no-one but myself when I say: I have had no trouble learning to think in postfix. Some people do, but that is their problem. I have had no trouble learning to keep a three-deep stack in my head. Some people do, but that is their problem. It is simply a matter of conventions and aptitudes, that's all. Some people get it and some people don't. It's not really a big deal. People that like to program in Forth are not simply "unenlightened". To the contrary, many that I have met have been the most computer literate people I've seen. Using Forth is a matter of informed choice, not ignorance. Fraser, I am sure that you have learned things that I would have a terrible time at. My wife is comptroller of a small company, and I can't make hide nor hair of anything she does -- it's all "magic". Likewise, the work I do -- archival and distribution of astronomical data -- is "magic" to her. I think it is time to accept the fact that the problems you have with Forth are not universal. I grant you this: Forth has a steep learning curve. It also has rewards for traveling up that curve that are difficult, if not impossible, to find in other languages. For instance, take the message that I will send following this one. I just saw it this morning on a local bulletin board dedicated to Forth programming called the East Coast Forth Board (ECFB: 703-442-8695, 8-bits, no parity, 1 Stop bit; 300, 1200, and 2400 baud; McLean, Virginia, USA). My first thought was, "Fraser Orr should see this." It was written by Walt Pohl of Haverford College. Using three simple Forth words, he can redefine any Forth operator as infix rather than postfix. It isn't fancy, but it works. Can you name another language where it is so easy to change the compiler? In C or Fortran or Pascal you are stuck with the language constructs as they come, whether you like them or not (notwithstanding the C macro facility). In Forth, if you don't like it, CHANGE IT! It is this freedom that Forth programmers like. It is individualism. I can understand that you may not like it. I only ask that you understand that I (we) do. You also mentioned in your reply to me that you applaud the innovations to the language I listed, but you added the caveat that if they weren't part of a standard you wouldn't use them. This I simply don't understand. Do you mean to say that you have not built a library of functions in C for your own use? C without it's libraries -- much of which are not standard -- is practically useless. Extensions to Forth are like C libraries. They are useful items that have been developed to add functionality. Many Forth programmers have their own versions of "mylib.c", except with a different name of course, just like C programmers. It is something we share, not something that sets us apart. As for developing a typing system in Forth, I participated in a many- months-long discussion about data typing on the ECFB with Mr. George Hawkins. To summarize it now would be impossible, suffice it to say that data typing is possible at a great expense in compile time overhead. If you are accustomed to traditional language compilers, waiting a minute or two to compile a program probably doesn't bother you. To a Forth programmer, that is an interminable wait. Anything that impacts compile time, even if it may decrease some testing time will be resisted. Personally, the typing scheme used in Forth, where the data are not typed but the operators on the data are (e.g. + to add two integers and D+ to add two double precision integers) doesn't bother me in the least. Another one of those attitude differences, I suppose. As for my statement of the rapid evolution of Forth. On the scale of the single programmer, the changes are not so great. He has his system and sticks with it. That system evolves at its own rate and if he has purchased a commercial system, his vendor should supply periodic updates which outline any changes. This evens out the learning curve somewhat. By keeping "plugged in" to forums such as Usenet and BITNET, and the bulletin boards like the ECFB and its "sister" boards the North Coast Forth Board (NCFB) and the British Columbia Forth Board (BCFB), all three of which I recommend very highly, one can see how things are changing and adapt or not as one sees fit. Electronic Forth conferences also exist on other commercial systems like BIX and GEnie. The Forth Interest Group publishes a periodical with articles about new developments. The Journal of Forth Applications and Research, published by the Institute for Applied Forth Research in Rochester, New York, also carries articles about advancements and applications in Forth. Using these resources, one can learn a lot. I am sure that some of the international subscribers to the BITNET FIGI-L mail conference can also tell of resources available in their countries. Forth isn't just a "back woods" programming language anymore, even though it isn't as popular as Fortran, C, Pascal, COBOL, and Ada. It has been used to control hydrogen fusion lasers, astronomical telescopes, image processing systems, space hardware, robots, and automobiles. It has been used to write text editors, spread sheet programs and computer games. God knows what other applications Forth has been applied to. I do not see these as only "very special cases" as you do. Enough of the psuedo-religious babbling. I'll stop now. Look for my next message which contains the text of Mr. Pohl's infix operator code. -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM SPAN: CHAMP::BROTZMAN GEnie: L.BROTZMAN -- My opinions are my own and not those of my employer, ST Systems Corp., -- or their employer, NASA Goddard Space Flight Center, or their employer, -- Ronald Reagan, or his employer, Nancy Reagan, or her employer, the -- planets and stars.
ZMLEB@SCFVM.BITNET (Lee Brotzman) (08/13/88)
As I mentioned, this is the message concerning the use of infix operators
in Forth written by Walt Pohl of Haverford College. Enjoy.
-- Lee Brotzman
----------------------------- Message Follows --------------------------
I've come up with a small set of words for defining infix notation in
Forth. The words are simple and fairly Forth-like. They are basically
syntactical sugar that give the "illusion" of infix without any of infix
notation's speed costs at run time.
Define ( in Forth-83 Standard):
: ) IF EXECUTE ELSE , THEN ; IMMEDIATE
: INFIX CREATE ' , IMMEDIATE DOES> @ 0 ;
: IMFIX CREATE ' , IMMEDIATE DOES> @ -1 ;
We now use INFIX and IMFIX to create new infix words out of old postfix
ones. The syntax is INFIX <new infix word> <old postfix word> and IMFIX
<new infix word> <old postfix word> (use INFIX on non-immediate words, IMFIX
on immediate ones).
INFIX +( +
INFIX -( -
INFIX *( *
INFIX /( /
IMFIX IF( IF
IMFIX THEN( THEN
The syntax for usage is:
<new infix word> <last-argument> ), which is equivalent to
<last-argument> <old postfix word>
So, 3 +( 5 ) is equivalent to 3 5 + and IF( = ) is equivalent to
= IF.
When used properly, infix (particularly infix IF) can bring more
readable syntax. I don't plan on using infix all that heavily, but I
thought it would be nice to have available.
The three colon definitions define all the primitives necessary for
infix notation. INFIX and IMFIX are defining words which create actual
infix words. For example, with the above words defined with INFIX and IMFIX,
you can now type:
: FOO IF( 5 +( 5 ) 10 = ) THEN( ." YOU FOOL" ) ;
instead of:
: FOO 5 5 + 10 = IF ." YOU FOOL" THEN ;
or you can mix the two:
: FOO IF( 5 5 + 10 = ) THEN( ." YOU FOOL" ) ;
INFIX creates an infix form of a non-immediate word, and IMFIX
creates an infix form of an immediate word. By convention, each infix
word ends with an '('.
An infix word tells the compiler to wait until the ) before compiling
its code, so 5 +( 3 ) is equivalent to 5 3 +. The use of the right parenthesis
in that fashion allows nesting of infix words, like 5 +( 3 -( 2 ) ) instead of
5 3 2 - +.
Note that ) is an actual word in this case, and not just a delimiter.
Thus it must be preceded and followed by a space.
By making ) a word, and not just a delimiter, it allows infix
usage to spread over more than one line, such as:
: FOO IF(
5 3 = )
THEN(
." You fool"
) ;
Also, all of these words are immediate, and thus can only be used in
colon-definitions. They really work thus:
: FOO
5
+( \ put the address of + on the stack.
3
) \ compile the address of +
;
: FOO
IF( \ put the address if IF on the stack.
5 3 =
) \ Execute IF.
THEN( \ put the address of THEN on the stack.
." You fool"
) \ execute THEN.
I hope this was comprehensible. My brain was fried while I typed it.
If you have any questions, send me mail, and maybe I'll be able to explain it
better. I hope people find this useful.
--
Walt Pohl (Haverford College)orr@cs.glasgow.ac.uk (Fraser Orr) (08/18/88)
In article <8808121826.AA23206@jade.berkeley.edu> ZMLEB@SCFVM.BITNET (Lee Brotzman) writes: > > Fraser Orr wondered why we Forth programmers don't use infix operators. >Well, we could if we wanted to. I am following this message with another >that shows how to define infix operators in Forth. It takes only three >very short Forth words, plus a series of redefinitions of the words you >would like to "infixize". Well Lee, I held out a bit of hope until I read the following article. There seems to be rather a lot of spare brackets flying around in there. The purpose of infix notation is to make the program text clearer, it is not an end in itself ... "a+b+c*d" vs "a b c d * + +" vs "a +( b ) +( c *( d ) )" The last of these three is a clear looser for readability, the first is a clear winner. Anyway, that's not the point of your article, you could quite easily add infix, prefix and whatever-other-fix operators you like if you would accept a preprocessor. > Now, I guess the question is, "Why don't we want to use infix?" > > I can speak for no-one but myself when I say: I have had no trouble >learning to think in postfix. Some people do, but that is their problem. >I have had no trouble learning to keep a three-deep stack in my head. >Some people do, but that is their problem. What a very xenophobic attitude! "If people don't think the way I do then they really can't expect to understand what I'm saying!" Everyone who understands what addition means understands the "a+b" notation (yes because thats the way they've been taught), few understand the "a b +" notation (yes, because they haven't been so taught). I'm not trying to say that "a+b" is intuitvely better than "a b +" (though this is my belief - let's not argue over intuition though) all I'm saying is, if there is a well established standard (and you can't get much more well established than the infix arithmetic operators) you've got to have a VERY VERY good reason not to use it. Why has forth chosen to break this standard? Probably for the folloing reasons ... 1) It is easier to implement - as I mentioned before easy to use is MUCH more important than easy to implement. 2) You can save recalculations of intermediate results by the "drop swap flip flop" contortions - I believe that is what optimising compilers are for. 3) It gives a simple, straight forward syntax, that is easy to remember - i.e., it pretends that syntax doesn't exist, and although esy to learn, and not too hard to use, it is VERY HARD to read! These are not in my view anywhere near justification for breaking this standard, and I believe that the only reason that people aren't willing to change is because "its always been like that", and "I can read it, why can't you?", and other such nonsense. Let me also pick up on point 3 above. When Ada was being designed, they very sensible observed, that on average a program was read ten times more often than it was written, so making a program more readable, even at the expense of making it less writtable, was a wise investment (this is why Ada is such a verbose language). Now although I think they overdid it, they most certainly have a point. And all this "drop swap flip flop" (credit to whoever it was that first wrote this gem) is write only. I know, because I've got to detangle that sort of rubbish when I'm reading PostScript code. > It is simply a matter of conventions and aptitudes, that's all. Some >people get it and some people don't. It's not really a big deal. People >that like to program in Forth are not simply "unenlightened". To the >contrary, many that I have met have been the most computer literate >people I've seen. Using Forth is a matter of informed choice, not >ignorance. The majority of programmers in the world today chose to write in COBOL, any comments? > Fraser, I am sure that you have learned things that I would have a >terrible time at. My wife is comptroller of a small company, and I >can't make hide nor hair of anything she does -- it's all "magic". >Likewise, the work I do -- archival and distribution of astronomical >data -- is "magic" to her. I think it is time to accept the fact >that the problems you have with Forth are not universal. You miss my point. I don't have a problem with forth, I can program in forth. What I'm saying is that it is not appropriate in the vast majority of situations, there is a much better way. Just about all the "computer literate" people I know, recognise the value of clarity and explicitness in a computer program. Or to put it another way, they recongnise the value of syntax. I can cope with 3 deep stacks in my head, I don't want to though, the programmer should make the arithmetic and the parameter grouping explicit and unambigous in the program text. > I grant you this: Forth has a steep learning curve. It also has >rewards for traveling up that curve that are difficult, if not >impossible, to find in other languages. > > For instance, take the message that I will send following this one. >My first thought was, "Fraser Orr should see this." It was written by >Walt Pohl of Haverford College. Using three simple Forth words, he can >redefine any Forth operator as infix rather than postfix. It isn't fancy, >but it works. Can you name another language where it is so easy to change >the compiler? In C or Fortran or Pascal you are stuck with the language >constructs as they come, whether you like them or not (notwithstanding >the C macro facility). In Forth, if you don't like it, CHANGE IT! > As a matter of fact I can name some languages that do this, a language called LML provides just such a facility. Languages like C++ and Ada do so also ( though to a lesser extent). > It is this freedom that Forth programmers like. It is individualism. >I can understand that you may not like it. I only ask that you >understand that I (we) do. That is fine if programming were a solitary activity. It is not. Few if any programs are maintained, improved (or even originally written) by one and the same person, for this reason you must keep to a compromised standard that everyone agrees with. I'm sorry to be so blunt, but individualism is totally inappropriate when writting real programs. > You also mentioned in your reply to me that you applaud the innovations >to the language I listed, but you added the caveat that if they weren't >part of a standard you wouldn't use them. This I simply don't understand. >Do you mean to say that you have not built a library of functions in C for >your own use? C without it's libraries -- much of which are not standard -- >is practically useless. Extensions to Forth are like C libraries. >They are useful items that have been developed to add functionality. >Many Forth programmers have their own versions of "mylib.c", except with a >different name of course, just like C programmers. It is something we >share, not something that sets us apart. > Sorry but there is a huge difference between libraries and bolt on language features. In my C library I have routines like "Split_Line_Into_Words" and "Skip_Blank_Lines". Anyone reading these titles can make a fair guess at what they mean, and if I give a 2 line explanation, then they will know exactly and will remember exactly. But if you introduce things like structures and infix operators into a language that doesn't have them, then the poor guy comming from the outside is going to have to learn half a new language before he can hope to understand your programs. For the same reason, the extended operators in LML, C++ and Ada must be used with extreme care because if they are abused they totally obfuscate the meaning of the program. (There was a long discussion on this very subject a few months back in comp.lang.c++, if you want more on this read the archives of this group). Why am I saying, infix operators are great, but don't put them in forth because it will obfuscate the meaning? I am saying, design a totally new language on top of forth, that provides the same functionality, is parsed quickly down to forth, but has all these essential features (infix operators, syntax, structures, types and type checking, local scopes, static binding ...) as part of the standard language. > As for developing a typing system in Forth, I participated in a many- >months-long discussion about data typing on the ECFB with Mr. George >Hawkins. To summarize it now would be impossible, suffice it to >say that data typing is possible at a great expense in compile time overhead. >If you are accustomed to traditional language compilers, waiting a minute >or two to compile a program probably doesn't bother you. To a Forth >programmer, that is an interminable wait. Anything that impacts compile >time, even if it may decrease some testing time will be resisted. See my foregoing comment. > Personally, the typing scheme used in Forth, where the data are not >typed but the operators on the data are (e.g. + to add two integers and >D+ to add two double precision integers) doesn't bother me in the least. >Another one of those attitude differences, I suppose. The different names are not relly the issue here. What if you have to floats on the stack, and you apply D+? You get garbage! These sort of errors are amazingly hard to find, but they just don't occur with a decent type system. > By keeping "plugged in" to forums such as Usenet and BITNET, and the >bulletin boards like the ECFB and its "sister" boards the North Coast >Forth Board (NCFB) and the British Columbia Forth Board (BCFB), all [etc deleted] I don't have to look at builetin boards to get important features like structures, they're already provided. > > Forth isn't just a "back woods" programming language anymore, even >though it isn't as popular as Fortran, C, Pascal, COBOL, and Ada. It >has been used to control hydrogen fusion lasers, astronomical telescopes, >image processing systems, space hardware, robots, and automobiles. It >has been used to write text editors, spread sheet programs and computer >games. God knows what other applications Forth has been applied to. >I do not see these as only "very special cases" as you do. No I don't see these as special cases, just totally inappropriate things to write forth programs for. I can't think of no larger and more important program than IBM's OS/360, this was originally written in assembler, would you say this is justification for saying operating systems are best written in assembler? > > Enough of the psuedo-religious babbling. I'll stop now. Look for my >next message which contains the text of Mr. Pohl's infix operator code. > veni, vidi ..... ARGHHHHHH :^) Regards, ===Fraser Orr ( orr%cs.glasgow.ac.uk@nss.ucl.ac.uk )
jax@well.UUCP (Jack J. Woehr) (08/22/88)
It's late and too tedious to edit long postings! But Fraser Orr, self appointed Ahriman to all the Amesha Spentas of Forth here in comp.lang. forth has delivered some mighty blows! Nonetheless, what can we say but, "if you are not a true believer, Brother Orr, you cannot know the joys of Total Immersion in Forth ..." One point of fact though that we wish to quibble with you: your reference to a list of projects, predominantly control projects, done in Forth as a "list of totally inappropriate uses of Forth". As of 1988, it looks like Forth is taking the embedded control industry by storm. Reasons: tiny, complete programming environment; ease of translation of concept to reality; body of talented, well-trained Forth programmers to do the job; amazing power of Forth-oriented microchips like the Zilog Super8 and the Harris RTX. ********** well!jax@lll-winken.arpa jax@chariot.UUCP " Forth is the answer, what was the question?" JAX on GEnie
orr@cs.glasgow.ac.uk (Fraser Orr) (08/25/88)
In article <6882@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: > Nonetheless, what can we say but, "if you are not a true believer, >Brother Orr, you cannot know the joys of Total Immersion in Forth ..." > Did you miss out a simely there brother Jack? :-) > One point of fact though that we wish to quibble with you: your >reference to a list of projects, predominantly control projects, done >in Forth as a "list of totally inappropriate uses of Forth". > > As of 1988, it looks like Forth is taking the embedded control >industry by storm. Reasons: tiny, complete programming environment; >ease of translation of concept to reality; body of talented, well-trained >Forth programmers to do the job; amazing power of Forth-oriented microchips >like the Zilog Super8 and the Harris RTX. > Jack, are you suggesting that because "industry has taken it by storm", that it is necessarily the best (or even appropriate)? If so, do you also support COBOL as the best for buisness work, or Fortran for sientific work (yes, I know all the arguments about software libraries etc, but that's not the point, we're discussing what is the most appropriate medium to express your ideas is). I think though my statment was perhaps too strong though. I don't really know how good forth is for this kind of work, since I have never done such programming in forth. What I am absolutely certain of though, is that if you used a preprocessor that allowed infix, procedures with parameter lists, type checking, and all the other things that the rest of the Comp Sco world has agreed to be benificial, then the job would be much easier. Moreover if you designed your new language so that it mapped easily onto forth, then you could compile directly to forth, and use these new wonder microprocessors also. Or to put it another way, have your cake and eat it! Regards, ===Fraser (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk)
olorin@juniper.uucp (David Weinstein) (08/27/88)
In article <1581@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: [...] >never done such programming in forth. What I am absolutely certain of >though, is that if you used a preprocessor that allowed infix, procedures >with parameter lists, type checking, and all the other things that the >rest of the Comp Sco world has agreed to be benificial, then the job would >be much easier. NO, it would not. It is possible to write awful code for any language (ever *looked* at the Unix source?). But even the best written C still looks, well, sloppy. Forth lets you (but does not force you to) write very high level code, which will converge to RPN english (noun verb format). Writing in this style takes a bit more effort, but with proper factoring, and keeping most of the Forth "noise" words down at a lower level, the resulting code is quite readable, and does not suffer (at least at the top level), from "flip flop swap drop" fever (although these "noise words are used at lower levels). It is impossible to work to that high a level in languages like C, because the language format is inflexible, and you cannot abstract out the ()s or other pieces of syntactical noise from your code. As to the great infix/postfix/prefix/fix-the-fight controversy: RPN is not hard to learn, and quickly becomes intuitive. As to the assertion that programmers don't learn it, how many are using HP Calculators? How many non-programmers use adding-machines? And thanks Fraser.... ....comp.lang.forth has been saved from an ignominious decline into an infrequent stream of requests for Forth for new computers... :-) -- Dave Weinstein Internet: olorin@walt.cc.utexas.edu UUCP: {ames,utah-cs,uunet}!ut-sally!ut-emx!{walt.cc.utexas.edu,juniper}!olorin GEnie: DHWEINSTEIN
jax@well.UUCP (Jack J. Woehr) (08/28/88)
In article <1581@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >In article <6882@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: >> As of 1988, it looks like Forth is taking the embedded control >>industry by storm. Reasons: tiny, complete programming environment; >>ease of translation of concept to reality; body of talented, well-trained >>Forth programmers to do the job; amazing power of Forth-oriented microchips >>like the Zilog Super8 and the Harris RTX. >> >Jack, are you suggesting that because "industry has taken it >by storm", that it is necessarily the best (or even appropriate)? If so, >do you also support COBOL as the best for buisness work, or Fortran for >sientific work (yes, I know all the arguments about software libraries >etc, but that's not the point, we're discussing what is the most appropriate >medium to express your ideas is). > >I think though my statment was perhaps too strong though. I don't >really know how good forth is for this kind of work, since I have >never done such programming in forth. Frase, I write control apps for a living. In Forth. Sometimes two a day. My boss hates Forth, but he can't find a language other than Forth that is so productive. He wrings his hands, then he tells the client, "Well, actually, if we do it in Forth, we can take $8,000 off the development costs ..." You would be surprised how convincing an argument that is over here in the Land of the Almighty Dollar! Forth, being its own op system, interactive, and fully featured in a memory model that corresponds to controller apps, is *the* language for real time control. As a matter of fact, if you have not yet heard, the annual Forth Interest Group convention has been renamed the Real Time Programming convention. Yes, Forth has found a niche at last! ************************* jax@well jax@chariot "Repent! Reboot!" JAX on GEnie
gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (08/29/88)
In article <4057@juniper.uucp> olorin@juniper.UUCP (David Weinstein) writes: >In article <1581@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >[...] >>never done such programming in forth. What I am absolutely certain of >>though, is that if you used a preprocessor that allowed infix, procedures >>with parameter lists, type checking, and all the other things that the >>rest of the Comp Sco world has agreed to be benificial, then the job would >>be much easier. > >NO, it would not. It is possible to write awful code for any language (ever >*looked* at the Unix source?). But even the best written C still looks, >well, sloppy. This is certainly your opinion. I personally don't really like C, but I have seen some "neat" code in C. But how about languages like Pascal or Modula-2? Is it any wonder why many beginning cs courses use Pascal? It's readable, that's why! > Forth lets you (but does not force you to) write very high level >code, which will converge to RPN english (noun verb format). Writing in this >style takes a bit more effort, but with proper factoring, and keeping most of >the Forth "noise" words down at a lower level, the resulting code is quite >readable, and does not suffer (at least at the top level), from "flip flop >swap drop" fever (although these "noise words are used at lower levels). >It is impossible to work to that high a level in languages like C, because the >language format is inflexible, and you cannot abstract out the ()s or other >pieces of syntactical noise from your code. For an even better place for this type of factoring, consider Smalltalk. It has an even better "noun verb" format - instead of "noun noun noun verb", it is "noun adjective noun verb noun" (anArray at: 5 put: 10) - and this I wouldn't consider to be RPN english! >As to the great infix/postfix/prefix/fix-the-fight controversy: > >RPN is not hard to learn, and quickly becomes intuitive. As to the assertion >that programmers don't learn it, how many are using HP Calculators? How many >non-programmers use adding-machines? OK, now this is where I draw the line. I use and HP calculator. Many of my friends use HP calculators. But, consider how HP calculators are used - you sit down, you type the numbers & the operators and you get the result. What you are doing is "writing" code. You are not reading it. RPN is easy to write. Yes, it is intuitive to write. But not to read. You have to learn to do that. And many times it take a lot of work. As a disclaimer, I want it noted that I like the basic idea behind forth. It is elegent. And there are some neat things you can do with it. And it is small. I like forth since I first learned about it in 82? when Byte did an issue on it. I just don't like the syntax WITH REGARDS TO ARITHMETIC EXRESSION (I have no problems with the RPN of procedure calls, although control statements are a minor hassle - this is something you can get use to). Oh, BTW, the "infix" system posted earlier actually works as a prefix system, and it looks better that way too. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Now that isn't | Glenn Andreas = = enough" - Alex P. Keaton | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
olorin@juniper.uucp (David Weinstein) (08/31/88)
In article <472@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >In article <4057@juniper.uucp> olorin@juniper.UUCP (David Weinstein) writes: >> >>NO, it would not. It is possible to write awful code for any language (ever >>*looked* at the Unix source?). But even the best written C still looks, >>well, sloppy. >This is certainly your opinion. I personally don't really like C, but I have >seen some "neat" code in C. But how about languages like Pascal or Modula-2? >Is it any wonder why many beginning cs courses use Pascal? It's readable, >that's why! Funny...I thought that they taught Pascal because it's a programming straight jacket... :-) The "sloppiness" I was referring to is the: function (arguments) format. It is (at least in my opinion), harder to read than well written Forth (now badly written Forth on the other hand...) C, the language which I do most of my programming in (I have to pay my rent :-), is in fact "almost readable". I dislike Pascal because I feel confined (I *don't* like paternalistic compilers). > [Material about why you can't write really high level code in "conventional languages" deleted] >For an even better place for this type of factoring, consider Smalltalk. It >has an even better "noun verb" format - instead of "noun noun noun verb", it >is "noun adjective noun verb noun" (anArray at: 5 put: 10) - and this I >wouldn't consider to be RPN english! An excellent point. I am very interested in learning Smalltalk, but Forth is very efficient, powerful, and (in my opinion) easy to understand. I would be delighted to see Forth taught as an introductory class in CS, because it teaches so many wonderful technques (and it teaches about the underlying hardware in a very easy to undertsand manner). Forth does not require tremendous resources (although they are nice :-) ), and it is fairly easy to implement, and expand... As I have said, I don't know about Smalltalk, so I can't compare the two... > >>As to the great infix/postfix/prefix/fix-the-fight controversy: >> >>RPN is not hard to learn, and quickly becomes intuitive. As to the assertion >>that programmers don't learn it, how many are using HP Calculators? How many >>non-programmers use adding-machines? >OK, now this is where I draw the line. I use and HP calculator. Many of my >friends use HP calculators. But, consider how HP calculators are used - you >sit down, you type the numbers & the operators and you get the result. What >you are doing is "writing" code. You are not reading it. RPN is easy to >write. Yes, it is intuitive to write. But not to read. You have to learn >to do that. And many times it take a lot of work. > >As a disclaimer, I want it noted that I like the basic idea behind forth. >It is elegent. And there are some neat things you can do with it. And it >is small. I like forth since I first learned about it in 82? when Byte did >an issue on it. I just don't like the syntax WITH REGARDS TO ARITHMETIC >EXRESSION (I have no problems with the RPN of procedure calls, although >control statements are a minor hassle - this is something you can get use >to). I don't really see the problem. Well factored Forth keeps most of the mathematical "noise" at a low level. And, I have really had no problem mastering reading *well written* RPN (I hate reading badly written RPN, however, these are the areas in which comments get real important). -- Dave Weinstein Internet: olorin@walt.cc.utexas.edu UUCP: {ames,utah-cs,uunet}!ut-sally!ut-emx!{walt.cc.utexas.edu,juniper}!olorin GEnie: DHWEINSTEIN