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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Eric Bruecklmeier <nil@nil.nil> |
|---|---|
| Date | 2025-06-12 07:41 +0200 |
| Message-ID | <mav7k0Feg5vU1@mid.individual.net> |
| In reply to | #50667 |
Am 11.06.2025 um 19:13 schrieb Thomas Koenig: > 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 :-) In der Singleton Klasse könnte man prinzipiell für jede Instanz einer Klasse unterschiedliches Verhalten festlegen. Allerdings nicht bei Immutables und beim obigen Beispiel wäre das ohnehin Blödsinn. >>> x.arccos >>> >>> jetzt diese Definition hat oder nicht? >> >> x.respond_to? :arcos > > Runtime oder compile-time? Bei interpretierten Sprachen grundsätzlich runtime.
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <nil@nil.nil> |
|---|---|
| Date | 2025-06-12 08:22 +0200 |
| Message-ID | <mava15Feg5vU2@mid.individual.net> |
| In reply to | #50668 |
acos
Das ist nun zwar grober Blödsinn, aber so könnte man es auch lösen:
class MyFloat
def initialize value
begin
@value = Float value
rescue ArgumentError, TypeError
raise TypeError, 'Must be initialized with a Float-like value'
end
freeze
end
def method_missing method, *args, &block
case method
when :acos
raise NoMethodError, "undefined method `#{method}` for #{self}"
unless (-1.0..1.0).include? @value
Math.acos @value
else
return @value.public_send method, *args, &block if
@value.respond_to? method
super
end
end
def respond_to_missing? method, include_private = false
case method
when :acos
(-1.0..1.0).include? @value
else
@value.respond_to?(method, include_private) || super
end
end
def self.try_build value
new value
rescue TypeError
nil
end
end
f1 = MyFloat.new 0.4
f2 = MyFloat.new 1.2
p f1.respond_to? :acos # => true
p f2.respond_to? :acos # => false
p f1.acos # => 1.1592794807274085
p f2.acos # => raises NoMethodError
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-12 19:41 +0000 |
| Message-ID | <102fah1$2scdm$1@dont-email.me> |
| In reply to | #50668 |
Eric Bruecklmeier <nil@nil.nil> schrieb: > Am 11.06.2025 um 19:13 schrieb Thomas Koenig: >> 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 :-) > > In der Singleton Klasse könnte man prinzipiell für jede Instanz einer > Klasse unterschiedliches Verhalten festlegen. Allerdings nicht bei > Immutables und beim obigen Beispiel wäre das ohnehin Blödsinn. Hmm... ja, 2^64 verschiedene Instanzen für alle IEEE doubles festzulegen wäre ein bisschen viel. Und dann kommt jemand mit 128-bit-floats um die Ecke... POWER hat die ja in Hardware.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-12 20:00 +0000 |
| Message-ID | <102fblr$2scdm$4@dont-email.me> |
| In reply to | #50668 |
Eric Bruecklmeier <nil@nil.nil> schrieb: > Am 11.06.2025 um 19:13 schrieb Thomas Koenig: >> 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 :-) > > In der Singleton Klasse könnte man prinzipiell für jede Instanz einer > Klasse unterschiedliches Verhalten festlegen. Allerdings nicht bei > Immutables und beim obigen Beispiel wäre das ohnehin Blödsinn. > >>>> x.arccos >>>> >>>> jetzt diese Definition hat oder nicht? >>> >>> x.respond_to? :arcos >> >> Runtime oder compile-time? > > Bei interpretierten Sprachen grundsätzlich runtime. Und bei kompilierten? Ein bisschen effizient darf's ja auch noch sein :-) OOP ist ja erst mal langsamer als direkter Code, weil Funktionsaufrufe durch die vtab gehen müssen und dafür erst mal eine weitere Adresse geladen werden muss. Natürlich machen da Compiler mittlerweile einiges (devirtualization bei LTO, aber LTO daaaauuert... Firefox würde ich nicht freiwillig bauen), und die modernen OoO-Architekturen mit ihren branch predictors können ja auch einiges ausbügeln, aber ein L1-Speicherzugriff ist mittlerweile auf 4 Zyklen, und Cache ist weiterhin sehr kostbar.
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <nil@nil.nil> |
|---|---|
| Date | 2025-06-13 08:20 +0200 |
| Message-ID | <mb1u9vFsc21U1@mid.individual.net> |
| In reply to | #50685 |
Am 12.06.2025 um 22:00 schrieb Thomas Koenig: > Eric Bruecklmeier <nil@nil.nil> schrieb: >> Am 11.06.2025 um 19:13 schrieb Thomas Koenig: >>> 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 :-) >> >> In der Singleton Klasse könnte man prinzipiell für jede Instanz einer >> Klasse unterschiedliches Verhalten festlegen. Allerdings nicht bei >> Immutables und beim obigen Beispiel wäre das ohnehin Blödsinn. >> >>>>> x.arccos >>>>> >>>>> jetzt diese Definition hat oder nicht? >>>> >>>> x.respond_to? :arcos >>> >>> Runtime oder compile-time? >> >> Bei interpretierten Sprachen grundsätzlich runtime. > > Und bei kompilierten? Ein bisschen effizient darf's ja auch > noch sein :-) Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast ausschließlich in Ruby.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-13 16:55 +0000 |
| Message-ID | <102hl67$3hv4m$1@dont-email.me> |
| In reply to | #50691 |
Eric Bruecklmeier <nil@nil.nil> schrieb: > Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >> Und bei kompilierten? Ein bisschen effizient darf's ja auch >> noch sein :-) > > Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast > ausschließlich in Ruby. Also keinen High-Performance code. Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high performance ein zentraler Gedanke, und da überlegt man sich halt schon, ob man unbedingt Klassen braucht. Die Sprache bietet es allerdings an.
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-14 10:45 +0200 |
| Message-ID | <mb4r53FcqjaU1@mid.individual.net> |
| In reply to | #50699 |
Am 13.06.2025 um 18:55 schrieb Thomas Koenig: > Eric Bruecklmeier <nil@nil.nil> schrieb: >> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: > >>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>> noch sein :-) >> >> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >> ausschließlich in Ruby. > > Also keinen High-Performance code. > > Ich dagegen schreibe an einem Fortran-Compiler mit, Na dann...
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-14 09:24 +0000 |
| Message-ID | <102jf3u$3chv$1@dont-email.me> |
| In reply to | #50708 |
Eric Bruecklmeier <u@5i7.de> schrieb: > Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >> Eric Bruecklmeier <nil@nil.nil> schrieb: >>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >> >>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>> noch sein :-) >>> >>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>> ausschließlich in Ruby. >> >> Also keinen High-Performance code. >> >> Ich dagegen schreibe an einem Fortran-Compiler mit, > > Na dann... Ich hoffe mal, dass du deinen Studenten nicht erzählst, sie sollen Ruby verwenden, wenn es auf Performance ankommt :-) Ist es richtig, dass heute im Informatikunterricht die Studenten normalerweise wenig bis gar nichts darüber lernen, wie man gute Performance erreicht, und nicht mal lernen, Assembler wenigstens zu lesen? (Assembler ist ein bisschen wie Latein, d.h. schreiben ist selten nötig, aber Lesen können ist ein klarer Vorteil). Bisher hat uns Moore's Law ja über weitere Abstraktionsebenen hinweggeholfen, aber zumindest die Kurve der CPU-Performance über der Zeit flacht so stark ab, dass das nicht mehr groß hilft. Interpreter-Sprachen wie Python (was immer man auch von Python im Speziellen halten möge, ich persönlicht nicht viel, aus $GRUENDEN) sind da natürlich noch eine weiter Faktor. Java und Julia haben wenigstens JIT-Compiler, die die Performance auf einen kleinen Faktor gegenüber kompilierten Sprachen heraufheben.
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-14 11:29 +0200 |
| Message-ID | <mb4tp0FcqjaU2@mid.individual.net> |
| In reply to | #50709 |
Am 14.06.2025 um 11:24 schrieb Thomas Koenig: > Eric Bruecklmeier <u@5i7.de> schrieb: >> Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >>> Eric Bruecklmeier <nil@nil.nil> schrieb: >>>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >>> >>>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>>> noch sein :-) >>>> >>>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>>> ausschließlich in Ruby. >>> >>> Also keinen High-Performance code. >>> >>> Ich dagegen schreibe an einem Fortran-Compiler mit, >> >> Na dann... > > Ich hoffe mal, dass du deinen Studenten nicht erzählst, sie sollen > Ruby verwenden, wenn es auf Performance ankommt :-) Das tue ich natürlich nicht, im Gegenteil - ich weise explizit auf die Nachteile interpretierter Sprachen hin. > Ist es richtig, dass heute im Informatikunterricht die Studenten > normalerweise wenig bis gar nichts darüber lernen, wie man gute > Performance erreicht, und nicht mal lernen, Assembler wenigstens > zu lesen? Um beurteilen zu können, ob ich diese Frage überhaupt beantworten kann, müßtest Du zunächst klarstellen, was Du mit "Informatikunterricht" genau meinst.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-14 09:36 +0000 |
| Message-ID | <102jfqv$3chv$3@dont-email.me> |
| In reply to | #50710 |
Eric Bruecklmeier <u@5i7.de> schrieb: > Am 14.06.2025 um 11:24 schrieb Thomas Koenig: >> Eric Bruecklmeier <u@5i7.de> schrieb: >>> Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >>>> Eric Bruecklmeier <nil@nil.nil> schrieb: >>>>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >>>> >>>>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>>>> noch sein :-) >>>>> >>>>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>>>> ausschließlich in Ruby. >>>> >>>> Also keinen High-Performance code. >>>> >>>> Ich dagegen schreibe an einem Fortran-Compiler mit, >>> >>> Na dann... >> >> Ich hoffe mal, dass du deinen Studenten nicht erzählst, sie sollen >> Ruby verwenden, wenn es auf Performance ankommt :-) > > Das tue ich natürlich nicht, im Gegenteil - ich weise explizit auf die > Nachteile interpretierter Sprachen hin. > >> Ist es richtig, dass heute im Informatikunterricht die Studenten >> normalerweise wenig bis gar nichts darüber lernen, wie man gute >> Performance erreicht, und nicht mal lernen, Assembler wenigstens >> zu lesen? > > Um beurteilen zu können, ob ich diese Frage überhaupt beantworten kann, > müßtest Du zunächst klarstellen, was Du mit "Informatikunterricht" genau > meinst. s/unterricht/studium/
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-14 11:41 +0200 |
| Message-ID | <mb4ue0FcqjbU1@mid.individual.net> |
| In reply to | #50712 |
Am 14.06.2025 um 11:36 schrieb Thomas Koenig: > Eric Bruecklmeier <u@5i7.de> schrieb: >> Am 14.06.2025 um 11:24 schrieb Thomas Koenig: >>> Eric Bruecklmeier <u@5i7.de> schrieb: >>>> Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >>>>> Eric Bruecklmeier <nil@nil.nil> schrieb: >>>>>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >>>>> >>>>>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>>>>> noch sein :-) >>>>>> >>>>>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>>>>> ausschließlich in Ruby. >>>>> >>>>> Also keinen High-Performance code. >>>>> >>>>> Ich dagegen schreibe an einem Fortran-Compiler mit, >>>> >>>> Na dann... >>> >>> Ich hoffe mal, dass du deinen Studenten nicht erzählst, sie sollen >>> Ruby verwenden, wenn es auf Performance ankommt :-) >> >> Das tue ich natürlich nicht, im Gegenteil - ich weise explizit auf die >> Nachteile interpretierter Sprachen hin. >> >>> Ist es richtig, dass heute im Informatikunterricht die Studenten >>> normalerweise wenig bis gar nichts darüber lernen, wie man gute >>> Performance erreicht, und nicht mal lernen, Assembler wenigstens >>> zu lesen? >> >> Um beurteilen zu können, ob ich diese Frage überhaupt beantworten kann, >> müßtest Du zunächst klarstellen, was Du mit "Informatikunterricht" genau >> meinst. > > s/unterricht/studium/ Dazu kann ich nichts sagen, ich bin an einer Fakultät für Elektrotechnik und Informationstechnik tätig.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-14 14:37 +0200 |
| Message-ID | <mb58nhFf0b7U2@mid.individual.net> |
| In reply to | #50710 |
Eric Bruecklmeier, 2025-06-14 11:29: > Am 14.06.2025 um 11:24 schrieb Thomas Koenig: >> Eric Bruecklmeier <u@5i7.de> schrieb: >>> Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >>>> Eric Bruecklmeier <nil@nil.nil> schrieb: >>>>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >>>> >>>>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>>>> noch sein :-) >>>>> >>>>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>>>> ausschließlich in Ruby. >>>> >>>> Also keinen High-Performance code. >>>> >>>> Ich dagegen schreibe an einem Fortran-Compiler mit, >>> >>> Na dann... >> >> Ich hoffe mal, dass du deinen Studenten nicht erzählst, sie sollen >> Ruby verwenden, wenn es auf Performance ankommt :-) > > Das tue ich natürlich nicht, im Gegenteil - ich weise explizit auf die > Nachteile interpretierter Sprachen hin. Wobei viele "interpretierte" Sprachen wie Ruby, JavaScript oder PHP zur Laufzeit erstmal übersetzt werden in einer deutlich effizientere Form, was dann auch als "just in time compiler" bezeichnet wird. In diese Form ist der Code dann oft gar nicht mehr so viel langsamer, als reine binaries - zumal, wenn der Code nur genutzt wird, um Funktionen aus Libraries zu nutzen, die ihrerseits in C oder C++ geschrieben wurden. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-14 14:41 +0200 |
| Message-ID | <mb5912FcqjbU3@mid.individual.net> |
| In reply to | #50723 |
Am 14.06.2025 um 14:37 schrieb Arno Welzel: > Eric Bruecklmeier, 2025-06-14 11:29: > >> Am 14.06.2025 um 11:24 schrieb Thomas Koenig: >>> Eric Bruecklmeier <u@5i7.de> schrieb: >>>> Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >>>>> Eric Bruecklmeier <nil@nil.nil> schrieb: >>>>>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >>>>> >>>>>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>>>>> noch sein :-) >>>>>> >>>>>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>>>>> ausschließlich in Ruby. >>>>> >>>>> Also keinen High-Performance code. >>>>> >>>>> Ich dagegen schreibe an einem Fortran-Compiler mit, >>>> >>>> Na dann... >>> >>> Ich hoffe mal, dass du deinen Studenten nicht erzählst, sie sollen >>> Ruby verwenden, wenn es auf Performance ankommt :-) >> >> Das tue ich natürlich nicht, im Gegenteil - ich weise explizit auf die >> Nachteile interpretierter Sprachen hin. > > Wobei viele "interpretierte" Sprachen wie Ruby, JavaScript oder PHP zur > Laufzeit erstmal übersetzt werden in einer deutlich effizientere Form, > was dann auch als "just in time compiler" bezeichnet wird. In diese Form > ist der Code dann oft gar nicht mehr so viel langsamer, als reine > binaries - zumal, wenn der Code nur genutzt wird, um Funktionen aus > Libraries zu nutzen, die ihrerseits in C oder C++ geschrieben wurden. Völlig klar, aber einen Performance-sensiblen Gerätetreiber würde ich trotzdem nicht in Ruby schreiben. Abgesehen davon hängt die Performance dann auch immer von der konkreten Ruby VM ab.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-14 15:01 +0200 |
| Message-ID | <mb5a4vFf0b7U6@mid.individual.net> |
| In reply to | #50724 |
Eric Bruecklmeier, 2025-06-14 14:41: > Am 14.06.2025 um 14:37 schrieb Arno Welzel: [...] >> Wobei viele "interpretierte" Sprachen wie Ruby, JavaScript oder PHP zur >> Laufzeit erstmal übersetzt werden in einer deutlich effizientere Form, >> was dann auch als "just in time compiler" bezeichnet wird. In diese Form >> ist der Code dann oft gar nicht mehr so viel langsamer, als reine >> binaries - zumal, wenn der Code nur genutzt wird, um Funktionen aus >> Libraries zu nutzen, die ihrerseits in C oder C++ geschrieben wurden. > > Völlig klar, aber einen Performance-sensiblen Gerätetreiber würde ich > trotzdem nicht in Ruby schreiben. Abgesehen davon hängt die Performance > dann auch immer von der konkreten Ruby VM ab. "Performance-sensibler Gerätetreiber" ist aber auch ein sehr spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte Sprachen bezüglich Performance sehr gut aus. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-14 13:25 +0000 |
| Message-ID | <102jt8o$6ne5$2@dont-email.me> |
| In reply to | #50729 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > Eric Bruecklmeier, 2025-06-14 14:41: > >> Am 14.06.2025 um 14:37 schrieb Arno Welzel: > [...] >>> Wobei viele "interpretierte" Sprachen wie Ruby, JavaScript oder PHP zur >>> Laufzeit erstmal übersetzt werden in einer deutlich effizientere Form, >>> was dann auch als "just in time compiler" bezeichnet wird. In diese Form >>> ist der Code dann oft gar nicht mehr so viel langsamer, als reine >>> binaries - zumal, wenn der Code nur genutzt wird, um Funktionen aus >>> Libraries zu nutzen, die ihrerseits in C oder C++ geschrieben wurden. >> >> Völlig klar, aber einen Performance-sensiblen Gerätetreiber würde ich >> trotzdem nicht in Ruby schreiben. Abgesehen davon hängt die Performance >> dann auch immer von der konkreten Ruby VM ab. > > "Performance-sensibler Gerätetreiber" ist aber auch ein sehr > spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte > Sprachen bezüglich Performance sehr gut aus. Und wenn die Leute dann nichts anderes können und z.B. Python für eine Aufgabe nehmen (weil sie's halt so halbwegs können), die dann ewig lange braucht... Pech gehabt.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2025-06-14 21:20 +0200 |
| Message-ID | <102ki17$1gvdf$1@news1.tnib.de> |
| In reply to | #50731 |
Thomas Koenig <tkoenig@netcologne.de> wrote: >Arno Welzel <usenet@arnowelzel.de> schrieb: >> "Performance-sensibler Gerätetreiber" ist aber auch ein sehr >> spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >> Sprachen bezüglich Performance sehr gut aus. > >Und wenn die Leute dann nichts anderes können und z.B. Python für >eine Aufgabe nehmen (weil sie's halt so halbwegs können), die >dann ewig lange braucht... Pech gehabt. Ist es nicht auch in Python ganz besonders einfach, Libraries für Python zu haben, deren zeit- und performanckritische Teile in C oder anderen schnellen Programmiersprachen geschrieben sind? 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 | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-14 21:52 +0200 |
| Message-ID | <slrn104rkna.1lvfd.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50742 |
On 2025-06-14 21:20, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>Arno Welzel <usenet@arnowelzel.de> schrieb:
>>> Für die meisten Anwendungen reichen interpretierte Sprachen
>>> bezüglich Performance sehr gut aus.
>>
>>Und wenn die Leute dann nichts anderes können und z.B. Python für
>>eine Aufgabe nehmen (weil sie's halt so halbwegs können), die
>>dann ewig lange braucht... Pech gehabt.
>
> Ist es nicht auch in Python ganz besonders einfach, Libraries für
> Python zu haben, deren zeit- und performanckritische Teile in C oder
> anderen schnellen Programmiersprachen geschrieben sind?
Die Librarys zu haben ist eine Sache. Sie auch zu verwenden, eine
andere. In C schreibe ich halt schnell eine Schleife und die ist
vielleicht nicht ganz so schnell wie die spezialisierte Library, aber
irgendwo in der gleichen Gegend. In Python kann ich auch schnell eine
Schleife schreiben, die ist dann aber sehr viel langsamer, oder 2
Stunden Pandas-Dokumentation wälzen.
(Allerdings schreibe ich sehr wenig Code, wo Python das Bottleneck ist.
Mein Code wartet (fast) immer entweder aufs Netzwerk oder auf die
Datenbank oder auf den User. Performance-Optimierung besteht daher fast
immer daraus, Datenbank- oder HTTP-Zugriffe einzusparen. Ich behaupte,
dass mir das in Python (oder Perl) leichter fällt als in C (oder Go),
weil ich mich weniger um Details kümmern muss und daher mehr Zeit habe,
über den Algorithmus oder das Datenmodell nachzudenken.)
hjp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-15 07:42 +0000 |
| Message-ID | <102ltga$p02e$2@dont-email.me> |
| In reply to | #50742 |
Marc Haber <mh+usenetspam1118@zugschl.us> schrieb: > Thomas Koenig <tkoenig@netcologne.de> wrote: >>Arno Welzel <usenet@arnowelzel.de> schrieb: >>> "Performance-sensibler Gerätetreiber" ist aber auch ein sehr >>> spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >>> Sprachen bezüglich Performance sehr gut aus. >> >>Und wenn die Leute dann nichts anderes können und z.B. Python für >>eine Aufgabe nehmen (weil sie's halt so halbwegs können), die >>dann ewig lange braucht... Pech gehabt. > > Ist es nicht auch in Python ganz besonders einfach, Libraries für > Python zu haben, deren zeit- und performanckritische Teile in C oder > anderen schnellen Programmiersprachen geschrieben sind? Es geht, ob es besonders einfach ist, muss jemand entscheiden, der das schon mal gemacht hat (nicht ich :-) Die muss aber einer schreiben und einbinden, und das sind dan nicht die Leute, die nur Python können. Dazu kommt noch, dass die ABI von Python AFAIK nicht stabil ist...
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-14 16:13 +0200 |
| Message-ID | <mb5ecaFcqjaU3@mid.individual.net> |
| In reply to | #50729 |
Am 14.06.2025 um 15:01 schrieb Arno Welzel: > Eric Bruecklmeier, 2025-06-14 14:41: > >> Am 14.06.2025 um 14:37 schrieb Arno Welzel: > [...] >>> Wobei viele "interpretierte" Sprachen wie Ruby, JavaScript oder PHP zur >>> Laufzeit erstmal übersetzt werden in einer deutlich effizientere Form, >>> was dann auch als "just in time compiler" bezeichnet wird. In diese Form >>> ist der Code dann oft gar nicht mehr so viel langsamer, als reine >>> binaries - zumal, wenn der Code nur genutzt wird, um Funktionen aus >>> Libraries zu nutzen, die ihrerseits in C oder C++ geschrieben wurden. >> >> Völlig klar, aber einen Performance-sensiblen Gerätetreiber würde ich >> trotzdem nicht in Ruby schreiben. Abgesehen davon hängt die Performance >> dann auch immer von der konkreten Ruby VM ab. > > "Performance-sensibler Gerätetreiber" ist aber auch ein sehr > spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte > Sprachen bezüglich Performance sehr gut aus. > ja - und nun?
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-15 00:49 +0200 |
| Message-ID | <mb6cj5FklhqU4@mid.individual.net> |
| In reply to | #50732 |
Eric Bruecklmeier, 2025-06-14 16:13: > Am 14.06.2025 um 15:01 schrieb Arno Welzel: >> Eric Bruecklmeier, 2025-06-14 14:41: >> >>> Am 14.06.2025 um 14:37 schrieb Arno Welzel: >> [...] >>>> Wobei viele "interpretierte" Sprachen wie Ruby, JavaScript oder PHP zur >>>> Laufzeit erstmal übersetzt werden in einer deutlich effizientere Form, >>>> was dann auch als "just in time compiler" bezeichnet wird. In diese Form >>>> ist der Code dann oft gar nicht mehr so viel langsamer, als reine >>>> binaries - zumal, wenn der Code nur genutzt wird, um Funktionen aus >>>> Libraries zu nutzen, die ihrerseits in C oder C++ geschrieben wurden. >>> >>> Völlig klar, aber einen Performance-sensiblen Gerätetreiber würde ich >>> trotzdem nicht in Ruby schreiben. Abgesehen davon hängt die Performance >>> dann auch immer von der konkreten Ruby VM ab. >> >> "Performance-sensibler Gerätetreiber" ist aber auch ein sehr >> spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >> Sprachen bezüglich Performance sehr gut aus. >> > > ja - und nun? Und nun kann man alles, was nicht "Performance-sensibel" ist, auch gut in Ruby, JavaScript, PHP, C# etc. schreiben. Einen substantiellen Unterschied wird man in vielen Fällen nicht merken und etliche Sachen laufen heutzutage ohnehin nur noch als Web-Anwendung. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web