Parlare dell'OLP nel salone - pagina 21

 
Nikolai Semko:
Ignoranti militanti - che precisione e concisione. Aggiungo al mio vocabolario. :))
Si scopre che questo termine era usato dalla mia amata Elena Ivanovna e Konstantin Nikolaevich Roerich.
Niente cambia in questo mondo...
 
Andrei:

No, il punto è diverso. C'è una banana che si deve mangiare secondo la logica del programma, ma si deve mangiare la palma e la terra nera con il letame insieme ad essa.

Beh, no.

Non si vede una palma, la terra nera, il fertilizzante o una scimmia, è tutto incapsulato e non vi si può accedere.

Ecco di cosa sto parlando! È solo nell'approccio funzionale - devi trascinare tutto ESTREMAMENTE dietro di te per ottenere una banana. Nell'approccio OOP, il compilatore lo trascinerà per voi. Tu - ricevi la "banana" attraverso un'interfaccia concordata, e non sai da dove viene. Puoi scoprirlo se hai un accesso adeguato.

Questo è il punto di OOP - solo ciò di cui avete bisogno, in questo caso la banana, dovrebbe essere disponibile per voi. Non ci sono noccioline di palma-fertilizzanti a tua disposizione. Esistono (altrimenti, da dove verrebbe la banana), ma tu non ne hai accesso, e con tutta la tua volontà non potrai abbattere una palma o uccidere la scimmia stessa che ti sta strappando la banana.

 
Andrei:

Ciò che è tormento per le persone normali è gioia per i masochisti... :)

È un tormento per le persone normali limitarsi a usare un coltello? È un tormento per le persone normali limitarsi alle regole della strada?
 
Penso che gli autori dei due articoli citati siano persone profondamente infelici che hanno passato la loro vita facendo la cosa sbagliata. Questo, purtroppo, è spesso il caso. Avrebbero dovuto essere scrittori, non programmatori. Ovviamente, hanno espresso la loro antipatia per il lavoro che non gli piaceva attaccando l'OOP. Immagino che uno possa capirli in modo puramente umano :)) Dopo tutto, il paradigma OOP può essere veramente compreso solo da veri programmatori che sono innamorati del loro mestiere.
 

Potreste immaginare che l'OLP sia la vostra casa, con le sue regole. Ci sono cose che sono comuni a tutti. Si tratta di sedie da tavola, forchette, cucchiai, ecc. Ma ci sono cose che non sono nemmeno disponibili per i residenti di questa casa. Per esempio oggetti personali, una cassaforte, ecc.

Il proprietario della cassaforte può dare accesso alla cassaforte. Gli estranei non hanno il diritto di entrare in questa casa senza permesso.

Si può usare una classe per descrivere questa casa, quello che c'è dentro con certe funzioni di ciascuno. E la casa stessa è un oggetto.

OOP è come la nostra vita. Ha l'aspetto di una persona e consiste di due parti: l'anima, che la descrive e la controlla, e il corpo fisico, che è un oggetto.

OOP è una disciplina, non un'anarchia - chi fa quello che vuole.

 
Nikolai Semko:
Dopo tutto, il paradigma OOP può essere veramente compreso solo da veri programmatori che sono innamorati del loro mestiere.

Non necessariamente.

Renat nella pagina precedente - giustamente ha notato che "mettetelo a fare un vero progetto" - lo farà fallire. E si convincerà rapidamente di tutti i vantaggi dell'OOP, che più che compensano tutti gli svantaggi. Scommetto che nessuno di quelli che criticano l'OOP qui ha partecipato alla scrittura di un solo progetto, anche piccolo e complesso. Il che spiega la loro opinione.

Come "l'auto richiede un sacco di risorse in testa, e non puoi allontanarti da loro, devi portare quel mucchio di ferraglia in giro tutto il tempo, il che significa che è molto più corretto camminare". E in effetti, è abbastanza sciocco andare nella strada successiva. Tuttavia, se si deve andare in un'altra città - pochissime persone parlano seriamente di "camminare".

E così è qui.

 
George Merts:

Non necessariamente.

Renat nella pagina precedente - giustamente ha notato che "mettetelo a fare un vero progetto" - lo farà fallire. E si convincerà rapidamente di tutti i vantaggi dell'OOP, che più che compensano tutti gli svantaggi. Scommetto che nessuno di quelli che criticano l'OOP qui ha partecipato alla scrittura di un solo progetto, anche piccolo e complesso. Il che spiega la loro opinione.

Come "l'auto richiede un sacco di risorse in testa, e non puoi allontanarti da loro, devi portare quel mucchio di ferraglia in giro tutto il tempo, il che significa che è molto più corretto camminare". E in effetti, è abbastanza sciocco andare nella strada successiva. Tuttavia, se si deve andare in un'altra città - pochissime persone parlano seriamente di "camminare".

E così è qui.

Questo è quello che voglio dire...
 
Renat Fatkhullin:

Ora per microprogetti fino a centomila linee. Questo permette di creare qualsiasi cosa, poiché ha la possibilità di entrare nella testa di una persona e mantenere l'illusione del controllo. Quando si cerca di scalare - dolore, frustrazione e morte.

Faccio fatica a immaginare anche un progetto di 10K linee senza OOP. Probabilmente ce ne sono pochissimi.

 
Renat Fatkhullin:

Lo zio è un teorico e un chiacchierone, come molti nel mondo accademico. E non importa che sia un professore (il titolo è stato a lungo inflazionato) e autore di libri.

Questa spazzatura da frasi è in giro da molto tempo e ignora completamente la crescita esponenziale della complessità dei prodotti software. Ciò che era 30-20-10 anni fa non è in alcun modo paragonabile alla scala e alla complessità dei progetti attuali. E preferiscono ancora giocare nella sandbox, riducendo il tutto a dei modelli.

Fatelo sedere per fare un prodotto reale, che ha un sacco di requisiti, compresi quelli di risorse, economici e competitivi. Si scatenerà all'istante con il suo ragionamento, fallendo in tutti i modi possibili. È più probabile che venga addirittura cacciato per capitaneria infantile nella fase di progettazione della soluzione.

Il mondo ha provato molte pallottole d'argento, ma tutte si sono dimostrate inutili e sono state cancellate da tempo. Questo lascia una crescita costante della complessità, una crescita delle librerie (e c'è un oop) e dei frameshot (e c'è un oop), che permettono almeno un certo controllo sulla complessità.

E non c'è modo di sfuggire alla crescente complessità. Ci sarà ancora più complessità, ci saranno più sviluppatori analfabeti incapaci di stare al passo con i requisiti di qualità della conoscenza.

Ci saranno più tentativi di inventare linguaggi ancora più semplici per soddisfare il livello di massa sempre più basso dei programmatori. Sempre più aziende di software saranno in svantaggio, semplicemente credendo nella tecnologia sbagliata e perdendo la gara competitiva. È solo che i loro concorrenti useranno una tecnologia più pesante, ma efficace in termini di risultati del prodotto.

Investire in aziende di software è stato a lungo una cosa letale. I tassi di mortalità e di fallimento sono sconcertanti, e da qui in poi sarà sempre peggio.

Perché? Sì perché si tratta di un business con masse di richieste economiche, non di tecnologia. Circa l'80% di un'azienda di software viva e in piedi consiste nel marketing e nelle vendite. La tecnologia sbagliata (e qui la maggior parte delle persone dà la priorità alla presunta semplicità) uccide facilmente le vendite successive. Perché ci sono sempre concorrenti che hanno preso una strada più difficile e hanno ottenuto risultati migliori alla fine.

Ora sui microprogetti fino a centomila linee. Questo permette di creare qualsiasi cosa, poiché ha la possibilità di entrare nella testa di una persona e mantenere l'illusione del controllo. Se provi a scalare - dolore, frustrazione e morte.

Conclusioni:

  1. la complessità dei progetti sta crescendo e continuerà a crescere
  2. Molte nuove idee e approcci moriranno senza produrre risultati.
  3. la maggior parte del software è e sarà scritta in open source, duramente e con sforzo
  4. gli investimenti in start-up di software mostreranno tassi di fallimento crescenti.
  5. non c'è via d'uscita, solo dolore e sofferenza.

Tutto questo è buono e bello solo a parole....

Per creare progetti grandi e interessanti usando OOP è necessario sapere come farlo.

1 - Quelli che sanno come fare non vanno qui a µl, il linguaggio è limitato a un paio di piattaforme, e sono professionisti (già con progetti in altre lingue) già in attività...

2 - E quelli che non sanno come fare, torceranno OOP e altri come scimmie e non faranno nascere niente...

Sì, certo, ci sono alcuni appassionati dei mercati finanziari, ma troppo pochi per fare qualcosa di serio e farsi una vita... L'interesse principale è...

Quello che voglio dire, Renat, è che mt 5 avrà presto 10 anni, 10 anni non sono uno scherzo...

E non c'è una formazione adeguata nella programmazione OOP...

Qual è l'argomento di cui ho scritto? Riguardo all'OOP e a cosa si è arrivati? Nella spazzatura...

La mia domanda a te Renat, come o dove dovrebbero apparire le persone che programmano grandi progetti in µl?

 
Vladimir Pastushak:

come o dove dovrebbero arrivare le persone che programmano grandi progetti in µl?

Non ci sono mai stati e mai ci saranno grandi progetti nell'algotrading all'interno di un singolo piano di trading, indipendentemente dalla lingua e dalla piattaforma.

Al massimo, ci sono progetti semi-automatici.

Anche un solo grande progetto come semi-automatico in qualsiasi lingua? Le unità Scalper sono le più difficili. Ma non hanno mai avuto un appeal di massa. E se non c'è massa, perché preoccuparsi di qualcosa di grande? È più facile costruire qualcosa per il Mercato su un ginocchio.