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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-09 12:06 +0000 |
| Message-ID | <1026ing$hcmp$1@dont-email.me> |
| In reply to | #50553 |
Kay Martinen <usenet@martinen.de> schrieb: [...] > Das ist eben der Punkt. Ich habe drüber gelesen aber ich brauchte es nie > und sah für mich auch keinen Ansatz wie es dinge besser/Einfacher machen > könnte oder sollte. Ein Problem ist m.E. die merkwürdige Terminologie. Ich habe das erst so richtig verstanden, als ich mir generierten Assembler angeschaut habe. Objektorientierung ist auch (IMHO) kein Allheilmittel, aber es gibt jede Menge Beispiele, wo sie wirklich sinnvoll sind. Es ist kein Zufall, dass Objektorientierung aus der Simulation entstand. Mal angenommen, du möchtest motorisierte Fahrzeuge simulieren, die auf einer Straße fahren. Jedes Fahrzeug reagiert auf bestimmte Einflüsse von außen. Dann fängst du erstmal mit einer "Klasse" an und definierst alle Dinge, die alle Fahrzeuge gemeinsam haben. Jedes Fahrzeug kann beschleunigen, bremsen, abbiegen, überholen, eine rote Ampel sehen, einem vorherigen Fahrzeug näherkommen etc. Auf dem Level kannst du dir mal überlegen, was du denn für Einflüsse mitnehmen willst, und schreibst dafür Methoden (Nomenklatur C++, Java) oder "typebound procedures" (Fortran) auf, d.h. Unterroutinen, die die Reaktionen beschreiben. Auf dem Level könntest du z.B. schon Methoden schreiben, die die allgemeine Reaktion auf Einflüsse von außen beschreiben (rote Ampel voraus -> bremsen). Als nächstes überlegst du dir, was für Fahrzeuge es gibt - Motorräder, PKWs, Lastwagen. Die sind dann alle Spezialfälle von motorisierten Fahrzeugen und haben verschiedene Eigenschaften. Und dann kannst du das noch verfeinern. Ein Einsatzfahrzeug z.B. fährt wie ein normales Fahrzeug, wenn es Blaulicht und Sirene nicht anhat. Wenn das aber der Fall ist, dann reagiert es auf "rote Ampel" ganz anders, d.h. die Methode "rote Ampel" wird dann für die Klasse von Einsatzfahrzeugen geändert (overridden). Wenn du sowas rein prozedural programmieren willst, dann musst du entweder Informationen über Einsatzfahrzeuge da hineinziehen, so du sie gar nicht brauchst (beim Modellieren eines normalen PKWs), oder du legst dir Tabellen mit Routinen an, die dann aufgerufen werden, wenn was zu tun ist. Letzeres ist das, was der Compiler bei objektorientierten Programmiersprachen für dich tut, wenn du es ihm sagst (das sind dann die vtables). Man kann natürlich auch ohne programmieren, aber für bestimmte Aufgaben ist Objektorientierung eine "natürliche" Sache.
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-09 14:59 +0200 |
| Message-ID | <mao451F4mpgU1@mid.individual.net> |
| In reply to | #50585 |
Am 09.06.2025 um 14:06 schrieb Thomas Koenig: > Kay Martinen <usenet@martinen.de> schrieb: > > [...] > >> Das ist eben der Punkt. Ich habe drüber gelesen aber ich brauchte es nie >> und sah für mich auch keinen Ansatz wie es dinge besser/Einfacher machen >> könnte oder sollte. > > Ein Problem ist m.E. die merkwürdige Terminologie. IMHO ist das größte Problem die Denkfaulheit: Verstehe ich nicht -> brauche ich nicht -> ist doof! > Objektorientierung ist auch (IMHO) kein Allheilmittel, aber es > gibt jede Menge Beispiele, wo sie wirklich sinnvoll sind. Niemand würde ernsthaft das Gegenteil behaupten. Aber es gibt wohl nur wenig Anwendungen bei denen OOP die Softwarearchitektur nicht *deutlich* vereinfachen würde. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-09 14:02 +0000 |
| Message-ID | <1026pij$is5r$1@dont-email.me> |
| In reply to | #50597 |
Eric Bruecklmeier <u@5i7.de> schrieb: > Am 09.06.2025 um 14:06 schrieb Thomas Koenig: >> Kay Martinen <usenet@martinen.de> schrieb: >> >> [...] >> >>> Das ist eben der Punkt. Ich habe drüber gelesen aber ich brauchte es nie >>> und sah für mich auch keinen Ansatz wie es dinge besser/Einfacher machen >>> könnte oder sollte. >> >> Ein Problem ist m.E. die merkwürdige Terminologie. > > IMHO ist das größte Problem die Denkfaulheit: Verstehe ich nicht -> > brauche ich nicht -> ist doof! > >> Objektorientierung ist auch (IMHO) kein Allheilmittel, aber es >> gibt jede Menge Beispiele, wo sie wirklich sinnvoll sind. > > Niemand würde ernsthaft das Gegenteil behaupten. Aber es gibt wohl nur > wenig Anwendungen bei denen OOP die Softwarearchitektur nicht *deutlich* > vereinfachen würde. Es muss nicht immer OOP sein, multiple dispatch tut es häufig auch. Beispiel: Julia. Und dann gibt es noch die Fans der funktionalen Sprachen... > >> 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. Nehmen wir mal eins meiner allerersten Programme, auf das ich damals sehr stolz war: Primfaktorenzerlegung auf einem 38-Programmierschritte-Casio. (Ist ja "folklore" hier :-) 123456789 habe ich damit hinbekommen. Für Objektorientierung sehe ich bei so einem Programm keinen Nutzen.
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <nil@nil.nil> |
|---|---|
| Date | 2025-06-10 08:08 +0200 |
| Message-ID | <maq0e2Fh40dU1@mid.individual.net> |
| In reply to | #50601 |
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: >>> Kay Martinen <usenet@martinen.de> schrieb: >>> >>> [...] >>> >>>> Das ist eben der Punkt. Ich habe drüber gelesen aber ich brauchte es nie >>>> und sah für mich auch keinen Ansatz wie es dinge besser/Einfacher machen >>>> könnte oder sollte. >>> >>> Ein Problem ist m.E. die merkwürdige Terminologie. >> >> IMHO ist das größte Problem die Denkfaulheit: Verstehe ich nicht -> >> brauche ich nicht -> ist doof! >> >>> Objektorientierung ist auch (IMHO) kein Allheilmittel, aber es >>> gibt jede Menge Beispiele, wo sie wirklich sinnvoll sind. >> >> Niemand würde ernsthaft das Gegenteil behaupten. Aber es gibt wohl nur >> wenig Anwendungen bei denen OOP die Softwarearchitektur nicht *deutlich* >> vereinfachen würde. > > Es muss nicht immer OOP sein, multiple dispatch tut es häufig auch. > Beispiel: Julia. Und dann gibt es noch die Fans der funktionalen > Sprachen... Klar, muß es nicht OOP sein - es gibt ja genug andere Paradigmen. >> >>> 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) Das gleiche gilt, wenn man eine Eigenschaft dieses Gegenstandes abfragen möchte. Auto.zuladung statt Zuladung(Auto) In diesem Sinne bildet OOP die natürliche Art zu denken ab. Und wie bereits erwähnt, ist C++ das wirklich schlechteste Beispiel. Ruby z.B. eignet sich hervorragend als Anfängersprache. > Nehmen wir mal eins meiner allerersten Programme, auf das > ich damals sehr stolz war: Primfaktorenzerlegung auf einem > 38-Programmierschritte-Casio. (Ist ja "folklore" hier :-) 123456789 > habe ich damit hinbekommen. Für Objektorientierung sehe ich bei > so einem Programm keinen Nutzen. Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP keinen unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel könnte n.prime? nützlich sein...
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2025-06-10 09:36 +0000 |
| Message-ID | <1t6847fb66i4a2a6n3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #50618 |
On Tue, 10 Jun 2025 08:08:04 Eric Bruecklmeier wrote: >> Primfaktorenzerlegung auf einem 38-Programmierschritte-Casio. >> (Ist ja "folklore" hier :-) 123456789 habe ich damit hinbekommen. >> Für Objektorientierung sehe ich bei so einem Programm keinen >> Nutzen. > Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP > keinen unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel > könnte n.prime? nützlich sein... Eher nicht, das wäre ja das Analogon zu prime(n) und daher bereits die Lösung der Aufgabenstellung. Servus, Stefan -- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich Offizieller Erstbesucher(TM) von mmeike Stefan - die exklusivste Verführung der Sünde! (Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-10 12:10 +0200 |
| Message-ID | <maqek8Fi4ltU1@mid.individual.net> |
| In reply to | #50620 |
Am 10.06.2025 um 11:36 schrieb Stefan Froehlich: > On Tue, 10 Jun 2025 08:08:04 Eric Bruecklmeier wrote: >>> Primfaktorenzerlegung auf einem 38-Programmierschritte-Casio. >>> (Ist ja "folklore" hier :-) 123456789 habe ich damit hinbekommen. >>> Für Objektorientierung sehe ich bei so einem Programm keinen >>> Nutzen. > >> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP >> keinen unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel >> könnte n.prime? nützlich sein... > > Eher nicht, das wäre ja das Analogon zu prime(n) und daher bereits > die Lösung der Aufgabenstellung. Das war ein Beispiel zur Veranschaulichung. Natürlich würde man heute vorhandene Methoden verwenden und den Algorithmus nicht zu Fuß nachbauen. Aber klar, damals (TM) war so etwas nicht verfügbar...
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-10 18:41 +0200 |
| Message-ID | <slrn104go0t.kt57.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50620 |
On 2025-06-10 11:36, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
> On Tue, 10 Jun 2025 08:08:04 Eric Bruecklmeier wrote:
>>> Primfaktorenzerlegung auf einem 38-Programmierschritte-Casio.
^^^^^^^^^^^^^^^^^^^^^
>>> (Ist ja "folklore" hier :-) 123456789 habe ich damit hinbekommen.
>>> Für Objektorientierung sehe ich bei so einem Programm keinen
>>> Nutzen.
>
>> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP
>> keinen unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel
>> könnte n.prime? nützlich sein...
>
> Eher nicht, das wäre ja das Analogon zu prime(n) und daher bereits
> die Lösung der Aufgabenstellung.
Weder von einer Methode n.prime? noch von einer Funltion prime(n) würde
ich eine Primfaktorenzerlegung erwarten. Und ich würde eine solche
Funktion auch nicht zur Implementation einer Primfaktorenzerlegung
verwenden.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2025-06-10 21:03 +0000 |
| Message-ID | <3t68489d74i1693a9n3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #50623 |
On Tue, 10 Jun 2025 18:41:01 Peter J. Holzer wrote: > On 2025-06-10 11:36, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote: >> On Tue, 10 Jun 2025 08:08:04 Eric Bruecklmeier wrote: >>> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP >>> keinen unmittelbaren Mehrwert zeigt. Aber auch [bei >>> Primzahlzerlegung] könnte n.prime? nützlich sein... >> Eher nicht, das wäre ja das Analogon zu prime(n) und daher >> bereits die Lösung der Aufgabenstellung. > Weder von einer Methode n.prime? noch von einer Funltion prime(n) > würde ich eine Primfaktorenzerlegung erwarten. Und ich würde eine > solche Funktion auch nicht zur Implementation einer > Primfaktorenzerlegung verwenden. Das ist allerdings wahr :-/ Servus, Stefan -- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich Offizieller Erstbesucher(TM) von mmeike 2025! Das Jahr von Stefan. Geheuerter geht's nimmer. (Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2025-06-11 07:01 +0200 |
| Message-ID | <102b0af$2qc$3@news.bawue.net> |
| In reply to | #50639 |
On 6/10/25 23:03, Stefan Froehlich wrote: > On Tue, 10 Jun 2025 18:41:01 Peter J. Holzer wrote: >> On 2025-06-10 11:36, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote: >>> On Tue, 10 Jun 2025 08:08:04 Eric Bruecklmeier wrote: >>>> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP >>>> keinen unmittelbaren Mehrwert zeigt. Aber auch [bei >>>> Primzahlzerlegung] könnte n.prime? nützlich sein... > >>> Eher nicht, das wäre ja das Analogon zu prime(n) und daher >>> bereits die Lösung der Aufgabenstellung. > >> Weder von einer Methode n.prime? noch von einer Funltion prime(n) >> würde ich eine Primfaktorenzerlegung erwarten. Und ich würde eine >> solche Funktion auch nicht zur Implementation einer >> Primfaktorenzerlegung verwenden. > > Das ist allerdings wahr :-/ Wer unter Linux unterwegs ist und eine Primfaktorenzerlegung in einem Script braucht, einfach 'factor' benutzen. Sollte installiert sein. $ factor 984798576754875664 984798576754875664: 2 2 2 2 59 57119 18263954749 Gerrit
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-10 18:37 +0200 |
| Message-ID | <slrn104gnqe.kt57.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50618 |
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. Eine Prozedur scheint mir hier also
für einen Nicht-Programmierer naheliegender als eine Methode.
Ich habe das erste Mal objekt-orientiert programmiert, bevor ich den
Begriff kannte und außerdem noch in einer Programmiersprache, die eher
nicht dafür gedacht ist (C), und ich fühle mich in objekt-orientierter
Programmierung nach wie vor wohl - aber ich bezweifle, dass "man" (also
der Durchschnittsmensch) so denkt. Das ist eine zusätzliche
Abstraktionsstufe, die man lernen muss, und mit der auch Programmierer
durchaus ihre Probleme haben.
>> Nehmen wir mal eins meiner allerersten Programme, auf das
>> ich damals sehr stolz war: Primfaktorenzerlegung auf einem
>> 38-Programmierschritte-Casio. (Ist ja "folklore" hier :-) 123456789
>> habe ich damit hinbekommen. Für Objektorientierung sehe ich bei
>> so einem Programm keinen Nutzen.
>
> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP keinen
> unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel könnte
> n.prime? nützlich sein...
Eigentlich nicht. Und selbst wenn, ist n.prime? nicht besser als
isprime(n).
Objektorientierte Programmierung ist IMHO immer dort sinnvoll, wo man
"Dinge" behandelt, die mutablen State haben, oder wo man diese Dinge
ähnlich aber nicht gleich sind.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-10 18:49 +0200 |
| Message-ID | <mar60eFmarpU1@mid.individual.net> |
| In reply to | #50622 |
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. > Eine Prozedur scheint mir hier also > für einen Nicht-Programmierer naheliegender als eine Methode. Das sehe ich zu 100% anders. > Ich habe das erste Mal objekt-orientiert programmiert, bevor ich den > Begriff kannte und außerdem noch in einer Programmiersprache, die eher > nicht dafür gedacht ist (C), und ich fühle mich in objekt-orientierter > Programmierung nach wie vor wohl - aber ich bezweifle, dass "man" (also > der Durchschnittsmensch) so denkt. Das ist eine zusätzliche > Abstraktionsstufe, die man lernen muss, und mit der auch Programmierer > durchaus ihre Probleme haben. IMHO ist das genaue Gegenteil der Fall. Nach meiner Erfahrung haben nur Programmierer damit Probleme, die vorher durch andere Paradigmen "versaut" wurden. Die die direkt in OOP beginnen empfinden das als völlig normal und "natürlich". >>> Nehmen wir mal eins meiner allerersten Programme, auf das >>> ich damals sehr stolz war: Primfaktorenzerlegung auf einem >>> 38-Programmierschritte-Casio. (Ist ja "folklore" hier :-) 123456789 >>> habe ich damit hinbekommen. Für Objektorientierung sehe ich bei >>> so einem Programm keinen Nutzen. >> >> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP keinen >> unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel könnte >> n.prime? nützlich sein... > > Eigentlich nicht. Und selbst wenn, ist n.prime? nicht besser als > isprime(n). Das Beispiel prime? ist sicher nicht optimal, da es nur bei einem Datentypen sinnvoll ist und die Schönheit der Polymorphie damit nicht sichtbar wird. > Objektorientierte Programmierung ist IMHO immer dort sinnvoll, wo man > "Dinge" behandelt, die mutablen State haben, oder wo man diese Dinge > ähnlich aber nicht gleich sind. Diese Einschränkung sehe ich nicht, Ducktyping und Polymorphie können genauso bei Immutables sinnvoll sein. Aber wie bereits erwähnt: Ich bin kein Missionar!
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-10 20:52 +0200 |
| Message-ID | <slrn104gvml.tgel.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50624 |
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.
Ich, der Fahrer habe die Kontrolle darüber, was passiert: Ich habe ein
Ziel, ich nehme Inputs auf, entscheide dann jeweils was ich machen will
und verwende dafür dann einzelne Funktionen des Autos (Lenkrad, Gas,
Bremsen, ...). Diese Prozedur führe ich als Fahrer durch, ich sage nicht
dem Auto "fahr!" und es macht dann alles selbständig (noch nicht). Wenn
ich dafür eine Simulation schreiben müsst, würde ich fahre als Methode
der Klasse Fahrer implementieren, nicht als Methode der Klasse Auto.
>> Ich habe das erste Mal objekt-orientiert programmiert, bevor ich den
>> Begriff kannte und außerdem noch in einer Programmiersprache, die eher
>> nicht dafür gedacht ist (C), und ich fühle mich in objekt-orientierter
>> Programmierung nach wie vor wohl - aber ich bezweifle, dass "man" (also
>> der Durchschnittsmensch) so denkt. Das ist eine zusätzliche
>> Abstraktionsstufe, die man lernen muss, und mit der auch Programmierer
>> durchaus ihre Probleme haben.
>
> IMHO ist das genaue Gegenteil der Fall. Nach meiner Erfahrung haben nur
> Programmierer damit Probleme, die vorher durch andere Paradigmen
> "versaut" wurden. Die die direkt in OOP beginnen empfinden das als
> völlig normal und "natürlich".
In gewissem Umfang ist das klar: Wenn man noch keine Ahnung vom
Programmieren hat, wird man immer das, was man gerade lernt, als die
natürliche Art akzeptieren. Man kennt ja nichts anderes.
>>>> Nehmen wir mal eins meiner allerersten Programme, auf das
>>>> ich damals sehr stolz war: Primfaktorenzerlegung auf einem
>>>> 38-Programmierschritte-Casio. (Ist ja "folklore" hier :-) 123456789
>>>> habe ich damit hinbekommen. Für Objektorientierung sehe ich bei
>>>> so einem Programm keinen Nutzen.
>>>
>>> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP keinen
>>> unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel könnte
>>> n.prime? nützlich sein...
>>
>> Eigentlich nicht. Und selbst wenn, ist n.prime? nicht besser als
>> isprime(n).
>
> Das Beispiel prime? ist sicher nicht optimal, da es nur bei einem
> Datentypen sinnvoll ist und die Schönheit der Polymorphie damit nicht
> sichtbar wird.
Nein, das ist nicht der Grund. Polymorphie kann man da ganz zwanglos
sehen: Verschiedene Integer-Typen oder ganz andere Algebras (Algebren?
Ich glaube, das ist das erste mal, dass ich den Plural von Algebra
gebraucht habe) in denen das Konzept eines Prim-Elements Sinn ergibt.
Mein Argument ist, dass die Implementation des Algorithmus selbst in
einer objekt-orientierten Sprache nicht anders als in einer
nicht-objektorientierten Sprache formuliert würde und dass Existenz
einer Funktion oder Methode, die prüft, ob eine Zahl prim ist, dafür gar
nicht notwendig ist.
Hier ist eine Implementation (ganz naiv, nicht optimiert und ohne
Fehlerbehandlung):
def factors(n):
f = []
p = 2
while n >= p:
if n % p == 0:
f.append(p)
n //= p
else:
p += 1
return f
Wie würde ich das objekt-orientiert schreiben?
>> Objektorientierte Programmierung ist IMHO immer dort sinnvoll, wo man
>> "Dinge" behandelt, die mutablen State haben, oder wo man diese Dinge
>> ähnlich aber nicht gleich sind.
>
> Diese Einschränkung sehe ich nicht, Ducktyping und Polymorphie können
> genauso bei Immutables sinnvoll sein.
Du hast das "oder" im Satz übersehen. Ducktyping und Polymorphie helfen
eben genau dann, wenn die Dinge "ähnlich aber nicht gleich" sind. Also
wenn ich z.B. die sinngemäß gleiche Operation auf sie anwenden kann, die
aber anders implementiert sein muss.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-11 07:22 +0200 |
| Message-ID | <masi58Fu2jeU1@mid.individual.net> |
| In reply to | #50637 |
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. > Ich, der Fahrer habe die Kontrolle darüber, was passiert: Ich habe ein > Ziel, ich nehme Inputs auf, entscheide dann jeweils was ich machen will > und verwende dafür dann einzelne Funktionen des Autos (Lenkrad, Gas, > Bremsen, ...). Diese Prozedur führe ich als Fahrer durch, ich sage nicht > dem Auto "fahr!" und es macht dann alles selbständig (noch nicht). Wenn > ich dafür eine Simulation schreiben müsst, würde ich fahre als Methode > der Klasse Fahrer implementieren, nicht als Methode der Klasse Auto. > > >>> Ich habe das erste Mal objekt-orientiert programmiert, bevor ich den >>> Begriff kannte und außerdem noch in einer Programmiersprache, die eher >>> nicht dafür gedacht ist (C), und ich fühle mich in objekt-orientierter >>> Programmierung nach wie vor wohl - aber ich bezweifle, dass "man" (also >>> der Durchschnittsmensch) so denkt. Das ist eine zusätzliche >>> Abstraktionsstufe, die man lernen muss, und mit der auch Programmierer >>> durchaus ihre Probleme haben. >> >> IMHO ist das genaue Gegenteil der Fall. Nach meiner Erfahrung haben nur >> Programmierer damit Probleme, die vorher durch andere Paradigmen >> "versaut" wurden. Die die direkt in OOP beginnen empfinden das als >> völlig normal und "natürlich". > > In gewissem Umfang ist das klar: Wenn man noch keine Ahnung vom > Programmieren hat, wird man immer das, was man gerade lernt, als die > natürliche Art akzeptieren. Man kennt ja nichts anderes. > > >>>>> Nehmen wir mal eins meiner allerersten Programme, auf das >>>>> ich damals sehr stolz war: Primfaktorenzerlegung auf einem >>>>> 38-Programmierschritte-Casio. (Ist ja "folklore" hier :-) 123456789 >>>>> habe ich damit hinbekommen. Für Objektorientierung sehe ich bei >>>>> so einem Programm keinen Nutzen. >>>> >>>> Natürlich gibt es genug (sehr kleine) Aufgaben, bei denen OOP keinen >>>> unmittelbaren Mehrwert zeigt. Aber auch in Deinem Beispiel könnte >>>> n.prime? nützlich sein... >>> >>> Eigentlich nicht. Und selbst wenn, ist n.prime? nicht besser als >>> isprime(n). >> >> Das Beispiel prime? ist sicher nicht optimal, da es nur bei einem >> Datentypen sinnvoll ist und die Schönheit der Polymorphie damit nicht >> sichtbar wird. > > Nein, das ist nicht der Grund. Polymorphie kann man da ganz zwanglos > sehen: Verschiedene Integer-Typen oder ganz andere Algebras (Algebren? > Ich glaube, das ist das erste mal, dass ich den Plural von Algebra > gebraucht habe) in denen das Konzept eines Prim-Elements Sinn ergibt. Mein Argument war aber, daß bei n.methode Polymorphie ganz natürlich und logisch ist, während das bei Proc(n) nicht der Fall ist. Das wird schon dadurch erkennbar, daß in der Mathematik für bestimmte Funktionen manche Zahlen nicht als Parameter übergeben werden dürfen. Wären es Methoden im Sinne der OOP, dann gäbe es diese Methoden einfach nicht. Beim Ducktyping kann mir der Datentyp letztlich egal sein... > Mein Argument ist, dass die Implementation des Algorithmus selbst in > einer objekt-orientierten Sprache nicht anders als in einer > nicht-objektorientierten Sprache formuliert würde und dass Existenz > einer Funktion oder Methode, die prüft, ob eine Zahl prim ist, dafür gar > nicht notwendig ist. > > Hier ist eine Implementation (ganz naiv, nicht optimiert und ohne > Fehlerbehandlung): > > def factors(n): > f = [] > p = 2 > while n >= p: > if n % p == 0: > f.append(p) > n //= p > else: > p += 1 > return f > > Wie würde ich das objekt-orientiert schreiben? > > >>> Objektorientierte Programmierung ist IMHO immer dort sinnvoll, wo man >>> "Dinge" behandelt, die mutablen State haben, oder wo man diese Dinge >>> ähnlich aber nicht gleich sind. >> >> Diese Einschränkung sehe ich nicht, Ducktyping und Polymorphie können >> genauso bei Immutables sinnvoll sein. > > Du hast das "oder" im Satz übersehen. Ducktyping und Polymorphie helfen > eben genau dann, wenn die Dinge "ähnlich aber nicht gleich" sind. Also > wenn ich z.B. die sinngemäß gleiche Operation auf sie anwenden kann, die > aber anders implementiert sein muss. Ja, das "oder" hatte ich wohl übersehen. Ich melde mich jetzt mal aus der Diskussion ab - da viel Arbeit ruft!
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-11 05:51 +0000 |
| Message-ID | <102b5gj$1q55a$1@dont-email.me> |
| In reply to | #50645 |
Eric Bruecklmeier <u@5i7.de> schrieb: [...] > Mein Argument war aber, daß bei n.methode Polymorphie ganz natürlich und > logisch ist, während das bei Proc(n) nicht der Fall ist. Das ist eher ein Glaubenssatz als eine belastbare Aussage. > Das wird schon > dadurch erkennbar, daß in der Mathematik für bestimmte Funktionen manche > Zahlen nicht als Parameter übergeben werden dürfen. #ifdef PEDANTIC Argumente, nicht Parameter. #endif Hmm... wie sollte man den in der Mathematik das ausdrücken? Der Arkuscosinus von 1,2 ist nicht definiert (zumindest wenn man sich auf den reellen Zahlenbereich beschränkt, sonst natürlich schon). Also sollte 1,2.arccos undefiniert sein, aber 0,8.arccos schon? Und wie soll der Benutzer wissen, ob x.arccos jetzt diese Definition hat oder nicht? Und wie soll die mathematische Schreibweise aussehen, wenn ich die objektorientiert mache? cos(pi/4) wäre dann... pi/4.cos ? (pi/4).cos? Die Schreibweise f(x) kommt ja gerade aus der Mathematik und wurde von FORTRAN damals so übernommen, deshalb ja auch FORmula TRANslation. Und eine Addition? Wenn ich einen Ausdruck a + b habe, zu welchem der beiden Terme soll denn die Methode gehören? >Wären es Methoden im > Sinne der OOP, dann gäbe es diese Methoden einfach nicht S.o.
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-11 08:15 +0200 |
| Message-ID | <masl8bFu2jeU2@mid.individual.net> |
| In reply to | #50646 |
Am 11.06.2025 um 07:51 schrieb Thomas Koenig: Eigentlich wollte ich nicht mehr antworten, da ich wirklich gut zu tun habe ;-). > Eric Bruecklmeier <u@5i7.de> schrieb: > > [...] > >> Mein Argument war aber, daß bei n.methode Polymorphie ganz natürlich und >> logisch ist, während das bei Proc(n) nicht der Fall ist. > > Das ist eher ein Glaubenssatz als eine belastbare Aussage. > >> Das wird schon >> dadurch erkennbar, daß in der Mathematik für bestimmte Funktionen manche >> Zahlen nicht als Parameter übergeben werden dürfen. > > #ifdef PEDANTIC > Argumente, nicht Parameter. > #endif > > Hmm... wie sollte man den in der Mathematik das ausdrücken? > Der Arkuscosinus von 1,2 ist nicht definiert (zumindest wenn > man sich auf den reellen Zahlenbereich beschränkt, sonst natürlich > schon). Also sollte 1,2.arccos undefiniert sein, aber 0,8.arccos > schon? Und wie soll der Benutzer wissen, ob Das ist zwar ein extremes Beispiel, ist über die Singleton Klasse aber ganz leicht lösbar. > x.arccos > > jetzt diese Definition hat oder nicht? x.respond_to? :arcos > Und wie soll die mathematische Schreibweise aussehen, wenn ich > die objektorientiert mache? cos(pi/4) wäre dann... pi/4.cos ? > (pi/4).cos? Es dürfte klar sein, daß pi/4.cos und (pi/4).cos potentiell zwei verschiedene Dinge sind. Je nachdem was stärker bindet. > Die Schreibweise f(x) kommt ja gerade aus der Mathematik > und wurde von FORTRAN damals so übernommen, deshalb ja > auch FORmula TRANslation. > > Und eine Addition? Wenn ich einen Ausdruck a + b habe, zu > welchem der beiden Terme soll denn die Methode gehören? Das ist jetzt einfach: "1 + 3" ist syntactic sugar für "1.+ 3" oder "1.send(:+, 3)" Und das macht die ganze Stärke so richtig deutlich, damit geht dann auch: a = Myclass.new ... b = 1 + a Sofern a einen Integer auf sich addieren kann. >> Wären es Methoden im >> Sinne der OOP, dann gäbe es diese Methoden einfach nicht > > S.o. ja, eben! ;-)
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2025-06-11 08:04 +0000 |
| Message-ID | <1t68493730i28b3e9n3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #50647 |
On Wed, 11 Jun 2025 08:15:31 Eric Bruecklmeier wrote: > Am 11.06.2025 um 07:51 schrieb Thomas Koenig: >>> Mein Argument war aber, daß bei n.methode Polymorphie ganz >>> natürlich und logisch ist, während das bei Proc(n) nicht der >>> Fall ist. [...] >> Der Arkuscosinus von 1,2 ist nicht definiert (zumindest wenn man >> sich auf den reellen Zahlenbereich beschränkt, sonst natürlich >> schon). Also sollte 1,2.arccos undefiniert sein, aber 0,8.arccos >> schon? Und wie soll der Benutzer wissen, ob > Das ist zwar ein extremes Beispiel, ist über die Singleton Klasse > aber ganz leicht lösbar. Alles ist *lösbar*, aber tatsächlich habe ich ähnlich oft das Problem, mir unsicher zu sein, ob eine Methode nun für eine bestimmte Klasse implementiert ist (oder vielleicht nur für einige, davon abgeleitete Klassen, was meine Erinnerung durcheinanderbringt), wie ich Funktionen mit ungültigen Argumenten aufrufe. Wenig verwunderlich, weil es ja eine andere Ausdrucksform des gleichen Problems ist. >> Und wie soll die mathematische Schreibweise aussehen, wenn ich >> die objektorientiert mache? cos(pi/4) wäre dann... pi/4.cos ? >> (pi/4).cos? > Es dürfte klar sein, daß pi/4.cos und (pi/4).cos potentiell zwei > verschiedene Dinge sind. Je nachdem was stärker bindet. Es ist klar, wird allerdings zunehmend unlesbar. Und *das* jemanden noch als intuitive Verwendung von OOP zu verkaufen, wird ebenfalls schwierig. In der "echten" Welt ist Cosinus eine Funktion (und nicht etwas, das zu tun man eine Variable beauftragt), also spricht IMO alles dafür, das auch in der Programmierwelt so handzuhaben. > "1 + 3" ist syntactic sugar für "1.+ 3" oder "1.send(:+, 3)" > Und das macht die ganze Stärke so richtig deutlich Es ist super-elegant, fraglos, dafür aber (ohne den syntactic sugar) nicht mehr lesbar. Servus, Stefan -- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich Offizieller Erstbesucher(TM) von mmeike Stefan. Graus und zuckersüss! (Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-11 11:41 +0200 |
| Message-ID | <mat1a8F2spbU1@mid.individual.net> |
| In reply to | #50648 |
Am 11.06.2025 um 10:04 schrieb Stefan Froehlich: > On Wed, 11 Jun 2025 08:15:31 Eric Bruecklmeier wrote: >> Am 11.06.2025 um 07:51 schrieb Thomas Koenig: >>>> Mein Argument war aber, daß bei n.methode Polymorphie ganz >>>> natürlich und logisch ist, während das bei Proc(n) nicht der >>>> Fall ist. > [...] >>> Der Arkuscosinus von 1,2 ist nicht definiert (zumindest wenn man >>> sich auf den reellen Zahlenbereich beschränkt, sonst natürlich >>> schon). Also sollte 1,2.arccos undefiniert sein, aber 0,8.arccos >>> schon? Und wie soll der Benutzer wissen, ob > >> Das ist zwar ein extremes Beispiel, ist über die Singleton Klasse >> aber ganz leicht lösbar. > > Alles ist *lösbar*, aber tatsächlich habe ich ähnlich oft das > Problem, mir unsicher zu sein, ob eine Methode nun für eine > bestimmte Klasse implementiert ist (oder vielleicht nur für einige, > davon abgeleitete Klassen, was meine Erinnerung > durcheinanderbringt), wie ich Funktionen mit ungültigen Argumenten > aufrufe. > > Wenig verwunderlich, weil es ja eine andere Ausdrucksform des > gleichen Problems ist. > >>> Und wie soll die mathematische Schreibweise aussehen, wenn ich >>> die objektorientiert mache? cos(pi/4) wäre dann... pi/4.cos ? >>> (pi/4).cos? > >> Es dürfte klar sein, daß pi/4.cos und (pi/4).cos potentiell zwei >> verschiedene Dinge sind. Je nachdem was stärker bindet. > > Es ist klar, wird allerdings zunehmend unlesbar. Und *das* jemanden > noch als intuitive Verwendung von OOP zu verkaufen, wird ebenfalls > schwierig. In der "echten" Welt ist Cosinus eine Funktion (und nicht > etwas, das zu tun man eine Variable beauftragt), also spricht IMO > alles dafür, das auch in der Programmierwelt so handzuhaben. Genau darum wird das auch in Ruby als Math.cos(x) implementiert. Aber Fahre(Auto) ist davon meilenweit entfernt! >> "1 + 3" ist syntactic sugar für "1.+ 3" oder "1.send(:+, 3)" >> Und das macht die ganze Stärke so richtig deutlich > > Es ist super-elegant, fraglos, dafür aber (ohne den syntactic sugar) > nicht mehr lesbar. Der syntactic sugar ist aber vorhanden -> Problem gelöst.
[toc] | [prev] | [next] | [standalone]
| From | Dietrich Clauss <dietrich@clauss-it.com> |
|---|---|
| Date | 2025-06-12 12:47 +0200 |
| Message-ID | <srnqhl-hkse.ln1@clauss-it.com> |
| In reply to | #50649 |
Eric Bruecklmeier wrote: > Am 11.06.2025 um 10:04 schrieb Stefan Froehlich: >> On Wed, 11 Jun 2025 08:15:31 Eric Bruecklmeier wrote: >>> "1 + 3" ist syntactic sugar für "1.+ 3" oder "1.send(:+, 3)" >>> Und das macht die ganze Stärke so richtig deutlich >> >> Es ist super-elegant, fraglos, dafür aber (ohne den syntactic sugar) >> nicht mehr lesbar. > > Der syntactic sugar ist aber vorhanden -> Problem gelöst. Syntactic sugar löst Probleme, die man ohne OOP gar nicht hätte.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-12 16:50 +0000 |
| Message-ID | <102f0g8$2pscm$1@dont-email.me> |
| In reply to | #50671 |
Dietrich Clauss <dietrich@clauss-it.com> schrieb: > Eric Bruecklmeier wrote: >> Am 11.06.2025 um 10:04 schrieb Stefan Froehlich: >>> On Wed, 11 Jun 2025 08:15:31 Eric Bruecklmeier wrote: >>>> "1 + 3" ist syntactic sugar für "1.+ 3" oder "1.send(:+, 3)" >>>> Und das macht die ganze Stärke so richtig deutlich >>> >>> Es ist super-elegant, fraglos, dafür aber (ohne den syntactic sugar) >>> nicht mehr lesbar. >> >> Der syntactic sugar ist aber vorhanden -> Problem gelöst. > > Syntactic sugar löst Probleme, die man ohne OOP gar nicht hätte. Um mal jemanden von der J3-Mailing-Liste zu zitieren... # This is either simple syntactic sugar or complex syntactic # cyanide. Der gleiche Mensch auf der gleichen Mailingliste schrieb auch noch die goldenen Worte # Hiring someone else to write your C++ code is probably a # good idea for preserving sanity. Although having to read the # code later will undo any of the previously mentioned benefits.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-11 17:13 +0000 |
| Message-ID | <102cdg4$23hcu$2@dont-email.me> |
| In reply to | #50647 |
Eric Bruecklmeier <u@5i7.de> schrieb: > Am 11.06.2025 um 07:51 schrieb Thomas Koenig: > >> Hmm... wie sollte man den in der Mathematik das ausdrücken? >> Der Arkuscosinus von 1,2 ist nicht definiert (zumindest wenn >> man sich auf den reellen Zahlenbereich beschränkt, sonst natürlich >> schon). Also sollte 1,2.arccos undefiniert sein, aber 0,8.arccos >> schon? Und wie soll der Benutzer wissen, ob > > Das ist zwar ein extremes Beispiel, ist über die Singleton Klasse aber > ganz leicht lösbar. Wenn du willst, dass ich das verstehe, dann musst du mir das erklären :-) >> x.arccos >> >> jetzt diese Definition hat oder nicht? > > x.respond_to? :arcos Runtime oder compile-time?
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web