UNIX, C, Perl

[Pilcrow]

Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C? Examples:
Network and internet access, access to UNIX interprocess controls and
communication, locale determination, EBCDIC/ASCII discrimination, etc.

Almost all of these are easy in Perl. Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these? Isn't
anyone working on this problem? or is it all being left for proprietary
systems?

[Flash Gordon]

jacob navia wrote, On 09/09/08 09:50:

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.

You don't need to. One of the questions I was asked in my interview for
my current job was why one should not use strtok (or something of the
sort). My honest answer (which I gave) was that I did not know because I
had never used it. What I did not say was that the reason I had never
used it was that I had never done any token parsing in C so I had no
reason to have looked at it. There was a lot more of the C language
(specifically the library) that I did not bare in mind because it was
completely irrelevant to what I was doing, and ignoring it did no harm.

<snip>

"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.

There are more languages than just C and C++. I have also programmed in
Coral 66, Fortran 77, Basic, various assemblers some simper than C some
more complex, Forth (just a bit of playing), Logo (just a bit of
playing), ML (just a bit of learning), Lisp (just a little playing),
Pascal, Delphi, Perl, Java, a scripting language developed by someone I
know, a peculiar interfacing language designed and implemented by me
(which I am still learning the subtleties of), xslt, php (just a little
debugging and dabbling) and probably a few more I can't think of
currently. Often I'm dealing with multiple languages at the same time
and the interactions between them. I have also had to deal with code
written by fresh graduates with no experience, graduates with some
experience, and all the way up to people who have been programming
professionally since the early days of being able to get a job
programming. I've dealt with code written by good programmers and bad.
In my experience the programmer and process have a much greater impact
on the number of errors and how hard they are to find than the language.
Oh, and the hardest to debug has been some of the C code.
--
Flash Gordon

[CBFalconer]

Nick Keighley wrote:

jacob navia <ja...@nospam.c omwrote:

.... snip ...

>

>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;

Many, especially if operator overloading is present. As an
anti-example, consider the Pascal use of DIV for integers and '/'
for reals.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

REH wrote:

Ian Collins <[e-mail] mwrote:

>REH wrote:

>>jacob navia <ja...@nospam.c omwrote:

.... snip off-topic junk ...

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

The C++ newsgroup is, surprise, named comp.lang.c++. This is
comp.lang.c, and C++ is off topic.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Ian Collins]

jacob navia wrote:

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.

Which is how C++ does them, now there's an interesting contradiction!

--
Ian Collins.

[Ian Collins]

CBFalconer wrote:

REH wrote:

>Ian Collins <[e-mail] mwrote:

>>REH wrote:
jacob navia <ja...@nospam.c omwrote:

.... snip off-topic junk ...

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

The C++ newsgroup is, surprise, named comp.lang.c++. This is
comp.lang.c, and C++ is off topic.

We had that discussion yesterday.

--
Ian Collins.

[jacob navia]

Flash Gordon wrote:

Richard wrote, On 09/09/08 11:25:

>jacob navia <ja***@nospam.c omwrites:

<snip>

>>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.

<snip>

>>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?

<snip>

Yes, you are. I agree that operator overloading makes the language (and
particularly reading the code) more complex. This is one reason why I
don't expect operator overloading to ever be added to the C standard. It
is too controversial.

You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;
is simpler to read than
q = (b+c)/(b*c);

This is why many languages use operator overloading!
It is much simpler to read and use.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Bartc]

"jacob navia" <ja***@nospam.c omwrote in message
news:ga******** **@aioe.org...

Flash Gordon wrote:

>Richard wrote, On 09/09/08 11:25:

>>jacob navia <ja***@nospam.c omwrites:

<snip>

>>>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.

<snip>

>>>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?

<snip>

Yes, you are. I agree that operator overloading makes the language (and
particularly reading the code) more complex. This is one reason why I
don't expect operator overloading to ever be added to the C standard. It
is too controversial.

You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;

is simpler to read than
q = (b+c)/(b*c);

Where b,c,q are clearly numeric types, then q=(b+c)/(b*c) is more intuitive.

The point is that operator overloads could be applied to /any/ user-types,
where b+c is not intuitive at all.

Neither would add(b,c) be, but now you can go and look at function add().
And in this case, if you are not using function overloading, you woudn't
call it add(), but something more apt. Then the function form could be
clearer to read even without looking at the source.

Anyway where an add() function returns objects using heap storage, this
requires extra effort and skill by whoever is writing the overload functions
to take care of memory. So being able to write a=b+c syntactically is only
half the work.

>
This is why many languages use operator overloading!
It is much simpler to read and use.

No, the end-result is much simpler to read and use, when appropriate. It's
the /mechanisms/ for making it possible that make the language complex.

--
Bartc

[Flash Gordon]

jacob navia wrote, On 10/09/08 07:53:

Flash Gordon wrote:

>Richard wrote, On 09/09/08 11:25:

>>jacob navia <ja***@nospam.c omwrites:

<snip>

>>>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.

<snip>

>>>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?

<snip>

Yes, you are. I agree that operator overloading makes the language
(and particularly reading the code) more complex. This is one reason
why I don't expect operator overloading to ever be added to the C
standard. It is too controversial.

You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined functions.

is simpler to read than
q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling and
user defined functions and something about the types. If, on the other
hand, you have operator overloading you don't know whether or not you
are calling user defined functions (or which ones) without checking the
types of all of the variables and whether the operators have been
overloaded.

This is why many languages use operator overloading!
It is much simpler to read and use.

It can make some things easier to write, and with sufficient discipline
it can be very useful. However, in general you don't know whether
sufficient discipline has been used. With operator overloading tell me
what the following line does...

count = a - b;


Bet you got it wrong, a and b are set types, - is overloaded to provide
the intersection, and = is overloaded so that if the left operand is an
integer types and the right a set type it assigns the cardinality of the
set to the left operand. So count will be the number of elements in both
a and b.

Now, is the following easier to read?

count = card(intersect( a,b));
--
Flash Gordon

[Keith Thompson]

Flash Gordon <sp**@flash-gordon.me.ukwri tes:

jacob navia wrote, On 10/09/08 07:53:

[...]

>You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined functions.

>is simpler to read than
q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling and
user defined functions and something about the types. If, on the other
hand, you have operator overloading you don't know whether or not you
are calling user defined functions (or which ones) without checking
the types of all of the variables and whether the operators have been
overloaded.

Which means that operator overloading should (ideally) be used only
when not knowing whether you're calling user-defined functions doesn't
make it more difficult to understand the code.

If you happen to know that q, b, and c are of some type(s) other than
those for which those operators are built-in, then you know that at
least "+", "/", and "*" are overloaded operators (i.e., user-defined
functions). And if you don't know that, then you're probably not
going to understand the code anyway.

In real code, you'd use better names that q, b, and c (they're ok for
a short example like this, but not for real code). Even without
operator overloading, I have very little idea what
q = (b+c)/(b*c);
is supposed to do.

>This is why many languages use operator overloading!
It is much simpler to read and use.

It can make some things easier to write, and with sufficient
discipline it can be very useful. However, in general you don't know
whether sufficient discipline has been used.

Agreed. I've used operator overloading myself, and I don't recall
running into serious problems with it; perhaps I've been lucky.

With operator overloading
tell me what the following line does...

count = a - b;


Bet you got it wrong, a and b are set types, - is overloaded to
provide the intersection, and = is overloaded so that if the left
operand is an integer types and the right a set type it assigns the
cardinality of the set to the left operand. So count will be the
number of elements in both a and b.

Overloading "-" to denote set intersection is a bad idea; it's like
writing an ordinary function to compute a set intersection and calling
it "difference ". I think "*" is sometimes used -- and that's ok if
your intended audience understands that "*" means set intersection.

Now, is the following easier to read?

count = card(intersect( a,b));

Maybe.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Flash Gordon wrote:

jacob navia wrote, On 10/09/08 07:53:

>You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined functions.

>is simpler to read than
q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling and
user defined functions and something about the types. If, on the other
hand, you have operator overloading you don't know whether or not you
are calling user defined functions (or which ones) without checking the
types of all of the variables and whether the operators have been
overloaded.

This is just not true. If you are working in a 16 bit machine
and you are doing a long divide in 32 bits you call a
function. If you are in a 32 bit machine and you are doing
a 64 bit divide you call a function too. I know because I wrote
those functions and they are messy :-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32