Fragen zu OOP in MQL5 - Seite 25
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Detaillierte Statistiken gibt es hier https://githut.info/, aber es ist das Jahr 14.
Neue Statistiken auf github https://madnight.github.io/githut/#/pull_requests/2019/2
Ich denke, dass es für jeden von Vorteil ist, die professionelle Meinung in diesem Artikel zu lesen.
Viel Glück!
Ich denke, dass es für jeden von Vorteil ist, die professionelle Meinung in diesem Artikel zu lesen.
alle (völlig voreingenommenen) Schlussfolgerungen des Artikels werden durch eine einfache Frage ausgeglichen.
FP gibt es schon lange, warum hat es immer noch eine so kleine Nische, wenn es so toll ist?
Ich will damit keineswegs sagen, dass OOP das beste Konzept ist oder OP schlecht ist.
alle (völlig voreingenommenen) Schlussfolgerungen des Artikels werden durch eine einfache Frage entkräftet.
FP gibt es schon sehr lange, warum hat es immer noch eine so kleine Nische, wenn es so toll ist?
Der Artikel enthält die Antwort auf diese Frage. Sie haben ihn nicht sorgfältig gelesen.
Der Artikel gibt eine Antwort auf diese Frage.
Völlig voreingenommen und über nichts.
Es gibt Entwickler, die tatsächlich den Code schreiben. Es gibt Manager, die vielleicht gar nicht programmieren können.
Der Technologie-Stack wird also nicht unbedingt von den Entwicklern ausgewählt. Und wenn ein bestimmter Stack es einem Team ermöglicht, ein Problem effizienter zu lösen, muss man die Technologie nicht kennen und besitzen, um sie zu verstehen.
Glauben Sie immer noch, dass der Artikel die Frage beantwortet?
Ich denke, dass es für jeden von Vorteil ist, die professionelle Meinung in diesem Artikel zu lesen.
Viel Glück!
Hier ist das Übliche. Extreme Standpunkte. Es ist wie ein Streit darüber, was besser ist - ein Hammer oder ein Vorschlaghammer.
Sie werden keine guten Tools in C# schreiben, aber in reinem C werden Sie es leid sein, verzweigte logische Ketten in einer ernsthaften Anwendung zu beschreiben und zu debuggen.
Dieser Artikel ist also sinnlos.
Das ist immer so. Extreme Standpunkte. Es ist wie ein Streit darüber, was besser ist - ein Hammer oder ein Vorschlaghammer.
Sie werden keine guten Tools in C# schreiben, aber in reinem C werden Sie es leid sein, verzweigte logische Ketten in einer ernsthaften Anwendung zu beschreiben und zu debuggen.
In diesem Artikel geht es also um nichts.
Natürlich ist an dem Artikel etwas Wahres dran... zumindest, dass die Vererbung "ziehen" Methoden und Felder, die nicht wirklich benötigt werden, aber ach, müssen Sie für alles zu zahlen - es spart Zeit, aber es kann Speicherverbrauch oder die Gesamtleistung einer Lösung zu erhöhen, aber fünf nicht alle so traurig, das Niveau der Compiler und Code-Optimierung ist sehr steil jetzt, so dass die Ausgabe oft in eine gute Lösung für eine kurze Entwicklungszeit führt
über C #, gut, als ob der Zweck hat es andere, es ist rein eine "Windows-Sprache", um schnell Ergebnisse auf einem bestimmten PC oder eine begrenzte Gruppe von PCs, auch wenn nicht installiert Updates .Net kann kritische Fehler auf PCs, die keinen Zugang haben, und fangen dies ist recht teuer - schrieb ein Panel für den Handel in C # bereits überprüft es auf einer virtuellen Maschine, wenn nicht alle "Patch" in den Updates installiert, kann das Projekt nicht vorhersehbar bounce ;) Natürlich können Sie versuchen, für die Junior-Version von .Net zu schreiben, aber es gibt ein Problem - alle Nachrichten auf GitHub unter den neuen .Net-Builds gepostet - dh, werden Sie nur auf ihre Entwicklungen beschränkt werden
Im Allgemeinen, wie anderswo - Innovation ist "schmerzhaft und lang und traurig", müssen Sie Trends, die von den IT-Giganten zu folgen, dann ist alles schnell und ohne Probleme geschrieben, gut Microsoft schrieb alles, was sie in OOP-Stil konnte, müssen Sie es alle verwenden oder von Grund auf neu schreiben alle ihre WinForm, usw. Tausende von Tonnen und Terabytes von Code seit Win-95 geschrieben)))
In dem Artikel ist sicherlich ein bisschen Wahrheit enthalten...
Ein wenig? ) Eigentlich ist das einfach so. Allerdings gibt der Autor nicht die Wahrheit preis, es ist eine Art von offensichtlichen Dingen (zumindest für mich). Ich dachte, jeder Programmierer mit Erfahrung kommt zu der gleichen Erkenntnis über die Probleme der Zustandsänderung. Übrigens habe ich kürzlich einen sehr ähnlichen, aber kürzeren Artikel gesehen. Aber vielleicht ist es die ewige Debatte zwischen Funktionalisten und Open-Source-Programmierern )
Aber eigentlich hindert Sie niemand daran, OOP richtig anzuwenden. Sogar der Autor erwähnt, dass Sie unveränderliche Objekte verwenden können. Und 99% der beschriebenen Probleme verschwinden sofort. Es hängt also alles nur von der Frage der geraden Hände und des Kopfes auf den Schultern ab, nicht vom verwendeten Paradigma.
Obwohl natürlich die Tatsache, dass gängige OOP-Sprachen keine Möglichkeit bieten, die Variabilität von Objekten zu kontrollieren, den Prozess erschwert. Es wäre also wirklich cool, das Schlüsselwortimmutable anstelle von const/readonly zu haben.
Was die Gründe für die Unpopularität funktionaler Sprachen angeht, so stimme ich dem Autor hier nicht zu. Zunächst einmal ist die Wahrnehmung eines solchen Codes komplizierter, wie mir scheint. Es handelt sich nicht nur um einen Gegensatz zwischen OOP und FP, sondern um einen Gegensatz zwischen imperativen und funktionalen Ansätzen. Ersterer ist meiner Meinung nach für die meisten Menschen näher und intuitiver zu verstehen. Ich kenne funktionale Sprachen nur durch Korrespondenz, daher kann ich sie nicht objektiv beurteilen, aber wenn ich zum Beispiel Code sehe, der mit Lambdas überladen ist, löst das kognitive Dissonanzen aus) Es ist zu kompliziert und umständlich. Und wahrscheinlich denken die meisten Leute auch so )
Außerdem sind funktionale Sprachen für eine Reihe von Aufgaben, die mit der Interaktion mit der äußeren Umgebung verbunden sind, nicht geeignet, z. B. für die grafische Benutzeroberfläche. Wenn Sie auf die eine oder andere Weise den global geänderten Zustand zwischen Ereignissen speichern müssen.
Ein wenig? ) Das ist tatsächlich genau der Fall. Allerdings ist der Autor nicht offenbaren die Amerikaner, diese Dinge sind irgendwie offensichtlich (zumindest für mich). Ich dachte, jeder Programmierer mit Erfahrung kommt zu der gleichen Erkenntnis der Probleme eines veränderlichen Zustand. Übrigens habe ich kürzlich einen sehr ähnlichen, aber kürzeren Artikel gesehen. Nun, vielleicht ist es die ewige Debatte zwischen Funktionalisten und Open-Source-Programmierern )
Aber eigentlich hindert Sie niemand daran, OOP richtig anzuwenden. Sogar der Autor erwähnt, dass Sie unveränderliche Objekte verwenden können. Und 99% der beschriebenen Probleme verschwinden sofort. Es hängt also alles nur von der Frage der geraden Hände und des Kopfes auf den Schultern ab, aber nicht vom verwendeten Paradigma.
Obwohl natürlich die Tatsache, dass gängige OOP-Sprachen keine Möglichkeit bieten, die Variabilität von Objekten zu kontrollieren, den Prozess erschwert. Es wäre cool, das Schlüsselwort immutable anstelle von const/readonly zu haben.
Auf jeden Fall wird sich in naher Zukunft nichts ändern, IT-Giganten unterstützen dieses Paradigma, es kann vorteilhaft sein, Softwareentwickler zu zwingen, komplexe Implementierungen zu machen, die leistungsfähigere Hardware benötigen, um zu funktionieren, sowie ihre Dokumentation für Betriebssysteme oder Compiler mit vorgefertigten Bibliotheken in Form von OOP zu präsentieren, was Entwickler zwingt .... und so weiter bis ins Unendliche ;)
Wir können diese OOP-Geschichte als obligatorische Lateinkenntnisse für Mediziner betrachten - es war nicht notwendig, aber als Mittel der Kommunikation auf professioneller Ebene war es notwendig, es zu benutzen ;)