Container library (continued)

[ng2010]

I have often used list libraries. I'd use hash libraries if I needed a
hash.
In neither case would I use a "container" library in C -- it's the
wrong
level of abstraction for C, so far as I can tell. I've never in any
language
wanted "a container". In OO languages, it's useful that the specific
things
I request are also generically "containers". In C, it's not useful,
because
I can't do anything with it.

This sounds sooo much like thrashing on whether a "Line" should draw
itself or should be drawn by a "Canvas" or other abstraction. Don't walk,
run to the next level: jettison old paradigms.

 

[ng2010]

You can do OO in C. I think most people don't because they have
it drilled into their heads that "C is not an object-oriented"
language. Which to be fair, it isn't, but that doesn't mean that
there are reasonably-elegant[1] ways to do OO.

Your opinion of "reasonably elegant" is just that: an opinion. Apparently
Navia is willing to make the concessions necessary also. It is simply not
necessary to keep hitting one's self in the head with a hammer. OO and C
can never be "elegant". I think maybe Navia's problem is (as is my own)
that the compiler black box is just that: a black box! If you start with
a C compiler, then you end up trying to escape C by extending it and the
complex compiler you started with. It is an error of entry. The way to go
is to start with a clean slate. No baggage, no pain (from that hammer
hitting you on the head). It's sad to see him spinning his wheels and not
getting anywhere because he is stuck in the mud of C.

 

[Seebs]

This sounds sooo much like thrashing on whether a "Line" should draw
itself or should be drawn by a "Canvas" or other abstraction. Don't walk,
run to the next level: jettison old paradigms.

This is pretty useless advice.

Understanding what makes a design work is important regardless of language.

-s

 

[ng2010]

C++ doesn't use inheritance in its container classes. Having seen
inheritance based conatiner classes I tend to think its the wrong
mechanism.

Having implemented container libraries, I think that is where the layman
starts out. While I never had something like all containers derived from
a Container class, surely I did think about it (over a decade ago!). I do
think I have the "correct" architecture now (at least it is mature and
not kids stuff like Navia seems to be spouting!). Of course you'd have to
use "my" language (not yet available) to enjoy it. Stay tuned.

 

[ng2010]

and the solution was? I'm not convinced there *is* a single right
answer for all situations.

The solution to what? I know the answer to your second question and I
could tell ya, but then I'd have to kill ya. Ya know?

 

[ng2010]

This is pretty useless advice.

It wasn't advice. It was assessment of the situation of the current
dialog. aka, "been there, done that".

 

[Seebs]

It wasn't advice. It was assessment of the situation of the current
dialog. aka, "been there, done that".

"Don't walk, run..." is an imperative. Unless you're the emperor,
your imperatives are "advice".

The point is, it's not useful -- people need to think about these things
to develop a good map of the problem space. There's good reasons for some
things to be done in C, and thinking about how to do them well in C is
useful.

-s

 

[jacob navia]

ng2010 a écrit :

Jacob: Do you even know C++? Because it sounds like you are burying your
head in the sand and doing wishful thinking and hoping that others would
believe and follow you, but the fact of the matter is that you are the
only one who wants to put lipstick on a pig!

Why?

You are misunderstanding me. I do not want to use C++!

Eventually, all the old iron
of detroit will be gone, rusted away. So will C rust away.

The usage of C is not decreasing but increasing. Big and important
projects like the linux kernel, Apache, and many others are written
in C. The folks in C++ have been yelling this for ages now and
the usage of C doesn't disminish at all.

They believe that throwing ad hoc complexity at problems is the solution
to everything. No, it is not. C++ has become such a monster of
complexity that not even the creator of the language is able to add
a new feature, after years of trying. ("concepts" anyone?)

"A few" still
drive around the old cars, but they are still deathtraps and old,
obsolete technology.

Because you believe that more complexity is better. Go on. I believe that
the future belongs to SIMPLER languages.

What I want to do is participate to the evolution of C. This group is about
that. Note that you have comp.lang.c++ to discuss your stuff. Coming here
trolling about how C is a piece of crap is simply acknowledging that it
scares you if C would continue its own development. You, and all those
C++ zealots try to destroy C because deep in their minds they are afraid
that people realize that what is important in a language is simplicity
and power, not complexity.

 

[Richard Bos]

and the solution was? I'm not convinced there *is* a single right
answer for all situations.

....is the correct answer.

Richard

 

[ng2010]

You can do OO in C. I think most people don't because they have
it drilled into their heads that "C is not an object-oriented"
language. Which to be fair, it isn't, but that doesn't mean that
there are reasonably-elegant[1] ways to do OO.

Your opinion of "reasonably elegant" is just that: an opinion.
Apparently Navia is willing to make the concessions necessary also.
It is simply not necessary to keep hitting one's self in the head
with a hammer. OO and C can never be "elegant". I think maybe Navia's
problem is (as is my own) that the compiler black box is just that: a
black box! If you start with a C compiler, then you end up trying to
escape C by extending it and the complex compiler you started with.
It is an error of entry. The way to go is to start with a clean
slate. No baggage, no pain (from that hammer hitting you on the
head). It's sad to see him spinning his wheels and not getting
anywhere because he is stuck in the mud of C.

Redefine the term "elegant" and maybe, we could agree. Different people
have different meanings for that I think. I believe some, not so
horrible, OO in C could be done...

I don't even want to waste my time discussing it (OO in C). This isn't
the 1980's. (That said, a C-LIKE language who's purpose was to be an
enabler, for modern languages that are elegant, by being JUST an
intermediate language may have some merit, the point being to enable
language designers and them being able to avoid writing compiler
backends).

 

[ng2010]

ng2010 a écrit :

Why?

Maybe if you'd study C++ that would be apparent?

You are misunderstanding me. I do not want to use C++!

If you design just libraries, OK, then you fit in the category of "user"
(of the language). When you go and extend the language, you move or are
moving into language designer territory. It doesn't matter that something
is "valid C", once you start creating macros and keywords and
underpinnings that the language is not designed to support, then you are
outside of the realm of "user". You could build a house today with only
the tools that were available 100 years ago, but why? Programming
languages are nothing to be romantic about.

The usage of C is not decreasing but increasing. Big and important
projects like the linux kernel, Apache, and many others are written
in C.

Don't yell/advertise that too loudly, because that will increasingly
become a negative trait and a characteristic of obsolescence. All you did
was state large and incomprehensible codebases and poorly designed
software. (The Apache folks have some useful libraries that would be
better if not for the limitations of the language they are written in).

(Aside: Go Apache! Linux go suck a rock. GPL sucks!)

The folks in C++ have been yelling this for ages now and
the usage of C doesn't disminish at all.

C++ owes much of it's non-lucrativity to C. (Maybe ALL of it).

They believe that throwing ad hoc complexity at problems is the
solution
to everything. No, it is not. C++ has become such a monster of
complexity that not even the creator of the language is able to add
a new feature, after years of trying. ("concepts" anyone?)

I'm not going to be sucked into flame wars with you. C++'s major weakness
is it's ancestry: C. That's why I said STUDY it rather than saying USE
it.

Because you believe that more complexity is better. Go on. I believe
that
the future belongs to SIMPLER languages.

You're not listening. (Did I mention something about "burying your head
in the sand"?). I don't know you, so I don't know your ability to
comprehend, learn and think. But you dialog in this thread so far to me
seems to be very self-centered at worst, or childish at best.

What I want to do is participate to the evolution of C.

Go for it. I think that concept is oxymoronish. Reif with romanticism
misplaced, surely. But I can address, either my misunderstanding or
yours: Where do you C as being relevant? What domains? What application
programs? Who is the target user? If you say everything from desktop GUI
programs to space shuttle life support systems, well I'll probably bozo
bin you.

This group is about
that.

I thought there was a ISO standard group to talk about "evolution" (I
don't think that group is interested in doing that). And if this group is
then for USERS and USAGE of C, then I think your ideas are outside of the
language's charter. I recognize you were hoping for my quick dismissal. I
just lurk in here usually. I'm not here to try to convince anyone to use
C, extend it, or use any other language. You, OTOH, DO have agenda that I
have noted that I think is outside of the realm of C. (I called you an
aspiring language-designer/evolver or something, and if you are young
still, I would hope that you wouldn't waste your time with "legacy"
code/languages).

Note that you have comp.lang.c++ to discuss your stuff.

When you make assertions like that without knowing, I immediately
categorize you as "youngster" (no offense meant). Surely after this
response to you, you will see clearly where I was coming from and that it
was not obfuscated at all and that the "burying your head in the sand"
comment is true to your life: you are blinded by what you THINK you know.

Coming here
trolling about how C is a piece of crap is simply acknowledging that it
scares you if C would continue its own development.

You can go live in the haunted house in the remote location if you want
to. I don't find it habitable, nor do I find it rebuildable/rennovatible:
it's just not worth it. It's easier to start from scratch or buy
something shiney and new. The latter will trump the capabilities of the
former in every category (except maybe historical romanticism).

You, and all those
C++ zealots try to destroy C because deep in their minds they are
afraid
that people realize that what is important in a language is simplicity
and power, not complexity.

As if you knew something about language design.

 

[Andrew Poelstra]

Don't yell/advertise that too loudly, because that will increasingly
become a negative trait and a characteristic of obsolescence. All you did
was state large and incomprehensible codebases and poorly designed
software. (The Apache folks have some useful libraries that would be
better if not for the limitations of the language they are written in).

(Aside: Go Apache! Linux go suck a rock. GPL sucks!)

Ah, but surely you've noticed the popularity of
both Linux and Apache? Perhaps it's just since
all their users and developers are not as smart
as you are.

Because, obviously complexity is a Good Thing.

-plonk-

 

[Tim Rentsch]

A better word than "container" is "collection".

Invent a new technical term - like "box" or "sack". Why ever not?

Short words like this tend to be evocative of more specific (that
is, unintentionally or overly specific) properties, eg, a "box"
is "square" and "stackable", a "sack" will cause "everything to
be lumped together", etc. For a really abstract class a more
neutral, more generic word is better. Even "container" is more
evocative than "collection", which is neutral as to whether it
holds values or references.

 

[Tim Rentsch]

I don't know of another generalization to container in C. I know of
many lists and vectors and the like.


But without inheritance, "container" is not a useful level of abstraction.

I think you're confusing two distinct concepts, namely, inheritance,
which has to do with code reuse within a class hierarchy (or library),
and interface/type conversion, which has to do with using one kind of
"thing" as a different kind of "thing". These notions are not
unrelated but still largely orthogonal; certainly it's possible to
have either of the two without having the other.

The thing that makes "container" useful is that it provides for commonality
between "list" and "hash". But that's only useful when list and hash are
the types you actually work with, but because of inheritance, you can treat
them both as containers.

Because of interface/type conversion, not because of inheritance.

Without inheritance, either you have to call things "container" regardless
of which they are, and thus have access to an API that only makes sense for
a list when you're using a hash, and an API that only makes sense for a hash
when you're using a list, or you lose the ability to write a function which
just takes a "container".

Again, without interface/type conversion. Inheritance is an
implementation technique, and doesn't have any effect on how
client code uses a class library.

I have often used list libraries. I'd use hash libraries if I needed a hash.
In neither case would I use a "container" library in C -- it's the wrong
level of abstraction for C, so far as I can tell. I've never in any language
wanted "a container". In OO languages, it's useful that the specific things
I request are also generically "containers". In C, it's not useful, because
I can't do anything with it.

Actually, you could, although it takes a little more care and
little bit more effort in C than it does in languages that have
more support for object-oriented programming. That may make it
somewhat less useful in C than in other languages, but to say
absolutely that "it's not useful" in C is an overstatement.

 

[Tim Rentsch]

This is pretty useless advice.

Understanding what makes a design work is important regardless of language.

This comment seems somewhat naive. Some design patterns work much
better in one programming paradigm than another, and different
languages are definitely different in how well they fit different
paradigms. For example, C is just fine for procedural programming,
maybe okay for object-oriented programming, somewhere between fair
and poor (depending on "how functional") for functional programming,
and generally awful for logic programming. If someone is content to
stick just with design patterns that work in procedural programming
or (not too emphatic) object-oriented programming, then these all can
be expressed in C (or most other widely used procedural languages).
If, however, one wants to use functional programming design patterns
or logic programming design patterns, then trying to express said
designs in C will be fraught with difficulties. Of course, in the
literal sense the last statement quoted above may be true --
understanding what makes a design work _is_ important no matter which
language will be used to implement the design. But choosing a good
design, as well as understanding what makes it work, is _not_
independent of language, because not all designs work in all
languages.

 

[Seebs]

This comment seems somewhat naive. Some design patterns work much
better in one programming paradigm than another, and different
languages are definitely different in how well they fit different
paradigms.
Sure.

If, however, one wants to use functional programming design patterns
or logic programming design patterns, then trying to express said
designs in C will be fraught with difficulties.

Yes. That doesn't make it useless to look at how they work effectively,
even if the conclusion that leads you to is "this is a poor fit for
this language".

Of course, in the
literal sense the last statement quoted above may be true --
understanding what makes a design work _is_ important no matter which
language will be used to implement the design. But choosing a good
design, as well as understanding what makes it work, is _not_
independent of language, because not all designs work in all
languages.

Agreed. But in a case like this in particular, I think it's quite
reasonable to talk about the kinds of design Jacob is looking at in
terms of C. There are good reasons to implement these things in C
at one level or another, and good reasons not to jump to C++.

Newness for the sake of newness is not a particularly good engineering
strategy.

-s

 

[Nick Keighley]

This comment seems somewhat naive.  Some design patterns work much
better in one programming paradigm than another, and different
languages are definitely different in how well they fit different
paradigms.  For example, C is just fine for procedural programming,
maybe okay for object-oriented programming, somewhere between fair
and poor (depending on "how functional") for functional programming,
and generally awful for logic programming.  If someone is content to
stick just with design patterns that work in procedural programming
or (not too emphatic) object-oriented programming, then these all can
be expressed in C (or most other widely used procedural languages).
If, however, one wants to use functional programming design patterns
or logic programming design patterns, then trying to express said
designs in C will be fraught with difficulties.  Of course, in the
literal sense the last statement quoted above may be true --
understanding what makes a design work _is_ important no matter which
language will be used to implement the design.  But choosing a good
design, as well as understanding what makes it work, is _not_
independent of language, because not all designs work in all
languages.

http://www.paulgraham.com/avg.html

 

[Nick Keighley]

Yes.  That doesn't make it useless to look at how they work effectively,
even if the conclusion that leads you to is "this is a poor fit for
this language".  


Agreed.  But in a case like this in particular, I think it's quite
reasonable to talk about the kinds of design Jacob is looking at in
terms of C.  There are good reasons to implement these things in C
at one level or another, and good reasons not to jump to C++.

Newness for the sake of newness is not a particularly good engineering
strategy.

replicating wooden bridge design in iron isn't good either

 

[Nick Keighley]

ng:
If you hate C so much why do you post here?

I wouldn't hold your beath though. Most of the modern clever stuff
sits on top of a C implementation layer.

Don't yell/advertise that too loudly, because that will increasingly
become a negative trait and a characteristic of obsolescence. All you did
was state large and incomprehensible codebases and poorly designed
software. (The Apache folks have some useful libraries that would be
better if not for the limitations of the language they are written in).

(Aside: Go Apache! Linux go suck a rock. GPL sucks!)

what platform are you reading this on? I bet there's a fair amount of
C in there

C++ owes much of it's non-lucrativity to C. (Maybe ALL of it).

template syntax...


"Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary."

You're not listening. (Did I mention something about "burying your head
in the sand"?). I don't know you, so I don't know your ability to
comprehend, learn and think. But you dialog in this thread so far to me
seems to be very self-centered at worst, or childish at best.

you seem to think anyone who doesn't agree with you is stupid


ah, back to the dark, paranoid side

As if you knew something about language design.

you do?

 

[Tim Rentsch]

Yes. That doesn't make it useless to look at how they work effectively,
even if the conclusion that leads you to is "this is a poor fit for
this language".


Agreed. But in a case like this in particular, I think it's quite
reasonable to talk about the kinds of design Jacob is looking at in
terms of C. There are good reasons to implement these things in C
at one level or another, and good reasons not to jump to C++.

I was responding to the comment you made in the context of the
posting I responded to. I didn't know anything about the context
of "the kinds of design Jacob is looking at" because that context
had been snipped out of the posting I was responding to. I guess
I expect people to retain any previous context that's relevant
to what they're saying (and I admit I do sometimes err on the
side of caution in that area).

Newness for the sake of newness is not a particularly good engineering
strategy.

I'm sure there is more interesting discussion there but
it's getting somewhat far afield for comp.lang.c so I
will just stop here...