Interessante Sicht auf die PLO - Seite 2

 
Mikhail Mishanin:

Das ist eine destruktive Reaktion auf das Thema und eine destruktive Diskussion. Sagen Sie mir als Anhänger der prozeduralen Programmierung, wie man die "Spaghettisierung" in der OOP vermeidet, wie man parst und ob es sinnvoll ist, die "Spaghetti" von jemand anderem zu verwenden?

Schließlich dient OOP vor allem der Lesbarkeit und der Programmierung im Team, d.h. für große Projekte. Ein Expert Advisor, der ein Symbol zu seinem Diagramm mit der Kontrolle des maximalen Risikos des Gleichgewichts / Fonds auf dem Konto handelt, gut, kann nicht ein großes Projekt genannt werden - es ist ausreichend und profitabler in Speicher / Geschwindigkeit - prozedurale Programmierung.

Fragen:

- Nachteile/Vorteile von OOP (als Imperativ) aus persönlicher Erfahrung

- Nachteile/Vorteile von FP (als deklarativ) aus persönlicher Erfahrung.

Und eine Meinung zu den Aussichten ist natürlich interessant, vor allem in Richtung paralleles Rechnen. Ich sehe keinen Sinn darin, das Thema Quantum zu berühren.

Ich muss sehen, woher das kommt, denn ich verstehe nicht, was es mit Spargeting auf sich hat.

Eine gute Eigenschaft eines jeden Codes ist es, Funktionen so kurz wie möglich zu halten. Es wäre besser, wenn Sie mehr davon hätten.

Zum Beispiel sind die Hälfte der OOP-Eigenschaften Dinge, die wir aus Gründen der Benutzerfreundlichkeit trennen möchten (z. B. eine Reihe von Funktionen in eine Gruppe aufteilen und ihnen ihre eigenen Variablen geben, die in ihrem Namensraum leben).

Da wir mit einem Speichertyp "Klasse" arbeiten, können wir alle Variablen eindeutig vordefinieren, um ihnen einen bestimmten Typ zu geben....

ist es praktisch, eine externe API zu erstellen. Sie können bei der Arbeit mit einer Klassenreferenz (8 Bytes) arbeiten - sehr häufig verwendet.

Beispiel: Alle möglichen Arten von verknüpften Knotenlisten und so.


// hier habe ich nur Besonderheiten geschrieben, die ich sehe, es ist klar, dass es keinen Sinn macht, über Möglichkeiten und Eigenschaften von geschützten Methoden und anderen Dingen zu schreiben.... das ist nur Zucker.

Eigenschaften von FP ist, was wir irgendwo tun möchten, nachdem etwas, zum Beispiel, möchten wir eine neue Funktion on the fly in der Funktion machen - teilen aktuelle Funktion, die einige der aktuellen Variablen aus unserer Funktion verwenden würde. Um ihre Ausführung an eine andere Funktion weiterzugeben - es stellt sich heraus, dass wir einfach die verzögerte Funktion, die Berechnung, die noch nicht stattgefunden hat, weitergeben - nur als ein Stück Code....

Das ist in der Tat sehr praktisch.

Damit bleibt die Eigenschaft des vollständigen Abrollens von Code erhalten, da wir genau wissen, welche Funktion wir haben - was wahrscheinlich schneller in der Berechnung ist als OOP. Man kann ziemlich clevere Übertragungen von Berechnungen von einer Funktion zu einer anderen organisieren - außerdem merkt sich die Funktion komplett die Umgebung der aufgerufenen Variablen der vorherigen Funktion - was sehr cool ist (obwohl es eigentlich nur das Speichern von deklarierten Variablen aus dem externen Bereich ist). Mit FP hingegen können Sie die Adresse einer Funktion festlegen und sie wie eine Klasse in einem Array speichern - allerdings nicht besonders nützlich.

Einfaches Schreiben von Code für verzögerte Aktionen, alle Arten von asynchronen Funktionen, parallele Berechnungen

 

Lassen Sie mich meine Bedenken auf der Grundlage des zitierten Artikels und des Konzepts des Determinismus selbst erläutern. Was macht mir bei der "Spaghettifizierung" Angst (die Komplexität des Codes selbst und die Aufgabe, Rechenfehler zu finden )? Nun, das ist es, worauf sich der Artikel konzentriert - "unsinnige" Werte in Variablen oder nicht-deterministische Rückgaben von Funktionen.

Ich baue/trainiere neuronale Netze mit der Struktur meiner Variable(n). Und für sie ist es sehr kritisch, dass "Müll" bei den Werten aus dem Nichts kommt.

Wie in dem Artikel - Sie treten auf das Bremspedal, und das Pedal kümmert sich einen Dreck um Sie. Das ist in Gebrauch. Und wenn in der Anfangsphase des Aufbaus (automatische Auswahl der Architektur) und des Trainings Ihres neuronalen Netzes "Unsinn" möglich ist - wie wird es aufgebaut/trainiert?

Wie kann man "Müll" (Nondeterminismus) in OOP so weit wie möglich vermeiden?

 
Mikhail Mishanin:

Lassen Sie mich meine Bedenken auf der Grundlage des zitierten Artikels und des Konzepts des Determinismus selbst erläutern. Was macht mir bei der "Spaghettifizierung" Angst (die Komplexität des Codes selbst und die Aufgabe, Rechenfehler zu finden )? Nun, das ist es, worauf sich der Artikel konzentriert - "unsinnige" Werte in Variablen oder nicht-deterministische Rückgaben von Funktionen.

Ich baue/trainiere neuronale Netze mit der Struktur meiner eigenen Variable(n). Und für sie ist es sehr kritisch, dass "Müll" bei den Werten aus dem Nichts kommt.

Wie in dem Artikel - Sie treten auf das Bremspedal, und das Pedal kümmert sich einen Dreck um Sie. Das ist in Gebrauch. Und wenn in der Anfangsphase des Aufbaus (automatische Auswahl der Architektur) und des Trainings Ihres neuronalen Netzes "Unsinn" möglich ist - wie wird es aufgebaut/trainiert?

Wie kann man "Müll" (Nondeterminismus) in OOP so weit wie möglich vermeiden?

Der Artikel im Allgemeinen ist etwas seltsam, der Mann hat eindeutig vergessen, den Typ der const-Variable anzugeben, wie er js dann zumindest readonly hatte. Danach schreibt er, dass er angeblich einen Fehler hatte, wenn das Objekt, das die Größe nicht ändern darf (eine Konstante sein muss), irgendwie keine Konstante ist ..... und daraus schließt er, dass die Wahrscheinlichkeit eines Fehlers in OOP groß ist)))

Im Allgemeinen ermöglicht OOP die Kontrolle von Variablenbereichen. OOP ist als Übertragung von Variablen aus einer Funktion konzipiert, d.h. wir sollten bereits einen Standardtyp haben, da es wahrscheinlich nur wenige davon gibt. Und wenn nötig, kann diese Funktion selbst im laufenden Betrieb erweitert werden.

D.h. in OOP gibt es mehr anfängliche Kontrolle

 

Ich weiß nicht, wer solche "Artikel" schreibt, leere Worte, allgemeine Phrasen, minimaler Sinn.

" Der Code als Ganzes war verwirrend und unordentlich - was in der Umgangssprache als "Spaghetti " bezeichnet wird " - wegen der schlechten Programmierer beiToyota werden wir davon ausgehen, dassder Code inOOP verwirrend ist.

" Die eingebauten OOP-Funktionen tragen nur zur Verwirrung bei. " - nun, Logik, die Fähigkeit, Features zu verwenden, verwirren den Code, mit einer ständigen Zunahme der Anzahl von OOP (C#) Features wird es unmöglich sein, einfachen Code zu schreiben mehr. Ja.

"In den meisten objektorientierten Sprachen werden Daten per Referenz übergeben, d.h. verschiedene Teile des Programms können mit der gleichen Datenstruktur arbeiten - und sie verändern. Dies macht das Programm zu einem großen Klumpen eines globalen Zustands und widerspricht der ursprünglichen Idee von OOP " - Undprivat,geschützt?

"...Wenn Ihnen dieses Zitat nicht gefällt, dann deshalb, weil der Nicht-Determinismus im Allgemeinen Sie nicht weiterbringt."Nun, ja, die unvorhersehbaren Funktionen GetMicrosecondCount, MathRand, CoptBuffer, alle Netzwerkfunktionen und andere sollten verworfen werden, weil das Ergebnis dort vom externen Zustand abhängt. Es ist furchtbar.

Okay, genug, hier ist alles klar.

 

Die meisten Argumente werden Ihnen aus den Fingern gesaugt. Einige Experimente, die die Ungültigkeit von OOP "beweisen", sind überhaupt nicht korrekt. In normalen OOP-Sprachen ist sum(int a, int b) immer sauber, auch wenn Sie intern Unsinn wie a += b schreiben. Auch hier gilt: Wird ein Objekt innerhalb einer Methode auf dem Heap alloziert, ist es immer geschützt, da nur die Methode, die es aufgerufen hat, einen Verweis darauf hat. Sie können sie nach Belieben ändern. Es gibt Referenz- und signifikante Typen. Niemand hindert Sie daran, in OOP-Sprachen saubere Funktionen ohne jegliche Seiteneffekte zu schreiben. Die mathematischen Standardfunktionen sehen zum Beispiel so aus. Ja, manchmal kann man auf gemeinsam genutzte Ressourcen nicht verzichten, aber es gibt praktische thread-sichere Sammlungen und vieles mehr. Schließlich wird jedes reine FP unweigerlich mit IO, BD, Netzwerkanfragen und vielen anderen Dingen interagieren, und das ist der Punkt, an dem Modifizierbarkeits-Daemons den Durchbruch schaffen werden.

 

Seltsamer Artikel....

Quantität wandelt sich in Qualität um.

Wenn es viele Funkgeräte gibt, kann es zu einer elektromagnetischen Inkompatibilität kommen und sie funktionieren nicht mehr.

Die Spaghetti-Eigenschaften des Codes ergeben sich in der Regel aus der Menge und der Nichtberücksichtigung aller Eigenschaften des Wrappers, wenn es viele Verwendungen in verschiedenen Zuständen gibt.

Bei den Funktionen führt das Vorhandensein von Rückkopplungen zum selben Ergebnis. Hysterese ist ein Witz)

Probleme verstehen und sie richtig angehen ... ))))

 
Alexandr Andreev:

// Ich habe nur die Funktionen beschrieben, die ich hier sehen kann. Es macht natürlich keinen Sinn, über die Möglichkeiten und Eigenschaften von geschützten Methoden und anderen Dingen zu schreiben.... das ist nur Zucker.

Eigenschaften von FP ist, was wir irgendwo tun möchten, nachdem etwas, zum Beispiel, wir möchten eine neue Funktion on the fly in einer Funktion komponieren - teilen die aktuelle, die einige der aktuellen Variablen aus unserer Funktion verwenden würde. Um ihre Ausführung an eine andere Funktion weiterzugeben - es stellt sich heraus, dass wir einfach die verzögerte Funktion, die Berechnung, die noch nicht stattgefunden hat, weitergeben - nur als ein Stück Code....

Das ist in der Tat sehr praktisch.

Nun, wer verhindert, dass das gleiche in OOP zu tun? Selbst in einer rein prozeduralen Sprache? Sie übergeben einen Zeiger auf eine Funktion an eine andere Funktion und erhalten eine verzögerte Ausführung.

Im Allgemeinen ist die Asynchronität ein reines Entwurfsmuster. Sie können asynchronen Code auch in reinem C schreiben. Man muss nur eine Zustandsmaschine bauen, die die Aufgabe in Teilen ausführt. Übrigens habe ich es mit Indikatoren in MQL gemacht, deren Berechnung sehr lange dauerte. Ich habe dies getan, um die Grafik nicht zu verlangsamen und einen schönen Statusbalken anzuzeigen, der den Erfüllungsgrad ändert.

 
Vasiliy Sokolov:

Nun, wer hindert Sie daran, dasselbe in OOP zu tun? Selbst in einer rein prozeduralen Sprache? Sie übergeben einen Zeiger auf eine Funktion an eine andere Funktion und erreichen so eine verzögerte Ausführung.

Im Allgemeinen ist die Asynchronität ein reines Entwurfsmuster. Sie können asynchronen Code auch in reinem C schreiben. Man muss nur eine Zustandsmaschine bauen, die die Aufgabe in Teilen ausführt. Übrigens habe ich es mit Indikatoren in MQL gemacht, deren Berechnung sehr lange dauerte. Es hilft mir, das Diagramm nicht zu verlangsamen und einen schönen Statusbalken anzuzeigen, der den Prozentsatz der Umsetzung ändert.

) Sie können auch Assembler verwenden. Die Frage ist, wo es einfacher ist.

Und stecken Sie mich weder auf die eine noch auf die andere Seite.... Ich bin kein Verfechter der einen oder anderen Sache.

 

Seltsamer Artikel. OOP unterscheidet sich nicht zum Schlechteren vom prozeduralen Stil, weil man damit standardmäßig alles im prozeduralen Stil machen kann und umgekehrt, ohne dass der Code furchtbar aufgebläht wird, d.h. OOP ist ein "Überbau", kein grundlegend anderer Stil.

Wenn es in dem Artikel wirklich um funktionale und nicht um verfahrenstechnische Aspekte geht (was nicht so offensichtlich ist, wenn man darauf herumhackt), warum sollte man dann Dinge vergleichen, die völlig unterschiedliche Verwendungszwecke haben.

Topeka starter, schreibst du selbst und sprichst jetzt über was? funktional oder prozessual?

 
Mikhail Mishanin:

Schließlich hat sich herausgestellt, dass OOP vor allem für die Lesbarkeit und die Programmierung im Team, d.h. für große Projekte, geeignet ist.

Ich weiß nicht, wie man OOP benutzt. Aber ich verwende primitive Dinge davon. Aus der jüngsten Vergangenheit, postete einige sehr einfachen Code.


Ich habe mit dem Schreiben in FP begonnen, als ich noch nicht wusste, was ich letztendlich betrachten muss.

Abgeschlossen durch die primitiven Elemente der OOP. Wahrscheinlich verloren FP Fähigkeiten, aber hier OOP schien viel einfacher und lesbarer.


Der Code ist sehr einfach und kurz(Beschreibung). Wenn Sie es in FP schreiben, wäre es interessant zu vergleichen.