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?

[Nick Keighley]

On 10 Sep, 20:42, Flash Gordon <[e-mail] te:

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

<snip>

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,

and in well written code the definitions of a and b
wouldn't be far away. Hence I'd glance to the top of page
and find

SetType a;
SetType b;

which would warn me (even if I didn't know what SetType
meant) that there was something unusual going on with '-'
(at least).

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

- for set intersection is common mathematical notation

--
Nick Keighley

In a sense, there is no such thing as a random number;
for example, is 2 a random number?
(D.E.Knuth)

[Nick Keighley]

On 12 Sep, 09:06, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

On 10 Sep, 20:42, Flash Gordon <[e-mail] te:

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

<snip>

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,

and in well written code the definitions of a and b
wouldn't be far away. Hence I'd glance to the top of page
and find

SetType a;
SetType b;

which would warn me (even if I didn't know what SetType
meant) that there was something unusual going on with '-'
(at least).

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

- for set intersection is common mathematical notation

this is, of course, bollocks. - is sensible mathematical set
notation, but not intersection. A while since I played with
sets

--
Nick Keighley

[Flash Gordon]

Nick Keighley wrote, On 12/09/08 09:12:

On 12 Sep, 09:06, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

>On 10 Sep, 20:42, Flash Gordon <[e-mail] te:

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

<snip>

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

and in well written code the definitions of a and b
wouldn't be far away. Hence I'd glance to the top of page
and find

SetType a;
SetType b;

which would warn me (even if I didn't know what SetType
meant) that there was something unusual going on with '-'
(at least).

With well written code I agree. The problem is I also have to deal with
badly written code.

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

- for set intersection is common mathematical notation

this is, of course, bollocks. - is sensible mathematical set
notation, but not intersection. A while since I played with
sets

I'm sure someone will make that mistake when using operator overloading
to implement sets, just as both of us have now done ;-)

Many moons ago I did a lot of work using sets in Pascal, I just
miss-remembered it. With that Pascal code using * for intersection etc
was not a problem because the code was well written, after all I wrote
it ;-)

Operator overloading can be used to very good effect. However, for those
of us having to deal with code written by people we have no control over
and who abuse language features it would make reading the code more
complex because of the need to check.
--
Flash Gordon

[Flash Gordon]

Ian Collins wrote, On 12/09/08 03:32:

Flash Gordon wrote:

>Ian Collins wrote, On 11/09/08 20:38:

>>Ian Collins wrote:
Flash Gordon wrote:
s0****@gmail.co m wrote, On 11/09/08 11:38:
>There are a couple of important factors you're overlooking:
You are missing the point that lots of us have to deal with code
written
by other people who do not necessarily follow good practice.
>
If you are going to use that argument, you may as well ban pointers
as well.

I should have said macros there. While maintaining other people's code
I've had more arse ache form stupid macros then I've ever had from
overloaded operators.

If I was creating my ideal language it would not have macros, they make
the language more complex. However, that boat sailed a long time ago in
C. Anyway, I'm arguing that operator overloading is an additional
complexity and because of that it is unlikely to be added to C.

I can't argue with with it not being added to C, but having used
operator overloaded a lot in that other language, I still believe the
benefits more than outweigh any cost.

I agree that it can be used well. Where I used to work we could impose
appropriate disciplines to remove the abuses, and if I remember your
posting history correctly I suspect the same applies to where you work.

However, with one developer I know I can just imagine the mess he could
create since I know the mess he can create just with C as it is.

The last large project I working on had a lot of time types and
complicated periodic fixed or variable duration control processes. Most
of the time when working with times, the type of the time interval or
period was irrelevant. Having overloaded operators provided a
convenient level of abstraction enabling us to concentrate on the
problem, not the detail of the implementation.

Agreed.

You accept there is a cost, I accept there is a value.
--
Flash Gordon