Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #44345 > unrolled thread
| Started by | Joerg Walther <joerg.walther@magenta.de> |
|---|---|
| First post | 2024-04-06 09:37 +0200 |
| Last post | 2024-05-15 15:32 +0200 |
| Articles | 20 on this page of 262 — 28 participants |
Back to article view | Back to de.alt.folklore.computer
Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 09:37 +0200
Re: Triumph of the Nerds Michael Pachta <mipani@gmx.de> - 2024-04-06 10:06 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 11:37 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-06 11:14 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 11:39 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-08 12:27 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-08 13:33 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-17 17:33 +0000
Re: Triumph of the Nerds Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-04-18 08:46 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-04-18 19:41 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-19 18:44 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-20 22:34 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-21 17:18 +0200
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 07:41 +0200
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-24 08:49 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 11:38 +0200
Re: Triumph of the Nerds Michael Kraemer <m.kraemer@gsi.de> - 2024-04-24 16:28 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-24 18:55 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 20:53 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-30 13:33 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:11 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:15 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 18:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-02 21:14 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-02 21:16 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 07:46 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-03 20:21 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:03 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-04 07:14 +0000
Re: Triumph of the Nerds Michael Kraemer <m.kraemer@gsi.de> - 2024-05-04 09:37 +0200
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 11:23 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 13:17 +0200
Re: C Michael Kraemer <m.kraemer@gsi.de> - 2024-05-04 14:47 +0200
Re: C Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:43 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:41 +0200
Re: C "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 02:08 +0200
Re: C Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:41 +0200
Re: C Ralf Damaschke <rwspam@gmx.de> - 2024-05-05 16:02 +0000
Re: C Ralf Damaschke <rwspam@gmx.de> - 2024-05-05 23:47 +0000
Re: C "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:55 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:50 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-04 11:26 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-04 10:01 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 12:19 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:47 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 13:20 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-04 09:09 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-04 11:23 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-05 10:16 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:18 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 18:41 +0200
Pascal (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:55 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 06:40 +0200
Re: Pascal "F. W." <me@home.invalid> - 2024-05-07 07:48 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 08:26 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 13:04 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 14:57 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 13:11 +0000
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 13:55 +0000
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 21:33 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 07:42 +0000
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:09 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 12:37 +0200
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:42 +0200
Re: Pascal Andreas Bockelmann <xotzil@gmx.de> - 2024-05-12 11:36 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-12 13:42 +0000
Re: Pascal Andreas Bockelmann <xotzil@gmx.de> - 2024-05-12 19:19 +0200
Re: Pascal Andreas Karrer <ak-4a@gmx.ch> - 2024-05-12 21:39 +0000
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 16:09 +0200
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 17:49 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 20:56 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-12 19:46 +0000
Re: Pascal Peter Müller <invalid@invalid.invalid> - 2024-05-12 22:00 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:16 +0200
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:20 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 21:13 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-13 10:39 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 09:20 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:03 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-08 04:13 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-08 12:01 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-13 01:54 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-13 10:51 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-13 13:45 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-13 14:04 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-13 17:23 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 11:22 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 15:57 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 18:30 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 21:54 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 13:04 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 11:45 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 20:53 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 08:42 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 21:56 +0000
Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 21:06 +0200
Re: Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 07:31 +0000
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 10:12 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 13:03 +0000
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 16:03 +0200
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 16:57 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 17:36 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 18:52 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 03:49 +0200
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 19:22 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 04:07 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 17:00 +0000
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 20:25 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 20:55 +0000
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 23:53 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 04:26 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:53 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 20:09 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 12:50 +0200
Yoda expressions (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:39 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 14:16 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 19:04 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:28 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 18:33 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 13:09 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:01 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:01 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 20:15 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:18 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:36 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:37 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:51 +0200
Re: Triumph of the Nerds "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-05-06 07:41 +0000
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:13 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:58 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 10:34 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 14:00 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:57 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 12:06 +0000
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:29 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 06:49 +0200
Re: C Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:30 +0000
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 09:42 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 18:55 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:03 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:32 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 09:44 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 08:26 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:13 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-05-07 21:50 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 21:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:16 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:10 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-08 08:40 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 14:19 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-08 15:14 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-08 18:16 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 17:30 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:20 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 12:19 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 17:52 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:43 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 16:48 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:40 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 14:26 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:38 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 21:09 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-02 19:46 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 18:44 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:09 +0200
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 12:58 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 15:07 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:06 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-30 17:40 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-01 07:17 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-01 09:10 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:40 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-01 12:18 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 20:44 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-02 07:31 +0200
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-02 05:54 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-03 09:25 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 08:35 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-03 11:20 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:13 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 21:14 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-06 07:48 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:12 +0200
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-06 07:49 +0200
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-06 23:53 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:34 +0000
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-07 22:48 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-08 06:35 +0000
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-09 15:37 +0200
Re: Triumph of the Nerds Andreas Eder <a_eder_muc@web.de> - 2024-05-09 22:53 +0200
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-10 01:05 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 16:09 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-02 19:31 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-02 19:50 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:07 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 09:08 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 11:40 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-24 17:31 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 20:57 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-25 10:04 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-25 08:59 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-25 11:52 +0000
Re: Triumph of the Nerds Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-04-25 14:47 +0000
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-25 18:59 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-26 15:38 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 07:13 +0200
Re: Triumph of the Nerds Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-04-26 13:04 +0000
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 19:45 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-27 10:42 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-27 13:18 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:25 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-30 14:40 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 19:01 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-02 20:18 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-03 22:46 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-04 02:02 +0000
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-28 01:40 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-29 06:26 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-29 16:11 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-30 11:32 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-30 11:13 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:33 +0000
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-04-30 16:30 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-04-30 16:46 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 19:16 +0000
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 13:07 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 16:03 +0200
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 18:10 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-05-06 21:53 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:08 +0000
Re: Triumph of the Nerds Guido Grohmann <guido.grohmann@gmx.de> - 2024-05-07 06:59 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 08:28 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 16:10 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:15 +0000
Re: Triumph of the Nerds Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-05-08 08:42 +0200
Re: Triumph of the Nerds Guido Grohmann <guido.grohmann@gmx.de> - 2024-05-07 16:51 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 17:42 +0200
Re: Triumph of the Nerds Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-04-30 15:10 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-04-30 19:08 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-05-01 08:15 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:46 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:34 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-30 18:34 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:50 +0000
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-24 16:59 +0200
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-04-28 19:35 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-28 20:24 +0000
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-04-28 23:26 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:43 +0000
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-05-02 20:07 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-02 20:48 +0200
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-05-03 23:15 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 10:00 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 11:33 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 15:14 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-29 13:21 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-04-30 07:33 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-04-30 17:55 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:54 +0000
Re: Triumph of the Nerds Andreas Eder <a_eder_muc@web.de> - 2024-04-30 22:57 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 15:32 +0200
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-09 16:57 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <slrnv3pp37.1mhit.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44625 |
On 2024-05-09 13:03, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb:
>> Am 09.05.24 um 09:31 schrieb Thomas Koenig:
>>>
>> Die CDC 33000 hatte ein character nur 6 Bit.
>
> Wie viele andere auch. Erst das System/360 hat das 8-bit-Byte
> und Byte-Adressen eingeführt. Heute schwer vorstellbar, was
> das für eine Revolution war.
ASCII war ursprünglich als kombinierter 6Bit/7Bit-Standard geplant. Den
6_bit-Teil hat man aber offenbar sehr schnell fallen gelassen und sich
auf 7 Bit konzentriert.
EBCDIC war von Anfang an 8 Bit (mit einer sehr seltsamen Kodierung, die
man nur versteht, wenn man Lochkarten aus dieser Zeit sieht).
>>> Damit hatte C vom Sprachumpfang keinen Vorteil mehr gegenüber
>>> Fortran, es sei denn, man braucht unsigned ints (eine ärgerliche
>>> Lücke).
>>
>> Fortran 90 war praktisch eine andere Sprache,
>
> Mit dem großen Unterschied, dass alte Programme noch laufen.
> Und das ist auch heute noch ein Riesenvorteil gegenüber den
> Sprachen, die alle Jahre wieder Kompatibilität über den
> Haufen werfen. Ich sage nur Umstieg von Python 2 auf
> Python 3...
Das war tatsächlich ein Problem (und ist es für manche Leute immer
noch), aber es wäre falsch zu sagen, dass das "alle Jahre wieder"
passiert. Python gibt es seit 33 Jahren (30, wenn man die 0.x-Versionen
ignoriert). In dieser Zeit gab es nur diesen einen inkompatiblen
Versionssprung. Und zumindest, solange die Leute, die das miterlebt
haben, noch etwas zu sagen haben, wird es kein inkompatibles Python 4
geben.
Ein größeres Problem sehe ich in den diversen Frameworks (auch in
Python, aber noch viel mehr in JavaScript), die alle paar Monate eine
neue Version rausschießen, die irgendwie subtil inkompatibel zur alten
Version ist.
>> Der Vorteil von FORTRAN gegenüber C war die Längenangabe
>> bei elementaren Datentypen.
>> Also INT*1, INT*2, INT*4 statt char, short, long,
>> bei der die Länge in C oft nicht bekannt war
int8_t, int16_t, int32_t, int64_t, wenn man es exakt haben will.
Oder int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t, wenn man
einen Typ haben will, der mindestens so viele Bits hat und möglichst
schnell ist.
Oder int_least8_t, int_least16_t, int_least32_t, int_fast128_t wenn man
den kleinsten Typ haben will, der mindestens so viele Bits hat.
(Gibt es seit 1999)
Ich hätte es toll gefunden, wenn man da ein beliebiges N angeben könnte,
also z.B. uint_least17_t, wenn man einen Typ braucht, der 0..99999
darstellen kann (da gefällt mit die Range-Notation in Pascal sehr gut),
aber leider sind nur die 2er-Potenzen standardisiert.
hp
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-09 17:36 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <la48rfFhfuaU1@mid.individual.net> |
| In reply to | #44634 |
Am 09.05.24 um 16:57 schrieb Peter J. Holzer: > ASCII war ursprünglich als kombinierter 6Bit/7Bit-Standard geplant. Den > 6_bit-Teil hat man aber offenbar sehr schnell fallen gelassen und sich > auf 7 Bit konzentriert. Irgendwann war hardware nicht mehr so teuer. Nach 7 Bit kam 8 bit ISO, welche Chaos verursachte. > EBCDIC war von Anfang an 8 Bit (mit einer sehr seltsamen Kodierung, die > man nur versteht, wenn man Lochkarten aus dieser Zeit sieht). Das is_klein_Buchstabe x>='a' && x <='z' passt zu ASCII, nicht aber zu EBCDIC. Was die bei utf gemacht gaben, weiß ich nicht. > Ein größeres Problem sehe ich in den diversen Frameworks (auch in > Python, aber noch viel mehr in JavaScript), die alle paar Monate eine > neue Version rausschießen, die irgendwie subtil inkompatibel zur alten > Version ist. Bei Python habe ich das cgi Problem noch nicht gelöst. Ab 3.11 ist die bequeme Schnittstelle gekündigt. Und die Verbindung json <form> fehlt mir noch. >>> Der Vorteil von FORTRAN gegenüber C war die Längenangabe >>> bei elementaren Datentypen. >>> Also INT*1, INT*2, INT*4 statt char, short, long, >>> bei der die Länge in C oft nicht bekannt war > > int8_t, int16_t, int32_t, int64_t, wenn man es exakt haben will. +u* Insbesonder mag ich auch den (u)intptr_t. raspberry pi ist noch 32 bit. > Ich hätte es toll gefunden, wenn man da ein beliebiges N angeben könnte, > also z.B. uint_least17_t, wenn man einen Typ braucht, der 0..99999 > darstellen kann (da gefällt mit die Range-Notation in Pascal sehr gut), > aber leider sind nur die 2er-Potenzen standardisiert. Da wäre mir eine Schreibweise mit :len wie bei Bitfelder lieber. Und dann hätte ich gerne noch offset zur genauen Positionierung. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-09 18:52 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <la4d9jFi4aiU1@mid.individual.net> |
| In reply to | #44635 |
Am 09.05.24 um 17:48 schrieb Stefan Ram: > Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte: >> Das is_klein_Buchstabe x>='a' && x <='z' >> passt zu ASCII, nicht aber zu EBCDIC. >> Was die bei utf gemacht gaben, weiß ich nicht. > > Bei Unicode muß man zwischen der Oktettdarstellung und den > Codepunkten unterscheiden. Bei den lateinischen kleinen Buchstaben > sollte sich UTF-8 aber in beiden Fällen wie ASCII verhalten. Im gesamten 7 Bit ASCII Bereich ja.. <http://www.hermann-riemann.de/utf/0.html> > Die anderen UTF-Darstellungen werden heute seltener verwendet. > >> Bei Python habe ich das cgi Problem noch nicht gelöst. > > Falls Du das cgi-Modul für Deine Python-Version vermissen > solltest: Hast Du schon einmal versucht, es mit pip oder > von PyPI zu installieren? Ich mag nicht auf jedem computer dauernd neu installieren. Den cgi Teil, der bei einer url hinter & auftritt, z.B. <a href="http//pc_name&x=7"> ist in der Umgebung environ() sichtbar. >> Ab 3.11 ist die bequeme Schnittstelle gekündigt. >> Und die Verbindung json <form> fehlt mir noch. > > Ich weiß zwar, was JSON ist, aber "json <form>" sagt mir jetzt > nichts. <form method=post action="ergebnis.py"> ist ein html tag der den Inhalt der Eingabe wie <input> an eine Datei, hier ergebnis.py weitergibt. Bisher konnte ich mit den gekündigten import cgitb die Eingaben verarbeiten und neue html Seiten ausgeben. Gelesen habe ich, das die Eingabe irgendwie im JSON Format stattfinden soll. Mit diesem Bruchstück komme ich nicht weiter. Ich vermute, die Ausgabe von post geht über stdout, so dass mein ergebnis.py das über stdin lesen kann. Wobei mir dann das Ende fehlen würde. ... >> Da wäre mir eine Schreibweise mit :len wie bei Bitfelder lieber. >> Und dann hätte ich gerne noch offset zur genauen Positionierung. > > C ist als maschinennahe Sprache konzipiert. Und Maschinen > handhaben eben erst einmal Zweierpotenzen zwischen 8 und 128 Bit, > aber haben normalerweise keine Register mit beliebiger Breite. Bei Grafik gibt es neben rgb a 8 bit auch rgb a 10 Bit. Und bei opcode gibt es im condition code Register bits wie carry. > Wenn man das ignoriert, besteht das Risiko, daß die Programme > dann manchmal weniger effizient laufen. Falls man lieber eine > höhere Sprache wünscht, kann man ja Python verwenden. Python und Bitfelder sind abenteuerlich, da deren integer interne beliebige Länge hat. Vorzeichen mit shift .. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-10 03:49 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <la5copFml79U1@mid.individual.net> |
| In reply to | #44646 |
Am 09.05.24 um 19:28 schrieb Stefan Ram: > Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte: >>>> Bei Python habe ich das cgi Problem noch nicht gelöst. >>> Falls Du das cgi-Modul für Deine Python-Version vermissen >>> solltest: Hast Du schon einmal versucht, es mit pip oder >>> von PyPI zu installieren? >> Ich mag nicht auf jedem computer dauernd neu installieren. > > Das kann ich verstehen. > >> Gelesen habe ich, das die Eingabe irgendwie >> im JSON Format stattfinden soll. >> Mit diesem Bruchstück komme ich nicht weiter. > > Ich glaube nicht, daß HTML hier grundsätzlich JSON voraussetzt. Ich suche Ersatz für cgitb. Aus diversen Gründen vermeide ich Datenbanken. Und Musterbeispiel, die ich finde, beziehen sich meist auf Datenbanken. > Es wird sicher auch nicht erwartet, daß Endbenutzer bei > HTML JSON eingeben, obwohl es grundsätzlich möglich ist, > JSON in HTML-Formulare einzugeben. > > Eine Alternative wäre natürlich die Verwendung von tkinter > als Benutzeroberfläche; aber ich sehe, daß Du Dich schon > ziemlich in HTML als Benutzeroberfläche eingearbeitet hast, > und bei tkinter wieder von vorne beginnen müßtest. Neben tkinter gibt es noch pygame ( SDL2) und pyqt. Das layout mit html und css und deren Möglichkeiten kommt mir handlicher vor als die Vorgaben von tkinter .. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-09 19:22 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <slrnv3q1if.1n32a.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44635 |
On 2024-05-09 15:48, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>>Das is_klein_Buchstabe x>='a' && x <='z'
>>passt zu ASCII, nicht aber zu EBCDIC.
>>Was die bei utf gemacht gaben, weiß ich nicht.
>
> Bei Unicode muß man zwischen der Oktettdarstellung und den
> Codepunkten unterscheiden. Bei den lateinischen kleinen Buchstaben
> sollte sich UTF-8 aber in beiden Fällen wie ASCII verhalten.
> Die anderen UTF-Darstellungen werden heute seltener verwendet.
Unabhängig davon funktioniert is_klein_Buchstabe x>='a' && x <='z'
nicht, weil es Kleinbuchstaben außerhalb des ASCII-Bereichs gibt. Das
war ja auch schon bei den diversen 8-Bit-Zeichensätzen so (z.B. IBM 437
[0x81..0x8D, 0x91, 0x93..0x98, 0xA0..0xA4, und wohl auch 0xE0, 0xE1,
0xE3, 0xE5..0xE7, 0xEB..0xEE - wem ist diese Anordnung eingefallen?). In
Unicode gibt es hunderte Kleinbuchstaben, die zwar etwas logischer
angeordnet sind als in IBM 437, aber definitiv keinen zusammenhängenden
Block bilden. Das kann man effizient nur mehr über Tabellen lösen.
>>Ab 3.11 ist die bequeme Schnittstelle gekündigt.
>>Und die Verbindung json <form> fehlt mir noch.
>
> Ich weiß zwar, was JSON ist, aber "json <form>" sagt mir jetzt
> nichts.
Ich vermute, er möchte den Inhalt einer HTML-Form als JSON-Objekt an den
Server übermittelt haben. Das ist in HTML nicht vorgesehen. Wenn man das
wirklich braucht, muss man zu JavaScript greifen. Oder man kann
natürlich den Inhalt eines application/x-www-form-urlencoded oder
multipart/form-data Requests serverseitig in JSON umwandeln, aber wozu
sollte man das tun?
hp
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-10 04:07 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <la5drbFmpi7U1@mid.individual.net> |
| In reply to | #44648 |
Am 09.05.24 um 19:22 schrieb Peter J. Holzer: > On 2024-05-09 15:48, Stefan Ram <ram@zedat.fu-berlin.de> wrote: >> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte: >>> Das is_klein_Buchstabe x>='a' && x <='z' >>> passt zu ASCII, nicht aber zu EBCDIC. >>> Was die bei utf gemacht gaben, weiß ich nicht. >> >> Bei Unicode muß man zwischen der Oktettdarstellung und den >> Codepunkten unterscheiden. Bei den lateinischen kleinen Buchstaben >> sollte sich UTF-8 aber in beiden Fällen wie ASCII verhalten. >> Die anderen UTF-Darstellungen werden heute seltener verwendet. > > Unabhängig davon funktioniert is_klein_Buchstabe x>='a' && x <='z' > nicht, weil es Kleinbuchstaben außerhalb des ASCII-Bereichs gibt. Im ASCII Bereich funktioniert das. Bei ISO und EBCDIC nicht. Bei EBCDIC sind die klein Buchstaben in Bereich verteilt, bei ISO sind ä .. irgendwie oberhalb 0x080 verteilt. Bei utf gibt es zusätzlich viele Bereiche z.B. für α bis ω Letztere kann man wie bei a-z durch Umkehrung eines bits Klein in Großbuchstaben jeweils umwandeln. Geht auch bei ä ö ü. aber nicht bei ß. >>> Ab 3.11 ist die bequeme Schnittstelle gekündigt. >>> Und die Verbindung json <form> fehlt mir noch. >> >> Ich weiß zwar, was JSON ist, aber "json <form>" sagt mir jetzt >> nichts. > > Ich vermute, er möchte den Inhalt einer HTML-Form als JSON-Objekt an den > Server übermittelt haben. Das ist in HTML nicht vorgesehen. Wenn man das > wirklich braucht, muss man zu JavaScript greifen. Das was ich will, ist die cgi Informationen vom <form> Bereich an ein Python Programmm übermitteln. Das geht bisher in Python mit cgitb ohne JavaScript. cgitb soll ab Python3 Version 13 nicht mehr dabei sein. > Oder man kann > natürlich den Inhalt eines application/x-www-form-urlencoded oder > multipart/form-data Requests serverseitig in JSON umwandeln, aber wozu > sollte man das tun? Ich habe die Vermutung, obiges könnte irgendwie mit json gehen. Zumal es Ajax Beispiel gibt. Mit denen ich aber nichts anfangen kann. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-09 17:00 +0000 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <v1iver$ov2b$2@dont-email.me> |
| In reply to | #44634 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > On 2024-05-09 13:03, Thomas Koenig <tkoenig@netcologne.de> wrote: [Fortran] >> Mit dem großen Unterschied, dass alte Programme noch laufen. >> Und das ist auch heute noch ein Riesenvorteil gegenüber den >> Sprachen, die alle Jahre wieder Kompatibilität über den >> Haufen werfen. Ich sage nur Umstieg von Python 2 auf >> Python 3... > > Das war tatsächlich ein Problem (und ist es für manche Leute immer > noch), aber es wäre falsch zu sagen, dass das "alle Jahre wieder" > passiert. Auf mich hat https://web.archive.org/web/20180123041857/https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/ einen nachhaltigen Eindruck hinterlassen. Wenn wissenschaftliche Veröffentlichungen aufgrund von Software-Änderungen nicht mehr reproduzierbar sind, dann ist was falsch. > Python gibt es seit 33 Jahren (30, wenn man die 0.x-Versionen > ignoriert). In dieser Zeit gab es nur diesen einen inkompatiblen > Versionssprung. Und zumindest, solange die Leute, die das miterlebt > haben, noch etwas zu sagen haben, wird es kein inkompatibles Python 4 > geben. > > Ein größeres Problem sehe ich in den diversen Frameworks (auch in > Python, aber noch viel mehr in JavaScript), die alle paar Monate eine > neue Version rausschießen, die irgendwie subtil inkompatibel zur alten > Version ist. ... was natürlich auch eine Rolle spielt, ich habe jetzt mit Python etwas verkürzend das ganze Ökosystem dazu gemeint. [...] > Ich hätte es toll gefunden, wenn man da ein beliebiges N angeben könnte, > also z.B. uint_least17_t, wenn man einen Typ braucht, der 0..99999 > darstellen kann (da gefällt mit die Range-Notation in Pascal sehr gut), > aber leider sind nur die 2er-Potenzen standardisiert. Genau das kann Fortran: integer,parameter :: ik = selected_int_kind(5) integer (kind=ik) :: a, b, c ... a = 42_ik + b liefert dir eben jenes.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-09 20:25 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <slrnv3q58h.1n32a.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44647 |
On 2024-05-09 17:00, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>> On 2024-05-09 13:03, Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> [Fortran]
>
>>> Mit dem großen Unterschied, dass alte Programme noch laufen.
>>> Und das ist auch heute noch ein Riesenvorteil gegenüber den
>>> Sprachen, die alle Jahre wieder Kompatibilität über den
>>> Haufen werfen. Ich sage nur Umstieg von Python 2 auf
>>> Python 3...
>>
>> Das war tatsächlich ein Problem (und ist es für manche Leute immer
>> noch), aber es wäre falsch zu sagen, dass das "alle Jahre wieder"
>> passiert.
>
> Auf mich hat
>
> https://web.archive.org/web/20180123041857/https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
>
> einen nachhaltigen Eindruck hinterlassen. Wenn wissenschaftliche
> Veröffentlichungen aufgrund von Software-Änderungen nicht mehr
> reproduzierbar sind, dann ist was falsch.
Naja, streng genommen stimmt es ja nicht: Die alten Versionen Python,
Numpy, etc. sind ja nicht weg. Die kann man nach wie vor herunterladen
und verwenden. Sie werden nur nicht mehr gewartet, was aber für die
Reproduzierbarkeit egal ist.
(Ja, unter Umständen wird es auf modernen Systemen irgendwann
schwierig, die noch zum Laufen zu bringen - vermutlich sollte man ein
Image von CentOS 7 oder Ubuntu 20 archivieren, solange man kann.)
Wird aber bei andere Software ähnlich sein. Ich höre von unseren
Wissenschaftlern auch gelegentlich, dass sie irgendein Modell
umschreiben müssen, weil das mit der aktuellen Version der
Simulationssoftware nicht mehr funktioniert.
(Die genauen Versionen aller verwendeten Pakete zu dokumentieren ist
allerdings etwas, das sich auch erst auf die harte Tour lernen musste.)
>> Python gibt es seit 33 Jahren (30, wenn man die 0.x-Versionen
>> ignoriert). In dieser Zeit gab es nur diesen einen inkompatiblen
>> Versionssprung. Und zumindest, solange die Leute, die das miterlebt
>> haben, noch etwas zu sagen haben, wird es kein inkompatibles Python 4
>> geben.
>>
>> Ein größeres Problem sehe ich in den diversen Frameworks (auch in
>> Python, aber noch viel mehr in JavaScript), die alle paar Monate eine
>> neue Version rausschießen, die irgendwie subtil inkompatibel zur alten
>> Version ist.
>
> ... was natürlich auch eine Rolle spielt, ich habe jetzt mit
> Python etwas verkürzend das ganze Ökosystem dazu gemeint.
Das ganze Ökosystem ist halt PyPI, und das steht nicht unter zentraler
Kontrolle. Wenn ich da eine inkompatible Änderung in einem meiner
Packages mache, dann kann mich niemand daran hindern (es wird auch
niemand kümmern, fürchte ich ;-)). Wenn die Entwickler von NumPy
inkompatible Änderungen machen, ist das im Prinzip das gleiche. Das
betrifft mehr User, aber das Python-Core-Team hat darauf keinen
Einfluss. Das müssen sich die Entwickler und User von NumPy miteinander
ausmachen.
Ein riesiges, dezentrales Ökosystem mit einer eher kleinen Sprache wie
Fortran zu vergleichen, ist einfach unpassend. Selbst die
Python-Standard-Library hat vermutlich mehr "batteries included". (Und
ich muss meine Aussage von vorher relativieren: Das Entfernen von "dead
batteries", das vor kurzem stattgefunden hat (darunter das cgi-Package,
dem Hermann offenbar nachweint) ist auch ein breaking Change. Sollte
aber im Normalfall nur zu minimalen Änderungen zwingen.)
hp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-09 20:55 +0000 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <v1jd8q$se14$1@dont-email.me> |
| In reply to | #44652 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > On 2024-05-09 17:00, Thomas Koenig <tkoenig@netcologne.de> wrote: >> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: >>> On 2024-05-09 13:03, Thomas Koenig <tkoenig@netcologne.de> wrote: >> >> [Fortran] >> >>>> Mit dem großen Unterschied, dass alte Programme noch laufen. >>>> Und das ist auch heute noch ein Riesenvorteil gegenüber den >>>> Sprachen, die alle Jahre wieder Kompatibilität über den >>>> Haufen werfen. Ich sage nur Umstieg von Python 2 auf >>>> Python 3... >>> >>> Das war tatsächlich ein Problem (und ist es für manche Leute immer >>> noch), aber es wäre falsch zu sagen, dass das "alle Jahre wieder" >>> passiert. >> >> Auf mich hat >> >> https://web.archive.org/web/20180123041857/https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/ >> >> einen nachhaltigen Eindruck hinterlassen. Wenn wissenschaftliche >> Veröffentlichungen aufgrund von Software-Änderungen nicht mehr >> reproduzierbar sind, dann ist was falsch. > > Naja, streng genommen stimmt es ja nicht: Die alten Versionen Python, > Numpy, etc. sind ja nicht weg. Die kann man nach wie vor herunterladen > und verwenden. Sie werden nur nicht mehr gewartet, was aber für die > Reproduzierbarkeit egal ist. Jep, und dann hat man für jedes Projekt eine eigene Version, und wenn man was vom einen zum anderen portieren will, gibt es wieder Schwierigkeiten... Ist im Artikel, der am Ende verlinkt ist, adressiert: - Für Code, der weiterenwickelt wird, ist das keine Lösung - Neue Layer von Infrastruktur: Wie lange läuft der Docker-Container von 2017 auf den neuen Systemen...? - Einfrieren ist, speziell für Wissenschaftler, nicht einfach. > (Ja, unter Umständen wird es auf modernen Systemen irgendwann > schwierig, die noch zum Laufen zu bringen - vermutlich sollte man ein > Image von CentOS 7 oder Ubuntu 20 archivieren, solange man kann.) Und das ganze macht Arbeit und erfordert Fachkenntnisse, die vielleicht ein Doktorand hat, aber wenn der das Institut verlässt... > Wird aber bei andere Software ähnlich sein. Ich höre von unseren > Wissenschaftlern auch gelegentlich, dass sie irgendein Modell > umschreiben müssen, weil das mit der aktuellen Version der > Simulationssoftware nicht mehr funktioniert. Ich habe vor einigen Jahren mal einen Fortran-Code aus den 1980ern/ frühen 1990ern auf modernen Systemen lauffähig zu bekommen. Das war schon eine ganze Menge Zeilen. Ich habe das durch gfortran gejagt, mit -fmax-errors=1 -Werrors, und habe die gemeldeten Fehler dann korrigiert - das waren vor allem ein paar VAX extensions, die gfortran nicht unterstützt, die aber schnell zu ersetzen waren. An einem Nachmittag war ich fertig. > (Die genauen Versionen aller verwendeten Pakete zu dokumentieren ist > allerdings etwas, das sich auch erst auf die harte Tour lernen musste.) Und dann stell dir mal wechselnde Generationen von Doktoranden vor...
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-09 23:53 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <slrnv3qhec.1nugg.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44656 |
On 2024-05-09 20:55, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Ich habe vor einigen Jahren mal einen Fortran-Code aus den 1980ern/
> frühen 1990ern auf modernen Systemen lauffähig zu bekommen.
>
> Das war schon eine ganze Menge Zeilen. Ich habe das durch gfortran
> gejagt, mit -fmax-errors=1 -Werrors, und habe die gemeldeten Fehler
> dann korrigiert - das waren vor allem ein paar VAX extensions,
> die gfortran nicht unterstützt, die aber schnell zu ersetzen waren.
>
> An einem Nachmittag war ich fertig.
Wenig überraschend. Ich weiß nicht, wie das Ökosystem von
Fortran-Software heute aussieht, aber in den 80er-Jahren hatten
Programmiersprachen generell sehr kleine Standard-Librarys und Librarys
von Dritten musste man erst mal haben. Von einem Programm aus dieser
Zeit würde ich also erwarten, dass es kaum mehr als den Sprachkern
verwendet und der Autor alles, was er sonst noch brauchte, selbst
geschrieben hat. Da ist nicht sehr viel da, was inkompatibel werden
könnte. Wenn jemand hingegen in seinem Code (wie das heute halt oft
üblich ist) 37 Librarys von Dritten verwendet, dann ist die
Wahrscheinlichkeit, dass mindestens eine davon nicht mehr verfügbar,
inkompatibel oder sonstwie unbrauchbar ist, groß. Natürlich erspart man
sich damit Arbeit, aber man sollte sich dann nicht beschweren, wenn
einem das auf den Kopf fällt.
Das Fortran-Programm, das ist anderswo in diesem Thread erwähnt habe,
und das bei uns 43 Jahre lang im Einsatz war, wurde übrigens nie
vollständig auf Linux portiert. Denn Oracle hat Pro*For nicht für Linux
herausgegeben, und den ganzen Embedded-SQL-Code durch einen
handgeschriebenen (und wartbaren!) Datenbanklayer zu ersetzen, war immer
zu viel Arbeit.
hp
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-10 04:26 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <la5eubFmv6kU1@mid.individual.net> |
| In reply to | #44652 |
Am 09.05.24 um 20:25 schrieb Peter J. Holzer: > Ein riesiges, dezentrales Ökosystem mit einer eher kleinen Sprache wie > Fortran zu vergleichen, ist einfach unpassend. Selbst die > Python-Standard-Library hat vermutlich mehr "batteries included". (Und > ich muss meine Aussage von vorher relativieren: Das Entfernen von "dead > batteries", das vor kurzem stattgefunden hat (darunter das cgi-Package, > dem Hermann offenbar nachweint) ist auch ein breaking Change. Sollte > aber im Normalfall nur zu minimalen Änderungen zwingen.) So Arbeit intensive Änderungen sind nicht neu. Das evalquote von lisp 1.5 habe ich vermisst und als Ersatz eine Kombination von eval und list ausprobiert. Meine > ca 20 Jahre alten C Programme werden von compiler plötzlich mit Meldungen bedacht, bis ich in einigen Funktionsdefinitionen ein "const" eingefügt habe. Erschwert Lesbarkeit, und ich sehe eigentlich keine Notwendigkeit dafür. Das keywort register in C habe ich auch nie verwendet. Die Änderungen stellen für mich größere Probleme da, wenn ich viel Zeit mit der Suche verbringe, *wie* ich das umsetzen kann. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-08 20:53 +0200 |
| Message-ID | <slrnv3nii7.1fdo8.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44544 |
On 2024-05-06 20:53, poc@pocnet.net <poc@pocnet.net> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> wrote:
>>> Fangen wir mal mit denjenigen an die laut rufen, dass Python und
>>> Rust so viel besser sei, weil man die typischen C-Fehler dort gar
>>> nicht machen könne. :-) Oder noch besser: Mit jenen die C verteufeln
>>> weil die Sprache per se ja "unsicher" wäre.
>>
>> Das verstehe ich jetzt nicht. Warum glaubst Du, dass genau diese Leute
>> in der Lage sein sollten, in C sauber und sicher zu programmieren?
>
> Habe ich das falsch verstanden? Ich meinte, dass man diesen Leuten zeigen
> kann, dass man auch in C "sicher" programmieren kann.
Deine Aussage war: "man kann in C sicher programmieren". Daraufhin habe
ich gefragt, wer denn dieser "man" sei, der in C sicher programmieren
könne. Wenn Du darauf so wie oben antwortest, kann das nur heißen, dass
deiner Meinung nach diese Leute in C sicher programmieren können.
Und in dieser Antwort haben wir jetzt schon zwei "man": Einen der
sicher programmieren kann und einen, der das zeigen kann ;-)
Also werde bitte konkret: Wer kann Deiner Meinung nach in C sicher und
sauber programmieren? Jeder? Jeder studierte Informatiker? Jeder, der
mit Dennis Ritchie ein Büro geteilt hat? Dan Bernstein?
>> Außer natürlich, du meinst mich. Ich halte mich für fähig, in C sauber
>> und sicher zu programmieren, und bin genau deshalb der Meinung, dass C
>> eine schreckliche Sprache ist, in der das unnötig schwierig ist.
>>
>> ;-)
>
> Vielleicht bin ich einfach nicht Programmierer genug, aber ich kenne das nur
> so: In aufwendig und schwierig. Aber möglich.
>
>>>>> Dazu braucht es IMHO Disziplin, Umsicht und Kenntnisse,
>>>>
>>>> ACK. Und damit wird die Menge der "man"s schon recht klein.
>>>
>>> Also haben wir im Wesentlichen ein Kompetenzproblem?
>>
>> Ja. Klar. Man kann Drahtseile über Schluchten spannen statt Brücken zu
>> bauen, und es ein Kompetenzproblem nennen, wenn die meisten Menschen
>> beim Versuch der Überquerung abstürzen.
>
> Irgendwie passt Dein Vergleich nicht, vor allem in Hinsicht des
> Ressourcenverbrauchs,
Doch genau in Hinsicht auf den Ressourcenverbrauch passt das perfekt.
Ein Seil braucht sehr viel weniger Resourcen als eine Brücke. Aber es
gibt halt sehr wenige Leute, die einen Abgrund auf einem Seil überqueren
können. Natürlich kann "man" das lernen und du kannst fordern, dass alle
das lernen sollen, um Resourcen zu sparen und den allgemeinen Mangel an
Hochseilkompetenz beklagen.
>>> Korrekt. Aber gilt das nicht auch für andere Berufszweige? Wenn ich eine
>>> Brücke bauen will, dann kümmere mich mich doch vorher um die geologischen
>>> Gegebenheiten, externe Faktoren wie Wind- und ggfs. Wasserdruck, wieviel
>>> Geicht schlechtestenfalls getragen werden muss, usw. Kurz: Ich *plane*.
>>
>> Wenn Du eine Brücke bauen willst, dann weißt Du erstens, was eine Brücke
>> ist, zweitens welche Punkte sie verbinden soll, drittens wieviel
>> Verkehr sie aunehmen soll und viertens die Umweltbedingungen.
>
> Wenn ich ein Programm schreiben soll/will, dann mach ich mir doch auch vorher
> Gedanken was es tun soll, auf welcher Plattform es laufen soll, etc.?
Gedanken machst Du Dir schon, die werden nur oft von der Realität
eingeholt. "Kein Plan überlebt den ersten Feindkontakt" heißt es beim
Militär. In der Softwareentwicklung ist es ähnlich. Ausnahmen gibt es
natürlich. Manchmal ist die Problemstellung völlig klar und ändert sich
auch nicht. Das ist aber meiner Erfahrung nach die Ausnahme, vor allem,
wenn das Programm User hat, die nicht mit dem Programmierer identisch
sind.
>> Planung ist keine Nebensächlichkeit, sondern in vielen Fällen unmöglich.
>> Wenn der Kunde unsicher ist, ob er lieber eine Brücke oder einen Tunnel
>> hätte, in Wirklichkeit aber einen Flughafen bräuchte, eine der beiden
>> Städte, die verbunden werden sollen, während der Bauzeit aufgelassen
>> wird (und dafür 10 Dörfer auf der anderen Seite entstehen) und zu Wind-
>> und Wasserdruck die Gefahr von Bombenanschlägen dazukommt, dann kannst
>> Du noch so gut planen, das Ergebnis wird enttäuschen.
>
> Klar. Ist das denn heute noch so, oder nicht doch ein vorgeschobener bequemer
> Grund? Gerade im OpenSource-Bereich gibt es ja z. B. keinen Kunden der sagt
> was er sich so in ungefähr vorstellt.
Es gibt User. Die sagen oft sehr laut, was sie wollen. Und vor allem,
was sie nicht wollen. Wenn man ein Open-Source-Programm als Hobby
entwickelt, hat man den Luxus, das ignorieren zu können. Wenn das
Open-Source-Programm Teil eines Business-Modells ist, schon weniger. Und
in jedem Fall gilt: Wenn niemand sagt, was er sich ungefähr vorstellt,
wo soll dann die Spezifikation herkommen?
>> Das "Wasserfall-Modell" (das eigentlich als abschreckendes Beispiel
>> erfunden wurde, aber in den 70er- und 80er-Jahren ernsthaft propagiert
>> wurde) ist daher zurecht wieder außer Mode gekommen.
>>
>> Stattdessen versucht man "agil" zu sein, d.h. auf die unausweichlich
>> kommenden Änderungen in den Anforderungen reagieren zu können.
>>
>> Das heißt nicht planlos vor sich hin wursteln.
>
> Den Eindruck habe ich aber als Außenstehener in sehr vielen Fällen.
Ja, aber das hat nichts mit "agil" zu tun, sondern mit Inkompetenz (auf
beiden Seiten: Beim Auftraggeber und beim Auftragnehmer).
hp
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-08 20:09 +0000 |
| Message-ID | <la24fqF7el7U1@mid.individual.net> |
| In reply to | #44606 |
Peter J. Holzer <hjp-usenet4@hjp.at> wrote: > Also werde bitte konkret: Wer kann Deiner Meinung nach in C sicher und > sauber programmieren? Jeder? Jeder studierte Informatiker? Jeder, der > mit Dennis Ritchie ein Büro geteilt hat? Dan Bernstein? Ich würde mal sagen, jeder der die Schwächen von C kennt, Disziplin hat und dem das Wort Sorgfalt nicht fremd ist. >> Irgendwie passt Dein Vergleich nicht, vor allem in Hinsicht des >> Ressourcenverbrauchs, > > Doch genau in Hinsicht auf den Ressourcenverbrauch passt das perfekt. > Ein Seil braucht sehr viel weniger Resourcen als eine Brücke. Aber es > gibt halt sehr wenige Leute, die einen Abgrund auf einem Seil überqueren > können. Natürlich kann "man" das lernen und du kannst fordern, dass alle > das lernen sollen, um Resourcen zu sparen und den allgemeinen Mangel an > Hochseilkompetenz beklagen. Äh, nein das passt nicht, weil diejenigen, die unter meiner "Forderung" zu leiden hätten die Programmierer sind und nicht die Anwender (die über die Brücke zu gehen haben). Zumindest wenn ich den Verlgeich richtig verstehe. >> Klar. Ist das denn heute noch so, oder nicht doch ein vorgeschobener bequemer >> Grund? Gerade im OpenSource-Bereich gibt es ja z. B. keinen Kunden der sagt >> was er sich so in ungefähr vorstellt. > > Es gibt User. Die sagen oft sehr laut, was sie wollen. Und vor allem, was > sie nicht wollen. Wenn man ein Open-Source-Programm als Hobby entwickelt, > hat man den Luxus, das ignorieren zu können. Ja, weil man das im Regelfall für sich selbst tut. > Und in jedem Fall gilt: Wenn niemand sagt, was er sich ungefähr vorstellt, > wo soll dann die Spezifikation herkommen? Wenn niemand sagt was er will, warum überhaupt anfangen? :-) -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-06 12:50 +0200 |
| Message-ID | <l9rqv5F91ndU1@mid.individual.net> |
| In reply to | #44510 |
Stefan Ram, 2024-05-05 20:51: [...] > Man kann solche inkrementellen Änderungen aber durchaus so > organisieren, daß man dabei von einer korrekten Programmversion > zur nächsten korrekten Programmversion kommt. > > Um mal ein Beispiel zu geben: Ich soll ein Programm schreiben, das > die Wörter "Haus", "Hof", und "Garten" ins Englisch übersetzen kann. > > Anstatt gleich alles zu planen, plane ich erstmal ein Programm, > das nur "Haus" übersetzen kann. Ergebnis: > > entry = input() > if entry == 'Haus': print( 'house' ) Wobei man hier mit Yoda expressions arbeiten sollte, um irrtümliche Zuweisungen statt Vergleichen bei Tippfehlern zu vermeiden: if 'Haus' == entry: print( 'house' ) > . Jetzt zeige ich das meinem Kunden, und frage ihn, ob das für > diese Wort so ist, wie er es sich vorgestellt hat. Nachdem das > dann geklärt wurde, nehme ich mir als nächstes "Hof" vor. Oder man fängt spätestens dann an, gleich ein Array mit Wörtern und deren Übersetzung aufzubauen, weil man sieht, dass laute einzelne Abfragen umständlich sind und die Liste der Wörter möglicherweise später auch leicht erweiterbar sein sollte. Im in noch einem weiteren Schritt lagert man das vielleicht aus in eine Datei, die beim Programmstart oder zu Compile-Zeit geladen wird. > Das ganze Handwerk des Refaktoring basiert auch darauf, Programme > /inkrementell/ zu verbessern. ACK. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-06 19:39 +0200 |
| Subject | Yoda expressions (was: Triumph of the Nerds) |
| Message-ID | <slrnv3i5ev.1b1lf.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44522 |
On 2024-05-06 10:50, Arno Welzel <usenet@arnowelzel.de> wrote:
> Stefan Ram, 2024-05-05 20:51:
>> entry = input()
>> if entry == 'Haus': print( 'house' )
>
> Wobei man hier mit Yoda expressions arbeiten sollte, um irrtümliche
> Zuweisungen statt Vergleichen bei Tippfehlern zu vermeiden:
Nein, sollte man nicht. Aus zwei Gründen:
1) hat Stefan hier Python geschrieben und in Python ist
if entry = 'Haus':
schlicht ein Syntaxfehler
2) widerspricht das der natürlichen Satzstellung. Das könnte man
hinnehmen, wenn es eine allgemeine Lösung des Problems wäre.
Da man aber weiterhin if (a = b) { ... } schreiben kann, wiegt der
Vorteil der Fehlervermeidung den Nachteil der schlechteren Lesbarkeit
nicht auf.
3) (nobody expects the Spanish Inquisition) ist es in Sprachen wie C
unnötig, weil die Compiler seit Ewigkeiten warnen, wenn man = in
einem Kontext verwendet, wo == gemeint sein könnte.
hp
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-06 14:16 +0200 |
| Message-ID | <l9s018F9pvfU1@mid.individual.net> |
| In reply to | #44510 |
Am 05.05.24 um 20:51 schrieb Stefan Ram:
> Um mal ein Beispiel zu geben: Ich soll ein Programm schreiben, das
> die Wörter "Haus", "Hof", und "Garten" ins Englisch übersetzen kann.
>
> Anstatt gleich alles zu planen, plane ich erstmal ein Programm,
> das nur "Haus" übersetzen kann. Ergebnis:
>
> entry = input()
> if entry == 'Haus': print( 'house' )
Ich würde so anfangen.
#!/usr/bin/python3
import os, sys, string
tab="""
Haus house
Hof court
Garten garden
""".split('\n')
trans={}
for x in tab:
l=x.split()
if len(l)==2: trans[l[0]]=l[1]
print(trans)
Bei längerer Tabelle würde ich tab in mind. eine Datei auslagern.
Bei Mehrdeutigkeit wäre es z.B.
if len(l)>=2: trans[l[0]]=set(l[1:])
Das könnte ich weiter ausbauen,
um Zusammenhänge, Gewichte einzubauen ..
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-05-06 19:04 +0200 |
| Message-ID | <v1b9j6.1vs.1@stefan.msgid.phost.de> |
| In reply to | #44510 |
Am 05.05.2024 um 20:30 schrieb poc@pocnet.net: > Peter J. Holzer <hjp-usenet4@hjp.at> wrote: >> Und auch Leute mit Disziplin, Umsicht und Kenntnissen sind nicht davor >> gefeit, dumme Fehler zu machen, insbesondere dann nicht, wenn sie unter >> Zeitdruck arbeiten. > > Korrekt. Aber gilt das nicht auch für andere Berufszweige? Wenn ich eine > Brücke bauen will, dann kümmere mich mich doch vorher um die geologischen > Gegebenheiten, externe Faktoren wie Wind- und ggfs. Wasserdruck, wieviel > Geicht schlechtestenfalls getragen werden muss, usw. Kurz: Ich *plane*. > > Bei dem was ich heutzutage so in c't und iX mitbekomme, scheint Programmieren > derzeit eher ein "wir fangen mal an und steuern die Richtung während das > Projekt Form annimmt". Planung scheint mir zu einer lästige Nebensächlichkeit > georden zu sein, da sie ja nicht direkt was mit Programmieren zu tun hat. > Oder täuscht mich da mein Eindruck? Die Erwartungshaltung ist halt, bis zuletzt noch Änderungen vornehmen zu können. "Ist ja nur Software". Und wenn dann dein Gerät nicht mit dem neuesten Apple-Spielzeug spielt, was leider nach dem Anforderungs-Einsendeschluss auf den Markt kam, ist halt doof. Dazu kommen noch Dinge wie "Entwickler weiß, dass Kunde ständig mit Änderungswünschen um die Ecke kommen wird und preist das ein" vs. "Kunde weiß, dass Entwickler so plant, und schickt deswegen die Änderungswünsche erst recht". Die Kunst ist, die technischen Auswirkungen von sowas zu kontrollieren. >>> und man könnte sich den Bloat durch "wir nehmen dem Programmierer einmalig >>> beim Programmieren das Denken ab und führen den zusätzlichen Bloat dann >>> beim Kunden tausendfach aus" deutlich reduzieren. >>> >>> Das fühlt sich für mich einfach falsch an. >> >> Bist Du bereit für den zusätzlichen Aufwand zu bezahlen? > > Kommt drauf an. Und, nicht jede Software die entwickelt wird, hat ein > monetäres Ziel. Stichwort OpenSource. Gerade bei Open Source ist das übergeordnete Ziel aber: löst das Problem, das ich gerade habe. Der Bildverarbeitungsalgorithmus ist halt gut genug, wenn er das Urlaubsvideo des Entwicklers verarbeiten kann und der Entwickler nicht zu sehr dafür schämen muss. Und wenn dafür NumPy anstelle eines mundgeblasenen C- oder Shader-Kerns reicht, prima. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-05 16:28 +0200 |
| Message-ID | <l9pjciFsmkrU10@mid.individual.net> |
| In reply to | #44495 |
poc@pocnet.net, 2024-05-05 13:22: > Stefan Reuther <stefan.news@arcor.de> wrote: [...] >>> Viele der einst als "langsam" und "ineffizent" betrachtete Sprachen >>> arbeiten mittlerweile mit Compilern, und wenn es auch nur >>> Just-in-time-Compiler sind. Das holt *sehr* viel raus. Node.js oder Kotlin >>> sind durchaus ernstzunehmende Umgebungen. >> >> Auch wenn ich dem letzten Satz zustimme, ist das aber kein Gewinn bezüglich >> Sicherheit oder Komplexität. > > Aus Komplexitätssicht definitiv nicht, und aus Sicht von Bloat ist Node von > dem bisschen was ich mitbekommen habe eine mittlere Katastrophe. Ja, weil vermutlich nicht wenige Leute, die mit Node arbeiten, schlicht keine große Erfahrung mit Softwareentwicklung haben. > Ein Beispiel: Webentwickler hat in Node ein Programm geschrieben, was per ODBC > auf einen MSSQL-Server zugreift, den Kundenstamm ausliest und per ODBC in eine > DB2-Datenbank schiebt. Mit vorherigem Löschen der Tabelleninhalte auf > DB2-Seite. Das Node-Script lief ca. 10 Minuten und brauchte etliche 100MB an > RAM. Wobei hier ODBC auch einen nicht unerheblichen Anteil daran hat. > Im Laufe der folgenden Monate wuchs der Kundenstamm dann auf knapp 1000 an. > Irgendwann lief das Script in ein Timeout. Der Programmierer sagte, der > SQL-Server wäre zu langsam, er könne nichts machen. Ja - typische Aussage von jemandem, der keine Ahnung hat. > Ich habe mich einen Nachmittag hingesetzt und das in Perl neu geschrieben. > Braucht inklusive der notwendigen Module lediglich einige 100KB auf der > Platte und ist in deutlich weniger als 10 Sekunden durch. Und braucht nur > wenige MB an RAM. Mache ich notfalls auch in Node - aber halt nicht mit ODBC ;-) Native Treiber für MS-SQL udn DB2 gibt es auch für Node: <https://learn.microsoft.com/de-de/sql/connect/node-js/node-js-driver-for-sql-server?view=sql-server-ver16> <https://www.ibm.com/docs/en/db2/11.5?topic=applications-nodejs> > Sicherlich ist hier auch eine gewisse Inkompetenz des Programmierers > ursächlich, aber unterm Strich zeigt dies für mich eine Tendenz, die ich auch > schon aus anderen Quellen mitbekommen habe: Effizienz sieht anders aus. Ja, dafür kann aber die Sprache nichts, wenn unfähige Programmierer sowas bauen. Mag sein, dass Sprachen wie JavaScript solceh Leute eher anziehen, weil es massenweise Online-Tutorials und Beispielcode gibt, der dann kritiklos einfach per Copy&Paste übernommen wird. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-05 18:33 +0000 |
| Message-ID | <l9q1mvFj2mU2@mid.individual.net> |
| In reply to | #44499 |
Arno Welzel <usenet@arnowelzel.de> wrote: >> Aus Komplexitätssicht definitiv nicht, und aus Sicht von Bloat ist Node von >> dem bisschen was ich mitbekommen habe eine mittlere Katastrophe. > > Ja, weil vermutlich nicht wenige Leute, die mit Node arbeiten, schlicht > keine große Erfahrung mit Softwareentwicklung haben. Also auch wiederum ein Kompetenzproblem. >> Ein Beispiel: Webentwickler hat in Node ein Programm geschrieben, was per >> ODBC auf einen MSSQL-Server zugreift, den Kundenstamm ausliest und per ODBC >> in eine DB2-Datenbank schiebt. Mit vorherigem Löschen der Tabelleninhalte >> auf DB2-Seite. Das Node-Script lief ca. 10 Minuten und brauchte etliche >> 100MB an RAM. > > Wobei hier ODBC auch einen nicht unerheblichen Anteil daran hat. Kann ich nicht nachvollziehen. Auch meine Perl-Lösung benutzt ODBC, die gleichen Definitionen wie zuvor für Node. >> Im Laufe der folgenden Monate wuchs der Kundenstamm dann auf knapp 1000 an. >> Irgendwann lief das Script in ein Timeout. Der Programmierer sagte, der >> SQL-Server wäre zu langsam, er könne nichts machen. > > Ja - typische Aussage von jemandem, der keine Ahnung hat. Mh, okay. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-06 13:09 +0200 |
| Message-ID | <l9rs45F91ndU3@mid.individual.net> |
| In reply to | #44511 |
poc@pocnet.net, 2024-05-05 20:33: > Arno Welzel <usenet@arnowelzel.de> wrote: [...] >> Wobei hier ODBC auch einen nicht unerheblichen Anteil daran hat. > > Kann ich nicht nachvollziehen. Auch meine Perl-Lösung benutzt ODBC, die > gleichen Definitionen wie zuvor für Node. Mag sein, dass die ODBC-Integration von Node nicht gut ist. Ich versuche ODBC in der Praxis aber generell zu vermeiden, wann immer es möglich ist. Es bildet halt generell nochmal eine Zwischenschicht, die je nach Datenbank das SQL-Statement nochmal selber bearbeitet, bevor es in der Datenbank landet. Das letzte Mal, dass ich ODBC noch regelmäßiger genutzt habe, war irgendwann Mitte bis Ende der 1990er Jahre, als es für Umgebungen wie Windows mit MFC kaum andere Optionen gab, um mit einem Oracle-Server zu sprechen - jedenfalls keine, die nicht erhblich viel mehr Aufwand gemacht hätte. Heute ist ODBC aber vielfach schlicht nicht mehr notwendig, weil die Client-Bibliotheken für Datenbanken in etlichen Programmiersprachen mit geringem Aufwand nutzbar sind. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web