Parlare dell'OLP nel salone - pagina 20

 
fxsaber:

L'articolo mente!

Non ho letto il resto dell'articolo. Molto probabilmente l'assurdità dell'autore è stata subito segnalata nei commenti.

Continuate a leggere, è tutto a posto.

 
fxsaber:

Nella codifica procedurale, è quasi sempre possibile personalizzare l'architettura di un programma mentre lo si scrive. Perché la flessibilità e la libertà sono complete

+

Si può dimenticare l'OOP solo per il gusto di farlo, specialmente per algoritmi computazionali, come nel trading...

 

Sui miti dell'OLP - non per i deboli di cuore aderenti all'OLP.

"Ci sono stati diversi miti sull'OOP dalla metà degli anni '80. Uno di questi, il Mito del Riutilizzo, dice che l'OOP rende lo sviluppo più produttivo perché permette di ereditare ed estendere il codice corrente invece di doverlo scrivere tutto da capo. L'altro è il Mito del Design, che implica che l'analisi, il design e l'implementazione si susseguono senza problemi, perché sono tutti oggetti. Naturalmente, nessuno di questi miti può essere il paradigma OOP".

Десять вещей, которые я терпеть не могу в ООП
Десять вещей, которые я терпеть не могу в ООП
  • 2015.02.13
  • habrahabr.ru
Боже, временами я просто ненавижу объектно-ориентированное программирование. Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят: «Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.” Обычно я не жалуюсь, но сейчас, думаю, самое время оглянуться назад и...
 

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 perdita, 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 mortale. 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 future. 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 si cerca di 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.
 

Forum sul trading, sistemi di trading automatico e test di strategia

Parlando dell'OLP

Renat Fatkhullin, 2018.01.17 09:17

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

Questa spazzatura fatta di frasi è in circolazione da molto tempo e ignora completamente la crescita esponenziale della complessità del 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 si troveranno 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 mortale. 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 future. 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. questo è un business in cui i professori non hanno affari.
  5. Non c'è via d'uscita - solo dolore e sofferenza

Il miglior post del mese, o forse dell'anno! Renat, perché tu o la tua azienda non scrivete articoli su hubra(l'azienda non è nemmeno registrata lì!)? Hai così tanto da dire, ma la tua esperienza si apprende solo a frammenti dai tuoi post. Davvero, molto attuale e preciso. Per illustrare il tuo post:https://habrahabr.ru/post/344356/

Почему дизайн Go плох для умных программистов
Почему дизайн Go плох для умных программистов
  • 2010.12.17
  • habrahabr.ru
На протяжении последних месяцев я использую Go для имплементаций Proof of Concept (прим.пер.: код для проверки работоспособности идеи) в свободное время, отчасти для изучения самого языка программирования. Программы сами по себе очень просты и не являются целью написания статьи, но сам опыт использования Go заслуживает того, чтобы сказать о нем...
 
Vasiliy Sokolov:

Il miglior post del mese, forse dell'anno!

Cosa ti è piaciuto tanto di questo post nel contesto dell'argomento OOP? Probabilmente non è giusto generalizzare anche sulle cose commerciali, gli investitori non sono stupidi e coinvolgono i loro esperti per valutare il rischio dei progetti...

Questo articolo di alcuni, ma ancora un professore ha argomenti logici specifici ai quali non sono state presentate adeguate controargomentazioni per la discussione...

È anche chiaro che il semplice pogramming non è sempre un male per i progetti...

 
Vasiliy Sokolov:

Il miglior post del mese, forse dell'anno! Renat, perché tu o la tua azienda non scrivete articoli su hubra(l'azienda non è nemmeno registrata lì!)? Hai così tanto da dire, ma la tua esperienza si apprende solo a frammenti dai tuoi post. Davvero, molto attuale e preciso. Come illustrazione al post:https://habrahabr.ru/post/344356/

Noi lavoriamo per milioni, non per i 1.000 - 5.000 lettori/viste che gli articoli su Habra ottengono di solito.

Abbiamo fatto uno standard industriale e stiamo rilasciando soluzioni che hanno un impatto sul mondo. Perché abbiamo bisogno di una specie di Habr, e ancora di più, stipato in una nicchia ristretta del segmento russo.

 
Andrei:

Cosa ti è piaciuto tanto di questo post nel contesto dell'argomento OOP? Probabilmente non è giusto generalizzare anche sulle cose commerciali, gli investitori non sono stupidi e coinvolgono i loro esperti per valutare il rischio dei progetti...

Ci sono argomenti logici specifici in questo articolo da parte di alcuni, ma ancora un professore, ai quali non sono stati presentati adeguati contro-argomenti per la discussione...

È anche ovvio che il semplice pogramming non è sempre un male per i progetti...

Basta con le battute dilettantistiche, per favore.

Sarete semplicemente bannati per essere tecnicamente analfabeti. Non abbiamo bisogno di ignoranti bellicosi nel nostro forum.

 
Andrei:

...

È anche ovvio che la semplicità di programmazione non è sempre un male per i progetti...

C'è un assioma: la complessità non va da nessuna parte. Di conseguenza, la "semplicità di programmazione" per l'utente è un trasferimento di complessità al compilatore. La complessità è come elaborata dal compilatore dietro le quinte e lui, il compilatore, cerca di nascondere qualsiasi perversione del programmatore secondo il principio "meglio farlo funzionare in qualche modo che niente". Il compilatore, non il programmatore, diventa il proprietario del progetto. Lo sviluppo e la manutenzione del codice diventano impossibili, perché non si capisce cosa sta succedendo (il compilatore lo costruisce in qualche modo, ma non importa).

Forum sul trading, sistemi di trading automatico e test di strategia

Parlare di OOP

Renat Fatkhullin, 2018.01.17 09:17

...

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 si troveranno in svantaggio semplicemente credendo nella tecnologia sbagliata e perdendo la gara competitiva. È solo che i loro concorrenti useranno una tecnologia più pesante, ma più efficace in termini di risultati del prodotto

...


 
Renat Fatkhullin:

Basta con le battute dilettantistiche, per favore.

Sarete semplicemente bannati per essere tecnicamente analfabeti. Non abbiamo bisogno di ignoranti militanti nel nostro forum.

Ignoranti militanti - che precisione e concisione. Aggiungo al mio vocabolario. :))