Q
QuantumG
Alan Balmer said:
It's not an "incorrect assumption" it's the declared charter of the C
standization committee.
It's not an "incorrect assumption" it's the declared charter of the C
standization committee.
C
Chris Barts
I could have been a lot clearer and much less wrong.
I meant that C not only had three successful lineal descendants
(Objective-C, C++, and C#), but that it inspired people to copy its syntax
(a freeform block structure, instead of line-oriented code, delimited with
curly-braces, instead of the Algolish begin-end blocks) and, to some
extent, semantics (using = for assignment and == for equality-test,
semicolon-as-separator instead of the Pascalish semicolon-as-terminator,
etc.)).
In my second sense, Java and Perl can be considered spiritual descendants
of C to some extent. They, especially Perl, stripped out a lot of the
lower-level semantics of C, but they kept a lot of things and generally
made it as easy as possible for an experienced C programmer to get up to
speed in the language.
Fortran and Cobol are both, traditionally, line-structured languages with
strict formatting rules. They have syntax that didn't catch on much past
the 1970s (Fortran has whitespace rules that almost defy belief when a
younger programmer sees them, Cobol has an odd reliance on a strict
grouping of divisions and subdivisions within the code) and semantics that
are simply not seen in most modern languages (Fortran has great
array-handling primitives, and doing very precise decimal math in Cobol is
more natural than most of the control structures). To be short, most
languages (by number of languages, not by number of lines of code) simply
don't look or work like that anymore.
Lisp has had a more pervasive influence, but it's usually dressed up in
more appealing syntax. I don't know how successful Scheme has been, but
(and here's where I dropped the ball in my own eyes) functional
programming has become a lot more common over the past few decades. Lispy
ideas about high-level control structures (map, closures) and
garbage-collection have really caught on. You can even program essentially
functional (in the Lisp sense) code in Perl and other ultra-high-level
`scripting' languages. So while languages don't look like Lisp, they sure
as hell work like it.
I didn't say that Fortran, Cobol, and Lisp are dead. They might smell
funny, but they aren't gone forever. ;-) I did say that C inspired a whole
class of block-structured languages that look different from the
Algol-inspired and `other' languages of this kind.
R
Richard Bos
Be careful. Your fun can easily slide into misrepresentation, which can,
in some jurisdictions, leave you open to lawsuits.
Richard
A
Alan Balmer
No, it's only one of 11 principles listed in the charter, and far from
the only reason to release a standard.
J
Julian V. Noble
[ snipped ]
It's an Abe Lincoln story, not a Mark Twain one. He said it in
a speech, possibly one of the debates with Douglas.
--
Julian V. Noble
Professor Emeritus of Physics
(e-mail address removed)
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/
"For there was never yet philosopher that could endure the
toothache patiently."
-- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.
It's an Abe Lincoln story, not a Mark Twain one. He said it in
a speech, possibly one of the debates with Douglas.
--
Julian V. Noble
Professor Emeritus of Physics
(e-mail address removed)
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/
"For there was never yet philosopher that could endure the
toothache patiently."
-- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.
M
Mark McIntyre
Alexander Bain, 1818-1903, Scottish philosopher. To have been
bain-damaged your schoolmates must be well into their second
century. I didn't think you were that old
From Wikipedia:
"Bain-damaged: forced to read the works of Alexander Bain until your brain
melts, or you become pregnant, or you begin to imagine you're a mattress.".
There was an Ed McBain in Once upon a Time in the West. Will he do?
M
Mark McIntyre
But a tale may well be a leg end
whitespace is significant in C....
M
Michael Wojcik
Three reasons for new development in C on general-purpose systems:
1. Portability. There's a well-supported standard C implementation
for all of the many platforms we deliver software on. (We use the OS
vendor's commercial implementation, except on Linux.) Until
relatively recently, C was the only language for which that was true.
2. Interoperability with existing code base. Like many
organizations, we have a large C code base (thanks to #1). Those
products need to be enhanced and extended, and C is the best choice
for much of that work because it's the least disruptive.
3. Expertise. For most projects there's no compelling reason to
discard thousands of programmer-years of C experience.
--
Michael Wojcik (e-mail address removed)
[After the lynching of George "Big Nose" Parrot, Dr. John] Osborne
had the skin tanned and made into a pair of shoes and a medical bag.
Osborne, who became governor, frequently wore the shoes.
-- _Lincoln [Nebraska] Journal Star_
J
jacob navia
You mention very good reasons.
There are others.
What I like from C is that it is not object oriented, nor
functional, nor a list processing language, nor are arrays
really the "basic object" like APL.
C is agnostic. It has no preferred data model, it is up to
the programmer.
This is quite a freedom. There is no preconceived notions, and
you can build anything.
This has its down sides. It is lacking parametized types,
and polymorphism. But incorporating this and a few changes
can make C a nice language to use. It is much simpler than
many, like C++.
C is a general purpose language, and many programming languages
are written in C.
Contrary to the opinion of many in this list, I think that C
has a great potential.
Not only for embedded systems, or maintenance code but for
developing new software.
There are others.
What I like from C is that it is not object oriented, nor
functional, nor a list processing language, nor are arrays
really the "basic object" like APL.
C is agnostic. It has no preferred data model, it is up to
the programmer.
This is quite a freedom. There is no preconceived notions, and
you can build anything.
This has its down sides. It is lacking parametized types,
and polymorphism. But incorporating this and a few changes
can make C a nice language to use. It is much simpler than
many, like C++.
C is a general purpose language, and many programming languages
are written in C.
Contrary to the opinion of many in this list, I think that C
has a great potential.
Not only for embedded systems, or maintenance code but for
developing new software.
R
Randy Howard
Do you really think there are many people that would bother subscribing
to a newsgroup (this is not a list btw), that don't think it has
potential?
As soon as a better language comes along to write operating systems,
you be sure and let us know.
G
Guillaume
Contrary to the opinion of many in this list, I think that C
I second that.
Not to mention than most "higher level" languages invariably
mean more bloat. I hear people claiming otherwise on a regular
basis (especially about C++), but no one has ever been able to
prove that. Never.
This bloat may allow to put extra bells and whistles all over
the place in less development time, but is that really useful?
No other language can beat the efficiency of C overall. That's
the bottom line in my opinion.
And the fact (that other people have mentioned) that the C
standard is of much higher quality than any other language's
(despite what we may read here and there every once in a while)
is equally a big plus.
I second that.
Not to mention than most "higher level" languages invariably
mean more bloat. I hear people claiming otherwise on a regular
basis (especially about C++), but no one has ever been able to
prove that. Never.
This bloat may allow to put extra bells and whistles all over
the place in less development time, but is that really useful?
No other language can beat the efficiency of C overall. That's
the bottom line in my opinion.
And the fact (that other people have mentioned) that the C
standard is of much higher quality than any other language's
(despite what we may read here and there every once in a while)
is equally a big plus.
M
Mike Wahler
Keith Thompson said:
It's coming up on election time in the U.S., of course.
-Mike
D
Dave Thompson
You stated that last backwards -- C terminator, Pascal separator. And
I would count = and ; as syntax issues also; for C's semantic
influence I would count pass-by-value at least as default, nonzero as
boolean true (although LISP had nonNIL), and to an extent bit
operations on integers (some other languages supported this, but not
as conveniently). And maybe value-returning assignment -- I _think_
algol68 did that, but no other "normal" (procedural) HLL.
While your list was unique to C, which is what you actually say as I
read it, the individual features aren't. Algol and PL/I were freeform,
the latter with terminator. AIUI algol 68 was so lax on representation
you could have { } "spell" do od, although you probably wouldn't have
been very popular. FORTRAN used = and .EQ.; COBOL used = for both
(although assignments are also done by "verb" forms that don't use =).
I would say (executable) Java and the action part of awk were
deliberate "cleanups" of C; csh and perl somewhat less so -- that is,
they used some features of C, but also their own dissimilar ones.
FORTRAN did in the days it was all-caps; the versions known by Fortran
(>= 1990) _also_ allow "modern" (or at least mainstream) syntax,
except with explicit continuation. COBOL did (at least through 1985, I
haven't examined the most recent version) require certain things
(divisions, sections, IIRC level numbers) to start at the beginning of
a line, but otherwise spanned lines and needed explicit continuation
only within a string (and FWIW standard C effectively does also -- it
requires breaking the literal and letting the pieces be concatenated)
and allowed multiple statements and IIRC even sentences on a line
although they were mostly verbose enough it would often be an
inconveniently long line. COBOL's required ordering is in my view not
that different from declarations-before-code in algol, FORTRAN, and C
within a block before C99; and Ada, and Pascal which in its classic
form has grouping/ordering at least as strict.
Original BASIC was strictly line-oriented. With = for both BTW.
APL also was line-oriented. And I believe MUMPS. (And RPG.)
The Fortran array enhancements (aka HPF) are standard only since F90.
PL/I and Ada (already) incorporated pretty much both of these, and APL
arguably did even better on arrays, but those aren't modern (at least
in the sense of recent) either.
I wouldn't call even the original COBOL control structures unnatural
-- admittedly a subjective judgement -- although they tend to be
fragile and definitely aren't orthogonal (arguably elegant); -85 adds
"structured" but (unsurprisingly) still rather verbose options.
- David.Thompson1 at worldnet.att.net
C
Chris Barts
Dave said:
Very likely true. I never fully learned the semicolon rules under
Pascal, because I never fully learned Pascal.
Again, all very true. C has set a lot of standards, and it seems that
they are reflexively thought of as being How It's Done even though
plenty of languages do/did it differently.
Yes, I meant for the whole list to stand as a unit, as a list of things
that were all present in C and are also all present in a lot of other
languages designed since C.
How styles change, neh?
And I was always fascinated by how Algol-68 could be so lax on the details of how the language was represented.
I have programmed FORTRAN and COBOL (note caps). These are both very true.
Yes, precisely. (Although isn't Java a `better C++'?
)Yes, I was lax in my spelling. (But, to be fair, FORTRAN is
case-insensitive, not necessarily all-caps.)
COBOL is inconvenient? Since when?
True. But C and FORTRAN don't create explicit divisions within the code,
so they at least look free-form with respect to where declarations can go.
APL is in a world of its own, and I don't think it's used much these
days. BASIC has gone through so many fundamental revisions and
nonstandard extensions it makes Pascal look like a single, unified
whole. I've never used MUMPS or RPG, nor have I ever seen sample code in
either of those languages.
Huh. I thought FORTRAN has always had array-handling primitives.
PL/I and Ada implemented pretty much everything from their respective
eras.
And, as I said, APL is Lisp translated to mirror-Greek for math geeks.
COBOL has PERFORM THROUGH and (in some versions) the ALTER verb. Hardly
a threat to if ... else or while.
And then we have the old joke:
The newest language in the COBOL family has object-oriented semantics.
It's called ADD 1 TO COBOL GIVING COBOL.
D
Dave Thompson
True, but at least the latter is a crock no one with sense would think
of as the natural solution to any but the weirdest problem. For me the
original control structures, used in the "obvious" way, are clear
enough, although when you (need to) change the algorithm even modestly
you often must rearrange the code (e.g. put a sentence, or PERFORM
body, out-of-line) which is what I meant by "fragile".
And as I said, COBOL-85 adds "properly structured" forms:
IF condition THEN body can contain nested forms [ELSE etc] END-IF
PERFORM VARYING var etc UNTIL cond body ditto END-PERFORM
(Plus a bunch of specialized ones like READ ... [NOT] AT END ... .)
These are isomorphic to, though often more verbose than, the algol/
Pascal/C etc. equivalents. On the PERFORM you can choose TEST BEFORE =
C while, Pascal while do or TEST AFTER = C do while, Pascal repeat
until. Plus EVALUATE which is like a case (C switch) statement on LSD.
And for that matter also nested procedures (aka program-units) a la
algol, PL/I, Pascal, Ada, but not C et seq; although with the clunky
syntax overhead (at least 10 lines or so) for each, and outer-unit
variables are NOT accessible unless you declare them GLOBAL -- which
actually isn't GLOBAL in the normal meaning, only for a subtree; what
other folks sometimes call global COBOL calls EXTERNAL!
It's more "OO" <G>, and more idiomatic, to just ADD 1 TO COBOL .
I believe this actually happened in 2002(?), along with other less
major changes, but I haven't looked seriously through the result yet.
- David.Thompson1 at worldnet.att.net
P
Paul Hsieh
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160
http://www.tiobe.com/tpci.htm
While neither is really "hard" data, they are at least independent
measures that show nearly the same thing. It shows C, C++ and Java to
be all neck and neck. Not sure why you are seeing any appreciable
amount of Fortran, but I'll take these figures over anecdotal claims
about what you have seen or not.
R
Rob Thorpe
This shows projects overall, but it is interesting to look at
distributions. They contain fairly well used and stable software, not
necessarily new software, but they show what is used in practice.
dhwheeler did a code line count on Red Hat 7.1. These are his
results:
C 71.18%
C++ 15.18%
Shell (Bourne-like) 2.63%
Lisp 2.40%
Assembly 1.88%
See http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html
The great masses of C code are the kernel, gcc, binutils and X