Wie programmiert ihr?
-
Hi,
ich lese gerade The Art of Unix Programming und das bringt mich doch zum Nachdenken wie wenig ich mir bisher über viele Techniken wie OO, Threads oder RPC Gedanken gemacht habe. Ein Zitat aus obigem Buch trifft den Kern der Sache recht gut:
The combination of threads, remote-procedure-call interfaces, and
heavyweight object-oriented design is especially dangerous. Used sparingly
and tastefully, any of these techniques can be valuable — but if you are
ever invited onto a project that is supposed to feature all three, fleeing
in terror might well be an appropriate reaction.We have previously observed that programming in the real world is all
about managing complexity. Tools to manage complexity are good things. But
when the effect of those tools is to proliferate complexity rather than to
control it, we would be better off throwing them away and starting from
zero. An important part of the Unix wisdom is to never forget this.Ich für meinen Teil habe fest vor zukünftig meine Programme grundsätzlich zu überdenken und mehr darauf zu achten meine Programme klein zu halten, statt Threads eher zwei Prozesse über ein wohldefiniertes Interface kommunizieren zu lassen und von Techniken wie RPC möglichst großen Abstand zu nehmen. Ebenso werde ich OO-Techniken deutlich reduzieren, damit ist nicht der objektorientierte Ansatz selbst gemeint, sondern die Tendenz tausend Klassen zu haben die alle "nichts" tun zu haben und das Wesentliche verbergen.
Wie programmiert ihr? Setzt ihr den Unix Ansatz schon lange ein? Oder seht ihr das völlig anders und geht daher einen anderen Ansatz?
-
Genau so wie beschrieben. Aber ich bin noch nie vor RPC+Thread+OO geflohen. Man muss halt etwas mehr ueber sein Design nachdenken und moegliche Teilsysteme entkoppeln.
-
Das einzige was "especially dangerous" ist ist die Dummheit und Unwissenheit der meisten "Programmierer" die aber trotzdem alle glauben richtig gut zu sein...
Zitat: 95% aller Programmierer glauben zu den Top 5% der Zunft zu gehören.
-
Hehe. Wenn dir schon RPC Angst macht, dann schau dir einmal Gambit an, das kann Continuations serialisieren...
-
µngbd schrieb:
Hehe. Wenn dir schon RPC Angst macht, dann schau dir einmal Gambit an, das kann Continuations serialisieren...
Meine compilierten Schemeprogramme haben sich immer mit einem segmentation fault beendet. Wahrscheinlich habe ich was falsch gemacht.
Habe dann bigloo benutzt und es funktionierte besser. Wer es interpretiert mag, kann auch ikarus oder guile (nicht ganz so schnell) benutzen.
-
Der erste Absatz ist kompletter Blödsinn. Jedenfalls wenn man ihn so allgemein nimmt, wie er formuliert wurde: In jedem Projekt, ganz gleich, worum es geht, sind Threads, RPC und OOP gefährlich. Darüber kann man doch eigentlich nur lachen!
OO-Techniken gehören, meine ich, überhaupt nicht in die Liste. Sie reduzieren Komplexität und erhöhen sie nicht. Selbstverständlich muss man diese Techniken beherrschen, aber gilt das nicht auch für Techniken ohne OO?! Wenn man objektorientiert desgined und programmiert, geht es nicht darum möglichst viele oder wenige Klassen zu haben, sondern angemessene Klassen, die gut designed sind.
Der zweite Absatz ist soweit OK. Bloß was folgt daraus? Irgend ein Hinweis auf die Techniken, Programmiersprachen, Tools, die man verwenden sollte? Ich meine nicht. Es ist einfach irgend eine allgemeine Aussage, die jeder abnicken kann. Sie klingt gut und sagt wenig. Irgendwie erinnert mich das an ein Interview mit Steinmeier (schreibt der sich so?), das letztens im Fernsehen kam
Stefan.
-
Komisch, das hab' ich auch noch nicht so richtig reflektiert, aber aus meinem Tätigkeitsfeld definiert sich das fast von selbst: Straight to the Bottom!
Ich meine damit, nicht tool- oder sprachorientiertes Denken führt zur effizientesten Lösung, sondern aufgabenzentriertes Denken. Letzteres sollte zum passenden Modell führen und rasch umsetzbar gewählt sein.
Leider versuchen viele, das Problem auf ihr Lieblingsmodell zu abstrahieren, was dann zu unpassenden Ansätzen und unnötiger Komplexität führt.
Ihr kennt das doch sicher auf, man erzählt jemandem, daß ein Byte von a nach b soll und ihr merkt am Gesichtsausdruck, daß bei dem Typen im Kopf zwanzig abstrakte Klassen ihren Pop- Up haben ...
-
Tools to manage complexity are good things. But when the effect of those tools is to proliferate complexity rather than to control it,
Erinnert mich an Programming Pearls (2nd. edition glaube). Wurde eine (einfache) Hausaufgabe gestellt. Zwei Gruppen habe Methoden der modernen Softwareentwicklung darauf angewandt und eine 3 Seiten Loesung produziert, obwohl eine halbe Seite schon viel war. Sie haben gerade so eine 3 (oder doch durchgefallen) bekommen mit der selben Begruendung: Tools sind zum Kontrollieren von Komplexitaet und nicht zum Erzeugen dieser.
Der zweite Absatz ist soweit OK. Bloß was folgt daraus?
Naja, daraus folgt, dass man erstmal seinen Kopf einschaltet.
-
Von Threads und RPC sollte man sich wirklich fernhalten. Wenn man sich nicht zu 100% sicher ist, dass man Threads braucht, kann man entweder das Programm nur unnoetig verkomplizieren und es dadurch langsamer machen, oder man baut sich Race-Conditions oder Deadlocks ein.
Bei RPCs sag ich nur Windows und die Virus-Situation. RPCs sind doch schon eine Einladung fuer jeden Botnet und fuer jeden Script-Kiddie. Siehe auch http://www.theregister.co.uk/2004/10/22/security_report_windows_vs_linux/#rpc
RPCs are potential security risks because they are designed to let other computers somewhere on a network to tell your computer what to do. Whenever someone discovers a flaw in an RPC-enabled program, there is the potential for someone with a network-connected computer to exploit the flaw in order to tell your computer what to do. Unfortunately, Windows users cannot disable RPC because Windows depends upon it, even if your computer is not connected to a network. Many Windows services are simply designed that way. In some cases, you can block an RPC port at your firewall, but Windows often depends so heavily on RPC mechanisms for basic functions that this is not always possible. Ironically, some of the most serious vulnerabilities in Windows Server 2003 (see table in section below) are due to flaws in the Windows RPC functions themselves, rather than the applications that use them. The most common way to exploit an RPC-related vulnerability is to attack the service that uses RPC, not RPC itself.
Edit:
Das beschreibt RPCs fuer Windows ziemlich gut: http://www.faqs.org/rfcs/rfc1831.html
Am Anfang der Seite steht:Attention: Are you looking for info about the cause of "Remote Procedure Call (RPC)", initiated by NT Authority\System error message that shuts down Windows (you might also see svchost.exe error occasionally)?
Ich erinnere mich noch, vor ein paar Jahren habe ich Windows XP neu installiert. Online gagangen und nach 10min oder so kommt ein Fenster mit "Your computer will be shutdown in Xxxx seconds". RPC FTW
-
knivil schrieb:
Der zweite Absatz ist soweit OK. Bloß was folgt daraus?
Naja, daraus folgt, dass man erstmal seinen Kopf einschaltet.
Schon recht. Das soll ja immer eine gute Sache sein
Ich hatte diesen Absatz bloß so verstanden, dass er den davor irgendwie argumentativ unterstützen soll (warum sonst wäre er zitiert worden?). Und ich meine, das tut er nicht. Es ist bloß ein Allgemeinplatz, der schön klingt. Und alle nicken weise mit den Köpfen. Konkret: Man erhält kein Argument für oder wider die allgemeine Verwendung von Threads, RPC und OO-Techniken.
Das ist wie: "Unsere Partei will Frieden und Wohlstand in Deutschland sichern..." ==> Also??? Gar nichts!!!
Stefan.
-
pointercrash() schrieb:
Ihr kennt das doch sicher auf, man erzählt jemandem, daß ein Byte von a nach b soll und ihr merkt am Gesichtsausdruck, daß bei dem Typen im Kopf zwanzig abstrakte Klassen ihren Pop- Up haben ...
wie wahr, hihi, *daumen_hoch*
-
DStefan schrieb:
Konkret: Man erhält kein Argument für oder wider die allgemeine Verwendung von Threads, RPC und OO-Techniken.
Wie schon oben erklaert, das Argument fuer die allgemeine Verwendung von Threads und RPC ist: Wenn du dir nicht zu 200% sicher bist, dann verwende es nicht.
Was aber OOP damit zu tun hat, weis ich auch nicht. Vielleicht ist der Satz mit OOP so zu verstehen, wie du, DStefan, es erklaert hast.
-
DEvent schrieb:
Wenn du dir nicht zu 200% sicher bist, dann verwende es nicht.
Bitte nochmal die Prozentrechnung üben.
-
knivil schrieb:
µngbd schrieb:
Hehe. Wenn dir schon RPC Angst macht, dann schau dir einmal Gambit an, das kann Continuations serialisieren...
Meine compilierten Schemeprogramme haben sich immer mit einem segmentation fault beendet. Wahrscheinlich habe ich was falsch gemacht.
Habe dann bigloo benutzt und es funktionierte besser. Wer es interpretiert mag, kann auch ikarus oder guile (nicht ganz so schnell) benutzen.Seltsam. Mit 4.4.0 auf win32 hatte ich noch gar keine Probleme. Mit irgendeinem 4.4.n auf Ubuntu hatte ich bis jetzt auch keine Probleme, es aber auch weniger verwendet. Was hast du denn für Sachen damit gemacht?
Btw sagen alle, die ich frage, dass Gambit und Schmeme48 "damn fast" sind. So bin ich nämlich drauf gekommen...
-
@µngbd: Du bist im falschen Thread.
War bestimmt 'ne race condition fuer bei einem remote procedure call verantwortlich. Zur Performance: stalin behauptet das auch, aber kann bigloo auch nicht schlagen. Mein Test war ein simples Tower of Hanoi, rekursiv mit 25 Scheiben.PS: Nein ich habe was verpeilt ... omg, ich sollte fuer heute aufhoeren zu arbeiten.
-
DEvent schrieb:
Wie schon oben erklaert, das Argument fuer die allgemeine Verwendung von Threads und RPC ist: Wenn du dir nicht zu 200% sicher bist, dann verwende es nicht.
Was für so ziemlich jede Technik der Software-Entwicklung gilt. Mir genügt es übrigens, zu 80% sicher zu sein
Stefan.
-
80% sicher sein? Ich strebe 100% an. Alles andere ist nur wischi waschi.
-
Nur 100%? Bei mir müssen es mindestens 120% sein.
-
knivil schrieb:
80% sicher sein? Ich strebe 100% an. Alles andere ist nur wischi waschi.
Na klar! Ich bin gern wischi waschi. Allerdings ein kleines bischen lieber wischi als waschi - wenn ich's recht bedenke
Und manchmal mach ich sogar einfach einen Thread, wenn ich mir nur 30% sicher bin. Aus Prinzip!
Stefan.
-
DEvent schrieb:
DStefan schrieb:
Konkret: Man erhält kein Argument für oder wider die allgemeine Verwendung von Threads, RPC und OO-Techniken.
Was aber OOP damit zu tun hat, weis ich auch nicht. Vielleicht ist der Satz mit OOP so zu verstehen, wie du, DStefan, es erklaert hast.
Um den OOP Teil zu verstehen muss man schon etwas mehr aus dem Buch gelesen haben als den Abschnitt, so isoliert passt er da nicht rein. Die Kernaussage zu OOP die sich über das Buch hinweg zieht ist, dass viele Programmierer dazu tendieren ihren Code mit tiefen und komplexen Klassenhierachien zuzupflastern, oder dicke "Glue"-Klassen ohne tiefe Funktionalität haben, oder starke Abhängigkeiten zwischen Klassen. Zu OOP wird auch folgender interessante Artikel referenziert: http://www.leshatton.org/IEEE_Soft_98a.html
Bevor jetzt die Autoren angegriffen werden: sie verteufeln weder OOP, RPC, Threads oder Java, nur die (vielen) Programmierer die diese Techniken leichtfertig einsetzen bzw. so einsetzen, dass die die Komplexität eines Programms erhöhen statt sie zu reduzieren (insoweit das möglich ist).