Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #49977 > unrolled thread
| Started by | "F. W." <me@home.invalid> |
|---|---|
| First post | 2025-05-16 07:53 +0200 |
| Last post | 2025-05-20 07:57 +0200 |
| Articles | 20 on this page of 184 — 17 participants |
Back to article view | Back to de.alt.folklore.computer
COMAL "F. W." <me@home.invalid> - 2025-05-16 07:53 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-16 10:45 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 07:59 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-19 09:36 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 11:27 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 11:40 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-19 14:59 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 15:58 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-19 16:37 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-05-31 10:16 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-01 17:19 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-01 23:57 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-02 08:16 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-02 12:56 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-02 17:10 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-04 11:54 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-04 13:16 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-08 22:19 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-09 09:47 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-09 16:38 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-09 12:06 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-09 14:59 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-09 14:02 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-10 08:08 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 09:36 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-10 12:10 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 18:41 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 21:03 +0000
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-06-11 07:01 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 18:37 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-10 18:49 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 20:52 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 07:22 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 05:51 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 08:15 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-11 08:04 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 11:41 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-06-12 12:47 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 16:50 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 17:13 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-12 07:41 +0200
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-12 08:22 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 19:41 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 20:00 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-13 08:20 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 16:55 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 10:45 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 09:24 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 11:29 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 09:36 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 11:41 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-14 14:37 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 14:41 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-14 15:01 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 13:25 +0000
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-06-14 21:20 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-14 21:52 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 07:42 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 16:13 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 00:49 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-15 11:09 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 17:01 +0200
Re: COMAL "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-06-16 08:56 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-17 07:03 +0000
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-06-14 21:20 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-14 21:58 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 00:51 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:40 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:29 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:16 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-17 08:44 +0000
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-14 14:34 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 13:23 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 13:05 +0000
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-15 13:17 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 13:43 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-15 16:52 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 15:32 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-15 21:25 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-16 07:00 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-16 18:38 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 19:23 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 18:08 +0000
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 21:31 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-16 06:56 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-15 21:32 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 22:22 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-16 06:58 +0000
Re: COMAL Peter Müller <invalid@invalid.invalid> - 2025-06-16 19:13 +0200
Re: COMAL Stefan Reuther <stefan.news@arcor.de> - 2025-06-16 18:25 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 17:02 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-06-15 19:08 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:58 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 13:06 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 15:11 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 16:43 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 17:59 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 15:12 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 12:53 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 15:14 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 16:35 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 18:00 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-10 19:25 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 20:06 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-06-12 12:41 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-12 13:26 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-12 20:17 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-06-12 20:56 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-12 21:26 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-06-13 06:48 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 19:44 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-13 08:32 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-06-13 09:49 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-13 10:43 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-13 10:47 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 06:18 +0000
OOP (was: COMAL) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 18:57 +0200
Re: OOP Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 21:12 +0000
Re: OOP "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 12:33 +0200
Re: OOP Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-13 11:25 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 20:09 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-19 22:19 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 23:40 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-20 16:41 +0000
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-20 16:49 +0000
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-20 20:33 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-20 20:54 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-20 19:44 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-20 20:29 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-20 21:33 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-21 17:43 +0000
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-21 20:52 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-21 21:37 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-21 22:55 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 09:17 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 09:42 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 09:46 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 10:37 +0200
Re: COMAL Christian Corti <use@reply.to> - 2025-05-22 11:15 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 11:52 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 12:35 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 13:08 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 15:27 +0200
Re: COMAL Christian Corti <use@reply.to> - 2025-05-22 16:14 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 14:11 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-31 15:38 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 09:44 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 09:48 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 10:11 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 10:12 +0200
Re: COMAL "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-05-22 08:24 +0000
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 10:38 +0200
Re: COMAL Stefan Reuther <stefan.news@arcor.de> - 2025-05-22 18:45 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-22 10:22 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 09:16 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 08:25 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-05-22 11:34 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 12:36 +0200
Re: COMAL "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-05-22 12:43 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 15:13 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 16:36 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 16:51 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 17:18 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-05-22 20:31 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-23 03:54 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-23 13:56 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-23 15:04 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-23 16:23 +0200
Re: COMAL Christian Corti <use@reply.to> - 2025-05-26 11:59 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-23 11:29 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-26 09:27 +0200
Re: COMAL Stefan Reuther <stefan.news@arcor.de> - 2025-05-20 18:47 +0200
Re: COMAL Andreas Eder <a_eder_muc@web.de> - 2025-05-27 21:56 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-05-31 13:19 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-16 11:53 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 08:01 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 08:14 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 08:51 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 09:05 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-19 09:02 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 09:20 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 19:59 +0200
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-05-20 07:48 +0200
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-05-20 07:57 +0200
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-16 18:38 +0200 |
| Message-ID | <slrn1050i4s.3r7m0.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50811 |
On 2025-06-16 09:00, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>> On 2025-06-15 17:32, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>>>>> Das *Ergebnis* des Compilerlaufs sollte hingegen möglichst performant
>>>>> sein.
>>>>
>>>> Das ist hingegen oft nicht so wichtig.
>>>
>>> Für Fortran sehr häufig schon.
>>
>> Ja, Fortran wird hauptsächlich für numerischen Code eingesetzt, da ist
>> die CPU das Bottleneck. Und die will man dann auch maximal ausnützen,
>> vor allem, was das SIMD-Zeug betrifft.
>
> Tatsächlich ist es sehr häufig der Speicherzugriff das Bottleneck,
> oder auch der Overhead zur Parallelisierung.
Ja, mit "CPU" meinte ich alles, was das OS als CPU-Zeit ansieht, das
inkludiert Memory-Zugriffe. Und du hast natürlich recht, dass auch hier
ein Compiler einen großen Unterschied machen kann.
>> Die meisten Programme verbringen hingegen den Großteil ihrer Zeit mit
>> Warten. Das kann der Compiler nicht optimieren. (Es kann trotzdem
>> sinnvoll sein, den nicht-wartenden Teil zu optimieren, z.B. um den
>> Stromverbrauch zu minimieren oder um möglichst viele Instanzen des Codes
>> auf einer Maschine laufen zu lassen, aber in vielen Fällen macht das
>> keinen Unterschied.)
>
> Oder halt um die Reaktionszeit niedrig zu halten, damit der Benutzer
> sich nicht zum Handkäs ärgert...
Ich meinte mit Warten nicht Warten auf den User, sondern auf andere
Systeme. Wenn die Reaktionszeit zu 50% aus HTTP-Querys an andere
(Micro-)Services und 40% aus Datenbank-Abfragen besteht, kann der
Compiler die Reaktionszeit um maximal 10% verbessern.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-15 19:23 +0200 |
| Message-ID | <mb8dsrFeblU4@mid.individual.net> |
| In reply to | #50782 |
Peter J. Holzer, 2025-06-15 16:52: > On 2025-06-15 15:17, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote: >> On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: >>> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >>> performance ein zentraler Gedanke, >> >> Wieso eigentlich? >> >> Gerade Compiler zählen zu den Dingen, bei denen für mich Performance >> so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange >> brauchen, dann gehe ich halt einen Kaffee trinken. > > Naja, das macht für die Arbeitweise schon einen Unterschied. Der > Cobol-Compiler, den ich in den 80er-Jahren verwendet habe, hat für einen > Compiler-Lauf (das Programm war nicht ganz klein) gute 20 Minuten > gebraucht. In der Zeit habe ich immer die nächsten 10 Seiten von Das war aber auch der Hardware geschuldet. Wenn ich anfang der 1990er auf meinem Atari 1040STe eine neue Version von "Thing" mit Pure C komplett neu gebaut habe, hat das auch eine gute Weile gebraucht. Heute in einem Emulator ohne Geschwindigkeitsbegrenzung ist das eine Sache von Sekunden. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-15 18:08 +0000 |
| Message-ID | <102n26d$1257s$1@dont-email.me> |
| In reply to | #50795 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > Peter J. Holzer, 2025-06-15 16:52: > >> On 2025-06-15 15:17, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote: >>> On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: >>>> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >>>> performance ein zentraler Gedanke, >>> >>> Wieso eigentlich? >>> >>> Gerade Compiler zählen zu den Dingen, bei denen für mich Performance >>> so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange >>> brauchen, dann gehe ich halt einen Kaffee trinken. >> >> Naja, das macht für die Arbeitweise schon einen Unterschied. Der >> Cobol-Compiler, den ich in den 80er-Jahren verwendet habe, hat für einen >> Compiler-Lauf (das Programm war nicht ganz klein) gute 20 Minuten >> gebraucht. In der Zeit habe ich immer die nächsten 10 Seiten von > > Das war aber auch der Hardware geschuldet. Wenn ich anfang der 1990er > auf meinem Atari 1040STe eine neue Version von "Thing" mit Pure C > komplett neu gebaut habe, hat das auch eine gute Weile gebraucht. Heute > in einem Emulator ohne Geschwindigkeitsbegrenzung ist das eine Sache von > Sekunden. Ein wesentlicher Treiber für die Module in C++ war m.W. Facebook. Die hatten zu lange Kompilierzeiten, weil sie alles in den Headern hatten, und die precompiled header waren ihnen auch nicht schnell genug.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-15 21:31 +0200 |
| Message-ID | <mb8lclF1k8mU3@mid.individual.net> |
| In reply to | #50798 |
Thomas Koenig, 2025-06-15 20:08: [...] > Ein wesentlicher Treiber für die Module in C++ war > m.W. Facebook. Die hatten zu lange Kompilierzeiten, weil sie alles > in den Headern hatten, und die precompiled header waren ihnen auch > nicht schnell genug. Hat Facebook seine Software nicht in PHP geschrieben? Aus der Ecke kam doch auch die "HipHop Virtual Machine" für PHP: <https://en.wikipedia.org/wiki/HHVM> Zitat: "HHVM was created as the successor to the HipHop for PHP (HPHPc) PHP execution engine, which is a PHP-to-C++ transpiler also created by Facebook." -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-16 06:56 +0000 |
| Message-ID | <102of70$1fjfk$1@dont-email.me> |
| In reply to | #50800 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > Thomas Koenig, 2025-06-15 20:08: > > [...] >> Ein wesentlicher Treiber für die Module in C++ war >> m.W. Facebook. Die hatten zu lange Kompilierzeiten, weil sie alles >> in den Headern hatten, und die precompiled header waren ihnen auch >> nicht schnell genug. > > Hat Facebook seine Software nicht in PHP geschrieben? Ich würde mal vermuten, nicht alle :-) >Aus der Ecke kam > doch auch die "HipHop Virtual Machine" für PHP: > ><https://en.wikipedia.org/wiki/HHVM> > > Zitat: > > "HHVM was created as the successor to the HipHop for PHP (HPHPc) PHP > execution engine, which is a PHP-to-C++ transpiler also created by > Facebook." Und selbst wenn, dann sind lange Kompilierzeiten vermutlich störend. Ein krasses Beispiel ist clang. Wenn man da einen Debug-build macht, auf gar keinen Fall mit parallelem Make, wenn man weniger als 64 GB Speicher hat. Ich weiß nicht, was der Linker macht, aber es ist atemberaubend, sich das mit htop anzuschauen.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-15 21:32 +0200 |
| Message-ID | <slrn104u7u6.2polj.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50795 |
On 2025-06-15 19:23, Arno Welzel <usenet@arnowelzel.de> wrote:
> Peter J. Holzer, 2025-06-15 16:52:
>> On 2025-06-15 15:17, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
>>> On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote:
>>>> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high
>>>> performance ein zentraler Gedanke,
>>>
>>> Wieso eigentlich?
>>>
>>> Gerade Compiler zählen zu den Dingen, bei denen für mich Performance
>>> so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange
>>> brauchen, dann gehe ich halt einen Kaffee trinken.
>>
>> Naja, das macht für die Arbeitweise schon einen Unterschied. Der
>> Cobol-Compiler, den ich in den 80er-Jahren verwendet habe, hat für einen
>> Compiler-Lauf (das Programm war nicht ganz klein) gute 20 Minuten
>> gebraucht. In der Zeit habe ich immer die nächsten 10 Seiten von
>
> Das war aber auch der Hardware geschuldet.
Klar. Der Compiler von damals würde das Programm auf heutiger Hardware
wahrscheinlich in 1 bis 2 Sekunden kompilieren.
Ein heutiger Compiler wäre wahrscheinlich nicht mehr so schnell, würde
dafür aber besseren Code produzieren.
Vor allem aber wäre ein heutiges Programm aber auch länger (obwohl der
ausgedruckte Source-Code damals schon recht beeindruckend aussah: War
ein netter Stapel ;-)).
Software passt sich halt immer der Hardware an. Wenn die Hardware
schneller wird, wird die Software komplexer, bis wieder das gleiche
Level an Ungeduld beim User eintritt.
Lange Compile-Zeiten gehören keineswegs der Vergangenheit an. Vor allem
von C++-Programmierern höre ich da immer Klagen.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-15 22:22 +0200 |
| Message-ID | <mb8oclF22deU2@mid.individual.net> |
| In reply to | #50801 |
Peter J. Holzer, 2025-06-15 21:32: [...] > Lange Compile-Zeiten gehören keineswegs der Vergangenheit an. Vor allem > von C++-Programmierern höre ich da immer Klagen. Ja - deswegen sollte man sich *vor* der Umsetzung eines Projekts immer fragen, ob es unbedingt C++ sein muss oder man nicht mit mit "langsamen" interpretierten Sprachen mit JIT nicht besser bedient ist, wenn man pro Tag in Summe einige Stunden an Compile-Zeit spart einem größeren Team. Ich erinnere mich auch an ein Projekt, wo IncrediBuild genutzt wurde, um C++-Compiler auf vielen Maschinen gleichzeitig laufen zu lassen, damit die Build-Zeit von 2-3 Stunden auf etwa 10-15 Minuten reduziert werden konnte. Der Flaschenhals war da dann eher das Netzwerk. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-16 06:58 +0000 |
| Message-ID | <102of9o$1fjfk$2@dont-email.me> |
| In reply to | #50802 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > Peter J. Holzer, 2025-06-15 21:32: > > [...] >> Lange Compile-Zeiten gehören keineswegs der Vergangenheit an. Vor allem >> von C++-Programmierern höre ich da immer Klagen. > > Ja - deswegen sollte man sich *vor* der Umsetzung eines Projekts immer > fragen, ob es unbedingt C++ sein muss oder man nicht mit mit "langsamen" > interpretierten Sprachen mit JIT nicht besser bedient ist, wenn man pro > Tag in Summe einige Stunden an Compile-Zeit spart einem größeren Team. Es gibt auch genung andere objektorientierte Sprachen, die das problem nicht in dem Ausmaß haben. > Ich erinnere mich auch an ein Projekt, wo IncrediBuild genutzt wurde, um > C++-Compiler auf vielen Maschinen gleichzeitig laufen zu lassen, damit > die Build-Zeit von 2-3 Stunden auf etwa 10-15 Minuten reduziert werden > konnte. Der Flaschenhals war da dann eher das Netzwerk. > Wenn's denn geht... AFAIK hat noch niemand ein paralleles LTO hingekriegt, und das braucht man nun mal für devirtualization.
[toc] | [prev] | [next] | [standalone]
| From | Peter Müller <invalid@invalid.invalid> |
|---|---|
| Date | 2025-06-16 19:13 +0200 |
| Message-ID | <mbb1liFdv70U1@mid.individual.net> |
| In reply to | #50802 |
> Ich bin ein Desktop-GUI-Freund. Ich denke, ich nutze Python vor > allem, weil es eine portable GUI-Bibliothek (Implementationen > gibt es auch für Android!) in der Standardbibliothek hat. > > Wenn es für C++ so etwas gäbe, würde ich mehr in C++ machen. Qt? Gibt es auch fürAndroid
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-06-16 18:25 +0200 |
| Message-ID | <102pnim.4og.1@stefan.msgid.phost.de> |
| In reply to | #50801 |
Am 15.06.2025 um 21:32 schrieb Peter J. Holzer: > Software passt sich halt immer der Hardware an. Wenn die Hardware > schneller wird, wird die Software komplexer, bis wieder das gleiche > Level an Ungeduld beim User eintritt. > > Lange Compile-Zeiten gehören keineswegs der Vergangenheit an. Vor allem > von C++-Programmierern höre ich da immer Klagen. Ich baue aktuell immer mal ein AOSP. Das (generierte) Buildscript hat 2 Gigabyte, der Generator braucht fünf Minuten und 30+ GB RAM. Natürlich würde ich mich freuen, wenn das schneller ginge. Dafür kann ich _irgendeine_ Datei ändern und er schraubt mir ein korrektes System-Image zusammen. Und wenn man dann berücksichtigt, dass das gut sechsstellig Dateien sind, die da auf Aktualität geprüft werden, dann ist's im Vergleich gar nicht mehr so langsam. Und Projekte dieser Dimension hat man halt früher nicht gebaut. Ich behaupte mal, mein Turbo-Pascal-Projekt aus den 90ern mit ~120 Modulen und ca. 1.3 MByte Code war für seine Zeit schon ein Gigant. Viel mehr schafft nämlich der Compiler nicht. Aber er ist schnell. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-15 17:02 +0200 |
| Message-ID | <mb85krFtobhU2@mid.individual.net> |
| In reply to | #50768 |
Stefan Froehlich, 2025-06-15 15:17: > On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: >> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >> performance ein zentraler Gedanke, > > Wieso eigentlich? > > Gerade Compiler zählen zu den Dingen, bei denen für mich Performance > so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange > brauchen, dann gehe ich halt einen Kaffee trinken. Das *Ergebnis* > des Compilerlaufs sollte hingegen möglichst performant sein. Eben - genau darum wird's ja auch gehen, wenn man von einem Fortran-Compiler spricht. Aber das ist alles Wissen, seit Jahrzehnten bekannt ist. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2025-06-15 19:08 +0200 |
| Message-ID | <102munc$1mble$1@news1.tnib.de> |
| In reply to | #50768 |
Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote: >On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: >> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >> performance ein zentraler Gedanke, > >Wieso eigentlich? > >Gerade Compiler zählen zu den Dingen, bei denen für mich Performance >so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange >brauchen, dann gehe ich halt einen Kaffee trinken. Das *Ergebnis* >des Compilerlaufs sollte hingegen möglichst performant sein. xkcd 303? Grüße Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-06-17 10:58 +0200 |
| Message-ID | <mbcp2gFmq61U1@mid.individual.net> |
| In reply to | #50768 |
Am 15.06.25 um 15:17 schrieb Stefan Froehlich: > On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: >> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >> performance ein zentraler Gedanke, > > Wieso eigentlich? > > Gerade Compiler zählen zu den Dingen, bei denen für mich Performance > so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange > brauchen, dann gehe ich halt einen Kaffee trinken. Das *Ergebnis* > des Compilerlaufs sollte hingegen möglichst performant sein. Ein Teil der Programmierarbeit besteht aus Fehlersuche. Und wenn da lange Zeiten wegen Übersetzungen entstehen.. Bei eigenen Programme auf aktuelle PCs ist die Übersetzungszeit heutzutage kaum bemerkbar. Um ca 1980 hat eine Gesamtübersetzung von der software, für die ich zuständig war, ca 2 Stunden gedauert. Mit noch mehr Stunden Wartezeit für die Auslieferung des Ergebnisses auf Papier. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-11 13:06 +0200 |
| Message-ID | <slrn104iopk.1n48v.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50646 |
On 2025-06-11 07:51, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Und eine Addition? Wenn ich einen Ausdruck a + b habe, zu
> welchem der beiden Terme soll denn die Methode gehören?
ACK. Das ist IMHO ein prinzipielles Problem des objekt-orientierten
Paradigmas: Es sind halt immer die Methoden *eines* Objekts.
Diverse Sprachen haben da natürlich Workarounds.
Python z.B. schaut bei a + b zuerst, on a.__add__ existiert, dann ob
b.__radd__ existiert.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-11 15:11 +0200 |
| Message-ID | <matdjtF4en4U1@mid.individual.net> |
| In reply to | #50653 |
Am 11.06.2025 um 13:06 schrieb Peter J. Holzer: > On 2025-06-11 07:51, Thomas Koenig <tkoenig@netcologne.de> wrote: >> Und eine Addition? Wenn ich einen Ausdruck a + b habe, zu >> welchem der beiden Terme soll denn die Methode gehören? > > ACK. Das ist IMHO ein prinzipielles Problem des objekt-orientierten > Paradigmas: Es sind halt immer die Methoden *eines* Objekts. > Und wo siehst Du da das Problem?
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-11 16:43 +0200 |
| Message-ID | <slrn104j5fo.1vdng.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50657 |
On 2025-06-11 15:11, Eric Bruecklmeier <u@5i7.de> wrote:
> Am 11.06.2025 um 13:06 schrieb Peter J. Holzer:
>> On 2025-06-11 07:51, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>> Und eine Addition? Wenn ich einen Ausdruck a + b habe, zu
>>> welchem der beiden Terme soll denn die Methode gehören?
>>
>> ACK. Das ist IMHO ein prinzipielles Problem des objekt-orientierten
>> Paradigmas: Es sind halt immer die Methoden *eines* Objekts.
>>
>
> Und wo siehst Du da das Problem?
>
Es macht eine Situation, die eigentlich symmetrisch ist, künstlich
asymmetrisch. Gut, das kann man jetzt als rein ästhetisches Problem
sehen, das in der Praxis keine Relevanz hat, aber es ist zumindest
etwas, wo der Programmierer eine willkürliche Entscheidung treffen muss,
und potentiell eine Quelle für Verwirrung.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-11 17:59 +0200 |
| Message-ID | <matneuF6pdmU1@mid.individual.net> |
| In reply to | #50661 |
Am 11.06.2025 um 16:43 schrieb Peter J. Holzer: > On 2025-06-11 15:11, Eric Bruecklmeier <u@5i7.de> wrote: >> Am 11.06.2025 um 13:06 schrieb Peter J. Holzer: >>> On 2025-06-11 07:51, Thomas Koenig <tkoenig@netcologne.de> wrote: >>>> Und eine Addition? Wenn ich einen Ausdruck a + b habe, zu >>>> welchem der beiden Terme soll denn die Methode gehören? >>> >>> ACK. Das ist IMHO ein prinzipielles Problem des objekt-orientierten >>> Paradigmas: Es sind halt immer die Methoden *eines* Objekts. >>> >> >> Und wo siehst Du da das Problem? >> > > Es macht eine Situation, die eigentlich symmetrisch ist, künstlich > asymmetrisch. Gut, das kann man jetzt als rein ästhetisches Problem > sehen, das in der Praxis keine Relevanz hat, aber es ist zumindest > etwas, wo der Programmierer eine willkürliche Entscheidung treffen muss, > und potentiell eine Quelle für Verwirrung. Wenn zwei völlig verschiedene Klassen beteiligt sind, muß die Situation nicht mehr zwingend symmetrisch sein. Es gibt einen gewaltigen Unterschied zwischen 5 * 'abcd' und 'abcd' * 5
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-11 15:12 +0200 |
| Message-ID | <matdlpF4en4U2@mid.individual.net> |
| In reply to | #50653 |
Am 11.06.2025 um 14:24 schrieb Stefan Ram: > "Peter J. Holzer" <hjp-usenet4@hjp.at> schrieb oder zitierte: >> On 2025-06-11 07:51, Thomas Koenig <tkoenig@netcologne.de> wrote: >>> Und eine Addition? Wenn ich einen Ausdruck a + b habe, zu >>> welchem der beiden Terme soll denn die Methode gehören? >> ACK. Das ist IMHO ein prinzipielles Problem des objekt-orientierten >> Paradigmas: Es sind halt immer die Methoden *eines* Objekts. > > Dies könnte man dadurch lösen, daß die Sprache hier zunächst a > und b zu einem Paarobjekt der Klasse Pair(A, B) zusammenfaßt, > wobei A die Klasse von a ist und B die von b. > > Methoden für Paarobjekte werden dann in Paarklassen definiert: Schau Dir mal in Ruby #coerce an!
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-11 12:53 +0200 |
| Message-ID | <slrn104io17.1n48v.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50645 |
On 2025-06-11 07:22, Eric Bruecklmeier <u@5i7.de> wrote:
> Am 10.06.2025 um 20:52 schrieb Peter J. Holzer:
>> On 2025-06-10 18:49, Eric Bruecklmeier <u@5i7.de> wrote:
>>> Am 10.06.2025 um 18:37 schrieb Peter J. Holzer:
>>>> On 2025-06-10 08:08, Eric Bruecklmeier <nil@nil.nil> wrote:
>>>>> Am 09.06.2025 um 16:02 schrieb Thomas Koenig:
>>>>>> Eric Bruecklmeier <u@5i7.de> schrieb:
>>>>>>> Am 09.06.2025 um 14:06 schrieb Thomas Koenig:
>>>>>>>> Man kann natürlich auch ohne programmieren, aber für bestimmte
>>>>>>>> Aufgaben ist Objektorientierung eine "natürliche" Sache.
>>>>>>>
>>>>>>> Exakt so ist es! Unter OO programmiert man so, wie man ohnehin
>>>>>>> denken würde.
>>>>>>
>>>>>> Die Aussage ist jetzt ein bisschen schräg. Wer ist "man"?
>>>>>> Was heißt "ohnehin"? Ohne was? Ohne vorher mal irgendetwas
>>>>>> von einer anderen Programmiersprache gehört zu haben? Dann
>>>>>> wird man auch mit C++ Probleme haben, ohne mit dem Konzept
>>>>>> von Variablen und Zuweisungen was anfangen zu können.
>>>>>
>>>>> Weiter oben im Thread hatte ich schonmal dargelegt, was ich damit meine:
>>>>>
>>>>> Wenn man in RL einen Gegenstand benutzen möchte, dann nutzt man eine
>>>>> "Methode" dieses Gegenstandes und schickt ihn nicht an eine "Funktion".
>>>>>
>>>>> Also: Auto.fahre statt Fahre(Auto)
>>>>
>>>> Gerade das halte ich für ein schlechtes Beispiel, denn "fahren" ist
>>>> etwas, das ich mit dem Auto mache.
>>>
>>> Genau aus diesem Grund ist es ein prägnantes Beispiel. Ich nutze eine
>>> Funktion des Objektes und übergebe nicht mein Objekt an irgendeine frei
>>> schwebende Funktion.
>>
>> Ich glaube, ich sehe da einen Unterschied im geistigen Modell, das wir
>> beide bei imperativen Sprachen haben: Für mich wird die Prozedur auf die
>> Parameter *angewendet*.
>> Du hingegen siehst die Prozedur als irgendeine freischwebende Entität,
>> an die das Auto geschickt wird. Ich vermute, dass Du da das
>> Message-Passing-Modell der OOP verinnerlicht hast.
>>
>> Ich gebe Dir vollkommen recht, dass die Vorstellung, das Auto würde an
>> die Prozedur geschickt, absurd ist. Aber die Anwendung der Prozedur
>> (wenn Du so willst, den Algorithmus, den man in der Fahrschule gelernt
>> hat) auf das Auto passt IMHO gut.
>
> Da wird es dann aber schon wieder komisch: Die selbe Prozedur fahren
> wird auf Skateboards und Autos angewandt? Das überzeugt mich nicht.
Genau das ist der Knackpunkt: Wenn ich mit einen Skateboard fahre, muss
ich *als Fahrer* sehr unterschiedliche Dinge tun als wenn ich mit dem
Auto fahre. Diese Komplexität muss also dem Fahrer zugeordnet sein,
nicht dem Fahrzeug. Der Fahrer muss gelernt haben, ein Auto und ein
Skateboard zu fahren, und wenn er ein Einrad fahren möchte, muss er das
auch lernen und kann nicht einfach einrad.fahre() aufrufen, und das
Einrad macht dann schon das Richtige.
Ein gutes Beispiel für eine Methode eines Fahrzeugs wäre IMHO z.B.
.bremse. Was der User macht, ist immer gleich (von Details wie Hebel
oder Pedal abgesehen), der erwünschte Effekt auch (das Fahrzeug wird
langsamer), aber was dazwischen ist, kann je nach Fahrzeug sehr
unterschiedlich sein; Das Fahrzeug kann Felgen- Trommel- oder
Scheibenbremsen haben oder einen rekuperierenden Elektromotor. Die
Übertragung kann über Seile, ein Gestänge, hydraulisch, pneumatisch oder
elektrisch erfolgen. Es kann ein ABS geben. Etcetera u. dergl.
All das hängt nur vom Fahrzeug ab und wird daher sinnvollerweise in
einer Methode es Fahrzeugs implementiert.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-11 15:14 +0200 |
| Message-ID | <matdp7F4en4U3@mid.individual.net> |
| In reply to | #50652 |
Am 11.06.2025 um 12:53 schrieb Peter J. Holzer: > On 2025-06-11 07:22, Eric Bruecklmeier <u@5i7.de> wrote: >> Am 10.06.2025 um 20:52 schrieb Peter J. Holzer: >>> On 2025-06-10 18:49, Eric Bruecklmeier <u@5i7.de> wrote: >>>> Am 10.06.2025 um 18:37 schrieb Peter J. Holzer: >>>>> On 2025-06-10 08:08, Eric Bruecklmeier <nil@nil.nil> wrote: >>>>>> Am 09.06.2025 um 16:02 schrieb Thomas Koenig: >>>>>>> Eric Bruecklmeier <u@5i7.de> schrieb: >>>>>>>> Am 09.06.2025 um 14:06 schrieb Thomas Koenig: >>>>>>>>> Man kann natürlich auch ohne programmieren, aber für bestimmte >>>>>>>>> Aufgaben ist Objektorientierung eine "natürliche" Sache. >>>>>>>> >>>>>>>> Exakt so ist es! Unter OO programmiert man so, wie man ohnehin >>>>>>>> denken würde. >>>>>>> >>>>>>> Die Aussage ist jetzt ein bisschen schräg. Wer ist "man"? >>>>>>> Was heißt "ohnehin"? Ohne was? Ohne vorher mal irgendetwas >>>>>>> von einer anderen Programmiersprache gehört zu haben? Dann >>>>>>> wird man auch mit C++ Probleme haben, ohne mit dem Konzept >>>>>>> von Variablen und Zuweisungen was anfangen zu können. >>>>>> >>>>>> Weiter oben im Thread hatte ich schonmal dargelegt, was ich damit meine: >>>>>> >>>>>> Wenn man in RL einen Gegenstand benutzen möchte, dann nutzt man eine >>>>>> "Methode" dieses Gegenstandes und schickt ihn nicht an eine "Funktion". >>>>>> >>>>>> Also: Auto.fahre statt Fahre(Auto) >>>>> >>>>> Gerade das halte ich für ein schlechtes Beispiel, denn "fahren" ist >>>>> etwas, das ich mit dem Auto mache. >>>> >>>> Genau aus diesem Grund ist es ein prägnantes Beispiel. Ich nutze eine >>>> Funktion des Objektes und übergebe nicht mein Objekt an irgendeine frei >>>> schwebende Funktion. >>> >>> Ich glaube, ich sehe da einen Unterschied im geistigen Modell, das wir >>> beide bei imperativen Sprachen haben: Für mich wird die Prozedur auf die >>> Parameter *angewendet*. >>> Du hingegen siehst die Prozedur als irgendeine freischwebende Entität, >>> an die das Auto geschickt wird. Ich vermute, dass Du da das >>> Message-Passing-Modell der OOP verinnerlicht hast. >>> >>> Ich gebe Dir vollkommen recht, dass die Vorstellung, das Auto würde an >>> die Prozedur geschickt, absurd ist. Aber die Anwendung der Prozedur >>> (wenn Du so willst, den Algorithmus, den man in der Fahrschule gelernt >>> hat) auf das Auto passt IMHO gut. >> >> Da wird es dann aber schon wieder komisch: Die selbe Prozedur fahren >> wird auf Skateboards und Autos angewandt? Das überzeugt mich nicht. > > Genau das ist der Knackpunkt: Wenn ich mit einen Skateboard fahre, muss > ich *als Fahrer* sehr unterschiedliche Dinge tun als wenn ich mit dem > Auto fahre. Ach Gottchen ja, "Fahren" ist halt schon ein bissl komplex - brich es auf Teilfunktionen runter, dann wird es sofort klar...
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web