oconnordm@CRD.GE.COM (Dennis M. O'Connor) (02/23/90)
mike@cs (Mike Coffin) writes:
] The fact that Unix seems to be taking over the
] world certainly seems to give C and C++ a *big* leg up.
] Not only are all the Unix tools built for, and based on, C,
Which is probably irrelevant, given that plenty of CASE
environments for Ada exist for UNIX ...
Saying that UNIX somehow leads to favors programming in C is like saying
that CISC architectures leads to programming in microcode.
] but the operating system itself is optimized for running C programs.
If we allow that UNIX is optimized for anything ;-), just what
are these C-specific optimizations that favor C and C++ over Ada ?
] Given that many contracts in the future will specify Unix, there will
] be a considerable tendency to also specify C or C++.
Sorry, I disagree. Operating systems provide a "virtual machine"
for the applications programs to execute on; compilers provide
a "virtual machine" for the programmer to write programs for.
An operating system that is only able to efficiently support one
language or one family of languages is an inadequate operating system :
Assumption : there is no one language that is appropriate
( much less best ) for authoring solutions to all problems.
[e.g. try an inference engine in C or Ada, or a real-time
embedded system in Prolog, or an interupt handler in a 4GL ]
Conclusion : an operating system incapable of adequate support
for a broad spectrum of languages does not adequately
support a broad spectrum of applications, and is not a wise
choice as a general-purpose operating system.
Does UNIX fit this description ? I don't dare venture an opinion ;-)
--
Dennis O'Connor OCONNORDM@CRD.GE.COM UUNET!CRD.GE.COM!OCONNOR
"Let's take a little off the top ... a bit off the sides ...
trim the back a bit ... Surprise ! You've been bald-ed !"barmar@think.com (Barry Margolin) (02/23/90)
In article <5476@crdgw1.crd.ge.com> oconnordm@CRD.GE.COM (Dennis M. O'Connor) writes: >mike@cs (Mike Coffin) writes: >] but the operating system itself is optimized for running C programs. >If we allow that UNIX is optimized for anything ;-), just what >are these C-specific optimizations that favor C and C++ over Ada ? The most obvious way in which a particular OS is oriented towards a particular language is when it comes to data being passed between application programs and OS routines. Unix kernel routines and system library routines expect things like null-terminated strings and structures laid out the way that system's C compiler lays them. Programs written in other languages often need to transform data when passing it into and out of the OS. Another area of language bias is documentation. Unix manual pages for subroutines generally describe the invocation mechanism and argument types in C syntax. Ada representation clauses may be useful for solving some parts of the first problem, but such programs are not portable. Further, the manual pages are written portably, so they don't describe argument representation. In order to write the rep spec for a structure being passed to a system routine you would have to go through the C compiler documentation and find out how it lays out structures (hopefully this is documented). These problems aren't as bad so long as programs stick to OS-independent libraries, such as stdio for C and the standard packages that Ada provides. However, the data transformation overhead is still there, buried inside the library implementation. >Sorry, I disagree. Operating systems provide a "virtual machine" >for the applications programs to execute on; compilers provide >a "virtual machine" for the programmer to write programs for. But there's opportunities to optimize when the two virtual machines have similarities. For instance, both the Unix VM and the C VM share the same string abstraction, so it is never necessary to convert C strings to Unix strings. >An operating system that is only able to efficiently support one >language or one family of languages is an inadequate operating system : Unfortunately, many OSes are inadequate. The Mac OS is Pascal-oriented, Unix is C-oriented, Genera (the OS on Symbolics Lisp Machines) is Lisp-oriented, Multics is PL/I-oriented, etc. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
Loren@cup.portal.com (Loren Louis Hart) (02/24/90)
In an article posted by barmar@think.com on this topic >In article <5476@crdgw1.crd.ge.com> oconnordm@CRD.GE.COM (Dennis M. O'Connor) w >rites: >>mike@cs (Mike Coffin) writes: >>] but the operating system itself is optimized for running C programs. >>If we allow that UNIX is optimized for anything ;-), just what >>are these C-specific optimizations that favor C and C++ over Ada ? > >The most obvious way in which a particular OS is oriented towards a >particular language is when it comes to data being passed between >application programs and OS routines. Unix kernel routines and system >library routines expect things like null-terminated strings and structures >laid out the way that system's C compiler lays them. Programs written in >other languages often need to transform data when passing it into and out >of the OS. I would say that things like null terminators and other system representations are implementation issues of the compiler, particularly with respect to Ada. Having written the Unix system interface for an Ada database, I would have to say that the Verdix compiler's implementation is superior. Ada allows for the implementation to deal with terminating strings and other such platform specific issues. I found that the Verdix Ada compiler provided all the necessary capabilites to write an effective, reliable, and efficient Unix Interface. >Another area of language bias is documentation. Unix manual pages for >subroutines generally describe the invocation mechanism and argument types >in C syntax. In our case it was helpful to know some C to write the OS interface; however since our project, Verdix has written and provided the text of the Ada package specifications for many of the unix system calls. I often find these Ada package specifications clearer than the unix manuals on issues of types and parameter passing mechanisms. >Ada representation clauses may be useful for solving some parts of the >first problem, but such programs are not portable. Further, the manual >pages are written portably, so they don't describe argument representation. >In order to write the rep spec for a structure being passed to a system >routine you would have to go through the C compiler documentation and find >out how it lays out structures (hopefully this is documented). >These problems aren't as bad so long as programs stick to OS-independent >libraries, such as stdio for C and the standard packages that Ada provides. >However, the data transformation overhead is still there, buried inside the >library implementation. Again, given the right choice of compiler in a given instance, what little data transformation overhead is negligable by comparison to the inherent cost of a system call. >>Sorry, I disagree. Operating systems provide a "virtual machine" >>for the applications programs to execute on; compilers provide >>a "virtual machine" for the programmer to write programs for. >But there's opportunities to optimize when the two virtual machines have >similarities. For instance, both the Unix VM and the C VM share the same >string abstraction, so it is never necessary to convert C strings to Unix >strings. Again with the Verdix implementatio, their strings are null terminated and there is never a need to convert them. >>An operating system that is only able to efficiently support one >>language or one family of languages is an inadequate operating system : >Unfortunately, many OSes are inadequate. The Mac OS is Pascal-oriented, >Unix is C-oriented, Genera (the OS on Symbolics Lisp Machines) is >Lisp-oriented, Multics is PL/I-oriented, etc. Again I argue that a proper implementation of an Ada compiler should be in line with the platform it runs on. A platform for a compiler includes not only the particular CPU, but the OS as well. I will admit that there are some special purpose operating systems that make these kinds of adaptations next to impossible, but I would not put Unix into this category! -- Loren L. Hart loren@cup.portal.com San Jose, California
kassover@jupiter.crd.ge.com (David Kassover) (02/26/90)
In article <34196@news.Think.COM> barmar@think.com (Barry Margolin) writes: ... >The most obvious way in which a particular OS is oriented towards a >particular language is when it comes to data being passed between >application programs and OS routines. Unix kernel routines and system >library routines expect things like null-terminated strings and structures >laid out the way that system's C compiler lays them. Programs written in >other languages often need to transform data when passing it into and out >of the OS. > >Another area of language bias is documentation. Unix manual pages for >subroutines generally describe the invocation mechanism and argument types >in C syntax. > ... C and Unix go together because they were implemented together, the C language to make the writing of the OS (which, after all, is just another computer program) easier. Using standard libraries (all that means is that *someone else* has implemented the interface from particular hardware to the language specification (Go ahead, flame. I know that's simplistic)). If one is writing a truly embedded system, then it's easy to fulfill the requirements of the Requirements and Functional specifications (assuming you have them...). On the other hand, if you're trying to implement a software system where there are specific (or specified) desires to take advantage of a particular platform feature, or that is intented to by interacted with by humans, you have to start getting into language extensions or hardware features, etc. Back to Ada vs. C. Ada, as specified, does a rather complete job of eliminating bugs caused by single character typos. (Ref the DO statement problem) One which it will not catch is that case where two variables whose names differ by one character are both declared in the same scope. C, on the other hand, does still have cases where the placement of a semicolon in the wrong place will alter the meaning of a program without having a failed compile (Yes, I know Lint can ask about things like this. I know some compilers warn about assumptions they are making. ANyone out there ever use PL/C?).
jnixon@andrew.ATL.GE.COM (John F Nixon) (02/26/90)
kassover@jupiter.crd.ge.com (David Kassover) writes: >Back to Ada vs. C. Ada, as specified, does a rather complete job ^ >of eliminating bugs caused by single character typos. (Ref the >DO statement problem) Sorry, you must be thinking of FORTRAN (e.g., DO 100 I = 1.10), not C. If c.l.a is going to be comparing languages, let's get them right. -- ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion
kassover@jupiter.crd.ge.com (David Kassover) (02/27/90)
In article <204@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes: >Sorry, you must be thinking of FORTRAN (e.g., DO 100 I = 1.10), not C. >If c.l.a is going to be comparing languages, let's get them right. > No need to apologize, I *was* thinking of FORTRAN, specifically that example, since we discussed it in particular. But it is possible to make single character mistakes in C. Just as bad, you can make single word mistakes in C, since there are cases where things like semicolons and breaks are optional. (Unless I misunderstand, or those options have been eliminated since I read K&R. If so, I apologise) Or even worse, I think, is the use of {} for many different kinds of block statements. In Ada I end a loop with end loop; I end an if with end if; In C, both of these things are delimited by {}. Can anyone out there honestly say he's never got his braces tangled? 8-) (That's a pun, by the way) FORTRAN is even worse: DO 100 I=1,10 DO 100 J=1,10 . . . 100 CONTINUE . . . GOTO 100 At least VAX FORTRAN provides an ENDDO and a DO WHILE
jnixon@andrew.ATL.GE.COM (John F Nixon) (02/27/90)
kassover@jupiter.crd.ge.com (David Kassover) writes: >No need to apologize, I *was* thinking of FORTRAN, specifically >that example, since we discussed it in particular. Whoops, I though you were talking about C. >But it is possible to make single character mistakes in C. It is possible to make single character mistakes in Ada. Suppose I have a loop named MISSLE_A and a loop (interior to MISSLE_A) named MISSLE_B. I can "exit" a named loop, and screw up the name. Admittedly a contrived example, but the principle extends to anything with a name (identifiers, types, ...). Nothing in *Ada* prevents this, only the discipline of the software developer. C does have several built in traps (= vs. ==), but there are ways of dealing with these problems at the developer level. ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion
kassover@control.crd.ge.com (David Kassover) (02/27/90)
In article <209@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes: >It is possible to make single character mistakes in Ada. ... I thought I said that. I thought I gave an example analogous to yours, involving quantites declared by the programmer with one character differences. We often do this kind of thing because we don't want to type stuff like in COBOL programs where everything with less than 3 _'s is a reserved word. It's difficult to avoid when it is necessary to type an explicit index into an array, so as to specifically distinguish x(1) from x(2). (it is impractical to avoid *all* litterals) My personal preference for Ada over C has to do with the fact that when I must write (or FIX) a program, the less time I spend avoiding traps rather than doing my work, the better. Also, personally, I have a hard time reading one-line wonders, especially other people's. It's harder to create such in Ada, therefore I see less of them.
epstein@trwacs.UUCP (Jeremy Epstein) (02/28/90)
[I promised myself I wouldn't join this grudge match, but...] In article <5563@crdgw1.crd.ge.com>, kassover@jupiter.crd.ge.com (David Kassover) writes: > In article <204@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes: > Or even worse, I think, is the use of {} for many different kinds > of block statements. In Ada I end a loop with end loop; I end > an if with end if; While that's certainly true, look at how Ada overloads symbols. For example, parentheses are used for parameters as well as subscripts (that's something that totally confuses me as an old-time C programmer). And while we're on the subject of Ada "end", why is it that Ada sometimes uses "end" to match "begin", and other times to match other keywords? -- Jeremy Epstein epstein@trwacs.uu.net TRW Systems Division 703-876-4202
blakemor@software.org (Alex Blakemore) (02/28/90)
In article <184@trwacs.UUCP> epstein@trwacs.UUCP (Jeremy Epstein) writes: > ... look at how Ada overloads symbols. For > example, parentheses are used for parameters as well as subscripts > (that's something that totally confuses me as an old-time C programmer). This is a strength of Ada not an inconsistency. This way you can change between using an array and a function to provide some info - for example the text sin(x) refers to some real value. sin could be a constant array or a function (a time/space tradeoff) - only the providing package need know. You can change your mind in one place and need only recompile. Provided you avoid named parameter association in this case. This is consistent with some formal proof methods (like Tony Hoare's) which treat array references as function calls. Logically they have the same effect. Mathematically a function is essentially a table anyway. Of course, there is a difference when you assign to an array element. The same syntactic overloading lets you reference a constant, variable or parameterless function using the exact same syntax. One safe way to have read only global variables is to define a visible (spec level) function that returns the current value, but hide the variable inside the package body - so only trusted operations can update it. Again, why should the code making the reference need to know how it is resolved- that is between the owning package and the compiler? C has some elegance but why should the programmer have to remember when to use [] or () ? just to make the compiler easier to write ? -- ------------------------------------------------------------------------- Alex Blakemore blakemore@software.org (703) 742-7125 Software Productivity Consortium 2214 Rock Hill Road Herndon, VA 22070 ------------------------ Eschew Obfuscation !!! -----------------------
defaria@hpclapd.HP.COM (Andy DeFaria) (03/01/90)
>/ hpclapd:comp.lang.ada / epstein@trwacs.UUCP (Jeremy Epstein) / 10:55 am Feb 27, 1990 / >[I promised myself I wouldn't join this grudge match, but...] >While that's certainly true, look at how Ada overloads symbols. For >example, parentheses are used for parameters as well as subscripts >(that's something that totally confuses me as an old-time C programmer). Why does C insist on differentiating between "=" meaning assignment and "=" meaning equality test. People naturally write "A = B" and "if A = B...". Based on the context the compiler should be able to figure out whether the "=" sign refers to assignment or equality test. I know that C allows you to do the assignment and then check the value of the assignment and that this is often useful but it is IMO something that totally confuses me as a novice C programmer. >And while we're on the subject of Ada "end", why is it that Ada sometimes >uses "end" to match "begin", and other times to match other keywords? I looks like you need a little look-ahead. Ada matches a "end" with a "begin" but matches an "end if" with an "if" ("end case" with "case", "end loop" with "loop", etc).
kassover@control.crd.ge.com (David Kassover) (03/01/90)
In article <184@trwacs.UUCP> epstein@trwacs.UUCP (Jeremy Epstein) writes: >[I promised myself I wouldn't join this grudge match, but...] > >In article <5563@crdgw1.crd.ge.com>, kassover@jupiter.crd.ge.com (David Kassover) writes: >> In article <204@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes: >> Or even worse, I think, is the use of {} for many different kinds >> of block statements. In Ada I end a loop with end loop; I end >> an if with end if; > >While that's certainly true, look at how Ada overloads symbols. For >example, parentheses are used for parameters as well as subscripts Sigh. I promised myself I would stop. Oh, well. C is the first language (no, wait a minute, I've repressed Basic. I think. I can't remember...) I encountered that used [ ] for subscripts. Not to mention a doubly dimensioned array using the notation [][] (which *really* screwed me up once, because the comma is an operator and the syntax x [a,b] is perfectly legal, even when x is declared [i] [j]) In ada, pointers are pointers and arrays are arrays, and never the twain will share syntax. In Fortran, there is really very little to distinguish a function call from an array reference. In fact, I submit that from the standpoint of examining a program that contains a statement such as A = F (i,j,k) it really doesn't matter whether a simple memory transfer or a complex subprogram execution is called for. What can screw you up here is a "SIDE EFFECT", which Ada flatly refuses to allow. (Has anyone out there *never* done something like: A = F(1) where F was a function that caused a side effect that changed *all* literal 1's to 3.14159265's (or whatever integer those bits happened to represent? What, not never?) And while we're on the subject of side effects, the C treatment of assignment as a function that returns a value, with the side effect of making the assignment has balled me up more than once. Especially when I tried to get too cute with fancy one-line wonder macros that expanded in grand and glorious unanticipated ways... Jeremy also mentions that in Ada the word end is used as a closure for begin, and also as a closure for loop, and also as a closure for if... End all by itself ends begin. End loop ends a loop, and if you try to make it end an if, the compiler will complain. If you want to end an if, you must use end if; If you want to end a named loop, you must use an end loop AND reference the name of the named loop. End all by itself, without a matching begin, will cause a complaint from the compiler. This is a lot different from } ending the last unmatched {.
tynor@prism.gatech.EDU (Steve Tynor) (03/01/90)
In article <5638@crdgw1.crd.ge.com> kassover@control.crd.ge.com (David Kassover) writes: >complex subprogram execution is called for. What can screw you >up here is a "SIDE EFFECT", which Ada flatly refuses to allow. It's perfectly legal to write functions with side effects in Ada - there's no restriction on what happens in the function's body - the only restriction Ada makes is that a function's _parameters_ must not be affected (hence `in' only). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= inherit STD_DISCLAIMER; -- Insist on Eiffel! Steve Tynor Georgia Tech Research Institute Artificial Intelligence Branch tynor@prism.gatech.edu
kassover@jupiter.crd.ge.com (David Kassover) (03/02/90)
In article <6553@hydra.gatech.EDU> tynor@prism.gatech.EDU (Steve Tynor) writes: >In article <5638@crdgw1.crd.ge.com> kassover@control.crd.ge.com (David Kassover) writes: >>complex subprogram execution is called for. What can screw you >>up here is a "SIDE EFFECT", which Ada flatly refuses to allow. > It should be obvious by now that what I was referring to as a SIDE EFFECT was the changing of the values of parameters of functions, that is, a PARAMETER that gets changed incidentally to the generation of the return value. This is how I have always understood the term to be meant, as mentioned in K&R and K&P.
rdh@sli.com (Robert D. Houk) (03/02/90)
In article <5563@crdgw1.crd.ge.com> kassover@jupiter.crd.ge.com (David Kassover) writes:
Or even worse, I think, is the use of {} for many different kinds
of block statements. In Ada I end a loop with end loop; I end
an if with end if;
In C, both of these things are delimited by {}. Can anyone out
there honestly say he's never got his braces tangled? 8-)
(That's a pun, by the way)
Yeah, I've tangled up {}'s in C proggies. I've also put in lots of
"endif"s and just plain "end"s in Ada. And I've left ";"s out of both.
Overall, I prefer {}'s simply because they emphasize or make code blocks
stand out better when perusing the listing (to my way of thinking anyways)
[i.e., I look at "end if;" and want to see a meaningful source statement
at the same code-level as the originating "if" clause, not a tail-end of
something earlier. I don't know if that makes sense to anyone, but that's
the way I think...]
-RDH
--
"If you build a system RDH@SLI.COM | uunet!sli!rdh
that even a fool could use, Robert D. Houk
then only a fool Software Leverage, Inc.
would want to use your system." 485 Massachusetts Avenue
-Somebody-r-Other's Law Arlington, Mass. 02174
Office (617) 648-1414RCAPENER@cc.utah.edu (03/15/90)
In article <598@software.software.org>, blakemor@software.org (Alex Blakemore writes: > > C has some elegance but why should the programmer have to remember > when to use [] or () ? just to make the compiler easier to write ? > Well, heck, I thought it was because we wanted to distinguish arrays from other constructs. (8-) If you want to talk about making a compiler easier to write, how about those semicolons in PASCAL? Obviously, it has created so much consternation and problems that Borland allows lots of slack on where you can put the consarned things! Then there is Ada. Damn the torpedos, full speed ahead in writing a language that is so big that in rivals Common LISP in size, and the writing of a compiler for it is one of the major undertakings of the past decade. Is there REALLY a full-featured Ada compiler out there that has all the features that it is supposed to have? Using friends' account Mail flames to: dharvey@wsccs.weber.edu