84  8476 
In article <11**********************@v23g2000prn.googlegroups .com>,
<aa*****@gmail.comwrote:
>Hi all,
I found an interesting article here:-
http://en.wikipedia.org/wiki/Critici...mming_language
well what do you guys think of this article....???
Is it constructive criticism that needs to be appreciated always...???
It will start with the standard CLC dogma that wikipedia isn't worth the
electrons it was printed with...
>>>>"aa" == aarklon <aa*****@gmail.comwrites:
aaHi all, I found an interesting article here:-
aa http://en.wikipedia.org/wiki/Critici...mming_language
aawell what do you guys think of this article....??? Is it
aaconstructive criticism that needs to be appreciated
aaalways...???
Just about everything on that list was an intentional design choice --
either because it provided some benefit that would otherwise be lost,
because alternative approaches required too much trading off, or
because it made porting C compilers easier to other platforms.
If you find that enough of the things on that list cause you problems,
then C is not the language you should be using. Fortunately, there
are a broad variety of computer languages to choose from, and nobody
is forcing you to use C.
Charlton
--
Charlton Wilbur cw*****@chromatico.net
On Nov 14, 10:03 pm, aark...@gmail.com wrote:
Hi all,
I found an interesting article here:-http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language
well what do you guys think of this article....???
Is it constructive criticism that needs to be appreciated always...???
i agree with this article. but C is good when it comes low level
programming like system programming. but u have to compromise on some
features.
"Charlton Wilbur" <cw*****@chromatico.netwrote in message
news:87************@mithril.chromatico.net...
>>>>>"aa" == aarklon <aa*****@gmail.comwrites:
aaHi all, I found an interesting article here:-
aa>
http://en.wikipedia.org/wiki/Critici...mming_language
aawell what do you guys think of this article....??? Is it
aaconstructive criticism that needs to be appreciated
aaalways...???
Just about everything on that list was an intentional design choice --
either because it provided some benefit that would otherwise be lost,
because alternative approaches required too much trading off, or
because it made porting C compilers easier to other platforms.
If you find that enough of the things on that list cause you problems,
then C is not the language you should be using. Fortunately, there
are a broad variety of computer languages to choose from, and nobody
is forcing you to use C.
Most points are just personal opinions. There could be a wiki too, "good
aspects of the C language" and it could say
syntax
no GC
many absent features
has pointers
economy of expression
etc.
On Nov 14, 9:03 am, aark...@gmail.com wrote:
Hi all,
I found an interesting article here:-http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language
well what do you guys think of this article....???
This article barely touches upon the poorly design library, esp. the
lack of re-entrancy and no-aliasing issue, or the conflict created
with C++ with the complex numbers introduced in C99. There is no
mention of the fact that this supposedly "portable" language is most
often used in non-portable custom implementations. For example, C is
heavily used for dynamically loaded device drivers -- but the dynamic
loading part is always platform dependent.
Is it constructive criticism that needs to be appreciated always...???
Well clearly as there is no further forward development of the C
language, this is mostly just a lot of hot air. But it can serve as a
useful platform for other language designers to know what *NOT* to do.
--
Paul Hsieh http://bstring.sf.net/ http://www.pobox.com/~qed/
Paul Hsieh wrote:
On Nov 14, 9:03 am, aark...@gmail.com wrote:
>Hi all,
I found an interesting article here:-http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language
well what do you guys think of this article....???
This article barely touches upon the poorly design library, esp. the
lack of re-entrancy and no-aliasing issue, or the conflict created
with C++ with the complex numbers introduced in C99. There is no
mention of the fact that this supposedly "portable" language is most
often used in non-portable custom implementations. For example, C is
heavily used for dynamically loaded device drivers -- but the dynamic
loading part is always platform dependent.
>Is it constructive criticism that needs to be appreciated always...???
Well clearly as there is no further forward development of the C
language, this is mostly just a lot of hot air. But it can serve as a
useful platform for other language designers to know what *NOT* to do.
Not everybody agrees that C is dead and there is no further development.
You are in good company however.
In this group, the official position of the "regulars" is precisely
that:
no new development, back to C 1990, etc.
I have tried (in this group and in comp.std.c) to argue against
that position. I can't say that I have succeeded.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32 aa*****@gmail.com wrote:
>
Hi all,
I found an interesting article here:-
http://en.wikipedia.org/wiki/Critici...mming_language
well what do you guys think of this article....???
Is it constructive criticism that needs to be appreciated always...???
No.
The article is not criticism at all.
The article is about criticism.
The article is an apology(in the classic sense),
concerning some common criticisms of the language.
--
pete
On Nov 14, 1:06 pm, jacob navia <ja...@nospam.comwrote:
Paul Hsieh wrote:
On Nov 14, 9:03 am, aark...@gmail.com wrote:
Hi all,
I found an interesting article here:-http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language
well what do you guys think of this article....???
This article barely touches upon the poorly design library, esp. the
lack of re-entrancy and no-aliasing issue, or the conflict created
with C++ with the complex numbers introduced in C99. There is no
mention of the fact that this supposedly "portable" language is most
often used in non-portable custom implementations. For example, C is
heavily used for dynamically loaded device drivers -- but the dynamic
loading part is always platform dependent.
Is it constructive criticism that needs to be appreciated always...???
Well clearly as there is no further forward development of the C
language, this is mostly just a lot of hot air. But it can serve as
a useful platform for other language designers to know what *NOT* to
do.
Not everybody agrees that C is dead and there is no further
development.
I have followed some number of your posts, and it seems to me that you
might be heading more towards where Walter Bright is going with his "D
language". It seems, like him, you want to make the language better
by virtue of semantic and syntactical changes, with true language
function augmentation.
My angle is different. There is a reasonable language hiding
somewhere in there, but it needs to be fixed. What I want to do is
plug all the stupid holes (start defining things that are currently
undefined), create a fully functional modification of the C library
that is fully re-entrant, have mandated runtime debugging assistance
and vastly expanded functionality for the heap, expose standard
functionality available on most modern CPUs (and which is otherwise
emulatable), redesign the file-IO for generic I/O (so that "FILE as
memory" emulation or sockets can happen fully at the library level)
and implement "one shot continuations" style coroutines into the
language. And fix glaring stupidities like ftell() and fseek() using
long as the file pointer offset.
In other words I just want to make the language to be a whole hell of
a lot better at doing what it already does today, and start making it
less suck at what it sucks at today. Most of what I want can be
solved with a better library alone.
But people are just satisfied with C for some reason. In the years of
posting here I have barely had any support for my point of view. It
kind of disturbs me that nobody cares about any of these issues. So
its not like any of this would ever make it into a proposal which
would be considered by the ANSI C committee. As they say and have
demonstrated themselves, they are concerned with putting a rubber
stamp on standard practice (totally ignoring the chicken and egg
problem inherent with this), and only venturing to do new things if
endorsed by some bizarre lobby that has absolutely no significant user
support (like MS's safe string stuff.)
You are in good company however.
Well I am *resigned* to the fact that nothing is going to happen.
Other people actually don't care and seem pretty happy with the status
quo.
In this group, the official position of the "regulars" is precisely
that:
no new development, back to C 1990, etc.
Well not exactly. They seemed really keen on complex numbers that put
them in direct conflict with the C++ standard. As long as it breaks C+
+ or has other anti-social effects, they seem more that willing to
adopt it.
I have tried (in this group and in comp.std.c) to argue against
that position. I can't say that I have succeeded.
Methinks there isn't a strong enough lobby for rationality in the
continued development of the C standard. And getting them to
acknowledge problems? I mean they are going to finally get rid of
gets() in the next standard. So they can no longer support any of
their prior claims that there was some good reason for it to be
there. They just have to admit, that they just left it in there for
18 years. Yay them for getting rid of gets(), but if that's how long
it takes, making the C library re-entrant is just never going to
happen.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
jacob navia wrote:
You are in good company however.
In this group, the official position of the "regulars" is precisely
that:
no new development, back to C 1990, etc.
I have tried (in this group and in comp.std.c) to argue against
that position. I can't say that I have succeeded.
Since there is no one taking the position that Jacob asserts to be 'the
official position of the "regulars"', you have a clue about how much you
can trust anything he writes. No one pays attention to his arguments in
comp.lang.c because they are inevitably about his private language,
implemented on his compiler for sale for commercial use, or completely
wrongheaded. It is never because anyone is wedded to "no new
development, back to C 1990, etc." That he identifies any disagreement
with his flights of fancy as that tells you much more about him than
about this group.
Without C and Assembly Language, how are we to prototype anything new?
[Please cite the context of your replies.]
"Chris Thomasson" <cris...@comcast.netwrote:
Without C and Assembly Language, how are we to
prototype anything new?
Same way we prototype new cheesecakes without tomato sauce.
Neither C nor (any) Assembly Language are particularly
favoured for prototyping new applications.
--
Peter
"Peter Nilsson" <ai***@acay.com.auwrote in message
news:12**********************************@a39g2000 pre.googlegroups.com...
[Please cite the context of your replies.]
"Chris Thomasson" <cris...@comcast.netwrote:
>Without C and Assembly Language, how are we to
prototype anything new?
Same way we prototype new cheesecakes without tomato sauce.
Neither C nor (any) Assembly Language are particularly
favoured for prototyping new applications.
How does do you prototype a new Garbage Collector Algorithms without
low-level languages ;like Assembly, C/C++?
In article <CO******************************@comcast.com>, Chris
Thomasson <cr*****@comcast.netwrote on Thursday 15 Nov 2007 7:59 am:
Without C and Assembly Language, how are we to prototype anything new?
Actually C and assembler are probably more often used for final
production than prototyping. In recent times prototyping
and "proof-of-concept" are most often done in an interpreted language.
The exponential increase in computing capacity has resulted in "heavier"
languages becoming acceptable for day-to-day use, thus eating
significantly into the niche that C monopolised back in the 70s and
80s.
However C is still a favoured language for systems programming. However
since systems and embedded work are largely "invisible" to the majority
of computer users and newbie programmers, a feeling is created that C
has "died" or is "dying".
The tenacious persistence of COBOL and FORTRAN should tell us that C is
likely to be used actively for a long time and supported for an even
longer time.
In article <Cv******************************@comcast.com>, Chris
Thomasson <cr*****@comcast.netwrote on Thursday 15 Nov 2007 9:10 am:
"Peter Nilsson" <ai***@acay.com.auwrote in message
news:12**********************************@a39g2000 pre.googlegroups.com...
>[Please cite the context of your replies.]
"Chris Thomasson" <cris...@comcast.netwrote:
>>Without C and Assembly Language, how are we to
prototype anything new?
Same way we prototype new cheesecakes without tomato sauce.
Neither C nor (any) Assembly Language are particularly
favoured for prototyping new applications.
How does do you prototype a new Garbage Collector Algorithms without
low-level languages ;like Assembly, C/C++?
No. This can be done any language like Java or Python, though presumably
the final implementation might be in C.
"santosh" <sa*********@gmail.comwrote in message
news:fh**********@registered.motzarella.org...
In article <Cv******************************@comcast.com>, Chris
Thomasson <cr*****@comcast.netwrote on Thursday 15 Nov 2007 9:10 am:
>"Peter Nilsson" <ai***@acay.com.auwrote in message
news:12**********************************@a39g2000 pre.googlegroups.com...
>>[Please cite the context of your replies.]
"Chris Thomasson" <cris...@comcast.netwrote:
Without C and Assembly Language, how are we to
prototype anything new?
Same way we prototype new cheesecakes without tomato sauce.
Neither C nor (any) Assembly Language are particularly
favoured for prototyping new applications.
How does do you prototype a new Garbage Collector Algorithms without
low-level languages ;like Assembly, C/C++?
No. This can be done any language like Java or Python, though presumably
the final implementation might be in C.
How do you create a GC in a language that requires a GC?
On Nov 14, 11:03 am, aark...@gmail.com wrote:
Hi all,
I found an interesting article here:-http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language
well what do you guys think of this article....???
Is it constructive criticism that needs to be appreciated always...???
The criticisms presented in that article are, for the most part,
valid. The only ones I'll quibble with are the lack of object-
oriented programming support; that's to be expected in a language that
wasn't designed to be object-oriented.
As others have pointed out, many of the weaknesses pointed out in the
article were results of deliberate design decisions. At the time, it
was more important that the language be small, fast, and easily ported
to other platforms rather than be fully featured.
All that means is that C is better suited to some tasks than others.
For example, text processing in C is a royal pain in the ass; C
doesn't define a native string type, for one thing, and the string
processing routines are rudimentary at best. jf****@austin.rr.com wrote:
....
article were results of deliberate design decisions. At the time, it
was more important that the language be small, fast, and easily ported
to other platforms rather than be fully featured.
Those characteristics continue to be important in many contexts, and it
is precisely in those contexts that C continues to flourish.
jfb...@austin.rr.com wrote:
All that means is that C is better suited to some tasks than others.
For example, text processing in C is a royal pain in the ass; C
doesn't define a native string type, for one thing, and the string
processing routines are rudimentary at best.
not a good example
the fact that the standard does not contain certain functionality does
not mean one can not implement them simply and efficiently
for high level tasks obviously you'll need libraries, where you can
hide the complexity behind a well designed api (and you can do it in c
pretty well)
actually many string processing applications and libraries are written
in c
(eg applications: sed, awk, grep, perl; libraries: bstring, tre, ..)
>>>>"PH" == Paul Hsieh <we******@gmail.comwrites:
PHIn other words I just want to make the language to be a whole
PHhell of a lot better at doing what it already does today, and
PHstart making it less suck at what it sucks at today. Most of
PHwhat I want can be solved with a better library alone.
PHBut people are just satisfied with C for some reason. In the
PHyears of posting here I have barely had any support for my
PHpoint of view. It kind of disturbs me that nobody cares about
PHany of these issues. So its not like any of this would ever
PHmake it into a proposal which would be considered by the ANSI
PHC committee.
The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.
I understand that you want a better language; why does it matter to
you that this better language is called C? What is it about the name
C and the ANSI imprimatur that is so valuable, that means you can't
create your own new language, with all the problems fixed, and call it
something else? There's precedent for this, you know: C++ and
Objective-C trod the same ground decades ago. Java started out as a
redesigned C++; Ruby started out as a redesigned Perl.
The reactions to your and Jacob's improvements to C has a very simple
explanation: they require tradeoffs that just don't make sense in a
lot of contexts. C is good enough in a lot of ways; more importantly,
the places where it's not good and the edge cases where it gets
pathological are well known. If you make major sweeping changes to
the language itself, suddenly that's not the case, and the only thing
New C has in common with Old C is the name.
In other words: people do care about the issues you care about, but
we're just addressing them by using other languages when the other
language is a better choice, not by altering C to suit.
So why can't you and Jacob design your new perfect languages and call
them something other than C?
Charlton
--
Charlton Wilbur cw*****@chromatico.net
>>>>"CT" == Chris Thomasson <cr*****@comcast.netwrites:
CTHow do you create a GC in a language that requires a GC?
The same way you produce a compiler for a new language that requires a
compiler: you bootstrap it from lower levels.
Charlton
--
Charlton Wilbur cw*****@chromatico.net
Charlton Wilbur wrote:
>>>>>"PH" == Paul Hsieh <we******@gmail.comwrites:
PHIn other words I just want to make the language to be a whole
PHhell of a lot better at doing what it already does today, and
PHstart making it less suck at what it sucks at today. Most of
PHwhat I want can be solved with a better library alone.
PHBut people are just satisfied with C for some reason. In the
PHyears of posting here I have barely had any support for my
PHpoint of view. It kind of disturbs me that nobody cares about
PHany of these issues. So its not like any of this would ever
PHmake it into a proposal which would be considered by the ANSI
PHC committee.
The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.
I understand that you want a better language; why does it matter to
you that this better language is called C?
I understand that you want a bad language. Why you want to call it C?
You say that any improvements to C should be in the official improvement
language for C: C++ isn't it?
All the time that anyone proposes an improvement the same lame
argument from the same people:
Why you want to improve something bad by design?
Just leave it like that. gets() is OK, needs no improvement.
What is it about the name
C and the ANSI imprimatur that is so valuable, that means you can't
create your own new language, with all the problems fixed, and call it
something else?
Why it is so that if you want a bad language you create your own and
allow other people to improve C?
There's precedent for this, you know: C++ and
Objective-C trod the same ground decades ago. Java started out as a
redesigned C++; Ruby started out as a redesigned Perl.
You can innovate. Call your language C--.
The reactions to your and Jacob's improvements to C has a very simple
explanation: they require tradeoffs that just don't make sense in a
lot of contexts.
This has never been said before. I do not see what tradeoffs
you are talking about. The introduction of improved libraries
like a malloc where you can query the size of an object as proposed
by Paul would make sense and take no overhead.
C is good enough
for YOU
in a lot of ways; more importantly,
the places where it's not good and the edge cases where it gets
pathological are well known.
Yes. And please do not improve them. Just make your new
language C-- and leave us in peace ok?
If you make major sweeping changes to
the language itself, suddenly that's not the case, and the only thing
New C has in common with Old C is the name.
Nobody is talking about your "sweeping changes", just you.
In other words: people do care about the issues you care about, but
we're just addressing them by using other languages when the other
language is a better choice, not by altering C to suit.
C must retain all its badly designed choices because you say so.
And people that propose improvements (that you do not even care
to say that are wrong!) are juust making a new language of course.
There is nothing worst than a new language that simplifies an old
one and makes it better. Yes.
So why can't you and Jacob design your new perfect languages and call
them something other than C?
I do not speak for Mr Hsieh but why should I?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
>>>>"JN" == jacob navia <ja***@nospam.comwrites:
JNI understand that you want a bad language. Why you want to
JNcall it C? You say that any improvements to C should be in
JNthe official improvement language for C: C++ isn't it?
Because the language already exists, and has been called C for the
past three decades.
JNAll the time that anyone proposes an improvement the same lame
JNargument from the same people:
JNWhy you want to improve something bad by design?
JNJust leave it like that. gets() is OK, needs no improvement.
No: the question is, what will this improvement cost us? We know why
you want to improve it, because you harangue us at length; we may even
agree with your rationale. But there are millions, possibly billions
of lines of C code out there, and hundreds of C compilers, and if you
make a change that isn't backwards compatible, *someone* has to go and
deal with those millions of lines of code and hundreds of C compilers.
>What is it about the name C and the ANSI imprimatur that is so
valuable, that means you can't create your own new language,
with all the problems fixed, and call it something else?
JNWhy it is so that if you want a bad language you create your
JNown and allow other people to improve C?
The language C already exists, and is reasonably well-defined.
JNThis has never been said before. I do not see what tradeoffs
JNyou are talking about. The introduction of improved libraries
JNlike a malloc where you can query the size of an object as
JNproposed by Paul would make sense and take no overhead.
In a new compiler, sure. In all new code, sure. What happens when
someone writes code with this new feature and tries to run it on an
old compiler?
>In other words: people do care about the issues you care about,
but we're just addressing them by using other languages when
the other language is a better choice, not by altering C to
suit.
JNC must retain all its badly designed choices because you say
JNso. And people that propose improvements (that you do not
JNeven care to say that are wrong!) are juust making a new
JNlanguage of course. There is nothing worst than a new
JNlanguage that simplifies an old one and makes it better. Yes.
No: C must retain all its badly designed choices because there are
millions of lines of code and hundreds of compilers that implement
them. I *don't* think your improvements are wrong, in the large; I
think that adding them to C is likely to break a lot of things, and
even if it doesn't, it will require updating a lot of compilers; thus
unless the cost of the change is less than the benefit of the change
is worth, the change should not be made.
If you're playing with even 100,000 lines of code and one compiler,
the tradeoffs are different.
>So why can't you and Jacob design your new perfect languages
and call them something other than C?
JNI do not speak for Mr Hsieh but why should I?
Because you'll get a lot farther that way. Because you might get your
new language into widespread use, instead of coming across as a crank.
You still haven't answered the basic question: why is the C name and
the ANSI imprimatur so important to you?
Charlton
--
Charlton Wilbur cw*****@chromatico.net
Charlton Wilbur wrote:
>>>>>"JN" == jacob navia <ja***@nospam.comwrites:
JNI understand that you want a bad language. Why you want to
JNcall it C? You say that any improvements to C should be in
JNthe official improvement language for C: C++ isn't it?
Because the language already exists, and has been called C for the
past three decades.
JNAll the time that anyone proposes an improvement the same lame
JNargument from the same people:
JNWhy you want to improve something bad by design?
JNJust leave it like that. gets() is OK, needs no improvement.
No: the question is, what will this improvement cost us? We know why
you want to improve it, because you harangue us at length; we may even
agree with your rationale. But there are millions, possibly billions
of lines of C code out there, and hundreds of C compilers, and if you
make a change that isn't backwards compatible, *someone* has to go and
deal with those millions of lines of code and hundreds of C compilers.
You still haven't proved that any change that I have proposed makes
some code go wrong. As far as I know the syntax
int operator[](Array tabv,int idx);
is not used in single line in those billions of C code lines.
Since we can do
#define operator __operator
we only use an already reserved word, and a new syntax. This
can't do any harm to any existing code.
>
JNThis has never been said before. I do not see what tradeoffs
JNyou are talking about. The introduction of improved libraries
JNlike a malloc where you can query the size of an object as
JNproposed by Paul would make sense and take no overhead.
In a new compiler, sure. In all new code, sure. What happens when
someone writes code with this new feature and tries to run it on an
old compiler?
And what happens if I try to use a compiler that still doesn't accept
prototypes?
It doesn't work. Great! Let's get rid of prototypes then!
Why you would try to use new code with an old compiler?
This is a data processing field, not an association for the
religious worship of old code!
>
>In other words: people do care about the issues you care about,
>but we're just addressing them by using other languages when
>the other language is a better choice, not by altering C to
>suit.
JNC must retain all its badly designed choices because you say
JNso. And people that propose improvements (that you do not
JNeven care to say that are wrong!) are juust making a new
JNlanguage of course. There is nothing worst than a new
JNlanguage that simplifies an old one and makes it better. Yes.
No: C must retain all its badly designed choices because there are
millions of lines of code and hundreds of compilers that implement
them. I *don't* think your improvements are wrong, in the large; I
think that adding them to C is likely to break a lot of things, and
even if it doesn't, it will require updating a lot of compilers;
OK. You agree that it will NOT break anything. Your arguments now
reduce to the price of retooling the compilers... I mean that
is a significant shift in your argumentation.
thus
unless the cost of the change is less than the benefit of the change
is worth, the change should not be made.
The cost of maintaining C code is staggering because of those
problems precisely. It require from the programmer a LOT of time
and attention to do all those allocations and freeings without a single
error.
The improvements to C would make it easier to use, the user base would
grow. Yes, there are zillions of old code but the people doing C
are less and less and everybody is associating the C language
with overflow bugs...
C applications could be rewritten using the new features slowly, and
they would improve.
Or, (and that is what you and many other people want) no improvements
would be done to either the language or the applications until they
disappear. C would disappear faster than Cobol and Fortran, since
even Cobol has improved, and Fortran accepts now operator overloading
and allows a modern style of programming.
But that would be in an horizon of 10 years from now, so nobody cares.
Let's freeze C until it dies away.
If you're playing with even 100,000 lines of code and one compiler,
the tradeoffs are different.
>So why can't you and Jacob design your new perfect languages
>and call them something other than C?
JNI do not speak for Mr Hsieh but why should I?
Because you'll get a lot farther that way. Because you might get your
new language into widespread use, instead of coming across as a crank.
I am only "a crank" in this group. My compiler system is used by many
people, I have arrived at 500 000 downloads of this system. Users
from Chine, U.S., many universities, single people, etc. And they like
it because the language is simple, modern, and the whole download is
just 5MB. It is fast, and produces small executables.
Yes, there are still people that appreciate that, and like to use
simple things.
C has a future, and I am convinced of that and I will work for that
goal. ANd if I am considered "a crank" by people in this group
I do not care at all about their opinions!
You still haven't answered the basic question: why is the C name and
the ANSI imprimatur so important to you?
Charlton
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Nov 15, 9:24 am, Charlton Wilbur <cwil...@chromatico.netwrote:
>>>"PH" == Paul Hsieh <websn...@gmail.comwrites:
PHIn other words I just want to make the language to be a whole
PHhell of a lot better at doing what it already does today, and
PHstart making it less suck at what it sucks at today. Most of
PHwhat I want can be solved with a better library alone.
PHBut people are just satisfied with C for some reason. In the
PHyears of posting here I have barely had any support for my
PHpoint of view. It kind of disturbs me that nobody cares about
PHany of these issues. So its not like any of this would ever
PHmake it into a proposal which would be considered by the ANSI
PHC committee.
The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.
Ironically, the argument you make in what follows applies equally well
to C99 itself. In other words your argument is essentially moving
*backwards* in time, referring to things for which we already have
precedent. Compare this to my position in which I have observed the
ANSI C committee approve radical changes to the language (i.e., C99)
so I know that are *willing* to change the language and I am well
aware of the compiler vendor's reluctance to make the changes.
The problem is you take all that as a conclusion, instead of asking
the simple question of *WHY* those events happen. The compiler
vendors didn't bother because the programming community doesn't care
for any of C99's features. If programmers *demanded* certain
features, then compiler writes would implement them whether they
wanted to or not. (Not surprisingly, you will find the ANSI C commit
populated mostly by representatives of compiler writers -- thus
indicating a preference for the "not" in the previous sentence.)
Now, it turns out from the number of heap debugger utilities being
sold out there, that its plainly obvious that there is programmer
demand for heap debugging assistance. (On the other hand, I have yet
to encounter even a single usage of the complex number extensions in
C99 anywhere.) One can see from the efforts of Motorola (AltiVec),
Intel (MMX/SSE) and AMD (3DNow!) that SIMD math extensions are an
important concern for some applications. And of course "mulhi" or
double-output multiplies have been implemented in most processors for
ages. And how long has multi-threading been a standard paradigm in C
programming?
Its so obvious and easy to find features where people are interested,
and language standardization is a useful value add. And the point is
that with enough of these features the changes would be *compelling*
enough, that people would *want* to move to it, which would *force*
compiler vendors to implement them.
These features would also make C a truly better language, and call to
real question people who have moved away from C (and C++) in favor of
other languages like Java or C# or Python or Ruby.
I understand that you want a better language; why does it matter to
you that this better language is called C?
Well I wonder why the people who designed STL for C++ didn't decide to
go off and make their own language. Same for the boost people.
Look, the ANSI committee has already demonstrated that they are
willing to break backward compatibility and put really esoteric
features into the language. People will pay attention of the
committee or some compiler vendors implement language features. Some
people *have* paid attention to various efforts of mine (the pstdint.h
file, and Bstrlib, both of which are used in real shipping commercial
and open source products) but obviously I alone don't wield the same
kind of influence as the standards committee.
[...] What is it about the name
C and the ANSI imprimatur that is so valuable, that means you can't
create your own new language, with all the problems fixed, and call it
something else? There's precedent for this, you know: C++ and
Objective-C trod the same ground decades ago. Java started out as a
redesigned C++; Ruby started out as a redesigned Perl.
Well maybe I am not a language designer? Maybe I don't have a few
years to dedicate to create my own IDE and debugger? It takes more
than just a desire for correctness to create a successful language.
The reactions to your and Jacob's improvements to C has a very simple
explanation: they require tradeoffs that just don't make sense in a
lot of contexts.
Mr. Navia and I have different suggestions, and I will let him speak
for himself.
My proposals tend to be limited to the library. Perhaps you can
enlighten me with examples where my proposals would lead to actually
giving something up (to be a trade off you have to gain something in
balance with giving something up)? When people try to challenge me on
this, the best I get is the typical circular reasoning: "that's not in
the standard, therefore its not portable" or some crap like that, when
clearly I am trying to suggest something to be standardized.
[...] C is good enough in a lot of ways; more importantly,
the places where it's not good and the edge cases where it gets
pathological are well known.
You can't make a sentence like that and not have sympathy for the
position that the C standard needs some changes.
[...] If you make major sweeping changes to
the language itself, suddenly that's not the case, and the only thing
New C has in common with Old C is the name.
You mean like C99? My proposed changes would have *LESS*
compatibility impact than C99 (except for the vast increase in
compiler warnings from deprecation notices), but have a generally
profound functionality increase impact.
In other words: people do care about the issues you care about,
And they spend time and money dealing with them.
[...] but
we're just addressing them by using other languages when the other
language is a better choice, not by altering C to suit.
Which is the better language choice for mulhi? Which language is
better for heap debugging do you think?
So why can't you and Jacob design your new perfect languages and call
them something other than C?
I don't speak for Jacob, but as I understand it, he has lcc-win32 or
something very similarly named. So he's already done the leg work,
because he's found the time, energy, and believes that strongly in it.
My proposals generally speak of things I have already done, but I
obviously didn't write my own language to do so.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
"Charlton Wilbur" <cw*****@chromatico.netwrote in message
news:87************@mithril.chromatico.net...
>>>>>"CT" == Chris Thomasson <cr*****@comcast.netwrites:
CTHow do you create a GC in a language that requires a GC?
The same way you produce a compiler for a new language that requires a
compiler: you bootstrap it from lower levels.
Fair enough. Humm... Can you use Java to create a brand new GC
implementation for itself, thus totally replacing the one in the VM?
jacob navia wrote, On 15/11/07 17:56:
Charlton Wilbur wrote:
>>>>>>"PH" == Paul Hsieh <we******@gmail.comwrites:
PHIn other words I just want to make the language to be a whole
PHhell of a lot better at doing what it already does today, and
PHstart making it less suck at what it sucks at today. Most of
PHwhat I want can be solved with a better library alone.
PHBut people are just satisfied with C for some reason. In the
PHyears of posting here I have barely had any support for my
PHpoint of view. It kind of disturbs me that nobody cares about
PHany of these issues. So its not like any of this would ever
PHmake it into a proposal which would be considered by the ANSI
PHC committee.
The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.
I understand that you want a better language; why does it matter to
you that this better language is called C?
I understand that you want a bad language. Why you want to call it C?
C is not a bad language. It has problems just as every language does.
You say that any improvements to C should be in the official improvement
language for C: C++ isn't it?
All the time that anyone proposes an improvement the same lame
argument from the same people:
Why you want to improve something bad by design?
Your characterisation is incorrect. It is also typical of your
misrepresentation of other peoples opinion when they disagree with you.
Just leave it like that. gets() is OK, needs no improvement.
Many of the people you are complaining about have been arguing for
removing gets from the language and expressed their pleasure when it was
at last declared that it would be deprecated. So you are clearly
misrepresenting the opinion of a lot of the people you are complaining
about.
<snip>
>The reactions to your and Jacob's improvements to C has a very simple
explanation: they require tradeoffs that just don't make sense in a
lot of contexts.
This has never been said before.
Well, it has been said in in this message http://groups.google.com/group/comp....a?dmode=source
This thread talks about the tradeoffs as well http://groups.google.com/group/comp....7639fa174f6db5
So does this one http://groups.google.com/group/comp....6a74953aa83f84
I will put this down to you forgetting that people have discussed the
tradeoffs in language design with you.
I do not see what tradeoffs
you are talking about. The introduction of improved libraries
like a malloc where you can query the size of an object as proposed
by Paul would make sense and take no overhead.
Apart from the systems where the information is not easily available
which people have mentioned before.
>C is good enough
for YOU
For a LOT of people otherwise it would not be used as much as it is.
<snip>
>If you make major sweeping changes to
the language itself, suddenly that's not the case, and the only thing
New C has in common with Old C is the name.
Nobody is talking about your "sweeping changes", just you.
<snip>
A lot of people seem to think that a lot of things you suggest, such as
operator overloading and garbage collection *are* sweeping changes.
--
Flash Gordon
>>>>"PH" == Paul Hsieh <we******@gmail.comwrites:
PHThe problem is you take all that as a conclusion, instead of
PHasking the simple question of *WHY* those events happen. The
PHcompiler vendors didn't bother because the programming
PHcommunity doesn't care for any of C99's features. If
PHprogrammers *demanded* certain features, then compiler writes
PHwould implement them whether they wanted to or not.
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
>I understand that you want a better language; why does it
matter to you that this better language is called C?
PHWell I wonder why the people who designed STL for C++ didn't
PHdecide to go off and make their own language. Same for the
PHboost people.
Those aren't different languages, though: those are libraries. They
don't require semantic changes in the language, and they don't require
the same stringency in the standardization process.
Things like garbage collecting and operator overloading *do* require
semantic changes in the language.
PHMy proposals tend to be limited to the library. Perhaps you
PHcan enlighten me with examples where my proposals would lead
PHto actually giving something up (to be a trade off you have to
PHgain something in balance with giving something up)? When
PHpeople try to challenge me on this, the best I get is the
PHtypical circular reasoning: "that's not in the standard,
PHtherefore its not portable" or some crap like that, when
PHclearly I am trying to suggest something to be standardized.
So why not just create your new improved library? POSIX is not C99;
neither is BSD sockets, or X11. Why does it need to have the ANSI
imprimatur for you to be happy?
>[...] C is good enough in a lot of ways; more importantly, the
places where it's not good and the edge cases where it gets
pathological are well known.
PHYou can't make a sentence like that and not have sympathy for
PHthe position that the C standard needs some changes.
I have sympathy for the position, but I see the costs, and I don't
understand why you consider the ANSI C imprimatur so important.
Charlton
--
Charlton Wilbur cw*****@chromatico.net
Charlton Wilbur wrote:
>>>>>"PH" == Paul Hsieh <we******@gmail.comwrites:
PHThe problem is you take all that as a conclusion, instead of
PHasking the simple question of *WHY* those events happen. The
PHcompiler vendors didn't bother because the programming
PHcommunity doesn't care for any of C99's features. If
PHprogrammers *demanded* certain features, then compiler writes
PHwould implement them whether they wanted to or not.
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
And I did not wait for people in ANSI to build lcc-win.
So What?
>
Things like garbage collecting and operator overloading *do* require
semantic changes in the language.
Garbage collection is just a library. No changes at all to the
language are required!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
"Paul Hsieh" <we******@gmail.comwrote in message
My angle is different. There is a reasonable language hiding
somewhere in there, but it needs to be fixed. What I want to do is
plug all the stupid holes (start defining things that are currently
undefined), create a fully functional modification of the C library
that is fully re-entrant, have mandated runtime debugging assistance
and vastly expanded functionality for the heap, expose standard
functionality available on most modern CPUs (and which is otherwise
emulatable), redesign the file-IO for generic I/O (so that "FILE as
memory" emulation or sockets can happen fully at the library level)
and implement "one shot continuations" style coroutines into the
language. And fix glaring stupidities like ftell() and fseek() using
long as the file pointer offset.
Generally object-orientation is more trouble than its worth. But one
exception is streams. Serialisation is so fundamental that it should be
built in. You might want to look at my serialisation pages.
>
Methinks there isn't a strong enough lobby for rationality in the
continued development of the C standard. And getting them to
acknowledge problems? I mean they are going to finally get rid of
gets() in the next standard.
gets() is something and nothing. Yes it is an easy way to make a broken
program, but it is only one function, not a methodology.
The other problem is the dependency feature. Time after time code which
could be reusable actually pulls in three of four headers, which pull in an
entire library, often for something totally trivial, such as a Point3d type.
Another one, which you will realise if you use Lisp, is that in C there are
too many ways to express the same thing - arrays of arrays of structures
with arrays, or lists of list of lists. Lisp handles it fine by simply
having one "list" structure. In C you are constantly checking - is it a
pointer or a nested array, where is the size member ?
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
Keith Thompson wrote:
jacob navia wrote:
>Charlton Wilbur wrote:
[...]
>>But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
And I did not wait for people in ANSI to build lcc-win.
So What?
So why do you insist on discussing lcc-win's non-ISO extensions here in
comp.lang.c?
Because I have the right to do that according to the charter
of this group published when this group was created.
Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.
>>Things like garbage collecting and operator overloading *do* require
semantic changes in the language.
Garbage collection is just a library. No changes at all to the
language are required!
Garbage collection breaks legal C programs. It can even break strictly
conforming C programs. Any program that stores a pointer value in a
place or format where the garbage collector can't recognize it as a
pointer will potentially be broken by GC.
int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached:-)\n");
fclose(f);
}
The function disk_format() breaks programs that were legal before...
How bad!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Kenny McCormack wrote:
[...]
Think of this ng as like a church. Church people have very rigid
(generally 13th century[*]) views on things. They ain't gonna change.
[*] If you're lucky. 13th century for Christians. 8th century for,
e.g., Muslims.
Good thing I'm Jewish -- we have 58th century ideas! :-)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Paul Hsieh wrote:
I haven't followed JN's GC proposal too closely, but if he had a way
of turning it off (which I would highly recommend) then I don't see
the issue.
If you call malloc/free and do not call GC_malloc the GC is
completely turned off!
It is a library!
If you do not use it you do not use it and it will not
be linked with your program!
The GC in lcc-win is an OPTIONAL feature.
But even THAT is too much for the regulars
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Keith Thompson wrote:
>jacob navia wrote:
>So why do you insist on discussing lcc-win's non-ISO extensions here
in comp.lang.c?
Because I have the right to do that according to the charter
of this group published when this group was created.
Jacob has been around long enough to know that this newsgroup predates
charters. His claim to have a right based on a non-existent charter
should tell you to ignore anything he writes. The reasons that
comp.lang.c has survived as one of the oldest and most successful
newsgroups include the fact that it preserves the concept of topicality.
That Jacob intends, and has proven repeatedly, that he intends to
destroy the concept of topicality in comp.lang.c means that his intent
is to destroy comp.lang.c. And he wonders why people have a problem
with him.
>
Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.
And, that, my friends, is Jacob as his best. It is clear that we do
discuss things at a "technical level", it is clear that the principal
poster of "polemic" is none other than Jacob. Those who are unclear
about his destructive role should heed this.
In article <fh**********@aioe.org ja***@nospam.org writes:
....
int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached:-)\n");
fclose(f);
}
The function disk_format() breaks programs that were legal before...
How bad!
I do not think the program will break. The worst that should happen is
that fprints returns a negative value and that fclose returns EOF.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In article <47***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:
>Kenny McCormack wrote:
[...]
>Think of this ng as like a church. Church people have very rigid
(generally 13th century[*]) views on things. They ain't gonna change.
[*] If you're lucky. 13th century for Christians. 8th century for,
e.g., Muslims.
Good thing I'm Jewish -- we have 58th century ideas! :-)
Good point!
jacob navia wrote:
Keith Thompson wrote:
>jacob navia wrote:
>>Charlton Wilbur wrote:
[...]
>>>But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
And I did not wait for people in ANSI to build lcc-win.
So What?
So why do you insist on discussing lcc-win's non-ISO extensions here
in comp.lang.c?
Because I have the right to do that according to the charter
of this group published when this group was created.
How many times must we explain to you that this newsgroup has no charter?
Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.
Not at all. I discuss technical issues here all the time.
Specifically, I discuss technical issues related to standard C, which is
the topic of this newsgroup. (Please don't try to claim that comp.std.c
is for discussing standard C and comp.lang.c is for non-standard C;
we've been over that.)
>>>Things like garbage collecting and operator overloading *do* require
semantic changes in the language.
Garbage collection is just a library. No changes at all to the
language are required!
Garbage collection breaks legal C programs. It can even break
strictly conforming C programs. Any program that stores a pointer
value in a place or format where the garbage collector can't recognize
it as a pointer will potentially be broken by GC.
int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached:-)\n");
fclose(f);
}
The function disk_format() breaks programs that were legal before...
How bad!
Be serious. Obviously disk_format(), or any non-standard function, is
going to do whatever it does.
You complain about an alleged lack of technical discussion. When you
claim that GC requires only additions to the library, not to the core
language, I raise a technical issue. You ridicule my point rather than
addressing it.
If I'm mistaken, refute what I said.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Dik T. Winter wrote:
In article <fh**********@aioe.orgja***@nospam.org writes:
...
int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached:-)\n");
fclose(f);
}
>
The function disk_format() breaks programs that were legal before...
How bad!
I do not think the program will break. The worst that should happen is
that fprints returns a negative value and that fclose returns EOF.
Depends on the implementation. Formatting a disk may or may not
interfere with a running program; the standard doesn't say.
It's at least conceivable that the object code for fprintf() is loaded
on demand when it's first called. It's also possible, and I suspect
more likely, that it will behave as you say.
--
Keith Thompson (The_Other_Keith) ks***@mib.org
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Paul Hsieh wrote:
[...]
So take for example some of the things I am proposing: 1) Heap
extensions and heap debugging APIs. These things obviously exist in
various products and compiler extensions -- no two of which are
compatible, of course. 2) "mulhi" and "SIMD" instructions -- many
modern compiler come with assembly language extensions, and that's how
they are implemented; one by one, every one of them incompatible with
the next (actually Intel is somewhat compatible with MSVC, but that's
a weird special case.) 3) Some kind of fseek/ftell on intmax_t
instead of long: every modern compiler I know implements some sort 64
bit fseek and ftell (again, each incompatible with the other), because
"64 bits ought to be enough for everyone".
People clearly want and need those things. The way it happens today
is kind of pathetic. Why do I have to learn a different way to deal
with those things as a Solaris, or a VxWorks or a QNX or even a Linux
programmer?
If you want to advocate changes to the C language, I encourage you to do
so in comp.std.c. The vast majority of us here in comp.lang.c are
users, not implementers or committee members; even if we like your
ideas, we're in no position to do anything about them.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
jacob navia wrote:
>Keith Thompson wrote:
>>jacob navia wrote:
Charlton Wilbur wrote:
[...]
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
And I did not wait for people in ANSI to build lcc-win.
So What?
So why do you insist on discussing lcc-win's non-ISO extensions here
in comp.lang.c?
Because I have the right to do that according to the charter
of this group published when this group was created.
How many times must we explain to you that this newsgroup has no charter?
>Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.
Not at all. I discuss technical issues here all the time. Specifically,
I discuss technical issues related to standard C, which is the topic of
this newsgroup. (Please don't try to claim that comp.std.c is for
discussing standard C and comp.lang.c is for non-standard C; we've been
over that.)
>>>>Things like garbage collecting and operator overloading *do* require
semantic changes in the language.
Garbage collection is just a library. No changes at all to the
language are required!
Garbage collection breaks legal C programs. It can even break
strictly conforming C programs. Any program that stores a pointer
value in a place or format where the garbage collector can't
recognize it as a pointer will potentially be broken by GC.
int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached:-)\n");
fclose(f);
}
The function disk_format() breaks programs that were legal before...
How bad!
Be serious. Obviously disk_format(), or any non-standard function, is
going to do whatever it does.
You complain about an alleged lack of technical discussion. When you
claim that GC requires only additions to the library, not to the core
language, I raise a technical issue. You ridicule my point rather than
addressing it.
If I'm mistaken, refute what I said.
If you allocate memory with GC_malloc, then store the pointer in a disk
file or hide it from the GC it will invoke UB. If you instead of using
GC_malloc you use malloc (that is still available and free for you to
use) NOTHING will happen since the GC only frees memory allocated with
GC_malloc. Programs that used malloc will CONTINUE to run as before,
the GC is backwards compatible with existing code.
I have repeated this OVER and OVER and here it goes yet one more time.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Op Thu, 15 Nov 2007 20:23:21 +0100 schreef Chris Thomasson
<cr*****@comcast.net>:
"Charlton Wilbur" <cw*****@chromatico.netwrote in message
news:87************@mithril.chromatico.net...
>>>>>>"CT" == Chris Thomasson <cr*****@comcast.netwrites:
CTHow do you create a GC in a language that requires a GC?
The same way you produce a compiler for a new language that requires a
compiler: you bootstrap it from lower levels.
Fair enough. Humm... Can you use Java to create a brand new GC
implementation for itself, thus totally replacing the one in the VM?
It wouldn't be very handy for a VM that doesn't run mostly on Java
already, because you'd need all the necessary information needed for GC,
accessible in the Java layer. Note that there is actually a JVM that does
run mostly on Java, though I don't remember its name or how GC is done.
--
Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
jacob navia wrote:
Keith Thompson wrote:
[...]
>You complain about an alleged lack of technical discussion. When you
claim that GC requires only additions to the library, not to the core
language, I raise a technical issue. You ridicule my point rather
than addressing it.
If I'm mistaken, refute what I said.
If you allocate memory with GC_malloc, then store the pointer in a disk
file or hide it from the GC it will invoke UB. If you instead of using
GC_malloc you use malloc (that is still available and free for you to
use) NOTHING will happen since the GC only frees memory allocated with
GC_malloc. Programs that used malloc will CONTINUE to run as before,
the GC is backwards compatible with existing code.
I have repeated this OVER and OVER and here it goes yet one more time.
There, that wasn't so difficult, was it?
I know I've raised this point before. I don't recall you ever addressing it,
other than just asserting that GC requires no changes to the core language. If
you did, I've forgotten. (Perhaps you could provide a pointer to a earlier
response in which you actually addressed the point?)
So it appears that I was mistaken. The point I was missing (or had forgotten,
whatever) is that GC only affects memory allocated by GC_malloc(). Even if GC
is enabled, a block of memory allocated by malloc() will never be garbage-collected.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" ym******@gmail.com said:
On Nov 16, 9:56 am, jacob navia <ja...@nospam.orgwrote:
<snip>
>I fail to understand how someone that knows how programming works
expects that the GC will soleve magically all memory allocation problems
using unspecified third party libraries!
It's called "strawman" I believe. Jacob Navia + GC =sloppy
programming and GC
is a magic wand or nothing. Come on, Richard Heathfield must have said
something,
he said something (hopefully I didn't call him a liar here somehow).
Well, of course I *did* say something, which I know Keith will be able to
understand, as will many other people here, although of course not
everyone. Nor do I believe I was setting up a strawman, particularly. I
certainly did not claim that AGC must either be a magic wand or nothing.
My claim was merely that a proposed AGC system that does not work for
third party libraries is significantly weaker than one that does. (Nor
would one need a magic wand to achieve such an AGC.)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Nov 16, 10:15 am, Richard Heathfield <r...@see.sig.invalidwrote:
ymunt...@gmail.com said:
On Nov 16, 9:56 am, jacob navia <ja...@nospam.orgwrote:
<snip>
I fail to understand how someone that knows how programming works
expects that the GC will soleve magically all memory allocation problems
using unspecified third party libraries!
It's called "strawman" I believe. Jacob Navia + GC =sloppy
programming and GC
is a magic wand or nothing. Come on, Richard Heathfield must have said
something,
he said something (hopefully I didn't call him a liar here somehow).
Well, of course I *did* say something,
I commented rather on *why* you did. Or rather my comment was made
because
of what I think about why you did. I bet everybody around (except
Keith, I think,
he's not able to catch RH-JN conversations in his permanent pedantry
mode)
understands why.
which I know Keith will be able to
understand, as will many other people here, although of course not
everyone.
Nor do I believe I was setting up a strawman, particularly. I
certainly did not claim that AGC must either be a magic wand or nothing.
My claim was merely that a proposed AGC system that does not work for
third party libraries is significantly weaker than one that does.
Yep. Merely said this and this.
Best regards,
Yevgen "I swear I will read comp.lang.c++ instead" Muntyan
jacob navia said:
<snip>
I mean can you explain what is AGC
I simply meant Automated Garbage Collection.
your honour?
An attempt at sarcasm, perhaps?
Or why you suppose that if I use the gc, library xyz.lib
automagically uses it too?
In my experience, explaining things to you is a complete and utter waste of
time, since you appear to be incapable of holding a rational debate,
preferring to insult your opponents rather than try to understand them.
You owe many apologies to many people in this group. I doubt very much
whether those apologies will ever be forthcoming, of course.
Because of your debating style, which seeks to attack that which it does
not understand, I have long since stopped trying to educate you, and have
contented myself with correcting your mistakes. Even THAT was happening so
often that it looked like I was attacking you out of some kind of
vendetta, so I stopped, and for a while your mistakes went largely
uncorrected.
Then I corrected a few, and again people thought I was attacking you. So
Charlie Gordon (one such person) agreed to my proposal that *he* should
correct all your mistakes in return for a promise that I would not mention
your name ever again. But he shows no sign of keeping his end of the
bargain, so we're back to square one again.
No doubt there are those who will see *this* reply as an attack. But in
fact it is merely an explanation, addressed more to the group than to you
(since I see no value in explaining things to you), of why I am not
answering your question.
Bottom line: if you want to learn stuff from me or from anyone else here,
leave your arrogance at the door, apologise to all those you have called
liars, fools, polemicists, etc etc etc ad nauseam, and learn how to take
part in a debate without assuming that anyone disagreeing with you must be
wrong, or trying to mock them simply because you don't understand them.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999 ym******@gmail.com said:
On Nov 16, 10:15 am, Richard Heathfield <r...@see.sig.invalidwrote:
>ymunt...@gmail.com said:
Come on, Richard Heathfield must have said something,
he said something (hopefully I didn't call him a liar here somehow).
Well, of course I *did* say something,
I commented rather on *why* you did. Or rather my comment was made
because of what I think about why you did.
My reply was mostly addressed to Keith, and I was making a valid technical
point. If you think it's part of some kind of vendetta, well, you're
wrong. I'm not interested in vendettas, vendettae, or vendetti. I'm just
weary of explaining the blindingly obvious to the obviously blind. Keith
is perfectly capable of understanding the technical point I was making,
and I'm sure you are too, if you'll only cut through your own
preconceptions and look at what I actually wrote.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield wrote:
jacob navia said:
<snip>
>I mean can you explain what is AGC
I simply meant Automated Garbage Collection.
Ahh , so I guessed correctly. Thanks
>
[snip long blah blah about why I am bad and the evil of my ways]
>
Bottom line:
You still haven't explained anything about why a third party
library should be automatically (or should I say
automagically) recognized by the GC, and why does it
disminish the usage of the GC.
People here say that the GC will make running programs
go awry because of if they do some legal hacks they
would not run any more. That was K. Thomson argument.
When told that the GC is backwards compatible with
existing code, you start arguing that this fact
makes it less useful since third party libraries
will still need their specific memory management calls.
Either way I am wrong. If the GC would take over
malloc and friends that would make current code
break down sometimes, and if it doesn't then it is
less useful.
Head I win, tails you loose.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia said:
<snip>
You still haven't explained anything about why a third party
library should be automatically (or should I say
automagically) recognized by the GC, and why does it
disminish the usage of the GC.
Correct, I haven't; that's because, judging by past experience, I see no
value in attempting to educate you. If you had understood my previous
reply, you would have realised this.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
jacob navia wrote:
Richard Heathfield wrote:
>jacob navia said:
<snip>
>>I mean can you explain what is AGC
I simply meant Automated Garbage Collection.
Ahh , so I guessed correctly. Thanks
>>
[snip long blah blah about why I am bad and the evil of my ways]
>>
Bottom line:
You still haven't explained anything about why a third party
library should be automatically (or should I say
automagically) recognized by the GC, and why does it
disminish the usage of the GC.
People here say that the GC will make running programs
go awry because of if they do some legal hacks they
would not run any more. That was K. Thomson argument.
When told that the GC is backwards compatible with
existing code, you start arguing that this fact
makes it less useful since third party libraries
will still need their specific memory management calls.
Either way I am wrong. If the GC would take over
malloc and friends that would make current code
break down sometimes, and if it doesn't then it is
less useful.
Head I win, tails you loose.
There is no free lunch. There are always tradeoffs. The fact that you
take this fact as a personal affront is not my problem.
There is no way to add GC to the language, or even to an implementation,
without *some* cost. If it takes over malloc and friends, the cost is
that some (perhaps obscure) code could break, the pattern of memory
usage would change, and there might be performance problems (the latter
can be particularly problematic for real-time code). If not, if instead
only memory allocated by GC_malloc is garbage-collected, then you've got
two memory allocation/deallocation systems, potentially both operating
in the same program at the same time. For any given pointer, you have
to keep track of whether it was allocated by malloc (and therefore must
be freed explicitly) or by GC_alloc (and therefore must not be freed
explicitly).
I do not argue that *either* of these is necessarily a reason to exclude
GC from an implementation, or even from the language. I merely point
out some technical issues. (You wanted to discuss technical issues, right?)
Earlier, I incorrectly assumed that GC would potentially break existing
programs that don't use it explicitly. Let me explain why I made that
assumption.
Consider a hypothetical GC implementation (not the one you're proposing)
in which memory allocated by malloc can be garbage-collected, and free
becomes a no-op (or perhaps forces an immediate deallocation). Then
existing programs and libraries gain the benefits of GC (in some cases,
memory leaks just go away), and new code can be written more simply
without bothering to call free().
Presumably there's a way to enable or disable GC for each program,
perhaps by specifying a library at link time.
For some applications, it seems to me that this could potentially be a
good thing. Most programs, I suspect, would continue to work in such an
environment, some better than they did before. Those few programs
that play games with pointers would just have to be built with GC
disabled, or modified to keep the pointers visible.
Given such an implementation, it would be very important to specify that
certain actions which are well-defined in standard C would become undefined.
In my earlier comments, I failed to distinguish between these two
alternatives, and I thought that you were ignoring a very important
issue, though one that perhaps affects only a few programs.
Now, a few questions about the form of GC that you propose.
If you allocate memory with GC_alloc, and free the same memory with
free, what happens? Is it undefined behavior?
Is there a GC_free function that forces an immediate deallocation?
Suppose I allocate a chunk of memory using malloc. Within that chunk of
memory, I have one or more pointers pointing to memory allocated by
GC_alloc. (If both models are supported, this kind of thing is going to
happen.) Then I free() the chunk of memory. Typically, though that
chunk of memory is no longer visible to my program, it's still going to
be in my program's address space with its contents unchanged (until the
same memory is allocated again and re-initialized). Will the garbage
collector be able to collect the memory pointed to by the GC_alloc()ed
pointers? Or, since the malloc()ed memory is still in the program's
address space, will this create a leak? Has the interaction between GC
and the existing malloc/free interface been thought through?
To be very clear, none of this implies that I'm rejecting your ideas.
I'm merely asking some technical questions.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chad |
last post by:
On page 180 from the 2nd edition of "The C Programming Language" by
Kernighan and Richtie, they use the following:
#define NAME_MAX 14
typedef struct {
long ino;
char name;
} Dirent;
|
by: John Salerno |
last post by:
There is an article on oreilly.net's OnLamp site called "The World's
Most Maintainable Programming Language"
(http://www.oreillynet.com/onlamp/blog/2006/03/the_worlds_most_maintainable_p.html).
...
|
by: Mike |
last post by:
Hi,
I'm auctioning the book "The C++ Programming Language" 3rd Ed. by
Bjarne Stroustrup on
ebay, details as follows or see eBay item number 250030480853.
Softback. Condition : Good. Pub....
|
by: kaili |
last post by:
i'm chinese i heard that "The C Programming Language " by Brian W.
Kernighan, Dennis
Ritchie is the best book for new learners.
but it is unavailable here. i mearn there is nobody selled it.
i...
|
by: rh00667 |
last post by:
hi all,
is some free site where i can download the book "The C Programming
Language" K&R
tia
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
