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?

Pilcrow wrote:

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

They are not impossible in "ordinary C", they are impossible in strictly
conforming C. The C that operating systems are written in will make
heavy use of highly non-portable constructs that give access to all of
these things. In some cases, those non-portable constructs will consist
of calls to routines written in assembly language, or in-line assembly
language, but a very large fraction of the system can be written
entirely in non-portable C.

... locale determination, EBCDIC/ASCII discrimination, etc.

I'm not at all clear to me why you think that those can't be performed
in ordinary C. What features are you asking for that aren't provided by
<locale.h>? Perhaps if you described in more detail the desired
functionality I could address the question better.

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?

There are such mechanisms - they are called "header files" and
"libraries", and together they serve a very similar purpose.

... Isn't
anyone working on this problem? or is it all being left for proprietary
systems?

There's no reasons why the libraries have to be proprietary, though many
certainly are.

Pilcrow wrote:

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?

Should a programming language set standards for all
the application arenas in which it can be used?

--
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalidwrote in message
news:2uadnYbBJKv5syDVnZ2dnUVZ_oTinZ2d@comcast.com. ..

Pilcrow wrote:

>
Should a programming language set standards for all
the application arenas in which it can be used?

Sun Microsystems: "YOU BETCHA!!!"

Java, the Esperanto of computer programming languages...

---
William Ernest Reid

Pilcrow <pilcrow@pp.infowrote in message
news:11aqb4dfqm5k92um5taqs2dcm942g2rmtu@4ax.com...

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?

I thought "PERL" WAS coded in "C"...

Somebody, many people have worked on this "problem"; for example,
I got a "regex" PERL-like library for free with MY "C" compiler, along
with a bunch of other stuff, including stuff you mention...the only
people who haven't worked on it are those DAMN BEAURUCRATS
IN WASHINGTON!!! (or whever the "C" standards committee met,
and of course, their "portability" yipping lap-dogs here)...

---
William Ernest Reid

On Sep 2, 10:18*am, "Bill Reid" <hormelf...@happyhealthy.netwrote:

Pilcrow <pilc...@pp.infowrote in message
>
news:11aqb4dfqm5k92um5taqs2dcm942g2rmtu@4ax.com...
>

>

>
I thought "PERL" WAS coded in "C"...
>
Somebody, many people have worked on this "problem"; for example,
I got a "regex" PERL-like library for free with MY "C" compiler, along
with a bunch of other stuff, including stuff you mention...the only
people who haven't worked on it are those DAMN BEAURUCRATS
IN WASHINGTON!!! *(or whever the "C" standards committee met,
and of course, their "portability" yipping lap-dogs here)...
>
---
William Ernest Reid

What are we considering "ordinary C?" Are we talking about the
libraries that are distributed with the GNU C library, any C compiler
that is POSIX standard supported, or are we talking about Visual C++?
The beauty of C is that it will run on damn near any piece of hardware
you throw at it. Almost every single platform's operating system is
written in a combination of C and (some form of) assembler. All of
these things that you mentioned are very possible, because frankly,
the language that you mentioned was implemented in C. The foundations
that you are building on were written in C, Pascal and assembler.

But here is the other interesting tidbit. Many languages that make it
easier for programmers to simply create a socket connection with two
lines of code (Python, C# and Java) have C libraries behind them doing
all the dirty work. If you really want to do all of these things in C
then your best bet is to follow a POSIX standard for sockets
(networking) and work strictly with C99 standards. You are almost
guaranteed that your code will run almost anywhere except certain
embedded platforms (and even those now are using POSIX compilers).

I am a firm believer that both C/C++ are portable as long as you have
someone in the background managing the projects. As long as the proper
libraries are used and standards are followed the code should be
relatively easy to port across platforms. But don't take my word for
it: there are many projects available at sourceforge.net that are open
source that can give you examples of a portable C application.
Although take a note: many "C" applications nowadays are essentially a
C++ application.

Bill Reid wrote:
....

IN WASHINGTON!!! (or whever the "C" standards committee met,

As you might expect for an international standards organization, the
meetings of ISO/IEC JTC1/SC22/WG14 are held in a wide variety of
places around the world. Judging from
<http://www.open-std.org/jtc1/sc22/wg14/www/meetings>, it would appear
that they have not met in Washington at any time since at least 1994,
and probably earlier. Since the US member is INCITS J11
<http://www.ncits.org/tc_home/j11.htm>, and that committee's meetings
are co-located with those of WG14, it doesn't look like Washington has
anything to do with this.

On 2 Sep 2008 at 11:48, Pilcrow wrote:

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.

You've spent too much time being brainwashed by the clc regulars.

ALL of these things are possible in C, OF COURSE. And if Official
Standards (peace be upon them) are really important to you, there's this
one you might have heard of: POSIX.

Pilcrow <pilcrow@pp.infowrites:

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?

It depends on what you mean by "ordinary C".

The C language is defined by an ISO standard. (Actually by two
versions of the same ISO standard, since the most recent one has not
yet been widely implemented.) That standard specifically permits
extensions with certain limitations -- and many implementations
provide extensions without those limitations in a non-conforming mode.

If you want to write code that depends only on features defined in the
language standard, then your code will be portable to any conforming C
implementation -- but it won't be able to do networking, interprocess
communication, and so forth.

If you need to use such features, you can. You'll just have to use
some extension (such as POSIX) that's provided by your implementation.
Your program won't be portable to an implementation that doesn't
provide the particular extension(s) you're depending on, and in many
cases your program's behavior won't be defined by the language
standard.

This kind of tradeoff is unavoidable.

C is *designed* to allow writing non-portable code.

The thing is, though, that for most of the extensions you might want
to use, this newsgroup isn't the best place to discuss them. If you
want to ask how to use POSIX, there's comp.unix.programmer; for Win32,
there's comp.os.ms-windows.programmer.win32.

Don't confuse the scope of this newsgroup (as agreed upon by most of
the participants) with the scope of C programming.

--
Keith Thompson (The_Other_Keith) kst-u@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"

On Tue, 02 Sep 2008 12:04:38 GMT, James Kuyper <jameskuyper@verizon.net>
wrote:

>Pilcrow wrote:

>
>They are not impossible in "ordinary C", they are impossible in strictly
>conforming C. The C that operating systems are written in will make
>heavy use of highly non-portable constructs that give access to all of
>these things. In some cases, those non-portable constructs will consist
>of calls to routines written in assembly language, or in-line assembly
>language, but a very large fraction of the system can be written
>entirely in non-portable C.
>

>
>I'm not at all clear to me why you think that those can't be performed
>in ordinary C. What features are you asking for that aren't provided by
><locale.h>? Perhaps if you described in more detail the desired
>functionality I could address the question better.
>

>
>There are such mechanisms - they are called "header files" and
>"libraries", and together they serve a very similar purpose.
>

>
>There's no reasons why the libraries have to be proprietary, though many
>certainly are.

I am certainly glad to hear that these things are possible. But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

The program I wrote is generalized enough to be able to do the same with
any other similar list. This saved me the chore of manually entering
each address into the form on that web page and copying and pasting the
zip code to my list. That chore would have taken several days, since I
am a clumsy typist, and the list, as I have said, has several hundred
entries.

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

I am sure that it is possible, since Perl itself is written in standard
C, or at least GCC.

In article <lnk5duv5be.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.orgmeant to say:
....

>Don't confuse the scope of this newsgroup (as defined by a small, but
>very vocal subset, of the participants) with the scope of C programming.

Typos fixed. No thanks are necessary. HTH. HAND.

Pilcrow wrote:

[...] But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

Good: Problem solved, need satisfied, it's Miller Time.

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will
you then go on to solve it in Ada, Fortran, Lisp, Jovial, ...?
Or to put it another way: If you feel impelled to throw out your
working Perl solution and write a fresh one in C, what is it
about Perl that you find unsatisfactory?

I'm not familiar with the libraries you mention, but there
are plenty of C libraries out there, perhaps including a few that
perform the kinds of tasks you're interested in.

I am sure that it is possible, since Perl itself is written in standard
C, or at least GCC.

I suspect you'll find that it's written in a C dialect --
maybe strictly-conforming C, maybe something looser -- and that
it also makes use of libraries of various kinds that are in turn
written in Lordknowswhat. Perhaps all you're really looking for
is the packaging of a bunch of libraries into a single convenient
framework so you don't have to hunt them up and integrate them?
That's a perfectly reasonable thing to want, but ... as part of
the definition of a general-purpose language?

In your kitchen, I imagine you have an assortment of various
knives. You've probably got a few general-purpose knives, and a
few that are more specialized: heavy broad-bladed knives for chopping,
skinny flexible-bladed knives for filleting, knives with serrated
edges for slicing bread, knives with finer serrations for cutting
tomatoes ... Why do you have so many knives, instead of doing all
your cutting, slicing, and chopping with just one? Is it, perhaps,
because a knife that could handle *all* cutting tasks might have
usability problems?

Stretching the analogy right up to the breaking point, here
are two competing views of what C should be:

http://www.victorinox.com/index.cfm?...age=158&lang=D

http://www.thinkgeek.com/gadgets/tools/8b97/zoom/

You'll notice that they differ mostly in degree.

--
Eric.Sosman@sun.com

Eric Sosman wrote:

Pilcrow wrote:

>
Good: Problem solved, need satisfied, it's Miller Time.
>

>
One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will

This isn't about a particular problem and it's solution, it's about
the availability of problem-solving tools. He's asking how he could
have used a similar approach to solving the problem in the first
place, if he had chosen C rather than perl.

Pilcrow wrote:
....

I am certainly glad to hear that these things are possible. But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.
>
The program I wrote is generalized enough to be able to do the same with
any other similar list. This saved me the chore of manually entering
each address into the form on that web page and copying and pasting the
zip code to my list. That chore would have taken several days, since I
am a clumsy typist, and the list, as I have said, has several hundred
entries.
>
How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many
similar repositories do exist for C code. What you're asking about is
mostly a social issue having to do with how CPAN works; it isn't
related to any technical differences between C and perl. Personally,
the repository I have the most familiarity with is sourceforge.net,
which handles a lot more than just C libraries.

Pilcrow wrote:

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?

Where the facilities exist, the C libraries are provided. What do you
think Perl modules use?

--
Ian Collins.

In article <db46c0cb-30fa-469a-b12f-09f5297c0890@73g2000hsx.googlegroups.com>,
<jameskuyper@verizon.netwrote:
....
(ditzy Eric scribbled)

>
>This isn't about a particular problem and it's solution, it's about
>the availability of problem-solving tools. He's asking how he could
>have used a similar approach to solving the problem in the first
>place, if he had chosen C rather than perl.

Yes. Anyone with a couple of brain cells to rub together can see that.

But it doesn't fit in with the CLC regs approach.

Go back and re-read Eric's text. It is chock full of nasty sarcasm
aimed at belittling the OP, while clearly feigning ignorance of what
this thread is really about.

Eric Sosman <Eric.Sosman@sun.comwrites:

Pilcrow wrote:

>
Good: Problem solved, need satisfied, it's Miller Time.
>

>
One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will

Yes. I mean, who on earth EVER prototypes something in a high level
language and then moves to something like C for, oh, I dont know,
speed, memory usage etc. Are you always so ready to belittle people?

you then go on to solve it in Ada, Fortran, Lisp, Jovial, ...?
Or to put it another way: If you feel impelled to throw out your
working Perl solution and write a fresh one in C, what is it
about Perl that you find unsatisfactory?
>
I'm not familiar with the libraries you mention, but there
are plenty of C libraries out there, perhaps including a few that
perform the kinds of tasks you're interested in.

So you do not know. Just throw in a bit of sarcasm because you are
bored?

>

>
I suspect you'll find that it's written in a C dialect --
maybe strictly-conforming C, maybe something looser -- and that
it also makes use of libraries of various kinds that are in turn
written in Lordknowswhat. Perhaps all you're really looking for
is the packaging of a bunch of libraries into a single convenient
framework so you don't have to hunt them up and integrate them?
That's a perfectly reasonable thing to want, but ... as part of
the definition of a general-purpose language?
>
In your kitchen, I imagine you have an assortment of various
knives. You've probably got a few general-purpose knives, and a
few that are more specialized: heavy broad-bladed knives for chopping,
skinny flexible-bladed knives for filleting, knives with serrated
edges for slicing bread, knives with finer serrations for cutting
tomatoes ... Why do you have so many knives, instead of doing all
your cutting, slicing, and chopping with just one? Is it, perhaps,
because a knife that could handle *all* cutting tasks might have
usability problems?

Who the hell do you think you are second guessing the OP? He came here
for C help - not you strutting around and telling him what he wants.

>
Stretching the analogy right up to the breaking point, here
are two competing views of what C should be:
>
http://www.victorinox.com/index.cfm?...age=158&lang=D
>
http://www.thinkgeek.com/gadgets/tools/8b97/zoom/
>
You'll notice that they differ mostly in degree.

The only thing I noticed is that you made a right fool out of
yourself. Congratulations and another clc stripe.

In article <g9k9a6$9tc$1@registered.motzarella.org>,
Richard <rgrdev@gmail.comwrote:
....

>
>Yes. I mean, who on earth EVER prototypes something in a high level
>language and then moves to something like C for, oh, I dont know,
>speed, memory usage etc. Are you always so ready to belittle people?
>

Answering for Eric: Yes. In a word. Yes. It is my biggest thrill in
life.

On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), jameskuyper@verizon.net wrote:

>Pilcrow wrote:
>...

>
>There is no single repository for C libraries which plays the same
>role for C that CPAN does for perl, but I would guess that many

why do you have to guess? CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included (unless you're installing ActiveState Perl, and a
similar facility is provided there).

>similar repositories do exist for C code. What you're asking about is
>mostly a social issue having to do with how CPAN works; it isn't
>related to any technical differences between C and perl. Personally,
>the repository I have the most familiarity with is sourceforge.net,
>which handles a lot more than just C libraries.

Similar repositories? How do I search them? Do they include
documentation? Are they cross-platform compatible? (I did my trick on a
MS platform, using a distribution of Perl know as 'Strawberry' perl, but
it would have worked also in a UNIX or Linux environment, using Perl
compiled for those). I have made use of Google's code search facility,
but it has its limitations.

Perhaps the reason for this contrast between C and Perl is the
cooperative spirit behind the Open Source movement. Also the evolving
nature of Perl, which, though it dates to 1987, has been frequently
improved and expanded. Facilities for OO programming, multi-threading,
forking, and others, though not in Perl a few years ago, are now
standard. And backward compatability has always been a consideration.

The documentation for Perl is also exemplary. There is little need to go
beyond the documentation available at the command line. All the
documentation needed is included with the installation. Little need to
buy other texts. I admit that more documentation is needed than with C,
but perl is a more complex language.

Pilcrow wrote:

On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), jameskuyper@verizon.net wrote:
>

....

>
why do you have to guess? ...

Because I don't possess enough information to be certain, one way or
the other. Do you? If your question was just rheotorical, as now seems
to be the case, then all you're doing is trolling this newsgroup to
promote perl as a superior alternative to C. I know too much about
perl to fall for that one: perl has a number of advantages over C in
particular contexts, and i use it routinely when those contexts apply,
but it has nowhere near enough advantages to replace C in all
contexts. I wouldn't dream of using it for any of the tasks that I
currently use C for.

... CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included (unless you're installing ActiveState Perl, and a
similar facility is provided there).

I can't figure out what relevance that has to my guesswork. It almost
seems as if you're saying that a C repository cannot count as
"similar" unless access to that repository is automatically installed
when you install your C compiler; but I can't imagine that you're
making such a fatuous suggestion.

>
Similar repositories? How do I search them? Do they include
documentation? Are they cross-platform compatible?

The only such repository I'm familiar with is sourceforge.net. If you
check out their web site, it's pretty obvious how to search it.
Documentation seems to be the norm, not the exception, but I'm sure
that the quality of the documentation is highly variable. I'm sure
that cross-platform compatibility is also highly variable. That's
pretty much unavoidable when source code comes from such a wide
variety of sources.

On Tue, 02 Sep 2008 04:48:57 -0700, Pilcrow <pilcrow@pp.infowrote:

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

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.

On Tue, 2 Sep 2008 16:13:34 -0700 (PDT), jameskuyper@verizon.net wrote:

>Pilcrow wrote:

>...

>
>Because I don't possess enough information to be certain, one way or
>the other. Do you? If your question was just rheotorical, as now seems
>to be the case, then all you're doing is trolling this newsgroup to
>promote perl as a superior alternative to C. I know too much about
>perl to fall for that one: perl has a number of advantages over C in
>particular contexts, and i use it routinely when those contexts apply,
>but it has nowhere near enough advantages to replace C in all
>contexts. I wouldn't dream of using it for any of the tasks that I
>currently use C for.
>

>
>I can't figure out what relevance that has to my guesswork. It almost
>seems as if you're saying that a C repository cannot count as
>"similar" unless access to that repository is automatically installed
>when you install your C compiler; but I can't imagine that you're
>making such a fatuous suggestion.
>

>
>The only such repository I'm familiar with is sourceforge.net. If you
>check out their web site, it's pretty obvious how to search it.
>Documentation seems to be the norm, not the exception, but I'm sure
>that the quality of the documentation is highly variable. I'm sure
>that cross-platform compatibility is also highly variable. That's
>pretty much unavoidable when source code comes from such a wide
>variety of sources.

I apologize. I don't think Perl is superior to C. Every Perl
programmer, however, knows of the existence of CPAN. I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN, so that I don't have to reinvent the wheel with every
new task. I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.

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

>
I apologize. I don't think Perl is superior to C. Every Perl
programmer, however, knows of the existence of CPAN. I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN, so that I don't have to reinvent the wheel with every
new task. I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.

You're not going to find CPAN here with the unterlanguage. It requires an
ecumenism that doesn't exist for C. Not sure why.

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.

Now that I think about it, the first reason for the lack of ecumenism is
history and the second is that there are dozens of competing
implementations of C while perl competes more convincingly for a
narrowslice, like sysadmins.
--
What men value in this world is not rights but privileges. 7
H. L. Mencken

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

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

>

C has no equivalent to CPAN. But then CPAN is pretty unique
to perl. You could say it was one of perl's selling points.

>
You're not going to find CPAN here with the unterlanguage. *It requiresan
ecumenism that doesn't exist for C. *Not sure why.
>
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?

Now that I think about it, the first reason for the lack of ecumenism is
history and the second is that there are dozens of competing
implementations of C while perl competes more convincingly for a
narrowslice, like sysadmins.

effectivly there is only one perl implementation


--