 news.only-4-geeks.com Forum Index » C | Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 Next |
|  | UNIX, C, Perl | | |
| | | Pilcrow |  |
|  Posted: Tue Sep 02, 2008 9:48 am Post subject: UNIX, C, Perl |  |
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? |
| |
| | | James Kuyper | |
| | Posted: Tue Sep 02, 2008 10:04 am Post subject: Re: UNIX, C, Perl | |
| |  | |
Pilcrow wrote:
| Quote: | 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.
| Quote: | ... 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.
| Quote: | 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.
| Quote: | ... 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. |
| |
| | | Eric Sosman | |
| | Posted: Tue Sep 02, 2008 10:15 am Post subject: Re: UNIX, C, Perl | |
Pilcrow wrote:
| Quote: | 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 |
| |
| | | Bill Reid | |
| | Posted: Tue Sep 02, 2008 12:18 pm Post subject: Re: UNIX, C, Perl | |
Eric Sosman <esosman@ieee-dot-org.invalid> wrote in message
news:2uadnYbBJKv5syDVnZ2dnUVZ_oTinZ2d@comcast.com...
| Quote: | 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?
|
Sun Microsystems: "YOU BETCHA!!!"
Java, the Esperanto of computer programming languages...
---
William Ernest Reid |
| |
| | | Bill Reid | |
| | Posted: Tue Sep 02, 2008 12:18 pm Post subject: Re: UNIX, C, Perl | |
| | | |
Pilcrow <pilcrow@pp.info> wrote in message
news:11aqb4dfqm5k92um5taqs2dcm942g2rmtu@4ax.com...
| Quote: | 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 |
| |
| | | Keith Thompson | |
| | Posted: Tue Sep 02, 2008 3:13 pm Post subject: Re: UNIX, C, Perl | |
| | | |
Pilcrow <pilcrow@pp.info> writes:
| Quote: | 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" |
| |
| | | Pilcrow | |
| | Posted: Tue Sep 02, 2008 3:50 pm Post subject: Re: UNIX, C, Perl | |
| | | |
On Tue, 02 Sep 2008 12:04:38 GMT, James Kuyper <jameskuyper@verizon.net>
wrote:
| Quote: | 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.
|
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. |
| |
| | | Guest | |
| | Posted: Tue Sep 02, 2008 4:06 pm Post subject: Re: UNIX, C, Perl | |
Bill Reid wrote:
....
| Quote: | 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. |
| |
| | | Antoninus Twink | |
| | Posted: Tue Sep 02, 2008 4:43 pm Post subject: Re: UNIX, C, Perl | |
On 2 Sep 2008 at 11:48, Pilcrow wrote:
| Quote: | 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. |
| |
| | | Eric Sosman | |
| | Posted: Tue Sep 02, 2008 4:54 pm Post subject: Re: UNIX, C, Perl | |
| | | |
Pilcrow wrote:
| Quote: | [...] 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
LINK I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
LINK 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.
| Quote: | 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.
| Quote: | 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:
LINK
LINK
You'll notice that they differ mostly in degree.
--
Eric.Sosman@sun.com |
| |
| Page 1 of 24 .:. Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 Next | |
|
|
