UNIX, C, Perl

[Ian Collins]

Re: UNIX, C, Perl

jacob navia wrote:

>
I consider C++ a very complex language where bugs have a lot more
places to hide.

While it is complex, it offers bigger hammers to squash bugs!

Like many new toys, C++ adds the tools to eliminate common C bugs, while
introducing plenty of scope for bugs of its own.

--
Ian Collins.

[Ian Collins]

Re: UNIX, C, Perl

REH wrote:

On Sep 6, 1:44 pm, jacob navia <ja...@nospam.c omwrote:

>TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
>This would apply to
>>
> table[idx] = newvalue;
>>
>In C++ there is no way to distinguish between those
>operations since you just return a pointer.
>>
>This is done to support read only data types, what is very hard in C++.

>
nonsense.
>
Read:
const TYPE& operator[](std::size_t i) const;
>
or, if you prefer by value:
>
TYPE operator[](std::size_t i) const;
>
Write:
TYPE& operator[](std::size_t i);
>
x = y[1]; would call the operator with the read prototype.
>
y[1] = x; would call the operator with the write prototype.
>

No you are wrong there. Ask why on c.l.c++.

--
Ian Collins.

[Flash Gordon]

Re: UNIX, C, Perl

jacob navia wrote, On 09/09/08 00:14:

Flash Gordon wrote:

>Anand Hariharan wrote, On 08/09/08 16:19:

>>On Sep 4, 6:15 pm, Flash Gordon <s...@flash-gordon.me.ukwro te:
>>>jacob navia wrote, On 04/09/08 00:08:
>>>>Because it is a *simple* language. Simple languages are easier to
>>>>understan d and use, and have less surface for bugs.
>>>I've seen a lot of bugs in code written in simpler languages.
>>>
>>Could you elaborate? What are the mainstream programming languages
>>(as in those languages with a reasonable number of programs written
>>using them) that you consider to be simpler than C?

>>
>Depending on your definition of simpler, I have...
>>
>Z80 assembler. This is a nice fairly simple assembly language and I've
>seen lots of bugs in code written in it. It certainly was mainstream
>back when I started using it, and there are a lot of NSC800 processors
>(the military equivalent with a few extra built-in peripherals) still
>flying around.
>>
>Pascal. This is simpler in terms of being in general a higher level
>language without OO (which Jacob considers complex, and not without
>reason), and I've seen lots of bugs in Pascal.
>>
>Choose a definition of simple and I am sure I can find a language I've
>used which meets that definition.

>
I did NOT say that C has no bugs. Read what I wrote again:

Read what I said again. I said "lots".

>>jacob navia wrote, On 04/09/08 00:08:
>>>Simple languages are easier to
>>>understand and use, and have less surface for bugs.

>
Is that clear to you now?
>
"Less surface" means that, less surface, not NO bugs but fewer and
easier to find.

My experience is that bugs are just as common and just as good at hiding
in code written in every language I have used.

I consider C++ a very complex language where bugs have a lot more
places to hide.

I don't have enough experience of C++ to comment about that. However, I
do have experience of "simpler" languages than C and my experience is
that the skill level of the people and the quality of the development
process have a far larger impact than the language on the bug count and
the difficulty in finding the bugs.
--
Flash Gordon

[Nick Keighley]

Re: UNIX, C, Perl

On 9 Sep, 00:14, jacob navia <ja...@nospam.c omwrote:

Flash Gordon wrote:

Anand Hariharan wrote, On 08/09/08 16:19:

On Sep 4, 6:15 pm, Flash Gordon <s...@flash-gordon.me.ukwro te:
>jacob navia wrote, On 04/09/08 00:08:

>>Because [C] is a *simple* language. Simple languages are easier to
>>understand and use, and have less surface for bugs.

I dunno. You tend to have to write more code to do things that
a more "complex" language would express in less code.

Consider a C with operator over-loading. This is more both more
expressive and more complex than standard C. :-)

>I've seen a lot of bugs in code written in simpler languages.

>

Could you elaborate?  What are the mainstream programming languages
(as in those languages with a reasonable number of programs written
using them) that you consider to be simpler than C?

>

Depending on your definition of simpler, I have...

>

Z80 assembler. This is a nice fairly simple assembly language and I've
seen lots of bugs in code written in it. It certainly was mainstream
back when I started using it, and there are a lot of NSC800 processors
(the military equivalent with a few extra built-in peripherals) still
flying around.

>

Pascal. This is simpler in terms of being in general a higher level
language without OO (which Jacob considers complex, and not without
reason), and I've seen lots of bugs in Pascal.

>

Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.

>
I did NOT say that C has no bugs. Read what I wrote again:

he didn't say you said...

 >>jacob navia wrote, On 04/09/08 00:08:
 >>>Simple languages are easier to
 >>>understand and use, and have less surface for bugs.
>
Is that clear to you now?
>
"Less surface" means that, less surface, not NO bugs but fewer and
easier to find.

um no. Since programming languages don't have surfaces they can't
have "less surface". It's a metaphor and you don't explain a metaphor
by, basically, repeating the metaphor.

One of my pet hates is things like "he was *literally* blown away".
Well
unless he was mishandling explosives, no he wasn't.

I consider C++ a very complex language where bugs have a lot more
places to hide.

how many places can this expression generate an exception?
a = b + c;


--
Nick Keighley

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?"
-- Tom Cargil, C++ Journal.

[jacob navia]

Re: UNIX, C, Perl

Nick Keighley wrote:

Consider a C with operator over-loading. This is more both more
expressive and more complex than standard C. :-)
>

No, because standard C includes complex numbers. This extension would
make the language *smaller* because complex numbers could
be left *out* of the language itself, making it simpler
yet more powerful.

>"Less surface" means that, less surface, not NO bugs but fewer and
>easier to find.

>
um no. Since programming languages don't have surfaces they can't
have "less surface". It's a metaphor and you don't explain a metaphor
by, basically, repeating the metaphor.
>

The "surface" of a language is the number of features exposed
to the user at any given time.

When you write in a simple language you can have all the features
of the language in your mind and you can know exactly what are you
doing.

When you write in a complex language, there are so many features
available that it is impossible for you to have all of them
in your mind when writing new code. There are then features that can
provoke bugs that you can't foresee.

>
--
Nick Keighley
>
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?"
-- Tom Cargil, C++ Journal.

It is interesting that in your signature you quote a confirmation of
what I am arguing.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Re: UNIX, C, Perl

Flash Gordon wrote:

I don't have enough experience of C++ to comment about that. However, I
do have experience of "simpler" languages than C and my experience is
that the skill level of the people and the quality of the development
process have a far larger impact than the language on the bug count and
the difficulty in finding the bugs.

The problem with complicated/complex languages is that you just
can't have all the features of the language in your mind when writing
new code.

For instance I said in this same thread that C++ can't differentiate
with the overloaded '[' ']' operator between writing and reading.

Almost immediately, one C++ expert told me that is nonsense and
proposed a solution. The solution looks quite plausible, and nobody
objected (I was just waited).

A day later another expert says that the solution proposed by the
first expert will just not work. He said (to the first expert) that
he should ask in comp.lang.c++ why it doesn't work.

When I asked the same question in the C++ experts group, it took
quite a while until one expert proposed a solution that was
accepted by the others, maybe because involved templates and
was (as always in c++) an atomic bomb to kill a fly.

The problem with a language like that is that the interactions
among the million features are just *beyond* what a human
mind can follow.

The specifications for name lookup when following a class
overloaded operator are pages and pages, involving a
topological sort, etc. It is impossible for a human to
follow all that. Only a machine can have the patience to
do this kind of stuff.

At that point, a language becomes segmented in the programmer's
mind. He/she will concentrate on the features he/she assumes
that have relevance to the problem at hand and ignore the
possible subtle interactions of all the others.

You have to keep in mind that when writing code there are
TWO completely different "computers" involved:

(1): A "biological " computer made of billions of processors that
is NOT designed for programming
(2) a CPU

(1) is designed after around 1 billion years of evolution for
coping with a natural environment, where computers just
do not exist. It has a short attention span and a very
limited short term memory.

"To err is human", and the possibility of introducing errors in a
program increases with the number of features you have to keep
in mind.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Nick Keighley]

Re: UNIX, C, Perl

On 9 Sep, 09:26, jacob navia <ja...@nospam.c omwrote:

Nick Keighley wrote:

Consider a C with operator over-loading. This is more both more
expressive and more complex than standard C.   :-)

>
No, because standard C includes complex numbers. This extension would
make the language *smaller* because complex numbers could
be left *out* of the language itself, making it simpler
yet more powerful.

a similar argument could be made for templates in C++
allowing the existence of the STL


<snip>

The "surface" of a language is the number of features exposed
to the user at any given time.
>
When you write in a simple language you can have all the features
of the language in your mind and you can know exactly what are you
doing.
>
When you write in a complex language, there are so many features
available that it is impossible for you to have all of them
in your mind when writing new code. There are then features that can
provoke bugs that you can't foresee.
>
>
>

--
Nick Keighley

>

"If you think C++ is not overly complicated, just what is a protected
 abstract virtual base pure virtual private destructor, and when
 was the last time you needed one?"
                   -- Tom Cargil, C++ Journal.

>
It is interesting that in your signature you quote a confirmation of
what I am arguing.

my sigs are not randomly generated


--
Nick Keighley

why isn't there an obfuscated C++ contest?

[Richard]

Re: UNIX, C, Perl

jacob navia <jacob@nospam.c omwrites:

Flash Gordon wrote:

>I don't have enough experience of C++ to comment about
>that. However, I do have experience of "simpler" languages than C
>and my experience is that the skill level of the people and the
>quality of the development process have a far larger impact than the
>language on the bug count and the difficulty in finding the bugs.

>
The problem with complicated/complex languages is that you just
can't have all the features of the language in your mind when writing
new code.
>
For instance I said in this same thread that C++ can't differentiate
with the overloaded '[' ']' operator between writing and reading.
>
Almost immediately, one C++ expert told me that is nonsense and
proposed a solution. The solution looks quite plausible, and nobody
objected (I was just waited).
>
A day later another expert says that the solution proposed by the
first expert will just not work. He said (to the first expert) that
he should ask in comp.lang.c++ why it doesn't work.
>
When I asked the same question in the C++ experts group, it took
quite a while until one expert proposed a solution that was
accepted by the others, maybe because involved templates and
was (as always in c++) an atomic bomb to kill a fly.
>
The problem with a language like that is that the interactions
among the million features are just *beyond* what a human
mind can follow.

Am I allowed here to say once more - and this is why operator
overloading is nonsense and leads to horrible, unmaintainable code?

I have worked with experts and language lawyers. And all they do is
argue about the cleverest way to do things. And Introducing Operator
Overloading into C will see a huge reduction in the quality and
maintainability of the code bases. Been there done that with C++.- Yes,
I know, "if done properly" - but listen to the experts argue about best
approach and then consider "average Ted" and what he would
do. Nope. Keep them away.

[REH]

Re: UNIX, C, Perl

On Sep 9, 1:13 am, Ian Collins <ian-n...@hotmail.co mwrote:

REH wrote:

On Sep 6, 1:44 pm, jacob navia <ja...@nospam.c omwrote:

TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

>

        table[idx] = newvalue;

>

In C++ there is no way to distinguish between those
operations since you just return a pointer.

>

This is done to support read only data types, what is very hard in C++..

>

nonsense.

>

Read:
const TYPE& operator[](std::size_t i) const;

>

or, if you prefer by value:

>

TYPE operator[](std::size_t i) const;

>

Write:
TYPE& operator[](std::size_t i);

>

x = y[1]; would call the operator with the read prototype.

>

y[1] = x; would call the operator with the write prototype.

>
No you are wrong there.  Ask why on c.l.c++.
>
--
Ian Collins.

Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.

REH

[Ian Collins]

Re: UNIX, C, Perl

jacob navia wrote:

>
For instance I said in this same thread that C++ can't differentiate
with the overloaded '[' ']' operator between writing and reading.
>
Almost immediately, one C++ expert told me that is nonsense and
proposed a solution. The solution looks quite plausible, and nobody
objected (I was just waited).
>

How do you define 'immediately' (almost 2 days) and how do you define
expert?

A day later another expert says that the solution proposed by the
first expert will just not work. He said (to the first expert) that
he should ask in comp.lang.c++ why it doesn't work.

Where else should the so called expert go to find the error of his ways?
Do all C programmers agree all of the time? A day or two here will
answer that.

When I asked the same question in the C++ experts group, it took
quite a while until one expert proposed a solution that was
accepted by the others, maybe because involved templates and
was (as always in c++) an atomic bomb to kill a fly.
>

Proxies are the idiomatic way to determine read from write. No
templates are required.

The problem with a language like that is that the interactions
among the million features are just *beyond* what a human
mind can follow.

Then use the ones your mind can follow, which is what most programmers
do in most languages. What I do like is a language that can solve
problems (such as determining read from write to an array) without
resorting to language extensions.

At that point, a language becomes segmented in the programmer's
mind. He/she will concentrate on the features he/she assumes
that have relevance to the problem at hand and ignore the
possible subtle interactions of all the others.

So all C programmers use all the dusty corners of the language? Most
programmers work in teams and the collective knowledge of the team helps
the individual's knowledge to grow.

--
Ian Collins.

[REH]

Re: UNIX, C, Perl

On Sep 9, 1:13 am, Ian Collins <ian-n...@hotmail.co mwrote:

REH wrote:

On Sep 6, 1:44 pm, jacob navia <ja...@nospam.c omwrote:

TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

>

        table[idx] = newvalue;

>

In C++ there is no way to distinguish between those
operations since you just return a pointer.

>

This is done to support read only data types, what is very hard in C++..

>

nonsense.

>

Read:
const TYPE& operator[](std::size_t i) const;

>

or, if you prefer by value:

>

TYPE operator[](std::size_t i) const;

>

Write:
TYPE& operator[](std::size_t i);

>

x = y[1]; would call the operator with the read prototype.

>

y[1] = x; would call the operator with the write prototype.

>
No you are wrong there.  Ask why on c.l.c++.
>
--
Ian Collins.

Re-reading it, I believe you were confused/mislead by my overly
concise example. I meant to imply x = y[1]; was being used in a
context were y was constant. Obviously, if y is not constant, it would
call the "write" version for both lvalues and rvalues.

REH

[Ian Collins]

Re: UNIX, C, Perl

REH wrote:

On Sep 9, 1:13 am, Ian Collins <ian-n...@hotmail.co mwrote:

>REH wrote:

>>Read:
>>const TYPE& operator[](std::size_t i) const;
>>or, if you prefer by value:
>>TYPE operator[](std::size_t i) const;
>>Write:
>>TYPE& operator[](std::size_t i);
>>x = y[1]; would call the operator with the read prototype.
>>y[1] = x; would call the operator with the write prototype.

>No you are wrong there. Ask why on c.l.c++.
>>

>
Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.
>

No, the constness of the object determines which one gets called. Try
it then ask down the hall.

--
Ian Collins.

[Bartc]

Re: UNIX, C, Perl

"jacob navia" <jacob@nospam.c omwrote in message
news:g9n5f3$dm3 $1@aioe.org...

Flash Gordon wrote:

>>
>Are you claiming that C should be used as a general solution to ALL
>programming problems?
>>

>
Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...
>
You apparently are of the same opinion.
>
By leaving application programming for other languages, you
effectively destroy C.
>
Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.

My opinion when I first looked at C a few years ago was that this would be a
great language if you got rid of all the obsolete baggage and brought it
up-to-date. Like a 'C2004' version (as it would have been).

And, perhaps target it at more modern machines. Looking at a table of basic
types like the following (for perhaps C# or D):

char 1 byte 8 bits
short int 2 bytes 16 bits
int 4 bytes 32 bits
long int 8 bytes 64 bits

is somehow very wonderful and refreshing. Finally, you know exactly where
you are! Compare with the woolly approach used in C, which makes it
difficult to code with any confidence.

New C would be simpler and yet could be more powerful. Unfortunately people
creating successors to C don't know where to stop.

I am claiming that C can be used for general application
programming. It needs just a single modification
(operator overloading) and a rewrite of the standard library
to be able to be very useful in application programming.

When I looked at this for one of my languages once (but never implemented; I
found it easier to build any special types and their operators into the
language), I tried this approach:

* Create the code needed for the operations using ordinary functions. The
function names need to be unique, as function overloading is not used.

So far, this does not require anything special in the language, and people
who don't like overloading can use these directly.

THEN, possibly link each of these functions to a standard operator using
some syntactic device, perhaps a pragma:

#pragma registerop "*" (mat,mat) = multiplymat()

This way you can sneak in operator overloading into the language with hardly
anyone noticing.

--
Bartc

[REH]

Re: UNIX, C, Perl

On Sep 9, 7:11 am, Ian Collins <ian-n...@hotmail.co mwrote:

REH wrote:

On Sep 9, 1:13 am, Ian Collins <ian-n...@hotmail.co mwrote:

REH wrote:
>Read:
>const TYPE& operator[](std::size_t i) const;
>or, if you prefer by value:
>TYPE operator[](std::size_t i) const;
>Write:
>TYPE& operator[](std::size_t i);
>x = y[1]; would call the operator with the read prototype.
>y[1] = x; would call the operator with the write prototype.
No you are wrong there.  Ask why on c.l.c++.

>

Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.

>
No, the constness of the object determines which one gets called.  Try
it then ask down the hall.
>
--
Ian Collins.

Please, read my other response.

REH

[s0suk3@gmail.com]

Re: UNIX, C, Perl

On Sep 9, 6:53 am, "Bartc" <bc@freeuk.comw rote:

"jacob navia" <jacob@nospam.c omwrote in message
>
news:g9n5f3$dm3 $1@aioe.org...
>
>
>

Flash Gordon wrote:

>

Are you claiming that C should be used as a general solution to ALL
programming problems?

>

Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...

>

You apparently are of the same opinion.

>

By leaving application programming for other languages, you
effectively destroy C.

>

Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.

>
My opinion when I first looked at C a few years ago was that this would be a
great language if you got rid of all the obsolete baggage and brought it
up-to-date. Like a 'C2004' version (as it would have been).
>
And, perhaps target it at more modern machines. Looking at a table of basic
types like the following (for perhaps C# or D):
>
char        1 byte    8 bits
short int   2 bytes   16 bits
int         4 bytes   32 bits
long int    8 bytes   64 bits
>
is somehow very wonderful and refreshing. Finally, you know exactly where
you are! Compare with the woolly approach used in C, which makes it
difficult to code with any confidence.
>

char 1 byte 8 bits
int16_t 2 bytes 16 bits
int32_t 4 bytes 32 bits
int_least64_t 8 bytes 64 bits (or more)

;-)

Sebastian