Lotus Notes / Domino Sonstiges > Projekt Bereich

Welche Schleife wann in Script

<< < (11/16) > >>

Axel_Janssen:
@Semaphoros,

1. Dykstra sagt in diesem paper, dass gotos in Assembler eine Berechtigung haben.
2. Deine strukturierte Programmierung 201 Beiträge sind wertvoll.  
3. halte ich deine Reaktion für hm irgendwie übertrieben.
4. Meine alte Paranoia kocht hoch, dass Leute mit fundierter Informatikausbildung mich als
- Freund von Java
- Freund von Webservices
- Freund von JSP/Servlets
- ca. 5 und steigend grösseren Java open Source frameworks
- Eclipse user
- OO-Pattern-Freund
- don't code take google
- Unified Process Anhänger,  
als irgendwie neureichen Modegeck ansehen.
 
Das ist aber einfach nicht wahr, weil:
- ich habe meinen Mc Conell, Code complete  
- ohne Studium von fundamentalen Prinzipien von verteiltem Rechnen und Datenbanktheorie und -praxis und 120 weitere Sachen helfen einem weder SOAP noch Enterprise Java Beans irgendwie weiter. Das ganze Marketing-Geseiber es würde einfacher und man bräuchte dieses ganzes low level Quatsch nicht, ist komplettester Unsinn.
 
Auf diese Tour bekommt man auf jeden Fall keine akzeptabel performanten Anwendungen hin und vermutlich noch nicht einmal lauffähige Anwendungen. Man muß oft eine Etage in den Keller gehen und sich damit auseinandersetzen, was dort passiert.  
Man kann auch nicht OO programmieren ohne ein vernünftig strukturiert programmieren zu können.

noch was:

--- Zitat ---Noch was: einen Schleifenkörper möglichst kurz zu halten ist nicht nur eine Frage der Uebersicht, sondern auch der Performance. Deshalb ist auch Vorsicht geboten mit Aufruf von Subroutinen anstelle der Ausprogrammierung einer Sequenz, da Subroutinen notorische Performance-Verschwender sind (keine Ahnung, welchen Preis man dafür in LotusScript zahlt, um das gleich mal klarzustellen).

--- Ende Zitat ---
Der Aufruf von Subroutinen kostet einen gewissen Performance overhead, ok. Das wird beim erzeugen von lustigen layers of indirection mit Klassen tendentiell noch verstärkt. Und wenn man dann noch nifty die Objekte auf verschiedene Tiers verteilt und coole xml-Layer verwendet möglicherweise potentiert (und das ist dann oft ein Problem).  
Solange man aber keine vernünftigen empirischen Daten hat, wie lange jetzt Methoden/Funktions/Remote SOAP_RPC-Aufruf A dauert und sich überlegt, ob der overhead signifikant für den business case ist, handelt es sich dabei um eben theoretische Informatik. Ich glaub wir sind uns da einig. Manche Sachen kann man mit Erfahrung voraussagen. Ich bin aber ehrlichgesagt oft überrascht worden, seitdem ich eigentlich bei jedem Java-code den ich schreibe mir Milisekunden Werte hole (da die Messung selbst Zeit kostet, sind solche Werte natürlich nie genau, aber man kann auf jeden Fall immer vergleichen).
 
Ich habe starkes Mißtrauen gegenüber:
- Objekt Verteilung auf verschiedene Rechner um ihrer selbst willen
- Aufteilung von Subsystemen in Komponenten mit "sauberen" Interfaces (low coupling, high cohesion) um ihrer selbst willen.

Performance ist ein Punkt bei der Entwicklung. Es gibt nur ein nicht wegzudiskudierender trade off zwischen Übersichtlichkeit von code und Performance von code.
Das klassische OO-Prinzip ist: Sauberer code ist erst einmal wichtiger. Zumal man in übersichtlichen code auch leichter die realen performance bottlenecks findet. Da ist meiner Ansicht nach sehr viel wahres dran.
Die Praxis (und v.a. die Praxis mit Erfahrung) ist aber immer ein Kompromiss und nicht diese Schlagwörter. Ich baue oft frühzeitig Performance freundliche Infrastruktur (Objekt-Pools, Singletons, etc) bevor es nach der reinen OO-Lehre nötig wäre. Ich beherzige ca. 20 grundlegende oft programmiersprachenspezifische Regeln von performanter Programmierung direkt beim coden.

Trotzdem würde ich niemals (ausser in "onError goto Fehler") goto verwenden, da ich in diesem Leben niemals Assembler programmieren werde. :)
 

Gruß Axel

Semeaphoros:
Axel, ich kann Dir im wesentlichen nur zustimmen und wie Du richtig bemerkst, war meine Aussage über "Achtung Performance" nur ein Hinweis, den ich anbringen wollte, weil viele Entwickler sich des möglichen Problemes nicht bewusst sind (insbesondere wenns um verteilte und mehrfach gelayerte Sachen geht, wie Du korrekt schreibst).

In deinem ganzen Post, zu dem ich praktisch überall nur "völlig richtig" sagen kann, gibt es einen Problempunkt, und der ist nicht technischer Natur:

Du schreibst:
Meine alte Paranoia kocht hoch, dass Leute.... mich .... als irgendwie neureichen Modegeck ansehen.

Also, damit meinst Du sicher nicht mich, ich habe das nicht getan, werde das auch nie tun.

Du hast früher mal geschrieben:
Goto ist nicht einfach grausam sondern ein Synonym für das Ende der Zivilisation.

Damit tust Du aber genau das mit anderen Leuten, was Dir gegenüber Deine Paranoia aufkochen lässt.

Also bitte, verwende doch für Dich genau dieselben Masstäbe, die Du auch von Deiner Umwelt Dir gegenüber verlangst.


Ich bin sogar mit Dir einverstanden, dass ich seit Jahren keine Gotos mehr verwende (ebenfalls mit Ausnahme des On Error Goto, wo es simpel keine Alternative gibt), und ich gehe sogar so weit, dass ich auch die verkappten Gotos genannt Exits praktisch immer vermeide (und zum Beispiel dafür lieber eine Flag-Variable verwende, welche dann unmerklich weniger performant ist als ein Exit, aber ich weiss das). Deine Bemerkungen über OO und strukturierte Programmierung und zuerst saubere Strukturen und dann Performance, da kann man nur sagen, das sollte man mal GANZ LAUT IN DIE WELT HINAUSSCHREIEN !!

In dem Sinne ganz sicher vielen vielen Dank für diese Auflistung.

TMC:
OK, überarbeitete Dokumentation siehe 1.Posting.

Recherchen von Rob's Links muss ich noch machen und einbauen.

Teilweise sind noch praxisnähere Beispiele erwünscht, als nur die von mir erwähnten (Zahlen von 1-20).

Also Beispiele für
  kopfgesteuerte
    - Do While...Loop
    - Do Until...Loop
  fußgesteuerte
    - Do...Loop While
    - Do...Loop Until
  sonstige
   - forall
   - do...loop

Thema Performance erwarte ich mir noch einiges von Rob's Links, muss die erstmal durcharbeiten.

Thema "Wie komm ich wieder raus": Hier brauche ich noch Input.
Was ja geht ist ein goto, was allerdings vermieden werden sollte weil es unübersichtlich werden könnte.
Dann wäre da noch ein Exit Sub, aber auch nicht so schön.

TMC

Semeaphoros:
Die Frage nach dem "wie komme ich wieder raus" ist weniger eine Frage des technischen "raus" (also goto oder exit) sondern mehr eine Frage der korrekten Logik:

Extremfall: For i= 1 to 20 step -1

.... verlässt den Loop nach einer Ewigkeit mit einem negativen Overflow ......

Für Forall ist der Ausstieg ja vorgegeben, Ueberlegung überflüssig, er nimmt einach alle Elemente des übergebenen Objektes.

Für do while, do until, while wend, loop until, loop while ist wichtig, sich beim Konzept der Schlaufe die Abbruchbedingung genau zu überlegen: Wird die Schleife überhaupt durchlaufen? Wenn ja, wird die Bedingung zur Abbruch der Schleife irgendwann erreicht? Gibt es Bedingungen, in denen die Schleife (vielleicht wegen Datenfehlehrn) gar nie verlassen werden kann und somit zum endlos-loop wird?

.... und dann bleibt ja noch der "nackte" do .... loop, bei dem der Hinweis fällig ist, dass er mit exit loop verlassen werden muss, da er keine steuernde Bedingung besitzt.

Semeaphoros:
Da habe ich mal die Links von Rob zur Schleifenperformance rasch überflogen und wurde eigentlich darin bestätigt, dass Performance ein hervorragendes Thema für eine Entwickler-Konferenz ist. Es beschäftitgt sporadisch wohl fast jedes Diskussions-Forum und ist trotzdem etwas, das für viele Entwickler, ganz besonders für "Quereinsteiger", recht schwer zu fassen ist. Eine gute Präsentation zum Thema dürfte deshalb ein willkommenes Ereignis darstellen.

Ich werde jedenfalls mal die Sache noch genauer studieren und dann wahrscheinlich entsprechende Vorschläge bei einschlägigen Konferenzen einreichen.

Ich halte Euch auf dem Laufenden, wenn irgendwo etwas in die Richtung "einschlägt".

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete