Huh?

Post #55,655 by tablizer 10/8/02 11:40:57 PM Reply	Huh? ________________ oop.ismad.com
Post #55,757 by deSitter 10/9/02 11:59:35 AM Reply	Re: Huh? When C was invented, the most popular languages, COBOL and FORTRAN, were line-oriented. Typically a program would go into the system via a punched card reader. In FORTRAN, you had columns 7 to 72 to scribble in on a keypunch machine. Everyone saw that having to worry about carriage control at the language level was brain-dead. So a delimiter was needed to tell the compiler that a line was concluded. What would you have picked? -drl
Post #57,386 by tablizer 10/17/02 3:53:17 PM Reply	Who is "everyone"? Everyone saw that having to worry about carriage control at the language level was brain-dead. I don't see the problem. I am not the only one who dislikes semicolons. Bertrand Meyer made them optional because of complaints of Eiffel semicolons, for example. Besides, there were other languages around to serve as possible solution ideas. LISP does not need semi's, for example. Just accept the fact that some people don't like semi's. ________________ oop.ismad.com
Post #57,406 by deSitter 10/17/02 5:09:06 PM Reply	Once More With Feeling Everything in UNIX is byte-stream oriented. The compiler chews on a byte stream. Because it was developed as a time-share system with terminals (a radical idea at that time), it uses newlines to format byte-streams for the screen. That's a particular delimiter. The C compiler uses another delimiter in its input stream of code - and GASP! someone had the thought that it would be a GOOD THING if humans could SEE them! The semi-colon is very expressive - stop, but keep going. It's a total, complete, non-issue. -drl
Post #57,751 by tablizer 10/18/02 11:20:43 PM Reply	I don't care about the 1970's, I hate them here and now That is a bunch of bolarky! There are plenty of non-semicolon languages that run just fine on UNIX. If semi's made stuff easier in the 70's, well, this is NOT the 70's. Get modern. I don't like semi's and work faster without the damned things. That is a FACT. If you like them, that is fine, but don't force them down everybody else's throat. ________________ oop.ismad.com
Post #57,775 by static 10/19/02 12:43:55 AM Reply	Simple solution. And that is don't use languages with semi-colons as statement terminators, if it bothers you so much. There's no need (or call) for you to insist that everyone subscribe to your view. I happen to intensely dislike identifiers with a leading underscore, but I can't make everyone stop using them. (Fortunately, it's less of an issue for me in PHP because of the leading $ on all variables.) Wade. "Ah. One of the difficult questions."
Post #57,782 by deSitter 10/19/02 1:54:47 AM Reply	The Galileo of Computing! Sorry. It's really funny to watch you have a stroke over a stupid delimiter. Maybe we should replace it by a new character just for you - the "catastrophe". -drl
Post #58,195 by tablizer 10/22/02 2:32:44 AM Reply	Others complain too It's really funny to watch you have a stroke over a stupid delimiter. That happens to be the topic at hand. If you have Bertrand Meyer's OOSC2 you will see that others have found it problematic also. Page 897 partial quote: "The War of the Semicolon [title]....Two clans inhabit the computer world, and the hatred between them is as ferocious as it is ancient...." It is just one of those annoying things that keep slowing things down. I used Pascal extensively in College, and never did get used to semi's. Perhaps if all the langs I ever used only had semi's, then it would be a natural habit by now. However, I encounter a mix. If one keeps losing their car keys once every 2 weeks, then a combination-based lock starts to look pretty good (like the Nissan Maxima). BTW, some non-semi languages do NOT need VB-style dashes or continuation characters. Python and LISP come to mind. ________________ oop.ismad.com
Post #57,407 by admin 10/17/02 5:12:06 PM Reply	Wrong. Everyone saw that having to worry about carriage control at the language level was brain-dead. No, it isn't. cf. Python Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #57,414 by deSitter 10/17/02 5:34:53 PM Reply	Re: Wrong. We're talking 1970s, FORTRAN, COBOL, etc. Carriage control was heavily device-oriented and record-oriented, because IBM made record-oriented systems. Byte-stream oriented UNIX was really radical. Some of us were around in antediluvian times :) Things change. Here's a history of carraige control: [link\|http://www.ibiblio.org/pub/languages/fortran/ch2-14.html\|http://www.ibiblio.o...rtran/ch2-14.html] -drl
Post #57,487 by ben_tilly 10/18/02 7:25:31 AM Reply	This is a general trend Later-invented systems often find simple solutions to problems that are so bad that earlier systems never considered doing it that way. Byte-oriented UNIX with lines parsed out versus records is one example. Automatic memory management in new languages is a more familiar one today. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #57,418 by hnick 10/17/02 5:41:27 PM Reply	Historical trivia that applies... I seem to recall that the early C compilers actually had a 80 character limit that paralleled a Hollorith card. If you ran over the 80 char line limit, the line was truncated. New compilers have no line limit and span lines without a '\\' for a line break. A delimiter is needed. No question. This works. I would rather a simple syntax, than the tyranny of making everything I code intuitively readable to all potential readers_{mean?average?every bum off the street? WHO?}.
Post #57,465 by a6l6e6x 10/17/02 9:59:49 PM Reply	Nah, not Kernighan and Ritchie. K&R: Blanks, tabs, newlines, and comments (collectively called "white space") as described below are ignored except as they serve to separate tokens. Some white space is required to separate otherwise adjacent identifiers, keywords, and constants. So any C compiler that does otherwise would not be K&R. Alex "I have a truly marvelous demonstration of this proposition which this margin is too narrow to contain. -- Pierre de Fermat (1601-1665)
Post #57,488 by hnick 10/18/02 8:13:04 AM Reply	Right, Not K&R I didn't start using C until 1984 or so, and every compiler I saw was mostly K&R compliant. ISO came later. I was told that a lot of the code I was looking at was written like it was because of the 80 line limitation on the system it came from. I never saw the original system, and the story came to me as probably third hand word-of-mouth. I suppose you can say that if it's not K&R, it's not a C compiler. I suppose that the story could also be bullshit, although I did not pass it on with such knowledge. A lot of the information I possess, I have through informal sources, including this forum. I recalled the story and thought that it pertained to the thread. Sorry about that.. Hugh
Post #57,489 by CRConrad 10/18/02 8:30:21 AM Reply	Don't be. Sorry, I mean.
Post #57,548 by deSitter 10/18/02 12:37:33 PM Reply	Re: Right, Not K&R No, it's very interesting! Even as late as the late 70s, college computing was done on a Forbin Project style 'frame - ours was a Cyber, one of the fastest computers then made. The hapless student/researcher would code up his program on Hollerith cards and present the deck at the I/O window - later a public card reader was available and you could submit your own deck, eat some horrid dry cookies or chips with your 10th Dr. Pepper of the day, and wait for the I/O window troll to deliver your output. General availability of time-share terminals only came in early 80s IIRC. PROFS for VM/CMS (Professional Office System or some such), the GroupWise of its day, had "virtual card readers" and "virtual punch files". GASP! -drl
Post #58,034 by wharris2 10/21/02 12:00:00 PM Reply	Actually, might it have been a "standard" to fit terminals? When I first went to work (in the mid-80's) programming C, it was a "standard" that the code would match a certain format - and, except for long strings (back in those days C compilers didn't append adjacent strings together), it was recommended that we use 80-character lines (at worst) and preferably something like 72 columns, for readability on the Wyse75 terminals we had at the time and, I suppose, the ability to more easily print stuff out on the 80-column line printers we had at the time. If I remember correctly, you could put those Wyse's into 132-column mode, but you'd probably go blind if you did so. And if you went over 80 columns on any particular terminal, you'd have to monkey with termcap/terminal settings, and it seems to me it always seemed to take a lot more effort than it was ever worth. The lawyers would mostly rather be what they are than get out of the way even if the cost was Hammerfall. - Jerry Pournelle

Welcome to IWETHEY!