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 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-08 12:01 +0200 |
| Message-ID | <la10rlF29p9U3@mid.individual.net> |
| In reply to | #44578 |
Stefan Reuther, 2024-05-07 18:03: > Am 07.05.2024 um 09:20 schrieb Arno Welzel: >> Stefan Reuther, 2024-05-06 18:41: >>> Am 05.05.2024 um 16:18 schrieb Arno Welzel: >>>> Rust ist schon ein guter Kandidat, wenn es um Sicherheit geht. >>> >>> Braucht halt immer noch 'unsafe', um interessante Dinge wie eine >>> Speicherverwaltung zu implementieren. Es ist natürlich zweifelsohne >>> ein Fortschritt, die potenziell unsicheren Teile zu markieren. >> >> Definiere "Speicherverwaltung implementieren". >> >> Was spricht gegen Konstrukte wie sowas: >> >> let mut buffer = vec![0_u8; 100000]; > > Wenn du dann eine Funktion 'malloc' schreibst, die einen Index rausgibt, Wozu sollte ich das? Die Frage war, ob das obige Konstrukt nicht besser ist. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-05-13 01:54 +0200 |
| Message-ID | <rf18hk-m5d.ln1@news.martinen.de> |
| In reply to | #44538 |
Am 06.05.24 um 18:41 schrieb Stefan Reuther: > Am 05.05.2024 um 16:18 schrieb Arno Welzel: >> Stefan Reuther, 2024-05-05 10:16: >>>>> Auf irgendeiner Ebene in dem Stapel braucht es eine Sprache wie C. Zum >> [Rust] > Braucht halt immer noch 'unsafe', um interessante Dinge wie eine > Speicherverwaltung zu implementieren. Es ist natürlich zweifelsohne ein > Fortschritt, die potenziell unsicheren Teile zu markieren. > Pascal ist nicht besser als C. Da kann man genauso mit Casts und Zeigern > rumferkeln. >> Ja, sowas meine ich aber nicht, sondern die Vermeidung von Pointern ohne >> Information darüber, wie groß der Adressbereich ist, der über den >> Pointer angesprochen werden darf und eine zuverlässige Verhinderung von >> Buffer Overflow. Das alleine verhindert sich eine sehr große Zahl >> Sicherheitsproblemen. > Aber das ist nur eins von vielen Problemen. Das Problem "use-after-free" > löst auch ein Pointer mit Größeninformation nicht. Ich will jetzt nicht behaupten ich wüsste was Pointer genau machen, aber es sind wohl Zeiger in einen Adressraum. Und das Problem besteht bei einem Multitasking-system wohl darin das dies auch ein Fremder Prozess sein könnte oder? Und speicherverwaltung... Wenn man es mal auf Anwendungen einschränkt und Systemprogramme ausnimmt: Wozu braucht die Anwendung unbedingt Pointer und eine Speicherverwaltung? Speicher wird doch vom System angefordert und das sollte auch die Anwendung eingesperrt haben so das diese mit einem (Far?)Pointer auch nicht raus käme - und nur gegen Gitterstäbe rennen sollte (Abbruch wg. Illegaler Operation z.b.) womit dann der Autor in der Pflicht stünde das zu korrigieren. Und ein Artiges OS sollte auch nach Programm-ende den Müll weg räumen = Use-after-free was doch wohl hieße das nach Freigeben noch etwas genutzt werden könnte - was nicht weg geräumt wurde!? BTW. Pointer mit Größenangabe klingt sehr nach Segment-selektor. Da steht auch die Startadresse und die Größe des Segments drin. :-) Vielleicht sehe ich das aber doch zu sehr durch die Gitterstäbe des Segment-Modells im Protected Mode ab i386 - bei dem man jedem Segment RO, Code oder RW,Data und eine Größe und Basis-adresse mit geben konnte. Wird ja heute wohl nicht mehr verwendet, stattdessen alles in einem Flat-Modell und mit kruden Hilfsmitteln (DEP, NX) eingezäunt. "Die Geister die man rief..."? Wäre es da wirklich eine Verbesserung wenn man für Anwendungen eine Sprache wählte die nicht mit Zeigern rum ferkeln könnte, und die "Ferkeligen" Sprachen eher nur dort verwendet wo es wirklich nötig wäre? Bye/ /Kay -- nix
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-05-13 10:51 +0200 |
| Message-ID | <v1srbq.5sk.1@stefan.msgid.phost.de> |
| In reply to | #44679 |
Am 13.05.2024 um 01:54 schrieb Kay Martinen: > Am 06.05.24 um 18:41 schrieb Stefan Reuther: >> Am 05.05.2024 um 16:18 schrieb Arno Welzel: >>> Ja, sowas meine ich aber nicht, sondern die Vermeidung von Pointern ohne >>> Information darüber, wie groß der Adressbereich ist, der über den >>> Pointer angesprochen werden darf und eine zuverlässige Verhinderung von >>> Buffer Overflow. Das alleine verhindert sich eine sehr große Zahl >>> Sicherheitsproblemen. > >> Aber das ist nur eins von vielen Problemen. Das Problem "use-after-free" >> löst auch ein Pointer mit Größeninformation nicht. > > Ich will jetzt nicht behaupten ich wüsste was Pointer genau machen, aber > es sind wohl Zeiger in einen Adressraum. Und das Problem besteht bei > einem Multitasking-system wohl darin das dies auch ein Fremder Prozess > sein könnte oder? Nein, denn der fremde Prozess nutzt einen anderen Adressraum. > Und speicherverwaltung... Wenn man es mal auf Anwendungen einschränkt > und Systemprogramme ausnimmt: Wozu braucht die Anwendung unbedingt > Pointer und eine Speicherverwaltung? Speicher wird doch vom System > angefordert und das sollte auch die Anwendung eingesperrt haben so das > diese mit einem (Far?)Pointer auch nicht raus käme - und nur gegen > Gitterstäbe rennen sollte (Abbruch wg. Illegaler Operation z.b.) womit > dann der Autor in der Pflicht stünde das zu korrigieren. Das Problem ist (heutzutage) nicht, dass der Prozess versehentlich auf Speicher zugreift, der einem anderen Prozess gehört, sondern dass ein Teil des Prozesses auf Speicher zugreift, den ein anderer Teil des gleichen Prozesses für einen anderen Zweck verwenden möchte. > BTW. Pointer mit Größenangabe klingt sehr nach Segment-selektor. Da > steht auch die Startadresse und die Größe des Segments drin. :-) Wenn man mit maximal ~8000 möglichen Allokationen auskommt, kann man das so machen. Dann ist die Deskriptortabelle voll. > Wäre es da wirklich eine Verbesserung wenn man für Anwendungen eine > Sprache wählte die nicht mit Zeigern rum ferkeln könnte, und die > "Ferkeligen" Sprachen eher nur dort verwendet wo es wirklich nötig wäre? Eine Programmiersprache, die Speichersicherheit durchsetzt, ist sicher ein Fortschritt gegenüber einer, die das nicht tut. Nur verführt das halt zu der Ansicht "ich habe einen Garbage Collector und nun bin ich alle meine Probleme los und muss mich um nichts mehr kümmern". Das ist eben nicht so. Abstrahiert betrachtet ist ein Pointer nur ein Bitmuster, das eine Ressource beschreibt. Ein File Descriptor ist auch nur ein Bitmuster, das eine Ressource beschreibt. Und *gerade* in Sprachen, die meinen, sich nicht um Ressourcenmanagement kümmern zu müssen - "wir haben ja einen Garbage Collector" - ist die Verwaltung solcher Ressourcen dann extrem nervig. Entweder man lässt das den GC über Finalizer machen (deprecated feature), dann führt das dazu, dass der Jenkins nach dem RAM-Upgrade mit "too many open files" stirbt, weil der GC seltener aufräumt. Oder man versucht es manuell, und muss damit wieder alle Ressourcen einzeln verwalten - wo einem doch versprochen wurde, dass man das nicht mehr müsse. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-13 13:45 +0200 |
| Message-ID | <laecqlF2um9U1@mid.individual.net> |
| In reply to | #44682 |
Am 13.05.24 um 10:51 schrieb Stefan Reuther: > Am 13.05.2024 um 01:54 schrieb Kay Martinen: >> Am 06.05.24 um 18:41 schrieb Stefan Reuther: >>> Am 05.05.2024 um 16:18 schrieb Arno Welzel: >>>> Ja, sowas meine ich aber nicht, sondern die Vermeidung von Pointern ohne >>>> Information darüber, wie groß der Adressbereich ist, der über den >>>> Pointer angesprochen werden darf und eine zuverlässige Verhinderung von >>>> Buffer Overflow. Das alleine verhindert sich eine sehr große Zahl >>>> Sicherheitsproblemen. >> >>> Aber das ist nur eins von vielen Problemen. Das Problem "use-after-free" >>> löst auch ein Pointer mit Größeninformation nicht. >> >> Ich will jetzt nicht behaupten ich wüsste was Pointer genau machen, aber >> es sind wohl Zeiger in einen Adressraum. Und das Problem besteht bei >> einem Multitasking-system wohl darin das dies auch ein Fremder Prozess >> sein könnte oder? > > Nein, denn der fremde Prozess nutzt einen anderen Adressraum. Auch bei shared memory? > Das Problem ist (heutzutage) nicht, dass der Prozess versehentlich auf > Speicher zugreift, der einem anderen Prozess gehört, sondern dass ein > Teil des Prozesses auf Speicher zugreift, den ein anderer Teil des > gleichen Prozesses für einen anderen Zweck verwenden möchte. Welcher Speicherbereich gehört zu welche threads? >> BTW. Pointer mit Größenangabe klingt sehr nach Segment-selektor. Da >> steht auch die Startadresse und die Größe des Segments drin. :-) Wird bei intel.. noch Segemente verwendet? Da gab es doch diverse Register. > Eine Programmiersprache, die Speichersicherheit durchsetzt, ist sicher > ein Fortschritt gegenüber einer, die das nicht tut. Nur verführt das > halt zu der Ansicht "ich habe einen Garbage Collector und nun bin ich > alle meine Probleme los und muss mich um nichts mehr kümmern". Das ist > eben nicht so. Garbage Collector nascht CPU Takte. Buchführung über referenzen. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-13 14:04 +0200 |
| Message-ID | <laeduqF33fuU1@mid.individual.net> |
| In reply to | #44682 |
Am 13.05.24 um 11:49 schrieb Stefan Ram: > Stefan Reuther <stefan.news@arcor.de> schrieb oder zitierte: >> Am 13.05.2024 um 01:54 schrieb Kay Martinen: >>> Ich will jetzt nicht behaupten ich wüsste was Pointer genau machen, aber >>> es sind wohl Zeiger in einen Adressraum. Und das Problem besteht bei >>> einem Multitasking-system wohl darin das dies auch ein Fremder Prozess >>> sein könnte oder? >> Nein, denn der fremde Prozess nutzt einen anderen Adressraum. > > Ich möchte hier einmal auf die Frage, was "Pointer genau machen" > zurückkommen. > > Ein Zeiger ist eher ein Datum, er "macht" also nichts. > Was etwas "macht", ist ein Prozeß. > > Was ein "Zeiger" genau ist, hängt von der Programmiersprache ab. > > In der verbreitetesten Programmiersprache, Python, gibt es überhaupt > keine Zeiger. id dürfte Zeiger lesen. In der zweitverbreitetesten, C, gibt es aber Zeiger. > > Die Definition von Zeigern in der Sprachnorm finde ich aber nicht > überzeugend, so daß ich hier etwas meine eigene Definition geben muß: > > Zunächst einmal eine vereinfachte Definition, die aber für > viele Zwecke schon ausreicht: > > Ein /Zeiger/ ist nichts anderes als eine /Adresse/. > > Wenn man es dann etwas genauer sagen will, muß man hinzufügen, > daß ein Zeiger neben einer Adresse auch noch eine Information > über den /Typ und die Größe/ des Zieles enthält. Das wäre kein pointer sondern ein descriptor. Z.B. enthält ein descriptor für einen string Adresse, benutzte Länge eventuell allozierte Länge. Eventuell noch ein used_count für garbage collection. Eventuell noch Angaben über Inhalt z.B. ISO oder utf* > Bei den Zeigerwerten müssen wir zwischen zwei Wertarten > unterscheiden: > > - dem Nullzeiger und > - allen anderen Zeigern. Ach was. In C verwende ich den Wert 0 für Null. ( menset(pointer 0, sizeof(struct)) auch wenn struct pointer enthält. ) Funktioniert unter intel* Linux. Wenn 0->irgendwas zugegriffen wird, liegt erfahrungsgmäß ein Adressing error vor. > > Bei den Zeigertypen müssen wir zweischen zwei Zeigertyparten > unterscheiden: > > - Objektzeigertyparten und > - Funktionszeigertyparten. > > Bei den Objektzeigertyparten müssen wir unterscheiden: > > - dem Void-Zeiger-Typ und > - Nichtvoid-Zeiger-Typarten. Für gewisse Zeiger Arithmetik habe sich cast auf (char *) verwendet. Wenn ich z.B. in opcode positioniere, die verschiedene layout von opcode in struct mit union habe .. > Einem Zeiger des Void-Zeiger-Typs fehlt die Information über den > Typ und damit über die Größe des Objektes an der Adresse des Zeigers. > Er entspricht damit einer reinen Adresse aus der Maschinensprache. > Schließlich muß man noch festhalten, daß es eine zentrale > Operation für Zeiger gibt, nämlich die Dereferenzierung "*". > Mehr dazu folgt. > > Dann können wir sagen: > > - Ein Zeigerobjekt enhält einen Zeigerwert. > > - Der Nullzeiger darf nicht dereferenziert werden. War der nicht früher mal #define Null 0? > - Ein Wert des Void-Zeiger-Typs darf auch nicht > dereferenziert werden. void *p; *(char*)p ist erlaubt. > Was ein "Pointer" ist, hängt von der Sprache ab. In C ist > er nicht nur die Adresse, sondern hat eben manchmal auch > noch Typinformation, welche manchmal die Größe liefert. Beim compiler ja, im Objekt nicht mehr. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-13 17:23 +0000 |
| Message-ID | <v1tiah$3j99h$1@dont-email.me> |
| In reply to | #44679 |
Kay Martinen <usenet@martinen.de> schrieb: > > > Am 06.05.24 um 18:41 schrieb Stefan Reuther: >> Am 05.05.2024 um 16:18 schrieb Arno Welzel: >>> Stefan Reuther, 2024-05-05 10:16: >>>>>> Auf irgendeiner Ebene in dem Stapel braucht es eine Sprache wie C. Zum > >>> [Rust] > >> Braucht halt immer noch 'unsafe', um interessante Dinge wie eine >> Speicherverwaltung zu implementieren. Es ist natürlich zweifelsohne ein >> Fortschritt, die potenziell unsicheren Teile zu markieren. > >> Pascal ist nicht besser als C. Da kann man genauso mit Casts und Zeigern >> rumferkeln. > >>> Ja, sowas meine ich aber nicht, sondern die Vermeidung von Pointern ohne >>> Information darüber, wie groß der Adressbereich ist, der über den >>> Pointer angesprochen werden darf und eine zuverlässige Verhinderung von >>> Buffer Overflow. Das alleine verhindert sich eine sehr große Zahl >>> Sicherheitsproblemen. > >> Aber das ist nur eins von vielen Problemen. Das Problem "use-after-free" >> löst auch ein Pointer mit Größeninformation nicht. > > Ich will jetzt nicht behaupten ich wüsste was Pointer genau machen, aber > es sind wohl Zeiger in einen Adressraum. Und das Problem besteht bei > einem Multitasking-system wohl darin das dies auch ein Fremder Prozess > sein könnte oder? Schon die IBM /360 von 1965 hatte da einen Schutz. Ich zitiere einfach mal aus dem "Principle of Operations": # Protection feature # # The Protection Feature protects the contents of certain areas of # storage from destruction due to erroneous storing of information # during the execution of a program. This protection is achieved by # identifying blocks of storage with a storage key and comparing this # key with a protection key supplied with the data to be stored. The # detection of a mismatch results in a protection interruption. # For protection purposes, main storage is divided into blocks # of 2,048 bytes. A four-bit storage key is associated with each # block. When data are stored in a storage block, the storage key # is compared with the protection key. When storing is specified # by an instruction, the protection key of the current psw is # used as the comparand. When storing is specified by a channel # operation, a protection key supplied by the channel iis used as # the comparand. The keys are said to match when they are equal or # when either one is zero.
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-05 11:22 +0000 |
| Message-ID | <l9p8fuFrft6U1@mid.individual.net> |
| In reply to | #44478 |
Stefan Reuther <stefan.news@arcor.de> wrote: >> Zumindest *weiß* Python wie groß Speicherblöcke sind und kennt auch >> Garbage Collection. Das ist um Größenordnungen zuverlässiger als C. > > Ja, Python weiß das, weil jemand ein C-Programm geschrieben hat, dass > diese Informationen mitführt und überprüft. Deswegen ist "verbietet C" > weder möglich noch sinnvoll. Philiosophisch gesehen ist in diesem Beispiel Python die Abstraktionsschicht, die durch ihr Vorhandensein und die ihr programmierten Aufgaben wiederum Ressourcen (RAM, CPU) braucht und damit mehr oder weniger "schlimm" das verursacht, was ein Teil der Gruppenmitglieder hier als "Bloat" verteufelt. Dazu kommt, dass jeglicher Code, der vorhanden ist, potentiell Bugs hat und damit eine zusätzliche Angriffsfläche bietet. Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch in C sauber und sicher programmieren kann. Dazu braucht es IMHO Disziplin, Umsicht und Kenntnisse, 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. >> 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. 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. 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. 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. 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. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-05 15:57 +0200 |
| Message-ID | <slrnv3f42j.16usm.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44495 |
On 2024-05-05 11:22, poc@pocnet.net <poc@pocnet.net> wrote:
> Stefan Reuther <stefan.news@arcor.de> wrote:
>>> Zumindest *weiß* Python wie groß Speicherblöcke sind und kennt auch
>>> Garbage Collection. Das ist um Größenordnungen zuverlässiger als C.
>>
>> Ja, Python weiß das, weil jemand ein C-Programm geschrieben hat, dass
>> diese Informationen mitführt und überprüft. Deswegen ist "verbietet C"
>> weder möglich noch sinnvoll.
>
> Philiosophisch gesehen ist in diesem Beispiel Python die Abstraktionsschicht,
> die durch ihr Vorhandensein und die ihr programmierten Aufgaben wiederum
> Ressourcen (RAM, CPU) braucht und damit mehr oder weniger "schlimm" das
> verursacht, was ein Teil der Gruppenmitglieder hier als "Bloat" verteufelt.
>
> Dazu kommt, dass jeglicher Code, der vorhanden ist, potentiell Bugs hat und
> damit eine zusätzliche Angriffsfläche bietet.
>
> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch
> in C sauber und sicher programmieren kann.
Kommt darauf an, wen du mit "man" meinst.
> Dazu braucht es IMHO Disziplin, Umsicht und Kenntnisse,
ACK. Und damit wird die Menge der "man"s schon recht klein. Und auch
Leute mit Disziplin, Umsicht und Kenntnissen sind nicht davor gefeit,
dumme Fehler zu machen, insbesondere dann nicht, wenn sie unter
Zeitdruck arbeiten.
> 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?
Programmiererzeit kostet. CPU-Zeit beim Kunden nicht.
(CPU-Zeit auf der eigenen Hardware kostet auch - nicht umsonst stecken
die großen Cloud-Provider großen Aufwand in Performance. Aber Du wirst
feststellen, dass auch dort eher wenig in C oder gar Assembler
programmiert wird. Das ist ein Tradeoff zwischen Entwicklungszeit,
Wartbarkeit und Betriebskosten.)
>>> 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.
>
> Ein Beispiel:
Schlechtes 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.
>
> 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.
>
> 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.
>
> 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.
Das liegt sicher zu 99% an der Unfähigkeit des Programmierers. Node.js
ist sicher etwas größer als Perl (schon wegen des JIT-Compilers) und das
npm-Ökosystem ist notorisch dafür, dass jede kleine Library hundert
andere kleine Libraries mit rein zieht, aber gerade bei Datenbanken
liegt schlechte Performance fast immer daran, dass der Programmierer
kein vernünftiges SQL schreiben kann (zugegeben: Manchmal liegt das
"nicht können" nicht am mangelnden Wissen, sondern an einem ORM, aber
das ist wiederum sprachunabhängig und im Zweifelsfall sollte man auch
wissen, wie man ohne ORM auskommt, bzw. dieses umgeht).
(Wir haben übrigens gerade einen ähnlichen Fall in PHP. Die
Wordpress-Applikation braucht für eine Seite 6 bis 10 Sekunden. Das sind
ca. 800-900 einzelne SQL-Querys, natürlich ist das langsam. Mittels
Cache ist das jetzt auf ein akzeptables Maß beschleunigt worden, aber
das sollte bei der moderaten Datenmenge (ca. 20000 Dokumente) gar nicht
notwendig sein. Und sowenig ich PHP mag: PHP ist nicht schuld. Das ist
zum Teil ein Problem mit der Wordpress-Infrastruktur (das ist halt eine
Blogging-Software und kein CMS) aber zum Großteil ein Problem der
Entwickler, die nicht verstanden haben, dass für diesen Anwendungszweck
das Wordpress-Datenmodell ungeeignet ist und sie ihre eigenen Tabellen
anlegen und ihre eigenen Querys (in SQL oder mittels einem geeigneten
ORM) schreiben müssen.)
hp
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-05 18:30 +0000 |
| Message-ID | <l9q1h8Fj2mU1@mid.individual.net> |
| In reply to | #44497 |
Peter J. Holzer <hjp-usenet4@hjp.at> wrote: >> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch >> in C sauber und sicher programmieren kann. > > Kommt darauf an, wen du mit "man" meinst. 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. >> 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? > 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? Sicherlich ist alles zuvor auf's Kleinste raus planen und dann das ganze im vorletzten Schritt in Code umsetzen auch nicht der Königsweg, aus verschiedenen Gründen. Wirtschaftliche, aber auch psychologische bei denjenigen die dann die Umsetzung letztendlich "doof" vornehmen sollen und zu "dummen" Code Monkeys degreadiert werden. >> 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. > Programmiererzeit kostet. CPU-Zeit beim Kunden nicht. Du triffst den Nagel auf den Kopf. Das ist eine zu KKWs vergleichbare Milchmädchenrechnung: Wenn man dort Rückbau und Entsorgung aus den Gesamtkosten rausnimmt, sieht die Bilanz für die Technik sehr interessant aus. > (CPU-Zeit auf der eigenen Hardware kostet auch - nicht umsonst stecken die > großen Cloud-Provider großen Aufwand in Performance. Aber Du wirst > feststellen, dass auch dort eher wenig in C oder gar Assembler programmiert > wird. Das ist ein Tradeoff zwischen Entwicklungszeit, Wartbarkeit und > Betriebskosten.) Vermutlich, ja. Ich habe keine Einblicke. Aber wie schon weiter oben gesagt, das Problem der "sicheren" (einfacheren, billigeren) Programmierung als Einmal-Investition tausendfach zum Kunden bzw. dessen Infrastruktur zu verschieben gefühlt falsch. >> Ein Beispiel: > > Schlechtes Beispiel. Beispiel aus dem Alltag. Deiner Reaktion nach zu urteilen nicht typisch. > das npm-Ökosystem ist notorisch dafür, dass jede kleine Library hundert > andere kleine Libraries mit rein zieht Das habe ich auch an verschiedenen Stellen mitbekommen und war auch schon Thema in einer Heise-Publikation: Besser mal 5 Zeilen selbst schreiben als -zigfach externen Code reinzuzerren, der schon nächste Woche nicht mehr gewartet wird. > aber gerade bei Datenbanken liegt schlechte Performance fast immer daran, > dass der Programmierer kein vernünftiges SQL schreiben kann Äh. Select * from … insert den Käse auf der anderen Seite? How hard can it be? > (zugegeben: Manchmal liegt das "nicht können" nicht am mangelnden Wissen, > sondern an einem ORM, aber das ist wiederum sprachunabhängig und im > Zweifelsfall sollte man auch wissen, wie man ohne ORM auskommt, bzw. dieses > umgeht). -v, bitte. Was ist (ein) ORM? > (Wir haben übrigens gerade einen ähnlichen Fall in PHP. Die > Wordpress-Applikation braucht für eine Seite 6 bis 10 Sekunden. Das sind ca. > 800-900 einzelne SQL-Querys, natürlich ist das langsam. Mittels Cache ist > das jetzt auf ein akzeptables Maß beschleunigt worden, aber das sollte bei > der moderaten Datenmenge (ca. 20000 Dokumente) gar nicht notwendig sein. Und > sowenig ich PHP mag: PHP ist nicht schuld. Das ist zum Teil ein Problem mit > der Wordpress-Infrastruktur (das ist halt eine Blogging-Software und kein > CMS) aber zum Großteil ein Problem der Entwickler, die nicht verstanden > haben, dass für diesen Anwendungszweck das Wordpress-Datenmodell ungeeignet > ist und sie ihre eigenen Tabellen anlegen und ihre eigenen Querys (in SQL > oder mittels einem geeigneten ORM) schreiben müssen.) Ja, auch das beobachte ich immer wieder. Hat man einen Hammer sieht man plötzlich lauter Nägel um sich, obwohl es bei genauerem Hinsehen z. B. Schrauben sind. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-05 21:54 +0200 |
| Message-ID | <slrnv3fovi.17r33.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44510 |
On 2024-05-05 18:30, poc@pocnet.net <poc@pocnet.net> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> wrote:
>>> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch
>>> in C sauber und sicher programmieren kann.
>>
>> Kommt darauf an, wen du mit "man" meinst.
>
> 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?
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.
;-)
>>> 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.
>> 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*.
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.
>
> Bei dem was ich heutzutage so in c't und iX mitbekomme,
Das klingt jetzt nicht so, als ob selbst programmieren würdest.
> 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 Antwort ist ein entschiedenes "Vielleicht".
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.
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. Anforderungsanalyse,
Architektur, etc. sind nach wie vor wichtig. Aber es heißt, dass man
damit rechnen muss, dass Teile nie umgesetzt werden und es daher sinnlos
ist, die ins kleinste Detail vorzuplanen. Und man muss auch damit
rechnen, dass komplett neue Teile dazukommen, mit denen am Anfang noch
niemand gerechnet hat,
Nicht zuletzt ist ein Programm erst dann fertig, wenn es nicht mehr
verwendet wird. Das ist etwas ganz anderes als eine Brücke, die fertig
ist, bevor sie eröffnet wird. Ein Programm ist eher sowas wie
mittelalterliche Burg, die über Jahrhunderte immer wieder erweitert und
umgebaut wird. #thereisnoproject
>>> Ein Beispiel:
>>
>> Schlechtes Beispiel.
>
> Beispiel aus dem Alltag. Deiner Reaktion nach zu urteilen nicht typisch.
Doch. Das ist typisch. Aber es ist ein schlechtes Beispiel für das was
Du belegen willst. Das Problem hier ist eben nicht JavaScript, sondern
die Kompetenz des Programmierers. Der hätte in C sicher den gleichen
Unsinn gebaut oder vielleicht noch einen größeren (weil er sich mehr mit
Eigenheiten von C beschäftigen muss und noch weniger in der Lage ist,
sich auf das eigentliche Problem zu konzentrieren). Und Du hast ja
geschrieben, dass Du das in Perl (das nun wirklich kein
Performance-Wunder ist) deutlich beschleunigt hast.
>> aber gerade bei Datenbanken liegt schlechte Performance fast immer daran,
>> dass der Programmierer kein vernünftiges SQL schreiben kann
>
> Äh. Select * from … insert den Käse auf der anderen Seite? How hard can it be?
Für jemanden, der sich nie mit den Grundlagen beschäftigt hat: Ziemlich.
>> (zugegeben: Manchmal liegt das "nicht können" nicht am mangelnden Wissen,
>> sondern an einem ORM, aber das ist wiederum sprachunabhängig und im
>> Zweifelsfall sollte man auch wissen, wie man ohne ORM auskommt, bzw. dieses
>> umgeht).
>
> -v, bitte. Was ist (ein) ORM?
Object-Relational-Mapping. Ein System, das es dem Programmierer
erlaubt, objektorientierten Code in seiner Applikations-Sprache (Java,
Perl, Python, JavaScript, Go, ...) zu schreiben und im Hintergrund wird
automatisch SQL generiert und ausgeführt. Bekannte Beispiele sind z.B.
Hibernate für Java, DBIx::Class für Perl, Django[1] für Python, GORM für
Go, ...
Die Idee dahinter ist, dass es für einen Java-Programmierer leichter
ist, typischen Java-Code zu lesen und zu verstehen, als eine Mischung
aus Java- und SQL-Code (wobei letzterer dann wahrscheinlich noch
dynamisch generiert wird). Und bei der Gelegenheit kann der Compiler
auch noch gleich Typüberprüfungen vornehmen, etc.
Problem dabei ist, dass "der Programmierer muss nicht SQL schreiben"
oft als "der Programmierer muss keine Ahnung von relationalen
Datenbanken haben" missverstanden wird. Und wenn man keine Ahnung von
relationalen Datenbanken hat, wird man keinen effizienten Code
schreiben (selbst wenn man Ahnung hat, ist nicht immer offensichtlich,
welche Methoden man in welcher Reihenfolge aufrufen muss, damit am Ende
effizientes SQL herauskommt).
hp
[1] Django ist ein komplettes Framework für Web-Entwicklung. Das ORM ist
nur ein Teil davon.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-06 13:04 +0200 |
| Message-ID | <l9rrpkF91ndU2@mid.individual.net> |
| In reply to | #44513 |
Peter J. Holzer, 2024-05-05 21:54:
> On 2024-05-05 18:30, poc@pocnet.net <poc@pocnet.net> wrote:
[...]
>> -v, bitte. Was ist (ein) ORM?
>
> Object-Relational-Mapping. Ein System, das es dem Programmierer
> erlaubt, objektorientierten Code in seiner Applikations-Sprache (Java,
> Perl, Python, JavaScript, Go, ...) zu schreiben und im Hintergrund wird
> automatisch SQL generiert und ausgeführt. Bekannte Beispiele sind z.B.
> Hibernate für Java, DBIx::Class für Perl, Django[1] für Python, GORM für
> Go, ...
... Doctrine, Propel, Laravel[2]. Implementierungen gibt es wohl für
jede Sprache, die ein Konzept von Klassen kennt.
[...]
> Problem dabei ist, dass "der Programmierer muss nicht SQL schreiben"
> oft als "der Programmierer muss keine Ahnung von relationalen
> Datenbanken haben" missverstanden wird. Und wenn man keine Ahnung von
> relationalen Datenbanken hat, wird man keinen effizienten Code
> schreiben (selbst wenn man Ahnung hat, ist nicht immer offensichtlich,
> welche Methoden man in welcher Reihenfolge aufrufen muss, damit am Ende
> effizientes SQL herauskommt).
ACK. Wobei "ORM" durchaus auch verstanden sein sollte. Ich hatte mal den
Fall, dass ein Team lange vor mir eine Anwendung gebaut hat, die
Strukturen wie diese hatte:
Person {
Int id;
String name;
}
Document {
Int id;
String name
};
DocumentRelation {
Int idPatient;
Int idPerson;
}
Dazu kam noch, dass die Relation Person zu Dokument 1:n war und die
Möglichkeit, dass ein Dokument auch mehreren Personen zugewordnet werden
konnte, rein sachlich falsch war. Dass die ORM-Bibliothek aber sowohl
1:1 wie auch 1:n, n:1 oder n:m in allen Varianten abbilden konnte, war
den damals verantwortlichen Leuten, die das implementiert hatten, wohl
schlicht komplett unklar. Die korrekte Lösung war dann sinngemäß sowas:
Person {
Int id;
String name;
Document documents[];
}
Document {
Int id;
Person person;
String name
};
Fazit: nein, Tools alleine reichen nie aus, man muss auch wissen, wie
man damit umgeht.
> [1] Django ist ein komplettes Framework für Web-Entwicklung. Das ORM ist
> nur ein Teil davon.
[2] Laravel ist ein komplettes Framework für Web-Entwicklung. Das ORM
ist nur ein Teil davon ;-)
--
Arno Welzel
https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-06 11:45 +0000 |
| Message-ID | <v1afsl$2hojv$1@dont-email.me> |
| In reply to | #44523 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > ... Doctrine, Propel, Laravel[2]. Implementierungen gibt es wohl für > jede Sprache, die ein Konzept von Klassen kennt. Für Fortran kenne ich das nicht, ist aber jetzt auch nicht die typische Datenbank-Sprache (aber objektorientiert, wenn man CLASS verwendet).
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-06 20:53 +0000 |
| Message-ID | <l9suacFe83jU1@mid.individual.net> |
| In reply to | #44513 |
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. > 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, der auf Kosten "einfacherer" Programmierung ungefragt den Anwendern (und in Form von global höherem Stromverbrauch auch der Umwelt auferlegt wird. Ja, "sichere" Programmierung und Bloat ist nicht genau das gleiche. Aber es gibt IMHO eine signifikante Schnittmenge. >> 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.? >> Bei dem was ich heutzutage so in c't und iX mitbekomme, > > Das klingt jetzt nicht so, als ob selbst programmieren würdest. Das was ich programmiere sind kleinere Dinge, in C, in RPG und in Perl. Ich sehe mich selbst nicht als Fachmann in diesem Zweig und auch als sehr ineffizient: Ich bin ziemlich langsam. Aber: Auch wenn ich selbst programmiere, habe ich ja trotzdem nur meine eigene Sicht. Was "da draußen" so geht, bleibt mir mehr oder weniger verborgen, ob ich nun programmiere oder nicht. > 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. > 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. > Nicht zuletzt ist ein Programm erst dann fertig, wenn es nicht mehr > verwendet wird. Das ist etwas ganz anderes als eine Brücke, die fertig > ist, bevor sie eröffnet wird. Ein Programm ist eher sowas wie > mittelalterliche Burg, die über Jahrhunderte immer wieder erweitert und > umgebaut wird. #thereisnoproject Guter Punkt. >> -v, bitte. Was ist (ein) ORM? > > Object-Relational-Mapping. Ein System, das es dem Programmierer > erlaubt, objektorientierten Code in seiner Applikations-Sprache (Java, > Perl, Python, JavaScript, Go, ...) zu schreiben und im Hintergrund wird > automatisch SQL generiert und ausgeführt. Bekannte Beispiele sind z.B. > Hibernate für Java, DBIx::Class für Perl, Django[1] für Python, GORM für > Go, ... Okay, ich bin raus. :-) Den Objektkram habe nur ansatzweise verstanden, auf abstrakte Weise. Definitiv nicht ausreichend um das Wissen in der Praxis anzuwenden. > Problem dabei ist, dass "der Programmierer muss nicht SQL schreiben" > oft als "der Programmierer muss keine Ahnung von relationalen > Datenbanken haben" missverstanden wird. Verstehe. Und wieder eine Abstraktionsschicht, die vermeintlich was verbessern soll, aber dann am Ende doch nur wieder, nun, eine Abstraktionsschicht bleibt, die zudem über die Problemlösung hinaus weitere Probleme mit sich bringt. :-) > Und wenn man keine Ahnung von relationalen Datenbanken hat, wird man keinen > effizienten Code schreiben (selbst wenn man Ahnung hat, ist nicht immer > offensichtlich, welche Methoden man in welcher Reihenfolge aufrufen muss, > damit am Ende effizientes SQL herauskommt). Nun, wenn ich SQL kann und mich mit Datenbanken auskenne, dann brauche ich das ganze Rätselraten nicht und entwickle besser auf die "unbequeme" Mischmaschtour, aber effizient(er). Das geht durchaus in die Richtung in die ich denke, wenn ich das allgemeine Verteufeln von C verteufele. ;-) -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-07 08:42 +0000 |
| Message-ID | <v1cpgu$35feh$1@dont-email.me> |
| In reply to | #44544 |
poc@pocnet.net <poc@pocnet.net> schrieb: > Peter J. Holzer <hjp-usenet4@hjp.at> wrote: >> 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. Ist möglich, im Prinzip. Allerdings (und jetzt hole ich mal ein bisschen aus) hängt das mit dem zusammen, was Brooks "accidental complexity" und "essential complexity" nennt (in "No Silver Bullet"). "Accidental complexity" ist bei ihm der Teil der Komplexität, der durch die Umstände verursacht wird, wie z.B. die Wahl einer Programmiersprache (Assembler, C, Fortran, Julia oder Python) oder einer Programmierumgebung (Batch oder interaktiv (bei ihm noch "Timesharing" genannt - folkloristisch)). "Essential complexity" ist der Teil, dem einen keiner abnhehmen kann - da muss selber gedacht, strukturiert etc werden. Und C hat, als Programmiersprache auf einem relativ niedrigen Level, eine höhere "accidental complexity" als Fortran oder Julia. Damit sinkt in der Regel die Produktivität, und die Fehlerrate erhöht sich. Bei Programmierern ist sowieso die Produktivität sehr stark unterschiedlch, Brooks berichtet schon über einen Faktor 10. Die Frage ist halt, ob man die niedrigere "accidental complexity" mit schlechterer Performance bezahlen muss. Bei Python ist das definitiv der Fall, bei Fortran ist es eher das Gegenteil (Fortran-Code ist zumindest von den Möglichkeiten der Sprache schneller als C), bei Julia muss man mit einer gewissen Disziplin programmieren (statische statt dynamische Arrays z.B.), um an die Geschwindigkeit von C oder Fortran ranzukommen und bei Python hat man entweder hocheffiziente Libraries oder todlangsamen interpretierten Code.
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-07 21:56 +0000 |
| Message-ID | <l9vmd5FqocnU1@mid.individual.net> |
| In reply to | #44565 |
Thomas Koenig <tkoenig@netcologne.de> wrote: >>> 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. > > Ist möglich, im Prinzip. Deckt sich mit meiner Einschätzung. > Allerdings (und jetzt hole ich mal ein bisschen aus) hängt das mit dem > zusammen, was Brooks "accidental complexity" und "essential complexity" > nennt (in "No Silver Bullet"). > > "Accidental complexity" ist bei ihm der Teil der Komplexität, der durch die > Umstände verursacht wird, wie z.B. die Wahl einer Programmiersprache > (Assembler, C, Fortran, Julia oder Python) oder einer Programmierumgebung > (Batch oder interaktiv (bei ihm noch "Timesharing" genannt - > folkloristisch)). "Essential complexity" ist der Teil, dem einen keiner > abnhehmen kann - da muss selber gedacht, strukturiert etc werden. Klar, essential, oder auch inhärent: Wenn ich ein komplexes Problem programmatisch lösen möchte, ist das zugehörige Programm meistens auch komplex. Diese Art Komplexität meine ich allerdings nicht, sondern die accidental. > Und C hat, als Programmiersprache auf einem relativ niedrigen Level, eine > höhere "accidental complexity" als Fortran oder Julia. Damit sinkt in der > Regel die Produktivität, und die Fehlerrate erhöht sich. Nachvollziehbar, beleuchtet aber nur das Thema der Programmierung an sich, und nicht das was hinten rauskommt. > Bei Programmierern ist sowieso die Produktivität sehr stark unterschiedlch, > Brooks berichtet schon über einen Faktor 10. Ich kann mir sogar vorstellen, dass Faktor 10 bei der gleichen Person je nach Tagesform drin ist. > Die Frage ist halt, ob man die niedrigere "accidental complexity" > mit schlechterer Performance bezahlen muss. Nicht zwingend, aber oftmals ist das der Fall. Vor allem, wenn man den Themenkomplex nicht nur auf Programmiersprachen per se eingrenzt, sondern auch das um die jeweilige Sprache gewachsene Ökosystem (Dickicht?) mit berücksichtigt. Das Thema überbordende Includes bei Node wurde ja schonmal an anderer Stelle erwähnt und sei hier als Beispiel genannt. > Bei Python ist das definitiv der Fall, bei Fortran ist es eher das Gegenteil > (Fortran-Code ist zumindest von den Möglichkeiten der Sprache schneller als > C), bei Julia muss man mit einer gewissen Disziplin programmieren (statische > statt dynamische Arrays z.B.), um an die Geschwindigkeit von C oder Fortran > ranzukommen und bei Python hat man entweder hocheffiziente Libraries oder > todlangsamen interpretierten Code. Tja, nur programmiert heutzutage fast keiner mehr in Fortran, bäh, alt, staubig, uncool, nicht hip, mega out. Die üblichen Argumente. Es gilt halt nach wie vor: Um einen Nagel in der Wand zu versenken brauche ich einen Hammer und keinen Schraubendreher. :-) Use the right tool for the job. Aber nee, muss ja alles modern sein und daher müssen wir mit den Ineffizienzen von Python, Java und vergleichbaren modernen Konstrukten leben. ;-) -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-08 21:06 +0200 |
| Subject | Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) |
| Message-ID | <slrnv3nj8o.1fdo8.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44565 |
On 2024-05-07 08:42, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Allerdings (und jetzt hole ich mal ein bisschen aus) hängt das
> mit dem zusammen, was Brooks "accidental complexity" und "essential
> complexity" nennt (in "No Silver Bullet").
>
> "Accidental complexity" ist bei ihm der Teil der Komplexität,
> der durch die Umstände verursacht wird, wie z.B. die Wahl einer
> Programmiersprache (Assembler, C, Fortran, Julia oder Python) oder
> einer Programmierumgebung (Batch oder interaktiv (bei ihm noch
> "Timesharing" genannt - folkloristisch)). "Essential complexity"
> ist der Teil, dem einen keiner abnhehmen kann - da muss selber
> gedacht, strukturiert etc werden.
>
> Und C hat, als Programmiersprache auf einem relativ niedrigen Level,
> eine höhere "accidental complexity" als Fortran oder Julia.
Ich habe sehr wenig in Fortran programmiert und das ist lange her (ich
glaube, das war noch nicht mal Fortran 77[1]), daher demonstriere ich jetzt
vermutlich nur meine Ahnungslosigkeit, aber mein Eindruck von Fortran
war, dass es zwar für eine kleine Klasse von (hauptsächlich numerischen)
Problemen sehr gut geeignet ist, aber alles andere ist sehr umständlich.
Die accidental complexity von Fortran ist also für die meisten
Anwendungen ziemlich hoch. Es hat IMHO schon seinen Grund, warum
allgemeine Applikations- und Systemsoftware eher nicht in Fortran
geschrieben ist und dieser Grund ist IMHO nicht der Mangel an
Fortran-Compilern.
hp
[1] Wir hatten außerdem bis 2016 ein in Fortran geschriebenes
Datenbankabfragesystem, da habe ich gelegentlich beim Debuggen
geholfen. Und ein Buch über Fortran 90 habe ich auch mal gelesen.
Das zählt aber IMHO beides nicht wirklich.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-09 07:31 +0000 |
| Subject | Re: Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) |
| Message-ID | <v1hu4g$hea9$1@dont-email.me> |
| In reply to | #44607 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > On 2024-05-07 08:42, Thomas Koenig <tkoenig@netcologne.de> wrote: >> Allerdings (und jetzt hole ich mal ein bisschen aus) hängt das >> mit dem zusammen, was Brooks "accidental complexity" und "essential >> complexity" nennt (in "No Silver Bullet"). >> >> "Accidental complexity" ist bei ihm der Teil der Komplexität, >> der durch die Umstände verursacht wird, wie z.B. die Wahl einer >> Programmiersprache (Assembler, C, Fortran, Julia oder Python) oder >> einer Programmierumgebung (Batch oder interaktiv (bei ihm noch >> "Timesharing" genannt - folkloristisch)). "Essential complexity" >> ist der Teil, dem einen keiner abnhehmen kann - da muss selber >> gedacht, strukturiert etc werden. >> >> Und C hat, als Programmiersprache auf einem relativ niedrigen Level, >> eine höhere "accidental complexity" als Fortran oder Julia. > > Ich habe sehr wenig in Fortran programmiert und das ist lange her (ich > glaube, das war noch nicht mal Fortran 77[1]), daher demonstriere ich jetzt > vermutlich nur meine Ahnungslosigkeit, aber mein Eindruck von Fortran > war, dass es zwar für eine kleine Klasse von (hauptsächlich numerischen) > Problemen sehr gut geeignet ist, aber alles andere ist sehr umständlich. Das ist tatsächlich ein Problem der Sprache, es größtenteils ein Image-Problem. FORTRAN 77 hatte tatsächlich einige Eigenschaften, die den Umgang damit umständlich machten: Lochkartenformat, keine dynamische Speicherverwaltung, keine structs, keine Pointer (wenn man sie denn braucht, für Datenstrukturen), außer der DO-Loop und dem IF/THEN/ELSE/ENDIF keine strukturierten Kontrollstrukturen, kein Checken von Argumentlisten, record-orientierte I/O (wenn auch sehr mächtig), globale Variablen über die gefürchteten COMMON-Blöcke, aber dafür mehrdimensionale Arrays. Fortran 90 (etwas irreführend Ende 1991 herausgekommen, also jetzt 32 immerhin Jahre alt, das ist schon eine lange Zeit...) hat das grundlegend geändert: Seitdem hat Fortran user-defined types, Strukturierung von Programmen mit Modulen mit automatischer Prüfung von Argumenten, automatische Übergabe von Arraygrenzen, Pointer (wobei eine Variable explizit als "TARGET" deklariert werden muss, damit ein Pointer drauf zeigen kann; aber Pointer können z.B. auch auf einen Array oder Teile davon zeigen und nicht nur auf ein Element), globale Variablen in Modulen, freie Source-Form ohne das alte Lochkartenvormat, alle notwenigen Kontrollstrukturen einschließlich SELECT CASE (entsprechend switch() in C), ... Damit hatte C vom Sprachumpfang keinen Vorteil mehr gegenüber Fortran, es sei denn, man braucht unsigned ints (eine ärgerliche Lücke). Seit Fortran 95 (und einem TR kurz darauf) kamen auch noch allocatable variables dazu, mit denen man dynamische Speicherverwaltung einschließlich automatischer Deallokierung machen kann, ohne sich drum kümmern zu müssen. Wikipedia hat einen ausführlicheren Artikel zu dem Stand unter https://en.wikipedia.org/wiki/Fortran_95_language_features Seit Fortran 2003 hat gibt es auch Objektorientierung, wobei glücklicherweise auf multiple inheritance verzichtet wurde. Seit Fortran 2008 hat hat es Coarrays, eine vernünftige Methode der Parallelisierung, die auf partitioned global address spaces aufbaut (PGAS). Aber wenn Leute FORTRAN sagen, dann denken sie meistens (wenn überhaupt) an FORTRAN 77. Außerdem schienen sich eine ganze Generation von Informatikern über ihre Ablehnung von FORTRAN definiert zu haben, auch wenn sie in ihren eigenen Sprachen schamlos davon geklaut haben. > Die accidental complexity von Fortran ist also für die meisten > Anwendungen ziemlich hoch. Es hat IMHO schon seinen Grund, warum > allgemeine Applikations- und Systemsoftware eher nicht in Fortran > geschrieben ist und dieser Grund ist IMHO nicht der Mangel an > Fortran-Compilern. Als allgemeine Sprache war Fortran unter Informatikern nie beliebt, bis FORTRAN 77 aus verständlichen Gründen. Und danach war der Zug halt abgefahren.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-09 10:12 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <la3er8Fdm4jU1@mid.individual.net> |
| In reply to | #44612 |
Am 09.05.24 um 09:31 schrieb Thomas Koenig: >> Ich habe sehr wenig in Fortran programmiert und das ist lange her (ich >> glaube, das war noch nicht mal Fortran 77[1]), Während meiner Ausbildung habe ich für diverse Probleme FORTRAN IV verwendet. Während meiner Berufszeit war überwiegend FORTRAN 77 mit Erweiterung Strings mit variable Länge ( FOR1 ) meine bevorzugte Sprache. >> daher demonstriere ich jetzt >> vermutlich nur meine Ahnungslosigkeit, aber mein Eindruck von Fortran >> war, dass es zwar für eine kleine Klasse von (hauptsächlich numerischen) >> Problemen sehr gut geeignet ist, aber alles andere ist sehr umständlich. Bei diverse Problem ist sie auch jetzt noch C überlegen. > Das ist tatsächlich ein Problem der Sprache, es größtenteils ein > Image-Problem. > FORTRAN 77 hatte tatsächlich einige Eigenschaften, die den Umgang > damit umständlich machten: Lochkartenformat, keine dynamische > Speicherverwaltung, keine structs, keine Pointer (wenn man sie > denn braucht, für Datenstrukturen), außer der DO-Loop und dem > IF/THEN/ELSE/ENDIF keine strukturierten Kontrollstrukturen, kein > Checken von Argumentlisten, record-orientierte I/O (wenn auch sehr > mächtig), globale Variablen über die gefürchteten COMMON-Blöcke, > aber dafür mehrdimensionale Arrays. Und Großbuchstaben. Und (wie Basic) Ziffern statt Namen bei Sprungzielen. Sie stammt wie COBOL und LISP aus der Lochkartenzeit, in der einige computer keine Kleinbuchstaben konnten. Die CDC 33000 hatte ein character nur 6 Bit. LISP hatte sich schon von Lochkarten verabschiedet. > Fortran 90 (etwas irreführend Ende 1991 herausgekommen, also jetzt > 32 immerhin Jahre alt, das ist schon eine lange Zeit...) hat das > grundlegend geändert: Fortran 90 habe ich nicht mehr verwendet. % statt Punkt bei Strukturen behindert Lesbarkeit. Zumal ich 1990 auch schon C kannte, wo es keine software Einschränkung bei String Länge gab. > 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, 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 > Seit Fortran 95 (und einem TR kurz darauf) kamen auch > noch allocatable variables dazu, mit denen man dynamische > Speicherverwaltung einschließlich automatischer Deallokierung > machen kann, ohne sich drum kümmern zu müssen. Der Fortran 77 Spezial compiler FOR1 konnte nach meiner Erinnerung auch dynamische arrays. > Als allgemeine Sprache war Fortran unter Informatikern nie beliebt, > bis FORTRAN 77 aus verständlichen Gründen. Und danach war der Zug > halt abgefahren. Das hängt vom Aufgabenbereich ab. FORTRAN ist Spitze bei Numerik + Geschwindigkeit. C, auch wenn es nicht zum Sprachstandard gehört, bei gewissen Systemaufgaben wie Datei header. Python ist für mich bei Textverarbeitung so bequem wie bei keiner anderen Programmiersprache. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-09 13:03 +0000 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <v1ihid$lpo2$1@dont-email.me> |
| In reply to | #44614 |
Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb: > Am 09.05.24 um 09:31 schrieb Thomas Koenig: > >>> Ich habe sehr wenig in Fortran programmiert und das ist lange her (ich >>> glaube, das war noch nicht mal Fortran 77[1]), > > Während meiner Ausbildung habe ich > für diverse Probleme FORTRAN IV verwendet. > Während meiner Berufszeit war überwiegend FORTRAN 77 > mit Erweiterung Strings mit variable Länge ( FOR1 ) > meine bevorzugte Sprache. Hmm... scheint für BS2000 zu sein, korrekt? Ist aber auch bei Fortran 77 stehengeblieben, genauso wie VS Fortran für die IBM-Systeme. [...] > Und Großbuchstaben. War kaum ein Problem, in der Praxis. > Und (wie Basic) Ziffern statt Namen bei Sprungzielen. > Sie stammt wie COBOL und LISP aus der Lochkartenzeit, > in der einige computer keine Kleinbuchstaben konnten. FORTRAN wurde für die IBM 704 entwickelt, das war ein 36-bit-System mit 6-bit-Characters. Daher auch die Beschränkung auf 72 gültige Spalten: Mehr konnte der Lochkartenleser der 704 nicht auf einmal einlesen, weil er den Akkumulator und das MQ-Register zeilenweise vollgeschrieben hat. > 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. [...] >> Fortran 90 (etwas irreführend Ende 1991 herausgekommen, also jetzt >> 32 immerhin Jahre alt, das ist schon eine lange Zeit...) hat das >> grundlegend geändert: > > Fortran 90 habe ich nicht mehr verwendet. > % statt Punkt bei Strukturen behindert Lesbarkeit. Das ist einfach Gewöhnung. > Zumal ich 1990 auch schon C kannte, > wo es keine software Einschränkung bei String Länge gab. String-Handling war in Fortran tatsächlich etwas umständlich und ist auch heute, mit allocatable Characters, noch nicht ganz 100% zufriedenstellend (aber es kann alles, was man braucht). > >> 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... > 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 Nie richtig standardisiert, aber weit verbreitet. Seit Fortran 90 geht es viel besser, dan kann man z.B. eine REAL-Zahl mit mindestens 12 gültigen Stellen anfordern. > >> Als allgemeine Sprache war Fortran unter Informatikern nie beliebt, >> bis FORTRAN 77 aus verständlichen Gründen. Und danach war der Zug >> halt abgefahren. > > Das hängt vom Aufgabenbereich ab. > FORTRAN ist Spitze bei Numerik + Geschwindigkeit. > C, auch wenn es nicht zum Sprachstandard gehört, > bei gewissen Systemaufgaben wie Datei header. Vor allem natürlich, wenn die Interfaces in C definiert sind. Aber seit Fortran 2003 existiert auch in ein in der Norm defniiertes C-Interface. > Python ist für mich bei Textverarbeitung so bequem > wie bei keiner anderen Programmiersprache. Ich bin kein Pyhton-Freund; ich nehme typischerweise Perl (oder, seit neuestem, Julia).
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-09 16:03 +0200 |
| Subject | Re: Accidental Complexity von Programmiersprachen |
| Message-ID | <la43dfFglnrU1@mid.individual.net> |
| In reply to | #44625 |
Am 09.05.24 um 15:03 schrieb Thomas Koenig: > Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb: >> Am 09.05.24 um 09:31 schrieb Thomas Koenig: >> >>>> Ich habe sehr wenig in Fortran programmiert und das ist lange her (ich >>>> glaube, das war noch nicht mal Fortran 77[1]), >> >> Während meiner Ausbildung habe ich >> für diverse Probleme FORTRAN IV verwendet. >> Während meiner Berufszeit war überwiegend FORTRAN 77 >> mit Erweiterung Strings mit variable Länge ( FOR1 ) >> meine bevorzugte Sprache. > > Hmm... scheint für BS2000 zu sein, korrekt? Ja. Beruflich habe ich fast nur mit BS2000 gearbeitet. Ein wenig mit Unix ( Sinix ) und bei Verwaltungsaufgaben etwas windows. > Ist aber auch > bei Fortran 77 stehengeblieben, genauso wie VS Fortran für die > IBM-Systeme. Bis auf Erweiterungen wie strings mit variabler Länge. >> Und Großbuchstaben. > > War kaum ein Problem, in der Praxis. Namen und Schlüsselwörter mit Kleinbuchstaben kann ich leichter lesen. >> Und (wie Basic) Ziffern statt Namen bei Sprungzielen. >> Sie stammt wie COBOL und LISP aus der Lochkartenzeit, >> in der einige computer keine Kleinbuchstaben konnten. > > FORTRAN wurde für die IBM 704 entwickelt, das war ein 36-bit-System > mit 6-bit-Characters. Daher auch die Beschränkung auf 72 gültige > Spalten: Mehr konnte der Lochkartenleser der 704 nicht auf einmal > einlesen, weil er den Akkumulator und das MQ-Register zeilenweise > vollgeschrieben hat. > >> 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. Die CDC 3300 hatte 24 Bit Wörter; 4 Buchstaben a 6 Bit. Und 15 Bit Wortadressen. Und ich brauchte Benutzungserlaubnis. die ich dank Kurse erhielt. Mein 12 bit computer ( IM6100, PDP8 kompatibel ) hat nicht funktioniert. >> Fortran 90 habe ich nicht mehr verwendet. >> % statt Punkt bei Strukturen behindert Lesbarkeit. > Das ist einfach Gewöhnung. % stört bei mir das Lesen. ( @ in Perl auch ) >> Zumal ich 1990 auch schon C kannte, >> wo es keine software Einschränkung bei String Länge gab. > > String-Handling war in Fortran tatsächlich etwas umständlich > und ist auch heute, mit allocatable Characters, noch > nicht ganz 100% zufriedenstellend (aber es kann alles, > was man braucht). Die strings mir variabler Länge in Fortann 77 von Siemens (FOR1) waren sehr bequem. >>> 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. Wie C in C++. > 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... Python 2 war noch zur relativen Frühzeit von Python. Python 3 ist schon 15 Jahre her. >> FORTRAN ist Spitze bei Numerik + Geschwindigkeit. >> C, auch wenn es nicht zum Sprachstandard gehört, >> bei gewissen Systemaufgaben wie Datei header. > > Vor allem natürlich, wenn die Interfaces in C definiert sind. > Aber seit Fortran 2003 existiert auch in ein in der Norm > definiertes C-Interface. Bei Siemens gab es auch Sprachmix verschiedener Sprachen mit gewissen Einschränkungen durch gemeinsame Unterprogrammschnittstelle. >> Python ist für mich bei Textverarbeitung so bequem >> wie bei keiner anderen Programmiersprache. > Ich bin kein Python-Freund; ich nehme typischerweise Perl > (oder, seit neuestem, Julia). Ich fand Python besser lesbar als Perl. Was kann Julia, was Python nicht kann? Auf dem PC 8 SuSE 15.0) habe ich Julia Version 0.6.2 (2017-12-13) Wenn ich bei Julia das lästige end weglasse, scheint es mir bei normalen Anweisungen wie Python auszusehen. Wenn ich meine aktiven eigenen Programme abschätze, habe ich ca 90% Python3, ca 9% C, ca 5‰ jeweils Javascript und bash. Unter den "ich will vermeiden" Sprachen fallen bei mir Java, Pascal, Ada, COBOL, Perl, Algol*. Unter den "eventuell verwenden" Sprachen am ehesten Rust. Dann wären noch Lisp, Lua, Haskell, C++ Kandidaten Eventuell²: Julia, R, Ruby Meine Lisp (1.5) Erfahrung liegt Jahrzehnte zurück. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web