vergesst C++ ...

[DEvent]

Heißt das, ich muß die Klasse einmal für 2^n schreiben, dann für 2^n+1,
2^n+2, 2^n+3, und vielleicht gibt's ja für 7|n noch eine "lecker" Beschleunigung
mit ein paar fiesen rekursiven Tricks, also die Klasse noch für 7|n und 8|n^2+1 separat implementieren. Ja, lüg' ich denn ?!

ich würde mir eine Basisklasse für 2^n bauen und dann davon Klassen ableiten lassen für 2^n+1 und dann von dieser Klasse wiedreum eine weitere Klasse ableiten. Naja eh ein komisches Beispiel :p.
Das es in Python solche Datentypen gibt, gibts doch nur einen Grund: Um es Anfängern zu erleichtern mit der Sprache zu programmieren.

Was bei mir persönlich Kopfweh auslöst sind solche Sachen:

def foo(value): 
if (value==1): 
return 123; 
else: 
return list = ["1", "2", "3"] 

x = foo(1)

wieso hast du dicht noch immer nicht zu dem Code-Beispiel geäusert? Was macht der Compiler nun aus x ?
Was ist wenn ich sowas noch hinschreibe:

x = 10 * foo(10)

was passiert jetzt? Konvertiert der Compiler die Liste in einen Int-Typ ?
Bei diesem Codebeispiel fühle ich mich bestätigt, das Python eine Sprache für Anfänger ist, für die Leute die nocht nicht wissen was Typen sind und welche Vorteile es hat statische Typen zu haben.

Du sagt immer, das es ganz toll in Python ist, das man einen eingebauten GC hat, eingebaute Typen, keine delete, new, uvm, und wirfst C++ das genau Gegenteil vor. Aber: Du brauchst kein delete, new und keine eingebaute Typen.
delete, new : mach alles auf den Stack, funktioniert genau so gut.
einebaute Typen wie Tupel, Map usw: benutze eine Lib wie Boost oder was auch immer.

Du hast immer noch keinen Grund dafür genannt wieso eingebaute Typen ja so viel toller sind als Typen die man aus einer Lib bekommt. Der einzige Grund der mir einfällt ist nur Bequemlichkeit.

Ich kann dir aber ein Paar gute Gründe sagen die dafür sprechen keine eingebauten Typen zu haben.
Der wichtigeste Grund ist wohl der: wenn String in die Sprache eingebaut ist, dann gibt es nur diese eine Implementation von String. Der eingebaute Typ kann für mittlere Strings richtig gut funktionieren aber was ist mit richtig großen Strings oder ganz kleinen? Ich suche einfach eine Lib die einen String anbieren für große Strings. Mit eingebauten Typen kann ich das nicht.
Weiteres Beispiel: diese Liste in Python. Ist es eine doppelt-Verkettet ? Einfache ? Was ist wenn ich die Liste rückwärts durchsuchen will?

Fazit: Eingebaute Typen sind immer ein Mittelweg, mittig gut für alle Anwenungsmöglichkeiten, aber nirgendwo richtig gut. Wenn du richtige gute Implementierungen für eine spezielle Gegebenheit willst, kommst du nicht drumherum es selbst zu machen oder eine Lib zu benutzen. Also wieso nicht gleich eine Lib benutzen?

[maximAL]

Ben04 schrieb:

Wenn du mir zeigen kannst wo ich bei std::vector, boost::ptr_vector, boost::shared_ptr, boost::scoped_ptr oder bei std::string selbst um Kopiekonstruktor oder new/delete kümmern muß dann wechsele ich zu Python.

gleich 2 verschiedene managed pointer sowie ein pointer-container, alles aus einer 3rd party lib - was wolltest du noch gleich beweisen?

[ChockoCookie]

DEvent schrieb:

ich würde mir eine Basisklasse für 2^n bauen und dann davon Klassen ableiten lassen für 2^n+1 und dann von dieser Klasse wiedreum eine weitere Klasse ableiten. Naja eh ein komisches Beispiel :p.

Ich würde eher Traits nehmen.

DEvent schrieb:

Das es in Python solche Datentypen gibt, gibts doch nur einen Grund: Um es Anfängern zu erleichtern mit der Sprache zu programmieren.

Was bei mir persönlich Kopfweh auslöst sind solche Sachen:

def foo(value): 
if (value==1): 
return 123; 
else: 
return list = ["1", "2", "3"] 

x = foo(1)

wieso hast du dicht noch immer nicht zu dem Code-Beispiel geäusert? Was macht der Compiler nun aus x ?

Der "Compiler" macht gar nix draus. Der Interpreter bindet entweder ein Integer-Objekt oder ein Listen-Objekt an das Symbol x.

DEvent schrieb:

Was ist wenn ich sowas noch hinschreibe:

x = 10 * foo(10)

was passiert jetzt? Konvertiert der Compiler die Liste in einen Int-Typ ?

Nein, Python ist dynamisch Typisiert, aber nicht schwach Typisiert. dh falls eine Funktion (in diesem Fall der * Operator) nicht definiert ist, gibts eine Runtime Exception.
[edit] In diesem Fall ist der * Operator so definiert, dass er die Liste vervielfältigt und aneinandergehängt zurückgiebt (als neue Liste)[/edit]

DEvent schrieb:

Bei diesem Codebeispiel fühle ich mich bestätigt, das Python eine Sprache für Anfänger ist, für die Leute die nocht nicht wissen was Typen sind und welche Vorteile es hat statische Typen zu haben.

Und bei dieser Aussage fühle ich mich bestätigt, das du die Vorteile der dynamischen Typisierung in Python nicht verstanden hast.
Du musst bei Python sehr wohl wissen was Typen sind. Und wie man die Vorteile dynamischer Typen gewinnbringend einsetzt.

[Ben04]

ChockoCookie schrieb:

ich würde mir eine Basisklasse für 2^n bauen und dann davon Klassen ableiten lassen für 2^n+1 und dann von dieser Klasse wiedreum eine weitere Klasse ableiten. Naja eh ein komisches Beispiel :p.

Ich würde eher Traits nehmen.

Ich würde eher zu einer Policy basierten Lösung hin tendiren.

ChockoCookie schrieb:

Und bei dieser Aussage fühle ich mich bestätigt, das du die Vorteile der dynamischen Typisierung in Python nicht verstanden hast. Du musst bei Python sehr wohl wissen was Typen sind. Und wie man die Vorteile dynamischer Typen gewinnbringend einsetzt.

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig! Ich kenne keine Situation wo das von dir beschriebene Verhalten angebracht wäre. Mit C oder C++ wäre dir das nicht passiert.

maximAL schrieb:

gleich 2 verschiedene managed pointer sowie ein pointer-container, alles aus einer 3rd party lib - was wolltest du noch gleich beweisen?

Gut man kann daraus natürlich auch nur boost::shared_ptr und std::vector<boost::shared_ptr<> > machen. Wäre auch besser angebracht als Vergleich da man in Pyhton ja auch nur ein Konstrukt hat das für alle Situation herhalten muß.

[O'Rakl]

Ben04 schrieb:

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig!

So, wie denn ? Ich habe noch nie ein Python-Programm abstürzen sehen.
Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception und Zeilenangabe.

Ich kenne keine Situation wo das von dir beschriebene Verhalten angebracht wäre. Mit C oder C++ wäre dir das nicht passiert.

Bei generischen Algorithmen ist die Ein- und Ausgabe von Datentypen,
die erst zur Laufzeit fest liegen, nicht nur Gang und Gäbe, sondern
sogar Prinzip. In Python ist das nur so einfach, dass es jeder nutzen kann,
wogegen in C++ zur Nutzung von RTTI und STL ein Vorwissen im Umfang eines halben Informatik-Grundstudiums praktisch vorausgesetzt wird.

Wäre auch besser angebracht als Vergleich da man in Pyhton ja auch nur ein Konstrukt hat das für alle Situation herhalten muß.

[/quote]

Die Verbindung von Einfachheit und Allgemeinheit ist eben wahre Eleganz. Das ist in der Mathematik nicht anders als bei Programmiersprachen.

[volkard]

O'Rakl schrieb:

Die Verbindung von Einfachheit und Allgemeinheit ist eben wahre Eleganz.

aber warum programmierst du nicht in basic?
falls du das beantworten kannst, weißte auch, warum ich nicht in python programmiere.

[ChockoCookie]

Ben04 schrieb:

ChockoCookie schrieb:

ich würde mir eine Basisklasse für 2^n bauen und dann davon Klassen ableiten lassen für 2^n+1 und dann von dieser Klasse wiedreum eine weitere Klasse ableiten. Naja eh ein komisches Beispiel :p.

Ich würde eher Traits nehmen.

Ich würde eher zu einer Policy basierten Lösung hin tendiren.

Ja, klar. Sorry, ich hab das verwechselt (nur die Namen )

Ben04 schrieb:

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig!

Klar, in welcher Sprache kann man das nicht? Du kannst davon ausgehen, dass man in jeder Sprache Funktionen schreiben kann, die nicht ihren Zweck erfüllen.
Nur ob man das als Schwäche der Sprache werten darf ist fraglich.

Ben04 schrieb:

Ich kenne keine Situation wo das von dir beschriebene Verhalten angebracht wäre.

Ich kann mir dafür keine Situation vorstellen, in der man einen solchen Fehler unabsichtlich machen würde. Und wenn, würde man ihn sofort herausfinden.

Ben04 schrieb:

Mit C oder C++ wäre dir das nicht passiert.

Ich habe ja gesagt, man muss in Python auch achtgeben. Aber die Sprache ist so gedacht, dass Typen nicht wichtig sind (ein Ziel der Objektorintierung). Stattdessen werden Methoden einfach durch den Namen bestimmt, ohne vorher Vererbungsmodelle erstellen zu müssen.

Allerdings kannst du sehr wohl bestimmen welchen Typ ein Objekt hat und von welchen Eltern es abgeleitet ist, nur musst du es meißtens nicht, weil du auf abstrakterer Ebene programmierst.

[BasicMan01]

Also 27 Seiten mir jetzt durchzulesen, ist echt hart.
Die erste tuts auch.
Also Programmieren muss schon bissl schwierig sein, wie+
soll man denn sonst andere beeindrucken?
Dann kann ja bald jeder sein Windows selbst schreiben *lol*

[O'Rakl]

volkard schrieb:

aber warum programmierst du nicht in basic?

Weil BASIC eine hoffnungslos veraltete Sprache ist, die ursprünglich entwickelt
wurde, damit Nicht-Programmierer leichter Programmieren lernen können.
Wenn ich mit einem nicht-proprietären BASIC-Dialekt schneller Software würde schreiben können, die genauso gut elegant,
wartbar, erweiterbar und verstehbar ist wie Python-Software, würde ich
BASIC nehmen. Augenblicklich scheint mir aber Python die bessere Wahl zu sein.

Im Ggs. zu BASIC (und auch C++) enthält Python Objektorientierung nicht als Add-on, sondern als Grundlage.

falls du das beantworten kannst, weißte auch, warum ich nicht in python programmiere.

Du wirst gute Gründe dafür haben. Ich sage ja nicht, daß alles in Python
programmiert werden sollte, aber andererseits sehe ich auch nicht, warum
Dinge, die man ebensogut in Python wie in C++ herstellen könnte, nicht in
Python mit all den damit verbundenen Vorteilen programmiert werden.
Tradition spielt hier sicher eine gewisse Rolle - es dauerte ja auch lange,
bis COBOL weitgehend verschwunden ist, obwohl es mancherorts heute noch
benutzt wird.

[Ben04]

O'Rakl schrieb:

Ben04 schrieb:

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig!

So, wie denn ? Ich habe noch nie ein Python-Programm abstürzen sehen.
Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception und Zeilenangabe.

Genau das ist ja das Problem! Erstens wird von Compiler Schwachsinn übersetzt und zweitens knallt es noch nicht einmal at runtime. Erst wenn der Kunde da sitzt und den Fall value = 1 durchspielt, den man vorher ja natürlich in den Betatests vergessen hat, kommen ganz merkwürdige Resultate raus.

Eine Sprache die es zulässt, dass Schwachsinn wüten kann ohne dem auch nur eine Schranke vorzuschieben lässt den nun einmal Programmier leicht sich selbst in den Fuß schießen. Das Gefährliche ist ja, dass er es noch nicht einmal merkt.

O'Rakl schrieb:

Ich kenne keine Situation wo das von dir beschriebene Verhalten angebracht wäre. Mit C oder C++ wäre dir das nicht passiert.

Bei generischen Algorithmen ist die Ein- und Ausgabe von Datentypen,
die erst zur Laufzeit fest liegen, nicht nur Gang und Gäbe, sondern
sogar Prinzip. In Python ist das nur so einfach, dass es jeder nutzen kann,
wogegen in C++ zur Nutzung von RTTI und STL ein Vorwissen im Umfang eines halben Informatik-Grundstudiums praktisch vorausgesetzt wird.

In braucht man in C++ dafür weder STL noch RTTI. Templates schaffen das ohne Runtimeoverheat. Aber das ist ja nicht das Thema, da es sich in dem Beispiel nicht um einen generischen Algorithmus handelt ist alles was du diesbezüglich gesagt hast hinfällig.

Wieso sind generischen Algorithmen eigentlich auch in Codeform? Die müssten doch auch buildin sein da das ja nur Vorteile hat.

O'Rakl schrieb:

Wäre auch besser angebracht als Vergleich da man in Pyhton ja auch nur ein Konstrukt hat das für alle Situation herhalten muß.

Die Verbindung von Einfachheit und Allgemeinheit ist eben wahre Eleganz. Das ist in der Mathematik nicht anders als bei Programmiersprachen.

Halleluja! In der Mathematik geht es darum ans Ziel zu kommen, wie ist eigentlich egal. Bei Software ist das "wie" aber das Haupinteresse.

ChockoCookie schrieb:

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig!

Klar, in welcher Sprache kann man das nicht? Du kannst davon ausgehen, dass man in jeder Sprache Funktionen schreiben kann, die nicht ihren Zweck erfüllen.
Nur ob man das als Schwäche der Sprache werten darf ist fraglich.

Dann sind wir uns ja einig, dass O'Rakls Argument, dass Phyton iditonsicher ist nicht weiter hält.

ChockoCookie schrieb:

Ich kann mir dafür keine Situation vorstellen, in der man einen solchen Fehler unabsichtlich machen würde. Und wenn, würde man ihn sofort herausfinden.

Ich schon : Primzahlenzerlegung. 1 wird sonder behandelt also hat man dann

def foo(value):
if (value==1):
return [1];
else:
  /* code */

Ich brauch nur die [] zu vergessen und fertig ist der Lack. Gut vielleicht kann man auch sagen 1 habe keine Primzahlenzerlegung aber das eigentliche Problem dürft klar sein.

O'Rakl schrieb:

Du wirst gute Gründe dafür haben. Ich sage ja nicht, daß alles in Python programmiert werden sollte,

Das vestehst du also unter "Vergesst C++"?

O'Rakl schrieb:

Dinge, die man ebensogut in Python wie in C++ herstellen könnte,

kann man in C++ oder Python schreiben da es ja keinen Vorteil bringt.

O'Rakl schrieb:

Python mit all den damit verbundenen Vorteilen programmiert werden.

Bisher hast du mir noch keinen einzigen klar gemacht. Also nochmal wieso sollte ich C++ vergessen und auf Python wechseln?

[Sovok]

O'Rakl schrieb:

Ben04 schrieb:

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig!

So, wie denn ? Ich habe noch nie ein Python-Programm abstürzen sehen.
Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception und Zeilenangabe.

ähem und was macht c++ da großartig anders? es kracht auch mit exception und zeilenangabe falls code und debuginformationen verfügbar sind

[Ben04]

Sovok schrieb:

O'Rakl schrieb:

Ben04 schrieb:

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig!

So, wie denn ? Ich habe noch nie ein Python-Programm abstürzen sehen.
Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception und Zeilenangabe.

ähem und was macht c++ da großartig anders? es kracht auch mit exception und zeilenangabe falls code und debuginformationen verfügbar sind

Übersetzt es nicht einmal.

std::list<boost::any>foo()
{
  return 1; 
}

[Sovok]

wie? mit python kann ich auch

asdfghj

schreiben und es kommt keine fehlermeldung?

[Gast]

Weil's einfach so schön passt: klick

[groovemaster]

O'Rakl schrieb:

So, wie denn ? Ich habe noch nie ein Python-Programm abstürzen sehen.
Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception und Zeilenangabe.

Was ist für dich denn der Unterschied zwischen "abstürzen" und "Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception"?

O'Rakl schrieb:

Im Ggs. zu BASIC (und auch C++) enthält Python Objektorientierung nicht als Add-on, sondern als Grundlage.

Also ein gewisses komödiantisches Talent muss man ihm ja durchaus zugestehen.
Übrigens, C++ enthält Objektorientierung auch als Grundlage.

[kartoffelsack]

Ein paar Nachteile hat der C++-Weg mit den Libs allerdings schon. Und weil o'rakl sie nicht nennt ...:

Der ganze Schmus (also z.B. std::vector) wird jedesmal neu übersetzt. Das kostet Compilezeit und die ist in C++ z.T. wirklich nicht mehr lustig. Hinzu kommt, dass es kein anständiges Modulkonzept gibt und jede übersetzungseinheit jedesmal xxx Zeilen Headercode neu mitübersetzt. Vorkompilierte Header etc. bringen zwar was, lösen aber das Problem nicht. Ein compiler, der wie in Java den Code während der eingabe übersetzt und eine IDE, die mir die Fehler dann - wie in ner Text-Verarbeitung - unterringelt, ist so nicht zu machen. In C++ freu ich mich wie ein kleines Kind, wenn die Codevervollständigung die richtigen hints gibt.
Übliche Tricks, abhängigkeiten zwischen Übersetzungseinheiten zu vermeiden (forward-Deklaration) funzen nicht mehr, wenn man mit smart_ptr arbeitet. Da muss nämlich die Definition des verpackten Typs bekannt sein, damit der Dtor aufgerufen werden kann. Gut, dann kann ich mit pimpl arbeiten, aber das verdoppelt die Tipparbeit für die Definition der Schnittstelle, eine Schnittstellenänderung wird gleich noch unangenehmer und unübersichtlicher etc.. Das alles heist, dass ich mich neben sauberer Modellierung in der Sprache auch noch einen Haufen sachen kümmern muss, damit mir nicht jeder Compilerlauf, während ich grad Unit-Tests mache und da und dort Fehler ausbessere ne viertelstunde kostet. Und auch 3 Minuten sind eigentlich viel zu viel.

Ein weiterer Nachteil ist die Arbeit mit dem Debugger. Welcher Debugger kann mir einfach mal schnell den Inhalt eines list<int>-Objekts anzeigen? Ganz zu schweigen von map<string, shared_ptr<Foo> >. Das schaffen die Werkzeughersteller bisher nichtmal für die STL-Konstrukte.

mE kann man C++ z.T. schon vorwerfen, dass es nicht so produktiv ist, wie andere Sprachen. Das liegt aber nicht an den Eigenschaften der Sprache an sich (mögliche Konstrukte, Einschränkungen oder Freiheiten), sondern
an mangelnder Unterstützung durch Werkzeuge bzw. daran, dass es die Sprache offensichtlich schwer macht, gute Werkzeuge zu entwickeln.

Das Argument, dass boost nicht zählt, weil es nicht zum Standard gehört, ist me übrigens nichtig. Boost lässt sich auf den verbreiteten Plattformen auf denen es einen vernünftigen standardkonformen Compiler gibt, übersetzen. Auf exotischen Plattformen zwar vielleicht nicht, aber da gibts dann auch keine python-Implementierung

[ChockoCookie]

Ben04 schrieb:

Genau das ist ja das Problem! Erstens wird von Compiler Schwachsinn übersetzt und zweitens knallt es noch nicht einmal at runtime. Erst wenn der Kunde da sitzt und den Fall value = 1 durchspielt, den man vorher ja natürlich in den Betatests vergessen hat, kommen ganz merkwürdige Resultate raus.

Es knallt auch in Python zur runtime, wenn du eine Methode aufrufst, die der Typ nicht unterstützt.
Ausserdem hast du auch in C++ genügend Möglichkeiten Fehler einzubauen, die du ohne ausreichende Tests übersiehst.

Ben04 schrieb:

In braucht man in C++ dafür weder STL noch RTTI. Templates schaffen das ohne Runtimeoverheat. Aber das ist ja nicht das Thema, da es sich in dem Beispiel nicht um einen generischen Algorithmus handelt ist alles was du diesbezüglich gesagt hast hinfällig.

Ja, aber auch für Templates muss der Typ zur Laufzeit feststehen.
Die einzige Chance, die du hast in C++ dynamische Typisierung zu betreiben, sind Virtuelle Funktionen. Und das ist im Vergleich zu Python doch sehr begrenzt.

Ben04 schrieb:

Dann sind wir uns ja einig, dass O'Rakls Argument, dass Phyton iditonsicher ist nicht weiter hält.

Natürlich sind wir das. Ich finde es in der Tat schwer, neben ihm Python zu verteidigen, da einiges was er sagt irrelevant / nicht haltbar ist. Womit er aber nicht alleine ist.

Ben04 schrieb:

ChockoCookie schrieb:

Ich kann mir dafür keine Situation vorstellen, in der man einen solchen Fehler unabsichtlich machen würde. Und wenn, würde man ihn sofort herausfinden.

Ich schon : Primzahlenzerlegung. 1 wird sonder behandelt also hat man dann

def foo(value):
if (value==1):
return [1];
else:
  /* code */

Ich brauch nur die [] zu vergessen und fertig ist der Lack. Gut vielleicht kann man auch sagen 1 habe keine Primzahlenzerlegung aber das eigentliche Problem dürft klar sein.

Schon, aber sowas würde man sofort bemerken (wie gesagt), da die Python runtime excellente Fehlerinformationen liefert.

Ben04 schrieb:

Bisher hast du mir noch keinen einzigen klar gemacht. Also nochmal wieso sollte ich C++ vergessen und auf Python wechseln?

Die Gründe wieso ich Python mag sind:

• Die unglaublich mächtigen Sachen, die du mit der Sprache anstellen kannst und der daraus folgende hohe Abstraktionsgrad. Stell dir vor, C++ hätte eine RTTI, in der wirklich alles über das betreffende Objekt steht und du könntest sogar einiges davon ändern.
• Die umfangreiche Standard Bib
• List Comprehensions: [i+5 for i in myList]

[kartoffelsack]

Ja, aber auch für Templates muss der Typ zur Laufzeit feststehen.
Die einzige Chance, die du hast in C++ dynamische Typisierung zu betreiben, sind Virtuelle Funktionen. Und das ist im Vergleich zu Python doch sehr begrenzt.

Aber mit std::list<int> kann ich halt sagen, dass da einfach nur ints drin sein dürfen. Und mit std::listboost::any kann ich sagen, dass da alles rein darf. Und mit std::list<boost::variant<int, string> >, dass da ints und strings reindürfen. Genau das ist der Vorteil der statischen Typisierung. Die dynamische Typisierung nimmt mir die Möglichkeit dieser Festlegung.
Ein bisschen mehr dynamik (rtti a la reflexions) würden natürlich trotzdem nicht schaden.

[super!!]

Die unglaublich mächtigen Sachen, die du mit der Sprache anstellen kannst und der daraus folgende hohe Abstraktionsgrad. Stell dir vor, C++ hätte eine RTTI, in der wirklich alles über das betreffende Objekt steht und du könntest sogar einiges davon ändern.

Toll. Sowas braucht man aber nicht.

[kartoffelsack]

Toll. Sowas braucht man aber nicht.

Du vielleicht nicht. Aber wenn Du was mit interprozesskommunikation machen willst, Deployment zur Laufzeit etc.. Dann brauchst Du es. Und eine 'general-purpose-Language' wie C++ es ist, sollte sowas durch die Sprache unterstützen.

Wenn O'rakl mit solchen Sachen kommen würde, dann könnte man ihm ja recht geben ...