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 3 Sep, 11:18, Ron Ford <r...@example.i nvalidwrote:

On Wed, 3 Sep 2008 00:23:52 -0700 (PDT), Nick Keighley posted:

On 3 Sep, 07:47, Ron Ford <r...@example.i nvalidwrote:

On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:

<snip>

Every time time you "reinvent the wheel," you have to have a caller and a
target. *

>I find that crossing syntax avoids weaknesses in given syntaxes.

what does that mean? Is it even english?

Since texans have monopolized vapidity, I'm afraid the answer is yes. *I
can't make the point without posting a syntax which is not c, but that just
reminds me of texans, the not-constitution oil retards.

since this makes no more sense than the bit I tried to get you clarify
I assume you don't actaully want to communicate.

<snip>

--
Nick Keighley

[Kenny McCormack]

In article <Nduvk.481$Wd.2 23@trnddc01>,
James Kuyper <ja*********@ve rizon.netwrote:

>Pilcrow wrote:
...

>am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, ...

Asking provocative questions tends, by definition, to provoke negative
reactions. I'd recommend asking interesting questions, rather than
provocative ones.

This is true on Usenet and is Usenet's primary flaw.

It's not true in general (Note: You should probably spend some time with
a dictionary - look up the word "provocativ e") - that is, in real life - but
it is true that anything the least bit off the well-trodden path in a
Usenet posting, just gets people's dander up. The thread then just
turns into a big mess of defensiveness.

[Kenny McCormack]

In article <4h************ *************** *****@4ax.com>,
Pilcrow <pi*****@pp.inf owrote:
....

>So many people have accused me of having a hidden agenda that I feel I
should declare my agenda explicitly. I am a man who has had a bit of
programming experience, most recently with Perl, who is now trying to
acquire a working knowledge of C, sufficient to do the kinds of things I
am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, especially as to the resources available to
the C programmer who is trying not to have to reinvent the wheel, but I
seem to have ruffled some feathers, for which I apologize. Please bear
with me, and be patient.

I already have gotten some answers, such as the existence of the
locale.h header file, which I should have noticed before.

I again apologize to all of you, but C, though faster than Perl, seems
to me very constricting. I am still working my way through K&R2, (and
posting some of my solutions on clc-wiki), so maybe there will be an
epiphany soon. I hope so.

Comments:
1) The obvious question is: Why? Others have alluded to this
question as well. The basic fact is that, in the context of
hosted systems, C is a legacy language; I can't see any reason
to do new development in it. People are pretty open about the
fact that, in today's world, C's domain is a) maintaining legacy
code and b) embedded systems.
2) Despite the name, this is not the newsgroup for you. None of the
things that you want to do are "on topic" here. I'm surprised
people haven't been hammering this point a lot harder than they
have. In fact, it can be said that, in general, anything that
you can do in C that is "on topic" here, shouldn't be done in C.
It should be done in a simple scripting language, such as AWK or Perl.

[Richard Heathfield]

Pilcrow said:

Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C?

I don't know of anything computable that isn't computable in ordinary C.

Examples:
Network and internet access,

C allows you to call library functions that provide these features, but
doesn't go so far as to make their provision mandatory. (Otherwise, you
couldn't have a C implementation on a system that didn't have internet
access - and that would be silly.)

access to UNIX interprocess controls and communication,

Unix systems provide this access. Other systems don't. Don't blame the
language for the lack of provision of Unix interprocess communication
functionality on (some) non-Unix systems.

locale determination,

It's not very well-named, but setlocale() has a query option.

EBCDIC/ASCII discrimination, etc.

Well, if those were the only two choices, it would be trivial to determine
between them: if('A' == 65) it's ASCII. But since there are many choices,
why these two in particular?

(As it turns out, very often it doesn't actually matter what character set
you're using.)

Almost all of these are easy in Perl.

That's nice.

Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these?

There is. It's called "libraries" .

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

Richard Heathfield wrote:

Pilcrow said:

>Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C?

I don't know of anything computable that isn't computable in ordinary C.

>Examples:
Network and internet access,

C allows you to call library functions that provide these features, but
doesn't go so far as to make their provision mandatory. (Otherwise, you
couldn't have a C implementation on a system that didn't have internet
access - and that would be silly.)

Exactly.

There are many implementations of networking, from
Windows sockets, BSD sockets, Netware, USB networking,
Wan, LANs, etc.

To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftplib .pl');
use strict;
my(@dirList);
ftp::debug('ON' );
ftp::open('ftp. cis.ufl.edu', 'anonymous', 'm******@planet .net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary();
ftp::gets('FAQ. gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n") ;
}
@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n") ;
}
ftp::debug();
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n") ;
}
----------------------------------------------perl

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

>
Unix systems provide this access. Other systems don't. Don't blame the
language for the lack of provision of Unix interprocess communication
functionality on (some) non-Unix systems.

Exactly. The OP is completely confusing what a computer language is, and
what an operating system is.

>locale determination,

It's not very well-named, but setlocale() has a query option.

>EBCDIC/ASCII discrimination, etc.

Well, if those were the only two choices, it would be trivial to determine
between them: if('A' == 65) it's ASCII. But since there are many choices,
why these two in particular?

(As it turns out, very often it doesn't actually matter what character set
you're using.)

>Almost all of these are easy in Perl.

That's nice.

>Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these?

There is. It's called "libraries" .

Exactly. C has "modules", and the interface is simple and efficient.
There is an enormous amount of C libraries around.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[vippstar]

On Sep 3, 6:07 pm, jacob navia <ja...@nospam.c omwrote:

<snip>

To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftplib .pl');
use strict;
my(@dirList);
ftp::debug('ON' );
ftp::open('ftp. cis.ufl.edu', 'anonymous', 'medi...@planet .net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary();
ftp::gets('FAQ. gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n") ;}

@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n") ;}

ftp::debug();
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n") ;}

----------------------------------------------perl

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

And using my implementation of perl, the above program looks like
this:
f()

So what?

[Richard Heathfield]

jacob navia said:

Kenny McCormack wrote:

<snip>

> People are pretty open about the
fact that, in today's world, C's domain is a) maintaining legacy
code and b) embedded systems.

This is the opinion of many people here, specially the regulars.

It certainly isn't my opinion.

I am really disappointed that you are basically in agreement
with them.

I don't think he is.

I am convinced that C is a language with a future,

Sure.

that can be
modified and improved to fit better the needs of software development
today without losing its inherent simplicity.

The whole C99 experience suggests that the process of changing C will not
be an easy one. That does not in itself mean that the task should not be
attempted, but it is at least a heads-up that Here Be Dragons.

All my posts, and my work building a freely distributable
C99 compiler go in that direction.

I would propose that people that think that C is dead should
keep their opinion and go to other newsgroups.

On the contrary, I would propose that they change their opinion, since
there is no point in holding onto broken opinions.

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

vi******@gmail. com wrote:

On Sep 3, 6:07 pm, jacob navia <ja...@nospam.c omwrote:

<snip>

>To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftpli b.pl');
use strict;
my(@dirList) ;
ftp::debug('ON ');
ftp::open('ftp .cis.ufl.edu', 'anonymous', 'medi...@planet .net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary( );
ftp::gets('FAQ .gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n" );}

@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n" );}

ftp::debug() ;
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n" );}

----------------------------------------------perl

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

And using my implementation of perl, the above program looks like
this:
f()

So what?

Then, that proves that in any language, verbosity is a function of the
libraries that you are using!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ben Bacarisse]

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

Richard Heathfield wrote:

>Pilcrow said:

>>Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C?

I don't know of anything computable that isn't computable in ordinary C.

>>Examples:
Network and internet access,

C allows you to call library functions that provide these features,
but doesn't go so far as to make their provision
mandatory. (Otherwise, you couldn't have a C implementation on a
system that didn't have internet access - and that would be silly.)

Exactly.

There are many implementations of networking, from
Windows sockets, BSD sockets, Netware, USB networking,
Wan, LANs, etc.

To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl

<snip bad Perl>

----------------------------------------------perl

No, using the correct module it is two lines.

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

You need at least a #include and a main function as well, no? Your C
program will be no shorter than my Perl one.

These sorts of discussions (about program length) are daft and will
often degenerate into pointless comparisons like this.

But there *is* an important issue here. Perl's modules work well
together because of the dynamic type system, and the fact that Perl
has very flexible containers. Using C, you may be able to find a
great XML parsing library (for example) but it will probably represent
its lists and tables using different types (and access functions) to
all the other libraries you need. This is why Perl is so good at
"gluing" tasks.

This is the elephant in the room as far as C is concerned. Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

--
Ben.

[jacob navia]

Ben Bacarisse wrote:

But there *is* an important issue here. Perl's modules work well
together because of the dynamic type system, and the fact that Perl
has very flexible containers. Using C, you may be able to find a
great XML parsing library (for example) but it will probably represent
its lists and tables using different types (and access functions) to
all the other libraries you need. This is why Perl is so good at
"gluing" tasks.

This is the elephant in the room as far as C is concerned. Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

That is why I have been insisting that we adopt the operator overloading
feature that would allow using the '[' and ']' notation for general
containers. Then, we could agree that lists/flexible arrays/arrays
and all sequential containers could be accessed with that notation and
code would be compatible.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32