Re: Fun with C

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 4/18/11 9:12 PM, Elias Salom�o Helou Neto wrote:
> On Apr 17, 7:26 pm, Georg Bauhaus<rm.dash-bauh...@futureapps.de>

>> I suggest turning to observable facts and away from
>> normative ontology for a moment.  Towards justifiable
>> language design.

Unfortunately, when it comes to empirical research into the effects
of language definitions, hardly anyone ever finds a scientific
approach worthwhile.

> if you wish we can find a metric whereby
> C is better than Ada as well.

I'm eager to add more metrics to my collection programming language
metrics.

C's pointer arithmetic is unchecked, unlike Ada's, and thus faster.
(A experiment that some embedded C people found fair resulted in
a ratio of 10:12).  Another metric.

So we have three PL metrics and three hypotheses for a start.

> I won't argue on that. Specially, your
> metric seems to imply that Ada is much better for those who find it
> hard to think, most people after all.

Uhm, no, that's a misunderstanding, Ada requires quite some thinking,
it is just that its basic types do not require so much thinking.

I should stress one *major* concern of my favorite approach to
language definition:

Smart brains should not have to spend time with tackling basic
programming techniques.  In any language.  They should have all
their thinking capacity engaged in thinking about smart solutions.
Not in keeping track of types' implicit sizes. That's wasted effort.
(PC-lint -w 4 seems to confirm this view.)

If mastering a relatively basic feature of a language requires
much learning, then this investment should be compared to its results.
What is the return on investment a programmer spent on implicit
type size education, say?

Among the observable results are these:

(a) you know how to use basic programming features

(b) you take pride in this ability

(c) you can set yourself apart from others without the skill

Which skill is, nota bene, knowing how to write basics.


> Of course Ada is a better approach for the masses.

Certainly not in full.  Like C++. Because no big, detailed language
will ever work for the masses.  Subsets may do so, as a starting
point, I think.


> However, here is my piece of advice: it won't work. See Ariane 5's
> example.

I understand your idea, I think, but it is this very example that
has surprisingly little to do with languages, in spite of all
the ambitious remarks made about the case.  Have you had time to
look into the report?

> Ada may give programmers a false sense of security, leading
> to even more sloppiness.

Hmm... Is there an operational definition useful to turn this claim
into a hypothesis?  I had thought that Ada culture nurtures awareness
of security issues more than false beliefs in "secure languages".

> Surely Ada would be a good and justifiable choice for most industrial
> programming projects, but this is not what C was planned for - don't
> blame it.

Complaints were addressing using C in industrial projects because of the
effects it has in industrial projects.  There is evidence that different
fundamental type  systems help non-dumb people solve their problems more
successfully.  People will still be using C libraries and additional
code generators, as a replacement for a better suited type system.

If something is going to replace C, it sure mustn't look like Ada.
Just be like it in some ways.  That's the crucial part, I think.
Keeps face.