On the development of C

[Tony]

It's still a jumping off point. That's a lie, in that I don't believe it
is
that. The concepts are a good jumping off point. The implementation sucks.

"I have constant difficulty understanding your posts. *What's* a
"jumping
off point"? C? Do you mean C is a good base for the design of a
language?"

Some of the undisputed syntax is, IMO. I like curly-brace languages over
other kinds.

For us "oldtimers"? Aren't the "new languages" the kids' "rock and roll"?

"what?"

Python, Ruby, web dev... the stuff the kids pick up on first and exploit
maximally. Those special-purpose tools are like rock-n-roll where every song
is destined to become unbearably annoying because of it's lack of musical
substance. (I could have simply said it is masturbation). The kids won't be
creating the next GP language or extending C. They will just use the next
rock-n-roll hit language in an ever-increasing specific and uncoherent way.

Cobol does OO now? (Just a blast from the past... I think they used to kid
me about structures because they said they came from Cobol... they called
them "records". I remember that day well. 1995. (There's a hidden story
that
I'm not telling here.))

"I think you *always* have a hidden story that you're not telling. I
sometimes
think you must be passing secret messages to some third party."

It wasn't a topical story. Just related.

That's the wrong question, of course, IMO. "What can be learned or
salvaged
from C?", seems more appropriate.

"I think Jacob wants to extend C"

I think he's already done that.

I've NEVER liked it!!! Good riddens! Bury it or drive a wooden stake into
it.

"I quite like it."

Fine.

Not really though,

"yes, really. Lots of things other languages put in the language
C puts in the library. The core C language is very small."

In that it is optional, I consider it, well, optional. The library part
probably hindered-it/is-hindering-it-now.

I am using C++ and replacing the std library with my own
library. Similar applies to C std lib.

"well if you want to, go for it."

Nope. It's the UNIX API.

"no it isn't. It really is a highly portable general purpose library."

I disagree because it is too "unixy" akin to how the Win32 API is too
"windowsy". YMMV. I consider both of those platform-specific APIs. That they
can be implemented on other platforms does not change my categorization of
them. My code currently runs against both of those but I am seeking
indepence from them (RIP).

That is all it is. I abstract it less than Win32
API because [it] is far less relevant to me. Nonetheless (is that one
word?), the
ISO lib is just another platform (UNIX), IMO.

Its main problems are:

1.1: No support for standard containers like lists or hash tables

I don't see that as a problem at all.

"since you don't think the library should be standardised this doesn't
surprise me!"

OK, good then.

don't think the comittee should be
in the library business. [he]language definition probably suffers because
of that.

"I disagree. Actually many language standards (most language
standards?)
include a library. Ada, Scheme, Algol-68, python, Java, perl.
Ones that don't (or are very small) Pascal, Coral, Algol-60"

Opinions vary. That's fine. The committees for languages like a centralized
approach. I, OTOH, prefer something much more specific, simple and elegant
rather than the proverbial "horse designed by committee".

Did you mean that "typedef" is brain-damaged? If so, I agree. (See Ada
2005
for a solution).

"No, he means things like complex and bignum"

So then one solution is to use C++, perhaps just that capability of it.
YMMV. "C with classes" all over again he was suggesting?

I don't think that is hardly the issue at all. It may be secondary, or
tertiary or... I don't know. But I know it is hardly primary.

"what is the issue then? I'm not necessarily agreeing with Jacob
but at least I know what's he's talking about."

I was just saying that that is not a big issue. I wouldn't bawk at
overloading the [] for strings, but I may for operator + meaning
concatenation. For me, the big issue is one of representation (structure)
vs. operation. There should probably be more than one type of string and
null-terminated shouldn't be any of those though.

Sounds like a NON-solution from the get-go.

"in what way is a non-solution? JN what's to extend and expand C
to rescue it from he perceives as it stagnation. In what way is that
a non-solution?"

It's making the same mistake C++ is today: built upon the baggage of C.

D is the opposite track, but
still fails. Go figure. Hmm. "Have C compiler, can travel" mantra? (What's
wrong with this picture?").

"it's word-salad?"

D chose the right method (a new language) IMO, but still didn't produce
something compelling, IMO.

Hmm. Kinda suspect. Why? Because you are focusing on "throwing errors over
the wall" rather than good design.

""you" (Jacob) or "they" (Microsoft)?"

"you" meaning anyone who exploits some general theory of EH in cognitive
laziness. That is, to invent an EH paradigm that results in less EH ("the
caller will handle it").

As you have noted: a NON-solution.

The C baggage is still there. While noting that there are things lacking,
one should analyze the flip side of that and see what is best to remove or
rethink/redesign/rework. (An example would be the brain-damaged enums and
typedefs). The backward compatibility constraint is too big of a pill to
swallow, IMO. For that, there is C++ already.

"Life support"? Unplug the respirator already!


False.

"why?"

Why do _I_ have to DISprove a statement like "True, C is simple"?
(Rhetorical). I don't. Prove it is simple.

Appeal to long-and-hard-thinker, non-sequitur.

Referencing Einstein seemed gratuitous.

Tony

 

[Tony]

Yes, but Jacob's point way about the need to convert. When you join
systems that have different lists, it does not matter how clean the
interface is, you can't use (usually) one where the other is expected.

Interfacing code at that level (the list implementation level) of
granularity is not recommended. Interfaces should be higher level than that.
If you have your nose that deep in someone else's code, you're just doing
hunting for snippets or complete rewrite based upon the thornier problem
domain algorithms contained therein. It is good to think of granularity,
subsystems, interfaces, DLL exported funcs and the like when architecting
systems. The internals should be hidden away. Containers are just
ingredients in the mixture.

"Standard" (ahem, "committee designed") libraries tend to be overly general
and complex to use and understand. While every programmer on a team
shouldn't be using separate container implementations, on separate projects
or in separate companies, I don't see that as a problem at all and actually
beneficial.

Tony

 

[Tony]

Some would say C++ and those other languages aren't even object oriented.
The creator of the term "object-oriented programming" defined what he
considers the definition.

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

"OOP to me means only messaging, local retention and protection and hiding
of state-process, and extreme late-binding of all things. It can be done
in
Smalltalk and in LISP. There are possibly other systems in which this is
possible, but I'm not aware of them." -- Alan Kay

The term OOP has become misused, and applied to cases where it shouldn't
be.

OO or OOP are overloaded terms. Abstract terms. Subjective terms. Those that
require the black-or-white strict definition of such a high level concept
have a problem with abstract thinking and probably are therefor not suited
to OO development. One who can think abstractly though can do OO in almost
any language. It's just easier in some than others (C++ vs C) and less
constraining in some than others (C++ vs Smalltalk).

I don't think we need OOP for most C programs though, and I don't like C++
for a variety of reasons.

I can't imagine a large C project where structure pointers aren't passed to
functions to better organize code. That is OO-style.

Tony

 

[jacob navia]

Interfacing code at that level (the list implementation level) of
granularity is not recommended. Interfaces should be higher level than that.
If you have your nose that deep in someone else's code, you're just doing
hunting for snippets or complete rewrite based upon the thornier problem
domain algorithms contained therein. It is good to think of granularity,
subsystems, interfaces, DLL exported funcs and the like when architecting
systems. The internals should be hidden away. Containers are just
ingredients in the mixture.

This is completely wrong.

Suppose there is a library using a list somewhere. They hide the way the
list is represented. Obviously, they give you then:

o An "enumeration" function that will call your function with each
member of the list.
o A "count" function that will tell you how many elements are in the
list
o An "insert" function that allows you to insert an element in the
list.
o A "delete" function that will take out an element from the list.

Of course they

o Forgot to add an "apply" function that will apply a function
to each member. You can make it by using the enumeration function
but you pay an extra function call.
o Forgot a "erase-all" function to wipe out tyhe entire list.

Why they forgot?

Because they were concentrated in their subject matter and not
in providing a full list interface OBVIOUSLY.

If there was a STANDARD list interface then they would have used
THAT interface immediately without losing time to develop
YET ANOTHER LIST INTERFACE!

Each new list interface must be learned, looked up in the
documentation, maintained. Multiply that and you get a
staggering number of wasted effort.

I have presented several months ago in this group the code
that lcc-win uses for its list package as a possibility.

In short, each list object has a function table of interface
functions that provides a base interface.

list->lpVtbl->Append(list,newmember);
list->lpVtbl->Insert(list,existingMember,position);

Forgot one?

Just add a functionto the table.

Do not like the behavior of one interface function?

Replace at run time the function pointer by your own.

This design is flexible and simple enough.

Note that we do not even stress the need to cover 100% of
applications. 80% would be enough since the design is
completely flexible.

"Standard" (ahem, "committee designed") libraries tend to be overly general
and complex to use and understand.

The C library is bad, but "overly general"? Surely not.

While every programmer on a team
shouldn't be using separate container implementations, on separate projects
or in separate companies, I don't see that as a problem at all and actually
beneficial.

There is absolutely not any support in the real world for this. You
think it is beneficial to rediscover the wheel each time?

Yes, wheels ARE USEFUL, but why do you need to design a different one
for each application?

 

[Guest]

"I have constant difficulty understanding your posts. *What's* a
"jumping off point"? C? Do you mean C is a good base for the design of a
language?"

I *really* don't like this quoting style

Some of the undisputed syntax is, IMO. I like curly-brace languages over
other kinds.

my point was you seem to employ a deliberatly obscure way of
saying things. So C would make the good basis for a design.
You like the rather spare syntax, for instance?

"what?"

Python, Ruby, web dev... the stuff the kids pick up on first and exploit
maximally. Those special-purpose tools are like rock-n-roll where every song
is destined to become unbearably annoying because of it's lack of musical
substance.

you know, I would *never* have guessed that was what you meant by rock-
n-roll!
Why not say what you mean rather than hiding it behind your own
private language?

(I could have simply said it is masturbation). The kids won't be
creating the next GP language or extending C. They will just use the next
rock-n-roll hit language in an ever-increasing specific and uncoherent way.

history indicates that when someone of your maturity (I assume you
don't
put yourself in the "kids" class) says something like this about
"kids"
they are usually wrong. The shallowness and here-today-gone-
tomorrowness
that you perceive in the use of modern languages may go on to surprise
you.
I suspect some of those "kids" will go on the write amazing GP
languages.
Or maybe the time of GP languages has passed.

"No, he means things like complex and bignum"

So then one solution is to use C++, perhaps just that capability of it.
YMMV. "C with classes" all over again he was suggesting?

You should really ask Jacob. Or read his back posts in clc.
But in essence he considers C++ to be too big, a mess.
Whilst C has stagnated. He wants a small language with modern
features like operator overloading. Operating Overloading
gives, he believes, a way to add new arithmetic types and
standardised containers.

Why do _I_ have to DISprove a statement like "True, C is simple"?
(Rhetorical). I don't. Prove it is simple.

Well "simple" is a little wooly to define. C has a small official
definition- even with the library! The basics of C can be learned
quite
quickly. K&R is a small book.

By these sort of criteria C and Pascal are "simple". Ada and C++
are not.

What is simpler than C. Scheme?

<snip>

 

[Tony]

This is completely wrong.

That is completely wrong: you are expressing an opinion and trying to make
it an absolute.

Suppose there is a library using a list somewhere. They hide the way the
list is represented. Obviously, they give you then:

o An "enumeration" function that will call your function with each
member of the list.
o A "count" function that will tell you how many elements are in the
list
o An "insert" function that allows you to insert an element in the
list.
o A "delete" function that will take out an element from the list.

Of course they

o Forgot to add an "apply" function that will apply a function
to each member. You can make it by using the enumeration function
but you pay an extra function call.
o Forgot a "erase-all" function to wipe out tyhe entire list.

Why they forgot?

Because they were concentrated in their subject matter and not
in providing a full list interface OBVIOUSLY.

If there was a STANDARD list interface then they would have used
THAT interface immediately without losing time to develop
YET ANOTHER LIST INTERFACE!

Again, I don't think containers should be things you are interfacing with
rather than using directly. It's the wrong (bad design) componentization of
the software. If you're making some kind of assumption that someone is
actually going to bite off on the concept of a container "library" that is
only exposed via an interface in a DLL, and it's pretty apparent that you
are, well I think that's ridiculous.

[snip]

The C library is bad, but "overly general"? Surely not.


There is absolutely not any support in the real world for this.

Yes there is:

You
think it is beneficial to rediscover the wheel each time?

I didn't say that and you know I didn't. Surely you can grok that there are
more choices than using an ISO container library or creating a new one each
time.

Yes, wheels ARE USEFUL, but why do you need to design a different one
for each application?

I didn't say that so stop implying that I did.

Tony

 

[Tony]

I *really* don't like this quoting style

I'm not going to manually put in the >'s for the few people who have weird
output from their newreaders.

my point was you seem to employ a deliberatly obscure way of
saying things.

Sometimes "I don't want to give up the store" that easily.

So C would make the good basis for a design.

Some percentage of it. Not enough to call it a "basis" though.

You like the rather spare syntax, for instance?

Yes, definitely, but to a point. I would liked to have seen a few more
keywords in C++ in place of operators. Operators make source code too
cryptic.

you know, I would *never* have guessed that was what you meant by rock-
n-roll!
Why not say what you mean rather than hiding it behind your own
private language?

English is full of metaphor and analogy. You should probably get used to it.

history indicates that when someone of your maturity (I assume you
don't
put yourself in the "kids" class) says something like this about
"kids"
they are usually wrong.

Maybe I was prodding them?

The shallowness and here-today-gone-
tomorrowness
that you perceive in the use of modern languages may go on to surprise
you.

Well VB was/is wildly popular too, but I don't use that either. Mass use is
no indication of excellence or even adequacy.

I suspect some of those "kids" will go on the write amazing GP
languages.

There's a first time for everything. Imagine that, the first amazing GP
language!

Or maybe the time of GP languages has passed.

Sounds like something I've said, just not so absolutely.

You should really ask Jacob. Or read his back posts in clc.
But in essence he considers C++ to be too big, a mess.

Why he would want to start out with the same smaller mess that the C++
designers did, knowing well that C baggage is a big issue with C++, is
perplexing.

Whilst C has stagnated. He wants a small language with modern
features like operator overloading. Operating Overloading
gives, he believes, a way to add new arithmetic types and
standardised containers.

That can already be done with C++, where "you don't pay for what you don't
use". I'm of the "strip away from C++" (especially C baggage) rather than
build upon C mindset. C, C++, D are all uninspiring IMO.

Well "simple" is a little wooly to define. C has a small official
definition- even with the library! The basics of C can be learned
quite
quickly. K&R is a small book.

By these sort of criteria C and Pascal are "simple". Ada and C++
are not.

What is simpler than C. Scheme?

I don't know. I haven't finished what I'm working on yet.

Tony

 

[Richard Bos]

Yes, wheels ARE USEFUL, but why do you need to design a different one
for each application?

No, of course not. The obviously right solution is to take a wheel from
a Roman war chariot, and add bits until it works both on a wheelbarrow
and on a Formula 1 car.

Richard

 

[Richard Bos]

Yes, but I took it to refer to faulty compilers. If you take it to
cover external agents like debuggers, then it seems to invalidate the
whole of your article. You're trying to draw a line between the
program itself and external files, but that is a purely theoretical
line. What matters for assessing safety is not what the standard
guarantees, but what you can rely on in practice.

The problem with that approach is that it implies that all programs are
perfectly safe, _and_ that all programs are potential death traps. It
doesn't really mean anything at all, and in particular, it doesn't mean
anything about the safety or otherwise of C, gets(), or assumptions
about the contents of files.
The difference is that the C Standard does claim that conforming
implementations must not change non-volatile objects, and does not claim
that about files. Someone mucking about with a debugger is not a
conforming C implementation. You might argue that it is, indeed, a
non-conforming C implementation instead - and you'd be correct, but at
the same time it is a non-conforming Ada implementation, a
non-conforming BASIC implementation, and a non-comforming INTERCAL
implementation. The argument, while true, has an information content of
zero.

Richard

 

[Richard Tobin]

Yes, but I took it to refer to faulty compilers. If you take it to
cover external agents like debuggers, then it seems to invalidate the
whole of your article. You're trying to draw a line between the
program itself and external files, but that is a purely theoretical
line. What matters for assessing safety is not what the standard
guarantees, but what you can rely on in practice.

[/QUOTE]

The problem with that approach is that it implies that all programs are
perfectly safe, _and_ that all programs are potential death traps. It
doesn't really mean anything at all, and in particular, it doesn't mean
anything about the safety or otherwise of C, gets(), or assumptions
about the contents of files.

Not at all. It just means that the truth is messy, and you have
to deal with it.

The difference is that the C Standard does claim that conforming
implementations must not change non-volatile objects, and does not claim
That About Files.

So the question is whether you have to worry about someone with a
debugger, and whether you have to worry about someone changing the
files. The C standard can give you no guarantees about either. It
may *assume* that no-one uses a debugger, and not make that assumption
about file modification, but that doesn't help: you can pay for the
most expensive, most tested C compiler and if still doesn't prevent
anyone from using a debugger.

Someone mucking about with a debugger is not a conforming C
implementation.

In which case, no-one sells a conforming C implementation, since they
can't control whether some one mucks around with a debugger. No-one
can say "I've got a conforming C implementation, so I don't have to
worry about someone changing the code with a debugger".

-- Richard

 

[Ben Bacarisse]

I'm not going to manually put in the >'s for the few people who have weird
output from their newreaders.

Your newsreader can't do standard Usenet quotes? I thought it could,
though I don't know it well.

 

[Keith Thompson]

I'm not going to manually put in the >'s for the few people who have weird
output from their newreaders.

[...]

Manually? Your newsreader should be putting in the >'s automatically.
If it doesn't, get a better newsreader.

I think you're using Outlook Expression. I've heard of something
called "Quotefix". Please look into it.

 

[jacob navia]

You should really ask Jacob. Or read his back posts in clc.
But in essence he considers C++ to be too big, a mess.
Yes.

Whilst C has stagnated.
Yes.

He wants a small language with modern
features like operator overloading. Operating Overloading
gives, he believes, a way to add new arithmetic types and
standardised containers.

I do not "believe" that. I have implemented it in lcc-win.
This is a small difference, but crucial in my opinion.

The problem with C++ is that they have gone into the complexity
trip so far that this reaches absurd proportions.

The problem with C is that it has stangnated also into absurd
proportions like keeping "gets()" in the standard in 2010!

What I propose is not going into the extremes. That's why
I am attacked from all sides

 

[Keith Thompson]

The problem with C is that it has stangnated also into absurd
proportions like keeping "gets()" in the standard in 2010!

It's not 2010 yet. The committee has plenty of time to do whatever
it's going to do with gets().

What I propose is not going into the extremes. That's why
I am attacked from all sides

No, it isn't.

 

[Ian Collins]

(e-mail address removed) wrote:

I do not "believe" that. I have implemented it in lcc-win.
This is a small difference, but crucial in my opinion.

Have you ever tried to persuade any other compiler maintainers to adopt
your implementation? That would be the first step to getting them
standardised.

The problem with C++ is that they have gone into the complexity
trip so far that this reaches absurd proportions.

As we've argued many times, a team or individual is free to pick the
subset of the language they are happy with.

One team (of DSP programmers) I'm currently mentoring has done just
that. They have opted for C++ because they initially want RAII and
function overloading. Once they are more familiar with the language
understand the benefits of other features, they will use more of them.

The problem with C is that it has stangnated also into absurd
proportions like keeping "gets()" in the standard in 2010!

There we agree!

What I propose is not going into the extremes. That's why
I am attacked from all sides

You get "attacked" for refusing to consider alternatives.

 

[jacob navia]

It's not 2010 yet. The committee has plenty of time to do whatever
it's going to do with gets().

Of course!

The future is very long...

They can debate that until 2020 or maybe 2030 who knows?

They could even wait until the clock turns around the 32 bits
in 2038...

 

[luser-ex-troll]

Of course!

The future is very long...

They can debate that until 2020 or maybe 2030 who knows?

They could even wait until the clock turns around the 32 bits
in 2038...

Is that when the monks finally stop shuffling the discs on the towers
of Hanoi? Good time to finally get our t's crossed.

lxt

 

[Dik T. Winter]

> >
> > I'm not going to manually put in the >'s for the few people who have weird
> > output from their newreaders.

> [...]
>
> Manually? Your newsreader should be putting in the >'s automatically.
> If it doesn't, get a better newsreader.

Everybody is apparently missing the point. The part with double quotes is
from an earlier article by Nick Keighley that Tony copied. I do not know
any newsreader that will put >'s automatically when you copy and paste from
any other source than the article you are replying to. It was in reply to

> It's still a jumping off point. That's a lie, in that I don't believe it
> is that. The concepts are a good jumping off point. The implementation
> sucks.

and so Tony's indirect quote seems pretty appropriate.

 

[Tony]

Your newsreader can't do standard Usenet quotes? I thought it could,
though I don't know it well.

Your complaint is not with me if you have one, it is with Microsoft. Unless
you tell me what menu to go to. I agree there is an issue. I don't think it
is Tony.

Tony

 

[Tony]

I'm not going to manually put in the >'s for the few people who have
weird
output from their newreaders.

[...]

Manually? Your newsreader should be putting in the >'s automatically.
If it doesn't, get a better newsreader.

Not my problemo. Go talk to MS and I will watch.

I think you're using Outlook Expression. I've heard of something
called "Quotefix". Please look into it.

Nope. Surely they have reason for not "fixing" the problem as it has been on
the books for quite some time. I'm not in the middle of a political pissing
contest. I use OE. If it has problems, my use of it will show that. If there
is an issue, it will surface. (Amazing how long this has been going on,
btw). I plug my TV into the cable and expect it to work.

Tony