C as a scripting language

[James Kuyper]

Keith Thompson wrote: ....

Always bear in mind that this discussion is for and on c.l.c. As I
read your suggestions, you seem to believe that any programmer,
when handed some code to modify/use/etc., should read it in its
entirety, identify anything not guaranteed by the C standard, and
verify its action on the system in question.

He neither said nor even implied anything of the kind.

No, it's not always necessary to read and understand an entire program
in order to make a small change. Well-designed code allows sufficiently
minor maintenance work to be performed without having to read and
understand the entire program, just the part being modified. Of course,
if this happens too often, it ceases to be well-designed code.

No, it's not always necessary to verify its action on the system in
question. It should be possible to determine what the requirements are
for the degree of portability the code should achieve. Those
requirements might, for example, state that it need only work on one
specific machine; they might say that they have to work on any platform
supporting a particular OS, or they might say it must work on any
conforming implementation of C90. Ideally, there's a requirements
document that specifies this. The programmer need only confirm that the
code meets whatever the requirements are (and bring it to the attention
of the person responsible for the requirements if they seem unreasonable).

For example, if a particular piece of code is, as a matter of deliberate
design, intended only for use on Windows, there's nothing wrong with it
containing features that are not guaranteed to work by the C standard,
as long as they are guaranteed to work by the relevant Windows authority
(whatever that might be).

Such Windows-specific software is off-topic in this newsgroup, but just
because it only works on Windows platforms does not justify lying about
what's wrong with mentioning it, by claiming that it does not work.

... I maintain this is
ridiculous, not to mention time consuming. If code is not
guaranteed to work I maintain that assuming it will not work is the
safe technique, and reorganizing it so it will always work (if
possible) prevents any future problems. The first step in this
process is recognizing that the code is not guaranteed.

Just because the C standard doesn't guarantee that the code will work
does not mean that the code is not guaranteed to work. Almost any
real-world program relies on some combination of the C standard and some
other authorities to guarantee that it will work, and for that reason,
it is guaranteed to work only in the joint domain where all of the
relevant authorities are authoritative. Claiming that such code "won't
work" is just plain false; it will work in that domain, and might or
might not work outside of it. A flat statement of "won't work" is
incompatible with that fact.

 

[wolfgang.riedel52]

Keith Thompson wrote:

Obviously I am using
lcc-win Unix ****
cc-win

***
an obvious naming strategy!
is there any chance, we see a lcc-win for zOS?
Wolfgang

 

[CBFalconer]

.... snip ...

Just because the C standard doesn't guarantee that the code will
work does not mean that the code is not guaranteed to work.
Almost any real-world program relies on some combination of the
C standard and some other authorities to guarantee that it will
work, and for that reason, it is guaranteed to work only in the
joint domain where all of the relevant authorities are
authoritative. Claiming that such code "won't work" is just
plain false; it will work in that domain, and might or might not
work outside of it. A flat statement of "won't work" is
incompatible with that fact.

I'm going to abandon this thread, since I don't seem to be
convincing anybody. Remember that this is c.l.c, and things are
not topical if system dependant. In that environment, to me,
system dependant routines are not usable. The only guarantor we
have is the C standard.

 

[Keith Thompson]

I'm going to abandon this thread, since I don't seem to be
convincing anybody. Remember that this is c.l.c, and things are
not topical if system dependant. In that environment, to me,
system dependant routines are not usable. The only guarantor we
have is the C standard.

No, you're not convincing anybody. You refuse to acknowledge that a
off-topic statement isn't necessarily an incorrect statement. You use
"off-topic" as a universal term of badness, and assume that all other
forms of badness are equivalent to it.

The C standard specifically allows for language extensions and
non-portable code. Trying to be more strict than the standard itself
is absurd.

I'm done here, at least until you pull the same stunt again in another
thread.

 

[James Kuyper]

CBFalconer wrote:
....

convincing anybody. Remember that this is c.l.c, and things are
not topical if system dependant. In that environment, to me,
system dependant routines are not usable.

That's where the problem lies. In reality, system dependent routines are
perfectly usable, on those systems; they're just off-topic in this
newsgroup. They don't become any less usable just because they're
off-topic, and statements that they can't be used are just plain false.
Such statements don't convince anybody of anything except that you don't
seem to know what you are talking about. I think you do know what you're
talking about in this regard, but have some issue that prevents you from
using the correct words to describe it.

 

[Richard Bos]

Unix knows how to do windows, and NO it doiesn't need wine!
Compiling when drunk is not recommended!

I thought you were French? Surely then you should know better than to
imply that all use of wine results in drunkenness. After all, you're not
a bleedin' Rosbif, who, once they've started on the booze, are incapable
of stopping until they're completely plastered and start breaking down
Sheffield city centre.

(Besides, coding while inebriated is, IME, not the problem. Debugging
while hung over is much worse...)

Richard

 

[Guest]

It's not surprising that C can be used for any task.

But the point of scripting languages is to accomplish a task more quickly
and less painfully than using C, where everything has to be just right,
especially the punctuation. And without bothering with compile-link-run as
much.

and in which script langauge don't you have to "get everything just
right"?
"especially the punctuation"! Most script languages seem just as picky
as C about their syntax. And some of them are a complete dog's
breakfast
of clashing syntaxi (that's the plural of syntax, yes?).

And without bothering with compile-link-run as much.

ok, on that bit


<snip>

 

[vippstar]

and in which script langauge don't you have to "get everything just
right"?
<snip>

HTML!

 

[Bartc]

and in which script langauge don't you have to "get everything just
right"?
"especially the punctuation"! Most script languages seem just as picky
as C about their syntax. And some of them are a complete dog's
breakfast
of clashing syntaxi (that's the plural of syntax, yes?).

I had one of my languages in mind. It just doesn't need as much punctuation
as C, which requires semicolons, #, () around conditionals, () around printf
calls (instead of print being a statement), all that fiddly stuff inside
format strings, () for function calls with empty params, () around
for-statement specifiers, {} around compound statements.

Plus no need for include files (and <...> brackets) for built-in stuff, or a
formal main() function.

And, being dynamically typed, no need to specify the exact type, width and
size of every variable, or even to declare them at all.

So while what there is, needs to be correct, there's not so much of it! And
with an instant edit-run cycle, and being much more fault-tolerant, you can
program in a much more informal manner.

Probably you're thinking of Perl...