Is C/C++ the dominant teaching language?
Jay Martin
>On 11 Oct 95, he then wrote:
> From what I have seen most major research universities have/are
> abandoning all operating systems and languages except Unix and C/C++
> (except maybe some useless theoretic masturbatorial crap).
>Coincidentally, I just stumbled over the "FIRST-COURSE LANGUAGE FOR
>COMPUTER SCIENCE MAJORS" list, which is maintained by Dick Reid and
>available at ftp.cps.msu.edu:pub/arch/CS1_Language_List.Z. This list
>surveys the languages used in the first course for Computer Science
>majors.
>The current (13th) edition lists 442 institutions. It turns out that
>only 39 of those institutions use C as the first language, and 34 C++.
>Pascal, on the other hand, is used by more than twice as many
>institutions as C and C++ combined!
>Here is a summary by language:
> Pascal: 157 institutions
> Ada: 73 institutions
> Scheme: 50 institutions
> C: 39 institutions
> Modula: 35 institutions
> C++: 34 institutions
> Modula-2: 13 institutions
> Fortran: 8 institutions
> Turing: 6 institutions
> SML: 6 institutions
> Miranda: 4 institutions
> Eiffel: 3 institutions
> Modula-3: 2 institutions
> Oberon: 2 institutions
> ISETL: 2 institutions
> ObjPascal: 1 institution
> ML: 1 institution
> Smalltalk: 1 institution
> Beta: 1 institution
> Prolog: 1 institution
> Simula: 1 institution
> Haskell: 1 institution
> Orwell: 1 institution
> Total: 442 institutions
What language is used for first class is not as important as
which languages are used in the core classes and which languages
are used in research. If you take your list and sort by
the top 40 US CS departments, you get:
01 C Stanford University
02 Scheme Massachusetts Institute of Technology
03 Scheme University of California, Berkeley
04 C Carnegie Mellon University
05 Pascal Cornell
06 Scheme Princeton University
07 Pascal University of Texas, Austin
08 Scheme University of Illinois
09 C University of Washington
10 Pascal/C University of Wisconsin, Madison (2/3-term Pascal, 1/3-term C)
11 C Harvard (Intro I, CS50).
12 C Cal Tech (CS1)
13 ObjPascal Brown University
14 C++ University of California, Los Angeles
15 Scheme Yale University
16 Pascal University of Maryland, College Park
17 Pascal New York University
18 Pascal University of Massachusetts Amherst
19 Scheme Rice University (C last half)
20 C University of Southern California
21 C University of Michigan (1/4 Pascal, then C)
22 Scheme Columbia University
23 Pascal University of California, San Diego
24 Scheme University of Chicago
25 Pascal University of Pennsylvania
26 C++ Purdue University
27 Pascal Rutgers University
28 Pascal University of North Carolina, Chapel Hill
29 ????? University of Rochester
30 Modula-3 State University of New York, Stony Brook (CS1)
31 Pascal Georgia Tech
32 Pascal University of Arizona
33 Pascal University of California, Irvine
34 C++ University of Virginia
35 Scheme Indiana University
36 Scheme Johns Hopkins
37 Scheme Northwestern University
38 Modula Ohio State
39 Pascal University of Colorado, Colorado Springs
40 Scheme University of Utah
Look mom no Ada and little Modula*!
First, Pascal is a ancient joke, you can't really do anything real in
it today and in my opinion those schools that teach it are too
bleeping lazy to change CS1 to a practical language. (My
undergraduate institution UCI said they were going to convert to Ada,
that was 10+ years ago) Pascal's antiquated design makes wonderful
fodder for C programmers to ridicule pascal style languages ({} vs
begin/end, etc). Its a temporary language which quickly gets switched
to the real "core" language. This is most likely to be C/C++.
Scheme is also a theoretic joke. Its for those computer scientists
who think programming is non-scientific vomit and want to shoe-horn
all the pathetic programming "CONCEPTS OF COMPUTER SCIENCE" into a
single quarter so they won't have to teach it very often. (They don't
care that they have 4-5 years to teach programming/software
engineering...). Thus, Scheme is also a temporary concepts language
(which like Pascal through its worthlessness promotes the conversion
of students into C biggots). Depts like Berkeley and UCLA quickly
switch to C in the second class (CS2) and basically use C for the
rest of the way (UCLA has now killed Scheme for the first class and
teaches only C++).
So basically for most universities in the above list, you can just change
Pascal => Pascal/C and Scheme => Scheme/C. C is thus around 100%.
From what I have seen in research, Unix/C/C++ almost completely
dominatates most software oriented parts of computer science like
operating systems, etc.
Jay.
Carsten Whimster
Marc Najork <naj...@pa.dec.com> wrote:
| A while ago (on 28 Sep 95), Jay Martin <jma...@cs.ucla.edu> wrote:
|
| What do you think the #1 Computer Science Dept. in the US
| teaches, not Ada or Modula* but C! This proves that C is 100X
| better than Ada! What does the rest of Computer Science use for doing
| research?: C and Unix!
| [... arguments extolling the virtues of C/C++ ...]
|
| A few days later (on 3 Oct 95), he disclaimed his previous posting:
|
| So for you out there who "don't get it" won't blow anymore fuses,
| my previous post was a parody, a joke.
|
|
| On 11 Oct 95, he then wrote:
|
| From what I have seen most major research universities have/are
| abandoning all operating systems and languages except Unix and C/C++
| (except maybe some useless theoretic masturbatorial crap).
|
|
| crap", but the statement that most major research universities use C or C++
| seems nonsense anyways.
|
| Coincidentally, I just stumbled over the "FIRST-COURSE LANGUAGE FOR
| COMPUTER SCIENCE MAJORS" list, which is maintained by Dick Reid and
| available at ftp.cps.msu.edu:pub/arch/CS1_Language_List.Z. This list
| surveys the languages used in the first course for Computer Science
| majors.
|
| The current (13th) edition lists 442 institutions. It turns out that
| only 39 of those institutions use C as the first language, and 34 C++.
| Pascal, on the other hand, is used by more than twice as many
| institutions as C and C++ combined!
|
| Here is a summary by language:
|
| Pascal: 157 institutions
Make that 158. All math and CS students at University of Waterloo,
Ontario, Canada see Pascal as the first language that they learn here.
| Ada: 73 institutions
| Scheme: 50 institutions
| C: 39 institutions
| Modula: 35 institutions
| C++: 34 institutions
| Modula-2: 13 institutions
| Fortran: 8 institutions
| Turing: 6 institutions
| SML: 6 institutions
| Miranda: 4 institutions
| Eiffel: 3 institutions
| Modula-3: 2 institutions
| Oberon: 2 institutions
| ISETL: 2 institutions
| ObjPascal: 1 institution
| ML: 1 institution
| Smalltalk: 1 institution
| Beta: 1 institution
| Prolog: 1 institution
| Simula: 1 institution
| Haskell: 1 institution
| Orwell: 1 institution
--
-------------------------------------------------------------
Carsten Whimster CS241 Tutor MC1021 x6657 cs241@cayley
-------------------------------------------------------------
Jay Martin
experience, UC Berkeley seems to have pumped out tons of C fanatics.
I quized with something like: "You know that C's language design is
somewhat less than perfect?". Him: "Huh?" Me:"Well what did they say
in your programming language course?". Him:"What programming language
course?". UC Berkeley CS degree does not require a course on
programming languages! (what I piece of $#^%~!) According to him,
most of the upper courses required little projects all written in C!
No wonder UCB grads worship C, they have never studied anything else!
With UCB (and "we teach C" Stanford) pumping these guys into the
influential Silcon Valley/Bay Area, its basically spells out doom for
alternate languages like Ada, Modula*, Eiffel, etc.
Michael Feldman
Rick Sutcliffe <rs...@twu.ca> wrote:
>In article <951017173...@bismol.pa.dec.com>, naj...@pa.dec.com (Marc
>Najork) wrote:
>> Here is a summary by language:
>> Pascal: 157 institutions
>> Ada: 73 institutions
>> Scheme: 50 institutions
>> C: 39 institutions
>> Modula: 35 institutions
>> C++: 34 institutions
>> Modula-2: 13 institutions
>> Fortran: 8 institutions
>> Turing: 6 institutions
>It seems evident that the listing of Modula and Modula-2 ought to be
>combined as the first clearly should be the second, making a total of 48
>for this language.
>
This list is just quoting data from the Reid Report, in which Richard
Reid of Michigan State (re...@cps.msu.edu) tracks languages used in the
intro course (to the extent that people report such to him).
Dick reports only what people tell him. If a school said it's using
Modula, he reports Modula. In his shoes, I'd do the same.:-)
My guess is that he is preparing a new release of the report, which he
posts several times a year to comp.edu. He takes only first-hand
information, so if you have anything to report, you should do so now.
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfel...@seas.gwu.edu (Internet)
------------------------------------------------------------------------
Fight FUD with Fact
------------------------------------------------------------------------
Ada on the WWW: http://lglwww.epfl.ch/Ada/ or http://info.acm.org/sigada/
------------------------------------------------------------------------
Anthony W. Becker
jma...@cs.ucla.edu (Jay Martin) wrote:
>>Coincidentally, I just stumbled over the "FIRST-COURSE LANGUAGE FOR
>>COMPUTER SCIENCE MAJORS" list, which is maintained by Dick Reid and
>>available at ftp.cps.msu.edu:pub/arch/CS1_Language_List.Z. This list
>>surveys the languages used in the first course for Computer Science
>>majors.
[...]
>What language is used for first class is not as important as
>which languages are used in the core classes and which languages
>are used in research. If you take your list and sort by
>the top 40 US CS departments, you get:
[...]
>37 Scheme Northwestern University
Not to be a nitpicker, but there are two equivalent intro-to-programming
sequences at NU, so this list is a little oversimplified. (I'm sure the same
is true for some of the other institutions on the list.) I am taking the
c/c++ sequence, A10 and B30. There is also A11/B11, which teaches using
Scheme and C++. To my knowledge, as far a operating systems, everybody's
encouraged to use whatever they want. The labs have DOS and UNIX compilers,
and I did my programming on a Mac actually, under CodeWarrior Version 5.
-Tony
______________
Anthony W. Becker "If we wish not to go backwards,
CAS Computer Science we must run."
sho...@nwu.edu -Pelagius
708.332.9179
Jonas J. Schlein
|> research simply because of its popularity! If you are
|> doing research on Concurrency, I bet you would rather use
|> Ada or Scheme. Try Multi-Tasking in C/C++!. On the otherhand,
|> if you are trying to build an operating system, don't be
|> silly...stick with C.
What do you call UNIX? Sure looks awful C like to me and does multi-tasking
just fine...Also I'm just starting to learn a parallel processing language
called MPL which is almost 100% ANSI C with some neat extensions. The compiler
is even made by the FSF.
If you're doing research you're probably less concerned with langauges and
more concerned with algorithms for getting the job done. I could be wrong
on this not being a researcher myself...
--
"If it wasn't for C, we would be using BASI, PASAL, and OBOL."
Jonas J. Schlein (sch...@gl.umbc.edu)
Robert Dewar
research simply because of its popularity! If you are
doing research on Concurrency, I bet you would rather use
Ada or Scheme. Try Multi-Tasking in C/C++!. On the otherhand,
if you are trying to build an operating system, don't be
silly...stick with C."
Naivety strikes again :-)
I am sorry to say that at least in Universities, researchers most definitely
*do* use a language simply because of its popularity. They may to be fair
have some reasons for doing so:
A popoular language may have more tools
A popular language may have free compilers to play with
They may have learned this popular language in school
There are MANY MANY people doing research on concurency who simply
don't know Ada (but are sure it is junk).
I find the last thought, that it is obvious to do an OS in C, to be
an entertaining self-referential statement along these lines. Why would
one only consider C to do an OS, could it possibly have something to
do with tradition and popularity? :-) :-)
It is of course perfectly reasonable and technically possible to write
an operating system in Ada-95, and indeed Ada seems a far better language
for such a project in C. Any of the low level stuff you can do in C,
you can do in Ada 95, often more easily (e.g. record rep clauses to
layout data explicitly), and certainly more clearly!
Michael Feldman
>I am sorry to say that at least in Universities, researchers most definitely
>*do* use a language simply because of its popularity. They may to be fair
>have some reasons for doing so:
>A popoular language may have more tools
>A popular language may have free compilers to play with
>They may have learned this popular language in school
How true. They may also be blithely unconcerned with choosing the
"right" language, rather they'll just pick the one they know, thinking
it'll get the job done just as well.
>There are MANY MANY people doing research on concurency who simply
>don't know Ada (but are sure it is junk).
One hopes this will change with the availability of GNAT. To be fair to
the researchers, they have built zillions of big and small C extensions
and dialects, because the C compilers, preprocessor, etc., were there
in source form for them to hack on. For this we can thank other nicely
funded efforts, such as those at AT&T and Berkeley (the latter funded
largely by ARPA).
An example of this is Concurrent C, which was done by Gehani and friends
at Bell Labs, in around 1986. This glued an extended and (IMHO) improved
Ada tasking model onto C, and was implemented as a preprocessor. Their
AT&T "religious" connections aside, all the tools were there to make
this development easy. Later they turned the preprocessor into a
compiler, presumably using some C compiler as a baseline on which to build.
Indeed, C++ started this way too, as a preprocessed "C with classes"
at Bell Labs, that later turned into a compiler.:-)
For reasons having (IMHO) mostly to do with DoD myopia, nothing
comparable was funded to completion for Ada in the early/mid 80's.
There was Ada/Ed, but this was not intended as a true compiler.
The true compilers were ALS and AIE, but these were contracted as
full-bore, industrial-strength things that turned out to be disasters
and were in any case overtaken by vents by the time they were delivered.
I saw a _reliable_ estimate of $125 million that went into the ALS
sinkhole before it eas finally cancelled.
The only thing remotely comparable to the C research compilers was
Arcturus, part of the Arcadia project at UC Irvine in the early 80's.
As I recall, this was ARPA-funded but (apparently) the funding for
it was cut off shortly before it would have been viable. I have never
been able to find out just why it was snuffed out, but have heard hints
that the decision was political (ARPA's priorities changed).
The sources for the early Pascal and Modula compilers were given away (or
sold for a pittance), and this helped stimulate research in those areas,
as well as fostering commercial implementations that could use the
freebies at least indirectly as "reference implementations".
I did not follow the early Pascal stuff, but knew of several Modula-2
houses who started their commercial compilers by purchasing Wirth's
original sources.
So now, with Ada 95, we have GNAT, and thank heavens for that.
Now researchers have an honest-to-goodness, nearly-validated,
multi-host, multi-target Ada 95 compiler to hack on.:-)
Mike Feldman
Roy Wilmhoff
>More fun talking to a UC Berkeley CS graduate today. In my ...
I don't teach. I've been programming in the embedded real-time area
since, literally, before most current college students were born. So
I have no idea what is being taught in schools. And, IMHO, knowledge
of a particular language is usually a prerequisiter for a programming
job.
These are the languages that I would look to see on a resume.
In my shop we use C and VisualBasic. There is still a need for Fortran
in places which are heavily Math intensive. ADA is used within the
defense related community. C++ is used extensively, although it is
just begining to be considered in the embedded arena. COBOL is not yet
dead within the DP industry. There is a limited need for ASM at the
hardware/driver level (usually an engineering application not CS). And
thats really about it for commercially useable languages.
My most marketable (embeded real-time) language skill is C.
--
Roy_Wi...@Milacron.com
Any opinions in this posting are my own and not those of my present
or previous employers.
Michael Feldman
Peter Moylan <pe...@tesla.newcastle.edu.au> wrote:
>This summary needs one slight correction. The language "Modula"
>is obsolete, and I doubt that anyone is using it. Almost
>certainly all the responses saying "Modula" were referring to
>Modula-2. In other words, the Modula and Modula-2 figures
>refer to the same language, and should be added together.
That is for Dick Reid to decide. He has just published a new
edition on comp.edu. I will not bother to cross-post it here,
as you can read it there. "Modula" is still given there. Dick
reports the information people send him, and probably has
neither time nor inclination to track down the "Modula"
places and ask them. I suggest you write to Dick.
>Somebody else pointed out that you get a different picture if
>you look at the "top universities". The catch here is that only
>US universities were mentioned. One very clear point that comes
>out of the list is that Modula-2 is very popular outside the
>US, but that US institutions seem to favour C/C++.
Some do. Maybe someone can take the new list and sort it by
country.
We do need to be careful not to lie with statistics. This list
may well be biased, as it lists those institutions have faculty
or students who are actibve on the net, and read comp.edu or
hear about Dick's tracking from other sources. We have no way to
know how representative it is, so I'd be careful in bandying these
numbers around as though they were Revealed Truth.
Mike Feldman
Michael Feldman
Roy Wilmhoff <roy_wi...@milacron.com> wrote:
>In my shop we use C and VisualBasic. There is still a need for Fortran
>in places which are heavily Math intensive. ADA is used within the
>defense related community.
I agree with your statements, for the most part. Since this is a heavily
cross-posted note, and these groups are international, I thought I'd
put a few Ada facts on the record. It is true that Ada is used in
the "defense community", but you might be surprised by some things
on the attached list.
Mike Feldman
---
Interesting Projects (mostly non-defense)
in which Ada is used to at least a significant degree.
I am just getting starting with this categorization by domain;
I know the list is incomplete. I am very interested in getting
additions, corrections, and additional domains; I want the data
to be current and verifiable.
Michael B. Feldman
chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052 USA
202-994-5919 (voice)
202-994-0227 (fax)
mfel...@seas.gwu.edu (Internet)
Air Traffic Control Systems, by country
Australia
Belgium
Brazil
Canada
China
Czech Republic
Denmark
Finland
France
Germany
Greece
Hong Kong
Hungary
India
Ireland
Kenya
Netherlands
New Zealand
Pakistan
Scotland
Singapore
South Africa
Spain
Sweden
United Kingdom
United States
Vietnam
Banking and Financial Networks
Reuters
Swiss Postbank Electronic Funds Transfer system
Commercial Aircraft
Airbus 330
Airbus 340
Beechjet 400A (US business jet)
Beech Starship I (US business turboprop)
Beriev BE-200 (Russian forest fire patrol)
Boeing 737-200, -400, -500, -600, -700, -800
Boeing 747-400
Boeing 757
Boeing 767
Boeing 777
Canadair Regional Jet
Embraer CBA-123 and CBA-145 (Brazilian-made regional airliners)
Fokker F-100 (Dutch DC-9-size airliner)
Ilyushin 96M (Russian jetliner)
Saab 2000
Tupolev TU-204 (Russian jetliner)
Communication and Navigational Satellites
Cassini
ENVISAT-1 - European Space Agency, Earth observation satellite
EOS - NASA's Earth Observing System
Goes
INMARSAT - voice and data communications to ships and mobile communications
Intelsat VII
NSTAR (Nippon Telephone and Telegraph)
PanAmSat (South American Intelsat-like consortium)
RadarSat (Canada)
United States Coast Guard Differential Global Positioning System
Railway Transportation
Cairo Metro
Calcutta Metro
Caracas Metro
Channel Tunnel
Conrail (major U.S. railway company)
French High-Speed Rail (TGV)
French National Railways
Hong Kong Suburban Rail
London Underground
Paris Metro
Paris Suburban Rail
Television Industry
Canal+ (French pay-per-view TV, remote cable box control software)
Scott Schwartz
| With UCB (and "we teach C" Stanford) pumping these guys into the
| influential Silcon Valley/Bay Area, its basically spells out doom for
| alternate languages like Ada, Modula*, Eiffel, etc.
Sounds like sour grapes from the losers to me. Highly effective
languages like Perl have no trouble penetrating the Unix community,
displacing C for many systems programming applications. The reason
that Ada, Modula, Eiffel, and the rest haven't made inroads is because
they aren't good enough. End of story. Not good enough means one or
more of: the compilers cost too much, are too big and slow, produce
executables that are too big and slow, are pointlessly non-ergonomic
(upper CASE keyword disease), don't interface gracefully with the OS
or with C, don't live up to their own claims ("safe" langauges don't
abort when you call NEW), and, most importantly, no cool programs ever
seem to be written in these languages. If Doom were written in Ada,
that would get people interested.
Scott Schwartz
| What the hell does it matter what case a keyword is? It makes no sense to me
| why that would be a reason not to use a language.
Hard to read, hard to type. Like I said, ergonomics counts,
especially given an entrenched champion. And that was just one factor
among many.
| IMO, there are two major reasons why you should choose a language:
|
| 1) speed.
| 2) portability.
Those aren't bad reasons. Quality of implementation, in general, is
very important.
| Also, Your last comparision is meaningless. If doom was produced by the DoD,
| then it would have been made in ADA.
No, my last point was valid. If people write interesting software in
a particular language and tell other people about it, other people
will make decisions based on that. Advertise your success stories.
Colin...@barclays.co.uk
: we...@cis.ohio-state.edu (Michael J Wenk) writes:
: | What the hell does it matter what case a keyword is? It makes no sense to me
: | why that would be a reason not to use a language.
: Hard to read, hard to type. Like I said, ergonomics counts,
: especially given an entrenched champion. And that was just one factor
: among many.
: | IMO, there are two major reasons why you should choose a language:
: |
: | 1) speed.
: | 2) portability.
The first point gives another reason, readability. Most programs are write
once, read many. Using a language with obfuscated syntax generates programs
which tend to be write only, i.e. non-maintainable.
--
Colin Walls |
Colin...@barclays.co.uk (work)| Die Tat ist alles,
Co...@murorum.demon.co.uk (home) | nichts der Ruhm.
Tel: 01565-614531 |
Peter Seebach
Trond Solem <tr...@multimaster.no> wrote:
>WHY??? I am building an embedded systems OS in Modula-2. I can't see that
>there are ANY problems with that. If I tried to write it in C, I would run
>into big problems with multitasking. How do you create a multitasking system
>in a language that doesn't support tasks?
Gee. I guess it must be impossible. Unix must have been written in
Modula 2.
How do you think it's done?
-s
--
Peter Seebach - se...@solon.com || se...@intran.xerox.com --
C/Unix proto-wizard -- C/Unix questions? Send mail for help. No, really!
Copyright 1995 Peter Seebach. -- High energy particle theology
The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq
Robert Dewar
(For one, the Bourne shell syntax in't nearly obscure enough.)
Um, perhaps if you think that the A68 syntax is (a) obscure and (b) unrelated
to the Bourne Shell, you do NOT quite have the knack of extracing the
context free granmmar from the W grammar yet!
There is nothing obscure about A-68 syntax, it is really a very straightforward
Pascal like syntax (actually closer in most respects to Ada than Pascal)
Edwin David Latham
----snip----
> The sources for the early Pascal and Modula compilers were given away
Does anyone know whether these are still available? And if so, where?
Ned
Robert B. Love
From: rl...@raptor.neosoft.com (Robert B. Love )
Subject: Re: Is C/C++ the dominant teaching language?
Organization: NeoSoft Internet Services +1 713 968 5800
In <SCHWARTZ.95...@galapagos.cse.psu.edu> Scott Schwartz wrote:
> | Also, Your last comparision is meaningless. If doom was produced by
the DoD,
> | then it would have been made in ADA.
>
> No, my last point was valid. If people write interesting software in
> a particular language and tell other people about it, other people
> will make decisions based on that. Advertise your success stories.
Wasn't Doom actually first written in Objective C on a NeXT? Didn't
do much for that language did it?
----------------------------------------------------------------
Bob Love, rl...@neosoft.com (local) MIME & NeXT Mail OK
rl...@raptor.rmnug.org (permanent) PGP key available
----------------------------------------------------------------
--
|Fidonet: Robert B. Love 4:901/215.99
|Internet: Robert.B..Love@p99.f215.n901.z4.fidonet.org
Robert B. Love
Carsten Whimster
Robert B. Love <rl...@raptor.neosoft.com> wrote:
| In <SCHWARTZ.95...@galapagos.cse.psu.edu> Scott Schwartz wrote:
| > | Also, Your last comparision is meaningless. If doom was produced by
| the DoD,
| > | then it would have been made in ADA.
| >
| > No, my last point was valid. If people write interesting software in
| > a particular language and tell other people about it, other people
| > will make decisions based on that. Advertise your success stories.
|
| Wasn't Doom actually first written in Objective C on a NeXT? Didn't
| do much for that language did it?
Or the platform :)
For the purposes of inheriting fame from the game Doom, though, I am
sure that C and C++ advocates will welcome Objective-C to the fold, at
least for a little while ;)
Don't forget too that all the snap and speed of Windows NT has
something to do with it being written in C.
Adam Beneschan
> In article <SCHWARTZ.95...@galapagos.cse.psu.edu> schw...@galapagos.cse.psu.edu (Scott Schwartz) writes:
>
> >Sounds like sour grapes from the losers to me. Highly effective
> >languages like Perl have no trouble penetrating the Unix community,
> >displacing C for many systems programming applications. The reason
> >that Ada, Modula, Eiffel, and the rest haven't made inroads is because
> >they aren't good enough. End of story. Not good enough means one or
> >more of: the compilers cost too much, are too big and slow, produce
> >executables that are too big and slow, are pointlessly non-ergonomic
> >(upper CASE keyword disease), don't interface gracefully with the OS
> >or with C, don't live up to their own claims ("safe" langauges don't
> >abort when you call NEW), and, most importantly, no cool programs ever
> >seem to be written in these languages. If Doom were written in Ada,
> >that would get people interested.
Good point. I don't think the FAA's air traffic control system or the
software used inside Boeing airplanes qualify as "cool" programs.
>
> What the hell does it matter what case a keyword is? It makes no sense to me
> why that would be a reason not to use a language. IMO, there are two
> major reasons why you should choose a language:
>
> 1) speed.
> 2) portability.
Interesting. I guess "readability" and "maintainability" count for
nothing; nor do features that help a programmer write correct
programs. In other words, all the features that help you make sure
your program works correctly and continues to work correctly when the
program's functionality is changed or enhanced.
But then again, if there are bugs in Doom, it's not going to cause
loss of life or injury or anything.
Just more stuff to add to my convinction that languages like C are
great if you don't particularly care how well your programs work.
-- Adam
Farshad Nayeri
In article <DH1qw...@latcs1.lat.oz.au> lath...@lion.cs.latrobe.edu.au (Edwin David Latham) writes:
> Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
> From: lath...@lion.cs.latrobe.edu.au (Edwin David Latham)
> X-Nntp-Posting-Host: lion.lat.oz.au
> Organization: CompSci & CompEng, La Trobe Uni, Australia
> Date: Thu, 26 Oct 1995 08:14:37 GMT
Sources for the SRC Modula-3 compiler can be found at:
gatekeeper.dec.com:/pub/DEC/Modula-3
I think somewhere on gatekeeper there is sources for other compiler as
well.
-- Farshad
--
Farshad Nayeri
nay...@gte.com
Peter Seebach
>I hate to infect a good argument with a newbie question, but I seem to
>be missing the point. I was under the impression that C++ was an
>improvement over C. So why would it be considered more marketable.
>Are there things that you can do in C that you cannot in C++?
"Improvement" is a debateable term. It's a *different* language. C is
smaller and simpler. They can do exactly the same things; just
differently. C is sften better for small code or embedded systems; C++ may
be better for large systems. Whatever you know is a good choice.
I prefer C, until C++ settles down more. I really like some of C++,
and hate some of it. YMMV.
Bryce M. Bardin
mfel...@seas.gwu.edu (Michael Feldman) wrote:
... Deletions
>I am just getting starting with this categorization by domain;
>I know the list is incomplete. I am very interested in getting
>additions, corrections, and additional domains; I want the data
>to be current and verifiable.
Hughes' commercial communication satellites which are based
on the HS-601 satellite bus use flight control software written
in Ada. (This is their latest and most popular model; there are
CZAR
>My most marketable (embeded real-time) language skill is C.
I hate to infect a good argument with a newbie question, but I seem to
be missing the point. I was under the impression that C++ was an
improvement over C. So why would it be considered more marketable.
Are there things that you can do in C that you cannot in C++?
Graham Forsythe
jgut...@brokersys.com
: WHY??? I am building an embedded systems OS in Modula-2. I can't see that
: there are ANY problems with that. If I tried to write it in C, I would run
: into big problems with multitasking. How do you create a multitasking system
: in a language that doesn't support tasks?
I don't know. Maybe it's impossible. Maybe the operating system I'm using
right now is a figment of my imagination. Maybe ALL Unixes are figments
of some collective imagination.
The fact is, if the language you want to use for your OS doesn't support
coroutines (or, if you prefer, activations like Scheme uses) then you need
to implement them in a combination of that language and perhaps some
assembly language. Note, however, that if you ARE using a language that
supports those features, then the language implementor has to implement
them using a combination of that language and perhaps some assembly
language. I'm not sure that there's anything to be gained there. What
happens if the guy who did the implementation for the language didn't do
exactly what you want?
From my perspective, the problem with using Modula-2 for a general-purpose
operating system is the level of abstraction inherent in the language.
I believe that the API of an OS should be defined with a minimum of
abstraction and that includes things like parameter passing conventions
and suchlike. If you write the OS in Modula-2, the natural way of defining
the system calls is in terms of Modula-2 functions, and I believe that that
is a mistake. That sort of thing makes it difficult to implement other
languages for that system and even may make it difficult to use different
implementations of the same language on that system.
In case anybody's wondering, I also think that sort of abstraction is a
problem with the way Unix defines its API in terms of C function calls.
Robert Dewar
"Wasn't Doom actually first written in Objective C on a NeXT? Didn't
do much for that language did it?"
Well certainly not many people know what language DOOM is written in. On the
other hand, Nextstep is written in Objective C, and that certainly does
provide significant visibility for Objective C (most people only know about
Objective C because of this use by Next).
Robert Dewar
"Look, I've written a fair number of well-defined modules in C that
I can reuse just fine. I've had no trouble producing bug-free code on
a smallish scale, and as it grows, I continue to produce well-defined
modules that I can rely on. Good coding vs. bad coding is orders of
magnitude more important than language."
And of course the crucial words in this paragraph are "smallish scale"
WRiting large programs has almost nothing in common with writing small
programs. Of course you can write in any language, including assembly
language, or even absolute machine langauge on a "smallish scale".
Gary Sims
Peter Seebach
>And of course the crucial words in this paragraph are "smallish scale"
>WRiting large programs has almost nothing in common with writing small
>programs. Of course you can write in any language, including assembly
>language, or even absolute machine langauge on a "smallish scale".
If that's how you write large programs, you have missed the concept of
modular programming entirely. I can produce 1,000 line pieces of code I
can trust, and I can put hundreds of them together.
How many millions of lines do you need to have before it's big enough?
It'll still be made of small, bug-free chunks, or badly written.
Peter Seebach
>Great, congratulatoins on having solved the problem of writing large programs
>using modular programs with no trouble. You have solved a problem that has
>puzzled the programming community for a long time!
Nice sarcasm. My point is that your criticism of C was ludicrous. The
things you were pointing at produce crappy unmaintainable code in
any language.
>If this is based on real experience, i.e. you really have put together
>hundreds of 1000 line modules with no trouble, you should share your
>method. However, to be convincing you need to be talking about programs
>of significant size, say at least 0.5 million Sloc (that is still not
>really big, but still big enough that the glib statement that modular
>programming solves all the problems is not easily credible!)
Sloc?
No, I haven't gone that big. I've only been doing this for about a year
in my spare time, and it takes a while. But it is the basis of the C
standard. What do you think the standard library *is*? It's a set
of pretested, reliable routines to do certain well defined things.
>Of course we are all familiar with the concept of modular programming (Parnas
>has after all been around for a while :-) But it is a long time since we
>bought this is aome magic elixir that *automatically* solves the problem
>of writing large programs.
I didn't say "automatically". I merely said it was possible to produce
large programs in C that are reliable. I never said it would be easy.
I just object to the characterization of C as a buggy language. It
isn't. I can show you bug free pieces of C code. I can also show you
horribly buggy programs in Ada, M3, Icon, Eiffel, or any other language
you care to name.
Don't blame the language, blame the programmers. When a language is
one of the most commonly used, every programmer who lies about experience
to get a job is likely to end up writing in it. So, you have a lot of
incompetent programmers working on projects specced so as to be impossible,
at companies that would rather release something early than stable.
But this is not the fault of C; the same programmers would produce just
as many useless things in any other language.
You can argue that your favorite magic bullet (run time type checking,
array bounds, whatever) will catch "almost all" of those errors, but I
can laugh at the claim, because it's wrong. No language level feature
will prevent shoddy programs from being broken and useless.
I have produced at least some small reliable programs. I am at this time
unconvinced there is ever a sufficient *reason* to make them much larger;
I suspect that a vast program, like a vast function, is a result of not
knowing when to break things into modules. uSoft has encouraged this
by sticking a lot of people with the application concept. No word processor
should *ever* have the code for sorting; sorting should be a separate
application. I doubt the code for searching should be in the WP either;
I could justify it as a common library thing, but really, a tool should
be used. Why should any two programs anywhere have substantially the same
code for substantially the same action?
I have never seen a vast application that was well-designed. I have seen
a lot that look really nice on paper, but it always comes down to modules;
if they wrote the basic pieces of their programs as separate programs,
and had them talk, they would do a lot better.
Basically, my point is that my magic bullet, while obviously not able
to make things perfect without human intervention, is every bit as
powerful as yours.
Robert Dewar
Carsten> something to do with it being written in C.
You must be using a different version of Windows NT than I have, what
"snap and speed"? In fact, especially on fast RISC machines, there are
serious performance problems in NT. These have to do more with software
architecture issues (eexcessive layering), than language issues.
Matthew B. Kennel
: I have produced at least some small reliable programs. I am at this time
: unconvinced there is ever a sufficient *reason* to make them much larger;
: I suspect that a vast program, like a vast function, is a result of not
: knowing when to break things into modules. uSoft has encouraged this
: by sticking a lot of people with the application concept. No word processor
: should *ever* have the code for sorting; sorting should be a separate
: application. I doubt the code for searching should be in the WP either;
: I could justify it as a common library thing, but really, a tool should
: be used. Why should any two programs anywhere have substantially the same
: code for substantially the same action?
: I have never seen a vast application that was well-designed. I have seen
: a lot that look really nice on paper, but it always comes down to modules;
: if they wrote the basic pieces of their programs as separate programs,
: and had them talk, they would do a lot better.
This only relegates the issue of large scale architecture to the
design of the interfacing between these smaller programs. Complexity
has only been shifted, not conquered.
In a large scale software engineering language, you can express many
complex and subtle relationships between the entities that go in one
place and go out another. And doing so is important to keeping
things working.
: --
Lawrence Kirby
cs...@undergrad.math.uwaterloo.ca "Carsten Whimster" writes:
>| Wasn't Doom actually first written in Objective C on a NeXT? Didn't
>| do much for that language did it?
>
>Or the platform :)
>
>For the purposes of inheriting fame from the game Doom, though, I am
>sure that C and C++ advocates will welcome Objective-C to the fold, at
>least for a little while ;)
I understood Doom to be written in ANSI C, which is why it has been so easily
ported to many platforms.
>Don't forget too that all the snap and speed of Windows NT has
>something to do with it being written in C.
You can't blame NT's dismal performance on C. Consider OS's such as Linux
and Freebsd which are written in C and generally perform significantly
better on the same hardware platform.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
AdaWorks
: In article <dewar.814970379@schonberg>, Robert Dewar <de...@cs.nyu.edu> wrote:
: >Great, congratulatoins on having solved the problem of writing large programs
: >using modular programs with no trouble. You have solved a problem that has
: >puzzled the programming community for a long time!
: Nice sarcasm. My point is that your criticism of C was ludicrous. The
: things you were pointing at produce crappy unmaintainable code in
: any language.
It is clear that Mr. Seebach is unfamiliar with the Ada model for
modularity. And it is also clear that he has the potential for
benefiting from it when he does learn how it works.
There are a lot of good programmers out there who intuitively have the
right idea about how to proceed, but do not have all of the information
necessary to harness that intuition. I suspect that Mr. Seebach, because
of his concern for excellence in modularity, may someday be a very
fine Ada programmer.
This is not intended as sarcasm. It is an observation drawn from
experience with other intelligent programmers who see the possibilities
of modularity but do not yet have the benefit of the knowing about the
substantial literature on the subject.
: >Of course we are all familiar with the concept of modular programming (Parnas
: >has after all been around for a while :-) But it is a long time since we
: >bought this is aome magic elixir that *automatically* solves the problem
: >of writing large programs.
Many programmers have never read Parnas. One of the best summaries of
modularity is in Bertrand Meyer's book, "Object-Oriented Software
Construction." the first four chapters of which are required reading for
anyone who wants to make a career in programming. (Oh, BTW, this is an
Eiffel book).
: I just object to the characterization of C as a buggy language. It
: isn't. I can show you bug free pieces of C code. I can also show you
: horribly buggy programs in Ada, M3, Icon, Eiffel, or any other language
: you care to name.
I agree that C is not inherently "buggy." However, it is a "one size
fits all" language that require substantial discipline to use correctly.
Ada, Modula 2/3, and Eiffel are designed so the compiler will give the
programmer more help in detecting potential defects early in the design
and development process. C programs tend to be more dependent on
"after the fact" auxiliary tools such as code analyzers and debuggers.
The use of C is not evil, but it does require considerable care. It is
a little like the difference between a safety razor and a straight
razor. I can still nick myself with a safety razor, but I will probably
not do enough damage to bleed to death.
: Basically, my point is that my magic bullet, while obviously not able
: to make things perfect without human intervention, is every bit as
: powerful as yours.
Alas, as so often been observed, there is no magic bullet for software
anymore than there is a royal road to mathematics.
Richard Riehle
adaw...@netcom.com
--
ric...@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX 328-1112
Pedro de las Heras
You can find a comparison between Windows NT, Windows, Windows for Workgroups
and NetBSD (a BSD-like free operating system) in:
"The Measured Performance of Personal Computer Operating Systems"
J. Bradley Chen, Yashuhiro Endo, Kee Chan, David Mazi`eres,
Antonio Dias, Margo Seltzer, and Michael D. Smith
The Proceedings of the 15th ACM Symposium on Operating System Principles
Regards,
--
Pedro de las Heras
phe...@ordago.uc3m.es
--
Pedro de las Heras Quir'os
mailto:phe...@ordago.uc3m.es // snail-mail:
Voice: +34-1-624 94 97 // Universidad Carlos III
Fax: +34-1-624 94 30 // C/ Butarque 15. E-28911
URL: http://www.uc3m.es/~pheras/ // Legan'es SPAIN
Peter Seebach
Richard A. O'Keefe <o...@goanna.cs.rmit.EDU.AU> wrote:
>The C standard library is rather small. For reference, it includes only
> <assert.h> Assertion checking
> <ctype.h> Character classification and case shift
> <errno.h> Error numbers and errno quasi-variable
> <float.h> Floating-point parameters
> <limits.h> Environment parameters with integral values
> <locale.h> New in standard; localisation support
> <math.h> Transcendental functions, &c
> <setjmp.h> Non-local GOTO
> <signal.h> Interrupts & exceptions
> <stdarg.h> Support for variable length argument lists
> <stddef.h> Some types and constants
> <stdio.h> I/O library
> <stdlib.h> Miscellaneous, including exit
> <string.h> Lousy string functions
Lousy? I like 'em.
> <time.h> time of day, elapsed time, calendar
>For comparison, Fortran, COBOL, and Lisp have almost all of this stuff as
>part of the built in syntax or predefined environment and nobody is in the
>habit of calling e.g. the SORT verb in COBOL "a rich heritage of reusable
>code".
Does the sort verb in cobol let you provide your own arbitrary method for
sorting?
> Of course, in all these cases the
>predefined types and routines of a language _are_ reusable code and of very
>great value, but SINCE THEY ARE DESIGNED WITH THE STANDARD they don't count
>as a demonstration of whether the language supports reuse well.
They do when they're traditionally implemented *in* the language. The
built-ins of some languages are sometimes implemented in C or assembly.
95% of the C library can be written in *completely portable* C.
>As for reuse of the C standard library, it isn't always advisable.
>I recently got a _very_ nasty shock hn a program that was supposed to
>save time by fseek()ing over records it didn't want ran slower by a
>very large factor (3 seconds went to 30 seconds); I am informed that
>the typical System V implementation of "fseek" _always_ flushes the
>current buffer and does an lseek() even when the position you are
>seeking to is the position you are now at. At various times on various
>machines I have found it necessary to replace large chunks of the C library
>to avoid such performance problems.
I've rarely had to do anything of the sort. But you miss the point; it is
the *definition* of fseek to do appropriate flushing. Although a good
implementation would have checked whether it was useful or not.
But, consider; the majority of the Standard Library of C was designed, not
as a part of the language, but as a tool to be used with C. It was a good
enough set of tools to standardize.
I have written a fair number of functions which I can reuse consistantly.
C has provided a good way for me to do this. C has done a lot to advance
the concept, partially by providing a portable way to do things efficiently
enough for people to use it back in the days of slow systems. It's
still pretty good at it.
-s
Peter Seebach
Steve Doiel <ste...@pacifier.com> wrote:
>Does this mean that when I spend two days chasing down a bug where I
>mistakenly used an = instead of an == that I am incompetent? I thought
>I was just human. When it comes to chasing down this type of program
>error, I would rather let the compiler to the work for me.
Well, most compilers can be gotten to warn for any use of = anyplace
where == would make sense. Almost any.
But I dunno; generally, if a bug takes me more than an hour to track down,
I consider myself sloppy. I have good debugging code in most of my work,
so I turn on debugging, and just see what I get...
However, I personally like the behavior of = and ==. I like being able
to put assignment anywhere. :)
Robert Dewar
Carsten Whimster
Blair MacIntyre <b...@cs.columbia.edu> wrote:
| >>>>> On Fri, 27 Oct 1995 13:12:50 GMT, cs...@undergrad.math.uwaterloo.ca (Carsten Whimster) said:
|
| Carsten> Don't forget too that all the snap and speed of Windows NT has
| Carsten> something to do with it being written in C.
|
| speed of NT has little to do with the fact its written in C, it has to do with
| 1) the users are seated at a console, so mouse/window communication
| isn't going over any wire (unlike X et. al.) so there is no lag
| 2) the OS is preemptive, so the mouse gets fast response by being
| handled without delay.
|
| You could write a similar OS in a language like c++, modula3 or modula2,
| not just a macro-assembler. It's a question of software engineering,
| not the language choice.
Actually, I was being sarcastic ! I am sorry, I didn't realize I had
been to subtle there. When I first evaluated NT for a company, we were
amazed at the LACK of speed it demonstrated, considering that
Microsoft had effectively made everyone believe that it was really the
OS/2-killer that they claimed it was. When we saw it, our jaws
dropped, and then we howled, and threw it out. They now run OS/2.
Since then, NT has gotten better, but my point was that if you need
speed, C is no guarantee.
I dearly love C, but I readily admit it has its flaws.
ob-modula-3: who knows if, when, and where the OS/2 port will be done,
and if it includes access to the full API? What is the speed like :)
Robert Dewar
that C has "excellent abstraction facilities" is that I suspect there are
*many* C programmers out there who think that. If all you have done is to
write small programs in C, and have not been exposed to the real problems
of software engineering (and all the work done in both language design
and methodology in the last 20 years), how could you know the issues?
As I mentioned to Peter in a private note, it kind of reminds me of Fortran
programmers wen EWD's letter on gotos appeared. They had a hard time
understanding the idea of goto free programming, which is not surprising
if you are in a language that has no reasonable control structures (no
doubt there were Fortran programmers who thought that Fortran had
excellent control structures and was "excellent for strucured programming".
Peter, I suggest that instead of "slogging through Knuth Volume I", you
spend some time instead reading about modern software engineering
methodology. Sure the algorithms in Knuth are important (indeed one
would assume that any programmer should be familiar with the algorithms
in Knuth Volume I, this is after all a book written 25 years ago). But
when it comes to writing really large scale programs, the algorithms are
the trees, and the issue is understanding the structure of the forest.
Another very typical notion in Peter's post is the "I don't want the
language enforcing methodology, I know how to program" viewpoint. One
might have hoped that this would have disappeared by now, but I fear
that schools these days are actually reinforcing this kind of attitude
to programming. Peter cannot see any value at all in enforced information
hiding, because he thinks programmers should be able to follow rules.
Of course as long as Peter sticks to what he is doing, which, from a
private note, is primarily writing little programs of a couple of hundred
lines long in C or Perl or shell scripts, then language is certainly
not much of an issue, and of course C is adequate. Bad programmers
can still make a hash of small programs, and well designed language
s can help even for small programs, but a good programmer can do fine
in C of course.
The worrying thing is that programmers with these kinds of attitudes
all to often *do* end up working on large projects, and importing
these working views into large projects is a quick road to a big mess.
It's depressing to think that so much of a computer science undergraduate
curriculum at many universities is devoted to completely out of date
stuff (think, an undergraduate can be introduced to a 25 year old language,
and use it to concentrate on programming simple algorithms that have been
around for a long time, and, at far too many schools, can graduate with
almost no idea of what has been done in software engineering and
understanding of program construction in the last two decades).
P.S. Peter, I don't think you should waste your time writing a MIX
assembler and simulator, there must be one around you can get your
hands on. At least there were 20 years ago, these days, Knuth's books
look a little flawed in their concentration on MIX. Of course DK would
not write those books that way today, or at least I don't think so. The
algorithms are important, and the discussion brilliant of course, but
the presentation is far too low level for my taste, with low level
efficiency concerns entering far too early. Precisely what is missing
from the code in these books is a good sense of abstraction. But I
guess if you think that C has excellent abstraction facilities, then
MIX will seem just fine to you :-)
By the way, Peter, if you want a full Ada 95 compiler, pick up GNAT 3.00
when it comes out in a week or so (earlier versions are in current use, but
if you are looking at Ada for the first time, you may as well wait a bit
to get version 3.00). If you seriously want to give this a try, I do NOT
recommend trying to learn Ada 95 from the reference manual (I would assume
you did not learn C from the ANSI C standard!) Instead I recomend getting
the Barnes book as an informal introduction. Then when you really understand
the basic structure, you can follow your (perfectly reasonable) desire to
program to "spec" and not to the "compiler", and study the reference
manual. Although a word of warning is appropriate here. THe defining
documents for modern complex languages are very complex documents, and
reading them, especially without a background in language design, is not
an easy task. After all, by comparison, C is a trivially simple language,
and yet the ANSI C standard is still not an easy document for most people
to read and fully understand.
Robert Dewar
"Does the sort verb in cobol let you provide your own arbitrary method for
sorting?"
Actually SORT in COBOL is a nice example of layered abstraction. You can
define methods for inputting the data, comparing the data, and outputting
the data, including reformtting the data for the actual sort.
The sorting algorithm itself is certainly built in. No one is about to want
to write their own sort in this kind of environment. Remember we are not
talking about simple quick sorts or heap sorts here, we are talking about
very sophisticated methods for external sorting, and the whole point of
the SORT verb is to connect you with prewritten reusable code for the sort.
So the question is a bit like: does lseek allow you to substitute your
own method for randomly accessing part of a file, and the answer is
of course no, and that is the point.
But as others have pointed out, the standard library of C is quite small
in any case, and large languages like COBOL typically have much richer
semantics built in. FOr example, the entire handling of fixed decimal
arithmetic with high precision in COBOL, very much appropriate of course
for fiscal applications, is completely missing from C and C++. Yes you
could write standard library routines to handle this, and people do, but
the integration with the language is poor (e.g. no high precision literals
are available, and no fixed-point literals are available). By contrast
Ada 95 does provide these high precision fixed-point decimal scaled
arithmetic capabilities, cleanly built into the language).
The question of how much should be built into the language is an interesting
one that is somewhat orthogonal to the issue of abstraction and modularity,
though not entirely (because a language like Ada 95 that provdies strong
capabilities for modularization and interfacing makes it easier to build
on new packages, compared to the rather primitive facilities in C. I'll give
two simple examples:
The single giant name space of C means that if you structure an addition
to the language library as a set of separate units (one visible to the
programmer, the others supposedly invisible, there is no way of limiting
the visibility, and name space pollution is inevitable). Ada 95 by
contrast provides package name spaces to solve this problem, and if you
like, you can use private child packages to enforce hiding.
In interfacing to other languages, C is very weak. For example, there is no
convenient way to interact with a multi-dimensional Fortran array. In C
you would end up having to index it backwards, whereas in Ada 95 you
can use pragma Convention Fortran to force a multi-dimensional array to
be mapped as Fortran would map it.
These kind of facilities in Ada 95 indeed make it easier to extend the
functionality of the language by adding libraries (for the record C++
is somewhere between C and Ada 95 in this capability).
But there still remains the issue of how rich the built-in semantics should
be. A decade ago, the trend seemed to be to smaller languages (Oberon comes
to mind as representative of that trend). However, a suprising thing has
happened in the last ten years, the simple languages have lost, and it seems
like this war was one by the complex languages almost without a shot being
fired. Consider:
COMMON LISP with CLOS
COBOL 81 (and now OOP COBOL)
FORTRAN 90
ADA 95
C++ (with the ISO extensions)
SMALLTALK (with its full library)
These are all very complex languages/systems. So it seems like that's what
the world wants these days. There are of course some hold outs for simpler
languages, notably C, but the number of C (as opposed to C++ enthusiasts)
seems to be dwindling (Richard Stallman is one obvious exception, he
certainly has not bought into C++ -- perhaps we can persuade him to
write GCC 3 in Ada 95 :-) :-)
Jay Martin
>A decade ago, the trend seemed to be to smaller languages (Oberon comes
>to mind as representative of that trend). However, a suprising thing has
>happened in the last ten years, the simple languages have lost, and it seems
>like this war was one by the complex languages almost without a shot being
>fired. Consider:
> COMMON LISP with CLOS
> COBOL 81 (and now OOP COBOL)
> FORTRAN 90
> ADA 95
> C++ (with the ISO extensions)
> SMALLTALK (with its full library)
>These are all very complex languages/systems. So it seems like that's what
>the world wants these days. There are of course some hold outs for simpler
>languages, notably C, but the number of C (as opposed to C++ enthusiasts)
>seems to be dwindling (Richard Stallman is one obvious exception, he
>certainly has not bought into C++ -- perhaps we can persuade him to
>write GCC 3 in Ada 95 :-) :-)
And the world is basically incompetent. The problem is that there are
basically no mechanisms to stop system/language bloat (which ever
system/language dies with the most features wins!) Commercial
products keep getting fatter as they keep adding features for
marketing reasons. Language/system committees have a tendency to keep
adding features to appease everyone. Academics are completely
apathetic about bloat and some encourage bloat because complex systems
have more "research potential". In fact, the only place where a call
for non-bloat could come from is from academia, but they really do not
give a fuck about software. Anyway the dreaded NIH syndrome in
precludes any popular languages coming from academia. Wirth has been
screaming about software bloat but he has proven totally irresponsible
when it comes to his languages, when he came out with Oberon (after
letting Pascal, Modula* rot), I just rolled my eyes.
>COMMON LISP with CLOS
Widely recognized as bloated and some say it is killing LISP. Or
maybe its AI thats killing LISP or possibly LISP is killing LISP.
>FORTRAN 90 and HPF
Bloated and where are the compilers?
>COBOL (Most real programmers will slit their wrists first).
>ADA 95
Ada was bloated and it got little commercial use and had
very expensive compilers. Ada 95 is more bloated
and it is questionable whether it will go anywhere.
>C++ (with the ISO extensions)
Extremely complex widely popular due mostly to C.
But, all these systems are bloated extensions to already bloated
poorly designed languages (except C which is not bloated but
incompetently designed).
Jay
Peter Seebach
Farshad Nayeri <nay...@gte.com> wrote:
>It always amazes me that people base their use of the language on what
>case the keyword is in. Oh yeah, I forgot, I am posting to
>comp.lang.advocacy.
Any one see any reason not to RFD it? We obviously need it.
I got frustrated by the all caps keywords in M3, the ugly template syntax in
C++, and many other "cosmetic" issues. (I wan't even bother listing my
problems with traditional FORTRAN.)
These are *NOT* trivial. If a language makes it impossible to write decent
looking code, there is something wrong with it.
Consider:
English IS a nice language. BUT IF you WERE to capitalize certain words
BECAUSE they WERE deemed more important THAN others, IT would BE practically
illegible. IT WOULD certainly BE A very difficult READ. NO native speaker OR
reader of English I HAVE ever met HAD any trouble reading text IN English.
THE fact THAT verbs AND certain "keywords" ARE NOT IN all caps DOES NOT hurt
THE language AT ALL.
ANY experienced reader OR writer OF A language WILL spot keywords easily AND
quickly. A sloppy-looking, unnatural, hard-to-read layer DOES NOT help AT
ALL.
>For those of you who like Modula-3 semantics but hate the uppercase
>keywords, I suggest you read he paragraph below (and fetch m3su which
>allows you to use lowercase keywords).
Given than, I may track it down and try to build it for my current home box.
Yes, it's a "minor" point, but they really are *horribly* ugly and hard to
read. I could accept leading caps, but fundementally, native usage of my
language does not have any all-caps words excpt for signs. Code should read
more like text, and less like a billboard.
> Some people prefer uppercase keywords others hate them. Another
> possibility is to accept both forms for keywords. This topic has been
> discussed at length and there is no solution that will completely
> satisfy everyone's tastes. Fortunately this is a very minor issue and
> you can easily have lowercase keywords automatically converted for you
> using an emacs macro or packages like
> <A HREF="file://pion.lcs.mit.edu/pub/m3su"> m3su </A>.
... But what I mostly don't see is why the language *requires* this. Why
not just go whole hog and require keywords to be in bold?
> http://www.research.digital.com/SRC/modula-3/html/welcome.html
(Left this in 'cuz it's a good pointer.)
Thanks for the response. If I don't get any good reasons not to, I'll track
down the RFD process and start the process for comp.lang.advocacy.
Peter Seebach
>The sad thing about Peter Seebach's post in which he expresses the opinion
>that C has "excellent abstraction facilities" is that I suspect there are
>*many* C programmers out there who think that. If all you have done is to
>write small programs in C, and have not been exposed to the real problems
>of software engineering (and all the work done in both language design
>and methodology in the last 20 years), how could you know the issues?
By about 220k of code, wost of the issues are visible, if subtle.
I have taken the time to ak a fair number of programmers of widely varying
backgrounds about this; all of them have agreed that abstraction is a feature
of programs and their designs, not languages.
The C standard I/O library uses a type "FILE" to hold information about files.
It does not matter what it is; it works the same everywhere. I have asked
Robert several times to explain how this is not an abstraction, and he has
chosen to ignore the request, because the way in which it is not an
abstraction is "too obvious" t oexplain. Anyone? Bueller?
>As I mentioned to Peter in a private note, it kind of reminds me of Fortran
>programmers wen EWD's letter on gotos appeared. They had a hard time
>understanding the idea of goto free programming, which is not surprising
>if you are in a language that has no reasonable control structures (no
>doubt there were Fortran programmers who thought that Fortran had
>excellent control structures and was "excellent for strucured programming".
...And yet it is now pretty well known that a goto can be legitimately and
sanely used in a structured program. My, how time flies.
>Peter, I suggest that instead of "slogging through Knuth Volume I", you
>spend some time instead reading about modern software engineering
>methodology. Sure the algorithms in Knuth are important (indeed one
>would assume that any programmer should be familiar with the algorithms
>in Knuth Volume I, this is after all a book written 25 years ago). But
>when it comes to writing really large scale programs, the algorithms are
>the trees, and the issue is understanding the structure of the forest.
I've read a fair number of books from the last few years. I've also gone out
and written programs, and looked for where my strategies started breaking
down. My early programs were morasses of code; my modern ones are
sufficiently modular that I can completely rewrite any part without even
recompiling the rest.
>Another very typical notion in Peter's post is the "I don't want the
>language enforcing methodology, I know how to program" viewpoint. One
>might have hoped that this would have disappeared by now, but I fear
>that schools these days are actually reinforcing this kind of attitude
>to programming. Peter cannot see any value at all in enforced information
>hiding, because he thinks programmers should be able to follow rules.
Yes, I do. Programmers who can't follow rules will produce shoddy code no
matter what you bind them with. C makes it quite possible to hide information
about the implementation of a structure; just
typedef struct foo *foo;
and foo is a perfectly valid type, which you know nothing of the
intenals of.
>Of course as long as Peter sticks to what he is doing, which, from a
>private note, is primarily writing little programs of a couple of hundred
>lines long in C or Perl or shell scripts, then language is certainly
>not much of an issue, and of course C is adequate. Bad programmers
>can still make a hash of small programs, and well designed language
>s can help even for small programs, but a good programmer can do fine
>in C of course.
Right... But everything I've heard about Ada is that it's wasting more time
jumping through ill-considered hoops than it saves preventing jumping off the
occasional cliff. Of course, many of these people were C or C++ programmers.
I do distrust anything designed by committee. Small groups can produce a
consistent design; committees never have. If Ada, designed by a committee, is
truly an legent language, with a solid internal concept of how everything
sholud go together, then it is the first time in all of human history that a
committee with a significant number of members has produced one. My
skepticism here is pretty heavy.
>The worrying thing is that programmers with these kinds of attitudes
>all to often *do* end up working on large projects, and importing
>these working views into large projects is a quick road to a big mess.
I see no evidence here. I use regularly a medium large system
which is written by hundreds of programmers, who drop out or join up with no
central authority at all, written almost entirely in C (one module of C++,
a few dozen of assembly), which seems to me to be fundewmentally quite stable.
The problems it has are almost always a result of a change to a device driver
being made by someone who has no documentation for the device.
I refer, of course, to NetBSD, a system running reliably on about a dozen
unrelated machines.
This is, of course, the way C is *designed* to enforce information hiding and
independance; if things are *completely* separate, make them separate
programs. vi is the largest program I've ever seen that I think is remotely
consistent, everything larger I see looks like two or more programs thrown
togethr.
This is what one expects, of coure; a language designed by committee would
doubtless be the right tool for a project designed by a committee. Support
for bloating and pointless or inappropriate marriages of unrelated tasks is
the natural strength of a bloated language consisting of pointless or
inappropriate marriages of unrelated languages.
>It's depressing to think that so much of a computer science undergraduate
>curriculum at many universities is devoted to completely out of date
>stuff (think, an undergraduate can be introduced to a 25 year old language,
>and use it to concentrate on programming simple algorithms that have been
>around for a long time, and, at far too many schools, can graduate with
>almost no idea of what has been done in software engineering and
>understanding of program construction in the last two decades).
Who said anything about CS? I'm a psychologist.
Seriously, though, I think you place too much reliance on tools, and too
little on understanding. Just as most maintenance patches are simply
band-aids, ignoring the fundemental design flaws, wrapping incompetent
programmers in tools that protect them is just a symptom patch, not addressing
the fundemental problem of programmers who do not spend at least a fair amount
of time being mentored in the art of computer programming.
I think what this field needs is apprenticeships.
>P.S. Peter, I don't think you should waste your time writing a MIX
>assembler and simulator, there must be one around you can get your
>hands on. At least there were 20 years ago, these days, Knuth's books
>look a little flawed in their concentration on MIX. Of course DK would
>not write those books that way today, or at least I don't think so. The
>algorithms are important, and the discussion brilliant of course, but
>the presentation is far too low level for my taste, with low level
>efficiency concerns entering far too early. Precisely what is missing
>from the code in these books is a good sense of abstraction. But I
>guess if you think that C has excellent abstraction facilities, then
>MIX will seem just fine to you :-)
The books show an excellent understanding of abstraction. Abstraction
consists of working with the problem in the problem's terms, not the
hardware's terms. You may get stuck writing a bit of glue here and there,
but as long as you know what you're *really* working with, you're fine.
>By the way, Peter, if you want a full Ada 95 compiler, pick up GNAT 3.00
>when it comes out in a week or so (earlier versions are in current use, but
>if you are looking at Ada for the first time, you may as well wait a bit
>to get version 3.00). If you seriously want to give this a try, I do NOT
>recommend trying to learn Ada 95 from the reference manual (I would assume
>you did not learn C from the ANSI C standard!) Instead I recomend getting
>the Barnes book as an informal introduction. Then when you really understand
>the basic structure, you can follow your (perfectly reasonable) desire to
>program to "spec" and not to the "compiler", and study the reference
>manual. Although a word of warning is appropriate here. THe defining
>documents for modern complex languages are very complex documents, and
>reading them, especially without a background in language design, is not
>an easy task. After all, by comparison, C is a trivially simple language,
>and yet the ANSI C standard is still not an easy document for most people
>to read and fully understand.
The C standard is pretty light. I learned C from comparing the code to the
known functionality of programs. Easy. :) If GNAT is portable, I'll try it.
If i won't run on my machines, I'll assume the programmers are incompetent.
:)
Scott Schwartz
| It always amazes me that people base their use of the language on what
| case the keyword is in.
It's a question of ergnonomics. Ergonomics is very important. M3 is
a language that put a lot of effort into solving hard problems, only
to punt on the easy ones. Upper case keywords are a probative example
of that. In a language with lower case keywords, NEW wouldn't abort
the program. All this makes M3 the moral equivalent of shredded
wheat: it might be good for you, but it tastes awful.
Peter Seebach
Nasser Abbasi <nab...@qualcomm.com> wrote:
>Well, you must be very good . I wish I was this good. I remember many
>subtle bugs that took me more than one hour to find. few took me days.
Just a couple of years ago, I found one that took, get this, *TWO WEEKS*.
More on this below...
>There are bugs that are time-dependant, or relating to memory usage that
>can be very hard to find. Most of these I found exist in asynchronous
>programming/ multi-threaded large software.
Hard to find, yes. Hard to fix, definitely. Isolation is a valuable skill,
and one I wish I were better at.
>Actually using debugging statements or running the program when build
>with debug mode on, can sometimes hide the bug you are trying to find
>away (by say slowing down the program).
Yes, but even then, I can often find the problem from that, these days; if
adding a line somewhere changes something, it's frequently a sign of where a
bug is hitting.
>Also, sometimes the bug can be in a software componentry you are just
>linking against and not part of the code you have personally written, and
>trying to determine that can be also very time consuming.
That was the two week bug. HP's VUE interface (the worst I have ever used; the
call to turn a button on or off leaks memory...) would write past the end of
strings you passed it. Not when you passed them in; *later*, when the X
server got to drawing the text. And, in retrospect, I was being sloppy; if
I'd paid attention to how the bug manifested, I would have fixed it much
sooner.
I didn't say I consider it incompetent to take more than an hour or two to
find a bug; just sloppy. Depends on the size of code, how much of it I wrote,
how much of it I have source for, and all of that. It's an approximation.
Rick Sutcliffe
schw...@galapagos.cse.psu.edu (Scott Schwartz) wrote:
> It's a question of ergnonomics. Ergonomics is very important. M3 is
> a language that put a lot of effort into solving hard problems, only
> to punt on the easy ones. Upper case keywords are a probative example
> of that. In a language with lower case keywords, NEW wouldn't abort
> the program. All this makes M3 the moral equivalent of shredded
> wheat: it might be good for you, but it tastes awful.
Wait a minute. I LIKE Shredded Wheat. I also like Modula-2 and its
progeny. Not only do neither taste awful, the restrictions help the
compiler to help the programmer to write bvetter and more maintainable
code.
Rick
--
Rick Sutcliffe Assoc. Prof. Computing/Math Trinity Western University
comp.lang.modula-2 FAQ maintainer & WG13(Can) chair. Not speaking for TWU/WG13
Spencer Allain
nay...@gte.com (Farshad Nayeri) writes:
| It always amazes me that people base their use of the language on what
| case the keyword is in.
It's a question of ergnonomics. Ergonomics is very important. M3 is
a language that put a lot of effort into solving hard problems, only
to punt on the easy ones. Upper case keywords are a probative example
of that. In a language with lower case keywords, NEW wouldn't abort
the program. All this makes M3 the moral equivalent of shredded
wheat: it might be good for you, but it tastes awful.
Ok, so you don't like the uppercase keywords. Maybe the language
shouldn't have kept that as a hard requirement, but it's not a problem
that isn't easily solved as Farshad pointed out earlier.
As for the NEW abort. I think you may wish to reconsider your
statement about a language with lower case keywords not aborting the
program. Every C++ compiler that I've used, caused the program to
dump core when there wasn't enough memory.
BTW, there is also a solution to the NEW problem that someone has submitted.
And hey, quit picking on shredded wheat. I eat that for breakfast
quite often and I like it. :-)
----------------------------------------------------------------------
Spencer Allain E-mail: spe...@era.com
Engineering Research Associates Phone : (703) 734-8800 x1414
1595 Spring Hill Road Fax : (703) 827-9411
Vienna, VA 22182-2235
----------------------------------------------------------------------
WIlliam B. Clodius
(Peter Seebach) wrote:
><snip>
>
> I do distrust anything designed by committee. Small groups can produce a
> consistent design; committees never have. If Ada, designed by a committee, is
> truly an legent language, with a solid internal concept of how everything
> sholud go together, then it is the first time in all of human history that a
> committee with a significant number of members has produced one. My
> skepticism here is pretty heavy.
>
><snip>
A few points:
1. The changes in C that produced ANSI C were done by a committee
2. The changes in C++ that produced the present draft standard were done
by a committee.
3. The detailed designs of Ada 83 and 95 were done by small teams led by
strong leaders, not by committees, albeit the general specs were set by
committees and the final design had to have the approval of a committee.
4. The most influentual programming language, ALGOL 60, was designed by a
committee.
AdaWorks
: AdaWorks (adaw...@netcom.com) wrote:
: : It is clear that Mr. Seebach is unfamiliar with the Ada model for
: : modularity.
: I'm reasonably familiar with it, and I don't see any big advantage over
: any other object-oriented language. In fact, all I really see with Ada
: is a type of "super-Pascal" with incredibly strict type-checking and
: about half the "object" features typically found with C++, Lisp, or
: Smalltalk.
I can only assume you are referring to Ada 83. Also, you indicate the
importance of "stong-typing" in Ada. As with many Ada novices you
overlook the somewhat equivalent importance of scope and visibility
rules. Once one understands these rules, it becomes clear that Ada
is much more than a "super-Pascal." It is a unique language design
which does owe a debt to Pascal as well as Algol.
: Nyet, tovarish.
Mozhet buit vui govoreetye po-russikii. Ya tozhe.
: C was not originally designed as a "one size fits all" language. It was
: designed to "program on the metal" on small-to-medium size machines. The
: fact that it was so good at what it did, and (once your eye learns to
: parse the symbols) so easy to learn and use, led to it's use in virtually
: every programming field.
Well, as I have noted earlier, C is not nearly as good for this as some
other languages, notably, FORTH, among others.
: The "after the fact" auxiliary tools you talk about -- are you saying I don't
: need analyzers or debuggers if I use Ada? I happen to be working on a
: monstrous Ada project right now, and I've never been more thankful for a
: good debugger in my life!
Perhaps the quality of your compiler, or the quality of your original
design is such that you are overly-dependent on code analyzers and
debuggers. It seems to be a function of experience with Ada, as well,
that heavy dependence on such low-level tools is important in the early
stages of familiarity with Ada, but diminishes as the experience and
confidence increases.
When I first began programming in Ada, I found myself embedding debug
code all over the place until I began to become more comfortable with
matching my expectations to those of the compiler. I think most Ada
programmers have had this experience.
: A safety razor is only good if I can take the blade out to clean or change
: it once in a while. A safety razor that has been welded shut (as in Ada)
: will become much more painfull than the straight razor.
Reasoning by analogy is always a little dangerous. Moreover, you have a
viewpoint that derives from your experience that is different from the
viewpoint that I derived from my experience.
Since you are currently working on an Ada project, I hope that you will
be able to find some positive benefit from it. The fact is that a large
number of projects have been successfully completed in Ada, Eiffel, C++,
and other high-order languages, and it rarely ever results in permanent
psychological damage to gain appreciation for their virtues as well as
their liabilities.
Jay Martin
>I would *LOVE* Modula 3 if the
>keywords were lower case, or mixed case. I abhor upper case keywords;
>it is a week's habituation to have the keywords leap out of the page when
>they're supposed to, and it takes more than a month for all-capitals to stop
>looking like shouting. (I don't know how *much* more than a month; that was
>when I gave up in disgust.)
Second vote for total hatred of all-caps keywords. In my Pascal class
centries ago our first quarter had all-caps keywords, in the second
quarter they said basically that having learned Pascal we should
now use all lower case keywords. This comes the simple fact
that keywords are not as important as user identifiers to the
programmer and thus do not need to be constantly "yelling-out"
from the source.
I generally like language designers to force stuff down the pinhead
programmer's throat with the exception of really stupid stuff.
Jay
Ron Collins
[snip]
: I can only assume you are referring to Ada 83. Also, you indicate the
: importance of "stong-typing" in Ada. As with many Ada novices you
: overlook the somewhat equivalent importance of scope and visibility
: rules. Once one understands these rules, it becomes clear that Ada
: is much more than a "super-Pascal." It is a unique language design
: which does owe a debt to Pascal as well as Algol.
Ada didn't invent private/public/protected types. With appropriate syntax,
I get the same features of scope and visibility with Object Pascal, C, C++,
and even some flavors of Fortran. I'm sure there are a host of others
that don't pop to mind immediately.
Object-orientation is not just a buzz-word, and it is not just a collection
of programming techniques. It is a software design philosophy, or a type
of programming architecture, that predates Ada by several decades. Most
of my contemporaries were using object-oriented techniques long before
"object", "encapsulation", "cohesion" and the like became buzzwords to
throw around the conference table to impress management.
: : Nyet, tovarish.
: Mozhet buit vui govoreetye po-russikii. Ya tozhe.
Da ... ya biil zhivu dva garod v'Udmurske.
Unfortunately, lack of use is taking it's toll on my memory and skills.
The best I can do these days is to try to catch the "Russian Report" on
late-nite CNN, and try to keep up with the Novosti commentator from Moscow.
: : C was not originally designed as a "one size fits all" language. It was
: : designed to "program on the metal" on small-to-medium size machines. The
: : fact that it was so good at what it did, and (once your eye learns to
: : parse the symbols) so easy to learn and use, led to it's use in virtually
: : every programming field.
: Well, as I have noted earlier, C is not nearly as good for this as some
: other languages, notably, FORTH, among others.
I agree here, with certain reservations. I still believe that C's powerfull
and (somewhat) intuitive syntax has led to it's great popularity with
the hobbyist programmer.
Professionals, IMO, have no "favorites". They dispassionately look at the
job to be done, assess the available tools, and pick the one that best
fits the job. The right tool can save weeks or months of developement
time; and time is money.
: : The "after the fact" auxiliary tools you talk about -- are you saying I don't
: : need analyzers or debuggers if I use Ada? I happen to be working on a
: : monstrous Ada project right now, and I've never been more thankful for a
: : good debugger in my life!
: Perhaps the quality of your compiler, or the quality of your original
: design is such that you are overly-dependent on code analyzers and
: debuggers. It seems to be a function of experience with Ada, as well,
: that heavy dependence on such low-level tools is important in the early
: stages of familiarity with Ada, but diminishes as the experience and
: confidence increases.
We're using one of the best Ada compiler's to be found for Sun workstations
and DEC Alpha's (Rational Apex/Ada). We have close to 40 guys working full
time for two years on this project, many of which were hired specifically
for their Ada expertise.
Debugging runs and analyzer output are not only essential developement
tools, they are required delivery items to the customer. These items
are important to show the buyer where his money is going, to explain
design and implementation snags, and verify that time and cost schedules
are being met.
: When I first began programming in Ada, I found myself embedding debug
: code all over the place until I began to become more comfortable with
: matching my expectations to those of the compiler. I think most Ada
: programmers have had this experience.
I prefer that the compiler meet _my_ expectations, not the other way around.
[snipped a bad rusty razor analogy]
: Since you are currently working on an Ada project, I hope that you will
: be able to find some positive benefit from it. The fact is that a large
: number of projects have been successfully completed in Ada, Eiffel, C++,
: and other high-order languages, and it rarely ever results in permanent
: psychological damage to gain appreciation for their virtues as well as
: their liabilities.
I get the best positive benefit possible -- I get paid :). As for the
psychological damage ... well, the doctor says when we complete the
electro-shock therapy, that maybe I can start eating solid foods again.
: Richard Riehle
: adaw...@netcom.com
:
: --
-- Collins --
-----
The views expressed here are mine alone.
Ron Collins/Hughes Aircraft Company/M20,P20/Tucson Az 85706
rcol...@thor.tu.hac.com col...@seagull.rtd.com
----
Steve Wootton
>C encourages the programmer to avoid stupid sloppiness in the good ol'
>Darwinian fashion. You write good code or suffer later. :)
But this isn't what really happens. What really happens is that the code starts
working "well enough," you collect your accolades, and then you move on to a
new project. The poor saps, er, uh, "new hires" who get assigned to maintain
the project after you leave are the ones who suffer.
--
Steve Wootton -- s-wo...@ti.com
Occasional Member of Suffering Maintainers International
Spencer Allain
NNTP-Posting-Host: qcd.lanl.gov
In article <dewar.815110989@schonberg>, de...@cs.nyu.edu (Robert Dewar)
writes:
|> Lawrence says:
|>
|> "I understood Doom to be written in ANSI C, which is why it has been so
easily
|> ported to many platforms."
|>
|> Two points. First writing in ANSI C specifically is NOT a very good path
|> to portability. Compliance with Ansi C is by no means universal.
The statement is VERY misleading.
There are very few universals: but almost every platform has good ANSI C
compilers. Can you think of one platform to which you cannot port ANSI C
code? (They do exist: but they are rare!)
Cheers
Tanmoy
--
Yes, portable and non-portable. Most people equate portable with
"yes I can compile it on many platforms". That is definitely one
type of portability.
The other type of portability involves encapsulation of system calls,
dependencies upon size of data types, implicit coercion of types that
may or may not be of compatible types dependent upon structure sizes
on different hardware, and a whole slew of other things that programmers
who have to port applications need to deal with.
I'm sick of hearing in 7 newsgroups, arguments whether ANSI-C is portable
or not. Followups are going to comp.lang.c
Maybe a whole newsgroup should be devoted to portability issues --
involving compiler availability, compilier compatibility, system
dependencies inherent in a language, type size dependencies inherent
in a language, the amount of encapsulation support inherent in a
language, how many things the language does behind the programmers
back, etc that affect portability.
I would be all for such a newsgroup, but this thread has devolved from
"Is C/C++ the dominant teaching language?" to "Is ANSI-C portable?",
and has outlived it's relevance to most of the newsgroups being posted
to.
Lawrence Kirby
>Lawrence says:
>
>"I understood Doom to be written in ANSI C, which is why it has been so easily
>ported to many platforms."
>
>Two points. First writing in ANSI C specifically is NOT a very good path
>to portability.
However it is probably the best path to portability that currently exists.
>Compliance with Ansi C is by no means universal.
However it exists for virtually every platform for which there is still
active development. I can't think of any other language standard which is
more universally implemented. Well, perhaps FORTRAN or COBOL take that crown
(I don't know) but C is still a safe bet for portability across the platforms
that most people are likely to encounter.
>Second, the difficulty in porting a program like DOOM, has far more to do
>with graphic libraries than with what language it is written in!
That's my point - since that vast majority of code is written in portable
ANSI C there is no difficulty at all on porting it - you just recompile
it on the new platform. It is only a small part of the graphics code (and
other I/O interfaces) that needs to be rewritten. Converting Doom from C
to ADA would be a vastly more difficult process than porting it between
systems that support ANSI C.
Bill Seurer
|> In article <dewar.814932130@schonberg>, Robert Dewar <de...@cs.nyu.edu> wrote:
|> >And of course the crucial words in this paragraph are "smallish scale"
|>
|> >WRiting large programs has almost nothing in common with writing small
|> >programs. Of course you can write in any language, including assembly
|> >language, or even absolute machine langauge on a "smallish scale".
|>
|> If that's how you write large programs, you have missed the concept of
|> modular programming entirely. I can produce 1,000 line pieces of code I
|> can trust, and I can put hundreds of them together.
|>
|> How many millions of lines do you need to have before it's big enough?
|> It'll still be made of small, bug-free chunks, or badly written.
You can write any number of chunks of code of any size you choose that you
trust BUT that doesn't mean much as far as all of them working together
goes.
--
- Bill Seurer ID Tools and Compiler Development IBM Rochester, MN
Business: BillS...@vnet.ibm.com Home: BillS...@aol.com
mma...@chattanooga.net
>
>Seriously, though, I think you place too much reliance on tools, and too
>little on understanding.
>
of safety devices, consider them as being there to increase your reach and strength
by orders of magnitude. An analogy: if you are given the task of digging a ditch 6 feet
deep and 100 feet long, would you do it with your hands (assembler), would you use
a hand shovel (C), or would you use a backhoe (Eiffel, Ada, etc.)? One of the
fundamental facts of the software industry, that all of the newer, more complex
languages seem to try to address, is that the activity of software creation and
maintenance is *extremely* manual-labor intensive. Of course, though, with power
also comes danger: if, using our previous analogy, if you were about to cut a 6 inch
bundle of fiber optic cable with your backhoe, wouldn't you want it to maybe warn
you of that fact?
>
>Just as most maintenance patches are simply
>band-aids, ignoring the fundemental design flaws, wrapping incompetent
>programmers in tools that protect them is just a symptom patch, not addressing
>the fundemental problem of programmers who do not spend at least a fair amount
>of time being mentored in the art of computer programming.
>
>I think what this field needs is apprenticeships.
>
I can't argue overmuch here: having observed (and occasionally participated in) the
software development process over the last 19 years (in the business realm), most
of the programmers I have seen have been insufficiently trained in their craft (at
least when compared to anyone practicing some type of hard engineering discipline).
The good practicies are usually confined to just a few people (and tend to move on
with them), the bad practices, almost like an incurable disease, seem to hang around
forever and spread like germs.
And all of these problems are exacerbated and compounded by management, who
have no fundamental understanding of the software development process, who would
(to meet thier deadlines) rather have it done now that to have it done right, and who
believe that they can successfully "negotiate" deadlines (and also "negotiate"
the effects of natural law...).
Peter Seebach
> If you rely on second hand uninformed opinions to form your own judgments,
> then it is not surprising you end up with some of the your conclusions!
... It depends on what you consider "uninformed". I generally count it as an
informed opinion if someone's been using a language for at least a year or
two.
> ... as is your ignorance -- neither Ada 83 nor Ada 95
> was designed by committee.
> This is a common misconception, but is complete nonsense. Their may be
> things in Ada you don't like, but in almost every case, you have to lay
> the blame (and the credit!) at the door of the chief designer and a small
> team of people closely working with that designer.
Okay; who was the chief designer of the *language*? Not the individual parts,
but the overall scheme? If that was done by a committee, no amount of
brilliance on the implementation of the parts can fix it, any more than my
hypothetical bug free modular code can make C a safe language.
> Should be quite possible to port GNAT to your machine. You will have to know
> what you are doing to accomplish it, but lots of people have successfully
> achieved ports. If you are as good as you think you are, you should have
> no trouble!
My ego accepts your humbly offered praise. :)
Would you be so kind as to drop me a line when that release
happens? I am rather curious...
Peter Seebach
>Peter said:
>>But I dunno; generally, if a bug takes me more than an hour to track down,
>>I consider myself sloppy. I have good debugging code in most of my work,
>>so I turn on debugging, and just see what I get...
> If all you are doing is writing little C programs of a couple of hundred
> lines, then even an hour is a long time to find a bug, and it is quite
> reasonable to aim at writing such small programs bug free in the first
> place. However, this has almost nothing whatsoever to do with locating
> complex interaction bugs in large systems.
The hour metric is generic; I used it also when debugging more than a million
lines of the *WORST* C++ you could imagine. (Although I gave myself 2 hours,
because the software took wore than 10 minutes to start up.)
By worst, I mean that they made *ALL* data members private, and then wrote
get() and put() member functions for *every* data member. If they had
just written it with public members, it would have been just as readable.
>>However, I personally like the behavior of = and ==. I like being able
>>to put assignment anywhere. :)
> I am sure you do! No doubt you have no concern about side effects. Again
> in small programs it hardly matters.
I don't think you follow; I consider side effects a *feature*. I like being
able to use them when I want them, and avoid them otherwise. It's notational
convenience. But I prefer
x = y = z = 0;
to having to break them all out.
> I once heard someone say that examining the problems of writing small
> programs to learn about how to write big problems was like NASA having
> an astronaut climb a tree ("well he's closer to the moon, we are making
> progress!")
I write big programs too. Not bigger than one person can comfortably do in a
month or two; no more than about 200k in C. I debug much larger programs than
that.
Tore Joergensen
...lot's of stuff deleted...
: It's notational convenience. But I prefer
: x = y = z = 0;
: to having to break them all out.
I don't agree. If you don't know the rules for the language, it will make
it very hard to read. If you program in C, and then a fantastic algorithm
is published in some language zxy, I don't think you would like to use
time to figure out if the statement means
x=y; y=z; z=0;
or if it means
z=0; y=z; x=y;
I guess everything will be 0 in C, but it doesn't have to mean that in
another language (and the other option is just as logic).
--
+-------------------------+-------------------------------------------+
| Tore B. Joergensen | e-mail : to...@lis.pitt.edu |
| Centre Court Villa | web : http://www.pitt.edu/~tojst1 |
| 5535 Centre Avenue # 6 | |
| Pgh, PA 15232, USA | Norwegian MSIS-student at Univ. of Pgh. |
+-------------------------+-------------------------------------------+
Rick Sutcliffe
bl...@zayin.cs.princeton.edu (Matthias Blume) wrote:
> In article <rsutc-31109...@rsutc.twu.ca> rs...@twu.ca (Rick
Sutcliffe) writes:
> >
> Wait a minute. I LIKE Shredded Wheat. I also like Modula-2 and its
> progeny. Not only do neither taste awful, the restrictions help the
> compiler to help the programmer to write bvetter and more maintainable
> code.
>
> Wait! I thought we are talking about upper-case keywords. In what
> way do they ``help the compiler to help the programmer to write
> better and more maintainable code''?!
>
Pardon me; I thought that with your last statement you had broadened the
discussion to one of general language philosophy. However, having taught
languages and programming for some 15 years, I believe that upper case
keywords do reduce the number of errors, or at least they increase the
percentage of errors that a compiler can find (for students, and for me.)
Arnt Gulbrandsen
Lawrence Kirby <fr...@genesis.demon.co.uk> writes:
> In article <wclodius-311...@clodius.lanl.gov>
> wclo...@lanl.gov "WIlliam B. Clodius" writes:
> >1. The changes in C that produced ANSI C were done by a committee
>
The committee very wisely decided to do that, which proves that
sometimes, a committee will act very wisely.
--Arnt
Tanmoy Bhattacharya
writes:
|> compilers. Can you think of one platform to which you cannot port ANSI C
|> code? (They do exist: but they are rare!)"
|>
|> personal experience. On the current release of SunOS, the sprintf function
|> is non-ANSI conforming, it returns the buffer address, rather than the
|> number of characters written.
|>
|> Note that a bug like this in the library is particularly unfortunate
because
|> it takes out ALL C compilers on that particular target, unless they supply
|> their own libraries.
Non sequitur. There are free implementations of the ANSI library from gnu (I
haven't actually installed them anywhere: so I do not know how good they
are). The default sun compiler is of course completely non-standard: it
crashes on free(NULL); <stdlib.h> does not define EXIT_SUCCESS etc., and the
default sun compiler is K&R I, not ANSI.
I never said or meant that the default implementation is standard conforming.
The point is that ANSI implementations are almost always available easily:
and they are becoming easier every day. In addition, excepting a small
number of such problems, it is currently easier to use than other portable
solutions.
Cheers
Tanmoy
--
tan...@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tan...@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003 voice: 1 (505) 665 4733 [ Home: 1 (505) 662 5596 ]
Tanmoy Bhattacharya
writes:
<snip>
|> : x = y = z = 0;
|> : to having to break them all out.
|>
|> I don't agree. If you don't know the rules for the language, it will make
|> it very hard to read. If you program in C, and then a fantastic algorithm
|> is published in some language zxy, I don't think you would like to use
|> time to figure out if the statement means
|> x=y; y=z; z=0;
|> or if it means
|> z=0; y=z; x=y;
Sure, but if you see x^y in language zxy, is it exponentiation or exclusive
or? When you see x%y what does it mean? Comeon, you cannot follow an
algorithm in a different language without knowing the basics of that
language.
And as a curiosity, is there a language which uses `x = y = z = 0' to mean `x
= y; y = z; z=0;'
|> I guess everything will be 0 in C, but it doesn't have to mean that in
|> another language (and the other option is just as logic).
In general you would be correct, but in this case I do not think that the
other option will be just as common (it may be `just as logic' depending on
what you mean by that: but if it is uncommon across the spectrum of
languages, I consider it likely that your view is not shared by others.)
The reason is that most languages will probably classify assignment as a
binary operator and parse the above as either
((x = y) = z) = 0
or as
x = (y = (z = 0))
For your interpretation to make sense, the result of an assignment has to
refer to the assignable object on the rhs of the assignment (which hopefully
is usually an expression and not an object at all)! It is certainly possible
that a language will do this: but the situation is pretty bizarre.
I think multiple assignments being misinterpreted this way is less likely
than misinterpreting a + b * c as (a+b)*c.
Daniel P Hudson
de...@cs.nyu.edu (Robert Dewar) wrote:
> Ron Collins said
> "Ada didn't invent private/public/protected types. With appropriate
> syntax,
> I get the same features of scope and visibility with Object Pascal, C,
> C++,
> and even some flavors of Fortran. I'm sure there are a host of others
> that don't pop to mind immediately."
> Would you care to share with us how in C you manage to duplicate the
> concept of a private type, including fully hiding its implementation?
pre-processor hacks I'm sure.
AdaWorks
: (Peter Seebach) wrote:
: ><snip>
: >
: > I do distrust anything designed by committee. Small groups can produce a
: > consistent design; committees never have. If Ada, designed by a committee, is
: > truly an legent language, with a solid internal concept of how everything
: > sholud go together, then it is the first time in all of human history that a
: > committee with a significant number of members has produced one. My
: > skepticism here is pretty heavy.
: >
: ><snip>
Mr. Seebach,
It is important to recognize that most important software is now
developed by teams. Such teams include designers, architects,
quality assurance people, independent testing organizations, documentation
specialists, and even programmers.
There are subtle differences between a committee and a team. I have had
the privilege of serving as a committee member on occasion and know about
the issues that concern you for that model of group enterprise. However,
I have also served as a team member and can assure you that
participating as a member of a well-managed team is a true delight.
Ada 95 was a team effort. Different members of the team had different
responsibilities. The team also received criticism and suggestions
from the software community at-large, including a fair representation
of people who are not Ada fanatics.
A programming language design always has to consider trade-offs between
complexity and simplicity. There is the Einsteiniam counsel to keep
it "as simple as possible, but not simpler." But it is difficult to
know where to draw the line.
One issue in a programming language is how much of the work do you want
the compiler to do to help you get it right. In C, the compiler does
very little. One may decide to use additional tools, but C is not a
language designed to give a large role to the compiler. Ada, Eiffel,
and C++ opt for giving the compiler a larger role. Neither approach
is inherently evil, just different.
The art of compiler design has advance over the past ten or fifteen
years to the point where truly excellent compilers do as well as
low-level options such as C or Assembler for many applications. However,
there are still bad compilers just as there are bad C and Assembler
programmers.
So why are we making all this noise about C versus Ada, or C versus
Eiffel, or C versus C++? A programming language is just a tool and
I am just a carpenter. In my toolbox I have some Ada, some C, some
COBOL, and a bunch of other tools. I need to know how and when to
use which tool. Sometimes C is the right tool. Sometimes it is not.
But a good craftsperson does know when to use a tool that is right for
the job at hand. C is like the "knucklebuster" I used to use on a
cold Pennsylvania Saturday before I could afford a good set of
socket wrenches. Boyoboyoboy, am I ever glad I finally discovered
the virtue of socket wrenches - just as I am glad I have found out
how nice it is to use a language such as Ada when I really want to
do the job right.
Robert Dewar
"Non sequitur. There are free implementations of the ANSI library from gnu (I
haven't actually installed them anywhere: so I do not know how good they
are). The default sun compiler is of course completely non-standard: it
crashes on free(NULL); <stdlib.h> does not define EXIT_SUCCESS etc., and the
default sun compiler is K&R I, not ANSI."
Yes, well perhaps you should try the effort of "installing" these libraries
on a new system. I would not actually use the word installing for what is
often a very tricky piece of coding. Remember that the C library is
standing in for a Unix (or NT or whatever API), and there is no standard
for what is behind (i.e. how you actually call the system). In fact in
the case of NT, Microsoft does not document how to call the system, and
it has been QUITE a struggle (ask Tom Griest!)
You seem to think you can just time "make free-library", but it ain't that
simple!
Yes, precisely the default sun compiler is quite non standard. The point
I was making was that it is quite possible to write portable C code that
does NOT require ANSI compatiibility, but which in fact compiles on almost
all C compilers in common use (GCC is carefully written with this in mind,
e.g. it uses macros to determine whether or not to use prototypes).
So all I was contesting was the idea that ANSI was the best basis of
portability in the C world, it is not!
Bjarne Stroustrup <9758-26353> 0112760
se...@solutions.solon.com (Peter Seebach) from Usenet Fact Police (Undercover) writes:
> WIlliam B. Clodius <wclo...@lanl.gov> wrote:
> >1. The changes in C that produced ANSI C were done by a committee
>
> Yes, and we have trigraphs to show for it. But the basic language and
> syntax *evolved during use* and were designed by a small group.
>
> >2. The changes in C++ that produced the present draft standard were done
> >by a committee.
>
> And in TDOEOC++, Stroustrup admits in a few places that committee pressures
> made for poor results. Certainly, there are a fair number of features in
> C++ today that violate the original stated design principles. I'd like
> to see where it would have gone if it had been kept away from the committee
> until it seemed ready.
In a FEW places, yes, but generally, what has been done to C++ during the
years of C++ standards work has been good. I'm very pleased with it.
My opinions can be found in some detail in ``The Design and Implementation
of C++.'' So can descriptions of all major C++ features and design decisions.
I think this longish quote from a recent article that I wrote for the C++
Report is relevant:
Introduction
As C++ programmers, we already feel the impact of the
work of the ANSI/ISO C++ standards committee.
Yet the ink is hardly dry on the first official draft
of the standard.
Already, we can use language features only hinted at in the ARM
and ``The C++ Programming Language (second edition),''
compilers are beginning to show improved compatibility,
implementations of the new standard library are appearing, and the
recent relative stability of the language definition is allowing
extra effort to be spent on implementation quality and tools.
This is only the beginning.
We can now with some confidence imagine the post-standard C++ world.
To me, it looks good and exciting. I am confident that it will give
me something I have been working towards for about sixteen years:
a language in which I can express my ideas directly; language
suitable for building large, demanding, efficient, real-world systems;
a language supported by a great standard library and effective tools.
I am confident because most of the parts of the puzzle are already
commercially available and tested in real use.
The standard will help us to make all of those parts available to
hundreds of thousands or maybe even millions of programmers.
Conversely, those programmers provide the community necessary to
support further advances in quality, programming and design
techniques, tools, libraries, and environments.
What been achieved using C++ so far have exeeded my wildest dreams
and we must realistically expect that the best is yet to come.
The Language
C++ supports a variety of styles.
In other words: C++ is a multi-paradigm programming language.
The standards process strengthened that aspect of C++ by providing
extensions that didn't just support one narrow view of programming,
but made several styles easier and safer to use in C++.
Importantly, these advances has not been bought at the expense of
run-time efficiency.
At the beginning of the standards process templates were considered
experimental; now they are an integral part of the language,
more flexible than originally specified, and an essential foundation
for standard library. Generic programming based on templates is now
a major tool for C++ programmers.
The support for object-oriented programming (programming using class
hierarchies) was strengthened by the provision for run-time type
identification, the relaxation of the overriding rules, and
the ability to forward declare nested classes.
Large-scale programming -- in any style -- received major new support
from the exception and namespace mechanisms.
Like templates, exceptions were considered experimental at the
beginning of the standards process.
Namespaces evolved from the efforts of
many people to find a solution to the problems with name clashes and
from efforts to find a way to express logical groupings to complement
or replace the facilities for physical grouping provided by the
extra-linguistic notion of source and header files.
Several minor features were added to make general programming safer and
more convenient by allowing the programmer to state more precisely the
purpose of some code. The most visible of those are the bool
type, the explicit type conversion operators, the ability to declare
variables in conditions, and the ability to restrict user-defined
conversions to explicit construction.
A description of the new features and some of the reasoning that led to
their adoption can be found in D&E. o can discussions of older features
and of features that were considered but didn't make it into \*C.
The new features are the most visible changes to the language.
However, the cumulative effect of minute changes to more obscure
corners of the language and thousands of clarifications of its
specification is greater than the effect of any extension.
These improvements are essentially invisible to the programmer
writing ordinary production code, but their
importance to libraries, portability, and compatibility of
implementations cannot be overestimated.
The minute changes and clarifications also consumed a large
majority of the committee's efforts.
That is, I believe, also the way things ought to be.
For good and bad, the principle of C++ being ``as close to C
as possible -- and no closer'' was repeatedly re-affirmed.
C compatibility has been slightly strengthened, and the remaining
incompatibilities documented in detail.
Basically, if you are a practical programmer rather than a conformance
tester, and if you use function prototypes consistently,
C appears to be a subset of C++. The fact that every example in K&R2
is (also) a \*C program is no fluke.
Coherence
ISO C++ is not just a more powerful language than the \*C presented in
``The \*C Programming Language (second edition);'' it is also more
coherent and a better approximation of my original view of what
C++ should be.
The fundamental concept of a statically typed language relying on
classes and virtual functions to support object-oriented programming,
templates to support generic programming, and providing low-level
facilities to support detailed systems programming is sound.
I don't think this statement can be proven in any strict sense,
but I have seen enough great C++ code and enough sucessful
large-scale projects using C++ for it to satisfy me of its validity.
You can also write ghastly code in C++, but so what?
We can do that in any language.
In the hands of people who have bothered learning
its fairly simple key concepts, C++ is helpful in guiding
program organization and in detecting errors.
C++ is not a ``kitchen sink language'' as evil tongues are fond
of claiming. Its features are mutually reinforcing and all have a
place in supporting C++'s intented range of design and programming
styles. Everyone agrees that \*C could be improved by removing
features. However, there is absolutely no agreement which features
could be removed. In this, C++ resembles C.
During standardization, only one feature that I don't like was added.
We can now initialize a static constant of integral type with a
constant expression within a class definition.
For example:
class X { // in .h file
static const int c = 42;
char v[c];
// ...
};
int X::c = 42; // in .c file
I consider this half-baked and prefer:
class X {
enum { c = 42 };
char v[c];
// ...
};
I also oppose a generalization of in-class initialization as an
undesirable complication for both implementors and users.
However, this is an example where reasonable people can agree
to disagree. Standardization is a democratic process, and I
certainly don't get my way all the time -- nor should any person
or group.
The paper is called ``A perspective on ISO C++'' and the rest of the paper
- the main bulk - is code examples illustrating my points above.
ISO C++ is a better language than the language I provided as the starting
point for the committee. However, no major feature that was outside the set
I considered suitable for C++ long before standardization was considered
was added. Furthermore, as the chairman of the standard's committee's
working group for extensions, I worked on every proposed extension and
was a major contributor to every major extension.
No language is perfect, of course, and the committee made a few mistakes
but so did when I didn't have a committee to help and distract me. So I
would have if I had had a few more years to polish C++ before the start
of standardization.
It is healthy and proper for a programming language to grow based on
experiment, use, and discussion. This C++ did, and the standards committee
was a major focus for that work. C++ didn't grow randomly, it grew within
my view of what it was supposed to be.
- Bjarne
Lawrence Kirby
> Robert said
>
> >First writing in ANSI C specifically is NOT a very good path
> >to portability.
>
> Lawrence said
>
> >However it is probably the best path to portability that currently exists.
>
>I disagree, if you want to write portable C, you don't want to blindly
>follow the ANSI standard, the implementations are simply not conformant
>enough.
There are a few systems left where the libraries aren't quite ANSI conformant.
However it is pretty trivial to port even to these.
>Instead you write in a pretty well-understood subset that stays
>away from problem areas, particularly runtime routines that are not
>universally implemented.
For example?
For instance there are many C systems that
>still don't support all the ANSI versions of the standard runtime
>library, and on the other hand you can safely use unlink even though
>it is not in the ANSI standard. GCC itself is carefully programmed in
>this highly portable style, and is MUCH more portable than if it
>required full ANSI compliance.
That used to be true but no longer. Actually gcc is a somewhat special case
since it will be naturally targetted to provide an ANSI C compiler on systems
that don't otherwise have one. Mostly now however its value is as an
alternative ANSI compiler, a C++ compiler or a free compiler.
...
> >That's my point - since that vast majority of code is written in portable
> >ANSI C there is no difficulty at all on porting it - you just recompile
> >it on the new platform. It is only a small part of the graphics code (and
> >other I/O interfaces) that needs to be rewritten. Converting Doom from C
> >to ADA would be a vastly more difficult process than porting it between
> >systems that support ANSI C.
>
>First, I think perhaps you don't know DOOM very well,
I know Doom well enough to win a recent international Doom competition. :-)
it is *very* graphics
>intensive, and furthermore, gets its performance from a lot of direct
>graphics mucking at the hardware level, I suspect that "a small part of
>the graphics code" is not such a small part!
The system dependent code needs to do little more than the low level
graphics plotting and dealing with other interfaces such as the the
pallette. This need no more than a small part of the graphics code.
Other time critical parts are no doubt optimised for speed in assembley
but sensible coding practices would suggest that even these were written
first in ANSI C (and for instance the SGI port probably doesn't need to
change it.)
>Of course it is easier to port DOOM from one C platform to another than
>to rewrite in Ada (that's a strawman, no one claimed the contrary). I
>think it is clear that it would be as easy or easier to port a similar
>program that was written in Ada, though we are certainly not yet at the
>stage where Ada 95 is universal (but it is surprising how many GNAT ports
>are appearing now!)
That's the point. If a language doesn't not exist on a wide range of
platforms you cannot write truely portable code in it. With DSPs you
could probably port Doom direct to DSPs or even perhaps some graphics
processors!
>P.S. Lawrence, save your little finger some extra work on the shift key,
>the name of the language is Ada, it is a woman's name. ADA is the
>American Dental Association, or any one of a number of organizations
>using this acronym, and translating Doom into that kind of ADA would
>certainly be most trying :-)
Wasn't Ada the woman who got most of the credit for COBOL?
Lawrence Kirby
to...@lis.pitt.edu "Tore Joergensen" writes:
>Peter Seebach (se...@solutions.solon.com) wrote:
>...lot's of stuff deleted...
>: It's notational convenience. But I prefer
>: x = y = z = 0;
>: to having to break them all out.
>
>I don't agree. If you don't know the rules for the language, it will make
>it very hard to read.
If you don't know the rules of a language you have no business maintaining
code in it.
>If you program in C, and then a fantastic algorithm
>is published in some language zxy, I don't think you would like to use
>time to figure out if the statement means
> x=y; y=z; z=0;
>or if it means
> z=0; y=z; x=y;
>I guess everything will be 0 in C, but it doesn't have to mean that in
>another language (and the other option is just as logic).
Publishing an algorithm to an audience you can't guarantee knows the
language well is a totally different proposition to writing code that is
to be maintained by other programmers of your language. Whatever the
language. It requires a different approach (possibly even a different
notation).
Lawrence Kirby
>In article <475rf0$h...@solutions.solon.com>, se...@solutions.solon.com
>(Peter Seebach) wrote:
>
>><snip>
>>
>> I do distrust anything designed by committee. Small groups can produce a
>> consistent design; committees never have. If Ada, designed by a committee,
> is
>> truly an legent language, with a solid internal concept of how everything
>> sholud go together, then it is the first time in all of human history that a
>1. The changes in C that produced ANSI C were done by a committee
However it was mostly a case of formalising existing practice.
>2. The changes in C++ that produced the present draft standard were done
>by a committee.
Can that be described as a 'consistent design'?
>3. The detailed designs of Ada 83 and 95 were done by small teams led by
>strong leaders, not by committees, albeit the general specs were set by
>committees and the final design had to have the approval of a committee.
How much did these teams work together? That could be a recipe for a
patchwork of highly inconsistent parts.
>4. The most influentual programming language, ALGOL 60, was designed by a
>committee.
That embodied a lot of innovative ideas but wasn't a particularly successful
language.
Robert Dewar
>First writing in ANSI C specifically is NOT a very good path
>to portability.
Lawrence said
>However it is probably the best path to portability that currently exists.
I disagree, if you want to write portable C, you don't want to blindly
follow the ANSI standard, the implementations are simply not conformant
away from problem areas, particularly runtime routines that are not
still don't support all the ANSI versions of the standard runtime
library, and on the other hand you can safely use unlink even though
it is not in the ANSI standard. GCC itself is carefully programmed in
this highly portable style, and is MUCH more portable than if it
required full ANSI compliance.
This will change in time, but we are certainly not there yet!
Robert said
>Second, the difficulty in porting a program like DOOM, has far more to do
>with graphic libraries than with what language it is written in!
Lawrence said
>That's my point - since that vast majority of code is written in portable
>ANSI C there is no difficulty at all on porting it - you just recompile
>it on the new platform. It is only a small part of the graphics code (and
>other I/O interfaces) that needs to be rewritten. Converting Doom from C
>to ADA would be a vastly more difficult process than porting it between
>systems that support ANSI C.
First, I think perhaps you don't know DOOM very well, it is *very* graphics
intensive, and furthermore, gets its performance from a lot of direct
graphics mucking at the hardware level, I suspect that "a small part of
the graphics code" is not such a small part!
Of course it is easier to port DOOM from one C platform to another than
to rewrite in Ada (that's a strawman, no one claimed the contrary). I
think it is clear that it would be as easy or easier to port a similar
program that was written in Ada, though we are certainly not yet at the
stage where Ada 95 is universal (but it is surprising how many GNAT ports
are appearing now!)
Rick Stanley
>"There are very few universals: but almost every platform has good ANSI C
>compilers. Can you think of one platform to which you cannot port ANSI C
>code? (They do exist: but they are rare!)"
>You only asked for one example (I could give more). This one comes from
>personal experience. On the current release of SunOS, the sprintf function
>is non-ANSI conforming, it returns the buffer address, rather than the
>number of characters written.
>Note that a bug like this in the library is particularly unfortunate because
>it takes out ALL C compilers on that particular target, unless they supply
>their own libraries.
Wouldn't gcc ported to the SunOS system be an answer to this? Doesn't
gcc provide its own version of the standard libraries?
--
Rick Stanley | RSI
stan...@acf4.nyu.edu | (212) 740-6600
Information Technologies Institute | C++ & C Language
New York University NYC, NY USA | Programming, Training, Consulting
Robert Dewar
gcc provide its own version of the standard libraries?"
In practice, gcc uses the native library, precisely because you want gcc
to look like the native C as much as possible, and of course some library
units are really OS calls and the ikmplementation is non-portable anyway.
Yes, there are standard portable libraries, and using these would be one
way to improve portability, but it is a tricky issue (one person's nice
portable behavior is another person's bug!)
Richard Bielak
Nasser Abbasi <nab...@qualcomm.com> wrote:
[...]
>
>There are bugs that are time-dependant, or relating to memory usage that
>can be very hard to find. Most of these I found exist in asynchronous
>programming/ multi-threaded large software.
>
>Actually using debugging statements or running the program when build
>with debug mode on, can sometimes hide the bug you are trying to find
>away (by say slowing down the program).
Yeah. Those are called "Heisen-bugs" - they disappear when you try to
oberve them ;-).
The bugs that you _reproduce_ in one hour are easy to fix. Try fixing
bugs that occur once every six months and no one can reproduce them.
...richie
--
* ric...@ritz.mordor.com - at home | Richie Bielak *
* ric...@calfp.com - at work | *
* --- Thomas Kuhn's bumper sticker: "Shift happens" --- *
*------------------------------------------------------------------*
Robert Dewar
a = b = c = d = e = 0;
is that if during maintenance you have to change, say c to have a different
value, then the change is not so straightfoward. I see how the above helps
writers of the code, but I don't think it is an overall plus for readers
and maintainers, and I don't care about writers!
Ron Collins
: Peter Seebach (se...@solutions.solon.com) wrote:
: ...lot's of stuff deleted...
: : It's notational convenience. But I prefer
: : x = y = z = 0;
: : to having to break them all out.
: I don't agree. If you don't know the rules for the language, it will make
If you don't know the rules (syntax), then the whole point is moot. You
worry about convenience only when you are completely familiar and comfortable
with a language. If you don't know the language, then convenience (and
inconvenience) mean nothing.
[snip]
: I guess everything will be 0 in C, but it doesn't have to mean that in
: another language (and the other option is just as logic).
I don't think I get your point... would you clarify please?
AdaWorks
Ron Collins (col...@thor.tu.hac.com) wrote:
: [snip]
: Ada didn't invent private/public/protected types. With appropriate syntax,
: I get the same features of scope and visibility with Object Pascal, C, C++,
: and even some flavors of Fortran. I'm sure there are a host of others
: that don't pop to mind immediately.
Somewhat more difficult with C. Also, Ada predates Object Pascal which
has a less robust model for encapsulation and separate compilation. C++
is another matter. It does, indeed, provide a good environment for
development, but it supports all of the most dangerous features of C.
You left out Eiffel. If you are not familiar with Eiffel, i recommend
it as an excellent language for study.
: Object-orientation is not just a buzz-word, and it is not just a collection
: of programming techniques. It is a software design philosophy, or a type
: of programming architecture, that predates Ada by several decades. Most
: of my contemporaries were using object-oriented techniques long before
: "object", "encapsulation", "cohesion" and the like became buzzwords to
: throw around the conference table to impress management.
Actually, object-orientation is a still emerging model for software
design and construction. There are certain aspects of OO about which
there is agreement, but a survey of the literature will reveal that many
new ideas are proposed by OO experts as more is discovered about this
fascinating notion.
The OO canon is not yet in its final form.
When you say that most of your contemporaries were using object-oriented
techniques, I cannot dispute your claim. However, Bertrand Meyer proposes
a notion of "Linguistic Modular Continuity" which asserts that one ought
to have direct language support for a method to get maximum benefits from
using that method.
Languages with such direct support provide a service by aiding the designer
in the process of reasoning about the method. This is why, for example,
we have special notations for different branches of mathematics. I can
certainly use my standard English to reason about Topology, but it is
helpful to have a notation that helps me in that reasoning process.
One could counter that such a notation constrains me to thinking only
in terms of that notation. Not so, as my ninth grade algebra use to say.
The notation does help me discover what I do not understand, and I can
proceed from there.
The idea from the preceeding paragraph is somewhat analagous to the
issues associated with "strong typing." It is easier to relax a language
that is strongly typed, such as Ada, than it is to strengthen a weakly
type language such as C.
: I agree here, with certain reservations. I still believe that C's powerfull
: and (somewhat) intuitive syntax has led to it's great popularity with
: the hobbyist programmer.
Very few of our clients are "hobbyist" programmers. In general, hobby
programs are not safety-sensitive.
: Professionals, IMO, have no "favorites". They dispassionately look at the
: job to be done, assess the available tools, and pick the one that best
: fits the job. The right tool can save weeks or months of developement
: time; and time is money.
I agree.
: We're using one of the best Ada compiler's to be found for Sun workstations
: and DEC Alpha's (Rational Apex/Ada). We have close to 40 guys working full
: time for two years on this project, many of which were hired specifically
: for their Ada expertise.
You know better than I how relevant your tools and experience are to
your project. I assume that, with so much available experience, you
are doing a creditable job on the task at hand.
: Debugging runs and analyzer output are not only essential developement
: tools, they are required delivery items to the customer. These items
: are important to show the buyer where his money is going, to explain
: design and implementation snags, and verify that time and cost schedules
: are being met.
I admit that debuggers are essential. So are code analyzers. My thought,
and it is widely shared by others in the software community, is that one
can become too dependent on such tools.
When I used to have to wait for two days for the results of a compile
before I could even consider running a test, I was more careful with
my design and deskchecking. As I began to have faster turnaround, and
then total interaction, and then wonderful debugging tools, I found
myself relying on those tools as a substitute for my own reasoning
ability. I have heard the same story from others. I do not mean to
suggest that your team is as sloppy as I can be, but there may be some
virtue in taking a look at this.
Respectfully,
Scott Schwartz
| As for the NEW abort. I think you may wish to reconsider your
| statement about a language with lower case keywords not aborting the
| program. Every C++ compiler that I've used, caused the program to
| dump core when there wasn't enough memory.
On the contrary. I've never seen a C++ compiler that did that. I've
also never seen a C++ compiler that didn't let you override the
default new_handler. Certainly this is true of Cfront and G++.
Norman H. Cohen
(Peter Seebach) writes:
|> >3. The detailed designs of Ada 83 and 95 were done by small teams led by
|> >strong leaders, not by committees, albeit the general specs were set by
|> >committees and the final design had to have the approval of a committee.
|>
|> Exactly; it is the *general design* that most needs a specific goal, because
|> it is the overall design that makes or breaks a tool. A bad design will
|> frustrate any amount of after the fact fixing; compare MSDOS to anything.
|> A good design will make a few warts, even significant ones, workable.
The general design of Ada is the product of one person, Jean Ichbiah.
The statement that "the general specs were set by committees" is
incorrect. There were a set of general REQUIREMENTS, a few pages long,
that were developed by committee. Four very different language designs
were developed competitively in repsonse to these requirements, and one
of them evolved into Ada.
|> C's warts are tolerable because an experienced programmer can often
|> avoid them completely. In Pascal (or Ada), there is no escape.
This is utter nonsense.
Concerning C: A colleague of mine, an extremely experienced C programmer,
is writing a long book describing machinations that he goes through to
protect himself against C's warts. At first he described it as a book of
programming techniques, but I pointed out to him that most of the
practices he described were aimed specifically at compensating for
weaknesses of C, and would be unnecessary in Ada.
Concerning Ada: Please be specific. What "inescapable warts" do you have
in mind? (The more of this thread I read, the more I become convinced
that you are really quite ignorant of Ada, and just repeating canards
that you have heard.)
--
Norman H. Cohen nco...@watson.ibm.com
Norman H. Cohen
(Peter Seebach) writes:
|> Well, most compilers can be gotten to warn for any use of = anyplace
|> where == would make sense. Almost any.
Please explain what you mean by "make sense". Syntactically, = and ==
are pretty much interchangeable, since a=b and a==b are both expressions.
(An "assignment statement" in C is really just a particular case on an
"expression statement", which consists of an expression followed by a
semicolon and whose execution consists of evaluating an expression--for
the sake of its side effects, since its value is discarded. Thus
a==b;
is also legal, though useless, C statement.)
|> However, I personally like the behavior of = and ==. I like being able
|> to put assignment anywhere. :)
I abhor it. When I must code in C, I always write
x = y;
y++;
instead of
x = y++;
I don't mind the y++ as a shorthand for y=y+1. What I dislike is the
intermixing of state changes with the computations of values. (By the
way, a compiler is likely to generate identical code for these two
constructions. The only difference is that the first is written to
enhnace clarity, the second in a misguided attempt to "cleverly exploit
the power of C".)
Ted Dennison
>iCarsten> Don't forget too that all the snap and speed of Windows NT has
>Carsten> something to do with it being written in C.
>
>You must be using a different version of Windows NT than I have, what
>"snap and speed"? In fact, especially on fast RISC machines, there are
>serious performance problems in NT. These have to do more with software
>architecture issues (eexcessive layering), than language issues.
>
That MUST have been sarcasm.
--
T.E.D.
| Work - mailto:denn...@escmail.orl.mmc.com |
| Home - mailto:denn...@iag.net |
| URL - http://www.iag.net/~dennison |
Jerry Coffin
>Ada looks like a brilliant example of second-system committee effect. It
>sounds like there is a beautiful language in there trying to get out.
Interestingly enough, Ada is based on a couple of Niklaus Wirth's
languages (Pascal and Modula) and he voiced a similar opinion, stating
that Ada was an abomination, but admitted that it had influenced his
design of Modula II. Apparently it influenced his design of Oberon even
more - his original statement seemed to imply that seeing the evils of
language design gone wild had prompted him to remove features from
Modula II, and Oberon removed far more.
Needless to say, Niklaus Wirth is human, and his opinion is just that.
However, if I had to name the 5 people whose opinions about language
design I respected most, his would likely be at the top of the list.
Later,
Jerry.
/* I can barely express my own opinions; I certainly can't
* express anybody else's.
*
* The universe is a figment of its own imagination.
*/
Alex Martelli
...
>Would you care to share with us how in C you manage to duplicate the
>concept of a private type, including fully hiding its implementation?
The easiest and most idiomatic way is:
-- cut hidden.h
/* the private-type gateway */
typedef struct hidden *hidden_t;
/* to create hidden_t objects: */
hidden_t hiddenKit(int frabbuz, double lokkez);
/* to duplicate hidden_t objects: */
hidden_t hiddenClone(hidden_t this);
/* to release hidden_t objects: */
int hiddenRelease(hidden_t this);
/* application methods on hidden objects: */
void hiddenOperate(hidden_t this, int wiggleCount);
int hiddenVerify(hidden_t this, double frammistan);
hidden_t hiddenSum(hidden_t this, hidden_t that, double scalingFactor);
/* and so on, and so forth */
-- end cut
Application sources can just include "hidden.h" and are limited
to the methods therein declared for operations on hidden_t
objects. The "struct hidden" is called an ``incomplete type'',
and its details are fully shrouded from any part of the program
that only accesses it through pointers.
This idiom is of very frequent use in C programs of any
complexity that are well modularized and structured.
Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: mart...@cadlab.it Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia Fax: +39 (51) 597120
Alex Martelli
>"There are very few universals: but almost every platform has good ANSI C
>compilers. Can you think of one platform to which you cannot port ANSI C
>code? (They do exist: but they are rare!)"
>You only asked for one example (I could give more). This one comes from
>personal experience. On the current release of SunOS, the sprintf function
>is non-ANSI conforming, it returns the buffer address, rather than the
>number of characters written.
>Note that a bug like this in the library is particularly unfortunate because
>it takes out ALL C compilers on that particular target, unless they supply
>their own libraries.
This does not constitute an example of a platform "to which you cannot
port ANSI C code", since several examples of ANSI C compilers exist
for the current release of SunOS that implement their own, standard
compliant libraries; gcc, in particular in the version released and
commercially supported by Cygnus, is perhaps the most widely available
one.
Alex Martelli
...
> I admit that debuggers are essential. So are code analyzers. My thought,
> and it is widely shared by others in the software community, is that one
> can become too dependent on such tools.
> When I used to have to wait for two days for the results of a compile
> before I could even consider running a test, I was more careful with
> my design and deskchecking. As I began to have faster turnaround, and
> then total interaction, and then wonderful debugging tools, I found
> myself relying on those tools as a substitute for my own reasoning
> ability. I have heard the same story from others. I do not mean to
This is totally analogous to the Druids' reasons (according to Julius
Caesar) for disdaining writing: that people would end up relying on
that tool as a substitute for their own mnemonic ability. No doubt
one is indeed much more careful in listening to some information and
committing it to memory if one knows it's not written down anywhere;
one HAS to. Do you agree with the Druids that one should thus be
careful not to become too dependent on "such tools" as pen and paper,
perhaps to the point of eschewing their use altogether...?
I suspect that when sharpened sticks were first coming into common use,
one could hear some of the more conservative cavemen complaining quite
similarly about how one could become too dependent on such tools,
relying on them as a substitute for one's own hunting ability...
Tanmoy Bhattacharya
writes:
<snip>
|> You seem to think you can just time "make free-library", but it ain't that
|> simple!
You are right: I was assuming it was that simple. I was assuming that when
gnu says that they have written `glibc', they have gont to the effort of
making it simple enough to install: so far, this has been true for all gnu
products that I have tried to install. If you assure me that you know that
this is not the case, I shall just express my puzzlement and refrain from
making further comments.
|>
|> Yes, precisely the default sun compiler is quite non standard. The point
On the other hand they do sell a supposedly completely ANSI compiler.
|> I was making was that it is quite possible to write portable C code that
|> does NOT require ANSI compatiibility, but which in fact compiles on almost
|> all C compilers in common use (GCC is carefully written with this in mind,
|> e.g. it uses macros to determine whether or not to use prototypes).
Certainly. One way to write a portable program in C is to follow the
algorithm:
1) Find out about all compilers ever written in this world.
2) Write a separate program which will compile on each specific compiler.
3) Choose a unique name for each compiler.
4) Merge the separate programs in (2) with `#ifdefs' guarding them.
5) Put the association between your name and compiler in the Makefile or
Readme :-)
Technically the code is now completely portable.
|>
|> So all I was contesting was the idea that ANSI was the best basis of
|> portability in the C world, it is not!
|>
In practice the algorithm I described is very hard to follow. So long after a
language has been standardized, there is no reason to pander to the small
number of compilers that still do not compile what is currently C.
ANSI C, or, if you insist, a major subset of it, is still the only practical
portable C. (Most of gcc could have been written in ANSI C, however, on
many platforms gcc is the first free ANSI C compiler :-)
Richard A. O'Keefe
>Right... But everything I've heard about Ada is that it's wasting more time
>jumping through ill-considered hoops than it saves preventing jumping off the
>occasional cliff. Of course, many of these people were C or C++ programmers.
This is a very curious perception of Ada indeed.
When I first used C, I greatly preferred it to Pascal because of the greater
freedom it gave me to get the job done instead of following useless
restrictions like labels-before-consts-before-types-before-vars-before-lunch.
When I got my hands on a decent Ada compiler and was able to start playing,
I found that I had _exactly_ the same feeling about Ada compared with C
that I had about C compared with Pascal: Ada gives me freedom to write what
I need to write instead of faking my way around meaningless restrictions.
One major example is that having had arrays with run-time bounds in Algol 60,
Burroughs Algol, PL/I, APL, Pop-2, Common Lisp, and Algol 68, it was _such_
a relief to use a language that didn't have that exclusively-for-the-benefit-
of-the-compiler-write restriction "array bounds must be known at compile
time and all lower bounds must be 0".
Another example is that even C++ still doesn't allow functions inside
functions. Well, there are times when that's the _right_ way to structure
something, and I don't want the language enforcing a particular (bad)
programming style on me. (Example: when debugging I would like to be able
to write a data structure invariant for _any_ set of variables, to express
that invariant as a checking procedure, and call that procedure when the
variables are changed. I see no reason why I should only be allowed to do
this when the variables are global. Do bugs never involve local variables?)
Off hand, I can't think of _anything_ I can do in C that I can't do in Ada,
except that pointer arithmetic is not portable. Signed and unsigned
integers? Got 'em. Floats? Got 'em. Pointers? Got 'em. Pointers to
local variables? Got 'em. (You have to explicitly say that the local
variable can be pointed to, but I have no problem with that; my comments
had to say it anyway.) Pointer to const? Got 'em. Control structures?
Got 'em. Lay out the bits to match the hardare? It's _easier_ in Ada.
For me, the bottom line is that it is _easier_ for me as a programmer to
express myself in Ada than in C. (Mind you, I also like Lisp, Scheme,
Haskell, Clean, Prolog, Mercury, AWK, ...)
--
"conventional orthography is ... a near optimal system for the
lexical representation of English words." Chomsky & Halle, S.P.E.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Robert Dewar
How much did these teams work together? That could be a recipe for a
patchwork of highly inconsistent parts.
They worked VERY closely, with, in each case, a chief designer who carefully
oversaw everything everyone did, and made modifications, changes and deletions
in all parts of the design to assure consistency.
Lawrence comments:
That [Alogol-60] embodied a lot of innovative ideas but wasn't a
particularly successful language.
That's the voice of either someone too young to know (you never know how
old people are on the internet), or perhaps someone who only saw the USA
scene, and even there, only part of it.
Algol-60 was for a long time the dominant language in Europe (including
the UK). It was the only language taught, and was used very widely for
industrial, commercial and military projects.
In this country, the failure (a real mistake I think) of IBM to embrace
Algol-60 certainly dampened its use, but even here Algol-60 was widely
taught and widely used. It was essentially the only language on the
Burroughs line of computers and acted as the systems programming language
on these machines (e,g, the B5500 which had no assembler, and was really
an Algol-60 machine). These machines were widely used in the banking
industry (I guess Lawrence that if you were around in the 60's, you were
not in banking :-) There were also important military uses (e.g. the
programs written for the Navy in "Mariner Algol" on the Univac 1108),
and it is well to remember that Jovial stands for "Jules Own Version of
the International Algorithmic Language", and is a version of Algol-60.
Algol-60 was an extermely successful language, it did not survive beyond
its day, since it was replaced by many Algol-60 inspired languages, but
to say it was not particularly successful is plain wrong.
By the way, anyone who professes to know something about programming
languages should be familiar with Algol-60, it is extremely easy to
learn, since the Algol-60 report is short and easy to read. It is
also worth reading "The remaining trouble spots in Algol-60" by Knuth.
Jerry Coffin
>C can be and has been used for megaprograms, but such projects pay a huge
>price in integration costs, compared to projects using a language like
>Ada that defines interfaces precisely and enforces compatibility among
>interfaces when individual units are first developed.
If you change that to "...projects can pay a huge price..." instead of
stating that they necessarily will, you'll at least approach reality. C
interfaces can be pre-specified, and the developers held to the
specified interface.
The basic question here is one of pre-specifying a good enough interface
that it can be used without modification. If you pre-specify an
interface that's poor enough that it later needs modification, Ada won't
do a thing to help you out.
The key here is in specifying the interface, separating it from the
implementation and (by FAR the most important point) insuring that the
interface won't need modification later. Ada provides some help with
the second point, but virtually none with the final, crucial point.
>C megaprogramming
>projects also pay a huge price in maintenance costs, as programmers
>struggle to discover by trial and error just which parts of the program
>constitute a unit's interface and which constitute the implementation of
>those interfaces. (When changing a unit, you can change its
>implementation without affecting other units, but must expect to change
>other units if you change its interface. When making a change to a unit
>that uses some other unit, you can rely on aspects of that other unit's
>interface, but should not rely on aspects of its implementation, which
>may change.)
See above - this is almost entirely an issue of designing a resiliant,
robust, flexible interface that won't require later modification.
There's nothing in C that prevents this, nor is there anything in Ada
that mandates it. In fact, this entire phase of design can (and IMO
should be) done in a language independent manner. It's often even
reasonable to implement different sides of a particular interface in
entirely different languages. As long as the interace itself is
properly specified, the language itself is generally irrelevant.
Jerry Coffin
>>Seriously, though, I think you place too much reliance on tools, and too
>>little on understanding.
>>
>A small commentary on the use of tools here. Don't consider tools from the standpoint
>of safety devices, consider them as being there to increase your reach and strength
>by orders of magnitude. An analogy: if you are given the task of digging a ditch 6 feet
>deep and 100 feet long, would you do it with your hands (assembler), would you use
>a hand shovel (C), or would you use a backhoe (Eiffel, Ada, etc.)?
There's one basic flaw in your reasoning here: you presuppose that use
of Eiffel of Ada IS actually an order of magnitude less labor intensive
than use of C, and likewise that use of C is truly an order of magnitude
less labor intensive than use of assembly language.
Thus far, of the many attempts I've seen attempting to show this, all
have failed.
Jerry Coffin
>2. Consider the following <stdio.h>, which is quite legal:
>/* stdio.h */
>#include <stdarg.h>
>typedef struct file FILE;
Almost legal anyway - make it:
typedef struct __file FILE;
or:
typedef strut _File FILE;
and it'll be legal. `file' is in the user's name space, so it can't be
defined in a standard header. ( I know, picky, picky picky...)
Note that Parnas, the inventor of the concept of information hiding,
doesn't particularly advocate hiding to the degree than others _can't_
obtain information, only to the extent that they don't need or want to
do so. What's important isn't hiding the information, it's providing a
stable API that provides the necessary operations without needing access
to the hidden information.
>Now, without library source, how does J Random Bad Programmer muck with the
>stdio internals?
By finding the definition of struct _File or struct __file wherever it
comes from. OTOH, there's no requirement that standard headers be
accessible to programmers, nor that they be readable text files. That's
certainly the most common design, but there's nothing in the C standard
that requires it. The language allows an implementation to hide _all_
internal details, and prevent any easy reading of stdio.h, or any other
standard header. The precompiled headers used in some PC based
implementations of C provide an example of a perfectly legal solution
that makes the information in standard headers essentially impossible
for the typical programmer to find. A Unix installation where standard
headers were made avaailable only to root and the compiler used setuid
to access them would be another possibility.
In short, this is a fine example of information hiding in action: the
form of standard headers, whether they're in files, or simply internals
of the compiler itself activated by appropriate directives, or various
other possibilities, are unspecified by the standard. They're hidden
details of the implementation.
Richard Kenner
>Wouldn't gcc ported to the SunOS system be an answer to this? Doesn't
>gcc provide its own version of the standard libraries?
No. GCC is merely a compiler.
The is a GNU libc (or glibc, for short), but it hasn't been ported to
as many systems as GCC. But I'm quite sure it's on SunOS.
Richard Kenner
>precisely because you want gcc to look like the native C as much as possible,
True. On the other hand, you want GCC on one machine to look as much
like GCC on another machine as possible.
These two goals are clearly incompatible and deciding which one to give
priority to in each situation is tricky.
Brandon Wallace
de...@cs.nyu.edu (Robert Dewar) writes:
-> Ron Collins said
->
-> "Ada didn't invent private/public/protected types. With appropriate syntax,
-> I get the same features of scope and visibility with Object Pascal, C, C++,
-> and even some flavors of Fortran. I'm sure there are a host of others
-> that don't pop to mind immediately."
->
-> Would you care to share with us how in C you manage to duplicate the
-> concept of a private type, including fully hiding its implementation?
Haven't done much X windows programming, have you...
>>>>>>monkey.h<<<<<<<
/* Example of a private type */
typedef struct MonkeyP * Monkey;
extern Monkey createMonkey (void);
extern void destroyMonkey (Monkey);
extern void feedMonkey (Monkey, int food);
extern void watchMonkeyClimb (Monkey);
>>>>>>>>>End Of monkey.h<<<<<<<<<<<<<<<<
Given that header file, and given libMonkey.a, you can create
a Monkey, destroy a Monkey, feed a Monkey, and watch a Monkey climb.
Yet, you have no idea how this is implemented. I would call that
a private type, with it's implementation hidden.
--
Brandon Wallace
Nicholas | Applegate Capital Management
mailto:bm...@criterion.com http://www.criterion.com/home-pages/brandon
"I live life face down in the fast lane."
Bob Kitzberger
: There's one basic flaw in your reasoning here: you presuppose that use
: of Eiffel of Ada IS actually an order of magnitude less labor intensive
: than use of C, and likewise that use of C is truly an order of magnitude
: less labor intensive than use of assembly language.
: Thus far, of the many attempts I've seen attempting to show this, all
: have failed.
Our internal metrics show our Ada code being several times less
costly to develop and maintain than our C code base. And our
C code base is several times less costly to maintain than our
makefile/support file code base. We had nothing in particular
"to show" one way or the other -- we make development environments
for Ada, C, and C++, as well as OO case tools for other languages.
Peter Seebach
Norman H. Cohen <nco...@watson.ibm.com> wrote:
>In article <475rf0$h...@solutions.solon.com>, se...@solutions.solon.com
>For starters, the entire definition of FILE is in stdio.h (or in some
>file included by stdio.h) and thus, in effect, present at the beginning
>of the C file.
This is often the case. It is not a requirement. Certainly, code using the
internals of a FILE * has ceased to be legal C. A compiler can certainly
warn for it if it so wishes.
>here is no means for detecting that a program has
>(through good intentions or bad) relied on the internal structure of a
>FILE. Second, a C compiler produces error messages based on the program
>text after preprocessing, so an error in the use of type FILE can produce
>an error message referring to the definition of FILE, forcing the
>programmer to be aware of, and perhaps understand, this definition.
But you never use a type FILE. You only use a type pointer-to-FILE.
And I never (well hardly ever) see errors about the stdio internals.
(The ones I see have to do with me trying to hack on extension to them
expirimentally.)
If stdio.h just puts:
typdef struct __file *FILE;
for a FILE, legal code will never know.
Mostly, I don't buy hte claim that cheating must be impossible; any Ada
programmer can just commit industrial espionage and read the project files.
As long as there is a definition of the interface, and that definition does
not depend on the implementation, that is an abstraction.
Protection from shoddy work is a good thing, but it is not the same as good
work. Abstraction is a design feature, not an enforced law. If it is
possible to use an interface without knowledge of its workings, that interface
has provided an abstraction. It may or may not force you to use only the
abstraction; what you do wrong is on your own head.
-s
--
Peter Seebach - se...@solon.com || se...@intran.xerox.com --
C/Unix proto-wizard -- C/Unix questions? Send mail for help. No, really!
Copyright 1995 Peter Seebach. -- High energy particle theology
The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq
Bill Seurer
|> In article <NAYERI.95O...@tahoe.gte.com>,
|> Farshad Nayeri <nay...@gte.com> wrote:
|> >It always amazes me that people base their use of the language on what
|> >case the keyword is in. Oh yeah, I forgot, I am posting to
|> >comp.lang.advocacy.
|>
|> Any one see any reason not to RFD it? We obviously need it.
|>
|> I got frustrated by the all caps keywords in M3, the ugly template syntax in
|> C++, and many other "cosmetic" issues. (I wan't even bother listing my
|> problems with traditional FORTRAN.)
|>
|> These are *NOT* trivial. If a language makes it impossible to write decent
|> looking code, there is something wrong with it.
|>
|> Consider:
|> English IS a nice language. BUT IF you WERE to capitalize certain words
|> BECAUSE they WERE deemed more important THAN others, IT would BE practically
|> illegible. IT WOULD certainly BE A very difficult READ. NO native speaker OR
|> reader of English I HAVE ever met HAD any trouble reading text IN English.
|> THE fact THAT verbs AND certain "keywords" ARE NOT IN all caps DOES NOT hurt
|> THE language AT ALL.
your argument falls apart because english does use capitalization to
emphasize certain words. see? skipping caps altogether looks odd too
just because you are used to seeing them. think about it, they really
aren't needed after all. you can spot the start of a sentence without
them and as for names like jill and george well they look just as good
without.
|> ANY experienced reader OR writer OF A language WILL spot keywords easily AND
|> quickly. A sloppy-looking, unnatural, hard-to-read layer DOES NOT help AT
|> ALL.
It's really funny then that all kinds of people here change their editors
to highlight, colorize, or otherwise make C/C++ keywords stand out. They
must be a bunch of inexperienced dweebs I guess.
|> >For those of you who like Modula-3 semantics but hate the uppercase
|> >keywords, I suggest you read he paragraph below (and fetch m3su which
|> >allows you to use lowercase keywords).
|>
|> Given than, I may track it down and try to build it for my current home box.
|> Yes, it's a "minor" point, but they really are *horribly* ugly and hard to
|> read. I could accept leading caps, but fundementally, native usage of my
|> language does not have any all-caps words excpt for signs. Code should read
|> more like text, and less like a billboard.
Heck, the editor we use at work will nicely take care of the capitalization
as you type things in. When it sees a keyword in Modula-2 or Modula-3
(and yes, it handles comments and quoted strings too) it automatically
highlights it. I turn it off because I find it disconcerting when I
sometimes use a variable named something like "var".
|>
|> > Some people prefer uppercase keywords others hate them. Another
|> > possibility is to accept both forms for keywords. This topic has been
|> > discussed at length and there is no solution that will completely
|> > satisfy everyone's tastes. Fortunately this is a very minor issue and
|> > you can easily have lowercase keywords automatically converted for you
|> > using an emacs macro or packages like
|>
|> > <A HREF="file://pion.lcs.mit.edu/pub/m3su"> m3su </A>.
|>
|> ... But what I mostly don't see is why the language *requires* this. Why
|> not just go whole hog and require keywords to be in bold?
|>
|> > http://www.research.digital.com/SRC/modula-3/html/welcome.html
|>
|> (Left this in 'cuz it's a good pointer.)
|>
|> Thanks for the response. If I don't get any good reasons not to, I'll track
|> down the RFD process and start the process for comp.lang.advocacy.
It is all what you are used to. I have no trouble switching between
Modula-2 and Modula-3 where the keywords are all caps, C/C++ where they
are all lower, and Pascal where they can be mixed. When I type in Modula-x
code I don't even think about caps any more, my fingers automatically do
it.
--
- Bill Seurer ID Tools and Compiler Development IBM Rochester, MN
Business: BillS...@vnet.ibm.com Home: BillS...@aol.com
Bill Seurer
|> nay...@gte.com (Farshad Nayeri) writes:
|> | It always amazes me that people base their use of the language on what
|> | case the keyword is in.
|>
|> a language that put a lot of effort into solving hard problems, only
|> to punt on the easy ones. Upper case keywords are a probative example
|> of that.
An example of what? An "easy problem"? What problem is that?
|> In a language with lower case keywords, NEW wouldn't abort
|> the program.
What? If you are saying that using "NEW" as a non-keyword (say a var
name) in Modula-3 shouldn't cause a problem then I bet you think that
in C you can have variables named "if" and "case" too.
|> All this makes M3 the moral equivalent of shredded
|> wheat: it might be good for you, but it tastes awful.
Gee, that's the first thought I had on encountering C. It was good to
learn it but it tasted awful (at first). Now it's no big deal to switch
between C/C++ and Modula-2/3 and I truly don't have a preference for
the semantics. They are different, not necessarily better.