Question on structs
phaedrus
I've got so far as structs in re-learning C and have hit a bit of a
wall. The online resources on the subject seem to contradict each
other in a way that I've not seen before. There's just ONE point I'd
like clarified, please.
This is my assertion:
A 'struct' in C is not actually a modularised cluster of disparate
data. It's simply a *template* for a complex variable of type struct,
and it is this *variable* which actually forms the modularised cluster
of disparate data. The struct itself is just an empty shell; merely a
*specification* for a data object. This data object is what we call a
variable of type struct. A struct alone therefore doesn't hold any
data; it is not like an array. Arrays can store data, structs by
themselves don't.
Have I got that right?
Thanks.
bert
No, I don't think that's right. An array can't store data; the
data is stored in its individual ELEMENTS. A struct can't store
data; the data is stored in its individual FIELDS. The elements
of the array are referenced by their subscripts; the fields of
the struct are referenced by their names. There's a difference,
but I think it's a much smaller difference than you think it is.
--
phaedrus
> No, I don't think that's right. An array can't store data; the
> data is stored in its individual ELEMENTS. A struct can't store
> data; the data is stored in its individual FIELDS. The elements
> of the array are referenced by their subscripts; the fields of
> the struct are referenced by their names. There's a difference,
> but I think it's a much smaller difference than you think it is.
> --
OK, point taken. Let me clarify, then.
The data in an array is stored in its elements.
The data for a struct is stored in the member fields of a structure
VARIABLE.
Is that correct?
Nick Keighley
> On Nov 5, 12:56 pm, bert <bert.hutchi...@btinternet.com> wrote:
> > No, I don't think that's right. An array can't store data; the
> > data is stored in its individual ELEMENTS. A struct can't store
> > data;
the struct declaration declares a type
> > the data is stored in its individual FIELDS. The elements
> > of the array are referenced by their subscripts; the fields of
> > the struct are referenced by their names. There's a difference,
> > but I think it's a much smaller difference than you think it is.
>
> OK, point taken. Let me clarify, then.
>
> The data in an array is stored in its elements.
> The data for a struct is stored in the member fields of a structure
> VARIABLE.
>
> Is that correct?
arrays are variables too...
There are types
int, struct S {float f}
there are declarations, which describe what something is but without
setting aside storage
extern int i;
extern int a[];
extern struct S s;
and there are definitions which set aside store
int i;
int a [10];
struct S s;
the slight confusion is that "naked" array types are hardly used (i'm
not even sure if they exist).
typedefs add an additional layer of confusing as despite their name
they don't define types but type aliases.
Richard Heathfield
Streater wrote:
> In article
> <ee58ab7e-f6b4-4f81...@w19g2000yqk.googlegroups.com>,
> phaedrus <orion....@virgin.net> wrote:
>
<snip>
>> The data in an array is stored in its elements.
>> The data for a struct is stored in the member fields of a structure
>> VARIABLE.
>>
>> Is that correct?
>
> As I recall, if I do:
>
> struct wiggy
> {
> int a;
> int b;
> }
>
> Then I've reserved some actual space (two ints-worth).
You recall incorrectly. The above is just a type definition. It
reserves no storage. If you'd done this:
struct wiggy
{
int a;
int b;
} earwig;
you'd have reserved (at least) two ints'-worth of storage. Or you
could do it like this:
struct wiggy
{
int a;
int b;
};
struct wiggy earwig;
> But you can also do:
>
> typedef struct wiggy
> {
> int a;
> int b;
> }
>
> which just defines a new type, wiggy,
No, it defines a new type, struct wiggy, and then gives (or rather, in
your case, fails to give) that type a synonym.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Richard
> In article
> <ee58ab7e-f6b4-4f81...@w19g2000yqk.googlegroups.com>,
> phaedrus <orion....@virgin.net> wrote:
>
> As I recall, if I do:
Why is everything "as you recall"?
>
> struct wiggy
> {
> int a;
> int b;
> }
>
> Then I've reserved some actual space (two ints-worth). But you can also
> do:
>
> typedef struct wiggy
> {
> int a;
> int b;
> }
>
> which just defines a new type, wiggy, and reserves no space. It's not
> until later that I do:
>
> int p;
> int q;
> wiggy diggy;
>
> that I've now reserved space for 4 ints.
>
> I *think* that's what I used to do.
Why would you offer advice in group of C specialists if you only "think"
that's what you used to do?
I'm intrigued.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
phaedrus
explain the concept better than anything else I've yet seen:
[begins...]
A structure is declared by making a blank template for a variable
package. This is most easily seen with the help of an example. The
following statement is actually a declaration, so it belongs with
other declarations, either at the head of a program or at the start of
a block.
struct PersonalData
{
char name[namesize];
char address[addresssize];
int YearOfBirth;
int MonthOfBirth;
int DayOfBirth;
};
This purpose of this statement is to create a model or template to
define what a variable of type struct PersonalData will look like. It
says: define a type of variable which collectively holds a string
called name, a string called address and three integers called
YearOfBirth, MonthOfBirth and DayOfBirth. Any variable which is
declared to be of type struct PersonalData will be collectively made
up of parts like these. The list of variable components which make up
the structure are called the members of the structure: the names of
the members are not the names of variables, but are a way of naming
the parts which make up a structure variable. (Note: a variable which
has been declared to be of type struct something is usually called
just a structure rather than a structure variable. The distinction is
maintained here in places where confusion might arise.) The names of
members are held separate from the names of other identifiers in C, so
it is quite possible to have variable names and struct member names
which are the same. Older compilers did not support this luxury.
At this stage, no storage has been given over to a variable, nor has
any variable been declared: only a type has been defined. Having
defined this type of structure, however, the programmer can declare
variables to be of this type. For example:
struct PersonalData x;
declares a variable called x to be of type struct PersonalData.
Seebs
I don't think so. Except I think you do, but you are using the terminology
in a surprising way.
IMHO, "a struct" refers both to the object of the type and to the type.
Consider:
"long int" is a type. "long int x;" declares an object of that type.
"struct foo" is a type. "struct foo x;" declares an object of that type.
But I would say that x is "a struct foo", and is "the struct itself" just
as much as the type declaration is.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
> The data for a struct is stored in the member fields of a structure
> VARIABLE.
>
> Is that correct?
No.
struct foo { ... };
void *v = malloc(10 * sizeof(struct foo));
struct foo *p = v;
p[3] <-- a struct, but not a struct variable.
The only variables there are p and v. Neither is a struct. p is a pointer,
not a struct.
Seebs
> Why shouldn't I? If I'm wrong, (certainly not excluded, see above) then
> I expect I'll be corrected by those who know better.
And this is why the status-weenies are idiots. They actually can't
conceive of you doing something in order to learn or develop, but which
could result in a temporary decline in other peoples' perception of you.
Scary, huh?
Richard Heathfield
> On 2009-11-05, Tim Streater <timst...@waitrose.com> wrote:
>> Why shouldn't I? If I'm wrong, (certainly not excluded, see above)
>> then I expect I'll be corrected by those who know better.
>
> And this is why the status-weenies are idiots. They actually can't
> conceive of you doing something in order to learn or develop, but
> which could result in a temporary decline in other peoples'
> perception of you.
Why would making a mistake result in a temporary decline in other
people's perception of you? I don't see that at all.
Richard
> In <slrnhf6733.42i...@guild.seebs.net>, Seebs wrote:
>
>> On 2009-11-05, Tim Streater <timst...@waitrose.com> wrote:
>>> Why shouldn't I? If I'm wrong, (certainly not excluded, see above)
>>> then I expect I'll be corrected by those who know better.
>>
>> And this is why the status-weenies are idiots. They actually can't
>> conceive of you doing something in order to learn or develop, but
>> which could result in a temporary decline in other peoples'
>> perception of you.
>
> Why would making a mistake result in a temporary decline in other
> people's perception of you? I don't see that at all.
>
> <snip>
It wouldn't. Honest mistakes are always fine.
Morris Keesan
struct foo { int bar; int baz; };
you're declaring a type, which is named "struct foo".
When you write
typedef struct { int bar; int baz; } foo;
you're declaring a type, which is named "foo".
When you write
struct { int bar; int baz; } foo;
you're declaring a variable named foo, which is a struct.
I think your confusion comes from the fact that struct types are often
declared as types, separate from declarations of variables.
--
Morris Keesan -- mke...@post.harvard.edu
Seebs
> Why would making a mistake result in a temporary decline in other
> people's perception of you? I don't see that at all.
That's a fascinating question, and frankly, I'm not sure I could answer it.
BUT!
Look at all the times the status weenies assert variously that people are
afraid to talk about things they don't know, afraid to answer questions,
afraid to post code for fear it might be criticized, and so on. There is
clearly a general pattern they presume, that demonstrating less-than-perfect
ability makes you look bad, so obviously, people ought to avoid doing this.
It's one of those epiphany things to realize that they genuinely think this
is a plausible motivation to ascribe to people. They really think stuff works
this way! (Perhaps more terrifying, there are large hunks of the world in
which it does to a greater or lesser extent...)
Keith Thompson
Not really.
I think you're getting hung up on the distinction between a *type* and
an *object* (variable) of that type.
Does the phrase "a struct" refer to a type or an object? Does the
phrase "an array" refer to a type or an object? Or, in either case,
does it refer to a value, which is yet another different thing?
I'm not going to give you a definite answer to any of those questions;
rather, I'm going to argue that they're not particularly important
questions.
Think of "array" and "struct" as adjectives, not nouns. You can have
an array type, an array object, an array value, a struct type, a
struct object, a struct value. And likewise for integers, pointers,
unions, et cetera.
(Note: I use the word "object" rather than "variable" because
it's more precise. An object is, by definition, a "region of
data storage in the execution environment, the contents of which
can represent values"; it typically, but not always, has a type
associated with it. The word "variable" is more ambiguous.
Is an object declared with "const" a variable? It can't vary,
can it? Is an object created by a call to malloc() a variable?
We don't have a name for it; some people would call it a variable,
some wouldn't. It's another way we can get hung up on terminology,
when it's the underlying concepts that are important.)
This:
struct foo { int x; int y; };
is a type declaration; it creates a struct type. This:
struct foo obj = { 10, 20 };
is an object definition; it creates an object of that type. The
*value* of that object (until you change it) is a composite value
consisting of the values of its members, 10 and 20.
Once you think of it this way, I suggest that the answers to all your
questions become fairly obvious. A struct type can be thought of
as a "template" (using the word in the English sense, not the C++
sense). As a type, it holds no data. It's a specification for a
data object; you can create arbitrarily many objects of that type.
A struct object (an object of a struct type) occupies some amount
of storage and holds some value, which may or may not change as
the program executes. And exactly the same applies to array types,
objects, and values.
Having said all that, people commonly do use "struct" and "array"
without qualification, as nouns. The phrase "a struct" can refer
to a struct object or a struct object, or even a struct value.
Likewise for "an array", though I suppose that refers more commonly
to an object rather than a type for some reason.
Most of the time, either the meaning is fairly obvious from the
context, or it doesn't matter much. If you find the unqualified
word "struct" or "array" confusing, just be more explicit, and
if someone else uses it in an unclear manner, just ask.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Kenny McCormack
Seebs <usenet...@seebs.net> wrote:
...
>It's one of those epiphany things to realize that they genuinely think this
>is a plausible motivation to ascribe to people. They really think stuff works
>this way!
Two words: Drama Queen
>(Perhaps more terrifying, there are large hunks of the world in
>which it does to a greater or lesser extent...)
Hmmm. That kinda disproves your whole thesis, don't it?
Richard Heathfield
> On 2009-11-05, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Why would making a mistake result in a temporary decline in other
>> people's perception of you? I don't see that at all.
>
> That's a fascinating question, and frankly, I'm not sure I could
> answer it.
I don't see any logical reason for it. Failure to acknowledge a
mistake, or failure to learn from it, would be a different matter.
But the man[1] who can't make a mistake can't do anything.
> BUT!
>
> Look at all the times the status weenies assert [...]
Well, no thanks - I have better ways to spend my time.
<snip>
[1] I have it on impeccable authority that women don't make mistakes.
Not "can't" - don't.
Seebs
> In article <slrnhf6dss.bjf...@guild.seebs.net>,
> Seebs <usenet...@seebs.net> wrote:
> ...
>>It's one of those epiphany things to realize that they genuinely think this
>>is a plausible motivation to ascribe to people. They really think stuff works
>>this way!
> Two words: Drama Queen
I'd agree that those words are perhaps accurate, but I was trying to be more
charitable. While thinking about relationships in terms of status does
generally lead to drama, I don't think it's usually intentional.
>>(Perhaps more terrifying, there are large hunks of the world in
>>which it does to a greater or lesser extent...)
> Hmmm. That kinda disproves your whole thesis, don't it?
Nope.
My thesis is that not everyone is completely driven by status -- in
particular, that especially among engineering sorts, you're likely to see
a lot of people who are totally unconcerned about status.
It's like culture. Cultural norms vary. That's fine. Lots of different
cultures work. What doesn't work is insisting on interpreting people's
behavior according to the rules of another culture, because that's crazy.
Imposing a status narrative on many of the posters in comp.lang.c is every
bit as stupid as trying to describe a Japanese business meeting in terms
of what the behaviors and speech acts in question would mean if they'd
been performed at a business meeting involving a bunch of Texans.
I'm not disputing that status relationships do exist in some contexts, or
that some people care about them. It's quite obvious that some people
care very deeply about them. I'm just disputing the assertion that every
relationship anywhere is necessarily about status, or even has a status
component to it. Not all do. It's only one of the many ways humans interact,
and some people don't do it. Autism's the obvious extreme case, but there
are plenty of people who are physically capable of experiencing status
relationships, but who still don't view status as a significant priority.
In short, there are a lot of people out there who would rather look bad
being right than look good being wrong. I know it may sound strange or
mysterious, but trust me, the opposite sounds just as strange to them.
But again: I've never claimed that *no* status relationships existed -- only
that not *everything* is a status relationship. If you think that
acknowledging the existence of status relationships undermines this, you
really do need to work on your basic reading comprehension skills. Maybe
you could start with the Sesame Street episode that introduces "some
of the monsters, all of the monsters, none of the monsters".
Seebs
>> Look at all the times the status weenies assert [...]
> Well, no thanks - I have better ways to spend my time.
I've found that a couple of hours spent saying "wait, they think WHAT?"
has been really rewarding in helping me deal with them when I have to.
It's like portability. Pays off eventually even if it's not obvious
why it should matter for a given project. :)
Peter Nilsson
> Tim Streater <timstrea...@waitrose.com> wrote:
> > In the context:
> > > Why would you offer advice in group of C specialists
> > > if you only "think" that's what you used to do?
> >
> > see above) then I expect I'll be corrected by those who
> > know better.
>
> And this is why the status-weenies are idiots. They
> actually can't conceive of you doing something in order
> to learn or develop,
Of course, we all learn through intelligent discourse,
but it's not particularly productive, educationally or
professionally, to be sloppy because you _expect_ others
to clean up after you.
'If I'm wrong people will correct me' is an attitude
that invariably places a burden on others to actually
do so. At the very least it is taking people for granted.
Asking questions is more conducive to development
than giving careless answers, whether qualified as
recollections or not.
--
Peter
Seebs
> Of course, we all learn through intelligent discourse,
> but it's not particularly productive, educationally or
> professionally, to be sloppy because you _expect_ others
> to clean up after you.
Not in general.
> 'If I'm wrong people will correct me' is an attitude
> that invariably places a burden on others to actually
> do so. At the very least it is taking people for granted.
In general, I might agree, but as it was already pointed out, Tim
went out of his way to highlight that his memory might be unreliable
in this matter.
> Asking questions is more conducive to development
> than giving careless answers, whether qualified as
> recollections or not.
If the only people giving answers are the ones who are totally certain
that they're right, we'll get a lot of very poor answers.
Barry Schwarz
By that reasoning, an int does not hold a value either, only an object
of type int can hold the value.
The phrase "int" can refer to the type or to an object of that type,
depending on the context of the discussion. The same is true of
struct y.
If you want to argue that after the definition
int x;
it is incorrect to say "x is an int" but rather "x is an object of
type int", then you would be consistent saying a struct y does not
hold data, only an object of type struct y does.
I would guess that the distinction is unnecessary in 99%+ of normal
discussions.
--
Remove del for email
Nick Keighley
> In <slrnhf6733.42i.usenet-nos...@guild.seebs.net>, Seebs wrote:
> > On 2009-11-05, Tim Streater <timstrea...@waitrose.com> wrote:
> >> Why shouldn't I? If I'm wrong, (certainly not excluded, see above)
> >> then I expect I'll be corrected by those who know better.
I still seems odd to give advice to newbies that is actually wrong. I
sometimes post stuff I don't know to be correct just so I can test the
waters. But if it went to a newbie I'd try to label it as tentative.
In front of experts I'd just say it.
> > And this is why the status-weenies are idiots.
for someone who doesn't understand status you don't half go on about
it...
> > They actually can't
> > conceive of you doing something in order to learn or develop, but
> > which could result in a temporary decline in other peoples'
> > perception of you.
never bothered me very much. Similarly I don't take the mick out of
people who don't know things I do (we're all ignorant about
something). The people who bug me are what I call the willfully
ignorant. It's not that they don't know something but that they don't
know something and pretend they do and won't be corrected.
Seebs
>> In <slrnhf6733.42i.usenet-nos...@guild.seebs.net>, Seebs wrote:
>> > And this is why the status-weenies are idiots. �
> for someone who doesn't understand status you don't half go on about
> it...
I can model it well enough to explain it and describe its effects, I just
don't have the experience. I dislike people who insist that I'm actually
motivated by something I don't experience. (It's IMPORTANT. Someone
is WRONG on the INTERNET.)
> never bothered me very much. Similarly I don't take the mick out of
> people who don't know things I do (we're all ignorant about
> something). The people who bug me are what I call the willfully
> ignorant. It's not that they don't know something but that they don't
> know something and pretend they do and won't be corrected.
Yeah. That can be either fascinating, horrifying, or funny, but is also
nearly always annoying. (I've been watching a particularly beautiful
case of it descend into madness, as someone who guessed wrong on a
physics brainteaser has spent months defending an ever stupider position,
and is now at a point where, to preserve his ego, he has to deny pretty
much the last four hundred years of basic physics. It's maddening,
and yet, strangely awe-inspiring to watch.)
phaedrus
now!
P.
spinoza1111
> On 2009-11-05,KennyMcCormack<gaze...@shell.xmission.com> wrote:
>
> > In article <slrnhf6dss.bjf.usenet-nos...@guild.seebs.net>,
But you are concerned with status, my dear boy. You are posting page
after page of nonsense to prove that you're right. And you continually
attempt to create artificial boundaries such that arguments that step
outside these boundaries can be dismissed as the arguments of the
insane.
For example, you thought recently that my relating of object oriented
code to labor unionization was a "non-sequitur" and proceeded to
denounce me as insane for this and other reasons.
But it's a documented fact that Bjarne Stroustrup started work in the
proto-object-oriented Simula culture, where Simula was a Fortran-based
language that used proto-objects to better document factory and
shipyard automation to Danish labor union heads, and I've provided the
documentation.
>
> -s
> --
> Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Nick Keighley
<snip>
> [spinoza related] object oriented code to labor unionization [...]
that *was* interesting (assuming you didn't make it up)
> But it's a documented fact that Bjarne Stroustrup started work in the
> proto-object-oriented Simula culture,
I know Simula was a major influence on C++. Did he actually start work
in the Simula culture?
> where Simula was a Fortran-based
Algol-60-based
<snip>
spinoza1111
wrote:
> On 12 Nov, 16:23,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> <snip>
>
> > [spinoza related] object oriented code to labor unionization [...]
>
> that *was* interesting (assuming you didn't make it up)
It's documented, but not, typically, in computer technical books
because most authors on tech matters within American culture are
silent on labor unionization or worker control as opposed to
management prerogative. This was because the Taft-Hartley act of 1948
stated that while American workers have the right to form unions, the
unions cannot control the workplace but only negotiate pay and
benefits.
My first programming job was at a heavily unionized university. The
computer operators at my job, two ladies of color who were Moms,
negotiated with my boss to get us all a four day week and as a result
our productivity increased and I was able to complete several art
works in a series called American Men of Science. This was in 1974. As
a long-term result the university gave its computer processing to a
facilities management company which proceeded to milk the university
while providing terrible service.
The operators needed clear instructions from me on my software which
is why I started using structured techniques in assembler (always GO
TO ing "down" the code so that its flowchart was structured). They
also had trouble determining which of 50+ programs to use to do Alumni
processing for selection and sorting, so I developed a proto-data base
that used format and selection sheets (somewhat on the model of an
ancient programming language called RPG, which had nothing to do with
rocket-propelled grenades) to replace those 50+ programs.
When I entered nonunion "real" jobs I was astonished and dismayed by
the authoritarianism and its reciprocal culture of doing as little as
possible work while claiming that "everybody else" was the problem.
For example, at Encyclopedia Britannica, most of the employees spent
half the day in the can snorting coke.
>
> > But it's a documented fact that Bjarne Stroustrup started work in the
> > proto-object-oriented Simula culture,
>
> I know Simula was a major influence on C++. Did he actually start work
> in the Simula culture?
He started work in Denmark.
>
> > where Simula was a Fortran-based
>
> Algol-60-based
OK, Fortran and Algol based.
>
> <snip>
Dik T. Winter
> On Nov 13, 5:10=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
...
> > > [spinoza related] object oriented code to labor unionization [...]
> >
> > that *was* interesting (assuming you didn't make it up)
>
> It's documented, but not, typically, in computer technical books
> because most authors on tech matters within American culture are
> silent on labor unionization or worker control as opposed to
> management prerogative.
I do not think Nick comes frm the American culture, and I do not come from
it either. But the story is in the Wikipedia page on Kristen Nygaard from
Norway, where Simula was invented. Note also that Ole-Johan Dahl has *not*
worked for the Norwegian trade unions, so the link between Simula and the
trade unions is very weak.
> This was because the Taft-Hartley act of 1948
> stated that while American workers have the right to form unions, the
> unions cannot control the workplace but only negotiate pay and
> benefits.
It is similar in Europe although no act is needed... BTW, Nygaards work
for the (Norwegian) trade unions was *not* oriented towards control of the
workplace, moreover, it was from 1971 to 1973 long after Simula had been
developed. But I think you have no idea how European trade unions work.
(Oh, BTW, I am also a member of a trade union...)
> > > where Simula was a Fortran-based
> >
> > Algol-60-based
>
> OK, Fortran and Algol based.
There is no trace of Fortran to be found in Simula.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
osmium
>>> where Simula was a Fortran-based
>>
>> Algol-60-based
>
> OK, Fortran and Algol based.
There is not an iota of Fortran influence in Simula. It is totally based on
Algol 60, you blathering nitwit.
spinoza1111
> In article <934919a0-6bcf-4c6d-831b-83cd29d68...@m7g2000prd.googlegroups.com>spinoza1111<spinoza1...@yahoo.com> writes:
> > On Nov 13, 5:10=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com> > wrote:
>
> ...
> > > > [spinoza related] object oriented code to labor unionization [...]
> > >
> > > that *was* interesting (assuming you didn't make it up)
> >
> > It's documented, but not, typically, in computer technical books
> > because most authors on tech matters within American culture are
> > silent on labor unionization or worker control as opposed to
> > management prerogative.
>
> I do not think Nick comes frm the American culture, and I do not come from
> it either. But the story is in the Wikipedia page on Kristen Nygaard from
> Norway, where Simula was invented. Note also that Ole-Johan Dahl has *not*
> worked for the Norwegian trade unions, so the link between Simula and the
> trade unions is very weak.
Didn't say he did. However, according to John Markoff (technology
historian) Simula was developed because the trade unions of Denmark
had by law input into technical decisions, and a right to learn how
factory automation was being implemented.
>
> > This was because the Taft-Hartley act of 1948
> > stated that while American workers have the right to form unions, the
> > unions cannot control the workplace but only negotiate pay and
> > benefits.
>
> It is similar in Europe although no act is needed...
In your dreams. The Taft-Hartley act is not law in Europe because it
would deprive European unions of power over work rules. The only
countries in which anything like it exists are marginal countries
returning to Fascism or clerical authoritarianism after Communism such
as Poland and Estonia, which were fooled into abandoning worker
protection by the "free market".
>BTW, Nygaards work
> for the (Norwegian) trade unions was *not* oriented towards control of the
> workplace, moreover, it was from 1971 to 1973 long after Simula had been
> developed. But I think you have no idea how European trade unions work.
> (Oh, BTW, I am also a member of a trade union...)
And as usual you'll get screwed because you don't even know your own
history and law.
>
> > > > where Simula was a Fortran-based
> > >
> > > Algol-60-based
> >
> > OK, Fortran and Algol based.
>
> There is no trace of Fortran to be found in Simula.
I was accepting a point made by another. This is because I first read
about Simula in 1970, in Saul Rosen's collection of papers on
programming languages, and it was designed, as were many other
languages of the time, in reaction to Fortran and in its footsteps.
Unfortunately, Fortran set the model because it was first implemented
and subsequent language designers had to react to its numerous
mistakes. Even Dijkstra says nice things about Fortran's being a
pioneering effort.
spinoza1111
> spinoza1111wrote:
Fuck you, asshole. I was tentatively accepting out of courtesy a point
made by another since I first read about Simula in Saul Rosen's 1968
collection of papers on programming languages, and all of the
implementors were reacting to or imitating Fortran.
bert
I think some of the European efforts would be
better described as reacting against Fortran,
than reacting to Fortran.
--
Squeamizh
Pass the crack pipe, please...
Dik T. Winter
> On Nov 17, 9:15 am, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
> > I do not think Nick comes frm the American culture, and I do not come from
> > it either. But the story is in the Wikipedia page on Kristen Nygaard
> > from Norway, where Simula was invented. Note also that Ole-Johan Dahl
> > has *not* worked for the Norwegian trade unions, so the link between
> > Simula and the trade unions is very weak.
>
> Didn't say he did. However, according to John Markoff (technology
> historian) Simula was developed because the trade unions of Denmark
> had by law input into technical decisions, and a right to learn how
> factory automation was being implemented.
It is highly unlikely to be correct as written. Why would a *Norwegian*
computing centre develop a language for the *Danish* trade unions? And
the right to give input to technical decisions and a right to learn how
things (not only automation) is implemented is pretty general in countries
that have reasonably strong trade unions (like much of Europe).
> > > This was because the Taft-Hartley act of 1948
> > > stated that while American workers have the right to form unions, the
> > > unions cannot control the workplace but only negotiate pay and
> > > benefits.
> >
> > It is similar in Europe although no act is needed...
>
> In your dreams. The Taft-Hartley act is not law in Europe because it
> would deprive European unions of power over work rules.
They do not have power over work rules. They have a right to go on strike
but it has to be announced and the managemant can start a legal procedure
which will in general be decided within 24 hours. The judges will decide
whether the strike is justified or not. In the case of public serevices
it is much less likely that the strike is justified than in other cases.
> >BTW, Nygaards work
> > for the (Norwegian) trade unions was *not* oriented towards control of
> > the workplace, moreover, it was from 1971 to 1973 long after Simula had
> > been developed. But I think you have no idea how European trade unions
> > work. (Oh, BTW, I am also a member of a trade union...)
>
> And as usual you'll get screwed because you don't even know your own
> history and law.
Apparently you do not know anything about it at all. Do you know that the
first trade union in the Netherlands dates from 1837?
> > > > > where Simula was a Fortran-based
> > > >
> > > > Algol-60-based
> > >
> > > OK, Fortran and Algol based.
> >
> > There is no trace of Fortran to be found in Simula.
>
> I was accepting a point made by another. This is because I first read
> about Simula in 1970, in Saul Rosen's collection of papers on
> programming languages, and it was designed, as were many other
> languages of the time, in reaction to Fortran and in its footsteps.
Oh well, it is also about that time that I first read about Simula 67...
I first did use it however some five or six years later.
> Unfortunately, Fortran set the model because it was first implemented
> and subsequent language designers had to react to its numerous
> mistakes. Even Dijkstra says nice things about Fortran's being a
> pioneering effort.
That Dijkstra says nice things about Fortran does not make Simula also
Fortran based.
Dik T. Winter
> On Nov 18, 11:56=A0am, "osmium" <r124c4u...@comcast.net> wrote:
...
> > >> Algol-60-based
> >
> > > OK, Fortran and Algol based.
> >
> > There is not an iota of Fortran influence in Simula. It is totally based
> > on Algol 60, you blathering nitwit.
>
> Fuck you, asshole. I was tentatively accepting out of courtesy a point
> made by another since I first read about Simula in Saul Rosen's 1968
> collection of papers on programming languages, and all of the
> implementors were reacting to or imitating Fortran.
If something is developped as a reaction of something else that does not mean
that it is also based on that something else.