C is fixed or not ?

[MikeP]

I hold no such opinion. The C standard library simply is.

.... is not a good top-level abstraction.

Well you wouldn't get very far if you did. Part of the attraction of
scripting languages and that abomination called Java is their
continuously evolving, often huge, cross-platform libraries.


Ah, so you don't always roll your own?

It's a work in progress. "Any day now" I'll be able to jettison that one
again, but for now I am using it (again).
I used to have my own text windows to output to but then I decided to
rework everything yet again so printf is again something I am using until
all the code is brought back in, but for development only, not in
prodution code.

Hint: you probably won't find one.

Java is a platform. Could say that about PHP too. I don't know about
Python, as that sounds like it has more GP language goals (?).

 

[Ian Collins]

It's a work in progress. "Any day now" I'll be able to jettison that one
again, but for now I am using it (again).
I used to have my own text windows to output to but then I decided to
rework everything yet again so printf is again something I am using until
all the code is brought back in, but for development only, not in
prodution code.

Lucky you, I wish I had the time to reinvent wheels.

 

[MikeP]

Lucky you, I wish I had the time to reinvent wheels.

For me it's a necessity, for where I'm traveling-to and what I'm
traveling-in requires round, not square, wheels. It will not require jet
engines though, that's a relief, because planes are scary.

 

[Dr Nick]

... is not a good top-level abstraction.

It's not bad. I've managed to use it to write perfectly functional C on
(at least - I'm almost certainly forgetting some): CP/CMS, MVS, VMS,
QDOS, SMS/2, Linux and a custom OS.

That's the whole idea of an abstraction. I would not like to have had
to learn the underlying OS calls for each of these, cope with the
complexities of the file systems, and then written my own code.
Particularly when I then had to move programs from one to the other of
these.

 

[Dr Nick]

Nick Keighley wrote:
Well that's the THEORY behind programming language standard
libraries,

there is nothing as practical as a good theory.

LOL. You surely meant to say: there's nothing practical about theory!

Right, because if anyone states an opinion contrary to yours, it could
only have been a typo.

[...]

Lighten up dude, I was making a joke!

If everything you say that is rubbish is a joke, could you start saying
serious things please?

 

[MikeP]

It's not bad. I've managed to use it to write perfectly functional C
on (at least - I'm almost certainly forgetting some): CP/CMS, MVS,
VMS, QDOS, SMS/2, Linux and a custom OS.

That's the whole idea of an abstraction. I would not like to have had
to learn the underlying OS calls for each of these, cope with the
complexities of the file systems, and then written my own code.
Particularly when I then had to move programs from one to the other of
these.

Yeah, if you like the C API, that works. You could have been using
something nicer (assuming you are a good library designer) and evolving
though if you would have considered C just another platform. But then
again, if you only have C to work with, "nice" doesn't belong in the same
dialog. Move up a notch to C++ though, and you can create almost anything
and with some elegance too. (Preaching to the choir, surely).

 

[Dr Nick]

Yeah, if you like the C API, that works.

It's nothing to do with "liking" it, and it's not "that works". It's
"that's all there is to it".

You could have been using something nicer (assuming you are a good
library designer) and evolving though if you would have considered C
just another platform. But then again, if you only have C to work
with, "nice" doesn't belong in the same dialog.

No, I couldn't have "been using something nicer" (whatever that looks
like - any suggestions for a library that is "nicer" and works on all
the above OSs". I'd never have managed to write the code in the time
available (and this is nothing to do with bad planning - sometimes there
are external factors that mean that there was no need for some software
yesterday and there is /now/) if I'd had to start on the raw application
layer and build my own "nicer" library. I'm not even sure I had
documentation or appropriate header files for the native interface.

Some of that, as implied, was for myself. Some was for employers, so
migrating the library backwards and forwards would have been
problematical to say the least.

Move up a notch to C++
though, and you can create almost anything and with some elegance
too. (Preaching to the choir, surely).

So in one breath you are suggesting I cut out a huge chunk of the power
of C, and in the other you're suggesting I move to something much more
powerful. Most odd if you don't mind me saying so.

 

[Dr Nick]

Keith Thompson wrote:
Nick Keighley wrote:
[...]
Well that's the THEORY behind programming language standard
libraries,

there is nothing as practical as a good theory.

LOL. You surely meant to say: there's nothing practical about
theory!

Right, because if anyone states an opinion contrary to yours, it
could only have been a typo.

[...]

Lighten up dude, I was making a joke!

If everything you say that is rubbish is a joke, could you start
saying serious things please?

I don't understand what you mean.

No.

 

[Dr Nick]

It's nothing to do with "liking" it, and it's not "that works". It's
"that's all there is to it".

Sorry - some editing errors crept in there. Try this version:

 

[MikeP]

It's nothing to do with "liking" it, and it's not "that works". It's
"that's all there is to it".

Yeah, if "all you have is a hammer..".

No, I couldn't have "been using something nicer" (whatever that looks
like - any suggestions for a library that is "nicer" and works on all
the above OSs". I'd never have managed to write the code in the time
available
(and this is nothing to do with bad planning - sometimes
there are external factors that mean that there was no need for some
software yesterday and there is /now/) if I'd had to start on the raw
application layer and build my own "nicer" library. I'm not even
sure I had documentation or appropriate header files for the native
interface.

It would have gotten easier at every iteration though. And remember, the
"C API" is a target for the higher-level API also, so it could have been
used incrementally and evolved until it subsumed the "C API".

Some of that, as implied, was for myself. Some was for employers, so
migrating the library backwards and forwards would have been
problematical to say the least.


So in one breath you are suggesting I cut out a huge chunk of the
power of C, and in the other you're suggesting I move to something
much more powerful. Most odd if you don't mind me saying so.

I'm not making any suggestions to you. I was just thinking out loud. I
don't care much how other people do things though I am curious about why
sometimes.

 

[Dr Nick]

Yeah, if "all you have is a hammer..".

It's not that at all. In this case it's "I've got a hammer, and I have
a nail to hammer in - the horse is waiting outside. I'm not going to
fire up the blast furnace and start refining some iron ore to forge a
new hammer from".

It would have gotten easier at every iteration though. And remember, the
"C API" is a target for the higher-level API also, so it could have been
used incrementally and evolved until it subsumed the "C API".

First time you've told me that this is a layer on top of stdio. Up to
now you've been saying "replace". Now you're layering on top. That's
another thing entirely and, from my source repository I give you:

struct filepointer {
enum file_type type;
enum file_mode mode;
enum file_method method;
union {
FILE *fp; // it might be a stream (types text, format, program)
socket_handle sock; // or a socket (socket)
struct plotter *plotp; // or a plotter channel (plotter)
database *dbp; // or a database (database)
struct sql_database *sqlp; // perhaps an SQL one
struct variable_stream *var; // or a variable (variable)
} u;
struct filepointer *incfile; // files can nest
};

I won't include all the others here, but I'll note that sql_database is
in turn a union of mysql and sqlite types. Database is the old db3
type.

Note that I *haven't* got the underlying Unix file in there, it's still
FILE.

If it's not going to do this, it's not going to get any easier in
detail. I haven't a clue what the interface to PDS on MVS looks like
but it's going to be pretty messy. I strongly suspect I'd end up
parsing strings for dots and brackets for a start.

I'm not making any suggestions to you. I was just thinking out loud. I
don't care much how other people do things though I am curious about why
sometimes.

OK. Please think out loud to tell us what you would put in a library
that would handle files, in C, that interfaces with operating systems
with traditional directories, with PDS, with version numbering and with
flat file systems, that is sufficiently "nicer" than the existing C
library that the time spent working on it rather than on something else
would repay the effort.

 

[Kenny McCormack]

Right, because if anyone states an opinion contrary to yours, it could
only have been a typo.

That's rich - coming from you.

In your case, anyone who disagrees with you is automatically a "troll".

 

[Ben Bacarisse]

E.g. (what I was getting at): Unix has 'fopen', Windows has
'CreateFile'.

That may be an example of what you are getting at, but it is not an
example of what you said. If I counter with the true by unhelpful
statement that "Windows has fopen and Unix has open and creat" you
(presumably) will be able to refute the conclusion that fopen is part of
the Windows API. Swap that argument around and I believe you'll have a
valid refutation of your claim about the "Unix API". (I have to use
quotes because it's a bit vague and it may be in that vagueness that the
confusion lies. To me, the "Unix API" is the system call interface --
the one thing that all programs will eventually have to use to access
and manipulate system resources.)

Not really (not that I don't or do agree with that). Standard libraries
of programming languages notoriously suck. One is faced with that "holy
portability" (and "performance trumps elegance") thing even when one need
not be. That's fine if you need it, but if you don't, you don't. Not that
platform-provided libraries are a panacea, but that I'd rather build
something on top of that than on top of language-provided libraries
because I feel that language-provided libraries are not adequate as the
top-level of abstraction and if I have to build something on top of
something anyway, I prefer to build on top of the platform API. YMMV: I'm
not trying to persuade anyone to use my methods.

Does your interface/library/whatever not suck then? If you think it is
better than what programming languages currently do with their standard
libraries, the world needs to see it! If it is only better for one or
two programs (because it's tailored) and you re-write it for others,
then I think there is a valid technical objection to your methods: by
not abstracting you are wasting effort.

I acknowledge that there is another possibility. What you build on top
of the native OS might be a higher-level abstraction but so system
specific that there is no benefit to publishing it. That's possible but
I am having trouble imaging how that could be.

<snip>

 

[MikeP]

It's not that at all. In this case it's "I've got a hammer, and I
have
a nail to hammer in - the horse is waiting outside. I'm not going to
fire up the blast furnace and start refining some iron ore to forge a
new hammer from".

Funny thing, metaphor-wars are, huh.

First time you've told me that this is a layer on top of stdio.

It's "neither here nor there". I threw it out there as an option. I may
develop my library to stand beside the ISO library and you may develop
yours to sit on top of it. There is no one best way to do it all the
time. Way too much emphasis by programmers is put on, "well, someday I
may want to deploy on... therefore, THE standard library is the best
choice". There's usually enough stuff to worry about without bringing in
POTENTIAL stuff to worry about.

Up to
now you've been saying "replace".

I don't think so. Surely I've been saying "in alternative to".

Now you're layering on top.

Nope. YOU may have wanted to though, but I'm not sure that doing so
wouldn't have compromised the design. I may want to target, e.g., 2
platforms, Windows and Unix, and create a framework that talks to those
platforms' system-level APIs and ignore ISO std lib entirely.

OK. Please think out loud to tell us what you would put in a library
that would handle files, in C, that interfaces with operating systems
with traditional directories, with PDS, with version numbering and
with
flat file systems, that is sufficiently "nicer" than the existing C
library that the time spent working on it rather than on something
else
would repay the effort.

That is but one set of requirements, surely contrived to "show" that the
ISO standard library is "best". Some do argue that the ISO standard
library, is best everywhere and all of the time, when that is, of course,
either naivete or BS.

 

[MikeP]

That may be an example of what you are getting at, but it is not an
example of what you said.

Language is paltry for communication on the quick. Text even moreso. But
you will soon enough get my drift after a few posts. The logic is
consistent. I did know before I posted that there was something below
fopen on Unix but was too lazy to look it up. I wasn't diligent in
presenting my position. Of course I'm sure there are a few (if not more)
that just lurk here for the "opportunity" to render someone a total waste
of life the second that someone appears to be less than a total bit head.

If I counter

I wasn't debating though, really. I know y'all do that ("my language is
better than your language... I'm a better programmer than you are.. na
na!"), but I'm not part of any group that that does that.

with the true by unhelpful
statement that "Windows has fopen and Unix has open and creat" you
(presumably) will be able to refute the conclusion that fopen is part
of the Windows API. Swap that argument

What "argument"? I'm not arguing. Are you? What about?

around and I believe you'll
have a valid refutation of your claim about the "Unix API".

Oh, THAT one (NOW I remember where this started! I could've had a V8!).
To ME, then maybe, it is the Unix API. Does the std lib not like its
lineage? Hmm. You know that my feel for it is correct, admit it. Do you
think I'm "knocking it" and is it dear to you and you feel the need to
defend it?

(I have
to use quotes because it's a bit vague and it may be in that
vagueness that the confusion lies. To me, the "Unix API" is the
system call interface

Surely that is the "correct" technical answer, but there is more to
things than just "correct technical answers". Ya think?

-- the one thing that all programs will
eventually have to use to access and manipulate system resources.)


Does your interface/library/whatever not suck then?

Why would I make a sucky one?

If you think it
is better than what programming languages currently do with their
standard libraries, the world needs to see it!

Well it's quite a leap from "one man show library" to "mass consumption".
(And I'm not saying whether I'm doing that or have done that or will be
doing that, but just to respond to your very valid inquiry).

If it is only better
for one or two programs (because it's tailored) and you re-write it
for others, then I think there is a valid technical objection to your
methods: by not abstracting you are wasting effort.

See, there is no "enlightening" you guys! You keep doing it like you
always have and everyone before you has and someone somewhere in the
world WONDERS why there is no progress or why it is sooooo slooooow in
coming.

I acknowledge that there is another possibility.

Just one?

What you build on
top of the native OS might be a higher-level abstraction but so system
specific that there is no benefit to publishing it.

That's not true, of course, even if it is just one system. Actually, it's
probably a good scenario for doing such (have you looked at the .Net file
API lately? It's horrendous!).

That's possible
but I am having trouble imaging how that could be.

Look at the .Net file API and please give me your critique of it. I'd be
very interested in knowing that, but not here, because if MS wants
consulting, they should have to PAY for it! (My email available upon
request).

 

[MikeP]

In theory, there's no difference between theory and practice but in
practice, there often is.

Yes, surely I was quipping about that. Who said that? I think you just
admonished me Mr. Jones. TY. Eh em.. uh, you were saying Nick? Cat got
your tongue? (hehehe). Just kiddin' ya Joe.

 

[Ben Bacarisse]

Language is paltry for communication on the quick. Text even moreso.

Then take your time. If you don't have time to express what you want to
say, you could prefix your post with something like "Don't spend much of
your time trying to understand this -- I spent very time writing it".

But
you will soon enough get my drift after a few posts. The logic is
consistent. I did know before I posted that there was something below
fopen on Unix but was too lazy to look it up. I wasn't diligent in
presenting my position. Of course I'm sure there are a few (if not more)
that just lurk here for the "opportunity" to render someone a total waste
of life the second that someone appears to be less than a total bit
head.

But after all these posts I still don't know what your drift is.

I wasn't debating though, really. I know y'all do that ("my language is
better than your language... I'm a better programmer than you are.. na
na!"), but I'm not part of any group that that does that.

Call it what you like, but if you try to express an opinion in a public
forum other people may well express different options or they may offer
opinions about your options. You don't have to think of that as a
debate if you don't like the term, but that's what's happening here.

What "argument"? I'm not arguing. Are you? What about?

Yes, I am. I am arguing about whether the "C std library is [...] the
Unix API". Feel free not to express any more opinions on the matter,
but if you do I will probably conclude that we are having a "debate"
about it even if you don't ever do that.

Oh, THAT one (NOW I remember where this started! I could've had a V8!).
To ME, then maybe, it is the Unix API. Does the std lib not like its
lineage? Hmm. You know that my feel for it is correct, admit it. Do you
think I'm "knocking it" and is it dear to you and you feel the need to
defend it?

No. I wanted to correct a detail. I was also interesting in what you
would do instead since you dismissed the whole idea of language
libraries. I really would like to know what should be done instead.

Surely that is the "correct" technical answer, but there is more to
things than just "correct technical answers". Ya think?

Yes, a lot more. But do you object to correct technical answers? I
think there are a good place to start in technical news groups.

Why would I make a sucky one?


Well it's quite a leap from "one man show library" to "mass consumption".
(And I'm not saying whether I'm doing that or have done that or will be
doing that, but just to respond to your very valid inquiry).

So "standard libraries [...] suck" (which must include C's) and by
implication from the answer before this one yours does (in your option)
not suck. Is it not selfish not share at least the API? Even if you
plan to keep it proprietary, getting the interface out there can only
help.

For one thing it would do away with all the hypothetical questions that
I posed ("if it's this... if it's that...") which I've now snipped.
We'd see what it is and not have to speculate. For another thing, I'd
probably get your drift at last -- I'd see if you favour system
specifics over portability, or convenience over efficiency and so on.

May request is not some sarcastic "show us so we can mock" request. The
C library is so full of historical curiosities and idiosyncratic choices
that I can easily image that you have something better -- I've just been
too lazy to try to bring it all together into something new.

<snip>

 

[Nick Keighley]

LOL. You surely meant to say: there's nothing practical about theory!

no. I meant exactly what I said. I find it odd that people scorn
theory. It's our guide to the world.


you missed my point. If Unix can be programmed in C because it was
implemented in C (a dumb argument in the first place) why shouldn't
Windows be oprogrammed in C?

That was a loooong time ago. It's changing. It doesn't take much
imagination to see the trends.

so enlighten us. Is it all going to be programmed in .Net?

 

[Nick Keighley]

Yes, surely I was quipping about that. Who said that? I think you just
admonished me Mr. Jones. TY. Eh em.. uh, you were saying Nick? Cat got
your tongue? (hehehe).

I don't get on here as often as a I used to

Just kiddin' ya Joe.

my name isn't Joe

 

[MikeP]

Then take your time. If you don't have time to express what you want
to say, you could prefix your post with something like "Don't spend
much of your time trying to understand this -- I spent very time
writing it".

Or maybe you should get the **** out of my face?

But after all these posts I still don't know what your drift is.

Maybe I don't have one of those. Maybe I'm "a troll". Or maybe just a
good one. Who's to say

<

Call it what you like, but if you try to express an opinion in a
public forum other people may well express different options or they
may offer opinions about your options. You don't have to think of
that as a debate if you don't like the term, but that's what's
happening here.

But I wasn't doing that. I'm not you. I don't do that.[do I]

What "argument"? I'm not arguing. Are you? What about?

Yes, I am. I am arguing about whether the "C std library is [...] the
Unix API".

That is not an argument to me. I am not arguing. Shut up, I know what
Unix is.Are you testing me

Feel free

Now you're talkin. The keyword is 'feel'. Huh.

not to express any more opinions on the matter,
but if you do I will probably conclude that we are having a "debate"
about it even if you don't ever do that.

What matter

No. I wanted to correct a detail. I was also interesting in what you
would do instead since you dismissed the whole idea of language
libraries. I really would like to know what should be done instead.

I probably did do that. It was not intentional. I fucked up, surely.

Yes, a lot more.

You don't know that though.

But do you object to correct technical answers?

You posed an oxymoron. There is no question there.

I
think there are a good place to start in technical news groups.

I dunno. You said "get your feet wet in ".. stepped in what

Why would I make a sucky one?


Well it's quite a leap from "one man show library" to "mass
consumption". (And I'm not saying whether I'm doing that or have
done that or will be doing that, but just to respond to your very
valid inquiry).

So "standard libraries [...] suck" (which must include C's)

Well it is the epitome of suckiness of course.

and by
implication from the answer before this one yours does (in your
option) not suck. Is it not selfish not share at least the API?
Even if you plan to keep it proprietary, getting the interface out
there can only help.

I don't think it has worked for you. It hasn't worked for me. Why
wouldn't I curse it

For one thing it would do away with all the hypothetical questions
that I posed ("if it's this... if it's that...")

I did not recognize any hypotheticality in you post, and I quite liked
it.

which I've now
snipped. We'd see what it is and not have to speculate.

Well, see, that is not speculative at all. It is hopeful. Did I misread
that


[question marks and parens don't work on this computer.. fill in the
blanks]

For another
thing, I'd probably get your drift at last -- I'd see if you favour
system specifics over portability, or convenience over efficiency and
so on.

Not necessarily.

May request is not some sarcastic "show us so we can mock" request.
The C library is so full of historical curiosities and idiosyncratic
choices that I can easily image that you have something better --

Another keen observation. In a lot of my posts I have to Tango.

I've just been too lazy to try to bring it all together into
something new.

Is that the rub