Dennis Ritchie -- An Appreciation

[nroberts]

Strictly speaking you're right of course, but I do see his point.

If I hear someone say that French cooking is delicious, that leads me
to believe that the speaker holds French cooking in higher regard than
other cuisines.

Yes, it's possible that the speaker believes all cooking is delicious,
but in that case, why did he or she bother to single out French cooking?
It would have been more accurate and less effort to simply say that all
cooking is delicious.

But the speaker did choose to single out French cooking, and in my opinion
that can carry meaning.

(Of course this is all hugely subject to context.  If the speaker in my
example was specifically responding to a question about French cooking,
then that changes everything.)

Likewise, if someone made the statement out of the blue during a
discussion critiquing French and say Spanish cuisine I'd expect that
the singling out of French has even more special meaning.

Back to the original, the context here of course was discussing the
differences between C and C++ among a few others. Thus I expected a
claim that C has a bias toward whatever carried significance to the
author. Now I know better.

 

[Joe keane]

I'm a programmer, and just about always have been. My favorite
programming language is still C, and my favorite operating system is
still Unix.

i really apprieciate that

 

[nroberts]

Well said, but you shouldn't leave it at that.  By all means, ignore
everything I post from now - you have established to your satisfaction
that nothing I write is worth reading.  In fact, if you have
killfiles, put me in one immediately.  You may be concerned that you
might hurt my feelings by plonking me.  Don't be.  Do the right thing
and put me in a killfile.  You will all the better for it ... and so
will I.

Monkey.

 

[Ben Bacarisse]

I quoted it verbatim just two posts ago.

So you did -- I missed it.

However, Richard's point is symmetric but I agree that this was not
clear in the first post. The "bias" is for arrays of structs if we want
to access the structs but it would show up as a bias for structs of
arrays if it was common to want to process the members as arrays.

He is, I am sure, perfectly well aware of the symmetry. In the message
I replied to:

| The issue here is that our data in effect is a two dimensional array
| with one of the dimensions being the fields. In some languages
| slicing is intrinsic to the language; in C it is not.

Slicing 2D data is symmetric and applies to either declaration. If one
organisation is preferred over the other, it is only because some
accesses are more common *in practice*.

I find this observation entirely un-contentious.

I suspect you do not, because when I made this general point -- about
C's inability to talk about objects in the "other" dimension (arrays of
members when we have arrays of structs and structs when we have a struct
whose members are arrays) -- you still seemed to disagree.

 

[Malcolm McLean]

On Fri, 11 Nov 2011 22:11:14 +0000 (UTC), John Gordon


And that would be an error.  There is no reason to suppose that the
speaker is familiar with all cuisines.  Perhaps all of the cuisines he
is familiar with are all delicious, perhaps some are not.  Regardless
of that he cannot speak for the cuisines he does not know.

It implies the speaker is familiar with at least one other cuisine,
which he considers inferior to the French.

We didn't like school dinners when I was at primary, and we got our
parents to give us sandwiches instead. Then I moved to secondary
school, and I realised that the primary's dinners were actually quite
good for school dinners, though not as good as home cooking.

 

[nroberts]

No.  He might consider French inferior to Thai, but none the less
delicious.  Then again, he might consider French and Thai equally
delicious, but have no knowledge of German.  The only safe inference
is that the speaker purports to be able to distinguish between
delicious and not delicious.  It is an error of logic to claim that
Px->(Ey)~Py.

Bartholemy.

 

[Nick Keighley]

Actually, you're mixing and matching here.  The bits you're quoting
come from different lines of conversation.  The one that Mr. Gordan
was replying to was correctly stated, the one your pasting into
contained my misspeaking.

You're also completely ignoring the fact that I already corrected the
mistake regarding "unique to C".  Now you're just harping on something
that was never meant in order to ignore the real issue at hand, which
is getting YOU to explain what YOU said, which very much was that _C_
has this bias.

because we're in a C news-group? I suspect many langaues have a
similar "bias". But I also epect many don't if they don't try and
specify soem sort of storage layout. You claimed this "bias" was built
into hardware architecture, I'm not sure you ever showed this.


 If there's nothing special about C in any way

 

[Malcolm McLean]

In the first case (delicious,~delicious) there is a binary predicate,
either is or is not.  In your school dinners you have a comparative
adjective.  Different cases.

Was the Roman army a powerful army? Is the army of Lichtenstein a
powerful army? What would happen if, hypothetically, the Roman legions
were sent against the Lichtenstein national guard armed with assault
rifles?

In order to have attribute X, there must be something which is not X.
Otherwise you don't know you have attribute X.

 

[nroberts]

because we're in a C news-group? I suspect many langaues have a
similar "bias". But I also epect many don't if they don't try and
specify soem sort of storage layout. You claimed this "bias" was built
into hardware architecture, I'm not sure you ever showed this.

Mana mana

 

[Willem]

Robert Wessel wrote:
) Lichtenstein doesn't have an army or military (they *had* an army - of
) about 80 men - but it was disbanded in the 1860s). The do have a
) police force of about 90 officers, with the usual small arms.
)
) In any event, the legion would likely suffer disproportionate
) casualties, but would overrun the Liechtensteiners as soon as they ran
) out of ammunition. I would cite the Battle of Rorke's Drift, which
) was very nearly lost by the British. In this case the force imbalance
) would be worse, even when facing a single legion.

I'm sure morale plays a large part in this, given that the Romans would
have never heard of firearms in the first place. It rather depends on
their level-headedness and to be honest, I have no idea on how this fares
with the Romans.

Also, perhaps there are civilians in Liechtenstein that have firearms
handy, for entertainment purposes? All it takes is one idiot with a
Gatling to take down a whole lot of 'em.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Seebs]

I have to say that I'm not really buying all this logic crap you're
spewing.

I would agree that you appear not to be buying logic.

You had the chance to clarify that you did not mean to
single C out two weeks ago when I asked you why you thought this was a
bias in the C language; syntax specifically. I was quite clear about
what I was asking you and that was why were you singling out C as
special.

Maybe you were clear about this, but honestly, I think his original statement
made it pretty clear. Furthermore, it's easy to come up with an example
without a comparable bias: SQL. In SQL, it's just as practical to grab a
column from a table as a row. You can think of a table just as easily as
a structure of arrays as you can as an array of structures.

But in C, if you do an array of struct foo, there is no reasonable way to
get the "array" of just one member of each structure in the array. That's
not a natural thing in C. You can't treat it like you'd treat any other
array.

So I think it's pretty clear that C has such a bias. I think *most* languages
have this bias. But the thing is, I'm not really interested in whether it is
a stronger bias in C than it is in other languages, or a weaker bias. What I
care about is whether, in C, it is going to be practical to use a structure
of arrays rather than an array of structures, and the answer is "no".

-s

 

[nroberts]

Uranium atoms are large atoms; white dwarfs are small stars.
Therefore uranium atoms are larger than white dwarfs.  Conttext?  Who
needs context!




Thus you refute classical logic, e.g.,

    All men are mortal.
    Socrates is a man.
    Therefor Socrates is mortal.

By your criterion, for "mortal" to be an attribute, there must be
someone who is immortal.  Try this instead:  In order for X to be an
attribute it must be possible to distinguish between having X and not
having X.

I have to say that I'm not really buying all this logic crap you're
spewing. You had the chance to clarify that you did not mean to
single C out two weeks ago when I asked you why you thought this was a
bias in the C language; syntax specifically. I was quite clear about
what I was asking you and that was why were you singling out C as
special. If you'd said, "It's not and I never meant to say it was,"
way back then this whole long thread would never have happened. You
didn't though, you kept arguing with me as I explained why C wasn't
any different from any other programming language until now,
suddenly...you're trying to take the logical high ground.

You didn't say anything remotely like the logical construct above.
You just said, "Socrates is mortal." I said, "So is everyone else and
I don't think it can be otherwise," and then you argued with me! For
two weeks

I don't think anyone would debate that when working in formal logic
you'd be correct. The real point here isn't that you're wrong on
that, only that you're full of crap invoking it. This is bait and
switch.

I do have to say though, watching you seize about rather than do
anything quite so extreme as to admit perhaps you misspoke is a little
entertaining. How far into la-la land with Socrates, atoms and stars,
etc... are you willing to go?

Besides, how are you going to rationalize away the fact that you said
this was a syntactical bias? Even after I showed the same problem in
LISP you stuck to that one.

 

[nroberts]

I would agree that you appear not to be buying logic.  

Quadrille.

 

[nroberts]

In SQL, it's just as practical to grab a
column from a table as a row.  You can think of a table just as easily as
a structure of arrays as you can as an array of structures.

Employees table v1:

Name | Salary
================
Bob | 23
Joe | 10
Fred | 16

v2? (or did you have something better?):

Emp1 | Emp2 | Emp3
==================
Bob | Joe | Fred
23 | 10 | 16

Now, I assume you're going to ignore the fact that the types don't
match what you might do in v1; everything has to be a varchar now or
something similar. But let's pretend none of those inconvenient
things exist.

Compare addition and removal of employees in these two cases.

Average the salaries in the two...

COUNT the employees.

Looks to me like SQL has a "bias" toward representing employees as an
"array of structures" rather than "structure of arrays" to me.

 

[Seebs]

Employees table v1:

Name | Salary
================
Bob | 23
Joe | 10
Fred | 16

Right. Stop here.

Emp1 | Emp2 | Emp3
==================
Bob | Joe | Fred
23 | 10 | 16

No. I'm not talking about a different structure. I'm talking about that
first structure.

Looks to me like SQL has a "bias" toward representing employees as an
"array of structures" rather than "structure of arrays" to me.

But, contrast SQL's:
select salary from employees;
with C's idiom.

Consider if you will two SQL tables:

Table 1:
Value
1
2
3
4

Table 2:
value value2
1 foo
2 bar
3 baz
4 quux

SQL doesn't care which of these you select value from; you get the same
thing either way. Now contrast with C:

int a[100];
struct { int a, b; } a2[100];

In C, you can't turn a2.a into an array of 100 ints that you can use
precisely like any other array of 100 ints. In C, the array has to be
contiguous storage. In SQL, a column can be accessed as an array
regardless of how many columns there are, and multiple columns from
one table can be treated much as though they were themselves a table
regardless of whether or not they are adjacent to each other.

Consider the code to sum the array a, and the code to sum the members
a from the array a2 in C. Note that they differ at all in any way.
Now consider the code to sum a single-column table in SQL, and the code
to sum one of several columns in a table in SQL, and note that they
do not differ at all in any way.

C has a stronger bias here than SQL does.

-s

 

[nroberts]

Right.  Stop here.


No.  I'm not talking about a different structure.  I'm talking about that
first structure.

Yeah, more red herrings and other nonsense.

"If I use SQL I'm forced to use an abstraction that very much
resembles an array of records but I have this neat abstraction that
lets me to get values from the named columns of different records with
pretty much the same looking code. I like to think of this as an
inversion of the record/array relationship even though it isn't even
close to that and there's quite literally no sensible way to actually
invert that relation. Ergo C is biased to arrays of structures."

I don't know why that argument makes any sense to you, and apparently
a few others here, but it certainly doesn't me.

I agree, SQL has a nice table searching syntax. That's about as far
as we agree though. Even calling this phenomenon a "bias" seems
absurd to me.

 

[Seebs]

Yeah, more red herrings and other nonsense.

Not red herrings, a real observation about idioms in different languages.

I don't know why that argument makes any sense to you, and apparently
a few others here, but it certainly doesn't me.

Well, that we agree on. It seems you were uninterested in reading the
explanation.

I agree, SQL has a nice table searching syntax. That's about as far
as we agree though. Even calling this phenomenon a "bias" seems
absurd to me.

Okay, let's start from the top.

Imagine that there IS only one programming language, ever: C. And ask
the question:
I want to represent a number of items, each of which has several
traits. Should I represent these as an array of structures, or
as several arrays (possibly stored in a higher level structure)?

It seems pretty clear to me that, in C, the answer is nearly always the
former. In cases where there's an overwhelmingly strong reason to do it
the other way, such as working on a vector processor where it is *VITAL*
that all x be in one block of contiguous memory, and all y in another
block of contiguous memory, it's a lot of work and very easy to get it
wrong.

That constitutes a clear bias towards one way of approaching things.

Now what if there were other languages? Imagine, if you will, a language
in which the native data structure is a 2D array, in which both rows and
columns are primary objects which can be manipulated easily. In a language
like this, you might find that the degree of bias towards viewing things
one way rather than another was weaker. It might even be so weak that
it wasn't really obvious that doing things one way rather than the other
created a distinction you could perceive in code.

Think of, say, C's way of looking at arrays, where clearly each row is
an object, but each column is not an object. Now contrast this with, say,
the scripting language for a spreadsheet program, in which "column A"
and "row 1" are both primary objects.

So I put it to you that:

1. It is entirely meaningful to talk about C having a bias towards one
way of doing things rather than another, without any need to refer to
other languages or tools.
2. C in fact has a bias towards arrays of structures, rather than
structures of arrays, just as it has a bias towards arrays of rows
rather than arrays of columns.
3. Other languages do not always have as strong a bias.

-s

 

[nroberts]

On Nov 14, 8:01 am, (e-mail address removed) (Richard Harter) wrote:

I don't think anyone would debate that when working in formal logic
you'd be correct.

Actually, I change my mind. Having considered it more I believe
you're committing a categorical error here. In the above example,
there is a fact about Socrates that implies he is mortal. Not so when
one says that C has a bias toward arrays of structures.

C is simply a syntax of logic. There are many varieties. If it is
true, as seems to be now accepted, that the bias of arrays of
structures over structure of arrays is a logical one, and not
something specific to C, then there is nothing about C that causes the
bias. Since that's difficult to express, here's an example:

2 + 2 = 4.

Given the meaning of the symbols above we can evaluate that as a true
statement. Given your argument that C has a bias because it's an
example of a language of logic we would have to conclude that the
arabic symbols have a bias toward making 2 and 2 equal to 4. This is
not true though. The fact that two and two are four is an a priori
statement that superceeds syntax. "2+2=4" is simply an expression of
this truth, it does not create it. The bias that exists, if it even
makes sense to call it "bias" has nothing to do with the "language" we
are using to express it.

The same is true with regard to C and array of structure being
preferable to organize the kinds of data that have been discussed to
date. This preference is intrinsic to the nature of the data, not to
the language used to express its formulation.

 

[Seebs]

The same is true with regard to C and array of structure being
preferable to organize the kinds of data that have been discussed to
date. This preference is intrinsic to the nature of the data, not to
the language used to express its formulation.

I'm not sure this is the case. At one point I was doing some vectorizing
and it turned out that the nature of the data was such that I was best served
by using several arrays of 1024 objects and manually keeping track of the
parallels. Which, in C, was a giant pain to do. But it was *necessary*
that the x coordinates of four consecutive objects be stored contiguously.
(And on that hardware, moving individual scalars around was insanely
expensive, involving shifts and rotates and masks, because there were no
instructions for manipulating single 32-bit values.)

Let's consider a hunk of data. The data I propose we consider is
topographical data; we are considering a region of land, and we have
records of the average height above sea level of each square meter section
of a 1km square area.

So:

float heights[1000][1000];

Now consider a natural C operation:

float avg(float a[], int n) {
double total;
for (int i = 0; i < n; ++i)
total += a;
return (float) (total / n);
}

Consider the ease with which we determine the average height of each
row of data:

averages = avg(heights, 1000);

Now consider how we determine the average height of each column of
data.

C has a very strong bias which is in no way intrinsic to the data being
looked at.

-s

 

[Ben Pfaff]

I'm not sure this is the case. At one point I was doing some vectorizing
and it turned out that the nature of the data was such that I was best served
by using several arrays of 1024 objects and manually keeping track of the
parallels. Which, in C, was a giant pain to do. But it was *necessary*
that the x coordinates of four consecutive objects be stored contiguously.

The place where I always run into an equivalent problem is the
POSIX "poll" function. poll() accepts a pointer to the first
element of an array of structures. The array doesn't have any
space in it for user-provided metadata, and there's no way to
tell poll() to use a user-defined stride, etc. So almost every
time I use it, I end up with an array (or other data structure)
that parallels the array that poll() needs, to keep track of the
data that my own code needs. It's awkward, in my opinion.