mwm@cuuxb.UUCP (12/12/86)
In article <649@argus.UUCP> ken@argus.UUCP writes: >Quite a few projects have been designed with Pascal (several compilers >come to mind), and I'm not refering to Turbo Pascal. The C "language" >is such a joke its ridiculous. A local flowerchild here says "You've >got to understand the evolution of the language to use it" in response >to my question as to why there are so many inconsistencies in the language. >When I complain about inconsistencies and bugs in the libraries, I get >"That's not a bug, that's a feature". BULL. It's a bug if the documentation >says it does one thing, and the run does something else. That's like if >the right turn signal on a car activates the left turn light. And then >is all the stupid junk of having to order modules in archives in a certain >fashion. Haven't they heard of a two pass linker? "Old fashioned" Univac >has one that even dynamically links and loads modules as they are needed. > >The Ada standardization group has, among other things, not only defined >the language, but the environment and libraries around it. This is >good because the only way a language can be really portable is if the >language, libraries, and the environment expected are all consistent >and the same. > >REXX is a interpreted language similar to shell on Unix. But instead of >all the crazy junk that looks more like line noise there are well defined >control structures that enable maintainable programs to be written. > >> Strong typing is for weak minds, >Written by someone who wants to ensure job security by writting >code that only he can maintain. And then he maintains it only >if he feels like it, thus achieving a demi-god status. ... >Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 First of all WHY WAS THIS IN SOC.SINGLES?!?!?! If you want to discuss programming languages, do it in comp.lang.misc. I have posted this reply to that group as well, and aimed followups there as well. To those that are tired of this discussion in soc.singles, hit 'n' now... Yes C does not use strong type checking, and *some implementations* use single pass linker for speed. I have never seen a standard C library routine that did not perform as documented. What most people think of as inconsistencys in C are mainly differences between C and other languages. While C does have some inconsistencies which are mildly annoying, they are at worst only a minor inconvenience. Of course, I cannot address what you might be considering as inconsitent, since you didn't give any examples. There are some *derivatives* of Pascal in which large systems have been written, but even Pascal's author, Niklaus Wirth, says it was never intended to be used for anything but a simple introductory language. Your comments on portability are interesting, yet a program that does machine dependant things (such as an operating system kernel) will ALWAYS be machine dependant, no matter how portable the language is. Therefore no language which has constructs powerful enough to get down to the low level and bash bits with the hardware is going to be perfectly portable. Neither C nor Ada nor Modula2 nor <insert your favorite language here> can be portable (in the sense that you can take ANY program and run it ANYwhere) unless it prohibits doing machine-dependant things. The original Pascal definition had this quality, but was also useless for things like writing operating systems. Your poke about strong typing and maintainability is at best inflammatory and in bad taste. I have seen beautiful, easy to read C code, and Pascal that would curl your hair. Bad programmers can program poorly in any language, and good programmers can program well in most. -- Marc Mengel "All that is gold does not glitter ...!ihnp4!cuuxb!mwm Not all those who wander are lost The old that is strong does not whither Deep roots are not reached by the frost" -- J.R.R Tolkein
ken@argus.UUCP (Kenneth Ng) (12/16/86)
In article <973@cuuxb.UUCP>, mwm@cuuxb.UUCP (Marc W. Mengel) writes: > In article <649@argus.UUCP> ken@argus.UUCP writes: [edited comment from soc.singles on C, REXX, Ada] > First of all WHY WAS THIS IN SOC.SINGLES?!?!?! Because it came up in soc.singles in discussion of how to identify nerds, which doesn't belong in THIS group. >Yes C does not use strong type checking, and *some implementations* use single > pass linker for speed. I have never seen a standard C library routine that > did not perform as documented. What most people think of as inconsistencys > in C are mainly differences between C and other languages. While C does have >some inconsistencies which are mildly annoying, they are at worst only a minor >inconvenience. Of course, I cannot address what you might be considering as > inconsitent, since you didn't give any examples. I suspect the bulk of the linkers are one pass. If not, then why must I type in a command with tsort and a few other things in it when I put something into an archive? If you want a couple examples of C library functions doing something different: check out the timeout options on the read() function. Yes I know it is documented in the System 5 Interface Specifications. But it is NOT documented on the manual page, where it belongs. Check out the printf routine when printing hex integers which are supposed to be padded on a Waterloo compiler, it ignores the option. C does have some problems when you move a computation program from one machine to another and you get DIFFERENT results. About the inconsistencies: how about initializing characters with strings but other types with "{}" pairs? How come the maddening left to right, right to left, and partially hierarchical ordering of "*", "++" "+=" and the dozen other terms? I can't recall the exact thing I was asking about, it was over a year ago. I had asked someone who used to work at Bell Labs why part of C was done one way, and something else another. And he said: "You have to understand the order features were added to the language to understand it". I responded: "You mean they tweaked the compiler rather than made a consistent well ordered language." And he responded: "When you come down to it, yes." > > There are some *derivatives* of Pascal in which large systems have been written, > but even Pascal's author, Niklaus Wirth, says it was never intended to be used > for anything but a simple introductory language. > > Your comments on portability are interesting, yet a program that does machine > dependant things (such as an operating system kernel) will ALWAYS be machine > dependant, no matter how portable the language is. Therefore no language > which has constructs powerful enough to get down to the low level and bash > bits with the hardware is going to be perfectly portable. Neither C nor > Ada nor Modula2 nor <insert your favorite language here> can be portable > (in the sense that you can take ANY program and run it ANYwhere) unless it > prohibits doing machine-dependant things. The original Pascal definition > had this quality, but was also useless for things like writing operating > systems. You are missing one of the points of Ada. Ada helps minimize this by providing a consistent environment around it. Thus machine dependencies are somewhat confined to those writing the interface environment, not the ones writing in the application level. I think one of my points was confused. Obviously programs written at the level that actually interfaces with the hardware will be machine dependent. What I complain about is that application programs written on top of them should not have to worry about machine dependencies. > > Your poke about strong typing and maintainability is at best inflammatory > and in bad taste. I have seen beautiful, easy to read C code, and Pascal >that would curl your hair. Bad programmers can program poorly in any language, > and good programmers can program well in most. I haven't seen any haircurling Pascal yet, but I've seen some bad programs written in Pascal. I've also seen some good C code. But I find that helping others debug code written in C code for some reason always takes longer. Granted I've only used C for about 2 years, but I've used Pascal for about the same amount of time. About the poke about maintainability: unfortunately it is true because I know people who DO practice this where they work. I know someone who names his variables after Dutch cities (hardly mneumonic I'd say). I know some people who take PRIDE in writing the most incomprehensible code they can. Granted I also indulge in writing dense code if challenged to wrote "XXX" in the least number of lines. My 15 line Fortran game of life program comes to mind. But I'd never hand that program in for class or work, unless they were asking for the shortest program. > -- > Marc Mengel "All that is gold does not glitter > ...!ihnp4!cuuxb!mwm Not all those who wander are lost > The old that is strong does not whither > Deep roots are not reached by the frost" > -- J.R.R Tolkein -- Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** WARNING: NOT ken@bellcore.uucp *** !psuvax1!cmcl2!ciap!andromeda!argus!ken bitnet(prefered) ken@orion.bitnet Gillian: "Are you sure you won't change your mind?" Spock: "What's wrong with the one I have?"
bills@cca.CCA.COM (Bill Stackhouse) (01/07/87)
Poking and bashing bits are a weak excuse for using a low level language even in an op. system. Even if you never want to port a program, you should still use a HLL. For examples of HLLs in OP SYS, just look at the Buroughs large systems. In the newer versions of the languages used, they added systax so that a programmer could declare that they were about to do something that was machine dependent. They even had some conditional syntax so that you could say this is machine dependent and only for a certian machine which was specified during the compile. At least then you have some chance of locating what needs to change when moving between incompatible machines. -- Bill Stackhouse Cambridge, MA. bills@cca.cca.com