Domande su OOP in MQL5 - pagina 25
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ci sono statistiche dettagliate qui https://githut.info/, ma è l'anno 14.
Statistiche fresche su github https://madnight.github.io/githut/#/pull_requests/2019/2
Penso che tutti trarrebbero beneficio dalla lettura dell'opinione professionale in questo articolo.
Buona fortuna
Penso che tutti trarrebbero beneficio dalla lettura dell'opinione professionale in questo articolo.
tutte le conclusioni (totalmente di parte) dell'articolo sono compensate da una semplice domanda.
FP esiste da molto tempo, perché ha ancora una nicchia così piccola se è così fantastico?
Non voglio dire in nessun modo che OOP sia il miglior concetto o che OP faccia schifo.
tutte le conclusioni (totalmente di parte) dell'articolo sono livellate da una semplice domanda.
La FP esiste da molto tempo, perché ha ancora una nicchia così piccola se è così fantastica?
L'articolo ha la risposta a questa domanda. Non l'hai letto attentamente.
L'articolo ha una risposta a questa domanda.
Totalmente di parte e sul nulla.
Ci sono sviluppatori che scrivono effettivamente il codice. Ci sono manager che potrebbero non saper programmare affatto.
Quindi lo stack tecnologico non è necessariamente scelto dagli sviluppatori. E se un certo stack permette a una squadra di risolvere un problema in modo più efficiente, non è necessario conoscere e possedere la tecnologia per capirlo.
Pensi ancora che l'articolo risponda alla domanda?
Penso che tutti trarrebbero beneficio dalla lettura dell'opinione professionale in questo articolo.
Buona fortuna
Ecco il solito. Punti di vista estremi. È come una discussione su cosa sia meglio: un martello o una mazza.
Non scriverete buoni strumenti in C# ma in C puro vi stancherete di descrivere e debuggare catene logiche ramificate in un'applicazione seria.
Quindi questo articolo non è di alcuna utilità.
È sempre così. Punti di vista estremi. È come una discussione su cosa sia meglio: un martello o una mazza.
Non scriverete buoni strumenti in C# ma in C puro vi stancherete di descrivere e debuggare catene logiche ramificate in un'applicazione seria.
Quindi questo articolo non parla di niente.
C'è, naturalmente, un po' di verità nell'articolo... almeno, che l'ereditarietà "tirerà" metodi e campi che non sono realmente necessari, ma ahimè, si deve pagare per tutto - si risparmia tempo, ma può aumentare l'uso della memoria o le prestazioni complessive di una soluzione, ma cinque non tutti così triste, il livello di compilatori e ottimizzazione del codice è molto ripida ora, quindi l'uscita spesso si traduce in una buona soluzione per un breve tempo di sviluppo
su C#, beh, come se lo scopo che ha altri, è puramente un "linguaggio Windows" per ottenere rapidamente risultati su un particolare PC o un gruppo limitato di PC, anche se non installato aggiornamenti .Net può causare errori critici su PC che non hanno accesso, e prendere questo è abbastanza costoso - ha scritto un pannello per il commercio in C# già controllato su una macchina virtuale, se non installato tutte le "patch" negli aggiornamenti, il progetto non può prevedibilmente volare fuori ;) Naturalmente, puoi provare a scrivere per la versione più giovane di .Net, ma c'è un problema - tutte le notizie su GitHub pubblicate sotto le nuove build di .Net - cioè, sarai limitato solo ai loro sviluppi
In generale, come altrove - l'innovazione è "dolorosa e lunga e triste", bisogna seguire le tendenze stabilite dai giganti dell'IT, poi tutto è scritto velocemente e senza problemi, bene Microsoft ha scritto tutto quello che poteva in stile OOP, bisogna usare tutto o scriverà da zero tutte le loro WinForm, ecc. migliaia di tonnellate e terabyte di codice scritto da Win-95)))
c'è certamente un po' di verità nell'articolo...
Un po'? ) In realtà è così e basta. Tuttavia, l'autore non rivela la verità, si tratta di cose ovvie (almeno per me). Ho pensato che qualsiasi programmatore con esperienza arriva alla stessa realizzazione dei problemi di cambiamento di stato. A proposito, ho visto recentemente un articolo molto simile ma più breve. Ma, forse, è l'eterno dibattito tra funzionalisti e programmatori open source )
Ma in realtà nessuno vi impedisce di usare OOP correttamente. Anche l'autore stesso menziona che si possono usare oggetti immutabili. E il 99% dei problemi descritti spariscono subito. Quindi tutto dipende solo dalla questione delle mani dritte e della testa sulle spalle, non dal paradigma usato.
Anche se, naturalmente, il fatto che i linguaggi OOP popolari non forniscono i mezzi per controllare la variabilità degli oggetti, complica il processo. Quindi, sarebbe davvero bello avere la parola chiaveimmutabile invece di const/readonly.
Per quanto riguarda le ragioni dell'impopolarità dei linguaggi funzionali, non sono d'accordo con l'autore. Prima di tutto, è più complicata la percezione di tale codice, come mi sembra. Questa non è solo un'opposizione di OOP e FP, ma un'opposizione di approcci imperativi e funzionali. Il primo è più vicino e intuitivo per la maggior parte delle persone da capire, a mio parere. Conosco i linguaggi funzionali solo per corrispondenza, quindi non posso giudicarli obiettivamente, ma quando, per esempio, vedo del codice sovraccarico di lambda, mi provoca una dissonanza cognitiva) È troppo complicato e intricato. E probabilmente anche la maggior parte delle persone lo pensa)
E inoltre i linguaggi funzionali non sono pensati per un certo numero di compiti legati all'interazione con l'ambiente esterno. Prendete la GUI per esempio. Quando in un modo o nell'altro è necessario memorizzare lo stato globalmente cambiato tra gli eventi.
Un po'? ) In realtà, è proprio così. Tuttavia, l'autore non sta rivelando le Americhe, queste cose sono piuttosto ovvie (almeno per me). Ho pensato che qualsiasi programmatore con esperienza arriva alla stessa realizzazione dei problemi di uno stato variabile. A proposito, ho visto recentemente un articolo molto simile ma più breve. Ma, forse, è l'eterno dibattito tra funzionalisti e programmatori open source )
Ma in realtà nessuno ti impedisce di usare OOP correttamente. Anche l'autore menziona che puoi usare oggetti immutabili. E il 99% dei problemi descritti sparisce immediatamente. Quindi tutto dipende solo dalla questione delle mani dritte e della testa sulle spalle, ma non dal paradigma usato.
Anche se, naturalmente, il fatto che i linguaggi OOP popolari non forniscono un mezzo per controllare la variabilità degli oggetti, complica il processo. Sarebbe bello avere la parola chiave immutabile invece di const/readonly.
In ogni caso non cambierà nulla nel prossimo futuro, i giganti dell'IT sostengono questo paradigma, può essere vantaggioso costringere gli sviluppatori di software a fare implementazioni complesse che richiederanno un hardware più potente per funzionare, così come presentare la loro documentazione per OS o compilatori con librerie pronte in forma di OOP, che costringe gli sviluppatori .... e così via all'infinito ;)
Possiamo considerare questa storia OOP come una conoscenza obbligatoria del latino da parte dei medici - non era necessario, ma come mezzo di comunicazione a livello professionale era necessario da usare ;)