Loop
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
@Ralf: Genau genommen stimmt die Aussage doch. Da ABAP schon vor der Einführung des OO-Krams Turing-vollständig war ist durch die neuen Optionen nichts hinzugekommen was nicht vorher schon möglich war. Dass man mit OO Sachen möglicherweise verständlicher/leichter/kürzer/anders machen kann als ohne ist offensichtlich, genau wie jeder neue (ABAP)Befehl oder jede neue ausgelieferte Klasse einfach die Anzahl der Optionen erhöht.
Selbst wenn ABAP auf einmal funktionale Programmierung unterstützen würde käme de facto nichts Neues hinzu sondern es wäre nur möglich neue Sachen ganz anders aufzuziehen.
Selbst wenn ABAP auf einmal funktionale Programmierung unterstützen würde käme de facto nichts Neues hinzu sondern es wäre nur möglich neue Sachen ganz anders aufzuziehen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Gut, wenn man so argumentiert, dass nichts grundsätzlich Neues erfunden wurde, dann ist ABAP auch Assembler nicht überlegen. Dann frage ich mich, warum wir nicht alles in Assembler machen.
Funktional überlegen heißt für mich, dass eine Reihe von Dingen überhaupt erst praktikabel durchführbar werden, weil die Sprache dafür Mittel, Wege und Standards bieten.
Für mich ist OO *deshalb* funktional überlegen, weil es Funktionen von Haus aus bietet, die ich sonst mühevoll selbst implementieren müsste. Dass letztlich für den Prozessor alles gleich aussieht, ist mir so klar wie egal, mir geht es um die Sicht des Entwicklers, der praktikabel neue Möglichkeiten hat. So definiere ich funktionale Überlegenheit, weil ich sowas wie Vererbung oder Polymorphie nicht erfinden muss.
Ja, auch funktionale Programmierung ist nur eine Abstraktionsvsriante, aber auch die gibt es nur, weil sie in Bereichen anderen funktional überlegen ist. Sonst gäbe es sie nicht.
Mir kommt es darauf an, OO nicht als pseudo-religiöse Spinnerei abzutun.
Ralf
Funktional überlegen heißt für mich, dass eine Reihe von Dingen überhaupt erst praktikabel durchführbar werden, weil die Sprache dafür Mittel, Wege und Standards bieten.
Für mich ist OO *deshalb* funktional überlegen, weil es Funktionen von Haus aus bietet, die ich sonst mühevoll selbst implementieren müsste. Dass letztlich für den Prozessor alles gleich aussieht, ist mir so klar wie egal, mir geht es um die Sicht des Entwicklers, der praktikabel neue Möglichkeiten hat. So definiere ich funktionale Überlegenheit, weil ich sowas wie Vererbung oder Polymorphie nicht erfinden muss.
Ja, auch funktionale Programmierung ist nur eine Abstraktionsvsriante, aber auch die gibt es nur, weil sie in Bereichen anderen funktional überlegen ist. Sonst gäbe es sie nicht.
Mir kommt es darauf an, OO nicht als pseudo-religiöse Spinnerei abzutun.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
OO und Religion. Da erinnere ich mich an ein Interview mit Niklaus Wirth. Obwohl das schon recht alt ist, finden sich da doch einige Weisheiten drin. Und am Ende können sowohl Daniel als auch Ralf behaupten: "Seht alle her - N.W. teilt meine Meinung"ralf.wenzel hat geschrieben:Mir kommt es darauf an, OO nicht als pseudo-religiöse Spinnerei abzutun.
Niklaus Wirth in [url=http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html]Software Development, Vol. 5 No. 6, June 1997[/url] hat geschrieben:[...]
“Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming (OOP) solidly rests on the principles and concepts of traditional procedural programming (PP). OOP has not added a single novel concept, but it emphasizes two concepts much more strongly that was done with procedural programming. The fist such concept is that of the procedure bound to a composite variable called object. (The binding of the procedure is the justification for it being called a method). The means for this binding is the procedure variable (or record field), available in languages since the mid 1970s. The second concept is that of constructing a new data type (called subclass) by extending a given type (the superclass).
It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass. An interesting phenomenon is that many people learned for the first time about the important notions of data type, of encapsulation, and (perhaps) of information hiding when introduced to OOP. This alone would have made the introduction to OOP worthwhile, even if one didn’t actually make use of its essence later on.
Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming. Static modularization is the first step towards OOP. It is much easier to understand and master than full OOP, it’s sufficient in most cases for writing good software, and is sadly neglected in most common languages (with the exception of Ada).
In a way, OOP falls short of its promises. Our ultimate goal is extensible programming (EP). By this, we mean the construction of hierarchies of modules, each module adding new functionality to the system. EP implies that the addition of a module is possible without any change in the existing modules. They need not even be recompiled. New modules not only add new procedures, but – more importantly – also new (extended) data types. We have demonstrated the practicality and economy of this approach with the design of the Oberon System.”
[...]
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Es geht mir gar nicht darum, ob Daniel meine Meinung teilt, das passiert ohnehin nicht. Mir geht es darum, dass sie nicht als religiöse Spinnerei abgetan wird und OO ohnehin nur eine der Modewellen der letzten 40 Jahre ist, die genauso verschwinden wird wie einige andere.
OO hat seinen festen Platz in der IT und es gibt ein weites Feld praktikablen Einsatzes. Irgendwann wird es etwas anderes geben, aber ein "Zurück" werden wir nicht mehr erleben.
Ralf
OO hat seinen festen Platz in der IT und es gibt ein weites Feld praktikablen Einsatzes. Irgendwann wird es etwas anderes geben, aber ein "Zurück" werden wir nicht mehr erleben.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Zunächst mal sind Methoden Werkzeuge. Zur religiösen Spinnerei wird es
wenn jemand glaubt alles damit machen zu müssen. Das ist völliger Unfug.
Beispiel: Von Modewelle hab ich nix gesagt. Aber die Behauptung daß OO jetzt alle
Probleme löst (was in den letzten 40 Jahren mit fast jeder neuen Idee so
proklamiert wurde) ist Quatsch der leider ständig wiederholt wird.
Polymorphie führt zu unlesbarem Code. Ich halte das für sehr problematisch.
Es gibt Anwendungen wo es Sinn macht, aber das setzt man besser sehr sparsam
ein.
wenn jemand glaubt alles damit machen zu müssen. Das ist völliger Unfug.
Beispiel: Von Modewelle hab ich nix gesagt. Aber die Behauptung daß OO jetzt alle
Probleme löst (was in den letzten 40 Jahren mit fast jeder neuen Idee so
proklamiert wurde) ist Quatsch der leider ständig wiederholt wird.
Das Verwenden von vorhandenen Funktionen ist KEINE Errungenschaft von OO.Für mich ist OO *deshalb* funktional überlegen, weil es Funktionen von Haus
aus bietet, die ich sonst mühevoll selbst implementieren müsste.
Polymorphie führt zu unlesbarem Code. Ich halte das für sehr problematisch.
Es gibt Anwendungen wo es Sinn macht, aber das setzt man besser sehr sparsam
ein.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag (Insgesamt 2):
Romaniac • DeathAndPain
Ich sehe das eher so, dass DU keine andere Meinung teilst.ralf.wenzel hat geschrieben:Es geht mir gar nicht darum, ob Daniel meine Meinung teilt, das passiert ohnehin nicht. Mir geht es darum, dass sie nicht als religiöse Spinnerei abgetan wird und OO ohnehin nur eine der Modewellen der letzten 40 Jahre ist, die genauso verschwinden wird wie einige andere.
Ralf
Und "Dein" Thema "Ungarische Notation" ist doch auch in eine "religiöse Spinnerei' abgedriftet.
Ist meine Meinung, die Du sicher nicht teilen wirst.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Wenn ich mal auf die Stelle zurückverweise, an der diese Nebendiskussion begonnen hat: Was Du da beschrieben hast, geht komplett an dem vorbei, was Daniel gemeint hat. Er bezog sich auf meine Bemerkung, für eine 20-Zeilen-Formroutine nicht extra einen separaten lokalen Datentyp zu definieren, und Du redest von globalen Variabeln in 2000-Zeilen-Programmen. Sorry, aber das war komplett am Thema vorbei.
Es geht (Daniel) einfach darum, für jede Aufgabe ein angemessenes Werkzeug zu verwenden. Programme mit mehreren tausend Zeilen Code muss man sinnvoll strukturieren, damit sie verständlich bleiben. Lokale Typen in einer Form, die gerade mal 20 Zeilen Code umfasst, sind aber ebenso Overkill wie Methoden mit getrennter DEFINITION und IMPLEMENTATION in einem insgesamt nur 200-zeiligen Report. Man kann das machen, aber es macht nicht nur den Code länger und erhöht die Tipparbeit, sondern verschlechtert die Lesbarkeit sogar, weil dort, wo die Implementierung der lokalen Methode (also nix SE24) steht, die Parameter nicht ersichtlich sind. Da sind Formroutinen klar besser. Du darfst also nicht den Fehler machen, die Tatsache zu ignorieren, dass es im SAP-Bereich nicht nur Mammutprojekte gibt, sondern auch viele kleinere Entwicklungen. Nach meiner (und anscheinend auch Daniels) Erfahrung machen diese sogar die breite Mehrheit aus.
Wächst die Größe der Aufgabe, dann verschiebt sich das Kräftegleichgewicht hin zu OO. Allerdings kommt man gerade bei Projekten wie denen, von denen Du zu sprechen pflegst, normalerweise in den Bereich globaler Klassen, die man dann programmübergreifend recyclen kann und für die man übersichtlichere Entwicklungstools (wie die SE24) hat. Programmlokalen Methoden, bei denen am Anfang DEFINITION DEFERRED, dann irgendwo DEFINITION und noch wo anders IMPLEMENTATION steht, kann ich gegenüber Formroutinen keine Vorteile abgewinnen. Die Zersplitterung ein- und desselben Unterprogramms über den ganzen Code macht die Sache einfach nur unübersichtlich und damit schlecht wartbar.
Es geht (Daniel) einfach darum, für jede Aufgabe ein angemessenes Werkzeug zu verwenden. Programme mit mehreren tausend Zeilen Code muss man sinnvoll strukturieren, damit sie verständlich bleiben. Lokale Typen in einer Form, die gerade mal 20 Zeilen Code umfasst, sind aber ebenso Overkill wie Methoden mit getrennter DEFINITION und IMPLEMENTATION in einem insgesamt nur 200-zeiligen Report. Man kann das machen, aber es macht nicht nur den Code länger und erhöht die Tipparbeit, sondern verschlechtert die Lesbarkeit sogar, weil dort, wo die Implementierung der lokalen Methode (also nix SE24) steht, die Parameter nicht ersichtlich sind. Da sind Formroutinen klar besser. Du darfst also nicht den Fehler machen, die Tatsache zu ignorieren, dass es im SAP-Bereich nicht nur Mammutprojekte gibt, sondern auch viele kleinere Entwicklungen. Nach meiner (und anscheinend auch Daniels) Erfahrung machen diese sogar die breite Mehrheit aus.
Wächst die Größe der Aufgabe, dann verschiebt sich das Kräftegleichgewicht hin zu OO. Allerdings kommt man gerade bei Projekten wie denen, von denen Du zu sprechen pflegst, normalerweise in den Bereich globaler Klassen, die man dann programmübergreifend recyclen kann und für die man übersichtlichere Entwicklungstools (wie die SE24) hat. Programmlokalen Methoden, bei denen am Anfang DEFINITION DEFERRED, dann irgendwo DEFINITION und noch wo anders IMPLEMENTATION steht, kann ich gegenüber Formroutinen keine Vorteile abgewinnen. Die Zersplitterung ein- und desselben Unterprogramms über den ganzen Code macht die Sache einfach nur unübersichtlich und damit schlecht wartbar.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 4):
Daniel • Romaniac • Andaria • Unit605
Was hat der geraucht???trice001 hat geschrieben:Making your own beats isn't as troublesome as you may think. Hip Hop is straightforward, yet at the same time numerous makers over confuse the beat making process. Give me a chance to demonstrate to you best practices to make your own Hip Hop Beats with circles, and that it is so natural to make executioner tracks in a short measure of time. Most thumps comprise of a kick drum, catch, howdy cap, bassline and a slashed example that plays over the beat. The utilization of sound impacts, or percussion instruments, for example, bongos, or dairy animals chimes, can likewise be utilized to change up a beat. Timberland utilizes a great deal of percussion in his music. What a great many people don't know is top makers are utilizing circles to make music for prominent rappers and artists. In spite of mainstream thinking the utilization of circles are extremely basic in Hip Hop and Rap music.
Thanks& regards,
Angel anave
Toronto Web Development | Web Development Toronto
Geht nicht gibts nicht
Vergleichbare Themen
1
Antw.
Antw.
1492
Views
Views
Loop Loop & Loop - wie am besten eine Verschachtelung vermeiden?
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.