Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #124080 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2017-12-09 16:20 -0800 |
| Last post | 2017-12-24 21:04 -0800 |
| Articles | 20 on this page of 320 — 28 participants |
Back to article view | Back to comp.lang.c
Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-09 16:20 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-10 00:31 +0000
Re: Auto-execute code at exit? gordonb.k2333@burditt.org (Gordon Burditt) - 2017-12-09 20:40 -0600
Re: Auto-execute code at exit? fir <profesor.fir@gmail.com> - 2017-12-10 02:21 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-10 11:50 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 04:19 -0800
Re: Auto-execute code at exit? fir <profesor.fir@gmail.com> - 2017-12-10 04:32 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 04:43 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 05:03 -0800
Who's a troll now? (Was: Auto-execute code at exit?) gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-10 14:01 +0000
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 15:19 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 15:46 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:04 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:35 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:09 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 20:28 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:38 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:07 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 11:45 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 13:50 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 19:29 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-13 08:52 +1300
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 23:04 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 21:08 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 21:40 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 23:22 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-12 15:54 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 00:11 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 17:38 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 10:44 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-13 03:12 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 10:16 +0100
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-12 09:35 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 20:42 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:02 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-12 21:34 +1300
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 18:37 +0000
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-11 19:39 +0100
Re: Auto-execute code at exit? Gordon Burditt <gordon@hammy.burditt.org> - 2017-12-12 20:54 -0600
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-09 19:32 -0500
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-10 13:36 +1300
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-09 17:14 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-09 21:49 -0700
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-10 11:04 +0100
Re: Auto-execute code at exit? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-12-10 20:22 +0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-10 18:10 +0100
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-10 20:48 +0000
Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-10 10:59 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-10 20:37 +0100
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-10 15:58 -0500
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-10 22:59 +0000
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-11 02:34 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 15:33 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-11 16:42 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 15:52 +0000
Re: Auto-execute code at exit? gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-11 15:53 +0000
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-11 17:09 +0100
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:18 -0800
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-11 19:04 +0100
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:19 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 17:26 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 09:40 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:09 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:07 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 20:18 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:27 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-11 13:42 -0700
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:54 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-11 19:34 -0700
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-11 17:46 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-11 19:31 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:48 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:36 +0100
Re: Auto-execute code at exit? gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-11 18:49 +0000
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 20:33 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:39 -0800
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 21:22 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 13:25 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 05:45 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:00 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 13:13 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:45 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-12 10:46 +1300
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 14:04 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 05:42 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 13:53 -0800
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 21:21 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:53 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:01 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:00 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:01 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 20:44 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:52 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:16 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 13:24 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:55 +0100
Re: Auto-execute code at exit? Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2017-12-11 22:00 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:43 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:52 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-11 21:41 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 22:33 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-12 01:17 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 01:44 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 10:01 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 11:17 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-12 03:40 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 12:01 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-12 04:50 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-12 18:33 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 10:37 -0800
Re: Auto-execute code at exit? gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-12 21:43 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-12 11:31 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-12 20:09 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 13:56 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 19:44 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-13 09:07 +1300
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 23:28 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 00:08 +0000
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-13 01:42 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-13 16:35 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 10:55 +0000
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-13 11:04 +0000
Re: Auto-execute code at exit? Robert Wessel <robertwessel2@yahoo.com> - 2017-12-13 11:45 -0600
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 13:36 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-14 07:34 +1300
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-13 03:20 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 11:25 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 11:50 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 14:27 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 14:31 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 16:56 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 19:27 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 21:15 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 22:48 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-14 07:44 +0100
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-14 06:55 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-14 00:32 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-15 00:01 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-15 00:48 -0800
Why post to Usenet? (Was: Auto-execute code at exit?) gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-15 10:51 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-15 12:18 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-15 17:40 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-15 20:12 +0000
Re: Auto-execute code at exit? David Kleinecke <dkleinecke@gmail.com> - 2017-12-15 12:54 -0800
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-15 13:51 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-16 14:46 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-15 23:20 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-16 00:36 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-16 01:34 +0000
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-16 20:06 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-17 17:33 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-17 21:35 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-17 15:06 -0800
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-18 12:41 +1300
Re: Auto-execute code at exit? Robert Wessel <robertwessel2@yahoo.com> - 2017-12-18 03:36 -0600
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 11:51 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 12:02 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 12:43 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 15:07 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 16:07 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 20:50 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 13:57 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 15:36 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 21:04 +0100
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 09:08 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 20:51 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 15:37 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 16:28 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 10:59 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 19:35 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 19:55 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 20:48 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-18 13:03 -0800
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 21:14 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 00:08 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 16:58 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:28 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-19 14:35 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:45 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-19 01:49 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 02:54 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-19 14:45 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-19 07:48 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 16:00 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-19 17:42 +0100
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-19 17:19 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-19 09:43 -0800
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-19 18:57 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-19 09:33 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 18:34 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-19 11:05 -0800
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-18 21:09 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 20:38 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-19 13:35 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:00 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-19 14:04 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 13:42 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 15:52 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 15:42 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-20 08:16 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 18:25 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-20 10:48 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 20:43 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-20 12:44 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-21 15:18 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-21 09:45 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-21 20:08 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-21 12:33 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-21 22:42 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-21 15:20 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-22 09:57 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-22 08:21 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-23 13:32 +0100
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-23 19:35 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-26 12:08 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-26 12:36 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-27 10:38 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-27 08:14 -0800
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-27 09:50 -0500
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-20 12:12 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 18:16 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 19:41 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 22:52 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-20 15:39 -0800
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-21 13:02 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 00:50 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-20 18:22 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 12:10 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 13:10 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-21 20:55 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 21:37 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-22 01:50 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 12:14 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-22 17:01 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 17:34 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-22 09:52 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-22 12:02 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 20:18 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-22 12:39 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 23:10 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-22 17:05 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 02:17 +0000
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-22 22:14 -0500
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-23 14:43 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-23 14:31 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-24 09:45 +1300
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-23 16:28 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 11:23 +0000
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-23 13:24 -0500
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-24 09:29 +1300
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-21 20:57 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-21 13:11 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 21:58 +0000
Re: Auto-execute code at exit? jameskuyper@verizon.net - 2017-12-21 14:03 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 01:34 +0000
Re: Auto-execute code at exit? jameskuyper@verizon.net - 2017-12-22 07:55 -0800
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-22 16:41 +0000
Re: Auto-execute code at exit? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-12-22 12:46 -0500
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-23 11:57 +0000
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-23 08:12 -0500
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-23 21:02 +0000
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-23 16:13 -0500
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 22:15 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-23 14:45 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-23 15:47 -0800
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-23 19:34 -0500
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-24 12:08 +0000
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-24 12:11 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-24 12:17 +0000
Re: Auto-execute code at exit? jameskuyper@verizon.net - 2017-12-24 05:49 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-24 13:06 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-23 13:51 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 22:17 +0000
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-22 18:37 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 19:03 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-20 17:44 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 17:22 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:41 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-19 09:54 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 13:24 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-19 14:43 +0100
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-19 09:02 -0800
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-18 20:58 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 22:36 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 20:37 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 09:13 -0800
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 20:51 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 09:03 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-18 19:13 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 11:28 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 10:07 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-18 07:50 -0800
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-16 12:21 +1300
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-15 09:51 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-14 12:08 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-14 05:13 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-13 09:21 -0700
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 19:27 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 15:14 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 17:11 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-13 00:29 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-13 00:41 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-14 06:51 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-14 14:40 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-14 17:15 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-14 18:59 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:48 +0100
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-11 17:40 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 10:57 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 13:56 -0800
Re: Auto-execute code at exit? David Kleinecke <dkleinecke@gmail.com> - 2017-12-10 14:09 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 14:18 -0800
Re: Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-10 14:51 -0800
Re: Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-23 11:08 -0800
Re: Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-25 00:49 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 00:29 +0000
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-11 18:30 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:09 -0800
Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-10 15:05 -0800
Re: Auto-execute code at exit? mcheung63@gmail.com - 2017-12-24 21:04 -0800
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 10:55 +0000 |
| Message-ID | <AG7YB.159056$by1.58286@fx24.am4> |
| In reply to | #124262 |
On 13/12/2017 03:35, Ian Collins wrote: > On 12/13/2017 01:08 PM, bartc wrote: >> >> A one line example? Sure. The problem is when you're in the middle of >> 50,000 lines of someone else's horrendous code, and half the reason it >> is horrendous is because C ALLOWS IT. > > Can you name a useful general purpose language that prevents horrendous > code? > A good start would be not having a preprocessor like C's. (Look at the kinds of problems that the preprocessor solves, and see how the language can change to help make the subsequent macros unnecessary.) But I think it's meta-programming in general that is problematic. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-12-13 11:04 +0000 |
| Message-ID | <p0r1fa$v2h$1@news.albasani.net> |
| In reply to | #124273 |
On 2017-12-13, bartc <bc@freeuk.com> wrote: > On 13/12/2017 03:35, Ian Collins wrote: >> On 12/13/2017 01:08 PM, bartc wrote: >>> >>> A one line example? Sure. The problem is when you're in the middle of >>> 50,000 lines of someone else's horrendous code, and half the reason it >>> is horrendous is because C ALLOWS IT. >> >> Can you name a useful general purpose language that prevents horrendous >> code? >> > > A good start would be not having a preprocessor like C's. (Look at the > kinds of problems that the preprocessor solves, and see how the language > can change to help make the subsequent macros unnecessary.) > > But I think it's meta-programming in general that is problematic. > Well, show me language where horrendous code is immposible? COBOL? -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-12-13 11:45 -0600 |
| Message-ID | <jop23d9m4m74mor1lu4di5ih9dqm1v7a00@4ax.com> |
| In reply to | #124274 |
On Wed, 13 Dec 2017 11:04:10 +0000 (UTC), Melzzzzz <Melzzzzz@zzzzz.com> wrote: >On 2017-12-13, bartc <bc@freeuk.com> wrote: >> On 13/12/2017 03:35, Ian Collins wrote: >>> On 12/13/2017 01:08 PM, bartc wrote: >>>> >>>> A one line example? Sure. The problem is when you're in the middle of >>>> 50,000 lines of someone else's horrendous code, and half the reason it >>>> is horrendous is because C ALLOWS IT. >>> >>> Can you name a useful general purpose language that prevents horrendous >>> code? >>> >> >> A good start would be not having a preprocessor like C's. (Look at the >> kinds of problems that the preprocessor solves, and see how the language >> can change to help make the subsequent macros unnecessary.) >> >> But I think it's meta-programming in general that is problematic. >> >Well, show me language where horrendous code is immposible? COBOL? Trust me on this: horrible code is perfectly possible in Cobol...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 13:36 +0100 |
| Message-ID | <p0r6s5$20e$1@dont-email.me> |
| In reply to | #124273 |
On 13/12/17 11:55, bartc wrote: > On 13/12/2017 03:35, Ian Collins wrote: >> On 12/13/2017 01:08 PM, bartc wrote: >>> >>> A one line example? Sure. The problem is when you're in the middle of >>> 50,000 lines of someone else's horrendous code, and half the reason it >>> is horrendous is because C ALLOWS IT. >> >> Can you name a useful general purpose language that prevents >> horrendous code? >> > > A good start would be not having a preprocessor like C's. (Look at the > kinds of problems that the preprocessor solves, and see how the language > can change to help make the subsequent macros unnecessary.) > You have not answered Ian's question. > But I think it's meta-programming in general that is problematic. > Meta-programming, in general, can be a good way to write more structured and maintainable code with less copy-and-paste duplication. But it may mean you need to look at more code to understand the whole picture.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-14 07:34 +1300 |
| Message-ID | <f9da56F37deU11@mid.individual.net> |
| In reply to | #124273 |
On 12/13/2017 11:55 PM, bartc wrote: > On 13/12/2017 03:35, Ian Collins wrote: >> On 12/13/2017 01:08 PM, bartc wrote: >>> >>> A one line example? Sure. The problem is when you're in the middle of >>> 50,000 lines of someone else's horrendous code, and half the reason it >>> is horrendous is because C ALLOWS IT. >> >> Can you name a useful general purpose language that prevents horrendous >> code? >> > > A good start would be not having a preprocessor like C's. (Look at the > kinds of problems that the preprocessor solves, and see how the language > can change to help make the subsequent macros unnecessary.) Can you name a useful general purpose language that prevents horrendous code? > But I think it's meta-programming in general that is problematic. Meta-programming is fine but the C preprocessor is a poor meta-programming tool. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-12-13 03:20 -0800 |
| Message-ID | <fdf671b2-5080-440f-8581-9526d0f2d664@googlegroups.com> |
| In reply to | #124262 |
On Tuesday, December 12, 2017 at 10:35:46 PM UTC-5, Ian Collins wrote: > On 12/13/2017 01:08 PM, bartc wrote: > > > > A one line example? Sure. The problem is when you're in the middle of > > 50,000 lines of someone else's horrendous code, and half the reason it > > is horrendous is because C ALLOWS IT. > > Can you name a useful general purpose language that prevents horrendous > code? Most structured languages go a long way to prevent horrendous code, so long as there's a competent developer at the helm. But anybody could write purposefully horrendous code with some effort. It's just that some people have a knack for it. :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 11:25 +0100 |
| Message-ID | <p0qv5t$f2l$1@dont-email.me> |
| In reply to | #124254 |
On 13/12/17 01:08, bartc wrote: > On 12/12/2017 22:28, David Brown wrote: >> On 12/12/17 20:44, bartc wrote: >>> On 12/12/2017 12:56, David Brown wrote: >>>> On 12/12/17 12:17, bartc wrote: >>> >>>> I would say it is a flaw in your reading - or in your enthusiasm for >>>> posting. >>> >>> The point of my example was to show that the simplest example: >>> >>> 10 FOR I=1 TO 20 >>> 20 PRINT I,SQR(I) REM can't remember if "," or ";" >>> 30 NEXT I >>> >>> would be swamped in C by lots of irrelevant details and by excessive >>> punctuation, as shown by my comparison table. >> >> Well, if that was your point - it failed. There was no "swamping", > > Yes there was. Didn't you see the table which listed 23 extra special > symbols versus the 4 of my code? (Counting all tokens and format > elements, there 27 in C versus 11 in mine. Even with the revised one, > mine still had fewer elements.) > Yes, I saw the table. It is utterly irrelevant - so I ignored it. > and >> the C code was clear to anyone who has spent more than an hour trying >> to learn the language (rather than spending a decade trying to hate it). > > A one line example? Sure. The problem is when you're in the middle of > 50,000 lines of someone else's horrendous code, and half the reason it > is horrendous is because C ALLOWS IT. /Every/ language allows horrible code. /Every/ language (baring the silly ones) lets you write good code. It is the /programmer/ who makes the choices here - not the language. Do you really not understand that? Anyone who can write clear and understandable code in Pascal, Python, Bart's own languages, whatever, can /also/ write clear and understandable code in C. All they have to do is learn the language, and make the effort. Equally, anyone who writes a mess in C would /also/ write a mess if they were using Ada, Occam, Forth, or anything else. Any code for a purpose that is /hard/, is going to be more difficult to follow than code for easy purposes. Any code that is hard will need more context to make sense. Which tasks are easy or hard will vary between languages - some things are much easier and (and therefore clearer) in C than in Python, and vice versa. How can you, with your decades of experience as a programmer, not understand this? Are you so blinded by your hate of C (and C++, and who knows what else), or so arrogant and narcissistic about your own brilliance as a programming language designer, that you fail to understand this? At university, I learned about /programming/. Not "coding in C", or "software development in Modula 2" - /programming/. The actual language involved was a detail. If the teacher liked Modula 2, we learned the details of Modula 2 in a couple of days, and used that for the code. If the course was about provably correct coding, we used functional programming languages because they are better suited to the task. If it was about operating systems design, we used C because /that/ was more appropriate. You can write good code in /any/ language - and you can write /bad/ code in any language. The number of semicolons (or whatever your hobby-horse is) is absolutely and utterly irrelevant. > >> And once the code went a step beyond the very simple example, the C >> code was still clear and obvious, fitting the same pattern - while >> your own language needed a complete re-write. > > You've got that back to front. In the two code fragments, with the C you > had to write the more complicated code both times, with mine only once. Wrong - the C is not more complicated. It is like claiming the word "complicated" is more complicated than "complicd" just because it has more letters. > > But if you are talking about things that need rewriting, let's take a > look at C: > > (1) In-place declarations: you decide you need to use a certain variable > earlier on, you now have to move the declaration. And if you forget, and > it shadows an outer one, yet get a bug. [Mine: there are no block scopes > and variables can be declared out of order, so it can't happen.] You put your declarations where you need them. If you wander about your functions aimlessly, putting in bits here or moving bits there and accidentally shadowing your data, then you are in the wrong job - you are not structured enough to be a programmer. And if moving a declaration when a change requires it is a big job, then you are also in the wrong profession - change to something that doesn't need a screen and a keyboard. > > (2) Function signature: change the parameters in the definition (not > enough to need to change any calls), and you need change the > corresponding declaration in a header or a forward declaration in the > file. [Mine: there are no separate declarations needed, so no extra work.] If I change the definition of a function's interface, I change its declaration. Why would you possibly want to have them different? And if you change a function's interface, it is not the declaration line that is the extra effort - it where the function is /used/ that is important. The declaration (in a header) means this is all clear and documented, and the tools can automate checking. I /want/ to have to write declarations in headers - it is not "extra work", it is an important feature. > > (3) Function signature: you decide one or two calls need an extra > parameter. You need to add the parameter to the definition, then you > need to change any declarations as in (2), but also you have to update > EVERY call to the function. [Mine: an extra parameter can be added as an > optional parameter with a default value, so that only calls using that > parameter need changing.] Allowing parameters with defaults (like in C++) would be a nice feature. But I would be unlikely to add a new parameter to a function without also checking the call sites anyway. (I have development tools - such as IDEs that understand the whole program, and multi-file search, so that the mechanics of this are not time-consuming. It is the thought processes involved that usually take the time.) > > (4) Print formats: change the type of some variable, and the format code > of every printf involving that variable or an expression using that > variable, may need updating. [Mine: the built-in print statement doesn't > use format codes. This is only relevant when I call sprintf, and that is > rare compared to the use of built-in print.] I don't often change the type of a variable. I don't declare a variable until I know what I am going to do with it, so types are usually fixed. Occasionally I will have a type that can change, perhaps dependent on how the code is to be compiled. Any necessary formatting would be done in a single function - if you have format codes scattered around the code and need to change them often, you have poor code structure. A print method without needing formatting strings can be a handy shortcut for temporary code such as debug prints. > > (5) Move or insert functions within a module, and you may need to add > forward declarations if a function calls another later on in the module. > Or you need to spend timing re-ordering the functions. [Mine: functions > can be defined in any order.] I don't need to do either. In almost all cases, I have functions defined in code before they are called. The only stand-alone function declarations I normally need are in the headers - and I /want/ to write these. Other functions within a module are all static, and don't need forward declarations. I can appreciate that other people like to order functions in their code differently. They will then have to have forward declarations for their static functions at least some of the time. I can't see it as a big hardship, but maybe some do. I would not complain if static functions (and file-scope variables, typedefs, etc.) had their scope extended to the entire compilation unit. I'd hazard a guess that there would be incompatibilities or conflicts somewhere, if it were made the rule. > > (6) The same applies to shared variables as to the functions in (2): > change a detail of the type, and both declarations needed updating. > Sometimes you might get away with having a single declaration, if a > variable is not initialised, but that means hiding the declaration in a > header instead of in its home module. [Mine: a shared variable, even > initialised, is declared once in its home module where it belongs.] > > (7) Parallel tables: You have a set of enums, and matching sets of > parallel arrays (names), values etc which have to correspond. Add, > delete, insert or move entries, and all arrays must be adjusted. > Sometimes, macro techniques can be used to all updates in one place, but > the macro must be devised, and it adds an extra level of obfuscation to > the code. [Mine: a built-in language feature exactly this kinds of > tables to be easily created and updated. No macros needed] Macro techniques are used to make this sort of thing /easier/ and /clearer/ - it is not "obfuscation". You just get your knickers in a twist every time you see a macro, and therefore /think/ it is hard. I'd like to be able to do things like declare an array indexed by an enumeration, or access the names of enumerators in the code. It is not going to happen in C - that would mean massive changes to the way the language works. (It will be possible in C++, once reflection and metaclasses are in place - possibly C++20, more likely C++23.) > > (8) Things like sizeof(A)/sizeof(A[0]), min, max, swap etc all require a > million programmers to reinvent macros for them every time (either that > or they have to keep rewriting that boilerplate code, even worse). > [Mine: this stuff is all built-in] Yes, people must waste literally /hundreds/ of seconds here. > > That'll do I think. > > I'm sure you won't be convinced and that C is still superior to anything > I might think up. > Superior than anything /you/ might think up? Yes, I have no doubts. Superior than anything groups of people could think up? No, C is not perfect - but it is good enough for the job, which is really all it needs to be. I am sure you /could/ be good at language design if you were willing to open your mind a bit, drop your ridiculous prejudices and pre-conceptions, and try understanding a few languages. If you looked at how macros can be used, you might appreciate them more instead of knee-jerk panic reactions every time you see one. If you didn't run away screaming when you see a template, you might learn something from C++. If you weren't so obsessed that your programming habits and preferences are somehow superior to the rest of the world, you might look at modern C in modern styles and get inspiration. As it is, you have a number of good ideas - none of which are new, but they are nice anyway. But they are crushed beneath your hatred and condemnation of other language features. Your outlook is so knee-jerk negative that you can't see that things in C might be the way they are for /good/ reasons, and used to write /good/ code, and that people might like them. You also fail to see that there are many things in C that are not ideal, and would be done differently in a new language - but nonetheless they cannot be changed. > >> If you are writing the same code in your two different private >> languages, then you need to write it within their limitations. I >> write in C, and thus don't have that problem. > > Try writing in C, then porting it to Python. That's effectively what I'm > doing here. Good luck doing it with a sizeable block of code with no > changes (but no doubt you will have some hairy Python2C tool to do the > job!). C and Python serve different purposes. That's why I use both languages. I can't think of anything beyond the occasional small function where I would want the same program in C and in Python. > > But more usually I go the other way, so trying taking Python code, and > port it to C. I will have an easier job with my two languages as the > syntax is largely the same. Even less rewriting to do. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 11:50 +0000 |
| Message-ID | <6u8YB.165519$0a2.132359@fx27.am4> |
| In reply to | #124271 |
On 13/12/2017 10:25, David Brown wrote:
> On 13/12/17 01:08, bartc wrote:
> Yes, I saw the table. It is utterly irrelevant - so I ignored it.
OK. That's a good way of winning an argument - just ignore the evidence.
Unfortunately as a very clumsy typist I can't ignore it.
> Any code for a purpose that is /hard/, is going to be more difficult to
> follow than code for easy purposes.
You have that. But then you have extra things thrown in (macros in C,
templates in C++, meta-classes in Python) just for the hell of it.
The number of semicolons (or whatever
> your hobby-horse is) is absolutely and utterly irrelevant.
That must be why Python has done away with them.
That's why Go has done away with them.
That's why Rust has done away with them.
That's why Javascript has away with them.
That would be an extraordinary waste of effort if semicolons are as
irrelevant as you claim. So is it possible that you don't know what you
are talking about?
You seem to want to argue the opposite of everything I say, just for the
same of it.
Half of all syntax errors I get when writing fresh C code are to do with
missing semicolons. /You/ probably use some tool to insert them for you.
But why, in that case, couldn't all those languages have stipulated
using the same tools? Is it because languages should stand up by themselves?
>> (7) Parallel tables: You have a set of enums, and matching sets of
>> parallel arrays (names), values etc which have to correspond. Add,
>> delete, insert or move entries, and all arrays must be adjusted.
>> Sometimes, macro techniques can be used to all updates in one place, but
>> the macro must be devised, and it adds an extra level of obfuscation to
>> the code. [Mine: a built-in language feature exactly this kinds of
>> tables to be easily created and updated. No macros needed]
>
> Macro techniques are used to make this sort of thing /easier/ and
> /clearer/ - it is not "obfuscation".
No? Here's some code from LuaJIT. You encounter a BuildMode typedef in
the code, and trace it back to this:
/* Build modes. */
#define BUILDDEF(_) \
_(elfasm) _(coffasm) _(machasm) _(peobj) _(raw) \
_(bcdef) _(ffdef) _(libdef) _(recdef) _(vmdef) \
_(folddef)
typedef enum {
#define BUILDENUM(name) BUILD_##name,
BUILDDEF(BUILDENUM)
#undef BUILDENUM
BUILD__MAX
} BuildMode;
This just creates a normal list of enums, but you wander why it's done
that way. But then, 14000 lines later [in an agglomeration of all .h and
.c files], you see:
/* Build mode names. */
static const char *const modenames[] = {
#define BUILDNAME(name) #name,
BUILDDEF(BUILDNAME)
#undef BUILDNAME
NULL
};
What does it do? Well, I have to put it through a preprocessor to figure
it out, that's how clear it is! So here, it IS obfuscation. Nowhere in
the code is there a list of those enums as they would be used, such as
'BUILD_elfasm'. That is a really poor way of going about things.
Anyway, it simply creates a matching set of enums, and names of those enums.
I would write it like this in my language:
tabledata() []ichar modenames =
(BUILD_elfasm, "elfasm"),
(BUILD_coffasm, "coffasm"),
(BUILD_machasm, "machasm"),
(BUILD_peobj, "peobj"),
(BUILD_raw, "raw"),
(BUILD_bcdef, "bcdef"),
(BUILD_ffdef, "ffdef"),
(BUILD_libdef, "libdef"),
(BUILD_recdef, "recdef"),
(BUILD_vmdef, "vmdef"),
(BUILD_folddef, "folddef"),
end
Which do you think is clearer? If you say C, then I know you are just
being contrary for the sake of it.
(And actually, I normally write it as I show after my sig, to avoid the
duplication.)
--
bartc
tabledata() []ichar modenames =
(BUILD_elfasm, $),
(BUILD_coffasm, $),
(BUILD_machasm, $),
(BUILD_peobj, $),
(BUILD_raw, $),
(BUILD_bcdef, $),
(BUILD_ffdef, $),
(BUILD_libdef, $),
(BUILD_recdef, $),
(BUILD_vmdef, $),
(BUILD_folddef, $),
end
The '$' uses the name of the preceding enum as a string constant. But
because this encodes "BUILD_elfasm" not "elfasm", it is necessary to
ignore the first 6 characters to use the compact name.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 14:27 +0100 |
| Message-ID | <p0r9sp$m3c$1@dont-email.me> |
| In reply to | #124278 |
On 13/12/17 12:50, bartc wrote:
> On 13/12/2017 10:25, David Brown wrote:
>> On 13/12/17 01:08, bartc wrote:
>
>> Yes, I saw the table. It is utterly irrelevant - so I ignored it.
>
> OK. That's a good way of winning an argument - just ignore the evidence.
I hadn't realised this was a winnable argument. But I do consider a
list over the number of semicolons and other tokens to be of no
consequence or use in judging between two formulations here. It is like
trying to judge football players on the colours of their shoes.
>
> Unfortunately as a very clumsy typist I can't ignore it.
>
I don't believe you are that clumsy - not enough to make it relevant.
>
>> Any code for a purpose that is /hard/, is going to be more difficult to
>> follow than code for easy purposes.
>
> You have that. But then you have extra things thrown in (macros in C,
> templates in C++, meta-classes in Python) just for the hell of it.
>
Again, you assume that something that /you/ do not immediately
understand, is worthless.
Consider the number of man-hours that C++ templates took to develop from
a vague idea into a working concept, to implement them, to write books
about them, to use them in libraries, to teach them on courses, to use
them in every C++ application, to learn about them, to enhance and
expand them with every C++ version. It is a /massive/ investment that
is key to C++'s popularity and success. Yet you dismiss them as "extra
things thrown in just for the hell of it".
Meta-classes in Python are essential to the modern versions of the
language - even though they are mostly behind the scenes, and seen by
only a few people. Macros in C are everywhere - they are integral to
the language.
/You/ might not understand how they are used, or why they are useful.
/You/ might not like them. But your arrogance and navel-gazing here is
at an all-time high.
> The number of semicolons (or whatever
>> your hobby-horse is) is absolutely and utterly irrelevant.
>
> That must be why Python has done away with them.
>
> That's why Go has done away with them.
>
> That's why Rust has done away with them.
>
> That's why Javascript has away with them.
>
Some languages use them, some do not. Some use them as statement
separators, some as statement terminators. Some languages have them as
optional, and consider an end-of-line to be an implicit semicolon in
certain circumstances. It all depends on the language.
It does not matter a jot when considering how clear or readable code
written in the language is - you can write clear or messy code in either
case.
> That would be an extraordinary waste of effort if semicolons are as
> irrelevant as you claim. So is it possible that you don't know what you
> are talking about?
What on earth makes you think that the designers of these languages have
gone to "extraordinary efforts" to "do away with" semicolons? They have
simply chosen a language syntax that does not have semicolons (or at
least, not in the same position as in C). It is not as if every new
language comes with semicolons built in, and you have to work hard to
break them off.
>
> You seem to want to argue the opposite of everything I say, just for the
> same of it.
If you read again, you see I agree (at least partially) on some things
you say. But you do sometimes spout the most amazing garbage, and of
course I disagree with that.
>
> Half of all syntax errors I get when writing fresh C code are to do with
> missing semicolons.
How is it possible to get something /so/ simple, /so/ wrong, /so/ often?
> /You/ probably use some tool to insert them for you.
No. If semicolons were a particular effort in C programming, and there
were convenient ways to automate them, then I am sure editors /would/
handle them (as they do for things like indentation). But here I rely
on knowing how to write C code.
>
> But why, in that case, couldn't all those languages have stipulated
> using the same tools? Is it because languages should stand up by
> themselves?
>
>>> (7) Parallel tables: You have a set of enums, and matching sets of
>>> parallel arrays (names), values etc which have to correspond. Add,
>>> delete, insert or move entries, and all arrays must be adjusted.
>>> Sometimes, macro techniques can be used to all updates in one place, but
>>> the macro must be devised, and it adds an extra level of obfuscation to
>>> the code. [Mine: a built-in language feature exactly this kinds of
>>> tables to be easily created and updated. No macros needed]
>>
>> Macro techniques are used to make this sort of thing /easier/ and
>> /clearer/ - it is not "obfuscation".
>
> No? Here's some code from LuaJIT.
Ah, your favourite example of C code that is beyond your capabilities.
You have been told often enough why this is a poor example of common C
coding styles. You haven't listened before, so there is no point in
repeating it.
> You encounter a BuildMode typedef in
> the code, and trace it back to this:
>
> /* Build modes. */
> #define BUILDDEF(_) \
> _(elfasm) _(coffasm) _(machasm) _(peobj) _(raw) \
> _(bcdef) _(ffdef) _(libdef) _(recdef) _(vmdef) \
> _(folddef)
>
> typedef enum {
> #define BUILDENUM(name) BUILD_##name,
> BUILDDEF(BUILDENUM)
> #undef BUILDENUM
> BUILD__MAX
> } BuildMode;
>
> This just creates a normal list of enums, but you wander why it's done
> that way.
That looks like a technique known as "x macros". You can look it up.
Even if you don't know that, you could perhaps assume it is done that
way because the writers of the code find it a convenient way to get
consistent code in a maintainable way, and that /they/ understand what
they are doing.
But no, you find it preferably to assume that the rest of the world are
all idiots who know nothing about how to write code, and if someone
writes a program where /you/, the great C wizard Bart, cannot understand
every snippet taken out of context - then clearly it is the language C
that is at fault for forcing people to write code that confuses you.
> But then, 14000 lines later [in an agglomeration of all .h and
> .c files], you see:
You do know that such agglomerations are not the actual source files,
don't you? Or would that spoil more of your complains about the
language? (On the other hand, when there is more than one file, you
moan about that too. It seems you simply dislike any program that takes
more than a few hundred lines of code.)
>
> /* Build mode names. */
> static const char *const modenames[] = {
> #define BUILDNAME(name) #name,
> BUILDDEF(BUILDNAME)
> #undef BUILDNAME
> NULL
> };
Yes, x macros.
Here is the Wikipedia link:
<https://en.wikipedia.org/wiki/X_Macro>
It is a common enough technique, and can be very useful in cases like
this. But it is not something every C programmer knows - and you are
not alone in wondering about it the first time you see it. You are,
perhaps, unique in assuming it is obfuscation or a flaw in the C
language rather than a neat way of using the pre-processor to get
consistent, clear and maintainable code in an easy way.
>
> What does it do? Well, I have to put it through a preprocessor to figure
> it out, that's how clear it is! So here, it IS obfuscation. Nowhere in
> the code is there a list of those enums as they would be used, such as
> 'BUILD_elfasm'. That is a really poor way of going about things.
>
> Anyway, it simply creates a matching set of enums, and names of those
> enums.
Yes, that is perfectly clear (at least when you are familiar with the
technique involved - or when you understand how macros work and are
willing to apply some thought).
It might equally have been used later to provide function declarations
or definitions based on these names, or jump tables, or switch
statements, or anything else where you want a repetitive task based on
that list of names.
>
> I would write it like this in my language:
>
> tabledata() []ichar modenames =
> (BUILD_elfasm, "elfasm"),
> (BUILD_coffasm, "coffasm"),
> (BUILD_machasm, "machasm"),
> (BUILD_peobj, "peobj"),
> (BUILD_raw, "raw"),
> (BUILD_bcdef, "bcdef"),
> (BUILD_ffdef, "ffdef"),
> (BUILD_libdef, "libdef"),
> (BUILD_recdef, "recdef"),
> (BUILD_vmdef, "vmdef"),
> (BUILD_folddef, "folddef"),
> end
>
> Which do you think is clearer? If you say C, then I know you are just
> being contrary for the sake of it.
I would say C using x macros, for three main reasons. One is that it
does not have the repetition you have here. That means easier
maintenance because changes or additions only need to be made in one
place, and there is no risk of getting things inconsistent. Two is that
it separates the definitions of the different uses - you might well have
the enum declaration in a header and the table of names in an
implementation file. Three is that you might want to use the list again
in other contexts.
I have no idea if your code generates the equivalent of a C enumerated
type. But if not, then you are also missing that - giving a fourth
reason for preferring C and x macros. Note that in C - with proper
development tools - enumerated types give a lot more than just a list of
named numbers. In particular, they allow improved static error checking
(a key one is to have a switch on enumerated types give you warnings if
you have forgotten one), and they let debuggers give you the named value
rather than just a number.
Your code simply does not do what the x macros here do.
When I say you are wrong, or at that your experiences don't match mine,
or that the things you find to be problematic are not problems for
others - it is for good reason, and based on fact or personal
experience. I am not being contrary for the sake of it.
>
> (And actually, I normally write it as I show after my sig, to avoid the
> duplication.)
>
Please don't do that. Use a signature for a signature - put relevant
information in the post.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 14:31 +0000 |
| Message-ID | <_QaYB.132221$sg1.100336@fx43.am4> |
| In reply to | #124281 |
On 13/12/2017 13:27, David Brown wrote:
> On 13/12/17 12:50, bartc wrote:
> I don't believe you are that clumsy - not enough to make it relevant.
Yes I am. Maybe it's a disability as I can't reliably hit the right keys
squarely especially outside the qwerty block.
> Consider the number of man-hours that C++ templates took to develop from
> a vague idea into a working concept, to implement them, to write books
> about them, to use them in libraries, to teach them on courses, to use
> them in every C++ application, to learn about them, to enhance and
> expand them with every C++ version. It is a /massive/ investment that
> is key to C++'s popularity and success. Yet you dismiss them as "extra
> things thrown in just for the hell of it".
I'm sceptical of things so complicated that it takes man-years to
implement them.
A lot of things that templates let you do (as I understood templates 20
years ago; no doubt they are even more powerful now), I can also do in
my dynamic language. Ie. I don't need specialised renderings of the same
code parameterised by type, because the same dynamic code works for any
type.
A different, simpler approach to the problem.
>> That would be an extraordinary waste of effort if semicolons are as
>> irrelevant as you claim. So is it possible that you don't know what you
>> are talking about?
>
> What on earth makes you think that the designers of these languages have
> gone to "extraordinary efforts" to "do away with" semicolons?
The fact that they have gone to /any/ effort is extraordinary.
Doing it like C does is the simplest to implement and to document.
Otherwise you need a scheme to split up statements if the language is
not strictly line-oriented. But there must be some advantage in not
having to write them or they wouldn't have bothered.
>> Half of all syntax errors I get when writing fresh C code are to do with
>> missing semicolons.
>
> How is it possible to get something /so/ simple, /so/ wrong, /so/ often?
Because my other languages don't use them.
Perhaps 99% of statements in C are naturally terminated at the end of a
line. But all those 99% still need ";" as well. It's largely redundant.
> That looks like a technique known as "x macros". You can look it up.
So it's not specific to LuaJIT then? And people actually use this scheme?
Whatever, it's obfuscatory compared to just doing:
enum {
BUILD_elfasm,
...
}
char* modenames[] = {
"elfasm",
....
}
and putting them in the same place. Harder to maintain (although there
only ELEVEN of them), but considerably easier to read. Otherwise, how do
you even know an enum looks like "BUILD_elfasm", you have to run the
preprocessor in your head?
> Even if you don't know that, you could perhaps assume it is done that
> way because the writers of the code find it a convenient way to get
> consistent code in a maintainable way, and that /they/ understand what
> they are doing.
It's done that way because there isn't an alternative in C. If there was
a feature like mine, how many would bother with x-macros?
> You do know that such agglomerations are not the actual source files,
> don't you?
This is /my/ agglomeration (just concatenations really) so that I can
search more easily.
> It is a common enough technique, and can be very useful in cases like
> this. But it is not something every C programmer knows - and you are
> not alone in wondering about it the first time you see it. You are,
> perhaps, unique in assuming it is obfuscation or a flaw in the C
> language rather than a neat way of using the pre-processor to get
> consistent, clear and maintainable code in an easy way.
It's an ugly hack. And just look at my example: #defining and #undefing
a macro within a typedef? As for maintainability, they haven't even
bothered without putting each enum base-name on a separate line.
>> I would write it like this in my language:
>>
>> tabledata() []ichar modenames =
>> (BUILD_elfasm, "elfasm"),
>> (BUILD_coffasm, "coffasm"),
>> (BUILD_machasm, "machasm"),
>> (BUILD_peobj, "peobj"),
>> (BUILD_raw, "raw"),
>> (BUILD_bcdef, "bcdef"),
>> (BUILD_ffdef, "ffdef"),
>> (BUILD_libdef, "libdef"),
>> (BUILD_recdef, "recdef"),
>> (BUILD_vmdef, "vmdef"),
>> (BUILD_folddef, "folddef"),
>> end
>>
>> Which do you think is clearer? If you say C, then I know you are just
>> being contrary for the sake of it.
>
> I would say C using x macros, for three main reasons. One is that it
> does not have the repetition you have here.
What, writing elfasm twice? Or repeating BUILD? Or both?
This type of repetition on the same line, while tedious to write, is not
a problem. More important that entries can be trivially deleted, moved,
added or duplicated [so that they can be tweaked to create a new entry].
Also important is that someone reading or maintaining the code can see
'BUILD_ffdef' somewhere and match it up with a list of these enums. With
x-macros, the definition for 'BUILD_ffdef' is not visible.
(In the version in my sig, 'elfasm' etc is written once. A not fully
implemented feature of 'tabledata' allows BUILD to be written once too,
but that becomes a container type for the enums which then have to be
written BUILD.elfasm etc instead of BUILD_elfasm.)
> I have no idea if your code generates the equivalent of a C enumerated
> type.
Translated to C, you might get this (note original is 1-based):
enum {build_elfasm = 1};
static char* modenames[11]={
"elfasm",
"coffasm",
"machasm",
"peobj",
"raw",
"bcdef",
"ffdef",
"libdef",
"recdef",
"vmdef",
"folddef"
};
Enums are only output when there is a reference to them in the code.
Further examples: https://pastebin.com/5bF3ydH4
> Your code simply does not do what the x macros here do.
No, it just tells the reader exactly what they want to know instead of
burying that information inside a preprocessor script that needs to be
executed.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 16:56 +0100 |
| Message-ID | <p0rijl$km7$1@dont-email.me> |
| In reply to | #124282 |
On 13/12/17 15:31, bartc wrote:
> On 13/12/2017 13:27, David Brown wrote:
>> On 13/12/17 12:50, bartc wrote:
>
>> I don't believe you are that clumsy - not enough to make it relevant.
>
> Yes I am. Maybe it's a disability as I can't reliably hit the right keys
> squarely especially outside the qwerty block.
>
If that is the case, then it can make sense to consider semicolons for
/your/ language which only you use - but it is still irrelevant when
comparing programming languages more generally.
>> Consider the number of man-hours that C++ templates took to develop from
>> a vague idea into a working concept, to implement them, to write books
>> about them, to use them in libraries, to teach them on courses, to use
>> them in every C++ application, to learn about them, to enhance and
>> expand them with every C++ version. It is a /massive/ investment that
>> is key to C++'s popularity and success. Yet you dismiss them as "extra
>> things thrown in just for the hell of it".
>
> I'm sceptical of things so complicated that it takes man-years to
> implement them.
>
You must be sceptical of a lot of things!
> A lot of things that templates let you do (as I understood templates 20
> years ago; no doubt they are even more powerful now), I can also do in
> my dynamic language. Ie. I don't need specialised renderings of the same
> code parameterised by type, because the same dynamic code works for any
> type.
>
> A different, simpler approach to the problem.
Dynamic typing, or duck typing (like in Python) can do /some/ of the
things that C++ templates and other static language generic programming
can do. But only some things.
You still haven't given any justification for claiming that C++
templates (or C macros, or Python meta-classes) are just "thrown in for
the hell of it".
>
>
>>> That would be an extraordinary waste of effort if semicolons are as
>>> irrelevant as you claim. So is it possible that you don't know what you
>>> are talking about?
>>
>> What on earth makes you think that the designers of these languages have
>> gone to "extraordinary efforts" to "do away with" semicolons?
>
> The fact that they have gone to /any/ effort is extraordinary.
What makes you think they have gone to any effort at all? Even if they
had, what makes you think it is extraordinary? Your premise is
completely unfounded, your conclusions don't follow from your premises,
and your whole argument is nonsense.
>
> Doing it like C does is the simplest to implement and to document.
Simpler than "end of line is end of statement" ? No, I don't think so.
> Otherwise you need a scheme to split up statements if the language is
> not strictly line-oriented. But there must be some advantage in not
> having to write them or they wouldn't have bothered.
>
Some languages have semicolons at the end, some don't. In the same
vein, some languages have block delimiters, some use indents. It is
that simple.
>>> Half of all syntax errors I get when writing fresh C code are to do with
>>> missing semicolons.
>>
>> How is it possible to get something /so/ simple, /so/ wrong, /so/ often?
>
> Because my other languages don't use them.
>
> Perhaps 99% of statements in C are naturally terminated at the end of a
> line. But all those 99% still need ";" as well. It's largely redundant.
Most of the lines in my C code don't have terminating semicolons. A
current project has almost 20000 lines in the main set of C files. Of
these, 5000 end in semicolons. There are a total of about 6000
semicolons in the files. So 75% of my end of lines are /not/ statement
terminators. And 20% of my semicolons are not at the end of lines.
If your statistics were remotely correct, then you would be able to add
semicolons by reflex when programming C - it is not something you would
get wrong. You can't have it both ways, claiming that their are so
regular that they are redundant and also so irregular that you make
mistakes.
>
>> That looks like a technique known as "x macros". You can look it up.
>
> So it's not specific to LuaJIT then? And people actually use this scheme?
>
Yes. Did you read the link I gave you, or other web pages about them?
> Whatever, it's obfuscatory compared to just doing:
>
> enum {
> BUILD_elfasm,
> ...
> }
>
> char* modenames[] = {
> "elfasm",
> ....
> }
>
> and putting them in the same place. Harder to maintain (although there
> only ELEVEN of them), but considerably easier to read. Otherwise, how do
> you even know an enum looks like "BUILD_elfasm", you have to run the
> preprocessor in your head?
>
Did you read what I wrote in my post?
>
>> Even if you don't know that, you could perhaps assume it is done that
>> way because the writers of the code find it a convenient way to get
>> consistent code in a maintainable way, and that /they/ understand what
>> they are doing.
>
> It's done that way because there isn't an alternative in C. If there was
> a feature like mine, how many would bother with x-macros?
Anyone who knows about x macros and who is writing code that can take
advantage of them. Your suggested language feature does not do what the
LuaJIT authors (or other x macro users) want.
>
>> You do know that such agglomerations are not the actual source files,
>> don't you?
>
> This is /my/ agglomeration (just concatenations really) so that I can
> search more easily.
>
Can't you use "grep" ? Or at least an editor more sophisticated than
notepad - one that can search files?
>> It is a common enough technique, and can be very useful in cases like
>> this. But it is not something every C programmer knows - and you are
>> not alone in wondering about it the first time you see it. You are,
>> perhaps, unique in assuming it is obfuscation or a flaw in the C
>> language rather than a neat way of using the pre-processor to get
>> consistent, clear and maintainable code in an easy way.
>
> It's an ugly hack. And just look at my example: #defining and #undefing
> a macro within a typedef?
Personally, I prefer to write the #define and #undef outside the
typedef, and have a somewhat different spacing/indenting scheme. But
that is just my style. Is it ugly? Well, it is not pretty, I guess.
It is rare that pre-processor stuff is /pretty/. Making it pretty would
involve a huge amount more language support (like the future C++
metaclasses) - certainly your language doesn't cover more than a
fraction of what is wanted here.
> As for maintainability, they haven't even
> bothered without putting each enum base-name on a separate line.
Why should that affect maintainability? Can't you add or change
something in an existing line? Separate lines might be nicer if each
were commented, or if there were lots of changes happening and you
wanted a clearer difference in a source code control system.
>
>
>>> I would write it like this in my language:
>>>
>>> tabledata() []ichar modenames =
>>> (BUILD_elfasm, "elfasm"),
>>> (BUILD_coffasm, "coffasm"),
>>> (BUILD_machasm, "machasm"),
>>> (BUILD_peobj, "peobj"),
>>> (BUILD_raw, "raw"),
>>> (BUILD_bcdef, "bcdef"),
>>> (BUILD_ffdef, "ffdef"),
>>> (BUILD_libdef, "libdef"),
>>> (BUILD_recdef, "recdef"),
>>> (BUILD_vmdef, "vmdef"),
>>> (BUILD_folddef, "folddef"),
>>> end
>>>
>>> Which do you think is clearer? If you say C, then I know you are just
>>> being contrary for the sake of it.
>>
>> I would say C using x macros, for three main reasons. One is that it
>> does not have the repetition you have here.
>
> What, writing elfasm twice? Or repeating BUILD? Or both?
You are writing each name twice. That gives the risk of writing:
(BUILD_libdef, "libef"),
or other such mistakes. x macros are about giving the list /once/.
>
> This type of repetition on the same line, while tedious to write, is not
> a problem. More important that entries can be trivially deleted, moved,
> added or duplicated [so that they can be tweaked to create a new entry].
If you want to do that with the x macros, that's fine to. The LuaJIT
people happened to put multiple entries on each line, but it is not a
requirement.
>
> Also important is that someone reading or maintaining the code can see
> 'BUILD_ffdef' somewhere and match it up with a list of these enums. With
> x-macros, the definition for 'BUILD_ffdef' is not visible.
That is absolutely true, and is a disadvantage of the technique.
>
> (In the version in my sig, 'elfasm' etc is written once. A not fully
> implemented feature of 'tabledata' allows BUILD to be written once too,
> but that becomes a container type for the enums which then have to be
> written BUILD.elfasm etc instead of BUILD_elfasm.)
>
Except that your sig version does not do the same thing.
>
>> I have no idea if your code generates the equivalent of a C enumerated
>> type.
>
> Translated to C, you might get this (note original is 1-based):
>
> enum {build_elfasm = 1};
>
> static char* modenames[11]={
> "elfasm",
> "coffasm",
> "machasm",
> "peobj",
> "raw",
> "bcdef",
> "ffdef",
> "libdef",
> "recdef",
> "vmdef",
> "folddef"
> };
>
> Enums are only output when there is a reference to them in the code.
> Further examples: https://pastebin.com/5bF3ydH4
>
Thus you miss the point of having enums.
>> Your code simply does not do what the x macros here do.
>
> No, it just tells the reader exactly what they want to know instead of
> burying that information inside a preprocessor script that needs to be
> executed.
>
You skipped all the other reasons why the x macros solution is better
than your version. I assume that is because you agree with everything I
wrote?
It's okay to feel uncomfortable with x macros - many C programmers do.
But your language does not have the features needed to duplicate the
technique - claiming it does merely shows your misunderstandings of C,
the pre-processor, and how people want to write code. I am sure your
table feature has other uses, and advantages in some situations - but it
does not do the job here.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 19:27 +0000 |
| Message-ID | <I9fYB.285055$XT.131418@fx37.am4> |
| In reply to | #124286 |
On 13/12/2017 15:56, David Brown wrote:
> On 13/12/17 15:31, bartc wrote:
<snip comments showing you misunderstood what I was saying>
> If your statistics were remotely correct, then you would be able to add
> semicolons by reflex when programming C
(Outside of C, I've successfully used such schemes so that I've never
had to routinely insert semicolons since around 1978. So I can say I
have some experience in them.)
<snip a lot of negative comments about my 'tabledata' feature>
> But your language does not have the features needed to duplicate the
> technique - claiming it does merely shows your misunderstandings of C,
> the pre-processor, and how people want to write code. I am sure your
> table feature has other uses, and advantages in some situations - but it
> does not do the job here.
For this example it does almost exactly the same job.
This is the code needed for the x-macro version in C:
#define BUILDDEF(_) \
_(elfasm) _(coffasm) _(machasm) _(peobj) _(raw) \
_(bcdef) _(ffdef) _(libdef) _(recdef) _(vmdef) \
_(folddef)
typedef enum {
#define BUILDENUM(name) BUILD_##name,
BUILDDEF(BUILDENUM)
#undef BUILDENUM
BUILD__MAX
} BuildMode;
static const char *const modenames[] = {
#define BUILDNAME(name) #name,
BUILDDEF(BUILDNAME)
#undef BUILDNAME
NULL
};
This is the code needed to DO THE SAME JOB in my language:
tabledata() []ichar modenames =
(BUILD_elfasm, "elfasm"),
(BUILD_coffasm, "coffasm"),
(BUILD_machasm, "machasm"),
(BUILD_peobj, "peobj"),
(BUILD_raw, "raw"),
(BUILD_bcdef, "bcdef"),
(BUILD_ffdef, "ffdef"),
(BUILD_libdef, "libdef"),
(BUILD_recdef, "recdef"),
(BUILD_vmdef, "vmdef"),
(BUILD_folddef, "folddef"),
end
Despite:
(1) The C version having the enums packed over only 3 lines
(2) Having to write BUILD_ prefix 11 times in my version
(3) Having to manually duplicate the base enum name as a string
My version is still only 13 lines instead of 16. And it's only 352
characters instead of 417.
And it's a million times more readable, and easier to modify.
Really, in which version is it someone more likely to make an error?
It's no contest really.
The C version is a horrible ugly mess that offers no advantage
whatsoever in this use-case that I can see. You're dismissing an elegant
solution in another language for no reason other than sour grapes.
But it is what C coders have to resort to, unless they just write a
bunch of enums the regular way, and a matching table of names. It would
actually be easier to write, and the maintenance is not a big deal on
something this size.
This is what I would do. I, for some reason, have some consideration for
people who might want to read my code. I don't just write any old
rubbish and then say 'Tough, learn to read C' if someone complains.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 21:15 +0100 |
| Message-ID | <p0s1pi$92p$1@dont-email.me> |
| In reply to | #124300 |
On 13/12/17 20:27, bartc wrote:
> On 13/12/2017 15:56, David Brown wrote:
>> On 13/12/17 15:31, bartc wrote:
>
> <snip comments showing you misunderstood what I was saying>
>
>> If your statistics were remotely correct, then you would be able to add
>> semicolons by reflex when programming C
>
> (Outside of C, I've successfully used such schemes so that I've never
> had to routinely insert semicolons since around 1978. So I can say I
> have some experience in them.)
>
> <snip a lot of negative comments about my 'tabledata' feature>
>
>> But your language does not have the features needed to duplicate the
>> technique - claiming it does merely shows your misunderstandings of C,
>> the pre-processor, and how people want to write code. I am sure your
>> table feature has other uses, and advantages in some situations - but it
>> does not do the job here.
>
> For this example it does almost exactly the same job.
No, it does /not/.
You don't define a proper enumeration type.
You don't generate the strings automatically from the names.
You don't have a /separation/ of the parts - and this is the key thing
you fail on. The C solution with x macros means your list can be
defined in one place, and it can be used in different ways in different
places.
You don't have the flexibility to do anything else here - your table is
very limited. This example does not use so many possibilities of x
macros - other cases do, and the C solution is easily extendible.
>
> This is the code needed for the x-macro version in C:
>
> #define BUILDDEF(_) \
> _(elfasm) _(coffasm) _(machasm) _(peobj) _(raw) \
> _(bcdef) _(ffdef) _(libdef) _(recdef) _(vmdef) \
> _(folddef)
>
> typedef enum {
> #define BUILDENUM(name) BUILD_##name,
> BUILDDEF(BUILDENUM)
> #undef BUILDENUM
> BUILD__MAX
> } BuildMode;
>
> static const char *const modenames[] = {
> #define BUILDNAME(name) #name,
> BUILDDEF(BUILDNAME)
> #undef BUILDNAME
> NULL
> };
>
> This is the code needed to DO THE SAME JOB in my language:
>
> tabledata() []ichar modenames =
> (BUILD_elfasm, "elfasm"),
> (BUILD_coffasm, "coffasm"),
> (BUILD_machasm, "machasm"),
> (BUILD_peobj, "peobj"),
> (BUILD_raw, "raw"),
> (BUILD_bcdef, "bcdef"),
> (BUILD_ffdef, "ffdef"),
> (BUILD_libdef, "libdef"),
> (BUILD_recdef, "recdef"),
> (BUILD_vmdef, "vmdef"),
> (BUILD_folddef, "folddef"),
> end
>
> Despite:
>
> (1) The C version having the enums packed over only 3 lines
That is a choice of the C author here.
>
> (2) Having to write BUILD_ prefix 11 times in my version
That is a limitation of your system.
>
> (3) Having to manually duplicate the base enum name as a string
That is a significant drawback of your system.
>
> My version is still only 13 lines instead of 16. And it's only 352
> characters instead of 417.
And that doesn't matter - it is not an important difference.
The reason for the difference here is that your feature is a language
feature to do one specific thing - in C, you have a flexibility to
generate this kind of code and any other similar system. Your system is
neat and convenient for what it does - but it can /only/ do the one thing.
Your language is a set of 6 different colours of toy car. C and the
pre-processor is a box of lego. Your toy cars may look nicer than a car
made from lego, but they are useless when you want a house, or a
spaceship, or a robot.
>
> And it's a million times more readable, and easier to modify.
>
You really love that word, don't you? As though claiming it to be "a
million times" more readable would make someone believe you?
Yes, your code here looks neater. No, it is not more readable - at
least not to people with experience of C and familiarity with x macros.
And it is absolutely not easier to modify - even if we stick to your
pointless quantifications of character counts, adding, removing or
changing an entry in your version takes at least twice as many, often
more, character changes in comparison to the x macro version. And if
you want to modify it by doing something else with the list, your
version is useless.
> Really, in which version is it someone more likely to make an error?
The x macros are a little odd when you are not used to them. But they
are not very difficult. And the reduced repetition reduces the risk of
errors.
>
> It's no contest really.
>
> The C version is a horrible ugly mess that offers no advantage
> whatsoever in this use-case that I can see. You're dismissing an elegant
> solution in another language for no reason other than sour grapes.
>
You can't see the differences because you won't read what I wrote. You
also don't see that I agreed that the C code here is ugly - I said it
was useful, flexible, easy to maintain, and reasonably easy to
understand once you get the idea of x macros. I did not say it looked nice.
> But it is what C coders have to resort to, unless they just write a
> bunch of enums the regular way, and a matching table of names. It would
> actually be easier to write, and the maintenance is not a big deal on
> something this size.
I absolutely agree. Usually when I have an enum and I want a table of
names, I will define a normal C enumeration and have the table
separately. I use static assertions, compiler warnings and perhaps
designated initialisers to ensure that there are no inconsistencies.
Would I use your format if it were available in C? No, I cannot see any
use for it - because I don't want the enumeration type and the list of
strings defined in the same place in the code.
>
> This is what I would do. I, for some reason, have some consideration for
> people who might want to read my code. I don't just write any old
> rubbish and then say 'Tough, learn to read C' if someone complains.
>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 22:48 +0000 |
| Message-ID | <m6iYB.2$Og3.1@fx11.am4> |
| In reply to | #124304 |
On 13/12/2017 20:15, David Brown wrote:
> On 13/12/17 20:27, bartc wrote:
>> For this example it does almost exactly the same job.
>
> No, it does /not/.
>
> You don't define a proper enumeration type.
That's not what this is about. It's about automatically linking enums
and names for those enums.
> You don't generate the strings automatically from the names.
Christ, you're not going to let that go are you? Try this then:
tabledata() []ichar modenames
(BUILD_elfasm, $+6),
(BUILD_coffasm, $+6),
(BUILD_machasm, $+6),
(BUILD_peobj, $+6),
(BUILD_raw, $+6),
(BUILD_bcdef, $+6),
(BUILD_ffdef, $+6),
(BUILD_libdef, $+6),
(BUILD_recdef, $+6),
(BUILD_vmdef, $+6),
(BUILD_folddef, $+6),
end
Unlike the x-macro, here you can override the names for individual enums.
What's your next complaint, that BUILD_ has to be repeated? You're
forgetting that each enum will occur multiple times within the source
code anyway.
> You don't have a /separation/ of the parts - and this is the key thing
> you fail on. The C solution with x macros means your list can be
> defined in one place, and it can be used in different ways in different
> places.
The whole POINT of my solution is that the parts are all together.
That's part of the whole philosophy of my language versus C which likes
to have different bits scattered everywhere.
Types, structs, enums, variables, named consts, functions are only ever
defined in one place.
> You don't have the flexibility to do anything else here - your table is
> very limited.
Look at the link I posted with examples. What else is needed for that
purpose? Would you really prefer those tables replaced by
incomprehensible gobbledygook?
> And that doesn't matter - it is not an important difference.
It's not, but it's ironic that you write this a simpler way and it is
shorter and more readable.
> Your language is a set of 6 different colours of toy car. C and the
> pre-processor is a box of lego.
Yes I know. And little boys [and girls] love playing with lego.
The difference with lego is that the thing you end up with and that
others can enjoy or use is something you made with that lego, not the
instructions for assembling the lego into the result.
But what everyone else is expected to look at with C and work with, are
the cryptic instructions [for generating C], not the final product.
> No, it is not more readable - at
> least not to people with experience of C and familiarity with x macros.
So If I write an article in English for people in the UK, rather than
one in Chinese, you would say about mine:
'No, it is not more readable - at least not to people with experience
of Chinese'.
Please!
I think you're clutching at straws here.
Why not admit that this is actually a handy feature, rather than dismiss
it because it doesn't work some extreme scenarios. It's handy /because/
it does one thing well.
This is like the argument about C's for-loop: all the talk about it
being so flexible and being able to express any looping requirement you
can think up, and eventually you admitted that 98% of your for-loops
were simple A to B ones.
> And it is absolutely not easier to modify
What's hard about it? It is at least perfectly clear where in the source
you have to modify, and which bit to modify.
> Would I use your format if it were available in C? No, I cannot see any
> use for it - because I don't want the enumeration type and the list of
> strings defined in the same place in the code.
Why on earth not? Supposed you wanted to see at glance what the list of
enums was and what data ended up associated with each, do you have to
traipse all over the program looking for what you need? Would you have
to put it through a preprocessor to generate the TABLE that you can
actually see?
So you would deliberately avoid using it just to make your code more
unreadable and, as you admitted, a mess.
I've sometimes said I've found attitudes in this group extraordinary,
but yours truly is.
I do believe you are determined to find fault with this feature just
because /I/ came with it. (Now I can more understand why I never get
anywhere with some of my proposals; they are just too sensible.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-14 07:44 +0100 |
| Message-ID | <p0t6kv$pjf$1@dont-email.me> |
| In reply to | #124307 |
On 13/12/17 23:48, bartc wrote: > Christ, you're not going to let that go are you? Try this then: > Yes, I /am/ going to let it go. You don't like C - fair enough, it is not for everyone. You prefer your own language - that is understandable. Indeed, it would be absurd to design your own language, to be used only by you, in a way that you did not like. You don't understand C. You don't understand the language, you don't understand idioms or techniques used by others, and you don't understand C code written by others. That is also understandable, given that you see C only as a half-way language used to compile your own language, and you have no interest in learning anything more than the subset of the language and techniques needed to implement your translator. Therefore you are flummoxed by any C code outside of that subset. What I really don't get - and find extremely grating - is your astounding arrogance in your assumption that everyone else is /wrong/. You feel that because /you/ find C hard, /everyone/ finds it hard - and anyone who can use the language comfortably is in denial. You feel that because /you/ think your language is better, /everyone/ knows, deep down, that C is a terrible language but won't admit it. You feel that because /you/ want to limit yourself and your languages in various ways, then /everyone/ should want to do that too. You feel that because you have defined a language that /you/ like, then everyone involved in other languages (primarily C and C++), including language designers, compiler writers, and programmers - is wrong, through a mixture of incompetence and malice. Please accept that there are different people out there, with different ideas, different experiences, different needs, different abilities, and different preferences. Your language may suit /you/ - it does not suit everyone. It certainly does not suit me - just about everything in it that you think is so good, runs contrary to what I want in a programming language. It does not do what I need, and cannot replace the C code in the examples with your code, because your code does not do the same job - it improves on irrelevant metrics like the number of characters, and fails on the relevant ones such as code structure. I am happy that /you/ have a language you like - but it is for you alone. The C language has its quirks and its warts. No one here denies that. But it is the best we have for the tasks that suit it - the best choice by a very large margin. Many of us here /enjoy/ programming in C. Part of that is that we like to make the best of it - to use its features, rather than hide from them. Perhaps if you tried to learn the language and its use, rather than spending so much effort looking for things to hate in it, you might enjoy it too.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-12-14 06:55 +0000 |
| Message-ID | <87po7hre73.fsf@gmail.com> |
| In reply to | #124311 |
David Brown <david.brown@hesbynett.no> writes: > On 13/12/17 23:48, bartc wrote: > >> Christ, you're not going to let that go are you? Try this then: >> > What I really don't get - and find extremely grating - is your > astounding arrogance in your assumption that everyone else is > /wrong/. You feel that because /you/ find C hard, /everyone/ finds it > hard - and anyone who can use the language comfortably is in denial. > You feel that because /you/ think your language is better, /everyone/ > knows, deep down, that C is a terrible language but won't admit it. > You feel that because /you/ want to limit yourself and your languages > in various ways, then /everyone/ should want to do that too. You feel > that because you have defined a language that /you/ like, then > everyone involved in other languages (primarily C and C++), including > language designers, compiler writers, and programmers - is wrong, > through a mixture of incompetence and malice. Given everything that you've just written is 100% true, please consider the possibility that's its not worth the many hours you've spent attempting to reason with a man who has shown no interest or capacity in being reasoned with, and ill-disguised contempt for those that try.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2017-12-14 00:32 -0800 |
| Message-ID | <da0c4b88-0314-4e30-a12e-03d4dd7e4a59@googlegroups.com> |
| In reply to | #124313 |
On Thursday, 14 December 2017 06:55:37 UTC, gwowen wrote: > David Brown writes: > > > On 13/12/17 23:48, bartc wrote: > > > >> Christ, you're not going to let that go are you? Try this then: > >> > > > What I really don't get - and find extremely grating - is your > > astounding arrogance in your assumption that everyone else is > > /wrong/. You feel that because /you/ find C hard, /everyone/ finds it > > hard - and anyone who can use the language comfortably is in denial. > > You feel that because /you/ think your language is better, /everyone/ > > knows, deep down, that C is a terrible language but won't admit it. > > You feel that because /you/ want to limit yourself and your languages > > in various ways, then /everyone/ should want to do that too. You feel > > that because you have defined a language that /you/ like, then > > everyone involved in other languages (primarily C and C++), including > > language designers, compiler writers, and programmers - is wrong, > > through a mixture of incompetence and malice. > > Given everything that you've just written is 100% true, please consider > the possibility that's its not worth the many hours you've spent > attempting to reason with a man who has shown no interest or capacity in > being reasoned with, and ill-disguised contempt for those that try. Indeed. I've been observing this phenomenon for a while and the words of Mark Twain regarding the advisability of engaging in trials of physical prowess with porcine mammals have never seemed more apposite.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-15 00:01 +0000 |
| Message-ID | <%gEYB.365$uW7.71@fx07.am4> |
| In reply to | #124314 |
On 14/12/2017 08:32, mark.bluemel@gmail.com wrote: > On Thursday, 14 December 2017 06:55:37 UTC, gwowen wrote: >> Given everything that you've just written is 100% true, please consider >> the possibility that's its not worth the many hours you've spent >> attempting to reason with a man who has shown no interest or capacity in >> being reasoned with, and ill-disguised contempt for those that try. > > Indeed. You're replying to someone who doesn't disguise his contempt at all and will openly insult strangers on a forum. I've never known him to put forward any technical arguments. > I've been observing this phenomenon for a while and the words of Mark Twain > regarding the advisability of engaging in trials of physical prowess with > porcine mammals have never seemed more apposite. And I've made my own observations about the pig-headedness of some people here who will defend the indefensible in C. The subject of x-macros in this subthread really opened my eyes. Apparently C can never do anything wrong. Everything in C is good, never bad. If some shortcoming is admitted, it's OK because it's worked that way for decades; there's nothing wrong. It's a feature! If someone complains of too complicated or unreadable code, it's NEVER a problem with the language; it's the person doing the complaining who needs to learn C properly. Guys, it's OK to criticise. If something stinks, then it stinks. Don't pretend it's alright just because some of you /have/ to use the language.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2017-12-15 00:48 -0800 |
| Message-ID | <bedd8737-2a06-43a1-a0a8-f85eedaeea1b@googlegroups.com> |
| In reply to | #124341 |
On Friday, 15 December 2017 00:01:17 UTC, Bart wrote: <Snip usual character attacks, straw men and the rest> Can I ask a simple question Bart? What are you trying to achieve with your posts here? It's hard to see a coherent purpose in your continual attacks on C. Do you want to a) Change the language? Wrong forum. b) Understand the language better? You don't seem to be prepared to listen to what others tell you. c) Vent your frustration? Well, it seems a bit childish, but if it helps, perhaps you should do it. We could simply regard it a bit like I regard fir's talking to himself - the output of someone who can't distinguish between a newsgroup and a blog.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-12-15 10:51 +0000 |
| Subject | Why post to Usenet? (Was: Auto-execute code at exit?) |
| Message-ID | <p109ge$38o$1@news.xmission.com> |
| In reply to | #124347 |
In article <bedd8737-2a06-43a1-a0a8-f85eedaeea1b@googlegroups.com>,
<mark.bluemel@gmail.com> wrote:
>On Friday, 15 December 2017 00:01:17 UTC, Bart wrote:
><Snip usual character attacks, straw men and the rest>
>
>Can I ask a simple question Bart?
>What are you trying to achieve with your posts here? It's hard to see a coherent
>purpose in your continual attacks on C.
>Do you want to ...
What's yours? What's Kiki's? What's mine?
Foreach (member in CLC) DO: What is <members> reason for wasting time in CLC?
DONE
The point is that you will never get anywhere trying to guess other
people's motives for reading and/or posting to online forums.
Notes:
1) Unless: That reason is to actually to seek and get help. Which
obviously doesn't cover any of us - "us" being the frequent/persistent posters.
2) It probably has something to do with childhood trauma, but,
paraphrasing Tolstoy, each sad story is different.
--
Alice was something of a handful to her father, Theodore Roosevelt. He was once
asked by a visiting dignitary about parenting his spitfire of a daughter and he
replied, "I can be President of the United States, or I can control Alice. I
cannot possibly do both."
[toc] | [prev] | [next] | [standalone]
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web