david@ukma.UUCP (David Herron, NPR Lover) (07/24/85)
First a couple of quotes to set the stage.... In article <508@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: > I have seen several projects coded in the "make it look like algol" style > of programming. They define BEGIN to be { and END to be ;}, etc. It always > seems to cause more trouble in the end than it saved. By the time they > finished the project they are usually familiar enough with the language > that they no longer need these crutches. Experienced C programmers get > frustrated trying to follow the code because there is always this extra > level of indirection that has to be verified as correct. I have at > times refused to help users with "C problems" because figuring out > whether the syntax is correct requires reading a 300 line header file > that compleatly redefines the language. In article <2600006@ccvaxa> preece@ccvaxa.UUCP writes: > Unfortunately, the name 'opentest' doesn't imply that the variable > named 'foo' has been set to the new fd and that the file is now open. > It implies (to me, at least) a test of whether it is possible to > open the file. Now, if you wanted to call it "TRY_TO_OPEN", I would > be more likely to interpret the name correctly, but some people might > interpret that name as a Boolean indicating whether or not to try to > open the file. Naming is very tricky. Doing the operation is very > clear. I thought this was an interesting juxtaposition of ideas. On the one hand we have we have this argument to make C look like C. The idea is to avoid using "increment(i)" because the meaning of "increment()" isn't all too clear, and there's already an operator to do the desired function anyway .... On the other hand we have somebody saying that a particular word isn't clear enough (opentest) and offering up another (TRY_TO_OPEN) saying that his is unambiguous. (I don't quite follow him though, since all EITHER open() or fopen() do is TRY_TO_OPEN a file, returning an indicator as to their success, that the indicator is also useful in later code isn't important). What I think both these people are trying to say is that WORDS are very imprecise. Especially when asked to handle precise objects as are found inside computers. But then my biggest gripe about pascal is that it's full of words. The words get in the way of understanding the code. To sum up (and to get to sleep). Why can somebody see an infinity of additions in an integration, but it only takes up a half line of a page? It's the expressive use of symbols. That's what does it. Or taken from another tack. One of the neatest things I saw when I was first on Usenet was a picture of a see ship floating in a V shaped trough of water. But this wasn't a real picture. This was a drawing on a CRT screen. One of the lowest resolution mediums ever available. (Line printers are the next lowest I can think of). Yet somebody was able to make a believable picture of an ocean liner floating in a gallon of water in a huge V shaped trough. They didn't use words. They used symbols. And lines. Why do words have to be the only medium of communication? They aren't y'know! But some people act as if they were. Now. To bring this back down to C.... One of the BEST features of C is that 90% of the words you see on the page are VARIABLES. And ALL words are seperated by graphical symbols of one sort or another. Enabling you to quickly see where variables are (as long as you don't name Input File as "if") and where all the operators are. (i.e. you don't have a = b mod c, instead you have a = b % c). G'night. I'm rambling. -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> --- or david%ukma.uucp@anl-mcs.arpa --- Or even anlams!ukma!david@ucbvax.arpa --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david "It's *Super*User* to the rescue!"
mauney@ncsu.UUCP (Jon Mauney) (07/26/85)
> From: david@ukma.UUCP (David Herron, NPR Lover) > Subject: When words are good and when words are bad > Message-ID: <1985@ukma.UUCP> > > What I think both these people are trying to say is that WORDS are > very imprecise. Especially when asked to handle precise objects > as are found inside computers. But then my biggest gripe about > pascal is that it's full of words. The words get in the way of > understanding the code. > ... > They didn't use words. They used symbols. And lines. > ... > One of the BEST features of C is that 90% of the words you see > on the page are VARIABLES. And ALL words are seperated by graphical > symbols of one sort or another. Enabling you to quickly see where > variables are (as long as you don't name Input File as "if") and > where all the operators are. (i.e. you don't have a = b mod c, > instead you have a = b % c). > > G'night. I'm rambling. > -- > --- David Herron Symbols are useful because they permit a small object to represent a large idea. But remember that words are also symbols, just slightly longer. The trouble with graphic symbols is that their meaning is arbitrarily assigned -- why should '%' mean modulus? it looks like a percent sign to me. And even so, it is imprecise: is that a true mathmatical modulus or simply remainder after division? The exact meaning of a symbol must be set down in a set of rules and memorized, whether that symbol is a word or a single squiggle. The differences are: a) squiggles are shorter, making them easier to type, easier to fit on a line or a screenful, but also easier to overlook when scanning a page. b) squiggles don't look like variables or procedure names c) squiggles have no relation to other experience, such as natural language, and thus take more effort to memorize. If symbols are so great, why not do away with keywords entirely? We could use <- for "goto", @-> for "if", >< for "while", and [->] for "switch". Wouldn't that make programs a lot easier to read? -- Jon Mauney, mcnc!ncsu!mauney "The door's not shut on my genius, but... North Carolina State University I just don't have the time."
long@oliveb.UUCP (Dave Long) (07/28/85)
In article <2903@ncsu.UUCP> mauney@ncsu.UUCP (Jon Mauney) writes: | If symbols are so great, why not do away with keywords entirely? We could | use <- for "goto", @-> for "if", >< for "while", and [->] for "switch". | Wouldn't that make programs a lot easier to read? I think it would, but then I once rewrote cdecl so that it would use symbols instead of this English stuff. If you don't like symbols, use COBOL! (Paraphrased) "Let the programmers program in English, and you will "find that they cannot" -- <I don't know> @[:], Dave Long -- {hplabs,fortune,idi,ihnp4,tolerant,allegra,tymix}!oliveb!long
bc@cyb-eng.UUCP (Bill Crews) (07/29/85)
> Symbols are useful because they permit a small object to represent > a large idea. But remember that words are also symbols, just slightly > longer. The trouble with graphic symbols is that their meaning is > . . . > c) squiggles have no relation to other experience, such as natural language, > and thus take more effort to memorize. That is just the point. Words DO relate to other experiences. Thus we are lured occasionally into associating their denotations and connotations with their meanings in the programming language. Why try to dream up some word that closely approximates the meaning of, say, ^=, when one who knows what assignment operators do and what ^ does can unambiguously infer the meaning? -- / \ Bill Crews ( bc ) Cyb Systems, Inc \__/ Austin, Texas [ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc
haahr@macbeth.UUCP (Paul Haahr) (07/29/85)
Jon Mauney (mcnc!ncsu!mauney) writes in <2903@ncsu.UUCP>: > If symbols are so great, why not do away with keywords entirely? We could > use <- for "goto", @-> for "if", >< for "while", and [->] for "switch". > Wouldn't that make programs a lot easier to read? Dijkstra et. al. use the guarded command syntax with extremely few keywords, (i.e. do od if fi proc skip...) and heavy use of symbols to produce what many people consider readable code. I do work in lisp and certainly don't find (plus a b) more readable than "a + b", or (setq a b) easier to understand than a = b or a := b. The notation of (algol|fortran)-like languages certainly parallels more closely mathematics, which is how most people are taught ideas like multiplication. Control flow is something people generally first learn in computer science, so there is really no argument saying that we should steal from some other field a better notation. Use of keywords has been around for a while, but that seems to be only because that's the way things were done way back when. Certainly the notation you suggest is (intentionally) awful, but writing -> (or => or something) makes sense. Even in Ada (tm - DoD/AJPO), the most verbose of languages (not that this is necessarily bad, just an observation) the design team made the choice of use the "when green =>" rather than "when blue do" notation. That wasn't thought to decrease readability. Besides, what are words but symbols? They just happen to be symbols made up of symbols in a specific alphabet that have a meaning some arbitrary language (in this case English) that a lot of people have at least a passing familiarity with. One could argue that fewer keywords and more symbols in a programming language would lead to a more international (at least spoken language independent) style of programming. I am not arguing that the use of symbols is inherently better. I am arguing that carefully picked out symbols can lead to readable program structures. For expressions. For control flow. And for data types (note that I find C's notation worse than Pascal's for data types, and find this the part of C I like least, but this is the specific notation used and the use of notation in general). To quote the 4.2 bsd distribution of fortune: Re graphics: A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. Now algorithms aren't pictures. Or words. And a combination of words and pictures together provide the description of an algorithm. I find that more symbols help describe these ideas. Obviously there are different opinions. -- Paul Haahr ..!princeton!macbeth!haahr
beng@microsoft.UUCP (Ben Goetter ms1/261) (07/30/85)
==== | From: mauney@ncsu.UUCP (Jon Mauney) | Newsgroups: net.lang.c | Message-ID: <2903@ncsu.UUCP> | Keywords: !politicians, !preachers | If symbols are so great, why not do away with keywords entirely? We could | use <- for "goto", @-> for "if", >< for "while", and [->] for "switch". | Wouldn't that make programs a lot easier to read? ==== Doesn't this belong in net.lang.apl? or net.crypt? -- Miaowara Tomokato (Samurai Cat) ..!decvax!( (summer(1985)) ? (microsoft!beng) : (yale!goetter) )
wendt@bocklin.UUCP (07/30/85)
Imagine sheet music written in words so that anybody could read it. arizona!wendt
rdp@teddy.UUCP (08/01/85)
In article <263@bocklin.UUCP> wendt@bocklin.UUCP writes: >Imagine sheet music written in words so that anybody could read it. > >arizona!wendt dum de dum dum!
DHowell.ES@Xerox.ARPA (08/01/85)
It seems like there's this programming language called APL which uses almost nothing but symbols. Does you think APL is more readable than Pascal, Ada, C, etc.? I'm sure you're in a vast minority if you think so. Dan
nather@utastro.UUCP (Ed Nather) (08/01/85)
> In article <263@bocklin.UUCP> wendt@bocklin.UUCP writes: > >Imagine sheet music written in words so that anybody could read it. > > > >arizona!wendt > > dum de dum dum! No, no, no! It's Tum ti tum tum; Tum ti tum tum ... framp! -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather%utastro.UTEXAS@ut-sally.ARPA
peters@cubsvax.UUCP (Peter S. Shenkin) (08/02/85)
In article <> DHowell.ES@Xerox.ARPA writes: >It seems like there's this programming language called APL which uses >almost nothing but symbols. Does you think APL is more readable than >Pascal, Ada, C, etc.?.... > >Dan No, but it's a hell of a lot more WRITABLE!! You pays your money and takes your choice.... (I realize that this comment is irrelevant to the issue that inspired the remark in the first place, but what the hell; we're all bored to tears of that subject anyhow.) Peter Shenkin philabs!cubsvax!peters
david@ukma.UUCP (David Herron, NPR Lover) (08/03/85)
In article <357@brl-tgr.ARPA> DHowell.ES@Xerox.ARPA writes: >It seems like there's this programming language called APL which uses >almost nothing but symbols. Does you think APL is more readable than >Pascal, Ada, C, etc.? I'm sure you're in a vast minority if you think >so. > >Dan No, I don't think APL is a more readable language than anything else. I particularly don't like the habit of teaching people to program APL to be unreadable. It CAN be readable but people take pride in just the opposite. While you're reading this, take a look at my subject. My original article was intended in pointing out some good uses for symbology. And that in C there were already existing GOOD alternatives to declaring a increment() function. On the other hand. Would someone tell me some good symbols to use in place of something like 'while' or 'for'? Symbology better than using the words? Keep in mind that many languages already have certain operations already assigned to these particular words. And these operations are similar enough to the C operations that people can easily think about it either way. Like I said. Sometimes words are good and sometimes they are bad. There are things better said with non-words. For instance, the ++ operator is much better than defining an increment(). With ++ you can specify WHEN the increment happens (within a certain degree, as they say in K&R, "i++ = j++;" is undefined). Somebody give me a GOOD argument about THAT! -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david
ogasawar@noscvax.UUCP (Todd H. Ogasawara) (08/06/85)
In article <527@oliveb.UUCP> long@oliveb.UUCP (Dave Long) writes: >In article <2903@ncsu.UUCP> mauney@ncsu.UUCP (Jon Mauney) writes: >| If symbols are so great, why not do away with keywords entirely? We could >| use <- for "goto", @-> for "if", >< for "while", and [->] for "switch". >| Wouldn't that make programs a lot easier to read? Sounds like you might want to try APL. Most people say that APl is harder to read that other kinds of programming language. However, if you keep in mind that one line of APL is often the equivalent of dozens or hundreds of lines of other high level lanaguages, it doesn't seem to bad..todd p.s. Let's not start an argument about the relative merits of C and APL. Both have their place in my software toolkit. Sometimes one is more appropriate, sometimes the other is. Todd Ogasawara, Computer Sciences Corp. NOSC-Hawaii Laboratories UUCPmail: {akgua,allegra,decvax,ihnp4,ucbvax}!sdcsvax!noscvax!ogasawar MILNET: OGASAWAR@NOSC
eppstein@columbia.UUCP (David Eppstein) (08/06/85)
In article <2011@ukma.UUCP> david@ukma.UUCP (David Herron, NPR Lover) writes: >On the other hand. Would someone tell me some good symbols to use in >place of something like 'while' or 'for'? Sure, use angle brackets like TECO does. It wouldn't even conflict with their use as comparison operators...
peter@kitty.UUCP (Peter DaSilva) (08/07/85)
> (from net.lang.c) > p.s. Let's not start an argument about the relative merits of C and APL. > Both have their place in my software toolkit. Sometimes one is more > appropriate, sometimes the other is. Anyone got a public domain APL?