Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #90504 > unrolled thread

Advantages of C

Back to article view | Back to comp.lang.c

Contents

  Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:02 +0200
    Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 16:16 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 19:13 +0200
      Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:56 +0530
    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 08:17 -0700
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:38 +0200
    Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 16:48 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:58 +0200
        Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-18 17:27 +0100
          Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 15:19 -0400
          Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 21:49 +0100
            Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-18 22:06 +0100
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:11 +0100
                Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 01:31 +0100
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 02:29 +0100
                  Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 21:58 -0400
            Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:30 -0700
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 02:06 +0100
                Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 19:39 -0700
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:29 +0100
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:39 -0700
                      Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:19 +0100
          Re: Advantages of C luser droog <luser.droog@gmail.com> - 2016-07-18 21:16 -0700
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:47 +0100
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:48 -0700
        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-19 10:21 +1200
          Re: Advantages of C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:43 +0000
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 18:05 +0200
        Re: Advantages of C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 21:45 +0200
          Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 21:16 +0100
            Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:00 +0530
              Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-19 11:00 +0100
                Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 10:08 +0530
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 23:32 +0200
            Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:54 -0700
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:54 +0100
                Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 20:02 -0700
                  Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:26 +0530
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 01:43 -0700
                      Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 10:33 +0530
                        Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 01:07 -0700
                          Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 12:53 +0530
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:33 +0100
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:04 -0700
                      Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:35 +0100
                Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-19 19:21 +0100
            Re: Advantages of C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-20 12:05 +0200
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:51 -0700
            Re: Advantages of C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:24 +0000
              Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 02:33 -0700
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:36 +0100
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 00:00 +0200
            Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:46 +0100
            Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-20 19:49 +0100
              Re: Advantages of C supercat@casperkitty.com - 2016-07-20 12:02 -0700
                Re: Advantages of C Keith Thompson <kst-u@mib.org> - 2016-07-20 12:32 -0700
                  Re: Advantages of C supercat@casperkitty.com - 2016-07-20 13:18 -0700
                Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-20 20:37 +0100
              Re: Advantages of C jadill33@gmail.com - 2016-07-20 13:06 -0700
              Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-20 23:07 +0200
                Re: Advantages of C jadill33@gmail.com - 2016-07-21 09:48 -0700
                  Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 10:14 +0200
                    Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 20:25 +1200
                      Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 02:17 -0700
                        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 23:56 +1200
                      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 11:28 +0200
                        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 23:49 +1200
                    Re: Advantages of C jadill33@gmail.com - 2016-07-22 06:46 -0700
          Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 23:13 +0100
            Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:45 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 19:18 +0200
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:47 +0100
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 00:07 +0200
            Re: Advantages of C Melzzzzz <mel@zzzzz.com> - 2016-07-19 00:18 +0200
              Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 01:36 +0200
            Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-19 10:28 +1200
              Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:34 -0400
            Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:33 -0400
              Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 19:30 -0700
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 17:01 -0700
    Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:51 +0530
      Re: Advantages of C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 09:01 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#90504 — Advantages of C

This continues the discussion I proposed in my previous message "High 
level C".

The essential part of that message was this:

C doesn't impose a particular view of your data. That doesn't at all 
imply that you can't use data structures  like flexible arrays, lists, 
hash tables, whatever. But there is no further assumptions or concepts 
behind those C constructs. Actually, as language mechanisms go, all 
those containers are written in C89.

And that is the advantage: you do not have to fit your data into some 
complicated language construct: the complex data structures are just 
that: complex data structures, with no further categorization into 
"maps" or other stuff. A list of files is just that: a list of files.

The advantage here ist the simplicity and economy of effort that C allows.

Apparently (besides the religious people) in this group there are many 
lisp heads. They say that lisp notation is better than the notation we 
learned at school. Actually most of the messages were about lisp in the 
replies I got. It was maybe my fault because I spoke about lambda 
calculus in a reply. And then, it went downwards.

It could be, it could be that for the needs of the machine, some other 
kind of notation is more adequate. But I would say that in that sense C 
has the advantage of being more readable by non lisp heads.

You can write lisp in C too of course, you can write anything in C:

a+(b+4)/5

add(a,divide(add(b,4),5)));

with a suitable definition of the functions "add", "div", etc. C gives 
you the choice and lisp heads should be happy with it, since it accepts 
almost unmodified, their notation.

!!!!!!!!!!!

jacob

[toc] | [next] | [standalone]

#90505

On 18/07/2016 16:02, jacobnavia wrote:

> You can write lisp in C too of course, you can write anything in C:
>
> a+(b+4)/5
>
> add(a,divide(add(b,4),5)));

Which inherits some of Lisp's problems too: there's an extra parenthesis 
in there!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#90522

Le 18/07/2016 à 17:16, BartC a écrit :
> On 18/07/2016 16:02, jacobnavia wrote:
>
>> You can write lisp in C too of course, you can write anything in C:
>>
>> a+(b+4)/5
>>
>> add(a,divide(add(b,4),5)));
>
> Which inherits some of Lisp's problems too: there's an extra parenthesis
> in there!
>
Yeah, never got that parentheses at the end right...

:-)

[toc] | [prev] | [next] | [standalone]

#90532

On 07/18/2016 08:46 PM, BartC wrote:
> On 18/07/2016 16:02, jacobnavia wrote:
> 
>> You can write lisp in C too of course, you can write anything in C:
>>
>> a+(b+4)/5
>>
>> add(a,divide(add(b,4),5)));
> 
> Which inherits some of Lisp's problems too: there's an extra
> parenthesis in there!

  Sigh.  You can't have enough of them.

  More on point, Lisp programmers generally read and write using smart
  editing environments.  Surely you do not think that they manage
  something as repetitive as balanced delimiters by hand, do you?
  
-- 
Udyant Wig

[toc] | [prev] | [next] | [standalone]

#90506

On Monday, July 18, 2016 at 4:02:20 PM UTC+1, jacobnavia wrote:

> You can write lisp in C too of course, you can write anything in C:
> 
> a+(b+4)/5
> 
> add(a,divide(add(b,4),5)));
> 
> with a suitable definition of the functions "add", "div", etc. C gives 
> you the choice and lisp heads should be happy with it, since it accepts 
> almost unmodified, their notation.
> 
No, it looks superficially like Lisp, but isn't the real McCoy.
The point is that functions are data in Lisp. Everything is a tree, except
when its's a dotted pair, but let's not go there. As i said in a recent
thread on structured programming, it's all about tree, trees are where
it's at.
So you can pass a = x, b = (+ x (* x x)) to Lisp, and we've got a function
in x.  We then pass x = x + dx, write a filter to take only the dx terms in
the answer, and we have the derivative.
Or we can just pass a = 1, b = 2 an evaluate the function.

The only way of achieving this in C is to write a Lisp interpreter in C.

 

[toc] | [prev] | [next] | [standalone]

#90508

Le 18/07/2016 à 17:17, Malcolm McLean a écrit :
> No, it looks superficially like Lisp, but isn't the real McCoy.
> The point is that functions are data in Lisp. Everything is a tree, except
> when its's a dotted pair, but let's not go there. As i said in a recent
> thread on structured programming, it's all about tree, trees are where
> it's at.

The C expression:

add(a,divide(add(b,4),5)));

is a tree of root "add" with two branches:

"a" and a further expression (second tree level)

That expression is a tree of two branches

an expression "add(b,4)" and a constant 5.

That C expression represent a 3 level tree.

And as in any good language, in C functions are data too, they can be 
passed around, etc. Yes, you have no more complicated constructs like in 
Lisp with closures and what have you.

But those parts of lisp make it a write only language, where it is VERY 
difficult to figure out which variables were captured where and you have 
to start the interpreter to figure it out...

Call with current continuation?

Just add a void (*)(void) parameter to your functions, and end all your 
functions with a call to that function!

You can write *anything* in C.

:-)

[toc] | [prev] | [next] | [standalone]

#90510

jacobnavia <jacob@jacob.remcomp.fr> writes:

> This continues the discussion I proposed in my previous message "High
> level C".
>
> The essential part of that message was this:
>
> C doesn't impose a particular view of your data. That doesn't at all
> imply that you can't use data structures  like flexible arrays, lists,
> hash tables, whatever. But there is no further assumptions or concepts
> behind those C constructs. Actually, as language mechanisms go, all
> those containers are written in C89.

I said I'd reply to your next C-related message I'll have a go...

I want to make a meta-point: in general I'm wary of unbalanced
criticism.  I think you should also point out some of the reason why
this is a disadvantage that C has.  It helps make your point.  First, it
helps you not to come over as a fanatic and, second, it show that your
opinions are based in a deep understanding of the merits and demerits of
various programming languages.

> And that is the advantage: you do not have to fit your data into some
> complicated language construct: the complex data structures are just
> that: complex data structures, with no further categorization into
> "maps" or other stuff. A list of files is just that: a list of files.

Sure, but you can also often write such programs more simply in
languages with the very attributes you are denigrating.  You posted a
few examples and I showed, just for comparison, what they would be like
in C++.  The discussion should then have been about the merits and
demerits or each.  For example, C++ is harder to learn, but your code
used a library that would also have to be learnt.  The C++ library is
standard so the learning is likely to be of long-term use.  Your library
is unlikely to be become standard, but is written in standard C so it
can (probably) be compiled for lots of targets.  Try to give a flavour
of the pros and cons where you can.

> The advantage here ist the simplicity and economy of effort that C
> allows.

Now list at last one disadvantage?

> Apparently (besides the religious people) in this group there are many
> lisp heads. They say that lisp notation is better than the notation we
> learned at school.

I don't recall anyone saying that.  It has advantages.  That does not
mean it is "better".  For one thing "better" is too vague make sense in
a technical discussion.  What happens, though, is someone will say
something daft like "lambdas are a fad" and people like me feel obliged
to put the other side.  If the original post put both sides -- what's
good and bad about a feature -- there would be no need for the
discussion to become polarised.

> Actually most of the messages were about lisp in
> the replies I got. It was maybe my fault because I spoke about lambda
> calculus in a reply. And then, it went downwards.
>
> It could be, it could be that for the needs of the machine, some other
> kind of notation is more adequate. But I would say that in that sense
> C has the advantage of being more readable by non lisp heads.
>
> You can write lisp in C too of course, you can write anything in C:
>
> a+(b+4)/5
>
> add(a,divide(add(b,4),5)));
>
> with a suitable definition of the functions "add", "div", etc. C gives
> you the choice and lisp heads should be happy with it, since it
> accepts almost unmodified, their notation.

You should probably pick up a book about Lisp before you start saying
that the above has anything but the most superficial similarity to a
Lisp form.  In general, these discussion should, in my option, be much
less obsessed with syntax.  C limits the ways in which program can be
written because of its semantics.  This makes it easy to learn but
limiting in how you structure your code.  Those sorts of distinction are
for more significant than (+ 1 2) vs 1 + 1 and add(1, 2).

> !!!!!!!!!!!

Ah, I though you were being serious.  Sorry.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90511

Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
> Your library
> is unlikely to be become standard

Yes. I spent thousands of dollars in a trip to the committee session in 
Portland where I was told that after the STL what I was trying to do was 
ridiculous.

A committee member told me that in his shop, all code will be compiled 
as C++ anyway so what I proposed was besides the point.

Not all people were like that of course, and I gathered merit for the 
best documentation proposal from one of the committee members. They all 
were impressed by the package, nobody thought that what I was trying to 
do was possible in C.

Obviously in this group, the same people that told me to go to Portland 
told me I have merited my defeat.

Granted, my proposal wasn't accepted and I do not have the money nor the 
will of pursuing that way.

Obviously too, a group that discusses C is full of people that tell 
people here that C is doomed, nobody should really develop anything 
important in C, since the C++ language fills all needs that you could 
ever have.

[toc] | [prev] | [next] | [standalone]

#90515

On 18/07/16 16:58, jacobnavia wrote:
<snip>
>
> Obviously too, a group that discusses C is full of people that tell
> people here that C is doomed, nobody should really develop anything
> important in C, since the C++ language fills all needs that you could
> ever have.

I think you overstate the case. There are at least two (and quite 
possibly more than two) people in this group for whom C is their 
development language of choice: you, and me.

Any more?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#90533

On 7/18/2016 12:27 PM, Richard Heathfield wrote:
> On 18/07/16 16:58, jacobnavia wrote:
> <snip>
>>
>> Obviously too, a group that discusses C is full of people that tell
>> people here that C is doomed, nobody should really develop anything
>> important in C, since the C++ language fills all needs that you could
>> ever have.
> 
> I think you overstate the case. There are at least two (and quite
> possibly more than two) people in this group for whom C is their
> development language of choice: you, and me.
> 
> Any more?
> 

I use the language appropriate for the job. Sometimes it's C, sometimes
it's C++.  And sometimes it's something else.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#90536

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 18/07/16 16:58, jacobnavia wrote:
> <snip>
>>
>> Obviously too, a group that discusses C is full of people that tell
>> people here that C is doomed, nobody should really develop anything
>> important in C, since the C++ language fills all needs that you could
>> ever have.
>
> I think you overstate the case. There are at least two (and quite
> possibly more than two) people in this group for whom C is their
> development language of choice: you, and me.

I'm not sure what than means.  Surely even for the most enthusiastic C
programmer it would depend on what you are doing?

> Any more?

I don't code for money anymore, just for fun, but I wrote a small C
program a couple of weeks ago to respond to interrupts and flash lights
on my laptop to signal various things.  It seemed like the simplest tool
to use.  And then the other day I wanted to try a numerical problem
posted on sci.math and for that I used Haskell.  I think it would have
taken a lot longer and been something of a mess if I'd tried in C.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90537

On 18/07/16 21:49, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 18/07/16 16:58, jacobnavia wrote:
>> <snip>
>>>
>>> Obviously too, a group that discusses C is full of people that tell
>>> people here that C is doomed, nobody should really develop anything
>>> important in C, since the C++ language fills all needs that you could
>>> ever have.
>>
>> I think you overstate the case. There are at least two (and quite
>> possibly more than two) people in this group for whom C is their
>> development language of choice: you, and me.
>
> I'm not sure what than means.  Surely even for the most enthusiastic C
> programmer it would depend on what you are doing?

Of course. But the key word is "choice". When all else is equal, and all 
other factors have been taken into account, and you have eliminated 
unsuitable languages, and so you have a free choice among the survivors 
- if C is in the list of survivors, is that the language you choose? If 
so, then that's your language of choice (because, /given/ the choice, 
that's what you choose).

>> Any more?
>
> I don't code for money anymore, just for fun, but I wrote a small C
> program a couple of weeks ago to respond to interrupts and flash lights
> on my laptop to signal various things.  It seemed like the simplest tool
> to use.  And then the other day I wanted to try a numerical problem
> posted on sci.math and for that I used Haskell.  I think it would have
> taken a lot longer and been something of a mess if I'd tried in C.

I tend to default to C because I can write C programs very quickly and 
efficiently. I have even been known to generate shell scripts using C 
because I find it to be far quicker than coding them by hand(!).

But for Windows GUI programs, C++ Builder is much, much, /much/ faster 
(for me, at least), so that's what I use. For Web work, I use PHP.

But when all else is equal and it comes down to a toss of the coin, it's 
"heads I use C, tails I don't use anything but C".

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#90554

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 18/07/16 21:49, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 18/07/16 16:58, jacobnavia wrote:
>>> <snip>
>>>>
>>>> Obviously too, a group that discusses C is full of people that tell
>>>> people here that C is doomed, nobody should really develop anything
>>>> important in C, since the C++ language fills all needs that you could
>>>> ever have.
>>>
>>> I think you overstate the case. There are at least two (and quite
>>> possibly more than two) people in this group for whom C is their
>>> development language of choice: you, and me.
>>
>> I'm not sure what than means.  Surely even for the most enthusiastic C
>> programmer it would depend on what you are doing?
>
> Of course. But the key word is "choice". When all else is equal, and
> all other factors have been taken into account, and you have
> eliminated unsuitable languages, and so you have a free choice among
> the survivors - if C is in the list of survivors, is that the language
> you choose? If so, then that's your language of choice (because,
> /given/ the choice, that's what you choose).

But that does not help me understand.  You've replaced choice by "all
else is equal" in one place and "is not unsuitable" in another.  The
only reason I wanted to understand is that you asked:

>>> Any more?

so I wondered if I was another or not.  I'm still not sure.

Anyway, it's probably not very important.  You use C a lot and I think I
would probably used it in fewer situations than you would.  But if
that's because of how I evaluate all else being equal it many well be,
by your criteria, my language of choice.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90555

On 19/07/16 01:11, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 18/07/16 21:49, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>
>>>> On 18/07/16 16:58, jacobnavia wrote:
>>>> <snip>
>>>>>
>>>>> Obviously too, a group that discusses C is full of people that tell
>>>>> people here that C is doomed, nobody should really develop anything
>>>>> important in C, since the C++ language fills all needs that you could
>>>>> ever have.
>>>>
>>>> I think you overstate the case. There are at least two (and quite
>>>> possibly more than two) people in this group for whom C is their
>>>> development language of choice: you, and me.
>>>
>>> I'm not sure what than means.  Surely even for the most enthusiastic C
>>> programmer it would depend on what you are doing?
>>
>> Of course. But the key word is "choice". When all else is equal, and
>> all other factors have been taken into account, and you have
>> eliminated unsuitable languages, and so you have a free choice among
>> the survivors - if C is in the list of survivors, is that the language
>> you choose? If so, then that's your language of choice (because,
>> /given/ the choice, that's what you choose).
>
> But that does not help me understand.  You've replaced choice by "all
> else is equal" in one place and "is not unsuitable" in another.

Sorry. Let me try to be clear (or, at least, clearer!). But I really, 
really want to avoid specifics, because they'll just be grounds for 
arguments that are likely to end up being fruitless.

Let's say you have a task X, and you have at your disposal the ten 
languages A, B, C, D, E, F, G, H, I, J. (Perhaps you had more, but you 
have already eliminated some, for any of various criteria that you've 
already applied to the list. These ten are the survivors.)

One of the final criteria is, say, that the language must be available 
for the target platform. It happens that A and G are not available on 
the target platform. So your choice is reduced to B, C, D, E, F, H, I, J.

And the very last criterion is that, since the task X is likely to be 
particularly CPU-intensive, the language has to be fast enough to cope, 
and a few carefully-written test programs reveal that (your 
implementations of) D, F, and H are not going to be fast enough. That 
leaves B, C, E, I, J.

And now *all* objective criteria have been met, and these five are left, 
and the only criterion that remains is "personal preference". We will 
further assume that, by some miracle, these happen to be your five 
favourite languages (and that C is, by a happy chance, the C programming 
language). This is what I meant by "all else being equal" - we've 
eliminated the choices that are a poor fit for task X, for any of a 
number of reasons.

When you have no other grounds for selecting a language (because you've 
already applied all relevant criteria and eliminated those that do not 
meet those criteria), the one you choose from among the survivors is 
your language of choice. If you choose C, then C is your language of choice.

> The
> only reason I wanted to understand is that you asked:
>
>>>> Any more?
>
> so I wondered if I was another or not.  I'm still not sure.
>
> Anyway, it's probably not very important.  You use C a lot and I think I
> would probably used it in fewer situations than you would.  But if
> that's because of how I evaluate all else being equal it many well be,
> by your criteria, my language of choice.

I suspect that, if it were otherwise, you wouldn't be so good at it.

For me, it's a /fairly/ close call between C and C++, but for some 
reason I keep coming down on the side of C. If I were pressed for my 
reasons, I'd probably have to say: portability, simplicity, and speed 
(possibly even in that order).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#90562

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 19/07/16 01:11, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 18/07/16 21:49, Ben Bacarisse wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>
>>>>> On 18/07/16 16:58, jacobnavia wrote:
>>>>> <snip>
>>>>>>
>>>>>> Obviously too, a group that discusses C is full of people that tell
>>>>>> people here that C is doomed, nobody should really develop anything
>>>>>> important in C, since the C++ language fills all needs that you could
>>>>>> ever have.
>>>>>
>>>>> I think you overstate the case. There are at least two (and quite
>>>>> possibly more than two) people in this group for whom C is their
>>>>> development language of choice: you, and me.
>>>>
>>>> I'm not sure what than means.  Surely even for the most enthusiastic C
>>>> programmer it would depend on what you are doing?
>>>
>>> Of course. But the key word is "choice". When all else is equal, and
>>> all other factors have been taken into account, and you have
>>> eliminated unsuitable languages, and so you have a free choice among
>>> the survivors - if C is in the list of survivors, is that the language
>>> you choose? If so, then that's your language of choice (because,
>>> /given/ the choice, that's what you choose).
>>
>> But that does not help me understand.  You've replaced choice by "all
>> else is equal" in one place and "is not unsuitable" in another.
>
> Sorry. Let me try to be clear (or, at least, clearer!). But I really,
> really want to avoid specifics, because they'll just be grounds for
> arguments that are likely to end up being fruitless.
>
> Let's say you have a task X, and you have at your disposal the ten
> languages A, B, C, D, E, F, G, H, I, J. (Perhaps you had more, but you
> have already eliminated some, for any of various criteria that you've
> already applied to the list. These ten are the survivors.)
>
> One of the final criteria is, say, that the language must be available
> for the target platform. It happens that A and G are not available on
> the target platform. So your choice is reduced to B, C, D, E, F, H, I,
> J.
>
> And the very last criterion is that, since the task X is likely to be
> particularly CPU-intensive, the language has to be fast enough to
> cope, and a few carefully-written test programs reveal that (your
> implementations of) D, F, and H are not going to be fast enough. That
> leaves B, C, E, I, J.
>
> And now *all* objective criteria have been met, and these five are
> left, and the only criterion that remains is "personal preference". We
> will further assume that, by some miracle, these happen to be your
> five favourite languages (and that C is, by a happy chance, the C
> programming language). This is what I meant by "all else being equal"
> - we've eliminated the choices that are a poor fit for task X, for any
> of a number of reasons.

I don't recall being in that position with hard, binary, criteria to
reject a language often enough (ever?) to really know what I'd do.  If
I'm on my own, the notion of, say, portability might be very woolly.  C
is on these targets, but do I really need them all?  Maybe, maybe not.
If part of a team, the decision of often made for social reasons -- does
everyone know C?  Yes, so C it is!

> When you have no other grounds for selecting a language (because
> you've already applied all relevant criteria and eliminated those that
> do not meet those criteria), the one you choose from among the
> survivors is your language of choice. If you choose C, then C is your
> language of choice.

I have to imagine this situation because I don't recall ever being able
to rule out languages objectively whilst still having a free choice over
what's left.  But if I try to imagine it, I find that C is *not* my
language of choice.  I'd almost certainly use the one that I'd feel was
more fun -- often one I don't know well, but find interesting.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90563

On 7/18/2016 8:31 PM, Richard Heathfield wrote:
> On 19/07/16 01:11, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 18/07/16 21:49, Ben Bacarisse wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>
>>>>> On 18/07/16 16:58, jacobnavia wrote:
>>>>> <snip>
>>>>>>
>>>>>> Obviously too, a group that discusses C is full of people that tell
>>>>>> people here that C is doomed, nobody should really develop anything
>>>>>> important in C, since the C++ language fills all needs that you could
>>>>>> ever have.
>>>>>
>>>>> I think you overstate the case. There are at least two (and quite
>>>>> possibly more than two) people in this group for whom C is their
>>>>> development language of choice: you, and me.
>>>>
>>>> I'm not sure what than means.  Surely even for the most enthusiastic C
>>>> programmer it would depend on what you are doing?
>>>
>>> Of course. But the key word is "choice". When all else is equal, and
>>> all other factors have been taken into account, and you have
>>> eliminated unsuitable languages, and so you have a free choice among
>>> the survivors - if C is in the list of survivors, is that the language
>>> you choose? If so, then that's your language of choice (because,
>>> /given/ the choice, that's what you choose).
>>
>> But that does not help me understand.  You've replaced choice by "all
>> else is equal" in one place and "is not unsuitable" in another.
> 
> Sorry. Let me try to be clear (or, at least, clearer!). But I really,
> really want to avoid specifics, because they'll just be grounds for
> arguments that are likely to end up being fruitless.
> 
> Let's say you have a task X, and you have at your disposal the ten
> languages A, B, C, D, E, F, G, H, I, J. (Perhaps you had more, but you
> have already eliminated some, for any of various criteria that you've
> already applied to the list. These ten are the survivors.)
> 
> One of the final criteria is, say, that the language must be available
> for the target platform. It happens that A and G are not available on
> the target platform. So your choice is reduced to B, C, D, E, F, H, I, J.
> 
> And the very last criterion is that, since the task X is likely to be
> particularly CPU-intensive, the language has to be fast enough to cope,
> and a few carefully-written test programs reveal that (your
> implementations of) D, F, and H are not going to be fast enough. That
> leaves B, C, E, I, J.
> 
> And now *all* objective criteria have been met, and these five are left,
> and the only criterion that remains is "personal preference". We will
> further assume that, by some miracle, these happen to be your five
> favourite languages (and that C is, by a happy chance, the C programming
> language). This is what I meant by "all else being equal" - we've
> eliminated the choices that are a poor fit for task X, for any of a
> number of reasons.
> 

In over 45 years of programming, I have yet to find a case where
"personal preference" is the only criteria for choosing a language.
There are way too many other variables to consider.

> When you have no other grounds for selecting a language (because you've
> already applied all relevant criteria and eliminated those that do not
> meet those criteria), the one you choose from among the survivors is
> your language of choice. If you choose C, then C is your language of
> choice.
> 

By the time all criteria have been applied, one language will have an
advantage over all of the others.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#90548

On Monday, July 18, 2016 at 9:49:43 PM UTC+1, Ben Bacarisse wrote:
> 
> > I think you overstate the case. There are at least two (and quite
> > possibly more than two) people in this group for whom C is their
> > development language of choice: you, and me.
> 
> I'm not sure what than means.  Surely even for the most enthusiastic C
> programmer it would depend on what you are doing?
> 
Not really.
Obviously C won't run in a web browser, but that's because of poor
design decisions by the people who built the browser, not because
of C.
People say "languages for the problem domain", but the issue is 
grossly exaggerated. Virtually every programming problem boils
down to either build a nested structure of lists of lists of
lists, and iterate over them, applying manipulations, or build
a graph and crawl or exhaustively enumerate it, either manipulating
the structure or finding a path (rarely sub-graph) through it.

C handles both easily. You need loops, dynamic arrays, indexing
by integer, and nested subroutines for the first type of problem,
and travelling pointers, dynamic nodes, and recursion for the
second type of problem.
> 
> I don't code for money anymore, just for fun, but I wrote a small C
> program a couple of weeks ago to respond to interrupts and flash lights
> on my laptop to signal various things.  It seemed like the simplest tool
> to use.  And then the other day I wanted to try a numerical problem
> posted on sci.math and for that I used Haskell.  I think it would have
> taken a lot longer and been something of a mess if I'd tried in C.
> 
Sometimes you need built-in arbitrary precision arithmetic. But it's
rare to require that. doubles will represent most values with 
sufficient accuracy and range to satisfy the user. Sometimes
you also need "reflection", the ability to handle code or expressions
as data, and again to build that machinery using C is difficult.

But those tend to come up in "programming puzzles" rather than 
programs people actually want and will pay money for.

[toc] | [prev] | [next] | [standalone]

#90561

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Monday, July 18, 2016 at 9:49:43 PM UTC+1, Ben Bacarisse wrote:
>> 
>> > I think you overstate the case. There are at least two (and quite
>> > possibly more than two) people in this group for whom C is their
>> > development language of choice: you, and me.
>> 
>> I'm not sure what than means.  Surely even for the most enthusiastic C
>> programmer it would depend on what you are doing?
>> 
> Not really.
> Obviously C won't run in a web browser, but that's because of poor
> design decisions by the people who built the browser, not because
> of C.

Why is that obvious to you?  It seems obvious to me that it would be
very simple to run C in a browser, and, as it happens, a bad idea
precisely because of the design of C.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90565

On Tuesday, July 19, 2016 at 2:06:44 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > Not really.
> > Obviously C won't run in a web browser, but that's because of poor
> > design decisions by the people who built the browser, not because
> > of C.
> 
> Why is that obvious to you?  It seems obvious to me that it would be
> very simple to run C in a browser, and, as it happens, a bad idea
> precisely because of the design of C.
> 
It's not hard to take a C interpreter and add it to your own browser.
The difficulty is in making sure your users have the interpreter
installed in their browsers.
Obviously you would use fat pointers rather then raw addresses, so 
it would be safe. There's also a very technical and annoying issue
to do with typedefs that means a C interpreter has to do a full
parse when you'd like it to do a peephole interpret, but that's
by no means fatal on modern machines.
 
 

[toc] | [prev] | [next] | [standalone]

#90582

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Tuesday, July 19, 2016 at 2:06:44 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> > Not really.
>> > Obviously C won't run in a web browser, but that's because of poor
>> > design decisions by the people who built the browser, not because
>> > of C.
>> 
>> Why is that obvious to you?  It seems obvious to me that it would be
>> very simple to run C in a browser, and, as it happens, a bad idea
>> precisely because of the design of C.
>> 
> It's not hard to take a C interpreter and add it to your own browser.
> The difficulty is in making sure your users have the interpreter
> installed in their browsers.

How is that any different from any other client-side scripting language?
Anyway, I still don't see why it's obvious to you that C won't run in a
web browser.  You now seem to be saying that it's not hard.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web