I started it, so now a big answer...
> > I wouldn't consider C as anything 'grown'. maybe evolved in the
> > sense of degeneration.
> Hey, Hans, I don't get this. C is the most versatile, flexible, and portable
> language ever devised. It permits complete control of hardware while at the
> same time allowing elegance in program design and structure.
Please ? Thats a lot of stuff for that small thing.
Most versatile, flexible and portable ? Lets see:
Define most versitale - is that usable for any task ?
Basicly all programming languages are usable for anything (well,
at least the general purpose ones). And flexible ? Isn't that
redundant ? In fact, if you compare C to PASCAL you may notice
that there is almost no difference in the basic elements.
Almost anything writen in PASCAL can be ported straight to
C and the other way.
Now, portable - I assume you talk about the portability of
the compiler and not the programms (I did spend more than
just a few hours to convert C programms between different
platforms and compilers). Well you're right, the compiler
is fast to port and you need a very low time until it will
produce code, and a bit more until it runs native (most time
spend on building a minimal OS-like runtime). Just, where is
the gain if the produced code is way inaprobiate for the CPU ?
No, don't tell me that's just optimisation. It isn't. C unlike
almost all other HLLs implies a specific CPU Model. If the CPU
is not build acording to this model all code will suffer - even
if the CPU offers all stuff needed to do the task. Lets take
(the often used - but realy simple) example of string handling.
Let's assume you want to move a 10 byte string. C strings are
by definition byte orientated and terminated by a byte containing
the NIL code (x'00'). If you look at the PDP style CPUs thats
a real nifty thing, since you have no problem to move and
check the contend at once and do the incrementation. The
resulting code is fast and even in assembly a lot of people
would write the same code. Now lets port our compiler to a
/370ish machine where you have two kinds of block move
operation (MVC and MVCL) but no CC is modified by the bytes
moved ... instead of using a single operation (or a single
serias of operations) this definition of a string forces the
compiler to generate a series of 5 instructions MVC, CLI, LA,
LA, BC (plus two preceeding load instructions). Instead of
a single MVC to move the 10 bytes, these 5 instructions have
to be executed 10 times - resulting in 50 instructions instead
of one - do you consider this as a good portable ? Even
a UCSD P-Code machine can do better (and is an example of
a even faster way to port a language).
(I skip the 'ever' part, I know you Americanos trend to over
emphasis with constructs like this :))
Controll of hardware ? My memory may be fading, just I can not
see any reference to hardware controll in my K&R copy. All
hardware dependant stuff is proprietary to the compiler you
are using. And that's the same way as for example in PASCAL
Elegance in design and structure ? Maybe, because it's hard
for me to recognice elegance if 66% of all code is needed
to overcome limitations of the language or to rebuild basic
stuff all the time.
In my opinion C is the 'best' possible blend of all drawbacks
of assembler with all drawbacks of non-assembly high level
languages (I consider Asembly in contrast to Machine Language
as high level).
Things like messing up the whole programm by one wrong ; or }
(something impossible on Assembly) or easyly produce memory
leaks (hard to do on other HLL).
> Can ADA match that?
Well, of course. With ADA you may code anything
As Ethan already described, C is tight bound to the PDP
CPU model. While ADA is (like PASCAL) without a CPU Model.
Unlike PASCAL, ADA offers a lot of ways to describe your
data and your intention on the data so the compiler is
enabled to choose for every target processor a complete
different implementation, since he has more hints what
you are about to do. Also ADA offers tools to define
way more complex things with simple statements. Using
parallel processing within your code ? Just tell the
compiler, and if you're running on a machine capable to
do SIMD, your programm will get an additional kick.
Need Semaphors or other tools of IPC ? Tell the compiler
about it, and no matter what operating system, you'll
get what you want ... etc. pp. I could go on for hours.
Shure, you have to write a bit more text than in C to
build the 'Hello World' thing - but if Hello World is your
goal you should go for Basic or dBase. In real applications
ADA programms will be often more compact than C - in terms
of bytes ! SMALL is for example a simple Text adventure
engine to fit in just 42KB of Sourcetext - where more
than 50% is comments (Hard to create this in C and keep
all advantages of a real HLL).
Of course ADA is objectorientated. ADA has a lot inherited
from PASCAL/MODULA (and a little bit from COBOL :), so PASCAL
guys may feel like home.
Maybe take a look at
http://lglwww.epfl.ch/Ada/
The EPFL has put up some real usefull pages.
www.adahome.com is also a good start.
And yes, Bill S., A bad programmer can screw up any code.
Just in ADA it needs more effort to produce bad code than
C. I apreciate programming languages in two conected things:
First a language should help me writing a program - thats
I 'just' have to make my idea clear and the compiler has to
generate code - best possible code of course. To reach this
goal I need rather sophisticated construct and not only the
most basic ones - this also goes with the good code - if a
language like C offers onla the most basic operations it is
(almost) impossible for the compiler to guess what I'm about
to do and optimize the code accordingly. With usable higher
elements I may give more hints on my intention and the compiler
may generate better machine code - example: C doesn't include
any operation to move data other than the very basic elements
(Byte, Int , Float). So if I order the programm to move a
structure I use a loop to copy byte by byte - hard for a
compiler to optimize this into a block move operation (if
available. Other languages may compile this different - they
may for example generate a single block move, or a series
of unrolled moves or even more processor specific tricks
(load multiple registers/store multiple register - a real
nifty trick on 68K processors to save cycles). And writing
A:=B is way more easy than memcopy(...) - less work for me
and better optimisation (Yes, I know that some C compilers
optimize memcopy() - just thats a bad trick.
And second: A programming trick is like Laws or Locks - it
is about keeping honest people honest. If the effort to do
it the bad / wrong way is bigger than to do it right, the
number of 'faults' will be way reduced.
Dick, you say you use C to generate the basic stuff. Thats
fine, just I can't see what an Assembler can't do. Let's
first agree that Assembler equals to Macro Assembler - and
than it's just a bit of _one_time_ work to make any C
compimer senseless.
Alison:
>> I suppose it depends on the assembly language. I can write PDP-11 assemble
>> in C (knowing nearly exactly how the code generator works), but I can't
>> write VAX assembler in C since there are VAX instructions that don't
>> represent well.
> An interesting contardiction as VAX is a extreme superset of PDP-11.
Exactly the problem described above - The CPU modell upon which C
is designed is the PDP-11 and C is made to force the programmer
to code everything thats not within this basic set by himself -
and lateron the compiler is unable to interprete the intention
to generete more sophisticated code for more sophisticated CPUs.
Pascal on the other hand has no implied CPU model and can't force
this model onto the programmer.
Gruss
H.
Oh, a last thing:
Yes, I'm doing C when forced to - And that is not the rare case.
And No, I'm not doing a lot in ADA - 95% of all my programming is Asembly.
And Another thing, I wasn't in for a Language War, but rather realy
wondering what happened to the language world.
--
VCF Europa am 29./30. April 2000 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
Received on Sat Mar 11 2000 - 13:38:31 GMT