Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90504 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-18 17:02 +0200 |
| Last post | 2016-07-20 09:01 -0700 |
| Articles | 2 on this page of 82 — 17 participants |
Back to article view | Back to comp.lang.c
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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-18 23:51 +0530 |
| Message-ID | <nmj6nu$bsn$1@dont-email.me> |
| In reply to | #90504 |
On 07/18/2016 08:32 PM, jacobnavia wrote: > 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. Can these containers not be written as per other language standards such as C99 and C11? > 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. A list of files is a list of files anywhere. It is hard to have maps and folds and closures in C. These are usually said to be at a higher level than what C deals with. This is no slight: C was designed to operate at a particular level between man and machine. Languages since C (and some long before it) have usually targeted levels above it. > 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. Leaving aside the misrepresentation about the Lisp notation, this was an exchange between Jacob Navia and Ben Bacarisse: On 07/16/2016 12:43 PM, jacobnavia wrote: > Le 16/07/2016 à 00:27, Ben Bacarisse a écrit : >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> <snip> >>> .... Object oriented programming is no longer "en vogue" and the >>> fad went for templates, now lambdas, and tomorrow whatever computer >>> science students learn at the university, where those fads are >>> fabricated. >> >> Lambdas date from the 1930s. There were amongst the very first >> concepts to be implemented in a programming language (in the 1950s). >> They are a very long-lived fad. > > Lambda Calculus dates from 1930s. There was no lisp then. Jacob Navia made Lisp relevant to his discussion by trying to (and failing to) refute Ben Bacarisse, who did not even say that Lisp was there in the 1930s. > 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. Perhaps, it could also be that some people find the notation better to think in. Then, you would not have to categorize people as "lisp heads" and non-"lisp heads." > You can write lisp in C too of course, you can write anything in C: Really? Can you have closures, generic functions, n-ary comparators, Lisp macros in C? I would _love_ to know if you can. > 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. > > !!!!!!!!!!! The last line lit up my troll sensors, so I won't respond further. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-20 09:01 -0700 |
| Message-ID | <kfnd1m8uwn4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90531 |
Udyant Wig <udyant.wig@gmail.com> writes: > On 07/18/2016 08:32 PM, jacobnavia wrote: >> 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. > > Can these containers not be written as per other language standards > such as C99 and C11? > >> 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. > > A list of files is a list of files anywhere. > > It is hard to have maps and folds and closures in C. [...] It isn't hard to have closures in C. They are implemented (in the form of nested functions) as an extension in gcc. What is hard is to have closures whose environments survive a return from the surrounding function activation. The reason is C has no automatic memory management. But, if we drop in a conservative garbage collector, like the Boehm collector, then I think it's pretty straightforward to have fully capable closures in C, including being able to survive (reliably, obviously) a return from the surrounding function activation.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web