Interessante presa di posizione sull'OLP - pagina 2
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
Che reazione distruttiva all'argomento e che discussione distruttiva. Mi dica un seguace della programmazione procedurale come evitare la "spaghettizzazione" in OOP, come analizzare e se ha senso usare gli "spaghetti" di qualcun altro?
Dopo tutto, quello che si scopre, OOP è soprattutto per la leggibilità e la programmazione di gruppo, cioè per i grandi progetti. Un Expert Advisor che commercia un simbolo al suo grafico con il controllo del rischio massimo del saldo / fondi nel conto, beh, non può essere chiamato un grande progetto - è sufficiente e più redditizio in memoria / velocità - programmazione procedurale.
Domande:
- svantaggi/svantaggi di OOP (come imperativo) per esperienza personale
- svantaggi/svantaggi della FP (in quanto dichiarativa) per esperienza personale.
E un'opinione sulle prospettive è ovviamente interessante, soprattutto nella direzione del calcolo parallelo. Non vedo il motivo di toccare l'argomento quantistico.
Ho bisogno di vedere da dove viene, non capisco affatto cosa sia lo spargeting.
Una buona caratteristica di qualsiasi codice è quella di avere funzioni il più brevi possibile. È meglio che tu ne abbia di più.
Per esempio, la metà delle proprietà OOP sono cose che vorremmo separare per l'usabilità - per esempio, separare un certo numero di funzioni in un gruppo e dare loro le proprie variabili che vivrebbero nel loro namespace).
Dato che stiamo lavorando con un tipo di memorizzazione "classe", possiamo chiaramente predefinire tutte le variabili per dare loro un certo tipo....
è conveniente creare API esterne. Si può lavorare con il riferimento di classe (8 byte) quando si lavora - usato molto spesso.
Esempio: Tutti i tipi di liste di nodi collegati e altre cose.
// qui ho scritto solo le particolarità che vedo, è chiaro che non ha senso scrivere di possibilità e proprietà di metodi protetti e altre cose.... è solo zucchero.
Proprietà di FP è ciò che vorremmo fare da qualche parte, dopo qualcosa, per esempio, vorremmo comporre una nuova funzione al volo nella funzione - dividere la funzione corrente, che userebbe alcune delle variabili correnti della nostra funzione. Per passare la sua esecuzione a un'altra funzione - si scopre che passiamo solo la funzione ritardata, il calcolo che non è ancora avvenuto - proprio come un pezzo di codice....
In effetti, questo è abbastanza conveniente.
Questo lascia la proprietà dello srotolamento completo del codice, perché in effetti sappiamo chiaramente che funzione abbiamo - il che è probabile che sia più veloce nel calcolo rispetto all'OOP. È possibile organizzare trasferimenti piuttosto intelligenti di calcoli da una funzione all'altra - inoltre la funzione ricorda completamente l'ambiente delle variabili chiamate della funzione passata - il che è molto bello (anche se in realtà è solo il salvataggio delle variabili dichiarate dall'ambito esterno). FP, d'altra parte, si può impostare l'indirizzo di una funzione e memorizzarlo in un array come una classe - anche se non particolarmente utile.
Facile scrivere codice per azioni ritardate, tutti i tipi di funzioni asincrone, calcoli paralleli
Lasciatemi spiegare le mie preoccupazioni basate sull'articolo citato e sul concetto stesso di determinismo. Cosa mi spaventa della "spaghettificazione" (la complessità del codice stesso e il compito di trovare gli errori di calcolo)? Beh, è su questo che si concentra l'articolo - valori "spazzatura" nelle variabili o ritorni non deterministici dalle funzioni.
Costruisco/addestro reti neurali della mia struttura di variabili (evolvere). E per loro è molto critico che la "spazzatura" nei valori venga fuori dal nulla.
Come nell'articolo - tu premi il pedale del freno, e il pedale se ne frega di te. Questo è in uso. E se nella fase iniziale della costruzione (selezione automatica dell'architettura) e dell'addestramento della vostra rete neurale "spazzatura" è possibile - come viene costruita/addestrata?
Come evitare il più possibile la "spazzatura" (nondeterminismo) in OOP?
Lasciatemi spiegare le mie preoccupazioni basate sull'articolo citato e sul concetto stesso di determinismo. Cosa mi spaventa della "spaghettificazione" (la complessità del codice stesso e il compito di trovare gli errori di calcolo)? Beh, è su questo che si concentra l'articolo - valori "spazzatura" nelle variabili o ritorni non deterministici dalle funzioni.
Costruisco/addestro reti neurali della mia struttura di variabili (evolvere). E per loro è molto critico che la "spazzatura" nei valori venga fuori dal nulla.
Come nell'articolo - tu premi il pedale del freno, e il pedale se ne frega di te. Questo è in uso. E se nella fase iniziale della costruzione (selezione automatica dell'architettura) e dell'addestramento della vostra rete neurale "spazzatura" è possibile - come viene costruita/addestrata?
Come evitare il più possibile la "spazzatura" (nondeterminismo) in OOP?
L'articolo in generale è un po' strano, l'uomo ha chiaramente dimenticato di specificare il tipo di variabile const, come se avesse js allora almeno readonly. Dopo di che scrive che presumibilmente ha avuto un errore quando l'oggetto che non deve cambiare la dimensione (essere una costante) non è in qualche modo una costante ..... e in base a questo fa conclusioni che c'è molta probabilità di un errore in OOP))
In generale, l'OOP permette di controllare le aree delle variabili. L'OOP è concepita come un trasferimento di variabili da una funzione, cioè dovremmo già avere un tipo predefinito perché molto probabilmente ce ne sono pochi. E se necessario, questa stessa funzione può essere ampliata al volo.
Cioè in OOP c'è più controllo iniziale
Ecco, l'ho sempre sospettato)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Non so chi scrive questi "articoli", parole vuote, frasi generiche, senso minimo.
" Il codice nel suo insieme era confuso e disordinato - quello che in gergo si chiama "spaghetti "" - a causa di cattivi programmatori allaToyota considereremo che inOOP il codice è confuso.
" Le caratteristiche OOP integrate aggiungono solo confusione. " - beh, la logica, la capacità di usare le caratteristiche aggiunge confusione al codice, con un aumento costante del numero di caratteristiche OOP (C#) sarà impossibile scrivere ancora codice semplice. Sì.
"Nella maggior parte dei linguaggi orientati agli oggetti, i dati sono passati per riferimento, cioè diverse parti del programma possono trattare la stessa struttura di dati - e cambiarla. Questo trasforma il programma in un grande grumo di stato globale e contraddice l'idea originale di OOP " - Eprivato,protetto?
"...Se non vi piace questa citazione, è perché il nondeterminismo in generale non vi porta da nessuna parte. "Beh, sì, le funzioni imprevedibili GetMicrosecondCount, MathRand, CoptBuffer, tutte le funzioni di rete e altre dovrebbero essere buttate via perché il risultato lì dipende dallo stato esterno. È orribile.
Ok, basta, qui è tutto chiaro.
Ecco, sempre sospettato)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23La maggior parte degli argomenti lì vengono succhiati dalle dita. Alcuni esperimenti che "provano" l'invalidità dell'OOP non sono affatto corretti. Nei normali linguaggi OOP la somma (int a, int b) sarà sempre pulita, anche se scrivete internamente delle sciocchezze come a += b. Di nuovo, se un oggetto è allocato sull'heap all'interno di un metodo, è sempre protetto, perché solo il metodo che lo ha chiamato ha un riferimento ad esso. Si può cambiare a piacimento. Ci sono tipi di riferimento e tipi significativi. Nessuno vi impedisce di scrivere funzioni pulite senza effetti collaterali nei linguaggi OOP. Le funzioni matematiche standard sono così, per esempio. Sì, a volte non si può fare a meno delle risorse condivise, ma ci sono comode collezioni thread-safe e molto altro. Dopo tutto, qualsiasi FP puro interagirà inevitabilmente con IO, BD, richieste di rete e molte altre cose, che è dove i demoni di modificabilità faranno breccia.
Articolo strano....
La quantità tende a trasformarsi in qualità.
Quando ci sono molte radio, ci può essere incompatibilità elettromagnetica e smettono di funzionare.
Le proprietà spaghetti del codice è di solito dalla quantità e non tenendo conto di tutte le proprietà del wrapper quando ci sono molti usi in diversi stati.
Nelle funzioni la presenza di feedbacks porterà alla stessa cosa. L'isteresi è uno scherzo)
Capire i problemi, e farli bene ... ))))
// Ho descritto solo le caratteristiche che posso vedere qui, ovviamente non ha senso scrivere delle possibilità e proprietà dei metodi protetti e altre cose.... è solo zucchero.
Proprietà di FP è ciò che vorremmo fare da qualche parte, dopo qualcosa, per esempio, vorremmo comporre una nuova funzione al volo in una funzione - condividendo quella attuale, che userebbe alcune delle variabili attuali della nostra funzione. Per passare la sua esecuzione a un'altra funzione - si scopre che passiamo solo la funzione ritardata, il calcolo che non è ancora avvenuto - proprio come un pezzo di codice....
In effetti, è abbastanza conveniente.
Bene, chi impedisce di fare lo stesso in OOP? Anche in un linguaggio puramente procedurale? Si passa un puntatore a una funzione a un'altra funzione e si ottiene un'esecuzione ritardata.
In generale, l'asincronia è un puro design pattern. È possibile scrivere codice asincrono anche in C puro. Basta fare una macchina a stati che esegue il compito in parti. A proposito, l'ho fatto con indicatori in MQL che hanno richiesto molto tempo per essere calcolati. L'ho fatto per evitare di rallentare il grafico e visualizzare una bella status-bar che cambia la sua percentuale di realizzazione.
Bene, chi vi impedisce di fare lo stesso in OOP? Anche in un linguaggio puramente procedurale? Si passa un puntatore a una funzione a un'altra funzione e si ottiene un'esecuzione ritardata.
In generale, l'asincronia è un puro design pattern. Si può scrivere codice asincrono anche in C puro. Basta fare una macchina a stati che esegue il compito in parti. A proposito, l'ho fatto con indicatori in MQL che hanno richiesto molto tempo per essere calcolati. Mi aiuta a non rallentare il grafico e a visualizzare una bella status-bar che cambia la sua percentuale di implementazione.
) Potete anche usare l'assemblatore. La questione è dove è più facile.
E non mettetemi in un lato o nell'altro .... Non sono un fanatico di una cosa o dell'altra.
Strano articolo. OOP non differisce dallo stile procedurale in peggio, perché in esso si può fare tutto in stile procedurale di default, e viceversa senza terribile bloat di codice, cioè OOP è una "sovrastruttura sopra", non uno stile fondamentalmente diverso.
Se l'articolo riguarda davvero il funzionale piuttosto che il procedurale (il che non è così ovvio se ci si sofferma), allora perché confrontare cose che hanno usi completamente diversi.
Topeka starter, sei tu stesso a scrivere e ora parli di quale? funzionale o procedurale?
Dopotutto, quello che si scopre è che l'OOP è soprattutto per la leggibilità e la programmazione di gruppo, cioè per i grandi progetti.
Non so come usare OOP. Ma ne uso cose primitive. Dal recente passato, ha postato del codice molto semplice.
Ho iniziato a scriverlo in FP, quando ancora non capivo cosa avrei dovuto guardare alla fine.
Finito attraverso elementi primitivi OOP. Probabilmente ho perso le capacità di FP, ma qui OOP sembrava molto più semplice e più leggibile.
Il codice è molto semplice e breve(descrizione). Se lo scrivi in FP, sarebbe interessante confrontarlo.