why still use C?

[Alan Connor]

Greetings to the group. I'm reading the FAQ and K&R and monitoring here,
trying to get a handle on the transition from shell programming to C.

From what I've read, I honestly don't see the need for anything BUT C
and the simple functionality of the high-level programming provided by
any decent shell. (Okay, a teeny weenie bit of assembly language too

Hope I am not out-of-line here.

By-the-way, is there anyplace I can get the entire FAQ as a tarball or
something?

 

[Mike Wahler]

Greetings to the group. I'm reading the FAQ and K&R and monitoring here,
trying to get a handle on the transition from shell programming to C.

From what I've read, I honestly don't see the need for anything BUT C
and the simple functionality of the high-level programming provided by
any decent shell. (Okay, a teeny weenie bit of assembly language too

Which language(s) you find useful will of course depend
upon the application domain(s). Certain languages are more
suited to particular tasks than others. If C, shell scripting
and assembly is all you need to get the job done, nothing
wrong with that.

Hope I am not out-of-line here.

By-the-way, is there anyplace I can get the entire FAQ as a tarball or
something?

The FAQ itself (at http://www.eskimo.com/~scs/C-faq/top.html)
has links to such. Scan the first few paragraphs for the
phrase "other versions".

HTH,
-Mike

 

[Alan Connor]

Which language(s) you find useful will of course depend
upon the application domain(s). Certain languages are more
suited to particular tasks than others. If C, shell scripting
and assembly is all you need to get the job done, nothing
wrong with that.


The FAQ itself (at http://www.eskimo.com/~scs/C-faq/top.html)
has links to such. Scan the first few paragraphs for the
phrase "other versions".

HTH,
-Mike

Thanks Mike. Don't know how I missed that. Got it now from the FTP site.

Long...Scary

Thanks to Steve Summit.

 

[Richard Heathfield]

From what I've read, I honestly don't see the need for anything BUT C

C is fine for all your programming needs (if you like C, that is!), right up
until you have to do something that doesn't work in much the same way on
all machines. At that point, you have to start using platform extensions.
But that's okay, because any platform extension worth its salt has C
bindings anyway.

 

[Richard Heathfield]

Santa Claus is a troll. Please ignore him.

I think I'll have to disagree with you there. My children have seen Santa
Claus on quite a few occasions (typically in fairytale grotto-like
surroundings), so I have good observational evidence w.r.t. Sant Claus (or
Father Christmas, as my children call him). My experts tell me that "he is
short and fat and jolly"; "he has a long white beard"; "he wears a big red
coat with gold buttons"; "he gives out presents"; "he has twinkly eyes",
and "he drives a very special sleigh with lots of reindeer"; "he has lots
of elves to help him". These are not characteristics typically associated
with trolls; trolls tend to be taller and more vicious, and somehow don't
manage to get quite the same twinkle into their eye.

Now if you'd said that ***E. Robert Tisdale*** is a troll, I think you'd
have been closer to the mark.

 

[Alan Connor]

C is fine for all your programming needs (if you like C, that is!), right up
until you have to do something that doesn't work in much the same way on
all machines. At that point, you have to start using platform extensions.
But that's okay, because any platform extension worth its salt has C
bindings anyway.

Good to know that. I aspire to a Linux distro that uses nothing but straight
ANSI C and shell scripts.

 

[Micah Cowan]

Good to know that. I aspire to a Linux distro that uses nothing but straight
ANSI C and shell scripts.

I don't believe it's possible to implement typical shells in
straight ANSI C without extensions, so this could be a
problematic goal.

-Micah

 

[James Antill]

Good to know that. I aspire to a Linux distro that uses nothing but straight
ANSI C and shell scripts.

Why shell scripts, just install tcc and you can just do...

#! /bin/tcc -run
#include <stdio.h>

int main(void)
{
puts("Hello World");
return 0;
}

....

 

[Alan Connor]

I don't believe it's possible to implement typical shells in
straight ANSI C without extensions, so this could be a
problematic goal.

-Micah

Most pipe dreams are "problematic"

I really don't know what you mean by "extensions", although I will read up
on it in the FAQ asap.

But modern shells have all sorts of features that I could do perfectly well
without, that used to be done with independent utilities.

 

[Alan Connor]

Why shell scripts, just install tcc and you can just do...

#! /bin/tcc -run
#include <stdio.h>

int main(void)
{
puts("Hello World");
return 0;
}

...

Err, I couldn't a reference to tcc in the FAQ, the index to K&R2, and there's
no man page for it on my box....Nor is it in my list of available Debian
packages....

And I can't get on the internet for a while, so I give....

(but If I am reading that script correctly, it sounds like a rather more
limited shell than I had on my mind....The original sh would probably do
the trick, maybe the updated version called ash, wihich is a FreeBSD project
if I remember correctly. Tomsrtbt uses it (entire os on a floppy) and it's
pretty good. Got read, set,if,for,until,while,case, commandline history and
completiion and so forth.)

-)

 

[Mike Wahler]

Most pipe dreams are "problematic"

I really don't know what you mean by "extensions", although I will read up
on it in the FAQ asap.

"Extensions" are additional nonstandard language constructs
(e.g. keywords, modified versions of standard functions, etc.)
which an implementation might provide for access to platform
specific feature of the host system. C can also be 'extended'
by supplying platform specific libraries with a C implementation,
e.g. the Windows API supplied with compilers for Windows.

-Mike

 

[Sidney Cadot]

E. Robert Tisdale wrote:

Santa Claus is a troll. Please ignore him.

I think I'll have to disagree with you there. My children have seen Santa
Claus on quite a few occasions (typically in fairytale grotto-like
surroundings), [...]

Well now, that's where they traditionally lurk, isn't it?

Regards, Sidney

 

[Alan Connor]

"Extensions" are additional nonstandard language constructs
(e.g. keywords, modified versions of standard functions, etc.)
which an implementation might provide for access to platform
specific feature of the host system. C can also be 'extended'
by supplying platform specific libraries with a C implementation,
e.g. the Windows API supplied with compilers for Windows.

-Mike

Doesn't sound like any sort of massive corruption of C to me.

Thanks much.

 

[gswork]

Greetings to the group. I'm reading the FAQ and K&R and monitoring here,
trying to get a handle on the transition from shell programming to C.

From what I've read, I honestly don't see the need for anything BUT C
and the simple functionality of the high-level programming provided by
any decent shell. (Okay, a teeny weenie bit of assembly language too

Hope I am not out-of-line here.

By-the-way, is there anyplace I can get the entire FAQ as a tarball or
something?

Sometimes i wonder if *nix programmers will ever use anything but c
and shell... (ah, of course they use other languages - but sometimes
it doesn't seemt that way).

You could use C for everything, but the context of the programmer &
the project changes so other languages are consider by some to better
able to express what is required.

An OOPL can be good at describing an application where object
taxonomies make sense, you may need a programmer time 'shortcut' to a
particular thing that general purpose languages would require more
time on, a typical LISP app perhaps, or want trustrable 'built in'
advanced features so as not to rely on re-inventing the wheel or
reusing third party libs - STL for instance. Some particular tools
(e.g. kylix/delphi) are good for more quickly desiging GUI apps. It
all crosses over, a given language's 'unique' qualities are rarely
that unique - you could probably get a shocking amount of versatility
from QuickBasic if you tried hard enough!

 

[Alan Connor]

Sometimes i wonder if *nix programmers will ever use anything but c
and shell... (ah, of course they use other languages - but sometimes
it doesn't seemt that way).

You could use C for everything, but the context of the programmer &
the project changes so other languages are consider by some to better
able to express what is required.

An OOPL can be good at describing an application where object
taxonomies make sense, you may need a programmer time 'shortcut' to a
particular thing that general purpose languages would require more
time on, a typical LISP app perhaps, or want trustrable 'built in'
advanced features so as not to rely on re-inventing the wheel or
reusing third party libs - STL for instance. Some particular tools
(e.g. kylix/delphi) are good for more quickly desiging GUI apps. It
all crosses over, a given language's 'unique' qualities are rarely
that unique - you could probably get a shocking amount of versatility
from QuickBasic if you tried hard enough!

Well. I think I actually followed most of that.

Just thought it would be cool if all the software on my computer was
in only two languages. Sort of like having the same keybindings on
every app.

As for the object-oriented languages, well, I'm not into the GUI at
all. Graphics yes. Eye-candy and plastic rodents, no.

This post ends with

:wq

 

[Mike Wahler]

Doesn't sound like any sort of massive corruption of C to me.

It's not. It cannot be, since it's not part of C. What Micah
is telling you is that some of what is needed in order to implement
a 'typical' shell is not available with only the standard C language,
thus 'extensions' are needed. "Extension" means "addition", not
"corruption".


-Mike

 

[Mike Wahler]

Well. I think I actually followed most of that.

Just thought it would be cool if all the software on my computer was
in only two languages.

All of it is in *one* language. The instruction set of the
processor (unless you have some weird multiprocessor machine
and one or more of the processors use(s) a different instruction
set from the other(s) )

Take away the source code for all the programs, and the software
is still there.

-Mike

 

[Dan Pop]

All of it is in *one* language. The instruction set of the
processor (unless you have some weird multiprocessor machine
and one or more of the processors use(s) a different instruction
set from the other(s) )

Take away the source code for all the programs, and the software
is still there.

That's valid for compiled languages only. Doesn't work for interpreted
languages, where you're left with nothing after removing the source code.

Dan

 

[Alan Connor]

All of it is in *one* language. The instruction set of the
processor (unless you have some weird multiprocessor machine
and one or more of the processors use(s) a different instruction
set from the other(s) )

Take away the source code for all the programs, and the software
is still there.

-Mike

I was speaking in practical terms. No one is going to be entering machine
language at the prompt to copy a file.

 

[Mike Wahler]

I was speaking in practical terms. No one is going to be entering machine
language at the prompt to copy a file.

First, a 'prompt' will not typically accept machine language,
but interpret mnemonic 'commands' which are submitted to and
acted upon by the provider of such a prompt (typically
an operating system).


Dan has already pointed out my oversight regarding interpreted
languages. But aside from that, I still stand by what I said.

I don't need to type in, e.g. printf("Hello") etc. to run a
compiled C program.

-Mike