Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #65653 > unrolled thread
| Started by | doctor@doctor.nl2k.ab.ca (The Doctor) |
|---|---|
| First post | 2015-07-15 20:40 +0000 |
| Last post | 2015-07-16 09:55 +1200 |
| Articles | 20 on this page of 182 — 21 participants |
Back to article view | Back to comp.lang.c
SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 20:40 +0000
Re: SQL filesortcc question Paavo Helde <myfirstname@osa.pri.ee> - 2015-07-15 16:08 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-15 17:15 -0400
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 23:22 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 18:35 +0200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 17:48 +0100
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 19:38 +0200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 22:17 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 21:44 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:51 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:05 +1200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 11:36 -0400
Re: SQL filesortcc question The Doctor <doctor@doctor.nl2k.ab.ca> - 2015-07-17 22:22 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 18:44 -0400
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-18 11:13 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 22:06 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:24 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-17 00:26 +0000
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:50 +0000
Re: SQL filesortcc question John Bode <jfbode1029@gmail.com> - 2015-07-31 13:39 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:07 +1200
Re: SQL filesortcc question Philip Lantz <prl@canterey.us> - 2015-07-16 16:05 -0700
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:28 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 11:13 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 19:27 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-21 08:46 +1200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:12 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:55 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:01 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:51 +1200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:02 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:35 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 14:16 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:49 +0100
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-27 23:25 -0500
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-28 09:32 +0000
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-28 10:22 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-27 22:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:57 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 16:38 +1200
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-28 00:51 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 07:06 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 20:32 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 10:02 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 22:08 +1200
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-28 18:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 12:14 -0400
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-29 11:27 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 13:01 -0400
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-29 17:33 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 21:07 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 16:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 22:12 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-29 23:50 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 00:13 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 01:49 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 02:07 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 03:04 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 08:25 +0100
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-30 09:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:17 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 17:00 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:12 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 15:12 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 23:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 10:29 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-31 08:10 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 11:12 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 22:56 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 18:34 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 13:55 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 07:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 15:36 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 09:19 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 18:16 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 15:30 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-02 09:00 -0400
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-02 09:19 -0400
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:23 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:35 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:11 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 10:28 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 09:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 00:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 13:55 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 07:03 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 16:53 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 09:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 21:20 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:07 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 12:24 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 13:49 +0100
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 15:41 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 07:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-07 17:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:48 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:00 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 08:52 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:56 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-04 23:45 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-05 08:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:00 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 13:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 16:11 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 14:00 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:40 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:20 -0700
Re: SQL filesortcc question Rosario19 <Ros@invalid.invalid> - 2015-08-22 08:24 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-22 19:26 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 05:39 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 13:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:38 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:14 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 01:15 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 02:32 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 12:57 +1200
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 22:23 -0700
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:21 -0500
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:21 +0200
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:05 -0500
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:24 -0500
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 23:56 -0700
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:25 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:19 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-29 19:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 23:45 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 04:22 -0700
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:13 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 13:27 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:57 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 14:11 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:39 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 15:05 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:03 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 11:22 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 18:32 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:38 +1200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 10:56 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 22:28 +1200
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 10:57 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 08:02 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 08:33 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-03 20:50 -0400
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 04:52 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:08 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:20 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-03 19:09 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 06:09 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:40 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 13:24 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-05 21:51 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-09-05 17:16 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-09-05 19:59 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 07:51 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 17:32 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:04 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-07-21 13:23 +0200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:14 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:25 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:31 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 17:10 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 13:29 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 20:24 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 03:02 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 09:22 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:04 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 10:32 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 16:49 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 21:46 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-27 04:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-26 14:58 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:15 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:47 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:55 +1200
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-28 10:22 +0100 |
| Message-ID | <mp7hil$qi3$1@dont-email.me> |
| In reply to | #66472 |
On 28/07/2015 04:49, Richard Heathfield wrote: > On 28/07/15 03:16, Ian Collins wrote: >> Richard Heathfield wrote: >>> >>> Yes - or rather, I really think that none of the features you list (or >>> any you missed) were worth the cost. It is a real cost, and it is a cost >>> that all of us had to pay. We used to have a C language. Now we have >>> several C languages. We're right back where we were in the early 1980s. >> >> Oh no, some bugger has invented DVDs and BluRay, so I have several media >> formats to choose. We really should have stuck with VHS. > > A closer analogy: someone has invented several new VHS formats, all > slightly incompatible with each other, so a VHS player is no longer > enough for playing a VHS video - you have to have the /right kind/ of > VHS player. We really should have stuck with one single meaning for VHS. > If we want new formats, that's fine, but why not call them something > else, such as DVD or BluRay? I used SVHS because it was far better quality than normal VHS. Not many people had SVHS decks however, so if I had to send someone a tape, I would need to copy it onto standard VHS format. Similarly, I can't see why there can't be translators from C99 to C90 (running on your machine before being sent as C90). Of course, it's bit more effort, and I sort of agree with you that the new C99 features weren't that exciting. (And these days, people can also download free C99 compilers more easily than they can SVHS players.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-27 22:33 -0400 |
| Message-ID | <mp6pio$kku$1@dont-email.me> |
| In reply to | #66460 |
On 07/27/2015 06:35 PM, Richard Heathfield wrote: > On 25/07/15 18:02, Tim Rentsch wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: ... >>> On 20/07/15 19:13, Tim Rentsch wrote: >>>> Richard Heathfield <rjh@cpax.org.uk> writes: ... >>>> my question is not about the comparison but about the >>>> perceived differences between C90 and C99, and also C11. >>>> Can you elaborate on the particulars? In particular, which >>>> changes or additions in C99 were (in your opinion) worth >>>> introducing, >>> >>> That shouldn't take too long. >>> >>> Done. >> >> I find this assertion quite unbelievable. Did you even bother to >> review what features were added? Do you really think none of the >> following features provide a benefit over C90 > > Yes - or rather, I really think that none of the features you list (or > any you missed) were worth the cost. It is a real cost, and it is a cost > that all of us had to pay. ... I used to think that you were simply very concerned about backwards compatibility. But if you can't find a single change made since C90 that was worthwhile, you're basically implying that the language should never change. I can't feel much respect for that point of view. > ... We used to have a C language. Now we have > several C languages. We're right back where we were in the early 1980s. If you are calling C99 and C2011 different languages, I won't argue with you about that, but I consider it a normal acceptable consequence of having a language that is sufficiently alive to keep changing. However, if you're referring to the proliferation of optional features (particularly in C2011), I will agree with you that this has been a bad thing. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-28 04:57 +0100 |
| Message-ID | <mp6ufs$vuj$1@dont-email.me> |
| In reply to | #66470 |
On 28/07/15 03:33, James Kuyper wrote: > On 07/27/2015 06:35 PM, Richard Heathfield wrote: >> On 25/07/15 18:02, Tim Rentsch wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: > ... >>>> On 20/07/15 19:13, Tim Rentsch wrote: >>>>> Richard Heathfield <rjh@cpax.org.uk> writes: > ... >>>>> my question is not about the comparison but about the >>>>> perceived differences between C90 and C99, and also C11. >>>>> Can you elaborate on the particulars? In particular, which >>>>> changes or additions in C99 were (in your opinion) worth >>>>> introducing, >>>> >>>> That shouldn't take too long. >>>> >>>> Done. >>> >>> I find this assertion quite unbelievable. Did you even bother to >>> review what features were added? Do you really think none of the >>> following features provide a benefit over C90 >> >> Yes - or rather, I really think that none of the features you list (or >> any you missed) were worth the cost. It is a real cost, and it is a cost >> that all of us had to pay. ... > > I used to think that you were simply very concerned about backwards > compatibility. But if you can't find a single change made since C90 that > was worthwhile, you're basically implying that the language should never > change. I can't feel much respect for that point of view. The language did change considerably over its early history, but C90 was a very important line in the sand because it was /so/ universally implemented. We didn't quite have a portable assembly language, but we had something very very close to it. (And we still have that, because C90 hasn't become /un/implemented on all the platforms where it was installed.) I'm all in favour of new things, but I see no value in giving them old names. If we're going to make a whizzy new language that has exciting features like BCPL-style comments and an absence of gets() and dozens of other very splendid and worthwhile wossnames, that's brilliant! But let's find a new name for it, and let's use this new language to /add/ to the number of available languages, not to replace something that has a very important part still to play. -- 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]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-28 16:38 +1200 |
| Message-ID | <d1of9hFohsbU4@mid.individual.net> |
| In reply to | #66473 |
Richard Heathfield wrote: > > I'm all in favour of new things, but I see no value in giving them old > names. If we're going to make a whizzy new language that has exciting > features like BCPL-style comments and an absence of gets() and dozens of > other very splendid and worthwhile wossnames, that's brilliant! But > let's find a new name for it, and let's use this new language to /add/ > to the number of available languages, not to replace something that has > a very important part still to play. Every other significant programming language has evolved while retaining its name, maybe (just like C) adding a suffix. Some changes have been significant (PHP4->5) and some quite extreme (Python 3.x springs to mind), breaking backwards compatibility along the way. Why should C be any different? If every language changed its name each time it evolved, just imagine how many language names there would be... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-28 00:51 -0400 |
| Message-ID | <mp71ks$7f3$1@dont-email.me> |
| In reply to | #66473 |
On 07/27/2015 11:57 PM, Richard Heathfield wrote: > On 28/07/15 03:33, James Kuyper wrote: ... >> I used to think that you were simply very concerned about backwards >> compatibility. But if you can't find a single change made since C90 that >> was worthwhile, you're basically implying that the language should never >> change. I can't feel much respect for that point of view. > > The language did change considerably over its early history, but C90 was > a very important line in the sand because it was /so/ universally > implemented. We didn't quite have a portable assembly language, but we > had something very very close to it. (And we still have that, because > C90 hasn't become /un/implemented on all the platforms where it was > installed.) > > I'm all in favour of new things, but I see no value in giving them old > names. ... If they're not sufficiently new to justify treating them as completely different, there's value in giving them a name that reflects both the differences from the older version, and the continuity with the older version. > ... If we're going to make a whizzy new language that has exciting > features like BCPL-style comments and an absence of gets() and dozens of > other very splendid and worthwhile wossnames, that's brilliant! But > let's find a new name for it, and let's use this new language to /add/ > to the number of available languages, not to replace something that has > a very important part still to play. Are you trying to imply that you might have actually started writing some programs in C99, if it had, instead, been given a name that distinguished it completely from C90? If so, I don't believe you. C99 has it's own name, "C99", distinct from "C90". It's not sufficiently distinct for your preferences, but it's also not sufficiently different to treat as an entirely new language. And, more directly to the point, C99 was intended, ideally, to replace C90, just like C90 almost completely replaced K&R C. I don't agree that it would have been a bad thing for it to succeed in doing so - though success would almost certainly have required modifying the list of features added in C99. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-28 07:06 +0100 |
| Message-ID | <mp7621$ii2$1@dont-email.me> |
| In reply to | #66476 |
On 28/07/15 05:51, James Kuyper wrote: > On 07/27/2015 11:57 PM, Richard Heathfield wrote: >> ... If we're going to make a whizzy new language that has exciting >> features like BCPL-style comments and an absence of gets() and dozens of >> other very splendid and worthwhile wossnames, that's brilliant! But >> let's find a new name for it, and let's use this new language to /add/ >> to the number of available languages, not to replace something that has >> a very important part still to play. > > Are you trying to imply that you might have actually started writing > some programs in C99, if it had, instead, been given a name that > distinguished it completely from C90? If so, I don't believe you. No, I'm not trying to imply anything. I'll be quite candid about it. Would I have found a use for this new language? No, certainly not. Would others? Apparently so. And that's fine by me. I'm all for people being able to program in the language in which they wish to program. Me, I favour C90, for reasons stated over and over again. What surprises me is that so many people are seemingly so determined that I shouldn't be allowed to, at least not without being treated like some kind of Luddite. > C99 has it's own name, "C99", distinct from "C90". It's not sufficiently > distinct for your preferences, but it's also not sufficiently different > to treat as an entirely new language. And, more directly to the point, > C99 was intended, ideally, to replace C90, just like C90 almost > completely replaced K&R C. I don't agree that it would have been a bad > thing for it to succeed in doing so - though success would almost > certainly have required modifying the list of features added in C99. If it /had/, that might have been a different matter. But it didn't. -- 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]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-28 20:32 +1200 |
| Message-ID | <d1ot0tFohsbU6@mid.individual.net> |
| In reply to | #66478 |
Richard Heathfield wrote: > On 28/07/15 05:51, James Kuyper wrote: >> On 07/27/2015 11:57 PM, Richard Heathfield wrote: >>> ... If we're going to make a whizzy new language that has exciting >>> features like BCPL-style comments and an absence of gets() and dozens of >>> other very splendid and worthwhile wossnames, that's brilliant! But >>> let's find a new name for it, and let's use this new language to /add/ >>> to the number of available languages, not to replace something that has >>> a very important part still to play. >> >> Are you trying to imply that you might have actually started writing >> some programs in C99, if it had, instead, been given a name that >> distinguished it completely from C90? If so, I don't believe you. > > No, I'm not trying to imply anything. I'll be quite candid about it. > Would I have found a use for this new language? No, certainly not. Would > others? Apparently so. And that's fine by me. I'm all for people being > able to program in the language in which they wish to program. Me, I > favour C90, for reasons stated over and over again. What surprises me is > that so many people are seemingly so determined that I shouldn't be > allowed to, at least not without being treated like some kind of Luddite. I don't think people are saying that you shouldn't be allowed to use C90, your reasons are sound. What does surprise some of us is you not seeing any advantage in the new features added to C99. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-28 10:02 +0100 |
| Message-ID | <mp7gcg$m86$1@dont-email.me> |
| In reply to | #66480 |
On 28/07/15 09:32, Ian Collins wrote: <snip> > I don't think people are saying that you shouldn't be allowed to use > C90, your reasons are sound. What does surprise some of us is you not > seeing any advantage in the new features added to C99. Would I look at those features differently if they were enshrined in a different language? Perhaps, although seriously I don't think that any of them are much to write home about. Are any of them attractive enough to persuade me to favour such a language over not only the huge portability of C90 but also the enormous toy-box of C++? No, I don't think so. I'm surprised that you find that surprising. If one doesn't have to worry quite so much about portability, there are other, better choices than C99 and C11. -- 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]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-28 22:08 +1200 |
| Message-ID | <d1p2k3FohsbU7@mid.individual.net> |
| In reply to | #66482 |
Richard Heathfield wrote: > On 28/07/15 09:32, Ian Collins wrote: > > <snip> > >> I don't think people are saying that you shouldn't be allowed to use >> C90, your reasons are sound. What does surprise some of us is you not >> seeing any advantage in the new features added to C99. > > > Would I look at those features differently if they were enshrined in a > different language? Perhaps, although seriously I don't think that any > of them are much to write home about. Are any of them attractive enough > to persuade me to favour such a language over not only the huge > portability of C90 but also the enormous toy-box of C++? No, I don't > think so. I'm surprised that you find that surprising. If one doesn't > have to worry quite so much about portability, there are other, better > choices than C99 and C11. If you put it that way, no I'm not. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-28 18:17 -0700 |
| Message-ID | <37ce4d52-8813-41d6-860c-5517170ec73e@googlegroups.com> |
| In reply to | #66487 |
On Tuesday, July 28, 2015 at 3:08:20 AM UTC-7, Ian Collins wrote: > Richard Heathfield wrote: > > On 28/07/15 09:32, Ian Collins wrote: > > > > <snip> > > > >> I don't think people are saying that you shouldn't be allowed to use > >> C90, your reasons are sound. What does surprise some of us is you not > >> seeing any advantage in the new features added to C99. > > > > > > Would I look at those features differently if they were enshrined in a > > different language? Perhaps, although seriously I don't think that any > > of them are much to write home about. Are any of them attractive enough > > to persuade me to favour such a language over not only the huge > > portability of C90 but also the enormous toy-box of C++? No, I don't > > think so. I'm surprised that you find that surprising. If one doesn't > > have to worry quite so much about portability, there are other, better > > choices than C99 and C11. I have been reading source code from what I call the GTK community. The code I am reading is used in Gnome software. I don't know what other communities might exist that use strictly C90. I caught them using a gcc extension once but never any C99 or C11. I have no idea how to gather statistics on this matter but it is my feeling that most (whatever that means) C programming is C90 programming. Measured in, for example, lines of code written. I feel strongly enough that this is the case to say that the burden of proof is on anyone who says there is any significant use of C99 or C11. Not that it matters much but C90 would make things simpler.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-29 12:14 -0400 |
| Message-ID | <55B8FC02.8090800@verizon.net> |
| In reply to | #66478 |
On 07/28/2015 02:06 AM, Richard Heathfield wrote: > On 28/07/15 05:51, James Kuyper wrote: >> On 07/27/2015 11:57 PM, Richard Heathfield wrote: >>> ... If we're going to make a whizzy new language that has exciting >>> features like BCPL-style comments and an absence of gets() and dozens of >>> other very splendid and worthwhile wossnames, that's brilliant! But >>> let's find a new name for it, and let's use this new language to /add/ >>> to the number of available languages, not to replace something that has >>> a very important part still to play. >> >> Are you trying to imply that you might have actually started writing >> some programs in C99, if it had, instead, been given a name that >> distinguished it completely from C90? If so, I don't believe you. > > No, I'm not trying to imply anything. I'll be quite candid about it. > Would I have found a use for this new language? No, certainly not. Would > others? Apparently so. And that's fine by me. I'm all for people being > able to program in the language in which they wish to program. Me, I > favour C90, for reasons stated over and over again. What surprises me is > that so many people are seemingly so determined that I shouldn't be > allowed to, at least not without being treated like some kind of Luddite. No one's saying you shouldn't be allowed to choose which version of which language you want to use. I'm just saying that your recent explanations for your choice are unreasonable. You're not a Luddite, but only because Luddites used violence and destruction of property to advance their goals. Otherwise, the term is a pretty good fit. >> C99 has it's own name, "C99", distinct from "C90". It's not sufficiently >> distinct for your preferences, but it's also not sufficiently different >> to treat as an entirely new language. And, more directly to the point, >> C99 was intended, ideally, to replace C90, just like C90 almost >> completely replaced K&R C. I don't agree that it would have been a bad >> thing for it to succeed in doing so - though success would almost >> certainly have required modifying the list of features added in C99. > > If it /had/, that might have been a different matter. But it didn't. It's not clear from your objections that there is any possible modification to the list of features which were added since C90, which would have led to you accepting the latest version as a replacement for C90. Each of those changes occurred precisely because a solid majority (and in most cases a super-majority) of a bunch of C experts thought, after considerable debate, that they were a good ideas. They've made mistakes, and they may have made many more than I'm personally aware of - but the idea that every single one of those decisions was a mistake just isn't plausible (particularly since I know what those particular decisions were). Since you have said you don't approve of any of those changes, none of them could be on the modified list. Assuming the modified list isn't simply empty, every single change on that list would have to be one that the C committee either never heard about, or rejected as being not worthwhile, at least in comparison with the changes that were actually approved. In other words, your judgment on every item in the modified list, and every item on the actual list of changes, must be exactly the opposite of the C committee's judgment. That strikes me as so implausible that I must favor a different explanation: you're simply prejudiced against making any changes to C whatsoever. And that must indeed be a prejudice, not a reasoned judgment, because the idea that C as originally standardized was so perfect that it could not be improved upon is just plain ridiculous. I'm sure you'll deny the prejudice, and deny believing that C can't be improved upon - but your rejection of every single new feature of C is in conflict with those denials. Alternatively, since you've admitted to being prone to exaggeration, perhaps you do approve of a few features, but are unwilling to admit it. But if you approve of so few of the new features that you're willing to claim to approve of none of them, you should wear the label "Luddite" with pride.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-07-29 11:27 -0500 |
| Message-ID | <mpaura$1sr$1@dont-email.me> |
| In reply to | #66531 |
On 7/29/2015 11:14 AM, James Kuyper wrote: > On 07/28/2015 02:06 AM, Richard Heathfield wrote: >> On 28/07/15 05:51, James Kuyper wrote: >>> C99 has it's own name, "C99", distinct from "C90". It's not sufficiently >>> distinct for your preferences, but it's also not sufficiently different >>> to treat as an entirely new language. And, more directly to the point, >>> C99 was intended, ideally, to replace C90, just like C90 almost >>> completely replaced K&R C. I don't agree that it would have been a bad >>> thing for it to succeed in doing so - though success would almost >>> certainly have required modifying the list of features added in C99. >> >> If it /had/, that might have been a different matter. But it didn't. > > It's not clear from your objections that there is any possible > modification to the list of features which were added since C90, which > would have led to you accepting the latest version as a replacement for > C90. Each of those changes occurred precisely because a solid majority > (and in most cases a super-majority) of a bunch of C experts thought, > after considerable debate, that they were a good ideas. They've made > mistakes, and they may have made many more than I'm personally aware of > - but the idea that every single one of those decisions was a mistake > just isn't plausible (particularly since I know what those particular > decisions were). > > Since you have said you don't approve of any of those changes, none of > them could be on the modified list. Assuming the modified list isn't > simply empty, every single change on that list would have to be one that > the C committee either never heard about, or rejected as being not > worthwhile, at least in comparison with the changes that were actually > approved. In other words, your judgment on every item in the modified > list, and every item on the actual list of changes, must be exactly the > opposite of the C committee's judgment. > > That strikes me as so implausible that I must favor a different > explanation: you're simply prejudiced against making any changes to C > whatsoever. And that must indeed be a prejudice, not a reasoned > judgment, because the idea that C as originally standardized was so > perfect that it could not be improved upon is just plain ridiculous. I could be wrong, but I think his position isn't that C can't be improved upon, but that the cost of any improvements would/did outweigh any benefits. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-29 13:01 -0400 |
| Message-ID | <55B906DA.6040205@verizon.net> |
| In reply to | #66532 |
On 07/29/2015 12:27 PM, Martin Shobe wrote: > On 7/29/2015 11:14 AM, James Kuyper wrote: ... >> It's not clear from your objections that there is any possible >> modification to the list of features which were added since C90, which >> would have led to you accepting the latest version as a replacement for >> C90. Each of those changes occurred precisely because a solid majority >> (and in most cases a super-majority) of a bunch of C experts thought, >> after considerable debate, that they were a good ideas. They've made >> mistakes, and they may have made many more than I'm personally aware of >> - but the idea that every single one of those decisions was a mistake >> just isn't plausible (particularly since I know what those particular >> decisions were). >> >> Since you have said you don't approve of any of those changes, none of >> them could be on the modified list. Assuming the modified list isn't >> simply empty, every single change on that list would have to be one that >> the C committee either never heard about, or rejected as being not >> worthwhile, at least in comparison with the changes that were actually >> approved. In other words, your judgment on every item in the modified >> list, and every item on the actual list of changes, must be exactly the >> opposite of the C committee's judgment. >> >> That strikes me as so implausible that I must favor a different >> explanation: you're simply prejudiced against making any changes to C >> whatsoever. And that must indeed be a prejudice, not a reasoned >> judgment, because the idea that C as originally standardized was so >> perfect that it could not be improved upon is just plain ridiculous. > > I could be wrong, but I think his position isn't that C can't be > improved upon, but that the cost of any improvements would/did outweigh > any benefits. He claims that to be true of every single change that has ever been approved to C - it's the universality of that claim which makes it suspect; particularly since the people who approved those changes weren't complete idiots.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-29 17:33 +0100 |
| Message-ID | <mpav6m$3a6$1@dont-email.me> |
| In reply to | #66531 |
On 29/07/2015 17:14, James Kuyper wrote: > On 07/28/2015 02:06 AM, Richard Heathfield wrote: >> No, I'm not trying to imply anything. I'll be quite candid about it. >> Would I have found a use for this new language? No, certainly not. Would >> others? Apparently so. And that's fine by me. I'm all for people being >> able to program in the language in which they wish to program. Me, I >> favour C90, for reasons stated over and over again. What surprises me is >> that so many people are seemingly so determined that I shouldn't be >> allowed to, at least not without being treated like some kind of Luddite. .... >Alternatively, since you've admitted to > being prone to exaggeration, perhaps you do approve of a few features, > but are unwilling to admit it. But if you approve of so few of the new > features that you're willing to claim to approve of none of them, you > should wear the label "Luddite" with pride. The Luddites are 'Frank and Jill and Dai and Marie-Claire and Olu', who apparently refuse to upgrade their C compilers forcing people who send them source code to write to the earlier standard. That's what I understood anyway. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-29 21:07 +0100 |
| Message-ID | <mpbbnm$nca$1@dont-email.me> |
| In reply to | #66531 |
On 29/07/15 17:14, James Kuyper wrote:
> On 07/28/2015 02:06 AM, Richard Heathfield wrote:
>> On 28/07/15 05:51, James Kuyper wrote:
>>> On 07/27/2015 11:57 PM, Richard Heathfield wrote:
>>>> ... If we're going to make a whizzy new language that has exciting
>>>> features like BCPL-style comments and an absence of gets() and dozens of
>>>> other very splendid and worthwhile wossnames, that's brilliant! But
>>>> let's find a new name for it, and let's use this new language to /add/
>>>> to the number of available languages, not to replace something that has
>>>> a very important part still to play.
>>>
>>> Are you trying to imply that you might have actually started writing
>>> some programs in C99, if it had, instead, been given a name that
>>> distinguished it completely from C90? If so, I don't believe you.
>>
>> No, I'm not trying to imply anything. I'll be quite candid about it.
>> Would I have found a use for this new language? No, certainly not. Would
>> others? Apparently so. And that's fine by me. I'm all for people being
>> able to program in the language in which they wish to program. Me, I
>> favour C90, for reasons stated over and over again. What surprises me is
>> that so many people are seemingly so determined that I shouldn't be
>> allowed to, at least not without being treated like some kind of Luddite.
>
> No one's saying you shouldn't be allowed to choose which version of
> which language you want to use. I'm just saying that your recent
> explanations for your choice are unreasonable. You're not a Luddite, but
> only because Luddites used violence and destruction of property to
> advance their goals. Otherwise, the term is a pretty good fit.
It's all about getting the job done. How important is portability to
you? If it's very, very important, then you will be wary of using any
feature that might not be implemented on all the machines where your
code will be compiled. If it's not at all important, you will feel free
to use any feature you like, including even compiler-specific features.
And of course, in between, there is a gamut.
For me, portability is very, very important, and it's far /more/
important than trivial new features. If that makes me a Luddite, so be it.
<snip>
> It's not clear from your objections that there is any possible
> modification to the list of features which were added since C90, which
> would have led to you accepting the latest version as a replacement for
> C90.
Oh, I apologise. I do not believe there is any such modification
(except, perhaps, for the removal of gets() and implicit int).
> Each of those changes occurred precisely because a solid majority
> (and in most cases a super-majority) of a bunch of C experts thought,
> after considerable debate, that they were a good ideas. They've made
> mistakes, and they may have made many more than I'm personally aware of
> - but the idea that every single one of those decisions was a mistake
> just isn't plausible (particularly since I know what those particular
> decisions were).
I don't think for a moment that they were mistakes /from the perspective
of ISO/, but they resulted in a language that isn't portable enough when
I *most* need portability, and not powerful enough when I *most* need power.
<snip>
> That strikes me as so implausible that I must favor a different
> explanation: you're simply prejudiced against making any changes to C
> whatsoever. And that must indeed be a prejudice, not a reasoned
> judgment, because the idea that C as originally standardized was so
> perfect that it could not be improved upon is just plain ridiculous.
I would argue that it is a reasoned judgement *even though* C90 isn't
perfect. C90 /must/ remain, for the *practical* reason that it works
everywhere. For me, the ability to write /*this*/ like //this
isn't sufficient compensation for one of my users no longer being able
to compile my code.
So yes, I'm against making changes to C. If it weren't so darn
ubiquitous, I wouldn't care. You can make all the changes you like to,
say, Haskell, and I won't bat an eyelid. But it is precisely because C90
/is/ ubiquitous that it is unique. No other language is so widely
implemented on so many different machine types.
If you could *guarantee* that you could get C99 or C11 implemented on
every single machine type that C90 is implemented on, then - well, I'd
believe it when I saw it, but yes, that would work.
> I'm sure you'll deny the prejudice, and deny believing that C can't be
> improved upon - but your rejection of every single new feature of C is
> in conflict with those denials.
Do I deny the prejudice? I'm not sure. I think it's a rational attitude
based on portability criteria. I write for what's out there, not for
what ISO says ought to be out there. And what's out there, *everywhere*,
is C90.
It isn't because C90 is perfect that it shouldn't be changed (C90 is far
from perfect); it is because you can't just wave a magic wand and
upgrade every implementation currently in use.
> Alternatively, since you've admitted to
> being prone to exaggeration,
No, I've never done that. Never. Ever. Not even once.
Well, maybe once.
Or perhaps twice. Tops.
> perhaps you do approve of a few features,
> but are unwilling to admit it.
No, I don't think so. I really can't think of any that are actually
worth anything *to me*. I don't find myself thinking "Darn it! If only I
didn't have to be portable, I could use an int_least32_t here!" I just
don't. I see all you folks using these features all the time, and you
all seem to think they're terribly important, and that's fine, but not
everybody holds that view. I think they're trivial and pointless. And,
when push comes to shove, let's face it - if portability *isn't* a
concern, why use C at all? C++ has more toys.
> But if you approve of so few of the new
> features that you're willing to claim to approve of none of them, you
> should wear the label "Luddite" with pride.
I'll get a badge made up.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Chairman, C90 Luddites Association ("Bring Your Own Hammer")
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-29 16:33 -0400 |
| Message-ID | <55B93886.8090701@verizon.net> |
| In reply to | #66537 |
On 07/29/2015 04:07 PM, Richard Heathfield wrote: ... > No, I don't think so. I really can't think of any that are actually > worth anything *to me*. I don't find myself thinking "Darn it! If only I > didn't have to be portable, I could use an int_least32_t here!" I just > don't. ... The size-named types are one my favorite additions (though I dislike the clumsy naming convention). I frequently find myself often wanting for example, a type that is, portably, "the fastest signed type with at least 16 bits", and annoyed by the fact that C90 has no such type.The key difference is that I respond to this by saying to those who want me to write code for them, that they should get a compiler that supports C99 (which, simply because they keep their software up-to-date, they already have) and that they should give me permission to use C99 (which they haven't - but mainly through inaction, not as a matter of deliberate choice). You respond by saying "I can't use these features". Neither of us actually gets to use the new features :-(, but you seem to prefer it that way. > ... I see all you folks using these features all the time, and you > all seem to think they're terribly important, and that's fine, but not > everybody holds that view. I think they're trivial and pointless. And, > when push comes to shove, let's face it - if portability *isn't* a > concern, why use C at all? C++ has more toys. I don't have permission to use C++ for MODIS code; I'm required to use it for NPP VIIRS code. C++ has lots of nice features I want to use, and in principle many of those features should make it easier to write code that is more maintainable, at least if they're used right (a major caveat). However, either I'm getting dumber in my old age (not implausible), or that promise has not been achieved, at least not in code base I'm working on.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-29 22:12 +0100 |
| Message-ID | <mpbfgr$6sf$1@dont-email.me> |
| In reply to | #66538 |
On 29/07/15 21:33, James Kuyper wrote: > On 07/29/2015 04:07 PM, Richard Heathfield wrote: > ... >> No, I don't think so. I really can't think of any that are actually >> worth anything *to me*. I don't find myself thinking "Darn it! If only I >> didn't have to be portable, I could use an int_least32_t here!" I just >> don't. ... > > The size-named types are one my favorite additions (though I dislike the > clumsy naming convention). I think the important point here is that there is plenty of diversity within the programming community, and what one person finds essential is, to another, of no consequence. How can a single language meet every need? I argue that it can't. On the other hand, we don't want one language per programmer, either! So yes, I do understand why some people want to add new features to C. It's just that, to some /other/ people, this is a backward step. Whenever you change a language, you are going to make it more acceptable to some, but less acceptable to others. But that is in the nature of change, is it not? <snip> -- 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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-29 23:50 +0100 |
| Message-ID | <871tfq60jm.fsf@bsb.me.uk> |
| In reply to | #66537 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 29/07/15 17:14, James Kuyper wrote: <snip> >> That strikes me as so implausible that I must favor a different >> explanation: you're simply prejudiced against making any changes to C >> whatsoever. And that must indeed be a prejudice, not a reasoned >> judgment, because the idea that C as originally standardized was so >> perfect that it could not be improved upon is just plain ridiculous. > > I would argue that it is a reasoned judgement *even though* C90 isn't > perfect. C90 /must/ remain, for the *practical* reason that it works > everywhere. For me, the ability to write /*this*/ like //this > isn't sufficient compensation for one of my users no longer being able > to compile my code. But your ability to write //this rather than /*this*/ does not prevent a single user from compiling your code. You say your position is a reasoned one, but those reasons appear to support the idea that you should not use any features of C not in C90, not that all of the changes in C99 and C11 are inherently detrimental. > So yes, I'm against making changes to C. This is not (yet) supported by reasoned argument. Your position can't be "I'm against making changes to C that are incompatible with C90" or you'd be railing again restrict and not much bothered by most of the other additions. (Ironically, two of the changes that are *not* backwards-compatible (the removal of gets and implicit int) are singled out by you as being possible *exceptions* to your otherwise universal opprobrium.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 00:13 +0100 |
| Message-ID | <mpbmjv$1nt$1@dont-email.me> |
| In reply to | #66540 |
On 29/07/15 23:50, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 29/07/15 17:14, James Kuyper wrote: > <snip> >>> That strikes me as so implausible that I must favor a different >>> explanation: you're simply prejudiced against making any changes to C >>> whatsoever. And that must indeed be a prejudice, not a reasoned >>> judgment, because the idea that C as originally standardized was so >>> perfect that it could not be improved upon is just plain ridiculous. >> >> I would argue that it is a reasoned judgement *even though* C90 isn't >> perfect. C90 /must/ remain, for the *practical* reason that it works >> everywhere. For me, the ability to write /*this*/ like //this >> isn't sufficient compensation for one of my users no longer being able >> to compile my code. > > But your ability to write //this rather than /*this*/ > does not prevent a single user from compiling your code. Because it's you saying it, I'm trying hard to see some sense in what you say, but I'm afraid I'm failing. Okay, let's try this: it's certainly true that the ability itself doesn't prevent a user from compiling my code *provided that* I do not avail myself of that ability - and indeed that's the route I take. But somehow I don't think that's what you mean. Or you could mean that the user could always edit the code to change // comments to /* */ comments. That's true, too. But I hope that's not what you mean, because a wholesale adoption of C99 could mean a fairly hefty rewriting exercise for the user who only had a C90 compiler. So no, I'm not seeing your point. Sorry. No doubt I'm being obtuse, but I assure you it's not deliberate. > You say your > position is a reasoned one, but those reasons appear to support the idea > that you should not use any features of C not in C90, Yes. <overlord alignment="evil">And therefore everyone else in the world must also not use any features of C not in C90.</overlord> Well, maybe I don't quite mean that. But for me, yes, absolutely. > not that all of the changes in C99 and C11 are inherently detrimental. I think they're detrimental only in the sense that they have split the language. Thought experiment: take any C99 or C11 feature, and imagine that C had it all along, right back to K&R C days. Would I think it was a bad feature? I doubt it very much. So it isn't the things that are changing, but the fact of the change, that is the problem (for me). > >> So yes, I'm against making changes to C. > > This is not (yet) supported by reasoned argument. Your position can't > be "I'm against making changes to C that are incompatible with C90" or > you'd be railing again restrict I did all that, a few years ago. It didn't seem to help. :-) > and not much bothered by most of the > other additions. (Ironically, two of the changes that are *not* > backwards-compatible (the removal of gets and implicit int) are singled > out by you as being possible *exceptions* to your otherwise universal > opprobrium.) I'm not so interested in backward compatibility with an existing code base (although of course that's a very important point in general) as I am in the ability of anyone with (at least) a C90 compiler to be able to compile my code - i.e. I have to maintain backward compatibility with users' compilers. I stopped using gets() just as soon as I learned how dangerous it was, and I never bothered with implicit int, so I don't really care about those featurectomies, because they don't affect my code one jot, and in any case it is surely true on general principles that any code using gets() or implicit int ought to be rewritten. -- 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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-30 01:49 +0100 |
| Message-ID | <87pp3a4ghd.fsf@bsb.me.uk> |
| In reply to | #66541 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 29/07/15 23:50, Ben Bacarisse wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 29/07/15 17:14, James Kuyper wrote: >> <snip> >>>> That strikes me as so implausible that I must favor a different >>>> explanation: you're simply prejudiced against making any changes to C >>>> whatsoever. And that must indeed be a prejudice, not a reasoned >>>> judgment, because the idea that C as originally standardized was so >>>> perfect that it could not be improved upon is just plain ridiculous. >>> >>> I would argue that it is a reasoned judgement *even though* C90 isn't >>> perfect. C90 /must/ remain, for the *practical* reason that it works >>> everywhere. For me, the ability to write /*this*/ like //this >>> isn't sufficient compensation for one of my users no longer being able >>> to compile my code. >> >> But your ability to write //this rather than /*this*/ >> does not prevent a single user from compiling your code. > > Because it's you saying it, I'm trying hard to see some sense in what > you say, but I'm afraid I'm failing. Okay, let's try this: it's > certainly true that the ability itself doesn't prevent a user from > compiling my code *provided that* I do not avail myself of that > ability - and indeed that's the route I take. But somehow I don't > think that's what you mean. No, that's exactly what I mean. You are railing against changes that you do not need to avail yourself of. I have no complaint about your rational choice to use the smallest practical subset of C that suits your needs, but what is your argument against the growth of C in ways that are not incompatible with that? <snip> >>> So yes, I'm against making changes to C. >> >> This is not (yet) supported by reasoned argument. Your position can't >> be "I'm against making changes to C that are incompatible with C90" or >> you'd be railing again restrict <snip> >> and not much bothered by most of the >> other additions. <snip> > I'm not so interested in backward compatibility with an existing code > base (although of course that's a very important point in general) as > I am in the ability of anyone with (at least) a C90 compiler to be > able to compile my code - i.e. I have to maintain backward > compatibility with users' compilers. Yes, I get that, but in what way does, say, the presence of type-generic maths functions in C99 impact on your goal of having anyone compile your code? You are against making changes to C, but all the reasoning seems to relate only to why you should not use these new features. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web