Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #394664 > unrolled thread
| Started by | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| First post | 2025-10-22 14:39 -0700 |
| Last post | 2025-10-27 11:51 -0700 |
| Articles | 20 on this page of 196 — 19 participants |
Back to article view | Back to comp.lang.c
New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-22 14:39 -0700
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 22:19 -0300
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 02:42 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 03:04 +0000
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 15:05 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-23 11:36 +0100
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-23 07:59 -0300
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 16:04 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 01:44 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 19:00 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 14:27 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-24 19:35 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 19:50 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-24 18:59 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:20 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 23:18 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:25 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 11:26 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 13:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:07 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 17:03 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:04 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 16:58 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 17:27 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 22:49 +0200
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 23:07 +0200
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 18:01 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-29 20:33 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:29 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:07 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 03:08 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:50 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:58 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:45 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:48 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:23 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 22:39 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 15:59 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 16:05 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:00 +0200
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 18:28 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:49 +0200
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-29 21:30 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:32 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:14 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 16:36 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 17:24 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:39 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 11:16 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 14:59 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 23:14 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 18:48 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 19:24 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 15:10 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:19 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 18:03 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 09:02 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 08:06 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 11:20 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 17:12 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 21:21 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 00:04 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 16:47 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 00:36 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 03:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 21:24 -0700
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 04:52 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 05:38 +0000
Re: New and improved version of cdecl Richard Heathfield <rjh@cpax.org.uk> - 2025-10-30 07:45 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 16:41 +0200
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 16:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 17:30 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 18:29 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 18:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:21 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:44 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:49 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 12:50 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 00:27 +0000
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 17:35 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 14:13 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 14:32 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 16:22 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:40 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 12:39 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 14:55 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 17:18 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 17:52 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-30 05:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 11:15 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:07 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 16:04 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 18:30 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:49 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 18:59 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:23 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 16:44 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 00:15 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 18:16 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:36 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 19:13 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:43 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:10 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 16:34 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:01 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 00:28 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:22 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 10:29 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-31 13:15 +0200
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 21:39 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-31 11:43 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 22:47 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:16 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 23:40 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-31 17:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 09:31 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 23:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:49 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 02:14 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 22:01 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 11:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 14:56 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:37 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:37 +0100
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 11:52 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:48 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-29 23:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 06:57 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-29 14:17 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 14:40 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-29 16:09 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 16:47 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 05:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:56 +0000
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-28 17:34 -0400
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 04:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:31 -0700
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 20:52 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 17:30 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 19:11 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 19:59 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:45 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 10:27 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 01:22 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 17:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 22:26 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-29 00:04 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 14:56 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 00:34 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:45 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 01:12 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:15 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 14:56 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 13:18 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 15:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 16:16 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:04 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 13:51 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 17:18 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 15:12 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 10:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 11:22 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 17:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 17:44 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:10 +0100
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:47 -0700
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-27 22:33 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:23 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 16:20 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:48 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:41 +0100
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-25 11:40 -0400
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 16:48 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 19:14 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-25 15:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 08:07 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-24 21:36 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:07 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:01 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-24 15:01 -0700
Re: New and improved version of cdecl Andrey Tarasevich <noone@noone.net> - 2025-10-26 12:09 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:36 -0700
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 07:31 -0800
Re: New and improved version of cdecl Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-09 20:38 +0000
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 16:46 -0800
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-09 17:51 -0800
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 14:44 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:38 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 11:51 -0700
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-28 20:00 +0200 |
| Message-ID | <20251028200057.00000477@yahoo.com> |
| In reply to | #394888 |
On Tue, 28 Oct 2025 16:05:47 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > David Brown <david.brown@hesbynett.no> writes: > >On 28/10/2025 03:00, Janis Papanagnou wrote: > >> On 27.10.2025 21:39, Michael S wrote: > >>>> > >>>> Lua is not Algol 68. > >>> > >>> Correct. > >>> Lua is a useful programming language. > >> > >> (I have no stakes here. Never used it.) > >> > > > >It's usefulness is demonstrated by its widespread use. It is mostly > >used as a scripting or automation language integrated in other > >software, rather than as a stand-alone language. It is particularly > >popular in the gaming industry. > > > >>> Algol 68 is a great source of inspiration for designers of > >>> programming languages. > >> > >> Obviously. > >> > >>> Useful programming language it is not. > >> > >> I have to read that as valuation of its usefulness for you. > >> (Otherwise, if you're speaking generally, you'd be just wrong.) > >> > > > >The uselessness of Algol 68 as a programming language in the modern > >world is demonstrated by the almost total non-existence of serious > >tools and, more importantly, real-world code in the language. It > >certainly /was/ a useful programming language, long ago, but it has > >not been seriously used outside of historical hobby interest for > >half a century. And unlike other ancient languages (like Cobol or > >Fortran) there is no code of relevance today written in the > >language. Original Algol was mostly used in research, while Algol > >68 was mostly not used at all. As C.A.R. Hoare said, "As a tool for > >the reliable creation of sophisticated programs, the language was a > >failure". > > There is still one computer system that uses Algol as both > the system programming language, and for applications. > > Unisys Clearpath (descendents of the Burroughs B6500). > Is B6500 ALGOL related to A68? My impression from Wikipedia article is that B5000 ALGOL was a proprietary off-spring of A60. Wikipedia says nothing about sources of B6500 ALGOL, but considering that Burroughs was an American enterprise and that back at time in US ALGOL 68 was widely considered as a failed European experiment I would guess that B6500 ALGOL is derived from B5000 ALGOL rather than from A68.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-28 18:28 +0000 |
| Message-ID | <9X7MQ.784007$PBEc.76941@fx48.iad> |
| In reply to | #394895 |
Michael S <already5chosen@yahoo.com> writes: >On Tue, 28 Oct 2025 16:05:47 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> David Brown <david.brown@hesbynett.no> writes: >> >On 28/10/2025 03:00, Janis Papanagnou wrote: >> >> On 27.10.2025 21:39, Michael S wrote: >> >>>> >> >>>> Lua is not Algol 68. >> >>> >> >>> Correct. >> >>> Lua is a useful programming language. >> >> >> >> (I have no stakes here. Never used it.) >> >> >> > >> >It's usefulness is demonstrated by its widespread use. It is mostly >> >used as a scripting or automation language integrated in other >> >software, rather than as a stand-alone language. It is particularly >> >popular in the gaming industry. >> > >> >>> Algol 68 is a great source of inspiration for designers of >> >>> programming languages. >> >> >> >> Obviously. >> >> >> >>> Useful programming language it is not. >> >> >> >> I have to read that as valuation of its usefulness for you. >> >> (Otherwise, if you're speaking generally, you'd be just wrong.) >> >> >> > >> >The uselessness of Algol 68 as a programming language in the modern >> >world is demonstrated by the almost total non-existence of serious >> >tools and, more importantly, real-world code in the language. It >> >certainly /was/ a useful programming language, long ago, but it has >> >not been seriously used outside of historical hobby interest for >> >half a century. And unlike other ancient languages (like Cobol or >> >Fortran) there is no code of relevance today written in the >> >language. Original Algol was mostly used in research, while Algol >> >68 was mostly not used at all. As C.A.R. Hoare said, "As a tool for >> >the reliable creation of sophisticated programs, the language was a >> >failure". >> >> There is still one computer system that uses Algol as both >> the system programming language, and for applications. >> >> Unisys Clearpath (descendents of the Burroughs B6500). >> > >Is B6500 ALGOL related to A68? A-series ALGOL has many extensions. DCAlgol, for example, is used to create applications for data communications (e.g. poll-select multidrop applications such as teller terminals, etc). NEWP is an algol dialect used for systems programming and the operating system itself. ALGOL: https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000098-517/86000098-517.pdf DCALGOL: https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000841-208.pdf NEWP: https://public.support.unisys.com/aseries/docs/ClearPath-MCP-21.0/86002003-409.pdf
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-28 20:49 +0200 |
| Message-ID | <20251028204930.000008f4@yahoo.com> |
| In reply to | #394898 |
On Tue, 28 Oct 2025 18:28:21 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Tue, 28 Oct 2025 16:05:47 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> David Brown <david.brown@hesbynett.no> writes: > >> >On 28/10/2025 03:00, Janis Papanagnou wrote: > >> >> On 27.10.2025 21:39, Michael S wrote: > >> >>>> > >> >>>> Lua is not Algol 68. > >> >>> > >> >>> Correct. > >> >>> Lua is a useful programming language. > >> >> > >> >> (I have no stakes here. Never used it.) > >> >> > >> > > >> >It's usefulness is demonstrated by its widespread use. It is > >> >mostly used as a scripting or automation language integrated in > >> >other software, rather than as a stand-alone language. It is > >> >particularly popular in the gaming industry. > >> > > >> >>> Algol 68 is a great source of inspiration for designers of > >> >>> programming languages. > >> >> > >> >> Obviously. > >> >> > >> >>> Useful programming language it is not. > >> >> > >> >> I have to read that as valuation of its usefulness for you. > >> >> (Otherwise, if you're speaking generally, you'd be just wrong.) > >> >> > >> > > >> >The uselessness of Algol 68 as a programming language in the > >> >modern world is demonstrated by the almost total non-existence of > >> >serious tools and, more importantly, real-world code in the > >> >language. It certainly /was/ a useful programming language, long > >> >ago, but it has not been seriously used outside of historical > >> >hobby interest for half a century. And unlike other ancient > >> >languages (like Cobol or Fortran) there is no code of relevance > >> >today written in the language. Original Algol was mostly used in > >> >research, while Algol 68 was mostly not used at all. As C.A.R. > >> >Hoare said, "As a tool for the reliable creation of sophisticated > >> >programs, the language was a failure". > >> > >> There is still one computer system that uses Algol as both > >> the system programming language, and for applications. > >> > >> Unisys Clearpath (descendents of the Burroughs B6500). > >> > > > >Is B6500 ALGOL related to A68? > > A-series ALGOL has many extensions. > I read your answer as "I don't know. If you are interesting then RTFM by yourself". Is it correct interpretation? > DCAlgol, for example, is used to create applications > for data communications (e.g. poll-select multidrop > applications such as teller terminals, etc). > > NEWP is an algol dialect used for systems programming > and the operating system itself. > > > ALGOL: > https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000098-517/86000098-517.pdf > DCALGOL: > https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000841-208.pdf > NEWP: > https://public.support.unisys.com/aseries/docs/ClearPath-MCP-21.0/86002003-409.pdf
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2025-10-29 21:30 +0000 |
| Message-ID | <875xbxo0or.fsf@bsb.me.uk> |
| In reply to | #394898 |
scott@slp53.sl.home (Scott Lurndal) writes: > Michael S <already5chosen@yahoo.com> writes: >>On Tue, 28 Oct 2025 16:05:47 GMT >>scott@slp53.sl.home (Scott Lurndal) wrote: ... >>> There is still one computer system that uses Algol as both >>> the system programming language, and for applications. >>> >>> Unisys Clearpath (descendents of the Burroughs B6500). >>> >> >>Is B6500 ALGOL related to A68? > > A-series ALGOL has many extensions. > > DCAlgol, for example, is used to create applications > for data communications (e.g. poll-select multidrop > applications such as teller terminals, etc). > > NEWP is an algol dialect used for systems programming > and the operating system itself. > > > ALGOL: > https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000098-517/86000098-517.pdf > DCALGOL: > https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000841-208.pdf > NEWP: > https://public.support.unisys.com/aseries/docs/ClearPath-MCP-21.0/86002003-409.pdf None of these are related to Algol 68, any more than any other Algol-like language might be. None exhibit any of the key features that distinguish Algol 68 from Algol 60 or any of the many Algol-like languages such as Algol W or S-algol (sic). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-28 20:32 +0100 |
| Message-ID | <10dr5o0$2bqrc$1@dont-email.me> |
| In reply to | #394895 |
On 28.10.2025 19:00, Michael S wrote: > On Tue, 28 Oct 2025 16:05:47 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: >> >> There is still one computer system that uses Algol as both >> the system programming language, and for applications. >> >> Unisys Clearpath (descendents of the Burroughs B6500). >> > > Is B6500 ALGOL related to A68? I would have to look that up myself, but in older literature I've seen the all-caps "ALGOL" mostly (only?) in context of Algol 60. I also wouldn't expect that Burroughs is of any relevance nowadays. IMO it anyway doesn't invalidate the fact that Algol 68 is a dead language nowadays, certainly in its practical use, and otherwise also mostly forgotten. Janis > My impression from Wikipedia article is that B5000 ALGOL was a > proprietary off-spring of A60. Wikipedia says nothing about sources of > B6500 ALGOL, but considering that Burroughs was an American enterprise > and that back at time in US ALGOL 68 was widely considered as a failed > European experiment I would guess that B6500 ALGOL is derived from > B5000 ALGOL rather than from A68. > > > >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-28 20:14 +0100 |
| Message-ID | <10dr4nd$2b86l$1@dont-email.me> |
| In reply to | #394885 |
On 28.10.2025 15:59, David Brown wrote: > On 28/10/2025 03:00, Janis Papanagnou wrote: >> On 27.10.2025 21:39, Michael S wrote: >>>> >>>> [ snip Lua statements ] > >>> Algol 68 is a great source of inspiration for designers of >>> programming languages. >> >> Obviously. >> >>> Useful programming language it is not. >> >> I have to read that as valuation of its usefulness for you. >> (Otherwise, if you're speaking generally, you'd be just wrong.) >> > > The uselessness of Algol 68 as a programming language in the modern > world is demonstrated by the almost total non-existence of serious tools > and, more importantly, real-world code in the language. Obviously you are mixing the terms usefulness and dissemination (its actual use). Please accept that I'm differentiating here. There's quite some [historic] languages that were very useful but couldn't disseminate. (For another prominent example cf. Simula, that invented not only the object oriented principles with classes and inheritance, was a paragon for quite some OO-languages later, and it made a lot more technical and design inventions, some even now still unprecedented.) It's a pathological historic phenomenon that programming languages from the non-US American locations had inherent problems to disseminate especially back these days! Reasons for dissemination of a language are multifold; back then (but to a degree also today) they were often determined by political and marketing factors... (you can read about that in various historic documents and also in later ruminations about computing history) > It certainly /was/ a useful programming language, long ago, ...as you seem to basically agree to here. (At least as far as you couple usefulness with dissemination.) > but it has not been > seriously used outside of historical hobby interest for half a century. (Make that four decades. It's been used in the mid 1980's. - Later I didn't follow it anymore, so I cannot tell about the 1990's.) (I also disagree in your valuation "hobby interest"; for "hobbies" there were easier accessible languages used, not systems that were back these days mainly available on mainframes only.) As far as you mean in programming software systems, that may be true; I cannot tell that I'd have an oversight who did use it. I've read about various applications, though; amongst them that it's even been used as a systems programming language (where I was astonished about). > And unlike other ancient languages (like Cobol or Fortran) there is no > code of relevance today written in the language. Probably right. (That would certainly be also my guess.) > Original Algol was > mostly used in research, while Algol 68 was mostly not used at all. As > C.A.R. Hoare said, "As a tool for the reliable creation of sophisticated > programs, the language was a failure". I don't know the context of his statement. If you know the language you might admit that reliable software is exactly one strong property of that language. (Per se already, but especially so if compared to languages like "C", the language discussed in this newsgroup, with an extremely large dissemination and also impact.) > > I'm sure there are /some/ people who have or will write real code in > Algol 68 in modern times The point was that the language per se was and is useful. But its actual usage for developing software systems seems to have been of little and more so it's currently of no importance, without doubt. > (the folks behind the new gcc Algol 68 > front-end want to be able to write code in the language), There's more than the gcc folks. (I've heard, that gcc has taken some substantial code from Genie, an Algol 68 "compiler-interpreter" that is still maintained. BTW; I'm for example using that one, not gcc's.) > but it is very much a niche language. It's _functionally_ a general purpose language, not a niche language (in the sense of "special purpose language"). Its dissemination makes it to a "niche language", that's true. It's in practice just a dead language. It's rarely used by anyone. But it's a very useful language. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-29 16:36 +0100 |
| Message-ID | <10dtc9q$30cp7$1@dont-email.me> |
| In reply to | #394901 |
On 28/10/2025 20:14, Janis Papanagnou wrote: > On 28.10.2025 15:59, David Brown wrote: >> On 28/10/2025 03:00, Janis Papanagnou wrote: >>> On 27.10.2025 21:39, Michael S wrote: >>>>> >>>>> [ snip Lua statements ] >> >>>> Algol 68 is a great source of inspiration for designers of >>>> programming languages. >>> >>> Obviously. >>> >>>> Useful programming language it is not. >>> >>> I have to read that as valuation of its usefulness for you. >>> (Otherwise, if you're speaking generally, you'd be just wrong.) >>> >> >> The uselessness of Algol 68 as a programming language in the modern >> world is demonstrated by the almost total non-existence of serious tools >> and, more importantly, real-world code in the language. > > Obviously you are mixing the terms usefulness and dissemination > (its actual use). Please accept that I'm differentiating here. > > There's quite some [historic] languages that were very useful but > couldn't disseminate. (For another prominent example cf. Simula, > that invented not only the object oriented principles with classes > and inheritance, was a paragon for quite some OO-languages later, > and it made a lot more technical and design inventions, some even > now still unprecedented.) It's a pathological historic phenomenon > that programming languages from the non-US American locations had > inherent problems to disseminate especially back these days! > > Reasons for dissemination of a language are multifold; back then > (but to a degree also today) they were often determined by political > and marketing factors... (you can read about that in various historic > documents and also in later ruminations about computing history) I can certainly agree that some languages, including Algol, Algol 68 and Simula, have had very significant influence on the programming world and other programming languages, despite limited usage. I was interpreting "useful programming language" as meaning "a language useful for writing programs" - and neither Algol 68 nor Simula are sensible choices for writing code today. Neither of them were ever appropriate choices for many programming tasks (Algol and its derivatives was used a lot more than Algol 68). The lack of significant usage of these languages beyond a few niche cases is evidence (but not proof) that they were never particularly useful as programming languages. > >> It certainly /was/ a useful programming language, long ago, > > ...as you seem to basically agree to here. (At least as far as you > couple usefulness with dissemination.) I do couple these, yes. I agree with you that there are many reasons for the popularity of languages other than technical suitability, but many of these add up to the general "usefulness" of the language. When choosing the language to use for a particular task, the availability of programmers familiar with the language, the availability of tools, libraries, and existing code, can be just as important as the language's efficiency, expressibility, or any technical benefits. Consider Bart's language - if we believe him at face value, it is the fastest, clearest, most logical, most powerful, and generally best programming language ever conceived. But for almost every programmer on the planet, it is completely useless. Similarly, Algol 68 may have been the technically best language of its age, and highly influential on other languages, and yet still not a useful programming language. It could also have been a useful programming language in its day, and no longer be a useful programming language. > >> but it has not been >> seriously used outside of historical hobby interest for half a century. > > (Make that four decades. It's been used in the mid 1980's. - Later > I didn't follow it anymore, so I cannot tell about the 1990's.) > > (I also disagree in your valuation "hobby interest"; for "hobbies" > there were easier accessible languages used, not systems that were > back these days mainly available on mainframes only.) I did not suggest that it is now, or ever has been, an appropriate language for hobby programmers - I don't know the language enough to judge. I suggested that anyone programming in Algol 68 today is likely to be doing so as a hobby or for historical interest. (There may be the occasional professional maintaining ancient Algol code for ancient mainframes that are still in use.) > > As far as you mean in programming software systems, that may be true; > I cannot tell that I'd have an oversight who did use it. I've read > about various applications, though; amongst them that it's even been > used as a systems programming language (where I was astonished about). > My understanding - which may well be flawed - is that Algol 60 and many non-standard variants were used quite widely at the time. Algol 68, on the other hand, never took off outside. >> And unlike other ancient languages (like Cobol or Fortran) there is no >> code of relevance today written in the language. > > Probably right. (That would certainly be also my guess.) > >> Original Algol was >> mostly used in research, while Algol 68 was mostly not used at all. As >> C.A.R. Hoare said, "As a tool for the reliable creation of sophisticated >> programs, the language was a failure". > > I don't know the context of his statement. If you know the language > you might admit that reliable software is exactly one strong property > of that language. (Per se already, but especially so if compared to > languages like "C", the language discussed in this newsgroup, with an > extremely large dissemination and also impact.) > I don't know the context either. >> >> I'm sure there are /some/ people who have or will write real code in >> Algol 68 in modern times > > The point was that the language per se was and is useful. But its > actual usage for developing software systems seems to have been of > little and more so it's currently of no importance, without doubt. > >> (the folks behind the new gcc Algol 68 >> front-end want to be able to write code in the language), > > There's more than the gcc folks. (I've heard, that gcc has taken some > substantial code from Genie, an Algol 68 "compiler-interpreter" that > is still maintained. BTW; I'm for example using that one, not gcc's.) > >> but it is very much a niche language. > > It's _functionally_ a general purpose language, not a niche language > (in the sense of "special purpose language"). Its dissemination makes > it to a "niche language", that's true. It's in practice just a dead > language. It's rarely used by anyone. But it's a very useful language. > Can you give any examples of situations where it might be reasonable to choose Algol 68 as a language /today/ for a piece of code, rather than a more mainstream language (C, Python, Java, Pascal, Visual Basic, whatever) ? If such situations are very rare or non-existent, then I do not see it as a useful language. But I think we are mostly disagreeing about what we consider the term "useful programming language" to mean.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 17:24 +0000 |
| Message-ID | <10dtil1$333d0$1@dont-email.me> |
| In reply to | #394936 |
On 29/10/2025 15:36, David Brown wrote:
> On 28/10/2025 20:14, Janis Papanagnou wrote:
>> Reasons for dissemination of a language are multifold; back then
>> (but to a degree also today) they were often determined by political
>> and marketing factors... (you can read about that in various historic
>> documents and also in later ruminations about computing history)
>
> I can certainly agree that some languages, including Algol, Algol 68 and
> Simula, have had very significant influence on the programming world and
> other programming languages, despite limited usage. I was interpreting
> "useful programming language" as meaning "a language useful for writing
> programs" - and neither Algol 68 nor Simula are sensible choices for
> writing code today. Neither of them were ever appropriate choices for
> many programming tasks (Algol and its derivatives was used a lot more
> than Algol 68). The lack of significant usage of these languages beyond
> a few niche cases is evidence (but not proof) that they were never
> particularly useful as programming languages.
Algol68, while refreshingly different when I came across it in the late
70s, was a complex language.
Its reference document, the Revised Report, its two-level van
Wijngaarden grammar, suggested a language too much up its own arse.
Its complexities tended to leak even into straightforward features that
people are familiar with from other languages.
Understanding it, and confidently using it, looked hard. Implementing it
must have been a lot harder.
Also, at the time I'd only ever seen examples of it in print, where it
was beautifully typeset and looked gorgeous.
The reality when I finally got to try it was very different. You spent
half the time fighting with upper/lower case and trying to get
semicolons right. And most of rest grappling with esoteric error
messages couched in terms from the revised report (which has its own
vocabulary).
I borrowed some syntactic features I considered cool, but I had to
produce a real, practical systems language for microprocessors, whose
compiler had to run on the same machine.
From this perspective, I consider it rather dreadful now, with lots of
dubious-sounding aspects.
Take this one: comments start with '#' (an alternative to COMMENT) and
also end with '#'. Leave out '#' (or have a stray one) and everything
now gets out of step.
Or this one:
print((2 + 3 * 4));
BEGIN
PRIO * = 5;
print((2 + 3 * 4))
END
The first print shows 14. The second shows 20, as the precedence of '*'
has been set to match that of '+'.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-27 14:39 +0100 |
| Message-ID | <10dnsm7$rjo7$1@dont-email.me> |
| In reply to | #394784 |
On 27.10.2025 13:50, bart wrote: > On 27/10/2025 02:08, Janis Papanagnou wrote: >> On 26.10.2025 12:26, bart wrote: > [...] > >>> Anyway, I then tried this new 3.10 A68G on the Fannkuch(9) benchmark: >>> >>> a68g fann.a68 5 seconds >>> ./fann 3+3 seconds (via a68g --compile -O3 fann.a68) >>> >>> I then tried it under my scripting language (not statically typed): >>> >>> qq fann 0.4 seconds (qq built with my non-optimising compiler) >> >> Your 'qq' is an Algol 68 implementation? > >> (If not then you're comparing apples to oranges!) > > You've never, ever seen benchmarks comparing one language implementation > with another? First of all, in communication with you here in Usenet I've seen you constantly switching goal posts. - Here again. > > 'qq' implements a pure interpreter for a dynamically typed language. (Obviously completely useless to me.) > > Algol68 is statically typed, which ought to give it the edge. It can be > interpreted (the 5s figure) or compiled to native code (the 3s figure, > and it takes 3s to compile this 60-line program), which here makes > little difference. > > So for all that trouble, A68G's performance is indifferent. If you don't > care for my language, then here some other timings: > > A68G -O3/comp 6 seconds (3s to compile + 3s runtime) > A68G 5 > CPython 3.14: 1.2 > Lua 5.4 0.65 > qq 0.4 > (qq/opt 0.3 Optimised via C transpilation and gcc-O2) > PyPy 3.8: 0.2 > LuaJIT: 0.12 > > The 0.2/0.12 timings are from JIT-accelerated versions. You are again switching goal posts. Here even twice; once for comparing a68g compile times of some program, and second for comparing arbitrary other languages. - The topic of the sub-thread was my correction of your misinformation was how long it takes to create a complete Genie runtime from scratch; 45 seconds. And let me add that you usually don't do that regularly but typically maybe only once or twice a year. Even your imaginary "5 minutes" would be okay for that. Speed is not an end in itself. It must be valued in comparison with all the other often more relevant factors (that you seem to completely miss, even when explained to you). I know your goals are space and speed. And that's fine in principle (unless you're ignoring other relevant factors). >>> [...] > > A68G is poor on this benchmark. Other interpreted solutions are faster. > > It is disappointing after taking all that effort to build. Why do you care? You're anyway using your own languages, don't you? And others do what fit their needs. > > >> So you're again advertising your personal language and tools. - I'm not >> interested in non-standard language (or Windows-) tools, as you've been >> told so many times (also by others). > > Here's an example not related to my stuff: > > c:\cx>tim tcc lua.c > Time: 0.120 > > This builds the Lua intepreter in 1/8th of a second. Now, Tiny C > generally produces indifferent code (ie. slow). Still, I get this result > from my benchmark: > > Lua 5.4 0.65 (lua.exe built using Tiny C) > > It's still at least FIVE TIMES FASTER than A68G! So what? - I don't need a Lua system. So why should I care. You are the one who seems to think that the speed factor is the most important factor to choose a language for a project. - You are wrong for the general case. (But it may be right for your personal universe, of course.) > > >> The tools I'm using for my personal purposes, and those that I had been >> using for professional purposes, all served the necessary requirements. >> Your's don't. > > I'm just showing just how astonishingly fast modern hardware can be. > Like at least a thousand times faster than a 1970s mainframe, and yet > people are still waiting on compilers! You've been explained before many times already by many people that differences in compile time may not beat other more relevant factors. If you'd take a minimum time to think about that we could spare a lot of posts. > > But if you're happy with the performance of your tools, then that's fine. Generally that depends. If execution performance of a binary is crucial (and critical with a safer language) I'd switch to something else, like C++, or "C". Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-27 15:11 +0000 |
| Message-ID | <10do23k$u17l$1@dont-email.me> |
| In reply to | #394788 |
On 27/10/2025 13:39, Janis Papanagnou wrote: > On 27.10.2025 13:50, bart wrote: >> On 27/10/2025 02:08, Janis Papanagnou wrote: >>> On 26.10.2025 12:26, bart wrote: >> > [...] >> >>>> Anyway, I then tried this new 3.10 A68G on the Fannkuch(9) benchmark: >>>> >>>> a68g fann.a68 5 seconds >>>> ./fann 3+3 seconds (via a68g --compile -O3 fann.a68) >>>> >>>> I then tried it under my scripting language (not statically typed): >>>> >>>> qq fann 0.4 seconds (qq built with my non-optimising compiler) >>> >>> Your 'qq' is an Algol 68 implementation? >> >>> (If not then you're comparing apples to oranges!) >> >> You've never, ever seen benchmarks comparing one language implementation >> with another? > > First of all, in communication with you here in Usenet I've seen you > constantly switching goal posts. - Here again. > >> >> 'qq' implements a pure interpreter for a dynamically typed language. > > (Obviously completely useless to me.) > >> >> Algol68 is statically typed, which ought to give it the edge. It can be >> interpreted (the 5s figure) or compiled to native code (the 3s figure, >> and it takes 3s to compile this 60-line program), which here makes >> little difference. >> >> So for all that trouble, A68G's performance is indifferent. If you don't >> care for my language, then here some other timings: >> >> A68G -O3/comp 6 seconds (3s to compile + 3s runtime) >> A68G 5 >> CPython 3.14: 1.2 >> Lua 5.4 0.65 >> qq 0.4 >> (qq/opt 0.3 Optimised via C transpilation and gcc-O2) >> PyPy 3.8: 0.2 >> LuaJIT: 0.12 >> >> The 0.2/0.12 timings are from JIT-accelerated versions. > > You are again switching goal posts. Here even twice; once for comparing > a68g compile times of some program, and second for comparing arbitrary > other languages. Have a look at, for example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html I guess you would call that all a waste of time. To me, it is useful, but flawed, since different implementations are allowed. >- The topic of the sub-thread was my correction of > your misinformation was how long it takes to create a complete Genie > runtime from scratch; 45 seconds. I gave you actual measurements from my machine. > Speed is not an end in itself. It must be valued in comparison with > all the other often more relevant factors (that you seem to completely > miss, even when explained to you). Speed seems to be important enough that huge efforts have gone into creating the best optimising compilers over decades. Fantastically complex products like LLVM exist, which take 100 times longer to compile code than a naive compiler, in order to eke out the last bit of performance. Similarly, massive investment has gone into making dynamic languages fast, like the state-of-the-art products used in running JavaScript, or the numerous JIT approaches used to accelerate languages like Python and Ruby. Build-speed is taken seriously enough, and most 'serious' compilers are slow enough, that complex build systems exist, which use dependencies in order to avoid compilation as much as possible. Or failing that, by parallelising builds across multiple cores, possibly even across distributed machines. So, fortunately some people take this stuff more seriously than you do. I am also involved in this field, and my experimental work takes the approach of simplicity to achieve results. > > I know your goals are space and speed. And that's fine in principle > (unless you're ignoring other relevant factors). LLVM is a backend project which is massively bigger, more complex and slower (in build speed) than my stuff, by a number of magnitudes in each case. The resulting code however, might only be a fraction of a magnitude faster (for example the 0.3 vs 0.4 timings above, achieved via gcc, but LLVM would be similar). And that's if you apply the optimiser, which I would only use for production builds, or for benchmarking. Otherwise its code is just as poor as mine, or worse, but it still takes longer to build stuff! For me the trade-offs of a big, cumbersome product don't work. I like my near-zero builds and can work more spontaneously! >> It's still at least FIVE TIMES FASTER than A68G! [2-3 TIMES FASTER] > > So what? - I don't need a Lua system. So why should I care. > > You are the one who seems to think that the speed factor is the most > important factor to choose a language for a project. - You are wrong > for the general case. (But it may be right for your personal universe, > of course.) You are wrong. What language do you use most? Let's say it is C (although you usually post about every other language except C!). Then, suppose your C compiler was written in Python rather than C++ or whatever and run under CPython. What you think would happen to your build-times? Now imagine further if the CPython interpreter was inself written and executed with CPython. So, the 'speed' of a language (ie. of its typical implementation, which also depends on the language design) does matter. If speed wasn't an issue then we'd all be using easy dynamic languages for productivity. In reality those easy languages are far too slow in most cases. > >> >> >>> The tools I'm using for my personal purposes, and those that I had been >>> using for professional purposes, all served the necessary requirements. >>> Your's don't. >> >> I'm just showing just how astonishingly fast modern hardware can be. >> Like at least a thousand times faster than a 1970s mainframe, and yet >> people are still waiting on compilers! > > You've been explained before many times already by many people that > differences in compile time may not beat other more relevant factors. I've also explained that I work by very freqent edit-run cycles. Then compile-times matter. This is why many like to use scripting languages as those don't have a discernible build step. But I can use my system language, *or* C via my compiler, just like a scripting language. You will find now various projects that apply JIT-techniques to such languages in an effort to provide a similar experience. (I don't need such techniques as my AOT compilers already work near-instantly.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-28 03:35 +0100 |
| Message-ID | <10dpa4q$1ghgu$1@dont-email.me> |
| In reply to | #394795 |
On 27.10.2025 16:11, bart wrote: > On 27/10/2025 13:39, Janis Papanagnou wrote: >> On 27.10.2025 13:50, bart wrote: > >>> It's still at least FIVE TIMES FASTER than A68G! [2-3 TIMES FASTER] >> >> So what? - I don't need a Lua system. So why should I care. >> >> You are the one who seems to think that the speed factor is the most >> important factor to choose a language for a project. - You are wrong >> for the general case. (But it may be right for your personal universe, >> of course.) > > You are wrong. With which part? - With how I think you value project requirements? I can only derive your mindset from the myriads of posts you emitted over time with basically always the same content and focus. > What language do you use most? What shall that prove? - The projects' requirements are generally independent of my personal usage of programming languages. > Let's say it is C > (although you usually post about every other language except C!). That's meaningless, but if you're interested to know... Mostly (including my professional work) I've probably used C++. But also other languages, depending on either projects' requirements or, where there was a choice, what appeared to be fitting best (and "best" sadly includes also bad languages if there's no alternative). > > Then, suppose your C compiler was written in Python rather than C++ or > whatever and run under CPython. What you think would happen to your > build-times? The build-times have rarely been an issue; never in private context, and in professional contexts with MLOCS of code these things have been effectively addressed. (I recall you were unfamiliar with make files, or am I misremembering?) > > Now imagine further if the CPython interpreter was inself written and > executed with CPython. > > So, the 'speed' of a language (ie. of its typical implementation, which > also depends on the language design) does matter. > > If speed wasn't an issue then we'd all be using easy dynamic languages Huh? - Certainly not. Your mindset is really amazingly biased and restricted if it comes to speed as argument for or against "dynamic languages". - Speed may for some cases be a factor for such (poorly founded) decisions, but choice of language for a project (as I tried to explain you so many times) depends on many more important factors. I'm still unsure whether you grasped that the programming world and its projects is not a personal event. (In you're speaking only about one's personal context the person can do what he likes.) - If you're not willing to accept that or try to understand it I can't help you. > for productivity. In reality those easy languages are far too slow in > most cases. Speed is a topic, but as I wrote you have to put it in context >> >> Speed is not an end in itself. It must be valued in comparison >> with all the other often more relevant factors (that you seem to >> completely miss, even when explained to you). >>> [...] >> >> You've been explained before many times already by many people that >> differences in compile time may not beat other more relevant factors. > > I've also explained that I work by very freqent edit-run cycles. Then > compile-times matter. And I regular acknowledge that I see that it's the primary factor in your working context. > This is why many like to use scripting languages > as those don't have a discernible build step. I can't tell about the "many" that you have in mind, and about their mindset; I'm sure you either can't tell. I'm using for very specific types of tasks "scripting languages" - and keep in mind that there's no clean definition of that! - As far as I can tell there's various reasons for such decisions; certainly that's the case in my professional and private contexts. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-28 11:16 +0000 |
| Message-ID | <10dq8lr$1tm90$1@dont-email.me> |
| In reply to | #394850 |
On 28/10/2025 02:35, Janis Papanagnou wrote: > On 27.10.2025 16:11, bart wrote: > That's meaningless, but if you're interested to know... > Mostly (including my professional work) I've probably used C++. > But also other languages, depending on either projects' requirements > or, where there was a choice, what appeared to be fitting best (and > "best" sadly includes also bad languages if there's no alternative). Which bad languages are these? > The build-times have rarely been an issue; never in private context, > and in professional contexts with MLOCS of code these things have > been effectively addressed. Not really. There are the workarounds and compromises that I listed: compilation is avoided as much as possible. For that you need to use independent compilation, and require dependency graphs and external tools to manage the process. That CDECL took, what, 49 seconds on my machine, to process 68Kloc of C? That's a whopping 1400 lines per second! If we go back 45 years to machines that were 1000 times slower, the same process would only manage 1.4 lines per second, and it would take 13 HOURS, to create an interactive program that explained what 'int (*(*(*)))[]()' (whatever it was) might mean. So, yeah, build-time is a problem, even on the ultra-fast hardware we have now. Bear in mind that CDECL (like every finished product you build from source) is a working, debugged program. You shouldn't need to do that much analysis of it. And here, its performance is not critical either: you don't even need fast code from it. (I recall you were unfamiliar with make > files, or am I misremembering?) I know makefiles. Never used them, never will. You might recall that I create my own solutions. >> >> Now imagine further if the CPython interpreter was inself written and >> executed with CPython. >> >> So, the 'speed' of a language (ie. of its typical implementation, which >> also depends on the language design) does matter. >> >> If speed wasn't an issue then we'd all be using easy dynamic languages > > Huh? - Certainly not. *I* would! That's why I made my scripting languages as fast and capable as possible, so they could be used for more tasks. However, if I dare to suggest that even one other person in the world might also have the same desire, you'd say that I can't possibly know that. And yet here you are: you say 'certainly not'. Obviously *you* know everyone else's mindset! > Speed is a topic, but as I wrote you have to put it in context Actually, the real topic is slowness. I'm constantly coming across things which I know (from half a century working with computers) are far slower than they ought to be. But I'm also coming across people who seem to accept that slowness as just how things are. They should question things more! > I can't tell about the "many" that you have in mind, and about their > mindset; I'm sure you either can't tell. I'm pretty sure there are quite a few million users of scripting languages. > > I'm using for very specific types of tasks "scripting languages" - > and keep in mind that there's no clean definition of that! They have typical characteristics as I'm quite sure you're aware. For example: * Dynamic typing * Run from source * Instant edit-run cycle * Possible REPL * Uncluttered syntax * Higher level features * Extensive libraries so that you can quickly 'script' most tasks So, interactivity and spontaneity. But they also have cons: * Slower execution * Little compile-time error checking * Less control (of data structures for example)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-28 14:59 -0700 |
| Message-ID | <87zf9azo0m.fsf@example.invalid> |
| In reply to | #394879 |
bart <bc@freeuk.com> writes:
> On 28/10/2025 02:35, Janis Papanagnou wrote:
>> On 27.10.2025 16:11, bart wrote:
[...]
>>> If speed wasn't an issue then we'd all be using easy dynamic languages
>> Huh? - Certainly not.
>
> *I* would! That's why I made my scripting languages as fast and
> capable as possible, so they could be used for more tasks.
>
> However, if I dare to suggest that even one other person in the world
> might also have the same desire, you'd say that I can't possibly know
> that.
>
> And yet here you are: you say 'certainly not'. Obviously *you* know
> everyone else's mindset!
I'll give this one more try.
This kind of thing makes it difficult to communicate with you.
In this particular instances, you wrote that "we'd **all** be using easy
dynamic languages" (emphasis added).
Janis replied "Certainly not." -- meaning that we would not **all** be
using easy dynamic languages. Janis is correct if there are only a few
people, or even one person, who would not use easy dynamic languages.
In reply to that, you wrote that **you** would use such languages --
which is fine and dandy, but it doesn't refute what Janis wrote.
Nobody at any time claimed that *nobody* would use easy dynamic
languages. Obviously some people do and some people don't. If speed
were not an issue, that would still be the case, though it would likely
change the numbers. (There are valid reasons other than speed to use
non-dynamic languages.)
Are you with me so far?
You then wrote:
However, if I dare to suggest that even one other person in the world
might also have the same desire, you'd say that I can't possibly know
that.
That's wrong. I'll assume it was an honest mistake. If you suggested
that even one other person might also have the same desire, I don't
think anyone would dispute it. *Of course* there are plenty of people
who want to use dynamic languages, and there would be more if speed were
not an issue. As you have done before, you make incorrect assumptions
about other people's thoughts and motives.
> And yet here you are: you say 'certainly not'. Obviously *you* know
> everyone else's mindset!
The "certainly not" was in response to your claim that we would ALL
be using dynamic languages, a claim that was at best hyberbole. Nobody
has claimed to know everyone else's mindset.
You misunderstood what Janis wrote. It happens to all of us. You just
need to be aware that what Janis wrote was not what you thought Janis
wrote, and you have reacted to something nobody said -- and not for the
first time.
This post is likely to be a waste of time, but I'm prepared to be
pleasantly surprised.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-28 23:14 +0000 |
| Message-ID | <10drip8$2gm7h$1@dont-email.me> |
| In reply to | #394916 |
On 28/10/2025 21:59, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 28/10/2025 02:35, Janis Papanagnou wrote:
>>> On 27.10.2025 16:11, bart wrote:
> [...]
>>>> If speed wasn't an issue then we'd all be using easy dynamic languages
>>> Huh? - Certainly not.
>>
>> *I* would! That's why I made my scripting languages as fast and
>> capable as possible, so they could be used for more tasks.
>>
>> However, if I dare to suggest that even one other person in the world
>> might also have the same desire, you'd say that I can't possibly know
>> that.
>>
>> And yet here you are: you say 'certainly not'. Obviously *you* know
>> everyone else's mindset!
>
> I'll give this one more try.
>
> This kind of thing makes it difficult to communicate with you.
You're talking to the wrong guy. It's JP who's difficult to talk to.
He (I assume) always dismisses every single one of my arguments out of hand:
Build speed is never a problem - ever. The speed of any language
implemention is never a concern either.
Despite describing all the work that has gone on with making
optimisation compilers, faster linkers, tracing-JIT interpreters etc,
all of which suggest that some people think these are very much a
problem, that cuts no ice at all.
When I gave the example of my language that was 1000 times faster to
build than A68G, and which ran that test 10 times faster than A68G, that
apparently doesn't count; he doesn't care; or I'm changing the goalposts.
So I instead gave an example of Tiny C building Lua, and running the
test under Lua, but that was no good either:
"Lua is not Algol68".
It is just impossible get through. He is never going to admit that A68G
is rather sluggish in its performance (I guess suggesting optimised C
might be faster than A68G won't work either, since C isn't Algol68!)
It's rather frustrating. It's even more frustrating when you take his
side and think I'm the one who needs convincing about anything.
I made this remark:
> This is why many like to use scripting languages
> as those don't have a discernible build step.
On the face of it, it is uncontroversial: they do allow rapid
development and instant feedback, as one of their several pros. Yet, JP
feels the need to be contrary:
>I can't tell about the "many" that you have in mind, and about their
mindset; I'm sure you either can't tell.
And now you have joined in, to back him up!
>
> In this particular instances, you wrote that "we'd **all** be using easy
> dynamic languages" (emphasis added).
>
> Janis replied "Certainly not." -- meaning that we would not **all** be
> using easy dynamic languages. Janis is correct if there are only a few
> people, or even one person, who would not use easy dynamic languages.
You're still on about the logic and trying to prove that JP was right
and I was wrong.
JP is trying to trash everything I say and everything I do.
> In reply to that, you wrote that **you** would use such languages --
> which is fine and dandy, but it doesn't refute what Janis wrote.
>
> Nobody at any time claimed that *nobody* would use easy dynamic
> languages. Obviously some people do and some people don't. If speed
> were not an issue, that would still be the case, though it would likely
> change the numbers. (There are valid reasons other than speed to use
> non-dynamic languages.)
>
> Are you with me so far?
>
> You then wrote:
>
> However, if I dare to suggest that even one other person in the world
> might also have the same desire, you'd say that I can't possibly know
> that.
>
> That's wrong. I'll assume it was an honest mistake. If you suggested
> that even one other person might also have the same desire, I don't
> think anyone would dispute it. *Of course* there are plenty of people
> who want to use dynamic languages, and there would be more if speed were
> not an issue. As you have done before, you make incorrect assumptions
> about other people's thoughts and motives.
>
>> And yet here you are: you say 'certainly not'. Obviously *you* know
>> everyone else's mindset!
>
> The "certainly not" was in response to your claim that we would ALL
> be using dynamic languages, a claim that was at best hyberbole. Nobody
> has claimed to know everyone else's mindset.
>
> You misunderstood what Janis wrote.
I understand what he's trying to do. He despises me; he thinks the
projects I work on are worthless. And any results I get can be
dismissed. Meanwhile he's a 'professional', as stated many times.
Maybe you can make up your own mind: here's a survey of mostly
interpreted languages, all running the same Fibonacci benchmark:
https://www.reddit.com/r/Compilers/comments/1jyl98f/fibonacci_survey/
My products are marked with "*". You can see that the fastest purely
interpreted language is one of mine.
JP won't accept any of this, even if you took my stuff out, because he
contends that you can't compare different languages.
> This post is likely to be a waste of time, but I'm prepared to be
> pleasantly surprised.
*I'm* waiting to be pleasantly suprised by you agreeing with me for a change
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-28 18:48 -0700 |
| Message-ID | <87sef2zde6.fsf@example.invalid> |
| In reply to | #394923 |
bart <bc@freeuk.com> writes:
> On 28/10/2025 21:59, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 28/10/2025 02:35, Janis Papanagnou wrote:
>>>> On 27.10.2025 16:11, bart wrote:
>> [...]
>>>>> If speed wasn't an issue then we'd all be using easy dynamic languages
>>>> Huh? - Certainly not.
>>>
>>> *I* would! That's why I made my scripting languages as fast and
>>> capable as possible, so they could be used for more tasks.
>>>
>>> However, if I dare to suggest that even one other person in the world
>>> might also have the same desire, you'd say that I can't possibly know
>>> that.
>>>
>>> And yet here you are: you say 'certainly not'. Obviously *you* know
>>> everyone else's mindset!
>> I'll give this one more try.
>> This kind of thing makes it difficult to communicate with you.
>
> You're talking to the wrong guy. It's JP who's difficult to talk to.
No, I'm talking to you. It turns out that was a mistake.
My post was **only** about your apparent confusion about a single
statement, quoted above. I wasn't talking about JP personally, or about
any of his other interactions with you. I explained in great detail
what I was referring to. You ignored it.
You seem unwilling or unable to focus on one thing.
> He (I assume) always dismisses every single one of my arguments out of hand:
>
> Build speed is never a problem - ever. The speed of any language
> implemention is never a concern either.
And here you are putting words in other people's mouths.
I think you goal is to argue, not to do anything that might result in
agreement or learning.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 19:24 +0000 |
| Message-ID | <10dtpkr$34kqk$1@dont-email.me> |
| In reply to | #394928 |
On 29/10/2025 01:48, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 28/10/2025 21:59, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> On 28/10/2025 02:35, Janis Papanagnou wrote: >>>>> On 27.10.2025 16:11, bart wrote: >>> [...] >>>>>> If speed wasn't an issue then we'd all be using easy dynamic languages >>>>> Huh? - Certainly not. >>>> >>>> *I* would! That's why I made my scripting languages as fast and >>>> capable as possible, so they could be used for more tasks. >>>> >>>> However, if I dare to suggest that even one other person in the world >>>> might also have the same desire, you'd say that I can't possibly know >>>> that. >>>> >>>> And yet here you are: you say 'certainly not'. Obviously *you* know >>>> everyone else's mindset! >>> I'll give this one more try. >>> This kind of thing makes it difficult to communicate with you. >> >> You're talking to the wrong guy. It's JP who's difficult to talk to. > > No, I'm talking to you. It turns out that was a mistake. > > My post was **only** about your apparent confusion about a single > statement, quoted above. I wasn't talking about JP personally, or about > any of his other interactions with you. I explained in great detail > what I was referring to. You ignored it. > > You seem unwilling or unable to focus on one thing. > >> He (I assume) always dismisses every single one of my arguments out of hand: >> >> Build speed is never a problem - ever. The speed of any language >> implemention is never a concern either. > > And here you are putting words in other people's mouths. > > I think you goal is to argue, not to do anything that might result in > agreement or learning. Again, I think you're mixing up me and JP, whose only goal is to contradict and refute everything I say. I say: X has some problem; Y doesn't have that problem. This is about approaches to building software. He refuses to acknowledge that X has any problem whatsoever, or shrugs off the importance He refuses to accept that Y is a solution, because I devised it and he looks down upon me because he considers himself superior. He refuses to accept Z (which I haven't devised) for other reasons (to avoid admitting that I might have a point). The problems are X are real and I think you have acknowledged them. But I have decades of experience of viable alternatives so I think I can offer an educated, alternative opinion JP I don't think has offered any better alternatives has not devised any that I am aware. So he is just and user of such software and not a creator. This is rather frustrating to me. You seem to be on his side, and don't care about X versus Y either.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-29 15:10 -0700 |
| Message-ID | <87bjlpgxzy.fsf@example.invalid> |
| In reply to | #394940 |
bart <bc@freeuk.com> writes:
> On 29/10/2025 01:48, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 28/10/2025 21:59, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 28/10/2025 02:35, Janis Papanagnou wrote:
>>>>>> On 27.10.2025 16:11, bart wrote:
>>>> [...]
>>>>>>> If speed wasn't an issue then we'd all be using easy dynamic languages
[...]
Bart, is the above statement literally accurate? Do you believe that
we would ALL be using "easy dynamic languages" if speed were not an
issue, meaning that non-dynamic languages would die out completely?
That's what this whole sub-argument is about.
Maybe your statement was meant to be hyberbole, and that what you
really meant is that dynamic languages would be more popular than
they are now if speed were not an issue. Possibly someone just took
your figuratative statement a little too literally. If that's the
case, please just say so.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 23:19 +0000 |
| Message-ID | <10du7de$39jdl$1@dont-email.me> |
| In reply to | #394946 |
On 29/10/2025 22:10, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 29/10/2025 01:48, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> On 28/10/2025 21:59, Keith Thompson wrote: >>>>> bart <bc@freeuk.com> writes: >>>>>> On 28/10/2025 02:35, Janis Papanagnou wrote: >>>>>>> On 27.10.2025 16:11, bart wrote: >>>>> [...] >>>>>>>> If speed wasn't an issue then we'd all be using easy dynamic languages > [...] > > Bart, is the above statement literally accurate? Literally as in all 8.x billion individuals on the planet, including infants and people in comas, would be using such languages? This is what you seem to be suggesting that I mean, and here you're both being overly pedantic. You could just agree with me you know! 'If X then we'd all be doing Y' is a common English idiom, suggesting X was a no-brainer. > Do you believe that > we would ALL be using "easy dynamic languages" if speed were not an > issue, meaning that non-dynamic languages would die out completely? Yes, I believe that if dynamic languages, however they are implemented, could always deliver native code speeds, then a huge number of people, and companies, would switch because of that and other benefits. Bear in mind that if that was the case, then new dynamic languages could emerge that help broad their range of applications. > > That's what this whole sub-argument is about. Well I didn't start it. Somebody suggested the speed of a language implementation had little relevance (not willing to admit the shortcomings of A68G), and I suggested in light-hearted idiom that if dynamic languages were much faster, their take-up would be much greater. What should I have said, that it would increase by 54.91% over the next 4 quarters? (Remind me to run my posts through a lawyer next time.) > really meant is that dynamic languages would be more popular than > they are now if speed were not an issue. Possibly someone just took > your figuratative statement a little too literally. If that's the > case, please just say so. Oh, you finaly got it! See it wasn't hard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-29 18:03 -0700 |
| Message-ID | <87wm4dfbg9.fsf@example.invalid> |
| In reply to | #394949 |
bart <bc@freeuk.com> writes:
> On 29/10/2025 22:10, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 29/10/2025 01:48, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 28/10/2025 21:59, Keith Thompson wrote:
>>>>>> bart <bc@freeuk.com> writes:
>>>>>>> On 28/10/2025 02:35, Janis Papanagnou wrote:
>>>>>>>> On 27.10.2025 16:11, bart wrote:
>>>>>> [...]
>>>>>>>>> If speed wasn't an issue then we'd all be using easy dynamic languages
>> [...]
>> Bart, is the above statement literally accurate?
>
> Literally as in all 8.x billion individuals on the planet, including
> infants and people in comas, would be using such languages?
>
> This is what you seem to be suggesting that I mean, and here you're
> both being overly pedantic. You could just agree with me you know!
I have agreed with a significant number of your statements in the recent
past. I would not consider agreeing with this particular statement
without understanding just what you meant by it. (That would be a
necessary but sufficient prerequisite for my agreement.)
> 'If X then we'd all be doing Y' is a common English idiom, suggesting
> X was a no-brainer.
So you were being figurative, not literal. That's what I thought.
Thank you for confirming it.
>> Do you believe that
>> we would ALL be using "easy dynamic languages" if speed were not an
>> issue, meaning that non-dynamic languages would die out completely?
>
> Yes, I believe that if dynamic languages, however they are
> implemented, could always deliver native code speeds, then a huge
> number of people, and companies, would switch because of that and
> other benefits.
You are conflating "a huge number of people" with "ALL". I suppose this
is meant to be hyperbole.
You wrote :
If speed wasn't an issue then we'd all be using easy dynamic
languages
Janis replied :
Huh? - Certainly not.
Your reply to that was :
*I* would! That's why I made my scripting languages as fast and
capable as possible, so they could be used for more tasks.
That is not responsive to what Janis wrote. I'm 99% sure that
Janis's stated opinion is that *some but not all* programmers would
switch to "easy dynamic langauges" if speed were not an issue.
Telling us that you would does not contradict what Janis wrote
or meant.
However, if I dare to suggest that even one other person in the
world might also have the same desire, you'd say that I can't
possibly know that.
No. If you suggested that one or more other people would switch to
dynamic languages if speed were not an issue, I probably wouldn't even
reply, because that statement would be so obviously true that it
wouldn't be worth discussing. Your ideas about what other people think
are so distorted that you assume we would disagree.
And yet here you are: you say 'certainly not'. Obviously *you* know
everyone else's mindset!
And that's just nonsense, and *completely* nonresponsive to what Janis
wrote.
Your position is that, if speed were not an issue, "a huge
number of people, and companies, would switch" to "easy dynamic
languages". My position, and I believe Janis's position, is that *many*
people and companies would likely switch to such languages in those
circumstances, but probably not "a huge number". (I'm not interested in
debating what "a huge number" means. (I acknowledge the possiblity that
you're right and Janis and I are wrong, but we'll never know, because
speed will never not be an issue. In any case, the point of this reply
is to establish what was actually said, not who is right or wrong.)
When Janis expressed skepticism about your claim that either "all"
or "a huge number" of people would switch, you reacted exactly as
if Janis had says that *nobody* would switch. You were offended by
something that neither Janis nor anyone else wrote or suggested.
I don't care who started the argument, but your misinterpretation
of what Janis wrote is what has caused it to continue.
This kind of thing keeps happening.
Do you understand what I'm saying?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-30 09:02 +0100 |
| Message-ID | <10dv62b$3gl7t$1@dont-email.me> |
| In reply to | #394949 |
On 30/10/2025 00:19, bart wrote: > On 29/10/2025 22:10, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 29/10/2025 01:48, Keith Thompson wrote: >>>> bart <bc@freeuk.com> writes: >>>>> On 28/10/2025 21:59, Keith Thompson wrote: >>>>>> bart <bc@freeuk.com> writes: >>>>>>> On 28/10/2025 02:35, Janis Papanagnou wrote: >>>>>>>> On 27.10.2025 16:11, bart wrote: >>>>>> [...] >>>>>>>>> If speed wasn't an issue then we'd all be using easy dynamic >>>>>>>>> languages >> [...] >> >> Bart, is the above statement literally accurate? > > Literally as in all 8.x billion individuals on the planet, including > infants and people in comas, would be using such languages? > > This is what you seem to be suggesting that I mean, and here you're both > being overly pedantic. You could just agree with me you know! > > 'If X then we'd all be doing Y' is a common English idiom, suggesting X > was a no-brainer. > > >> Do you believe that >> we would ALL be using "easy dynamic languages" if speed were not an >> issue, meaning that non-dynamic languages would die out completely? > > Yes, I believe that if dynamic languages, however they are implemented, > could always deliver native code speeds, then a huge number of people, > and companies, would switch because of that and other benefits. > This would all be /so/ much easier if you just wrote what you meant in the first place. You don't need to use exaggerations and hyperbole, and you don't need to extrapolate your own opinions as though they apply to everyone. And it doesn't help when you write with the assumption that your gut feelings (with no objective information to back them up) are "no-brainers" or somehow obvious, and then you get in a fluster when others disagree. On the particular point here, would more people use "dynamic languages" (a somewhat vague term, but we are speaking vaguely here anyway) if speed were not an issue? I think if languages like Python or Javascript were faster, we'd see a /little/ more use of them - but not much more. After all, dynamic languages are already massively popular in particular fields with today's speeds. And while I doubt if anyone would complain if they were faster (unless the speed increase cost in other ways), they are apparently fast enough for a very wide range of uses. Of course there are situations where people have thought "Python is too slow for this, so I will have to use C even though I hate that language". But I personally do not think that will be the case for a "huge number of people and companies". > Bear in mind that if that was the case, then new dynamic languages could > emerge that help broad their range of applications. > New dynamic languages pop up regularly, and there are many ways in which their speed is being improved (such as JIT, or better byte compiling and better VM's, as well as language design targeting speed). But sure, new ones could emerge that cover different use-cases better. The same applies to static languages. Whether the speed of any /particular/ language - such as Algol 68 - affected its uptake, is another matter.
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web