Ich will C++ lernen...
Felix von Leitner
> Nun habe mich nun entschlossen C++ natürlich unter UNIX zu erlernen.
Lerne erstmal C.
> Aber C++ ist für mich immernoch ein Buch mit sieben Siegeln, darum frage
> ich Euch wie ich das Monster am besten angehen kann!? Könnt Ihr mir ein
> gutes Buch empfehlen oder sonst was, damit ich schnell und vorallem mit ein
> wenig Spass vorrankomme.
Der Stroustrup ist kein Lernbuch, auch wenn er das Standardwerk ist.
In ein paar Monaten kann man die Semantik von C++ vollständig erlernen,
aber bis du ein guter C++-Programmierer bist, werden noch ein paar Jahre
vergehen.
Schaffe dir die "Effective C++ Programming" Bücher von Scott Meyer an.
> Habe bis Ende August 2001 recht viel Zeit und Lust mich in diese Materie
> einzuarbeiten und möchte bis dahin ein paar kleine Programme programmieren
> und Code lesen bzw. abändern können. KDE-Programmierung würde mich
> irgendwie reizen :-) Ist dies eigentlich in dieser Zeit machbar?
Vergiß es. Es gibt viel zu viele GUI-"Programmierer" und viel zu wenige
richtige Programmierer. Wer mit Sachen wie KDE anfängt, lernt die
Sprache nie wirklich und konditioniert sich selber auf das Schreiben von
riesigen Monster-Programmen, ohne je ein Gefühl für die Maschine und die
Feinheiten der Sprache zu kriegen.
Fang mit GUI-Zapp an, wenn du den Rest kannst.
Felix
Thomas Riegler
>Thus spake Severin Olloz (S.O...@soid.ch):
>> Nun habe mich nun entschlossen C++ natürlich unter UNIX zu erlernen.
>Lerne erstmal C.
Wieso das? C hat mit C++ nicht allzuviel zu tun (ausser der Syntax teilweise).
Wenn der OP C++ lernen möchte dann sollte er sich IMO ein C++-Buch kaufen
anstatt ein C-Buch.
MfG
Thomas
--
C C ICQ: #99303362
V
Benedikt Meurer
<usenet-...@fefe.de>:
> Thus spake Severin Olloz (S.O...@soid.ch):
>> Nun habe mich nun entschlossen C++ natürlich unter UNIX zu erlernen.
>
> Lerne erstmal C.
Diese Aussage ist durchaus sinnlos, da C und C++ zwei völlig verschiedene
Sprachen sind, auch wenn C++ aus C entstanden ist. Aber C++ ist eine
objektorientierte Sprache, während C eine prozedurale Sprache ist, C++
folgt also ganz anderen Konzepten. Sicher ist es möglich in C auch objekt
orientiert zu programmieren (soll ja sogar Leute geben, die Assembler
nach OO-Grundsätzen programmieren), ebenso wie es möglich ist, in C++
prozedural zu programmieren. Deshalb ist C aber noch lange keine
Voraussetzung für C++. Ist in etwa so unsinnig, als würde man sagen: Wenn
du C lernen willst, lern erstmal B, jedoch wenn du B lernen willst, lern
erstmal BCPL.
>> Aber C++ ist für mich immernoch ein Buch mit sieben Siegeln, darum
>> frage ich Euch wie ich das Monster am besten angehen kann!? Könnt Ihr
>> mir ein gutes Buch empfehlen oder sonst was, damit ich schnell und
>> vorallem mit ein wenig Spass vorrankomme.
> Der Stroustrup ist kein Lernbuch, auch wenn er das Standardwerk ist.
> In ein paar Monaten kann man die Semantik von C++ vollständig erlernen,
> aber bis du ein guter C++-Programmierer bist, werden noch ein paar Jahre
> vergehen.
ACK!
>> Habe bis Ende August 2001 recht viel Zeit und Lust mich in diese
>> Materie einzuarbeiten und möchte bis dahin ein paar kleine Programme
>> programmieren und Code lesen bzw. abändern können. KDE-Programmierung
>> würde mich irgendwie reizen :-) Ist dies eigentlich in dieser Zeit
>> machbar?
>
> Vergiß es. Es gibt viel zu viele GUI-"Programmierer" und viel zu wenige
> richtige Programmierer. Wer mit Sachen wie KDE anfängt, lernt die
> Sprache nie wirklich und konditioniert sich selber auf das Schreiben von
> riesigen Monster-Programmen, ohne je ein Gefühl für die Maschine und die
> Feinheiten der Sprache zu kriegen.
>
> Fang mit GUI-Zapp an, wenn du den Rest kannst.
Wobei noch gerade bei KDE die hohe Abstraktion durch QT hinzukommen, man
also eigentlich nie "wirklich" programmiert, wenn man QT voll ausnutzt,
da es hier für alles - angefangen von einfachen String bis hin zu Sockets
- Abstrakte Objektklassen gibt, was das "Gefühl für die Maschine" (wie
Felix es so treffend formulierte) natürlich nicht wirklich fördert.
Das soll kein Vorwurf an QT sein, aber für einen Anfänger ist QT - meiner
Ansicht nach - doch etwas zu weit von der Maschine/Hardware abstrahiert,
um damit effizientes programmieren zu lernen. Besagter Anfänger könnte
sonst hinterher auf die Idee kommen z.B. für jeden noch so
winzige/witzlose Zeichenkette ein QString Objekt zu verwenden, was dann
natürlich im Vergleich zu einem normalen Bytezeiger, der in dieser
Situation vollkommen gereicht hätte, eine enorme Verschwendungen an
Resourcen (Memory und CPU, da auch immer erst ein QString Objekt erzeugt
werden muss, etc.) bedeuten würde, und seine Programme würden zu
"riesigen Monster-Programmen" (Z. Felix).
Frohe Ostern
Mit freundlichen Grüßen
Benedikt Meurer
Christoph Kliemt
F> Thus spake Severin Olloz (S.O...@soid.ch):
>> Nun habe mich nun entschlossen C++ natürlich unter UNIX zu
>> erlernen.
F> Lerne erstmal C.
*Gnade* :-/
[...]
F> Schaffe dir die "Effective C++ Programming" Bücher von Scott
F> Meyer an.
Ja, das ist ne Idee. Allerdings wär wohl erstmal ne Trainingseinheit
in OO-Denken angesagt.
[...]
F> Vergiß es. Es gibt viel zu viele GUI-"Programmierer" und viel zu
F> wenige richtige Programmierer. Wer mit Sachen wie KDE anfängt,
F> lernt die Sprache nie wirklich und konditioniert sich selber auf
F> das Schreiben von riesigen Monster-Programmen, ohne je ein Gefühl
F> für die Maschine und die Feinheiten der Sprache zu kriegen.
Diese Gefahr besteht, allerdings ist qt als Anschauungsbeispiel gar
nicht mal so schlecht.
Mein Vorschlag:
- qt tutorial nachprogrammieren (und ggf versuchen zu verstehen, wie
der signal/slot Mechanismus auf Quelltextebene funktioniert)
- Dann mal die Begriffe "stl" "c++" "tutorial" in eine Suchmaschine
deiner Wahl reinwerfen. Und dann mal versuchen das
nachzuvollziehen.
Wenn Du soweit bist, dann weißt Du selber, welche Bücher für Dich die
richtigen sind. :-)
F> Fang mit GUI-Zapp an, wenn du den Rest kannst.
Jepp.
\\// christoph
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real
Programmer wants a "you asked for it, you got it" text editor --
complicated, cryptic, powerful, unforgiving, dangerous.
Florian Weimer
> Felix von Leitner <usenet-...@fefe.de> wrote:
> >Lerne erstmal C.
>
> Wieso das? C hat mit C++ nicht allzuviel zu tun (ausser der Syntax
> teilweise).
Viele Probleme von C finden sich auch in C++ wieder. Die Beherrschung
von C ist daher sinnvoll, bevor man sich den zusätzlichen Problemen
von C++ aussetzt.
Wenn man noch nicht mit objektorientierten Konzepten vertraut ist,
sollte man diese auch irgendwie aneignen (mit C++ ist das nicht
unbedingt leicht).
Sascha Ziemann
| Immer wieder frage ich mich was der Compiler denn da eigentlich macht wenn
| ich wieder mal ein Programm backe und ich bin öfters daran gestossen: Warum
| kann das dieses Programm nicht und warum kann ich das nicht selber
| implementieren?
|
| Nun habe mich nun entschlossen C++ natürlich unter UNIX zu
| erlernen.
Unix definiert sich in Bezug auf das, was für einen Programmierer
interessant ist, durch die C-Library. Und die Relevanz von C++ für
die C-Library dürfte noch unter der von Fortran liegen. Sprich:
Unix-Programmierung hat exakt überhaupt nichts mit C++ zu tun, was man
auch sehr leicht daran sehen kann, dass in den Stevens-Büchern, die
wohl die mit Abstand besten Bücher zum Thema Unix-Programmierung sind,
keine einzige Zeile C++ zu finden ist.
| Programmiere schon in Perl und PHP und hatte mal einen Kurs für C++
| Programmierung unter Windows genommen und bringe somit schon ein wenig
| Erfahrung mit.
|
| Aber C++ ist für mich immernoch ein Buch mit sieben Siegeln, darum frage
| ich Euch wie ich das Monster am besten angehen kann!?
Gar nicht!
Wenn man C++ programmiert, sitzt man immer zwischen den Stühlen. Für
die Erstellung von Bibliotheken ist die aufgeblasene möchtegern
OO-Syntax keinesfalls den Aufwand wert, den man investieren muss, um
sie zu erlernen, und für die Erstellung von Anwendungen ist C++
aufgrund zu vieler Defizite wenig brauchbar.
C++ ist nur deswegen weit verbreitet, weil die Hersteller proprietärer
Software, den Quellcode ihrer Programme nicht offenlegen wollen, aber
trotzdem zumindest ein bischen den Komfort einer richtigen Hochsprache
haben wollen. Als Entwickler von Freier Software sollte man sich
nicht freiwillig diese Geissel auferlegen, zumal ja inzwischen auch im
Lager der Windows-Programmierer C++ ein Auslaufmodell darstellt, wenn
man dem NET-Geschwafel Glauben schenkt.
Die Benutzung einer richtigen Hochsprache wie CL, Perl, Guile, Java
oder Python, für die man bei Bedarf rechenintensive Algorithmen in C
implementieren kann, ist unterm Strich immer effizienter.
Anstatt seine Zeit damit zu verplempern, sich durch die ultimative
Syntax-Orgie zu quälen (die C++ Syntax wird wohl nur noch von VHDL
getopt), sollte man sich mal von Leuten, die wirklich was von
Programmierung verstehen, das Wesentliche beim Programmieren erläutern
lassen, indem man z.B. von Abelson und Sussman das Buch "Structure and
Interpretation of Computer Programs" liest.
Aber sei gewarnt: solltest du irgendwann um dir deine Brötchen zu
verdienen wirklich mal C++ programmieren müssen, wirst du dies nur
noch unter schweren Depressionen machen können, wenn du erst einmal
gesehen hast, wie einfach und flexibel Programmieren sein kann.
bis später...
Sascha
--
Ein Hoch auf den 7. Juni 2000
Juergen Hoetzel
> F> Vergiß es. Es gibt viel zu viele GUI-"Programmierer" und viel zu
> F> wenige richtige Programmierer. Wer mit Sachen wie KDE anfängt,
> F> lernt die Sprache nie wirklich und konditioniert sich selber auf
> F> das Schreiben von riesigen Monster-Programmen, ohne je ein Gefühl
> F> für die Maschine und die Feinheiten der Sprache zu kriegen.
>
> Diese Gefahr besteht, allerdings ist qt als Anschauungsbeispiel gar
> nicht mal so schlecht.
> Mein Vorschlag:
> - qt tutorial nachprogrammieren (und ggf versuchen zu verstehen, wie
> der signal/slot Mechanismus auf Quelltextebene funktioniert)
Keine gute Idee, sonst kommt er noch auf die Idee, dass signal/slot ein
C++ Schluesselwort ist. Ich finde die ganze Sache mit dem "moc" Preprozessor
ziemlich unschoen fuer eine C++/Bibliothek.
Juergen
Oliver Bandel
Vielleicht mal Objective-C anschauen.
Hat C-Syntax mit orthogonaler Erweiterung um von Smalltalk
abgeleitetem OO-Ansatz.
Tschüß,
Oliver
--
The direct combination of functions by means of the operator '.' which we
have seen here is not possible in other programming paradigms, or at least
it would be an 'advanced' aspect of the language, rather than appearing on
page 11 of an introductory text. (Simon Thompson, "Haskell")
Rolf Magnus
> Keine gute Idee, sonst kommt er noch auf die Idee, dass signal/slot ein
> C++ Schluesselwort ist. Ich finde die ganze Sache mit dem "moc"
> Preprozessor ziemlich unschoen fuer eine C++/Bibliothek.
Wieso? Wozu gibts Makefiles?
Ich finde signale/slots wahnsinnig praktisch und finde es anders rum
unschön, daß Sprachen wie C++ sowas nicht gleich mitbringen.
Uwe Witte
Severin Olloz schrieb in Nachricht <9bc5ef$r15$1...@news.imp.ch>...
Hallo zusammen...
>Immer wieder frage ich mich was der Compiler denn da eigentlich macht wenn
>ich wieder mal ein Programm backe und ich bin öfters daran gestossen: Warum
>kann das dieses Programm nicht und warum kann ich das nicht selber
>implementieren?
...
>Aber C++ ist für mich immernoch ein Buch mit sieben Siegeln, darum frage
>ich Euch wie ich das Monster am besten angehen kann!? Könnt Ihr mir ein
Hallo Severin,
Wenn du wirklich verstehen möchtest wie es funktioniert , lerne erst
Assembler.
Alles was mit Overloading, virtuellen Methoden usw. zu tun hat war für mich
ein Buch mit sieben Siegeln.
Ich kam mir immer vor als wenn ich versuche eine Japanische Tageszeitung zu
lesen. (Wieherrum halten ?)
Bis ich mir zu kleinen, möglichst einfachen Beispielen den erzeugten
Assembler-Code anschaute.
So in etwa: ´mov ebx, [ebp+8] ; push ebx ; mov ebx, [ebx] ; call [ebx+4]´
ist der Kern zu meinem Verständnis gewesen. :)
Gruss
Uwe
Benedikt Meurer
<Uwe....@de.bosch.com>:
> Wenn du wirklich verstehen möchtest wie es funktioniert , lerne erst
> Assembler.
Wo ist denn da die Logik?
> Alles was mit Overloading, virtuellen Methoden usw. zu tun hat war für
> mich ein Buch mit sieben Siegeln.
> Ich kam mir immer vor als wenn ich versuche eine Japanische Tageszeitung
> zu lesen. (Wieherrum halten ?)
Wenn C++ ne Japansiche Tageszeitung ist, was ist dann blos Assembler? Das
Alte Testament in der Original Version? ;-)
> Bis ich mir zu kleinen, möglichst einfachen Beispielen den erzeugten
> Assembler-Code anschaute.
> So in etwa: ´mov ebx, [ebp+8] ; push ebx ; mov ebx, [ebx] ; call
> [ebx+4]´ ist der Kern zu meinem Verständnis gewesen. :)
Die Logik ist wie gesagt nicht ganz verständlich: Hochsprachen wie C++,
Java oder Pascal sind ja eben dazu da auf höherer Ebene zu programmieren,
also nicht auf Assemblerebene. Somit ist es zunächst vollkommen unsinnig,
C++ mit Assembler zu verstehen, da man dort zwar das Codeouput versteht
(wohlgemerkt _nur_ auf einer Maschine, es gibt aber neben dem i386 auch
noch andere Plattformen mit c++ Compiler), aber nicht das eigentliche
Konzept hinter der jeweiligen Konstruktion. Zum zweiten will man ja
(jedenfalls die meisten) plattformübergreifende Programme schreiben, wo es
dann wesentlich hilfreicher ist, das Konzept verstanden zu haben, statt
dem ASM Output, der eh (fast) überall unterschiedlich ist (hier reicht
schon ein anderer Compiler und der Code sieht anders aus).
Immo 'FaUl' Wehrenberg
Assembler ist Logik, C++ ist ein gescheiterter Versuch einen Kompromiss
zwischen Menschlicher und Computersprache zu finden.
> Die Logik ist wie gesagt nicht ganz verständlich: Hochsprachen wie C++,
> Java oder Pascal sind ja eben dazu da auf höherer Ebene zu programmieren,
> also nicht auf Assemblerebene.
Man braucht Assembler um die Funktionsweise eines Computers zu verstehen,
die Sprache lernt man dann in ein paar Tagen.
FaUl
--
[Felix von Leitner in de.comp.security.misc über MS-Exchange]
Endlich mal ein Sicherheitskonzept von Microsoft, das funktioniert.
Sicherheit durch sofortigen und dauerhaften Absturz.
Benedikt Meurer
"Immo 'FaUl' Wehrenberg" <im...@faul.holomann.de>:
> Benedikt Meurer schrieb:
>> Im Artikel <9bhrms$d8m$1...@proxy.fe.internet.bosch.com> schrieb "Uwe
>> Witte" Wenn C++ ne Japansiche Tageszeitung ist, was ist dann blos
>> Assembler?
> Assembler ist Logik, C++ ist ein gescheiterter Versuch einen Kompromiss
> zwischen Menschlicher und Computersprache zu finden.
Da stimm ich dir zu.
>> Die Logik ist wie gesagt nicht ganz verständlich: Hochsprachen wie C++,
>> Java oder Pascal sind ja eben dazu da auf höherer Ebene zu
>> programmieren, also nicht auf Assemblerebene.
> Man braucht Assembler um die Funktionsweise eines Computers zu
> verstehen, die Sprache lernt man dann in ein paar Tagen.
Es geht auch nicht um die Sprache, sondern um das Konzept (bei C++ ist
das OOP)! Und ich wage mal zu bezweifeln, dass es dir viel hilft, wenn du
den i386er auswendig kannst, und sollst dann auf einer PDP-11 (oder einem
Embedded Gerät) ein Programm in C++ implementieren, dann wirst du nämlich
ziemlich dumm gucken, was dort auf Assemblerebene rauskommt.
Klar, ist es von Vorteil Assembler zu können, jedoch nicht um das Konzept
einer Hochsprache zu verstehen, sondern nur um die Arbeit der Maschine zu
verstehen, die in der Hochsprache programmiert wird. Versuch mal in
Assembler mit dem OOP Konzept ein grosses Programm zu schreiben, dann
verstehst du den kleinen aber entscheidenden Unterschied.
Immo 'FaUl' Wehrenberg
> Es geht auch nicht um die Sprache, sondern um das Konzept (bei C++ ist
> das OOP)! Und ich wage mal zu bezweifeln, dass es dir viel hilft, wenn du
> den i386er auswendig kannst, und sollst dann auf einer PDP-11 (oder einem
> Embedded Gerät) ein Programm in C++ implementieren, dann wirst du nämlich
> ziemlich dumm gucken, was dort auf Assemblerebene rauskommt.
Ich habe nie gesagt, das man sich jeden Output angucken soll, oder gar
nur in Assembler Programmieren soll (Btw.: Echte Programmierer schreiben
Binary-Code: 1011000101011 ;-), ich habe nur gesagt das Assembler hilft,
den Computer zu verstehen und das auch hilft, Funktionsweisen der Sprache
zu verstehen. Wie soll man sonst lernen mit z.b pointern umgehen zu können?
> Versuch mal in
> Assembler mit dem OOP Konzept ein grosses Programm zu schreiben, dann
> verstehst du den kleinen aber entscheidenden Unterschied.
Ich habe immer noch nicht richtig begriffen, was OOP überhaupt ist. Ich
bin scheinbar zu doof. Kann mir mal einer Objekt (im Sinne von OOP)
Definieren? Ich kann mir darunter garnichts Vorstellen.
FaUl
--
Lauferk C: Formatieren?
[J]a [N]a klar
Jens Dittmar
> Die Benutzung einer richtigen Hochsprache wie CL, Perl, Guile, Java
> oder Python,
*hüstel* Zumindest mein Guile spricht zum Glück noch so etwas wie ein
halbwegs normales R4-Scheme. ;)
> für die man bei Bedarf rechenintensive Algorithmen in C
> implementieren kann, ist unterm Strich immer effizienter.
Yep, ich erlaube mir, hier noch Tcl anzufügen - die Sprache mit dem
smartesten mir bekannten C-Interface.
Jens
--
There's a silence where you used to be
Just an empty space in history
Rainer Weikusat
> <Uwe....@de.bosch.com>:
> > Wenn du wirklich verstehen möchtest wie es funktioniert , lerne erst
> > Assembler.
>
> Wo ist denn da die Logik?
Wenn man weiß, wie es am unteren Ende aussieht, trägt das zum
Verständnis darüberliegender Ebenen bei.
> Wenn C++ ne Japansiche Tageszeitung ist, was ist dann blos
> Assembler?
In diesem Bild: Das (bzw eins der) japanische Alphabet(e).
> > So in etwa: ´mov ebx, [ebp+8] ; push ebx ; mov ebx, [ebx] ; call
> > [ebx+4]´ ist der Kern zu meinem Verständnis gewesen. :)
>
> Die Logik ist wie gesagt nicht ganz verständlich:
Sie ist es. 'Virtuelle Methode' ist ein sehr viel abstrakteres Konzept
als 'compilergenerierte Sprungtabelle'. 'Verstanden' habe ich das
dann, wenn ich weiß, was es bedeutet.
> Somit ist es zunächst vollkommen unsinnig,
> C++ mit Assembler zu verstehen,
Es ist nicht nur nicht unsinnig sondern die einzige
Möglichkeit. Allerdings muß man die Mechanismen nicht verstehen, um
sie sinnvoll benutzen zu können (obwohl man sich darüber streiten
könnte).
> (wohlgemerkt _nur_ auf einer Maschine, es gibt aber neben dem i386 auch
> noch andere Plattformen mit c++ Compiler),
Auf denen werden 'virtuelle Methoden' nichtsdestotrotz auf ähnliche
Weise realisiert.
--
SIGSTOP
Rainer Weikusat
> Versuch mal in Assembler mit dem OOP Konzept ein grosses Programm zu
> schreiben,
Es gibt (oder gab) übrigens sogar OO-Assembler.
--
SIGSTOP
Rainer Weikusat
> Ich habe immer noch nicht richtig begriffen, was OOP überhaupt ist. Ich
> bin scheinbar zu doof. Kann mir mal einer Objekt (im Sinne von OOP)
> Definieren?
Vereinigungsmenge von 'Datenstruktur' und 'darauf definierter
Operationen'.
Üblicherweise will (und hat) man allerdings polymorphe Objekte, dh
zu dem obengenannten kommt noch 'Compilerunterstützung für
Methodenauswahl anhand von Argumenttypen zur Laufzeit' dazu. Bei
simplen Ansätzen (zB C++) nur anhand eines (impliziten) ersten
Argumentes, in anderen Sprachen (CLOS, Ada) potentiell anhand aller
Argumente.
--
SIGSTOP
Rainer Weikusat
> Für die Erstellung von Bibliotheken ist die aufgeblasene möchtegern
> OO-Syntax keinesfalls den Aufwand wert, den man investieren muss, um
> sie zu erlernen,
Durchaus nicht. Zb kann man damit transparent und am theoretischen
Aufwandsminimum Threads wie 'normale Funktionen' mit Argumenten
aufrufen (allerdings, da muß ich Dir recht geben, möchte man die
entsprechenden templates schreiben und dann schnell wieder
vergessen).
> und für die Erstellung von Anwendungen ist C++ aufgrund zu vieler
> Defizite wenig brauchbar.
Maschinenahe Sprachen sind maschinenah. Je nach Anwendung rangiert das
unter 'Nachteil', 'Vorteil', 'notwendige Bedingung' oder
'überflüssiger Aufwand'.
> Die Benutzung einer richtigen Hochsprache wie CL, Perl, Guile, Java
> oder Python, für die man bei Bedarf rechenintensive Algorithmen in C
> implementieren kann, ist unterm Strich immer effizienter.
Der Blödsinn ist seit dem letzten Mal nicht richtiger geworden und
sogar die Perl-FAQ weiß es besser. 'Effizient bezogen auf was?' fehlt
hier als Fragestellung. Mögliche Kategorien (nicht aussschließlich):
Speicherverbrauch, CPU-Belastung, Entwicklungsaufwand ...
> Anstatt seine Zeit damit zu verplempern, sich durch die ultimative
> Syntax-Orgie zu quälen
[...]
> wie einfach und flexibel Programmieren sein kann.
Bla bla bla. Bitte entferne alle C- und C++-Programme von Deinem
Rechner und versuche, den Rest mit Perl zu benutzen.
--
SIGSTOP
Uwe Witte
>
>> Somit ist es zunächst vollkommen unsinnig,
>> C++ mit Assembler zu verstehen,
>
>Es ist nicht nur nicht unsinnig sondern die einzige
>Möglichkeit. Allerdings muß man die Mechanismen nicht verstehen, um
>sie sinnvoll benutzen zu können (obwohl man sich darüber streiten
>könnte).
>
Danke.
Tausende Menschen fahren Auto ohne etwas von Verbrennungsmotoren zu
verstehen.
Nicht schlimm.
Mir graut aber vor tausenden von Programmierern die keine ´Basics´ mehr
haben.
Das darunterliegende nicht verstehen und riesenmonsterresourcenfressende
Programme
in sicher elegant abgehobenen Hochsprachen produzieren.
Gruss
Uwe
Sascha Ziemann
| Ich habe immer noch nicht richtig begriffen, was OOP überhaupt ist. Ich
| bin scheinbar zu doof. Kann mir mal einer Objekt (im Sinne von OOP)
| Definieren? Ich kann mir darunter garnichts Vorstellen.
C++ ist kein besonders geeignetes Anschauungsmaterial, um zu lernen
was OOP ist, weil man erst mal Tonnen von Syntax lernen muss, bis man
überhaupt anfangen kann.
Im Kern basiert OOP auf der Erzeugung von Datenblöcken, die gleiche
Funktionen teilen. Das läßt sich in Scheme sehr leicht
veranschaulichen.
Dazu muss man evtl. ein paar Worte zur Syntax von Scheme fallen
lassen. In Scheme werden Funktionsaufrufe zusammen mit den Argumenten
in die Klammern geschrieben:
C: Scheme:
printf ("Hello World"); (display "Hello World")
Es gibt keine Unterscheidung zwischen Funktionen und Operatoren.
Jeder Operator ist eine Funktion:
C: Scheme:
add (1, 2); (add 1 2)
1 + 2 (+ 1 2)
Es gibt optisch keinen Unterschied zwischen Syntax und
Funktionsaufrufen. Funktionen werden durch den Lambda-Operator
erzeugt:
(lambda (a)
(* a a))
Dadurch wird eine Funktion mit dem Parameter "a" erzeugt, die das
Quadrat des Arguments berechnet. Will man das Quadrat von 5
berechnen, benutzt man das Ergebnis des obigen Lambda-Operators
einfach in einem weiteren Funktionsaufruf:
((lambda (a)
(* a a))
5)
In C kann man sowas gar nicht hinschreiben, da der Lambda-Operator
Funktionen ohne Namen erzeugt und man in C jeder Funktion auch einen
Namen geben muss. In Scheme kann man sich selber aussuchen, ob man
der Funktion einen Namen gibt. Die Namensgebung geschieht über den
Define-Operator. Das gleiche Beispiel aber diesmal mit Namen sieht
folgendermaßen aus:
(define quadrad (lambda (a)
(* a a)))
(quadrad 5)
Dadurch, dass man "on-the-fly" Funktionen erzeugen kann, kann man auch
Funktionen programmieren, die als Rückgabewert eine Funktion erzeugen:
(define make-adder (lambda (x)
(lambda (y)
(+ x y))))
Dadurch kann man z.B. eine Funktion erzeugen, die zu ihrem Argument
immer 8 hinzuaddiert:
(define add8 (make-adder 8))
Ein
(add8 3)
liefert somit 11 als Ergebnis. Und das ganze können wir auch für 5
machen:
(define add5 (make-adder 5))
Und sieht da: fertig sind die Objekte. Wir haben nun zwei
Kombinationen, bei denen jeweils unterschiedlichen Daten nämlich 5 und
8 mit der gleichen Funktion nämlich make-adder kombiniert werden. Das
ist die entscheidende Grundidee von OOP. Alles Weitere ist nur noch
Ausschmückung dieses Konzepts (auch syntaktischer Zucker genannt).
Beispielsweise möchte man unterschiedliche Funktionen an Daten
binden. Das sind dann die Methoden. Und man muss die Methoden
unterscheiden können anhand unterschiedlicher Namen, womit wir die
Slots hätten. Und man möchte Gruppen von Methoden zusammenfassen,
womit wir bei Klassen wären. Und diese Klassen sollen durch
Kombination anderer Klassen erzeugbar sein, womit wir Vererbung
hätten. Und man möchte Methoden und gewöhnliche Funktionen in
gleicher Weise benutzen können, womit wir Polimorphismus hätten.
Das Beispiel mit dem Addierer geht übrigens auf einen Artikel im
Scheme Repository zurück:
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/swob.txt
Im Grunde genommen ist OOP gar nicht besonders kompliziert.
Kompliziert wird es nur, wenn man auf die Idee kommt, C++ zu lernen.
Und bei Stroustrup kann man auch nachlesen, warum das so ist. Ziel
der Entwicklung von C++ war es, OOP mit möglichst wenig Anforderungen
an die Hardware zu ermöglichen. Deswegen hat die OOP bei C++ auch
gelitten und wird dann hinterher durch Erfindungen wie MOC wieder
aufgebohrt. Erst wird der Hund kastriert, um ihm hinterher wieder ein
Paar Eier anzukleben. Und manche Leute finden das auch noch toll.
Man tut sich also keinen besonderen Gefallen, wenn man OOP anhand von
C++ lernen will. Statt dessen sollte man sich lieber mal das Original
also Smalltalk ansehen oder bei Common Lisp nachlesen, was ein Meta
Object Protocol. Und wenn man dann weiss was OOP ist, kann man
sein Glück mit C++ versuchen. Und dann wird einem MOC auch als Segen
vorkommen. Aber nicht weil es so eine tolle Erfindung ist, sondern
weil es die Schmerzen lindert.
Wer mit Guile ein MOP (Meta Object Protocol) benutzen möchte, findet
Goops bestimmt interessant:
http://www.gnu.org/software/goops/goops.html
Sascha Ziemann
| > Die Benutzung einer richtigen Hochsprache wie CL, Perl, Guile, Java
| > oder Python, für die man bei Bedarf rechenintensive Algorithmen in C
| > implementieren kann, ist unterm Strich immer effizienter.
|
| Der Blödsinn ist seit dem letzten Mal nicht richtiger geworden und
| sogar die Perl-FAQ weiß es besser. 'Effizient bezogen auf was?' fehlt
| hier als Fragestellung. Mögliche Kategorien (nicht aussschließlich):
| Speicherverbrauch, CPU-Belastung, Entwicklungsaufwand ...
Effizient bezogen auf den Entwicklungsaufwand und heutige
PC/Workstation-Hardware. Worum sollte es wohl sonst gehen bei einer
so allgemeinen Diskussion?
| Bla bla bla. Bitte entferne alle C- und C++-Programme von Deinem
| Rechner und versuche, den Rest mit Perl zu benutzen.
Es ging nicht darum irgendeine Sprache zu verbannen, sondern darum wie
man bei neuen Projekten schnell zum Ziel kommt. Klar dass man bei
harten Echtzeitanforderungen mit einem GC ein Problem bekommt. Die
Gruppe heisst allerdings unix.programming und deshalb hatte ich auch
primär nur gewöhnliche Unix-Anwendungen im Sinn.
Rainer Weikusat
> PC/Workstation-Hardware.
Sowie 'geringe zu verarbeitende Datenmengen' (leider auch ein
Wabbelbegriff) und 'wenige gleichzeitig laufende Instanzen' (ggf
könnte man die Liste verlängern).
--
SIGSTOP
Arnim Weidner
>
> Aber C++ ist für mich immernoch ein Buch mit sieben Siegeln, darum frage
> ich Euch wie ich das Monster am besten angehen kann!?
> schnell und vorallem mit ein wenig Spass vorrankomme.
Es gibt eine NG zu C++: de.comp.lang.iso-c++. Die hat ne FAQ mit
einer Buecher Sektion: http://www.voyager.prima.de/cpp/books2.html
IMHO empfehlenswert sind die Jossutis und Meyers Buecher. Das
Stroustrup Buch ist fuer Einsteiger nicht empfehlenswert, eher fuer
Compilerbauer oder Library Entwickler.
BTW. schnell vorankommen ist bei C++ nicht. Ich schreibe schon seit
ca. 7 Jahren Programme in C++ und kann Dir ganz bestimmt sagen,
dass ich von C++ nur die Haelfte verstanden hab, obwohl ich meinen
Unterhalt mit Programmieren finanziere. C++ ist unnoetig kompliziert.
Such Dir ein Buch in dem OOP mit C++ erklaert wird. Also nicht
solche die den Umstieg von C beschreiben. Auch wenn einige es
nicht wahrhaben wollen C und C++ sind 2 unterschiedliche Sprachen
die vom Programmieransatz her nichts miteinander zu tun haben.
Wenn Du OOP direkt lernen willst nimm lieber Smalltalk, Eiffel
Objective C oder Python. C++ ist ein schlechtes Beispiel fuer OOP.
Der Templateansatz ist IMHO nur aufgepfropft und schlecht in die
Objektorientierung intergriert. Genauso die Unterscheidung von
Containern und Objekten.
> Habe bis Ende August 2001 recht viel Zeit und Lust mich in diese Materie
> einzuarbeiten und möchte bis dahin ein paar kleine Programme programmieren
> und Code lesen bzw. abändern können. KDE-Programmierung würde mich
> irgendwie reizen :-) Ist dies eigentlich in dieser Zeit machbar?
KDE und QT ist nicht schwer. Allerdings siehst Du dabei auch
sofort die Grenzen der ISO C++ Syntax. Ohne einen eigenen
Precompiler geht da nichts. D.h. wenn Du QT programmierst,
benutzt Du kein ISO C++, obwohl die signal/slot Geschichte
IMHO genial ist und den OOP Grundsatz besser wiederspiegelt
als ISO C++.
Fuer KDE Programmierung findet man hier Infos:
http://developer.kde.org/
Du solltest Dir allerdings bewusst sein, dass Du nur eine
Bibliothek fuer C++ programmierst ohne die Moeglichkeiten
von C++ dabei voll auszunutzen. Weiter behindert meist die
sofortige grafische Programmierung die Abstraktion in Teil-
Probleme. -> Monsterprogramme mit schlecht wartbarem und
wiederverwendbarem Code. Ich schreib z.B. in C++ nur
geschwindigkeitskritische Bibliotheken, das User Interface
laeuft i.Allg. ueber Scriptsprachen.
HTH, Gruss
Arnim
Rolf Magnus
> Tausende Menschen fahren Auto ohne etwas von Verbrennungsmotoren zu
> verstehen.
> Nicht schlimm.
Sie fahren ja die Autos nur und bauen sie nicht. Wenn der User eines
Programmes nix davon versteht, was ein Prozessor für Befehle ausführt ist
das auch nicht schlimm.
Stefan Reuther
Und warum muß man sich mit der Krücke `moc' rumschlagen, wo man
das doch direkt in C++ implementieren könnte?
Stefan
Rolf Magnus
> Und warum muß man sich mit der Krücke `moc' rumschlagen, wo man
> das doch direkt in C++ implementieren könnte?
Und zwar wie?
King Leo (Martin Oberzalek)
> Severin Olloz schrieb:
> >
> > Aber C++ ist für mich immernoch ein Buch mit sieben Siegeln, darum frage
> > ich Euch wie ich das Monster am besten angehen kann!?
> > Könnt Ihr mir ein gutes Buch empfehlen oder sonst was, damit ich
> > schnell und vorallem mit ein wenig Spass vorrankomme.
>
> Stroustrup Buch ist fuer Einsteiger nicht empfehlenswert, eher fuer
> Compilerbauer oder Library Entwickler.
Oder für Leute die es einfach wissen wollen.
> KDE und QT ist nicht schwer. Allerdings siehst Du dabei auch
> sofort die Grenzen der ISO C++ Syntax. Ohne einen eigenen
> Precompiler geht da nichts.
Stimmt nicht, sieh dir gtk-- und die libsigc++ an.
Dort wird demonstriert, dass man es sehrwohl auch ohne Precompiler
machen kann.
--
Make it so!
Anselm Lingnau
Rainer Weikusat <weik...@mail.uni-mainz.de>:
> Sowie 'geringe zu verarbeitende Datenmengen' (leider auch ein
> Wabbelbegriff) und 'wenige gleichzeitig laufende Instanzen' (ggf
> könnte man die Liste verlängern).
Bla, bla, bla. Das haben wir alles neulich schon gehört.
Eine wichtige Maxime beim Programmieren lautet »Make it work, *then*
make it work faster«. Und die neumodischen Sprachen sind *extrem*
hilfreich dabei, Sachen in vertretbarer Zeit zum Laufen zu bringen.
Wenn sich dann herausstellt, daß gewisse Teile des Programms zu
langsam sind, *dann* kann man anfangen, an C o.ä. zu denken (wenn
einem kein besserer Algorithmus einfällt).
Jedenfalls hat es keinen Zweck, ein 100.000-Zeilen-Programm in C zu
schreiben, wenn 98% des Rechenaufwands in 2.000 Zeilen des Codes
erbracht werden. Sobald man das weiß, kann man die betreffenden 2.000
Zeilen (oder einen Teil davon) in einer Sprache wie C implementieren
und den Rest des Codes, der in einer Sprache wie Python oder Tcl
tendenziell viel kürzer sein wird als 98.000 Zeilen, nämlich eher
20.000 Zeilen oder so, in dieser Sprache stehen lassen.
Es gibt jedenfalls keinen vernünftigen Grund, eine Skriptsprache nicht
zum Prototyping einzusetzen, selbst wenn man bereit ist, später
kritische Programmteile in C o.ä. zu schreiben. Denn erstens könnte es
durchaus sein, daß das Programm in der Skriptsprache schon effizient
genug läuft (und man so Wochen an Entwicklungsaufwand spart), und
zweitens ist es, wie oben erwähnt, unklug, ein Riesenprogramm von
Anfang an komplett in einer unbequemen Sprache wie C zu verfassen,
wenn es reicht, sich dabei auf den Anteil zu beschränken, bei dem man
durch C wirklich was gewinnt. Dies gilt erst recht, wenn das Programm
auf mehr als einer Plattform laufen soll, da man den Python- oder Tcl-
(oder was auch immer)-Teil in der Regel 1:1 übernehmen kann und nur
beim C-Teil mit ernsthaften Portierungsproblemen rechnen muß.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
We consider that any man who can fiddle all through one of those Virginia Reels
without losing his grip may be depended upon in any kind of musical emergency.
-- Mark Twain
Stefan Reuther
> Und zwar wie?
Meine Implementation hab ich Ende Januar in dcl.iso-c++ gepostet.
http://groups.google.com/groups?q=Signal1&hl=de&lr=&safe=off&rnum=2&seld=932983421&ic=1
(bekommt man damit irgendwie die MID raus?)
Stefan
Benedikt Meurer
Reuther" <sr...@inf.tu-dresden.de>:
> Und warum muß man sich mit der Krücke `moc' rumschlagen, wo man das doch
> direkt in C++ implementieren könnte?
Das halte ich für ein Gerücht: Du meinst vermutlich Objective-C, nicht
C++.
Benedikt Meurer
>>> Somit ist es zunächst vollkommen unsinnig, C++ mit Assembler zu
>>> verstehen,
>>
>>Es ist nicht nur nicht unsinnig sondern die einzige Möglichkeit.
>>Allerdings muß man die Mechanismen nicht verstehen, um sie sinnvoll
>>benutzen zu können (obwohl man sich darüber streiten könnte).
>
> verstehen.
> Nicht schlimm.
ACK. Da stimme ich dir zu.
> Mir graut aber vor tausenden von Programmierern die keine ´Basics´ mehr
> haben.
> Das darunterliegende nicht verstehen und riesenmonsterresourcenfressende
> Programme
> in sicher elegant abgehobenen Hochsprachen produzieren.
Aber das ist nicht der Punkt: Dass Assembler zu können eine Notwendigkeit
ist, habe ich nie bestritten. Ich bestreite lediglich, dass Assembler
hilft das Konzept von OO Hochsprachen zu verstehen. Natürlich kann man
sich ein Objekt als eine Abfolge von Speicherzellen mit den Daten, eine
Sprungtabelle für die virtuellen Funktionen und den Funktionen selber im
Code/Text-Bereich vorstellen, dann hat man verstanden, wie es umgesetzt
wird, aber noch immer nicht, was ein Objekt (im höheren Sinne) wirklich
ist, was man am Beispiel von Immo ja auch ganz gut sieht.
Ich persönlich mag C++ (oder andere OO Sprachen) nicht sonderlich gerne,
ich favourisiere C; aber um C++ zu verstehen musste ich trotzdem
umdenken, und nicht mehr in der alten prozeduralen Denkweise an ein
Problem rangehen (die natürlich prima in Assembler zu denken ist),
sondern man muss sich auf das neue Konzept einstellen, sonst kann man
auch gleich bei C oder Assembler bleiben (was IMHO nicht die schlechteste
Wahl ist ;-)).
Rainer Weikusat
> Rainer Weikusat <weik...@mail.uni-mainz.de>:
> > Sowie 'geringe zu verarbeitende Datenmengen' (leider auch ein
> > Wabbelbegriff) und 'wenige gleichzeitig laufende Instanzen' (ggf
> > könnte man die Liste verlängern).
>
Aber scheinbar nicht verstanden. Sondern würde nicht eine knappe Woche
später schon wieder jemand Dummfug des Kalibers 'Skriptsprachen sind
immer effizienter' von sich geben. Skriptsprachen sind immer
ineffizienter. Je nachdem, was ich eigentlich möchte, stellt das
wahlweise ein gravierendes Problem dar oder kann mir völlig egal sein.
--
SIGSTOP
Benedikt Meurer
Reuther" <sr...@inf.tu-dresden.de>:
>>> Und warum muß man sich mit der Krücke `moc' rumschlagen, wo man das
>>> doch direkt in C++ implementieren könnte?
>
>> Und zwar wie?
>
> Meine Implementation hab ich Ende Januar in dcl.iso-c++ gepostet.
> http://groups.google.com/groups?q=Signal1&hl=de&lr=&safe=off&rnum=2&seld=932983421&ic=1
Zugegebenermassen sehr interessant.
> (bekommt man damit irgendwie die MID raus?)
Friedrich Dominicus
> Severin Olloz schrieb:
> >
> > Aber C++ ist für mich immernoch ein Buch mit sieben Siegeln, darum frage
> > ich Euch wie ich das Monster am besten angehen kann!?
> > Könnt Ihr mir ein gutes Buch empfehlen oder sonst was, damit ich
> > schnell und vorallem mit ein wenig Spass vorrankomme.
>
> Es gibt eine NG zu C++: de.comp.lang.iso-c++. Die hat ne FAQ mit
> einer Buecher Sektion: http://www.voyager.prima.de/cpp/books2.html
> IMHO empfehlenswert sind die Jossutis und Meyers Buecher. Das
> Stroustrup Buch ist fuer Einsteiger nicht empfehlenswert, eher fuer
> Compilerbauer oder Library Entwickler.
Ok eine kleine Anmerkung von einem "die-hard" Eiffel
programmierer. Meyers Bücher sind recht gut aber definitv
einseitig. Das bekommt man aber leider erst im Laufe der Zeit
mit,wenn man sich wirklich mit OO beschäftigt hat.
Also immer im Hinterkopf behalten Meyer -> Eiffel -> gut ;-)
Eines der gelungenen Bücher ist wahrscheinlich Object oriented
software construction. Das ist auch nur 1200 Seiten dick ;-)
Mal von einer anderen Warte aus betrachtet bietet sich vielleicht eher
The Art of the Meta Objekt Protocol an. Und für eine Implementierung
des dort vorgeschlagenen MOP kanst Du dir Corman Lisp runterladen und
dich in den Quellen vergraben.
>
> BTW. schnell vorankommen ist bei C++ nicht. Ich schreibe schon seit
> ca. 7 Jahren Programme in C++ und kann Dir ganz bestimmt sagen,
> dass ich von C++ nur die Haelfte verstanden hab, obwohl ich meinen
> Unterhalt mit Programmieren finanziere. C++ ist unnoetig
>kompliziert.
Wow, das habe ich nicht allzu oft von C++ Programmierern
gehört. Leider werden dadurch meine Vorurteile bestätigt. "Ich hab's
ja gleich gewußt" ;-)
>
> Such Dir ein Buch in dem OOP mit C++ erklaert wird. Also nicht
> solche die den Umstieg von C beschreiben. Auch wenn einige es
> nicht wahrhaben wollen C und C++ sind 2 unterschiedliche Sprachen
> die vom Programmieransatz her nichts miteinander zu tun haben.
wäre hier nicht ein sollte angebracht ;-)
>
> Wenn Du OOP direkt lernen willst nimm lieber Smalltalk, Eiffel
> Objective C oder Python.
oder Ruby, Self, Sather, oder ruhig auch Common Lisp ;-)
Bis dann
Friedrich
Arnim Weidner
>
> Sondern würde nicht eine knappe Woche
> später schon wieder jemand Dummfug des Kalibers 'Skriptsprachen sind
> immer effizienter' von sich geben.
Und Du hoerst nicht zu und akzeptierst keine Argumente.
Wegen Leuten wie Dir wird das CERT immer was zu tun haben
und Rechner werden immer zu hacken sein.
> Skriptsprachen sind immer ineffizienter.
Er bestreitet ja gar nicht, dass Scripts langsamer und groesser
sind. Er sagt nur dass es bei Programmen nicht nur auf Groesse,
Resourcenbedarf und Geschwindigkeit ankommt. Sondern es kommt
darauf an, dass es funktioniert. Wenn ein Programm nicht
funktioniert, kann es das auch sehr schnell und effizient tun,
es funktioniert trotzdem nicht.
Bis man weiss was funktioniert nimmt man Skriptsprachen. Weil
da von einem anderen Abstraktionsniveau ausgegangen wird. Dann
nimmt man einen Profiler und schaut wo das Problem liegt, bzw.
ob ueberhaupt Probleme zu erwarten sind. Und dann beseitigt man
nach und nach die Probleme. Das kann auch bedeuten, einen Rewrite
von kritischen Passagen in C/ASM durchfuehren zu muessen. Aber
erst nachdem man dem Kunden etc. mit dem Script bewiesen hat,
das das Gesamtproblem loesbar ist.
Es geht nicht nur um effizienten Code, sondern um effizient
programmierten Code. Und dazu gehoeren gute Algorithmen mit
gutem Zeitverhalten, Vorhersagbarkeit von Ergebnissen, Erfahrung,
Beweis von Fehlerfreiheit, Portierbarkeit, Entwicklungszeit,
Entwicklungsaufwand/kosten, Teamarbeit, Wiederverwendung von
getestetem Code, Einbindung von extern getestetem Code,
reproduzierbare Fehlersituationen, Lesbarkeit und Verstehbarkeit.
Man kann sicher alles selbst machen, aber kaemest Du jemals auf
die Idee Alkohol selbst zu destillieren, weil Du vermutest, dass
das in Schottland ineffektiv gemacht wird, weil die den immer
erstmal 10 Jahre liegen lassen und weil das so ewig dauert bis
er in Deutschland ist? Bei Alkohol, Autos, Kuehlschraenken etc.
kommen die wenigsten auf solche Ideen, aber bei Software wird
das Rad jedesmal neu erfunden.
Gruss
Arnim
Ps.
Ich mag nicht, dass jetzt schon wieder ein Thread von Dir auf das
Thema "Scripts sind Scheisse" umgebogen wird.
F'up2 poster
Immo 'FaUl' Wehrenberg
> To be precise: Das wäre eine Klasse. 'Objekt' bekomme ich durch
> Deklaration einer Variablen des entsprechenden Typs.
Objekt == Variable eines bestimmten Types?
int a;
Ist das ein Objekt in C?
FaUl
--
[Frank Klemm zu Emacs]
Warum werden die Funktionen nicht mit Passwörtern versehen?
Immo 'FaUl' Wehrenberg
brauche OOP nicht wirklich.
Sascha Ziemann schrieb:
> Im Kern basiert OOP auf der Erzeugung von Datenblöcken, die gleiche
> Funktionen teilen. Das läßt sich in Scheme sehr leicht
> veranschaulichen.
Hm, das brauch man aber nur in wirklich großen[TM] Programmen, oder?
> Dazu muss man evtl. ein paar Worte zur Syntax von Scheme fallen
> lassen. In Scheme werden Funktionsaufrufe zusammen mit den Argumenten
> in die Klammern geschrieben:
Was schreibt man in Sheme nicht in Klammern? Kommentare?
> Dadurch, dass man "on-the-fly" Funktionen erzeugen kann, kann man auch
> Funktionen programmieren, die als Rückgabewert eine Funktion erzeugen:
Das ist aber ein Vorteil von Sheme, oder?
> Beispielsweise möchte man unterschiedliche Funktionen an Daten
> binden. Das sind dann die Methoden.
Hm, wozu brauch man das? Braucht man das nur für Altsheimerkranke, die
ständig Funktionsnamen verwechseln, oder hat das auch sonst noch Vorteile?
Hm, mein C-Compiler warnt auch, wenn ich eine Funktion
void foo (int bar)
mit
foo((char)test);
aufrufe.
Habe ich da was nicht verstanden?
> Und man muss die Methoden
> unterscheiden können anhand unterschiedlicher Namen, womit wir die
> Slots hätten.
undefined reference in "Methoden"
Natürlich müssen Funktionen
> Und man möchte Gruppen von Methoden zusammenfassen,
> womit wir bei Klassen wären. Und diese Klassen sollen durch
> Kombination anderer Klassen erzeugbar sein, womit wir Vererbung
> hätten.
Vererbung ist wenn ich
funktion1(aus klasse X) + funktion2 (aus klasse X) + neues_zeuchs = \
klasse foo
sage?
> Und man möchte Methoden und gewöhnliche Funktionen in
> gleicher Weise benutzen können, womit wir Polimorphismus hätten.
Also doch Falsch verstanden. Was ist der unterschied zwischen Funktion und
Methode?
FaUl
--
[Felix von Leitner in de.comp.security.misc über MS-Exchange]
Endlich mal ein Sicherheitskonzept von Microsoft, das funktioniert.
Sicherheit durch sofortigen und dauerhaften Absturz.
Benedikt Meurer
"Immo 'FaUl' Wehrenberg" <im...@faul.holomann.de>:
>> To be precise: Das wäre eine Klasse. 'Objekt' bekomme ich durch
>> Deklaration einer Variablen des entsprechenden Typs.
>
> Objekt == Variable eines bestimmten Types?
>
> int a;
>
> Ist das ein Objekt in C?
Stark vereinfacht: JA. Angenommen "int" wäre eine Basisklasse, so hätte
int die Komponentenfunktionen +, -, /, usw. Instanzen von "int", in
diesem Beispiel a, könnten dann die Objekteigenschaften der Instanz durch
diese Komponentenfunktionen ändern. Z.B. int a; a++; a -= 5;
Rainer Weikusat
> > To be precise: Das wäre eine Klasse. 'Objekt' bekomme ich durch
> > Deklaration einer Variablen des entsprechenden Typs.
>
> Objekt == Variable eines bestimmten Types?
Das ist eine notwendige Bedingung, keine hinreichende (zumindestens
nicht dann, wenn man 'übliche' OO-Bedeutungen dieses Begriffs
voraussetzt.
Man könnte auch noch Objekt ::= Funktion plus Zustand versuchen. Da
gibt es nichts, was nicht auch anders ginge, aber der Unterschied
liegt im Blickwinkel: In einer normalen 'prozeduralen' Sprache habe
ich Routinen, die mit irgendwelchen Daten arbeiten, bei OO habe ich
Daten, auf denen bestimmte Operationen definiert sind.
Ein gutes Beispiel für ein 'C-Objekt' wären stdio-streams, nur daß es
in einer 'richtigen' OO-Sprache eingebaute Möglichkeiten gibt, wie ich
die um eigenen Stream-Typen erweiteren kann (zB solche, die SSL
sprächen), sowie die Möglichkeit, generischen Code zu schreiben, der
mit jeder Sorte von 'stream-Objekten' zurechtkäme, vorausgesetzt, die
haben dasselbe Interface.
Zb:
void generic_open(stream &astream, char const *whatever)
{
astream.open(whatever);
if (astream.failed()) throw(open_failed);
}
int main()
{
stdio_stream ss;
socket_stream sks;
ssl_socket_stream ssks;
try {
generic_open(ss, "/dev/null");
generic_open(sks, "localhost:3128");
generic_open(ssks, "localhost:21");
.
.
.
} catch (open_failed) {
cout << "Aaaarghh!" << endl;
throw;
}
}
Wobei drei völlig unterschiedliche Funktionen tatsächlich ausgeführt
würden, die lediglich identische Prototypen haben müßten.
Damit gewinnt man nicht wirklich etwas neues, aber es lassen sich
ziemlich komplexe Zusamenhänge sehr einfach formulieren.
--
SIGSTOP
Rainer Weikusat
> Rainer Weikusat schrieb:
> > Sondern würde nicht eine knappe Woche
> > später schon wieder jemand Dummfug des Kalibers 'Skriptsprachen sind
> > immer effizienter' von sich geben.
>
> Und Du hoerst nicht zu und akzeptierst keine Argumente.
Sagen wir mal, ich warte auf Argumente. Allerdings nicht sehr
intensiv, weil ich leider das, was Du und Anselm gerne gehört hätten,
gar nicht behauptet habe.
> Wegen Leuten wie Dir wird das CERT immer was zu tun haben
> und Rechner werden immer zu hacken sein.
Eher wegen Leuten wie Dir.
[...]
> Bei Alkohol, Autos, Kuehlschraenken etc. kommen die wenigsten auf
> solche Ideen, aber bei Software wird das Rad jedesmal neu erfunden.
Du weißt, was eine Bibliothek ist?
> Ich mag nicht, dass jetzt schon wieder ein Thread von Dir auf das
> Thema "Scripts sind Scheisse" umgebogen wird.
Liest Du eigentlich die Postings, auf die Du antwortest?
--
SIGSTOP
Sascha Ziemann
| Was schreibt man in Sheme nicht in Klammern? Kommentare?
Exakt.
| > Dadurch, dass man "on-the-fly" Funktionen erzeugen kann, kann man auch
| > Funktionen programmieren, die als Rückgabewert eine Funktion erzeugen:
|
| Das ist aber ein Vorteil von Sheme, oder?
Das Ding heisst Scheme und Perl kann das auch:
$ man perlref
[...]
4. A reference to an anonymous subroutine can be created
by using sub without a subname:
$coderef = sub { print "Boink!\n" };
[...]
| > Beispielsweise möchte man unterschiedliche Funktionen an Daten
| > binden. Das sind dann die Methoden.
|
| Hm, wozu brauch man das? Braucht man das nur für Altsheimerkranke, die
| ständig Funktionsnamen verwechseln, oder hat das auch sonst noch Vorteile?
| Hm, mein C-Compiler warnt auch, wenn ich eine Funktion
|
| void foo (int bar)
| mit
| foo((char)test);
| aufrufe.
| Habe ich da was nicht verstanden?
Jup. Ein Funktionsaufruf ist keine Bindung. Dein Beispiel zeigt nur
eine statisch "getypte" Sprache. Eine Bindung wäre z.B. ein struct,
weswegen man in C++ Klassen auch mit struct definieren kann.
| > Und man möchte Methoden und gewöhnliche Funktionen in
| > gleicher Weise benutzen können, womit wir Polimorphismus hätten.
|
| Also doch Falsch verstanden. Was ist der unterschied zwischen Funktion und
| Methode?
Bei einer MOP-Implementation mit genereischen Funktionen gibt es
keinen.
Immo 'FaUl' Wehrenberg
> im...@FaUl.holomann.de (Immo 'FaUl' Wehrenberg) writes:
> | > Dadurch, dass man "on-the-fly" Funktionen erzeugen kann, kann man auch
> | > Funktionen programmieren, die als Rückgabewert eine Funktion erzeugen:
> | Das ist aber ein Vorteil von Sheme, oder?
> Das Ding heisst Scheme
Sorry.
> und Perl kann das auch:
Ja, und in Assembler kann man das auch machen. Ich meinte das hat nichts
mit OOP zu tun.
> | > Beispielsweise möchte man unterschiedliche Funktionen an Daten
> | > binden. Das sind dann die Methoden.
Was nicht in meinen Kopf rein gehen will. Wozu will man Daten mit funktionen
binden?
> Jup. Ein Funktionsaufruf ist keine Bindung. Dein Beispiel zeigt nur
> eine statisch "getypte" Sprache.
Naja, C = statisch getyped?
> Bei einer MOP-Implementation
undefined reference to 'MOP'
FaUl
--
Windows 95/98/ME/NT/2000: "A 32 bit extension and graphical shell,
for a 16 bit patch to an 8 bit operating system, originally
coded for a 4 bit microprocessor, written by a
2 bit company, that can't stand 1 bit of competition." OA
Christoph Kliemt
[...]
>> und Perl kann das auch:
I> Ja, und in Assembler kann man das auch machen. Ich meinte das hat
I> nichts mit OOP zu tun.
*Grins* Man lasse sich diese Aussagen mal auf der Zunge
zergehen... ;-)
>> | > Beispielsweise möchte man unterschiedliche Funktionen an Daten
>> | > binden. Das sind dann die Methoden.
I> Was nicht in meinen Kopf rein gehen will. Wozu will man Daten mit
I> funktionen binden?
Weil man im Ernstfall lieber nicht wissen will wie die Daten intern
organisiert sind.
Mittlerweile werden bei mir die Daten in "theContainer" geparkt, ob
das nu ne STL-Nummer wird oder ne db-Anbindung ist erstmal egal,
Hauptsache, das Interface bleibt gleich... :-)
\\// christoph
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real
Programmer wants a "you asked for it, you got it" text editor --
complicated, cryptic, powerful, unforgiving, dangerous.
Philipp Hemker
> Bla bla bla. Bitte entferne alle C- und C++-Programme von Deinem
> Rechner und versuche, den Rest mit Perl zu benutzen.
<http://language.perl.com/ppt/>
<http://sourceforge.net/projects/perlix/>
scnr,
philipp
--
Olaf Klischat
> "Benedikt Meurer" <bme...@fwdn.de> writes:
> > <Uwe....@de.bosch.com>:
> > > So in etwa: ´mov ebx, [ebp+8] ; push ebx ; mov ebx, [ebx] ; call
> > > [ebx+4]´ ist der Kern zu meinem Verständnis gewesen. :)
> >
> > Die Logik ist wie gesagt nicht ganz verständlich:
>
> Sie ist es. 'Virtuelle Methode' ist ein sehr viel abstrakteres Konzept
> als 'compilergenerierte Sprungtabelle'.
Deswegen aber nicht unbedingt schwerer zu verstehen, IMHO.
> 'Verstanden' habe ich das
> dann, wenn ich weiß, was es bedeutet.
Du willst doch nicht sagen, dass man das Konzept "virtuelle Methoden"
nur verstehen kann, wenn man sich eine spezielle
Implementierungstechnik (VMTs) vergegenwärtigt?
>
> > Somit ist es zunächst vollkommen unsinnig,
> > C++ mit Assembler zu verstehen,
>
> Es ist nicht nur nicht unsinnig sondern die einzige
> Möglichkeit.
Entscheidend für das Verständnis ist letztlich allein die
Sprachspezifikation.
Olaf
--
Olaf Klischat | TU Berlin computer science
Oberfeldstrasse 132 |
12683 Berlin, Germany |
phone: +49 30 54986231 | e-mail: klis...@cs.tu-berlin.de
Felix von Leitner
> Wenn du wirklich verstehen möchtest wie es funktioniert , lerne erst
> Assembler.
Totaler Quark.
Abgesehen davon kann man "Assembler" nicht lernen. Man kann die
Prinzipien dahinter lernen (man Rechnerarchitektur) und man kann die
Befehlssätze eines oder mehrerer Prozessoren lernen.
> Alles was mit Overloading, virtuellen Methoden usw. zu tun hat war für mich
> ein Buch mit sieben Siegeln.
Daß du C++ nicht kannst liegt sicher nicht an deiner Unkenntnis des
x86-Befehlssatzes.
> Bis ich mir zu kleinen, möglichst einfachen Beispielen den erzeugten
> Assembler-Code anschaute.
> So in etwa: ´mov ebx, [ebp+8] ; push ebx ; mov ebx, [ebx] ; call [ebx+4]´
> ist der Kern zu meinem Verständnis gewesen. :)
vtables und sogar trampolines kann man prima ohne Kenntnis den
Befehlssatzes des Zielprozessors verstehen.
Felix
Rainer Weikusat
> Rainer Weikusat <weik...@mail.uni-mainz.de> writes:
> > dann, wenn ich weiß, was es bedeutet.
>
> Du willst doch nicht sagen, dass man das Konzept "virtuelle Methoden"
> nur verstehen kann, wenn man sich eine spezielle
> Implementierungstechnik (VMTs) vergegenwärtigt?
Ich will sagen, das 'virtuelle Methode' bedeutet: Der Compiler
generiert Code, der sich anhand bestimmter, im einem (mehreren)
Argument(en) gespeicherter Werte zur Laufzeit eine 'reale' Funktion
aussucht. Dazu kann ich auch 'late binding' sagen, nur muß ich damit
schon etwas anfangen können, bevor ich es verstehe.
Für Leute, die bereits Vorkenntnisse mit prozeduralen Sprachen haben,
dürfte meine Umschreibung (eigentlich Übersetzung) verständlicher
sein, bei anderen kann es nicht schaden, wenn sie wenigstens
grundsätzlich wissen, was da eigentlich vor sich geht. Zumal obiges
immer noch ziemlich abstrakt ist (also keine Implementierungstechnik,
sondern das zu implementierende Modell beschreibt) und deswegen
grundsätzlich überall zutrifft.
> > > Somit ist es zunächst vollkommen unsinnig,
> > > C++ mit Assembler zu verstehen,
> >
> > Es ist nicht nur nicht unsinnig sondern die einzige
> > Möglichkeit.
>
> Entscheidend für das Verständnis ist letztlich allein die
> Sprachspezifikation.
CLOS rulez :-). Du unterschätzt die 'stubborness' von Leuten
beträchtlich. Ich kann mich da an jemand erinnern, der vor ~ 10 Jahren
mal zwei Nachmittage lang verständnislos auf eine Spezifikation gestarrt
hat und des Rätsels Lösung lag letzlich in 'hmm ... naja ... machen
wir mal was damit ... vielleicht ist es ja für irgendwas gut'. Danach
ist der Groschen dann zügig gefallen.
--
SIGSTOP
Rainer Weikusat
> > | > Beispielsweise möchte man unterschiedliche Funktionen an Daten
> > | > binden. Das sind dann die Methoden.
>
> Was nicht in meinen Kopf rein gehen will. Wozu will man Daten mit funktionen
> binden?
Weil es das Bauen von self contained abstractions erleichtert. Zb kann
ich eine Klasse 'handle' definieren, die sich, von außen betrachtet,
keinen Deut von einem richtigen Zeiger unterscheidet, nur, daß sie
zusätzlich noch einen reference counter enthält und dann Sachen wie:
void write_hello_to(char const *path)
{
handle<stream> s = new stream(path);
s->write("Hello!\n", 7);
}
anstatt von
void write_hello(char const *path)
{
stream *s;
s = new stream(path);
s->write("Hello!\n", 7);
delete s;
}
machen. Vor allem kann man auch viel üblere Dinge damit tun, dh zB den
handle nach Lust und Laune als Argument für dutzende von Funktionen
(potentiell in unterschiedlichen threads) verwenden, in globalen
Variablen speichern, kopieren usf ohne das ich mich auch nur einmal
darum kümmern muß, den Speicher selber freizugeben, sobald er wirklich
nicht mehr benötigt wird, sondern ich schreibe den entsprechenden Code
einmal an einer Stelle und überlasse dem Compiler/Interpreter, ihn
dann auszuführen, wenn es notwendig wird (also die letzte Referenz out
of scope geht).
Reduziert die Möglichkeit für (dumme) Flüchtigkeitsfehler, erhöht die
Wartbarkeit und sorgt für sehr viel lesbarere Programme, weil die dann
aus voneinander unabhängigen Einheiten bestehen, die man getrennt
schreiben und debuggen kann und später mit geringem Aufwand zu
beliebig komplexen Konstruktionen zusammenpappen kann, ohne sich um
globale Seiteneffekte und ähnlichen Müll Gedanken machen zu müssen.
Das C-Programm, mit dem ich momentan rumspiele, ist so furchtbar
ineinander verwoben, daß ich vor jeder Änderung an einer Stelle erst
einmal in vier anderen Quelldateien kontrollieren muß, daß ich
wirklich keine impliziten und nicht offensichtlichen Annahmen verletzt
habe. Das macht es vermutlich effizienter, aber sobald 'die Dinge' ein
bestimmtes Maß an Komplexität erreicht haben, kann man den Code bloß
noch verwenden oder neu schreiben.
> > Jup. Ein Funktionsaufruf ist keine Bindung. Dein Beispiel zeigt nur
> > eine statisch "getypte" Sprache.
>
> Naja, C = statisch getyped?
C hat kein type system, es tut bloß so. Ada hat eins. Deswegen wird
ein 'Hello, world' auch 60K(!) groß, aber falls ich erheblich mehr als
'Hello, world' machen will, spart das einen Haufen Kleinarbeit
(mutmaßlich. Ein interessantes Problem dafür fehlt mir bislang und
mein Chef würde mich wahrscheinlich furchtbar hassen, falls ich
irgendetwas damit machen würden, denn das verstünde er dann nicht
mehr).
--
SIGSTOP
Rainer Weikusat
Ohne Perl wird das trotzdem schwierig werden.
SCNR^2
--
SIGSTOP
Axel Schwenke
im...@FaUl.holomann.de (Immo 'FaUl' Wehrenberg) writes:
>> | > Beispielsweise möchte man unterschiedliche Funktionen an Daten
>> | > binden. Das sind dann die Methoden.
>
> Was nicht in meinen Kopf rein gehen will. Wozu will man Daten mit funktionen
> binden?
Um Abhängigkeiten im Code auf ein Minimum zu reduzieren. Wenn du ein
Objekt "Auto" nur durch die Methode "anlassen()" starten kannst, dann
wirst du nie Code wie "verbinde Kontakt A47 mit A48" schreiben, der
zwar möglicherweise das gleiche tut, aber schon bei der nächsten
Release von "Auto" evtl. nicht mehr geht.
Das Zauberwort heißt "Kapselung" und ist nur eine Facette von OOP,
allerdings IMHO die wichtigste.
XL
--
|-----------------------------------------------------------------------|
| Axel Schwenke, Systemadministrator @ jobpilot AG |
| www.jobpilot.{at,be,ch,cz,de,dk,es,fr,hu,it,net,nl,no,pl,se,co.uk...} |
|_____ Linux is like a Wigwam: no Windows, no Gates, Apache inside _____|
Anselm Lingnau
Rainer Weikusat <weik...@mail.uni-mainz.de>:
> Aber scheinbar nicht verstanden. Sondern würde nicht eine knappe Woche
> später schon wieder jemand Dummfug des Kalibers 'Skriptsprachen sind
> immer effizienter' von sich geben. Skriptsprachen sind immer
> ineffizienter. Je nachdem, was ich eigentlich möchte, stellt das
> wahlweise ein gravierendes Problem dar oder kann mir völlig egal sein.
*Du* hast offenbar immer noch nicht verstanden, daß Effizienz nicht
unbedingt in CPU-Taktzyklen und Speicher-Kilobytes gemessen werden
muß. Heutzutage ist Programmiererzeit sehr oft eine knappere
Ressource als Rechenzeit, und darum haben Skriptsprachen, die mit
ersterer in der Regel viel ökonomischer umgehen als Sprachen wie C
(eine Größenordnung ist da normalerweise auf jeden Fall drin), in sehr
vielen Fällen große Vorteile. Es ist ein großer Unterschied, ob ich
nach einer Woche ein Programm habe, das die Aufgabe löst, aber
möglicherweise langsam ist, oder nach zehn Wochen ein Programm habe,
das die Aufgabe (vielleicht) löst. In ersteres Programm kann ich
nochmal zwei Wochen Arbeit stecken, um die »hot spots« im Code
schneller zu machen, und bin immer noch dreimal so schnell fertig wie
mit letzterem.
Daß es auch Fälle gibt, in denen C nötig ist, bestreitet niemand --
allerdings ist es eben genauso Dummfug, ein Programm von Anfang an in
C zu schreiben, weil man befürchtet, es könnte sonst später zu langsam
sein. Solange man das nicht genau weiß (wobei es natürlich Situationen
gibt, wo das der Fall ist), tut man besser daran, es in einem Zehntel
der Zeit in einer Skriptsprache zum Laufen zu bringen, *nachzumessen*,
ob es wirklich zu langsam ist, und dann gezielt die Stellen zu
beschleunigen, wo es hakt. Die Faustregel sagt, daß 80% der
Ausführungszeit eines Programms in 20% des Codes verbracht wird. Diese
20% sind möglicherweise Kandidaten dafür, in C (neu) geschrieben zu
werden, die restlichen 80% mit einiger Sicherheit nicht.
Und um nochmal auf die vorige Woche zurückzukommen: Man sollte
natürlich auch seine Werkzeuge kennen. Deine Kommentare über Perl auf
der Basis Deines CGI-Beispiels erinnern an einen Leichtathleten, der
sich nach einem verlorenen 100-Meter-Lauf über seine miesen Laufschuhe
beschwert und nichts über die 20-kg-Stahlkugel sagt, die mit einer
Kette an seinem Fußgelenk hängt.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Imagination is the one weapon in the war against reality. -- Jules de Gaultier
Olaf Klischat
> Im Artikel <987594777.irz778%sr...@inf.tu-dresden.de> schrieb "Stefan
> Reuther" <sr...@inf.tu-dresden.de>:
> > Und warum muß man sich mit der Krücke `moc' rumschlagen, wo man das doch
> > direkt in C++ implementieren könnte?
>
> Das halte ich für ein Gerücht: Du meinst vermutlich Objective-C, nicht
> C++.
Und Du kennst vermutlich <http://libsigc.sourceforge.net/> nicht?
Rolf Magnus
> Reduziert die Möglichkeit für (dumme) Flüchtigkeitsfehler, erhöht die
> Wartbarkeit und sorgt für sehr viel lesbarere Programme, weil die dann
> aus voneinander unabhängigen Einheiten bestehen, die man getrennt
> schreiben und debuggen kann und später mit geringem Aufwand zu
> beliebig komplexen Konstruktionen zusammenpappen kann, ohne sich um
> globale Seiteneffekte und ähnlichen Müll Gedanken machen zu müssen.
Das kann man auch problemlos ohne Objektorientierung machen.
> Das C-Programm, mit dem ich momentan rumspiele, ist so furchtbar
> ineinander verwoben, daß ich vor jeder Änderung an einer Stelle erst
> einmal in vier anderen Quelldateien kontrollieren muß, daß ich
> wirklich keine impliziten und nicht offensichtlichen Annahmen verletzt
> habe. Das macht es vermutlich effizienter, aber sobald 'die Dinge' ein
> bestimmtes Maß an Komplexität erreicht haben, kann man den Code bloß
> noch verwenden oder neu schreiben.
Das liegt aber nicht unbedingt daran, daß C nicht OO ist, sondern eher
daran, daß das besagte Programm einfach schlecht programmiert ist. Ich kann
Dir auch mit OO ein Programm liefern, das beliebig fehlerträchtige
Abhängigkeiten enthält.
Andreas Krey
>Im Artikel <3ad9...@fefe.de> schrieb "Felix von Leitner"
><usenet-...@fefe.de>:
>> Thus spake Severin Olloz (S.O...@soid.ch):
>>> Nun habe mich nun entschlossen C++ natürlich unter UNIX zu erlernen.
>>
>> Lerne erstmal C.
>
>Diese Aussage ist durchaus sinnlos, da C und C++ zwei völlig verschiedene
>Sprachen sind, auch wenn C++ aus C entstanden ist. Aber C++ ist eine
>objektorientierte Sprache, während C eine prozedurale Sprache ist, C++
>folgt also ganz anderen Konzepten.
Du meinst 'obj->blub (x)' statt 'obj->vtbl->blub (obj, x)'?
C++ ist eine Sprache, die Objektorientierung leichter macht als C.
Aber OO ist ein Programmierstil, keine Spracheigenschaft.
Andreas
--
Andreas Krey, Ulm, Germany <a.k...@gmx.de>; Fon +49 731 9314502, Fax 9316254 ++
Someone remind these nice people that Mission Impossible is fiction. -- BrSn
Rainer Weikusat
> Rainer Weikusat wrote:
> > Reduziert die Möglichkeit für (dumme) Flüchtigkeitsfehler, erhöht die
> > Wartbarkeit und sorgt für sehr viel lesbarere Programme, weil die dann
> > aus voneinander unabhängigen Einheiten bestehen, die man getrennt
> > schreiben und debuggen kann und später mit geringem Aufwand zu
> > beliebig komplexen Konstruktionen zusammenpappen kann, ohne sich um
> > globale Seiteneffekte und ähnlichen Müll Gedanken machen zu müssen.
>
> Das kann man auch problemlos ohne Objektorientierung machen.
Ohne Unterstützung des Compilers muß man es aber weiterhin alles von
Hand machen. Der Witz bei OO ist, daß man sich das dann schenken kann.
Läuft auf einen Bequemlichkeits- und Klarheitsgewinn auf Kosten des
Laufzeitverhaltens hinaus.
> > Das C-Programm, mit dem ich momentan rumspiele, ist so furchtbar
> > ineinander verwoben,
[...]
> Das liegt aber nicht unbedingt daran, daß C nicht OO ist, sondern eher
> daran, daß das besagte Programm einfach schlecht programmiert ist.
Die Vermutung ist naheliegend, aber (wahrscheinlich) falsch. 'Schlecht
programmiert' wäre es dann, wenn es außerdem noch nicht funktionieren
würde. Tut es aber. :-)
--
SIGSTOP
Benedikt Meurer
Klischat" <klis...@cs.tu-berlin.de>:
>> > Und warum muß man sich mit der Krücke `moc' rumschlagen, wo man das
>> > doch direkt in C++ implementieren könnte?
>>
>> Das halte ich für ein Gerücht: Du meinst vermutlich Objective-C, nicht
>> C++.
>
> Und Du kennst vermutlich <http://libsigc.sourceforge.net/> nicht?
Schonmal von gehört, aber nie wirklich ernsthaft mit befasst. C++ ist mir
zu krank, ich mag C ;-).
Felix von Leitner
> *Du* hast offenbar immer noch nicht verstanden, daß Effizienz nicht
> unbedingt in CPU-Taktzyklen und Speicher-Kilobytes gemessen werden
> muß. Heutzutage ist Programmiererzeit sehr oft eine knappere
> Ressource als Rechenzeit, und darum haben Skriptsprachen, die mit
> ersterer in der Regel viel ökonomischer umgehen als Sprachen wie C
> (eine Größenordnung ist da normalerweise auf jeden Fall drin), in sehr
> vielen Fällen große Vorteile. Es ist ein großer Unterschied, ob ich
> nach einer Woche ein Programm habe, das die Aufgabe löst, aber
> möglicherweise langsam ist, oder nach zehn Wochen ein Programm habe,
> das die Aufgabe (vielleicht) löst. In ersteres Programm kann ich
> nochmal zwei Wochen Arbeit stecken, um die »hot spots« im Code
> schneller zu machen, und bin immer noch dreimal so schnell fertig wie
> mit letzterem.
Nein.
Erfahrene Programmierer sind in allen von ihnen beherrschten Sprachen
schnell. Man wählt die, mit der das gegebene Problem am besten zu lösen
ist.
Was du hier beschreibst ist die Zeit, die ein Idiot braucht, um in einer
Programmiersprache, die er nicht beherrscht, mal eben was
zusammenzukludgen. Das Ergebnis ist natürlich in fast allen Fällen
Schrott und damit ist die Frage nur von akademischem Interesse.
> Daß es auch Fälle gibt, in denen C nötig ist, bestreitet niemand --
> allerdings ist es eben genauso Dummfug, ein Programm von Anfang an in
> C zu schreiben, weil man befürchtet, es könnte sonst später zu langsam
> sein.
Anselm, du faselst.
Programme, die CPU-bound sind, wird nur ein Idiot in einer Skriptsprache
implementieren. Beispiele: bulk-cipher, md5sum, gzip,
langzahl-arithmetik, Signalverarbeitung, Volltextsuche.
> Solange man das nicht genau weiß (wobei es natürlich Situationen
> gibt, wo das der Fall ist), tut man besser daran, es in einem Zehntel
> der Zeit in einer Skriptsprache zum Laufen zu bringen, *nachzumessen*,
> ob es wirklich zu langsam ist, und dann gezielt die Stellen zu
> beschleunigen, wo es hakt.
So ein Quark.
Erfahrene Programmierer programmieren von Anfang an mit einem
effizienten Algorithmus. Ich habe jedenfalls noch nie in einem meiner
Perl-Programme im Nachhinein signifikante Performance-Gewinne erzielen
können. Warum auch. Wenn man weiß, wie es effizienter geht, macht man
es natürlich gleich so.
> Die Faustregel sagt, daß 80% der Ausführungszeit eines Programms in
> 20% des Codes verbracht wird.
Oh Mann, an deinen Aussagen hängen ja noch die Mottenkugeln...
Natürlich ist das so. Weil aber bei Programmen, für die Scriptsprachen
überhaupt in Frage kommen, grundsätzlich den vollständigen Überblick
behält, würden nur unerfahrene Programmierer diese Stellen nicht von
vorneherein erkannt und effizient implementiert haben.
> Diese 20% sind möglicherweise Kandidaten dafür, in C (neu) geschrieben
> zu werden, die restlichen 80% mit einiger Sicherheit nicht.
Du implizierst hier, daß nur Laufzeit eine relevante Ressource ist.
Tatsächlich ist der RAM-Verbrauch gewöhnlich auch eine Größenordnung
größer. Und das kriegst du nicht weg, wenn du nur ein bißchen
Schleifchen-Kram mal eben in C nachimplementierst und dich dabei mit
irgendwelchen Interface-Fragen aufhälst.
Felix
--
I think it would be a good idea.
--Mahatma Ghandi, when asked what he thought of Western civilization
Sven Mascheck
> Thus spake Anselm Lingnau (lin...@tm.informatik.uni-frankfurt.de):
>> *Du* hast offenbar immer noch nicht verstanden, daß Effizienz nicht
>> unbedingt in CPU-Taktzyklen und Speicher-Kilobytes gemessen werden
>> muß. Heutzutage ist Programmiererzeit sehr oft eine knappere
>> Ressource als Rechenzeit, und darum haben Skriptsprachen, die mit
>> ersterer in der Regel viel ökonomischer umgehen als Sprachen wie C
>> (eine Größenordnung ist da normalerweise auf jeden Fall drin), in sehr
>> vielen Fällen große Vorteile.
> Nein.
> Erfahrene Programmierer sind in allen von ihnen beherrschten Sprachen
> schnell.
...nahe an einer Tautologie.
> Man wählt die, mit der das gegebene Problem am besten zu lösen ist.
Wieso also nein? Wenn man eine andere als die passendste Sprache wählt,
_wird_ man eben deutlich länger brauchen.
> Was du hier beschreibst ist die Zeit, die ein Idiot braucht, um in einer
> Programmiersprache, die er nicht beherrscht, mal eben was
> zusammenzukludgen.
Du erwähnst die große Masse zwischen - ich zitiere - »Erfahrene
Programmierer« und »ein Idiot« irgendwie mit keinem Wort.
Für genau die passen aber Anselms Worte meiner Meinung nach recht
gut, wenn man (nicht unbegründet) einen Ratschlag-Charakter
hineininterpretiert.
Deine beiden Extreme wissen entweder sowieso was sie wollen
oder sie wissen es sowieso gar nicht und müssen eher noch
schmerzhaft lernern.
>> [...]
>> Diese 20% sind möglicherweise Kandidaten dafür, in C (neu) geschrieben
>> zu werden, die restlichen 80% mit einiger Sicherheit nicht.
> Du implizierst hier, daß nur Laufzeit eine relevante Ressource ist.
> Tatsächlich ist der RAM-Verbrauch gewöhnlich auch eine Größenordnung
> größer. Und das kriegst du nicht weg, [...]
Und der mitunter beeindruckende Overheaed beim Start, z.B. bei perl,
kommt besonders bei kleineren Programmen auch noch dazu.
Sven
Andreas Riedel
> Erfahrene Programmierer sind in allen von ihnen beherrschten
> Sprachen schnell. Man wählt die, mit der das gegebene Problem am
> besten zu lösen ist.
Ja. Das kann unter Umständen eine Scriptsprache sein.
> Was du hier beschreibst ist die Zeit, die ein Idiot braucht, um in
> einer Programmiersprache, die er nicht beherrscht, mal eben was
> zusammenzukludgen.
Manche Dinge gehen in Scriptsprachen ganz einfach wesentlich schneller
hinzuschreiben. Weil es da 20 Zeilen sind und nicht 200 zum Beispiel.
>> Daß es auch Fälle gibt, in denen C nötig ist, bestreitet niemand --
>> allerdings ist es eben genauso Dummfug, ein Programm von Anfang an
>> in C zu schreiben, weil man befürchtet, es könnte sonst später zu
>> langsam sein.
> Programme, die CPU-bound sind, wird nur ein Idiot in einer
> Skriptsprache implementieren. Beispiele: bulk-cipher, md5sum, gzip,
> langzahl-arithmetik, Signalverarbeitung, Volltextsuche.
Es gibt jede Menge Leute, die stark rechenintensive Sachen z.B. in
Matlab schreiben (Scriptsprache). Es ist halt etwas langsamer - na
und? Da kann man irgendwann mal einen Codeknecht ransetzen, der das
Ganze in Fortran oder C umschreibt.
>> Solange man das nicht genau weiß (wobei es natürlich Situationen
>> gibt, wo das der Fall ist), tut man besser daran, es in einem
>> Zehntel der Zeit in einer Skriptsprache zum Laufen zu bringen,
>> *nachzumessen*, ob es wirklich zu langsam ist, und dann gezielt die
>> Stellen zu beschleunigen, wo es hakt.
>
> Erfahrene Programmierer programmieren von Anfang an mit einem
> effizienten Algorithmus.
Den effizienteren Algorithmus schon.
> Ich habe jedenfalls noch nie in einem meiner Perl-Programme im
> Nachhinein signifikante Performance-Gewinne erzielen können. Warum
> auch. Wenn man weiß, wie es effizienter geht, macht man es
> natürlich gleich so.
Wenn Du merkst, daß ein bestimmter Teil des Perl-Programms die meiste
Zeit braucht, kannst Du diesen Teil in C implementieren. Ohne gleich
alles in C zu schreiben. Der Algorithmus bleibt der selbe.
>> Diese 20% sind möglicherweise Kandidaten dafür, in C (neu) geschrieben
>> zu werden, die restlichen 80% mit einiger Sicherheit nicht.
>
> Du implizierst hier, daß nur Laufzeit eine relevante Ressource ist.
> Tatsächlich ist der RAM-Verbrauch gewöhnlich auch eine Größenordnung
> größer.
Das kommt aber sehr stark auf die Problemstellung an. Ich habe höchst
selten Probleme, bei denen die Größe des Codes in irgendeiner Form
relevant wäre. Weil das maximal ein paar hundert Kilobyte sind,
bei >> 100 MB Daten. Bei anderen Problemen sieht's anders aus, das ist
klar. Man darf das halt nicht zu sehr verallgemeinern.
Gruß
Andreas
Rainer Weikusat
> Felix von Leitner schrieb:
> > Erfahrene Programmierer sind in allen von ihnen beherrschten
> > Sprachen schnell. Man wählt die, mit der das gegebene Problem am
> > besten zu lösen ist.
>
> Ja. Das kann unter Umständen eine Scriptsprache sein.
Um das mal explizit zu sagen: Niemand hat jemals das Gegenteil
behauptet, bzw 'wer Druckeraccounting in <insert compiled langugage of
choice> macht, hat vermutlich einen Dachschaden' (oder extreme
Langeweile).
> Manche Dinge gehen in Scriptsprachen ganz einfach wesentlich schneller
> hinzuschreiben. Weil es da 20 Zeilen sind und nicht 200 zum
> Beispiel.
Der umgekehrte Fall existiert. Als Beispiel seien Datenstrukturen und
Perl genannt: Es gibt nämlich keine. Es gibt Arrays und Hashes und
alles, was darüber hinausgeht, muß man mit irgendwelchen
ad-hoc-Improvisationen simulieren. Das sieht dann zB so aus:
#*** host()
#
# Return the host we are connected to.
#
sub host
{
return ${$_[0]}[&HOST];
}
C++-Äquivalent:
char const *host() const
{
return host;
}
[in einer Klasse]
> Da kann man irgendwann mal einen Codeknecht ransetzen, der das
> Ganze in Fortran oder C umschreibt.
<rant>
Solange man den Handwerkern nichts als Verachtung entgegenbringt,
werden die guten woanders arbeiten bzw es wird keine guten geben, weil
sich unter diesen Randbedingungen niemand leisten kann, 'sein
Handwerk' richtig zu erlernen --- Kisten schleppen im Supermarkt wird
nämlich idR besser bezahlt und verlangt weniger Zeit (und somit
letzlich Geld) kostende Selbstausbildung.
Ingenieure sind keine Schweißer und gute Ingenieure werden sich weder
für Schweißer halten, noch Schweißer für eigentlich überflüssig.
Komischerweise gilt das überall, außer in dem seltsamen Ding, das man
'IT' nennt. Unter anderem deswegen wird da soviel grauenhafter Pfusch
gemacht, aber das schad' ja nix, weil niemand erwartet, Computer
sinnvoll einsetzen zu könne, denn das ging ja eh noch nie.
Falls diese Attitüde unter Architekten so verbreitet wäre, wie
unter 'Informatikern' (und Artverwandtem) könnte niemand sich
beruhigten Gewissens in einem Haus schlafen legen, weil Häuser dann
nämlich, genau wie Programme, gewohnheitsmäßig zusammenbrechen
würden. Für Säcke voller Begründungen, warum das auch bei Programmen
ein wirklich blöde Idee ist, verweise ich auf ein paar von Detlef Bosaus
Lieblingsthemen.
custom definition: 'Informatiker' ::= 'Jemand, der "Datenbanken"
zugunsten von "Web-Design" aus dem Programm nimmt' (das Beispiel ist
real).
... und jetzt bin ich wieder ein braver 'Codeknecht', dh ich höre mir
an, was Du willst, nicke freundlich zu Deinen Vorstellungen, wie das
zu lösen wäre, ignoriere die klammheimlich und mache es so, das Du
tatsächlich das gewünschte Ergebnis bekommst. Solange ich mir das
leisten kann. Danach gehe ich wieder Kisten schleppen.
"Macht's gut und danke für den Fisch."
</>
Merkbefreiungen auf Anfrage.
> Wenn Du merkst, daß ein bestimmter Teil des Perl-Programms die meiste
> Zeit braucht, kannst Du diesen Teil in C implementieren. Ohne gleich
> alles in C zu schreiben. Der Algorithmus bleibt der selbe.
Können wir diese hirnrissige Fiktion endlich mal abhaken? Falls ich zB
viele kleine Funktionen habe, die dem oben zitierten Beispiel
entsprechen (also OO in Perl), besteht die reale Möglichkeit, daß der
Teil meines Programmes, indem es die meiste Zeit verbringt,
Perl-interne lookups in 1003 unterschiedlichen Tabellen sind. Abhilfe:
Unstrukturiert programmieren. Hat leider ein paar bekannte Defizite.
F'up2 poster
--
SIGSTOP
Rolf Magnus
>> Das liegt aber nicht unbedingt daran, daß C nicht OO ist, sondern eher
>> daran, daß das besagte Programm einfach schlecht programmiert ist.
>
> Die Vermutung ist naheliegend, aber (wahrscheinlich) falsch. 'Schlecht
> programmiert' wäre es dann, wenn es außerdem noch nicht funktionieren
> würde. Tut es aber. :-)
Auch Programme, die (meistens) funktionieren, können schlecht programmiert
sein. Spaghetti-Code bleibt was schlechtes, auch wenn er funktioniert. Und
OO bewahrt einen auch nicht davor, ein Programm unübersichtlich und
"ekelig" zu machen. Ob es dann funktioniert, ist eine andere Sache.
Rainer Weikusat
> Rainer Weikusat wrote:
> >> Das liegt aber nicht unbedingt daran, daß C nicht OO ist, sondern eher
> >> daran, daß das besagte Programm einfach schlecht programmiert ist.
> >
> > Die Vermutung ist naheliegend, aber (wahrscheinlich) falsch. 'Schlecht
> > programmiert' wäre es dann, wenn es außerdem noch nicht funktionieren
> > würde. Tut es aber. :-)
>
> Auch Programme, die (meistens) funktionieren, können schlecht programmiert
> sein.
Falls ich C tatsächlich als 'portablen Makroassembler' verwende, muß
das nicht notwendigerweise eine schlechte Sache sein.
> Spaghetti-Code bleibt was schlechtes, auch wenn er funktioniert.
Von 'Spaghetti-Code' war eigentlich nicht die Rede, nur von einem
etwas unsystematischen inneren Aufbau. Die Einzelteile für sich sind
eigentlich in Ordnung. Ist halt was älter...
> Und OO bewahrt einen auch nicht davor, ein Programm unübersichtlich und
> "ekelig" zu machen.
Sicher. Aber es hilft.
--
SIGSTOP
Andreas Riedel
>> Manche Dinge gehen in Scriptsprachen ganz einfach wesentlich schneller
>> hinzuschreiben. Weil es da 20 Zeilen sind und nicht 200 zum
>> Beispiel.
>
> Der umgekehrte Fall existiert.
Ja, natürlich. Dann ist ein Script wohl nicht das geeignete Werkzeug.
>> Da kann man irgendwann mal einen Codeknecht ransetzen, der das
>> Ganze in Fortran oder C umschreibt.
>
> <rant>
> Solange man den Handwerkern nichts als Verachtung entgegenbringt,
Das hat nichts mit Verachtung zu tun.
Ich studiere Mathematik. Da läuft es im Allgemeinen so, daß Profs,
Doktoren, Doktoranden neue bzw. verbesserte Verfahren entwickeln. Die
haben aber weder Lust noch Zeit, die dann wirklich optimal zu
implementieren. Da wird i.A. eine "Referenzimplementation" in Matlab
hingeklatscht und gut ist das erstmal. Oft gibt es ein paar Monate
später sowieso wieder etwas besseres, dann kann man das alte
wegwerfen.
Wenn jetzt jemand kommt, z.B. aus der Industrie, der einen solchen
Algorithmus wirklich einsetzen will, dann bezahlt derjenige Leute, ich
nannte sie "Codeknechte", dafür, daß sie ihm das ganze effizient
programmieren. Oft sind das Studenten, manchmal auch Angestellte.
So etwas ähnliches habe ich auch schon gemacht (im Wesentlichen stand
fest was zu tun war, wie das anfallende Optimierungsproblem zu lösen
ist, war allerdings mein Problem). So ein "Codeknecht" braucht den
Algorithmus nur in Ansätzen zu verstehen. Er muß programmieren können
und die Grundvorlesung Algebra gehört und verstanden haben. Den Rest
kann er "abschreiben".
> Falls diese Attitüde unter Architekten so verbreitet wäre, wie
> unter 'Informatikern' (und Artverwandtem) könnte niemand sich
> beruhigten Gewissens in einem Haus schlafen legen, weil Häuser dann
> nämlich, genau wie Programme, gewohnheitsmäßig zusammenbrechen
> würden.
Informatiker sind seltsame Menschen, ich weiß :-).
> Für Säcke voller Begründungen, warum das auch bei Programmen ein
> wirklich blöde Idee ist, verweise ich auf ein paar von Detlef Bosaus
> Lieblingsthemen.
An der Prosa mußt Du noch ein wenig feilen, aber ein guter Anfang.
> Merkbefreiungen auf Anfrage.
Hm, letztens hatte Brüderchen um eine gefleht... Ok, hat nix mit dem
Thema zu tun.
>> Wenn Du merkst, daß ein bestimmter Teil des Perl-Programms die meiste
>> Zeit braucht, kannst Du diesen Teil in C implementieren. Ohne gleich
>> alles in C zu schreiben. Der Algorithmus bleibt der selbe.
>
> Können wir diese hirnrissige Fiktion endlich mal abhaken?
Um in meinem Fachgebiet zu bleiben: Die ganzen Nutzerinterfaces etc.
bleiben fast immer in Matlab. Da macht sich keiner die Arbeit, und
programmiert das richtig. Das wäre auch gar nicht wünschenswert, weil
man Matlab-Scripte viel leichter ändern kann.
Eine schnelle, effiziente Implementation gibt es nur für die
eigentlichen Algorithmen, die dann wirklich die Ressourcen fressen.
> F'up2 poster
Ignoriert. So offtopic war das doch gar nicht.
Gruß
Andreas
Sascha Ziemann
| > und Perl kann das auch:
|
| Ja, und in Assembler kann man das auch machen. Ich meinte das hat nichts
| mit OOP zu tun.
Doch. Man kann auch in Assembler nach objektorientierten Prinzipien
programmieren, obwohl Assembler natürlich ziemlich weit hergeholt ist
und heutzutage wohl niemand mehr Assembler benutzt, es sei denn er
will einen Bootloader oder Gerätetreiber schreiben. Aber in C kann
man zum beispiel nach objektorientierten Prinzipien programmieren.
Wie das z.B. gehen könnte, kann man sich bei Gtk ansehen. Ich halte
reinrassige objektorientierte Sprachen auch für totalen Blödsinn, weil
es sich dabei um algorithmische Monokulturen handelt. Es ist genauso
Unsinn alles über Objekte lösen zu wollen wie es Unsinn ist, alles mit
Backtracking lösen zu wollen. Sinnvolle Sprachen sind deshalb keine
ojektorientierten Sprachen, sondern solche in denen man u.A. auch
objektorientiert programmieren kann.
| > | > Beispielsweise möchte man unterschiedliche Funktionen an Daten
| > | > binden. Das sind dann die Methoden.
|
| Was nicht in meinen Kopf rein gehen will. Wozu will man Daten mit funktionen
| binden?
Um beispielsweise sicherzustellen, dass Daten nur mit den für sie
gedachten Funktionen manipuliert werden.
Beispielsweise möchte man das Alter eines Rentenempfängers speichern.
Dazu nimmt man einen Datentyp, den die Programmiersprache hergibt.
Oft ist dieser Datentyp aber allgemeiner als für die Modellierung der
Wirklichkeit wünschenswert. Benutzt man z.B. einen Integer, könnte
man negative Werte in der Variablen ablegen, die für ein Alter total
unsinnig sind. Man könnte nun einwenden, einen vorzeichenlosen
Integer zu benutzen. Das lindert aber nur das Problem und löst es
nicht, da auch ein Alter von 0 Jahren eine höchst unsinniger Wert ist,
weil man erst was eingezahlt haben muss, um Rentenempfänger zu sein.
Und das Einzahlen setzt voraus, dass man nicht mit dem Gesetz, das
Kinderarbeit verbietet, in Konflikt gerät.
Also definiert man eigens zum Setzen des Rentenalters eine Funktion,
die die notwendigen Überprüfungen der Plausibilität durchführt und
dann den Wert speichert. Die Funktion könnte so aussehen:
int set_annuity_age (int *age);
Wenn man in dem gleichen Programm nicht nur mit den Altersangaben von
Rentenempfängern arbeitet, sondern auch mit den Altersangaben derer,
die mal Rentenempfänger werden, also mit den Kindern, hat man u.U. ein
Problem. Es hält nämlich niemanden davon ab, die Funktion zum Setzen
des Rentenalters auf das Alter von Kindern anzuwenden, da das Alter
selber nur als Integer gespeichert ist. Also definiert man einen
neuen Typ für das Rentenalter und verändert die Funktion zum Setzen
des Rentenalters so, dass nur noch Variablen dieses neuen Typs
geändert werden können.
typedef int annuity_age_t;
int set_annuity_age (annuity_age_t *age);
Und siehe da, wir haben Daten an Funktionen gebunden und obendrein
auch noch ein Objekt erzeugt, denn wenn man anstatt des einfachen
Integers für das Alter einen Struct bestehend aus Integer und Zeiger
auf die Funktion set_annuity_age definiert, ist man exakt bei den
Anfängen von C++ angekommen.
| > Jup. Ein Funktionsaufruf ist keine Bindung. Dein Beispiel zeigt nur
| > eine statisch "getypte" Sprache.
|
| Naja, C = statisch getyped?
Im Prinzip schon, nur gibt es in C so ziemlich alle erdenklichen
Möglichkeiten, um sich davor zu drücken.
| > Bei einer MOP-Implementation
|
| undefined reference to 'MOP'
Meta Object Protocol
Felix von Leitner
> > Was du hier beschreibst ist die Zeit, die ein Idiot braucht, um in einer
> > Programmiersprache, die er nicht beherrscht, mal eben was
> > zusammenzukludgen.
> Du erwähnst die große Masse zwischen - ich zitiere - »Erfahrene
> Programmierer« und »ein Idiot« irgendwie mit keinem Wort.
Diese Masse gibt es nicht.
Entweder man beherrscht eine Programmiersprache souverän oder man ist
ein Stümper, der nur zufällig mal ein funktionierendes Programm
abliefert. Ich habe nur Verwendung für Programmierer, bei denen ich mir
sicher sein kann, daß sie in der Lage sind, das Problem zu lösen. Wenn
ich das am Ende kontrollieren muß, kann ich es auch gleich selber
machen.
> Und der mitunter beeindruckende Overheaed beim Start, z.B. bei perl,
> kommt besonders bei kleineren Programmen auch noch dazu.
% echo "exit 0;" > empty.pl
% time perl empty.pl
perl empty.pl 0.00s user 0.00s system 0% cpu 0.000 total
%
Felix
Felix von Leitner
> > Was du hier beschreibst ist die Zeit, die ein Idiot braucht, um in
> > einer Programmiersprache, die er nicht beherrscht, mal eben was
> > zusammenzukludgen.
> Manche Dinge gehen in Scriptsprachen ganz einfach wesentlich schneller
> hinzuschreiben. Weil es da 20 Zeilen sind und nicht 200 zum Beispiel.
Nein.
Du verwechselst da Sprache und Laufzeitumgebung.
> > Programme, die CPU-bound sind, wird nur ein Idiot in einer
> > Skriptsprache implementieren. Beispiele: bulk-cipher, md5sum, gzip,
> > langzahl-arithmetik, Signalverarbeitung, Volltextsuche.
> Es gibt jede Menge Leute, die stark rechenintensive Sachen z.B. in
> Matlab schreiben (Scriptsprache).
Verstehst du den Unterschied zwischen "POV-Ray" (dein Beispiel) und
"Multiplikationsroutine für zwei Integer beliebiger Länge" (mein
Beispiel)?
> > Ich habe jedenfalls noch nie in einem meiner Perl-Programme im
> > Nachhinein signifikante Performance-Gewinne erzielen können. Warum
> > auch. Wenn man weiß, wie es effizienter geht, macht man es
> > natürlich gleich so.
> Wenn Du merkst, daß ein bestimmter Teil des Perl-Programms die meiste
> Zeit braucht, kannst Du diesen Teil in C implementieren. Ohne gleich
> alles in C zu schreiben. Der Algorithmus bleibt der selbe.
So ein Schwachsinn.
Daß ein bestimmter Teil CPU-intensiv ist, fällt dir erst während des
Programmierens auf?!
> > Du implizierst hier, daß nur Laufzeit eine relevante Ressource ist.
> > Tatsächlich ist der RAM-Verbrauch gewöhnlich auch eine Größenordnung
> > größer.
> Das kommt aber sehr stark auf die Problemstellung an. Ich habe höchst
> selten Probleme, bei denen die Größe des Codes in irgendeiner Form
> relevant wäre.
Ich rede nicht von der Code-Größe, sondern von der Größe der Metadaten
der Scriptsprache. Ein Array mit 10 Millionen Integern belegt in perl
ein Vielfaches der Größe in einem C-Programm.
Felix
Michael Linnemann
>> Du erwähnst die große Masse zwischen - ich zitiere - »Erfahrene
>> Programmierer« und »ein Idiot« irgendwie mit keinem Wort.
>Diese Masse gibt es nicht.
Selektive Wahrnehmung?
>Entweder man beherrscht eine Programmiersprache souverän oder man ist
>ein Stümper, der nur zufällig mal ein funktionierendes Programm
>abliefert.
Offensichtlich selektive Wahrnehmung...
> Ich habe nur Verwendung für Programmierer, bei denen ich mir
>sicher sein kann, daß sie in der Lage sind, das Problem zu lösen. Wenn
>ich das am Ende kontrollieren muß, kann ich es auch gleich selber
>machen.
Ach daher weht der Wind. Du arbeitest allein, stimmts? Weil du noch
niemanden getroffen hast, der dir das Wasser haette reichen koennen?
Gruss
Michael (fuer dich unsichtbar - sorry, ist keine Absicht)
Oliver Bandel
>> > Ich habe jedenfalls noch nie in einem meiner Perl-Programme im
>> > Nachhinein signifikante Performance-Gewinne erzielen können. Warum
>> > auch. Wenn man weiß, wie es effizienter geht, macht man es
>> > natürlich gleich so.
>> Wenn Du merkst, daß ein bestimmter Teil des Perl-Programms die meiste
>> Zeit braucht, kannst Du diesen Teil in C implementieren. Ohne gleich
>> alles in C zu schreiben. Der Algorithmus bleibt der selbe.
> So ein Schwachsinn.
Nö, nix Schwachsinn, das stimmt.
> Daß ein bestimmter Teil CPU-intensiv ist, fällt dir erst während des
> Programmierens auf?!
Das hat er doch garnicht gesagt.
"Wenn Du merkst, daß" heißt nicht "Ich merke es erst, während..."
>> > Du implizierst hier, daß nur Laufzeit eine relevante Ressource ist.
>> > Tatsächlich ist der RAM-Verbrauch gewöhnlich auch eine Größenordnung
>> > größer.
>> Das kommt aber sehr stark auf die Problemstellung an. Ich habe höchst
>> selten Probleme, bei denen die Größe des Codes in irgendeiner Form
>> relevant wäre.
> Ich rede nicht von der Code-Größe, sondern von der Größe der Metadaten
> der Scriptsprache. Ein Array mit 10 Millionen Integern belegt in perl
> ein Vielfaches der Größe in einem C-Programm.
Für solche umfangreichen Datensätze nimmt man i.d.R. dann auch C.
Das merkt man ja auch vorher ("wenn man merkt, daß"); wenn nicht,
ist das eben Pech.
Trotzdem kann man seine Algorithmus-Implementetion für 10.000 Ints
schon mal in Perl antesten und wenns bei 1.000.000 Ints zu lange
dauert, kann man immernoch auf C umsteigen.
Man ist bei der Vorab-Implementierung mit ein paar Perl-Zeilen
aber schneller am Ziel, wenn man sein Problem noch explorativ
erkunden muss.
Ciao,
Oliver
--
Anyway, pioneers are *always* depressed and always dissatisfied
with the current state of technology - it goes with the job. The
"this suck's, can't we do it better" thought is the eternal motivator ...
(Joe Armstrong in comp.lang.functional)
Andreas Kurth
> Entweder man beherrscht eine Programmiersprache souverän oder man ist
> ein Stümper, der nur zufällig mal ein funktionierendes Programm
> abliefert. Ich habe nur Verwendung für Programmierer, bei denen ich mir
> sicher sein kann, daß sie in der Lage sind, das Problem zu lösen. Wenn
> ich das am Ende kontrollieren muß, kann ich es auch gleich selber
> machen.
Kann es sein, daß Du noch nicht besonders viel Berufserfahrung hast
(ich rede hier nicht von fachlicher Erfahrung)? Der Betrieb im
Berufsalltag sieht leider zumeist etwas anders aus als der
Uni-Elfenbeinturm.
Du kannst doch nicht ernsthaft davon ausgehen - und zwar nicht nur
in der IT- sondern in jeder beliebigen Branche -, daß Du nur mit
120prozentigen Könnern zusammenarbeiten darfst. Deine zukünftigen
Mitarbeiter (so Du mal welche findest) tun mir leid.
--
Andreas Kurth
Mannheim, Germany
http://sites.inka.de/wam56
Axel Schwenke
Felix von Leitner <usenet-...@fefe.de> writes:
> Thus spake Andreas Riedel (andreas...@hrz.tu-chemnitz.de):
>> > Was du hier beschreibst ist die Zeit, die ein Idiot braucht, um in
>> > einer Programmiersprache, die er nicht beherrscht, mal eben was
>> > zusammenzukludgen.
>> Manche Dinge gehen in Scriptsprachen ganz einfach wesentlich schneller
>> hinzuschreiben. Weil es da 20 Zeilen sind und nicht 200 zum Beispiel.
>
> Nein.
> Du verwechselst da Sprache und Laufzeitumgebung.
Ich glaube, *du* hast noch nie versucht, ein mittelgroßes Perl-Skript
(ein bischen was mit Hashes, MySQL und RegEx) in C nachzuprogrammieren.
Sobald man für Strings mehr als strcat braucht, ist C purer Masochismus
>> > Programme, die CPU-bound sind, wird nur ein Idiot in einer
>> > Skriptsprache implementieren. Beispiele: bulk-cipher, md5sum, gzip,
>> > langzahl-arithmetik, Signalverarbeitung, Volltextsuche.
>> Es gibt jede Menge Leute, die stark rechenintensive Sachen z.B. in
>> Matlab schreiben (Scriptsprache).
>
> Verstehst du den Unterschied zwischen "POV-Ray" (dein Beispiel) und
> "Multiplikationsroutine für zwei Integer beliebiger Länge" (mein
> Beispiel)?
Auch dieses Beispiel sticht nicht. Ich habe gerade im Rahmen meiner
ersten Schritte mit Java (bin *nicht* begeistert) mein Standardbeispiel
"rechne n Fakultät aus" implementiert. Und mal verglichen. Einmal mit
Ruby (bin *total* begeistert) und mit je einer Perl-, C- und C++
Implementierung.
Laufzeiten für n=10000 (auf P3/725 unter Linux)
Ruby: 5.12 sec (inc + multiply)
Java: 4.95 sec (inc + multiply, JDK 1.2.2, green threads)
Perl: 1.35 sec (inc + multiply, Math::GMP)
C: 0.52 sec (mpz_fac_ui() aus libgmp)
C++: 0.27 sec (factorial() aus libcln)
Interessanterweise sind die Laufzeitunterschiede zwischen den nativen
Lösungen (C/C++) von der gleichen Größenordnung wie die zwischen den
nativen und Skriptsprachen. Wenn man in C/C++ statt der eingebauten
(optimierten) Fakultät-Funktionen eine increment+multiply Schleife
verwendet, wird der Abstand noch geringer.
Und was die Lesbarkeit/Kürze/Eleganz der Programme angeht:
1. Ruby
2. Perl
3. C++
4. Java
5. C
IMHO. YMMV. Wer möchte, kann die Programme gerne von mir bekommen.
Rainer Weikusat
> Sobald man für Strings mehr als strcat braucht, ist C purer
> Masochismus
Solange man mit 8-Bit-Zeichen auskommt, ist es dafür ein ziemlich
schneller Masochismus, weil essentiell lediglich ein leicht
generalisiertes 'Interface' zur CPU.
Vorteil: Portabler Makroassembler
Nachteil: Genau das.
--
SIGSTOP
Anselm Lingnau
Rainer Weikusat <weik...@mail.uni-mainz.de>:
> Solange man mit 8-Bit-Zeichen auskommt,
... und es einem nichts ausmacht, sich bei der Speicherverwaltung in
Knoten zu binden, ...
> ist es dafür ein ziemlich schneller Masochismus, weil essentiell
> lediglich ein leicht generalisiertes 'Interface' zur CPU.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Usenet is like Tetris for people who still remember how to read.
-- Joshua Geller
Anselm Lingnau
Felix von Leitner <usenet-...@fefe.de>:
> Daß ein bestimmter Teil CPU-intensiv ist, fällt dir erst während des
> Programmierens auf?!
Das hat er nicht behauptet.
> Ich rede nicht von der Code-Größe, sondern von der Größe der Metadaten
> der Scriptsprache. Ein Array mit 10 Millionen Integern belegt in perl
> ein Vielfaches der Größe in einem C-Programm.
Das ist ein Problem von Perl und keines von Skriptsprachen
schlechthin. Für Python zum Beispiel gibt es Numerikerweiterungen,
deren Overhead gegenüber den entsprechenden Datenstrukturen
(typischerweise Vektoren und Matrizen) in Sprachen wie C oder FORTRAN
minimal ist.
Im übrigen kann es Situationen geben, wo man den Preis gerne bezahlt,
weil andere Vorteile den Nachteil größerer Daten aufwiegen.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
The Wright Brothers weren't the first to fly. They were just the first not to
crash. -- Anon.
Rainer Weikusat
> Rainer Weikusat <weik...@mail.uni-mainz.de>:
> > Solange man mit 8-Bit-Zeichen auskommt,
>
> ... und es einem nichts ausmacht, sich bei der Speicherverwaltung in
> Knoten zu binden, ...
... wenn mans gewohnt ist ;-), ist das alles halb so wild ...
--
SIGSTOP
Frank Klemm
>
>>> [...]
>>> Diese 20% sind möglicherweise Kandidaten dafür, in C (neu) geschrieben
>>> zu werden, die restlichen 80% mit einiger Sicherheit nicht.
>
>> Du implizierst hier, daß nur Laufzeit eine relevante Ressource ist.
>> Tatsächlich ist der RAM-Verbrauch gewöhnlich auch eine Größenordnung
>> größer. Und das kriegst du nicht weg, [...]
>
>Und der mitunter beeindruckende Overheaed beim Start, z.B. bei perl,
>kommt besonders bei kleineren Programmen auch noch dazu.
>
Ob das nun Perl+C oder C+Assembler ist, ist egal.
Desweiteren sieht man sich zur Optimierung einfach die Profilingliste an:
------------------------------------------------------------------------------
100.0% 11307.450419 ms *** TOTAL *** [300.7 MHz]
34.31% 3879.414842 ms Synthese_Filter_opt() synth.c:323
20.19% 2282.503373 ms Read_Bitstream_SV7() decode.c:519
15.95% 1803.646555 ms Huffman_Decode_fastest() decode.c:221
13.11% 1482.251687 ms Calculate_New_V() synth.c:43
4.79% 541.890319 ms Requantize_MidSideStereo() tools.c:160
4.03% 456.191758 ms Synthese_Filter_opt() synth.c:329
2.15% 242.718695 ms Read_LittleEndians() tools.c:101
1.94% 219.661037 ms Huffman_Decode() decode.c:142
1.67% 189.052218 ms Bitstream_read1() decode.c:102
0.63% 71.447065 ms Bitstream_read() decode.c:74
0.50% 56.359363 ms fwrite_with_test() wave.c:26
0.44% 49.578043 ms Decode() mppdec.c:78
0.22% 24.648224 ms DecodeFile() mppdec.c:271
...
Ob das nun 80%, 90% oder 99% sind, ist egal.
--
Frank Klemm
Rainer Weikusat
> Desweiteren sieht man sich zur Optimierung einfach die
> Profilingliste an:
Und zwar solange, bis man kapiert hat, was ein bottleneck ist, und wo
es üblicherweise auftritt. Danach darf man das vergessen. Ein Profiler
ist ein sehr nützliches Lernwerkzeug.
--
SIGSTOP
Felix von Leitner
> Kann es sein, daß Du noch nicht besonders viel Berufserfahrung hast
> (ich rede hier nicht von fachlicher Erfahrung)?
Nein.
> Der Betrieb im Berufsalltag sieht leider zumeist etwas anders aus als
> der Uni-Elfenbeinturm.
Stümper dürfen gerne zugucken und kriegen mehr als eine Chance,
Lernfähigkeit zu zeigen. Ansonsten gilt: wer nicht helfen kann, soll
bitte auch nicht im Weg stehen. Ansonsten geht entweder er oder ich.
Mein Leben ist zu kurz, um mich an irgendwelchen Lusern aufzureiben.
Im Übrigen erwarte ich von anderen nichts, was ich nicht auch von mir
selber fordere. Bei einem Wasserrohrbruch werde ich dem Klempner nicht
im Wege stehen. Höchstens werde ich aus einer Entfernung zugucken, die
garantiert, daß ich nicht störe.
> Du kannst doch nicht ernsthaft davon ausgehen - und zwar nicht nur
> in der IT- sondern in jeder beliebigen Branche -, daß Du nur mit
> 120prozentigen Könnern zusammenarbeiten darfst.
Doch, natürlich.
Wer es nicht kann, arbeitet nicht mit mir zusammen, sondern steht herum.
Solange er nicht stört und mir keine Kosten verursacht, ist mir das egal.
> Deine zukünftigen Mitarbeiter (so Du mal welche findest) tun mir leid.
Probleme löst man nicht, indem man herumfaselt.
Probleme löst man, indem man herausfindet, wer sie lösen kann, und den
das Problem lösen läßt. Insbesondere heißt das, daß man demjenigen
nicht im Weg steht.
Welchen Teil davon hast du nicht verstanden?
Felix
Felix von Leitner
> ... und es einem nichts ausmacht, sich bei der Speicherverwaltung in
> Knoten zu binden, ...
Und wieder hat jemand den Unterschied zwischen Sprache und Umgebung
nicht verstanden.
Warum postest du zu Sachen, die du nicht verstehst?
Felix
--
> i believe under the same circumstance sendmail will skip subsequent
> deliveries.
Under the same circumstance, sendmail will choke and die.
--Dan Bernstein, author of qmail
Philipp Hemker
> > Ich rede nicht von der Code-Größe, sondern von der Größe der Metadaten
> > der Scriptsprache. Ein Array mit 10 Millionen Integern belegt in perl
> > ein Vielfaches der Größe in einem C-Programm.
>
> Das ist ein Problem von Perl und keines von Skriptsprachen
> schlechthin.
Warum und warum nicht?
Oder, was ist eine Skriptsprache? Eine Sprache an sich
oder eine bestimmte Implementierung eines Interpreters?
Hmm, "Nothing but perl can parse Perl."
> Für Python zum Beispiel gibt es Numerikerweiterungen, deren Overhead
> gegenüber den entsprechenden Datenstrukturen (typischerweise
> Vektoren und Matrizen) in Sprachen wie C oder FORTRAN minimal ist.
Welche meinst du? Gilt das auch für JPython, äh, Jython?
Aber, um beim Beispiel "10 Millionen Integer" zu bleiben, Python
hat ein Modul "array", für Perl gibt es u.a. "Tie::IntegerArray",
pack/unpack kennen beide, mehr oder weniger, Numerical Python hat
"multiarray", aka "extension types written in C", und, ein Skript:
#! /usr/bin/perl
use MyModule;
exit( MyModule::main(@ARGV) );
wird kaum langsamer sein und nur unwesentlich mehr Speicher
verbrauchen als eine compilierte Fassung von MyModule.c.
Dann waren da noch guile, scheme, common lisp, alle andere lisps,
visual basic, ruby, tcl, undsoweiter, Skriptsprachen oder nicht?
bis dann,
philipp
--
Andreas Kurth
> Stümper dürfen gerne zugucken und kriegen mehr als eine Chance,
> Lernfähigkeit zu zeigen.
>
Ich sehe noch nicht ein, warum jeder, der nicht in jeder beliebigen
Programmiersprache jederzeit optimalen Code schreibt, ein Stümper
sein muß. Deine Sprache ist arrogant und verächtlich. Ich kann mich
erinnern, daß ich in der achten Klasse eine ähnliche
Schwarz-Weiß-Sicht gepflegt habe.
> Welchen Teil davon hast du nicht verstanden?
Ich denke, ich habe jeden Deiner kindischen Sätze verstanden. Leider.
Uwe Ohse
>Ich sehe noch nicht ein, warum jeder, der nicht in jeder beliebigen
>Programmiersprache jederzeit optimalen Code schreibt, ein Stümper
>sein muß.
das behauptet Felix auch gar nicht.
Was er behauptet ist daß jemand, der in einer Sprache programmiert,
die er nicht beherrscht, und die Ergebnisse dann veröffentlicht,
eine Gefahr darstellt. Womit er, Bugtraq kann als Beweis herhalten,
recht hat.
Nebenbei behauptet er daß er nur mit Leuten zusammenarbeitet die
ihr Handwerkszeug beherrschen. Ich hoffe das ist auch so, alles
andere spricht gegen ihn.
Felix behauptet keineswegs daß man sich mit jeder Sprache
auskennen muß.
>erinnern, daß ich in der achten Klasse eine ähnliche
>Schwarz-Weiß-Sicht gepflegt habe.
Ach je. Lerne _lesen_.
>Ich denke, ich habe jeden Deiner kindischen Sätze verstanden. Leider.
Werd' nicht ausfallend, ja ...
Kindisch ist eher Dein "bäh, der will nicht mit mir spielen".
Gruß, Uwe
Sascha Ziemann
| > Wenn Du merkst, daß ein bestimmter Teil des Perl-Programms die meiste
| > Zeit braucht, kannst Du diesen Teil in C implementieren. Ohne gleich
| > alles in C zu schreiben. Der Algorithmus bleibt der selbe.
|
| So ein Schwachsinn.
|
| Daß ein bestimmter Teil CPU-intensiv ist, fällt dir erst während des
| Programmierens auf?!
Selbst wenn es so wäre, ist das nicht der Punkt. Tatsache ist, dass
der Rechner, den man heutzutage auf dem Schreibtisch stehen hat, in
den allerwenigsten Fällen nicht das Nadelöhr bei der überwiegenden
Mehrzahl der Programme ist. Erst wenn man anfängt, das was man in
seiner Entwicklungsumgebung erstellt hat, auf die Slot-CPU zu bringen,
die aus Kostengründen ggf. nur ein 386er ist, ist der Zeitpunkt
gekommen, wo man ernsthaft über Optimierung nachdenken muss. Es ist
viel einfachen die eigentlichen Algorithmen in einer mächtigen
Hochsprache zu verfassen, weil man dort viel schneller mal Variationen
an der Implementation austesten kann. Wichtig ist in ersten Linie,
dass das Programm übersichtlich ist, weil nur dadurch die Richtigkeit
überprüft werden kann. Und wenn man anhand der Referenzimplementation
zu dem Ergebnis gekommen ist, dass die erstellte Lösung das Problem an
besten löst, kann man anfangen, sich über Optimierungen Gedanken zu
machen. Oft ist es nämlich völlig nebensächlich, ob das Programm
optimiert ist oder nicht, weil sowieso genug Rechenleistung da ist.
Und warum soll man einen teuren Programmierer mit Optimierungen
beschäftigen, wenn man das Problem einfach dadurch lösen kann, indem
man eine CPU mehr daneben stellt?
Sascha Ziemann
Wenn man es gewohnt ist auf Bugtraq immer schön nach
Sicherheitslöchern zu suchen stört es nicht weiter?
Es ist doch wohl unbestritten, dass mindestens 50% aller auf dieser
Welt existierenden Sicherheitslöcher auf das Konto der
Speicherverwaltung von C gehen bzw. auf das Konto solcher, die meinen
sie hätten in ihrer Genialität die Speicherverwaltung von C im Griff.
Rainer Weikusat
> Es ist doch wohl unbestritten, dass mindestens 50% aller auf dieser
> Welt existierenden Sicherheitslöcher auf das Konto der
> Speicherverwaltung von C gehen bzw. auf das Konto solcher, die
> meinen sie hätten in ihrer Genialität die Speicherverwaltung von C
> im Griff.
Eher darauf, das Leute in ihre Programme Sachen wie '*tp++ = *cp++'
(ntpd) reinschreiben, wobei cp unüberprüfte Daten aus einer nicht
vertrauenswürdigen Quelle enthält.
--
SIGSTOP
Gerd Knorr
Das auch. perl kennt -T btw.
Gerd
Rainer Weikusat
> Rainer Weikusat wrote:
> > Eher darauf, das Leute in ihre Programme Sachen wie '*tp++ = *cp++'
> > (ntpd) reinschreiben, wobei cp unüberprüfte Daten aus einer nicht
> > vertrauenswürdigen Quelle enthält.
>
> Das auch. perl kennt -T btw.
Das ist das, womit man folgendes hinkriegt:
<perl [setuid]>
.
.
.
exec(@irgendwas)
</>
<irgendwas.c>
int main()
{
.
.
.
env = NULL;
execl(irgendwas, anderes);
}
</>
<perl>
Unsafe $ENV{PATH}...
</>
Der Nutzwert erscheint mir häufig begrenzt :->
--
SIGSTOP
Frank Klemm
Das sind einfach zwei Dateien und man muß leider jeweils das Anfang und das
Ende jeder Funktion (die man monitoren möchte) mit einem Makro markieren.
Funktioniert z.Z. nur mit gcc und mit MS VC++ (ab Pentium) und mit Turbo-C
unter MS-DOS (ab 8086).
--
Frank Klemm
Benedikt Meurer
<uwe-dcou...@ohse.de>:
>>Ich sehe noch nicht ein, warum jeder, der nicht in jeder beliebigen
>>Programmiersprache jederzeit optimalen Code schreibt, ein Stümper sein
>>muß.
>
> das behauptet Felix auch gar nicht.
> Was er behauptet ist daß jemand, der in einer Sprache programmiert, die
> er nicht beherrscht, und die Ergebnisse dann veröffentlicht, eine Gefahr
> darstellt. Womit er, Bugtraq kann als Beweis herhalten, recht hat.
> Nebenbei behauptet er daß er nur mit Leuten zusammenarbeitet die ihr
> Handwerkszeug beherrschen. Ich hoffe das ist auch so, alles andere
> spricht gegen ihn.
ACK.
>>erinnern, daß ich in der achten Klasse eine ähnliche Schwarz-Weiß-Sicht
>>gepflegt habe.
> Ach je. Lerne _lesen_.
Nunja, irgendwo hat er aber auch recht: Menschen nur nach Gut oder
Schlecht einordnen ist nicht ganz realistisch, da es auch Zwischenstufen
geben kann, die z.B. kurz vor Gut sind.
>>Ich denke, ich habe jeden Deiner kindischen Sätze verstanden. Leider.
> Werd' nicht ausfallend, ja ...
> Kindisch ist eher Dein "bäh, der will nicht mit mir spielen".
Nana, wir wollen doch den guten Ton wahren. Kein Grund sich gegenseitig
zu beschimpfen, jeder hat halt seine eigene Meinung.
Mit freundlichen Grüßen
Benedikt Meurer
Felix von Leitner
> Nebenbei behauptet er daß er nur mit Leuten zusammenarbeitet die
s/nur mit/nur gerne mit/
Ich sagte außerdem, daß ich Leute, die zugucken und bei der Arbeit nicht
im Wege stehen, nicht wegschicke. Ich habe überhaupt nichts dagegen,
wenn jemandem das Vorwissen fehlt, um ein Problem zu lösen. Ich habe
ein Problem damit, wenn derjenige sich dann trotzdem mit Gewalt
einbringt (und zwangsläufig Schaden verursacht), anstatt die Gelegenheit
zur Fortbildung zu nutzen.
Wenn ein Team _nur_ aus Leuten besteht, die sich nicht auskennen, dann
sollte man es natürlich lieber auflösen, als daß alle rumsitzen und auf
jemanden warten, von dem sie was lernen können.
Felix
--
I am not interested in your unjustified speculation about vague
categories of hypothetical events. I want to see _real_ examples so
that I can understand what _real_ problems people are facing.
--Dan Bernstein
Felix von Leitner
> Nunja, irgendwo hat er aber auch recht: Menschen nur nach Gut oder
> Schlecht einordnen ist nicht ganz realistisch, da es auch Zwischenstufen
> geben kann, die z.B. kurz vor Gut sind.
So ist das aber nicht.
Auf einem Gebiet bist du entweder gut genug, daß man deine Arbeit nicht
nochmal kontrollieren muß (das definiere ich als "gut"), oder du bist
ein Stümper, der eher zufällig mal was abliefert, das den Anforderungen
vielleicht genügt (das definiere ich als "stümperhaft"). Das richtet
Schaden an, weil jemand anderes Zeit aufbringen muß, um deine Arbeit
nachzuprüfen.
Abstufungen ergeben sich in der Summe der Gebiete, auf denen jemand gut
ist.
Ich will damit übrigens nicht sagen, daß es nicht allgemein sinnvoll
ist, wenn Code nochmal von anderen überprüft wird! Im Gegenteil.
Felix
--
Anytime four New Yorkers get into a cab together without arguing, a bank
robbery has just taken place.
--Johnny Carson