Why do you like C more than other programming languages?

C

Chris H

In message
At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process

Portability may not be an issue. A lot of libraries are portable.
 
S

santosh

Richard said:
rahul said:


No, the portability loss is inherent in the nature of those tasks.

Not if the language happened to provide procedures to accomplish them
across all it's supported environments. Of course, in that case, one is
likely to find that the number of supported environments is adversely
affected.

But IMHO portability is more a context dependant property than something
defined independently and absolutely. If a project is *meant* for just
N platforms and if language A supports all those *and* happens to
portably provide more facilities than language B, which however
supports more than N platforms, then, IMO, language A is
more "portable" than language B for this particular project.

Lots of similar "fuzzy" logic is possible, which computers struggle
with, but humans excel in. :)

This is why so many languages exist, despite the consternation of the
OP.

<snip>
 
A

Antoninus Twink

rahul said:

No, the portability loss is inherent in the nature of those tasks.

That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.
 
W

Walter Roberson

That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.

Rubbish. GTK cannot possibly support graphics, networking
and threading *completely* portably in C because all three of them
are hardware-dependant; GTK can at best support them on a "wide
variety" of platforms that it happens to have been implemented on.

For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?
 
D

dj3vande

santosh said:
But IMHO portability is more a context dependant property than something
defined independently and absolutely. If a project is *meant* for just
N platforms and if language A supports all those *and* happens to
portably provide more facilities than language B, which however
supports more than N platforms, then, IMO, language A is
more "portable" than language B for this particular project.

Not "more portable". *As* portable[1], and more useful. (At least
until somebody decides they want the project to support a platform that
doesn't have an implementation of language A.)


dave

[1] Actually, not quite even that. B is still more portable, but not
usefully so in this case. "Equivalently meets the relevant
portability constraints" is kind of a mouthful, but I think it's
what you really want to say here.

--
Dave Vandervies dj3vande at eskimo dot com
EMACS. The editor that OS's are jealous of.
I thought it was the OS that editors were jealous of.
--Curt Schemmel and Dann Corbit in comp.lang.c
 
A

Antoninus Twink

It's rather sad to see (in the text you quote) that there has been no
improvement in the accuracy of the articles posted by our resident
buffoons. But then, what did we expect? Some people can't be taught.

Yes Heathfield, carry on living in your dream-world, and I'll carry on
promoting common-sense practicality in this group.

GTK is 100% supported on all Unices, MS Windows and Mac OS X. It's also
widely supported on embedded platforms. That sounds pretty damned
portable to me. Of course, I guess there isn't a version yet for you and
your "friends"' DeathStations, but really, who cares?
 
B

Bartc

Walter Roberson said:
Rubbish. GTK cannot possibly support graphics, networking
and threading *completely* portably in C because all three of them
are hardware-dependant; GTK can at best support them on a "wide
variety" of platforms that it happens to have been implemented on.

What's the difference between a portable C program that needs a C
implementation for each platform it runs on, and, say, GTK which also needs
an implementation for each platform it runs on?
For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

Graphics on a text terminal is going to be difficult, not only with GTK.
 
R

robertwessel2

Exactly.
C# would not work, neither would .net. They all use at the end
the windows API.


Why? The new system would just need a version of the .NET runtime
that called whatever system API that was actually there. Think about
Mono, for example, it will run most C# programs (ignoring library
issues) just fine on *nix, with no Windows API in sight. Obvious
exceptions include .NET programs that directly call the Windows API.

OTOH, I agree that it's pretty unlikely that the Windows API is going
to go away any time soon. The MS-DOS API (aka Int 21h) survived the
introduction of the Windows API by better than two decades, and the
Win16 API survived the introduction of Win32 by something like 15
years. Although both are now going away. As for desktop/server OSs,
neither is available on any 64 bit version of Windows (although both
were supported on all 32 bit Oss, including the non-x86 ones, at least
until now). Nor are the DOS or Win16 APIs supported on any version of
Windows CE.

So the Win32 and Win64 APIs will certainly survive in the short/medium
term. But 15 or 20 years from now? Who knows.
 
D

dj3vande

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them.
[...]
Is it because C was my first programming language?

No. It's probably because you are, despite what you might tell yourself,
probably looking to criticise.

I disagree.
If C is the OP's first language and he hasn't learned to use a second
one well, he's probably judging languages by their resemblance to C;
this indicates a limited view that it would be good to get out of, but
it's a bit of a stretch to go from there to "looking to criticise".

There are languages that actually *are* inferior and not just
different, though. If the OP manages to get good at something like
Scheme or Erlang, or Forth, or Smalltalk, and then comes back to C++ or
Java and still hates them, then that criticism will be easier to take
seriously (even though it will probably still say more about the source
of the criticism than the target).


(Moderately amusing aside: The first three or four times I picked up a
project thinking it would use enough C++ features that C didn't have to
provide an excuse to learn C++, I ended up getting frustrated with the
additional complexity of C++ and learning how to make C do what I
thought I wanted C++ for.)


dave

--
Dave Vandervies dj3vande at eskimo dot com
EMACS. The editor that OS's are jealous of.
I thought it was the OS that editors were jealous of.
--Curt Schemmel and Dann Corbit in comp.lang.c
 
R

Richard Tobin

Walter Roberson said:
For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

I don't know, but the aalib library allows the display of graphics
using "ascii art", rather in the style of those 1970s line printer
pictures. I have watched part of Blade Runner rendered with this
library, and it's remarkable to say the least.

-- Richard
 
I

Ian Collins

OTOH, I agree that it's pretty unlikely that the Windows API is going
to go away any time soon. The MS-DOS API (aka Int 21h) survived the
introduction of the Windows API by better than two decades, and the
Win16 API survived the introduction of Win32 by something like 15
years. Although both are now going away. As for desktop/server OSs,
neither is available on any 64 bit version of Windows (although both
were supported on all 32 bit Oss, including the non-x86 ones, at least
until now). Nor are the DOS or Win16 APIs supported on any version of
Windows CE.
Boy I'm gad I only use POSIX systems!
 
I

Ian Collins

Richard said:
Bartc said:

Platforms for which a C implementation does not exist are very rare.
Platforms for which a GTK implementation does not exist are not so rare.
But platforms capable of supporting GTK without an implementation are
less rare. One could argue the same point with sockets, platforms that
support IP and don't use the BSD socket interface are pretty scarce.
Yeah, that's kinda the point - hardware features are inherently
non-portable, which is why GTK does *not* give you the magical ability to
do graphical stuff completely portably in C.
I guess we have to find a way to define portability in terms of
platforms that support a feature.
 
S

soscpd

Hello List

Why do you like C more than other programming languages?

I don't. I just like to use the right tool (one can argue here) to get
the job done.
So... where/when use C? Most likely (to me) when you need to build the
tool. To work with development, you can only use C where only c fit.
In this same place (the world), just the standard have not much to do.

Regards
Rafael
 
R

rahul

No, the portability loss is inherent in the nature of those tasks.
But had networking and other libraries been standardized for C, it
would have remained same across platforms. The changes will be there
in implementation of libraries on various platforms but source code
portability will still be there.

Regarding nature of the tasks, even addition of two numbers is not a
portable tasks on two platforms depending upon the opcode to be
generated, format of the executable, width of the data bus, width of
the address bus, representation (big, small-endian or the middle one
you mentioned) etc. But the underlying implementation takes care of it
so we call it portable. The same could have been done for the tasks
you were saying are inherently non-portable. In fact, Java and ports
of perl, python etc do that.
 
S

santosh

rahul said:
But had networking and other libraries been standardized for C, it
would have remained same across platforms.

Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).

If the C Standard codified interfaces for networking or graphics they
would either have to be left out on implementations targetting these
platforms (thus non-confirming), or create stubs and no-ops for these
routines. Both will break source code portability.
The changes will be there
in implementation of libraries on various platforms but source code
portability will still be there.

Not on all platforms that C intends to target. C (at least as the ISO
Committee envisage) aspires for "maximal" portability, which
essentially means that the language be kept small and easily
implementable, so that compilers can be quickly created for new
systems. If it were to be as ambitious as say C++ or Java, this would
not be possible.
Regarding nature of the tasks, even addition of two numbers is not a
portable tasks on two platforms depending upon the opcode to be
generated, format of the executable, width of the data bus, width of
the address bus, representation (big, small-endian or the middle one
you mentioned) etc. But the underlying implementation takes care of it
so we call it portable. The same could have been done for the tasks
you were saying are inherently non-portable. In fact, Java and ports
of perl, python etc do that.

There is a very great difference (in terms of magnitude) between
implementing basic arithmetic operations and something like a portable
graphics library.

No computer language has built-in facilities for doing all possible
tasks. Each language chooses to implement a subset of tasks when it is
designed, according to the consensus that emerges from the language's
purpose and consideration of various pros and cons.

C has chosen to implement a small subset of tasks so that the language
itself can be easily and widely implemented. Other tasks are either
performed by a sequence of built-in steps or are provided by external
code (which may not be in C).

Other languages have chosen to implement a plethora of features for the
sacrifice of some portability.

It is the task of the programmer to choose the appropriate language for
a task based on availability, requirements, skills, support and so on.

Unfortunately learning only one (or a few) language and expecting it to
provide built-in routines to solve all problems is an easy trap to fall
in. In practise you'll have to mix and match code in many languages if
you want to avoid endless frustration or time wasted in reinventing the
wheel again and again.
 
S

soscpd

Hello Walter, List

For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

Yes. I'm building, right now, one application to one display really
close to your's (but mine has 8x22), graphics enabled, RS232 too. I
can run graphics (on that display) with framebuffer (that is the
project main goal - *already* archived). I can run GTK over this same
framebuffer (but by hand the startup speed's up, and the graphics
interface don't need to be something that user friendly). Anything
that cannot run over GTK will, probably, work better (if not only)
with C and ASM coded directly to do hardware calls. That's
automagically possible, but rarely indicated.


Regards
Rafael
 
I

Ian Collins

santosh said:
Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).
Yet the standard includes _Complex and all that wonderful stuff in
<tgmath.h> that programmers of 8 bit micros had (not) been crying out for.
 
S

santosh

Ian said:
Yet the standard includes _Complex and all that wonderful stuff in
<tgmath.h> that programmers of 8 bit micros had (not) been crying out
for.

True, though tgmath.h isn't required under freestanding implementations.
As Keith said over in comp.std.c, the choices of the Committee don't
always seem logical. I think that complex support was standardised when
directory support was not because there was active demand for the
former from implementors and this was not the case with the latter,
perhaps because there were existing, well known, well implemented APIs
for them (POSIX), while there was no such thing for complex. Of course,
I'm purely speculating here, as I have never been involved with C
standardisation.

Actually rahul (and jacob) have a point. Things like network,
directories, and perhaps even graphics *could* be standardised, perhaps
by having several different overlapping standards (like we have today
with freestanding, hosted, with __STDC_IEC_559__). But it would be a
gigantic task, and mostly duplicating the efforts of existing standards
like POSIX, OpenGL, and would probably remain totally unimplemented by
virtually every implementation, even if the Committee could develop
such a document in the first place. I think what it would bring in
terms of advantages (theoretical portability), would not be sufficient
to justify the duplication of effort. If the adoption of C99 is an
indicator, then standardising things like network etc., would be doomed
from the start.
 
B

Bartc

Nick Keighley said:
I don't think it's the size that causes the problem. I think
there isn't enough demand for the new standard. The original
C89 has plenty of compilers. I reject your "C is deceptivly small"

On the face of it C can be described on the back of an envelope. But I keep
seeing stuff in clc that I had no idea was in the language. Sometimes this
stuff is new even to the C-compiler writer jacob navia!
really? What was you application (if you're allowed to say)

It's not a secret, it was a language interpreter I mentioned in clc a few
months back.

I was porting from a language (one of mine) that mixed a C-like semantics
with inline assembler. The compiler for this was very simple and I thought
that 100% C combined with this super-optimisation of modern compilers I kept
hearing about would result in something at least as fast. Then I would also
have a hll implementation that I could tweak and make even faster!

But instead I got a slow-down of 3-4 times, eventually down to 2x slower
with tweaking of the code and using gcc (I never tried ICC). To achieve my
original speed I had to use a separate ASM module (not inline), with
dedicated registers, for the main loop.

I'd also looked at the threaded code methods of gcc (goto plus an array of
&& labels) but this was doing strange things in the generated code.

However with use of ASM and compiler-specific code, and loads of
weird-looking macros (to achieve in C what I'd been doing easily in the
other language), it seemed that C wasn't helping me any. So I've abandoned
the port to C for now, and I'm using my original language. I'm now planning
an interpreter that will be 2-4 times faster than my original; I can't
afford to use C and take a couple of steps back!
 
B

Bartc

santosh said:
Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).

DVD players with no graphics are not going to be too popular...

The graphics (video display) is either built-in (to a screen), or present in
the video output.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top