Scrivere codice in russo. Pro e contro di un tale programma. - pagina 3
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
1. Quanti anni hai programmato?
2. Hai mai provato (da solo) a scrivere un programma in russo?
La domanda è: lo stereotipo esiste e non ne siamo ostaggio?
È una questione di atteggiamento. Preferisco scrivere in inglese perché è più comodo per me in ogni senso. Supponente, conciso, confuso, comunicativo.
Direi addirittura che la vostra riluttanza a scrivere in inglese è uno stereotipo, alimentato da una mancanza di volontà di imparare l'inglese correttamente.
Se le variabili esterne sono in russo, si potrebbe incorrere in ?????? quando non ci sono font sul sistema, per esempio sul server.
1C - sì, il russo è in qualche modo più familiare lì. Ma in altre lingue solo l'inglese (una volta alla fine degli anni '90 ho provato Visual Basic in "lingua russa", da allora mi sono curato).
Beh, si può scrivere in russo anche in OOP.
Qual è l'essenza del cutoff per rifiutare l'OOP?
L'essenza dell'OOP è che il programmatore può impostare lo scopo delle variabili. Se si ignora questo, cosa si guadagna?
Dovete costantemente usare nuovi contatori e nuove variabili, perché non avete più il controllo dell'ambito.
I nomi devono essere scritti più a lungo con suffissi e prefissi.
Si perde la capacità di riutilizzare il codice (uno dei pilastri della OOP).
Questo non è tutto, naturalmente, ma in breve.
Quale approccio preferite?
E a proposito, se state sviluppando un programma piuttosto che digitare semplicemente del testo, la capacità di trasformare è importante. Con OOP, devi riscrivere solo una bibbia. Con altri approcci, è necessario modificare l'intero programma.
Si può anche scrivere in russo usando OOP. Sono d'accordo. Tuttavia, ho le mie pretese riguardo all'OOP. La pretesa efficacia di questo metodo è stata completamente smentita nella mia pratica e ho rifiutato questo approccio come inefficace. Davvero, l'OOP permette di "umanizzare" un linguaggio di programma ma lo riempie di entità inutili di cui la macchina non ha affatto bisogno. Si scopre anche di più - queste entità non sono veramente necessarie per un umano e si può fare a meno di loro. Sta parlando dell'ambito delle variabili? Organizza le tue variabili in un array globale tridimensionale. Chiamate ogni campo di questa matrice una classe, e ogni riga di campi, diciamo un'enumerazione. Localizzare il valore di ogni variabile sarebbe molto facile, così come accedervi...
Dobbiamo pensare alla trasformazione... C'è l'idea di fare un motore software universale, che lavorerà con un nucleo logico. Le catene logiche saranno prescritte nel kernel. Il motore userà il kernel per accedere alle funzioni tramite i loro indici. Questo sarà molto facile da trasformare.
Guarda il C++ avanzato. Sembra che questo linguaggio di programmazione abbia già acquisito un proprio slang... Probabilmente non c'è nessun'altra lingua che abbia una tale accozzaglia di entità. Se fai qualche ricerca e lasci solo l'essenziale, si ridurrà di parecchie volte. Di conseguenza, diventerebbe più comprensibile e accessibile alla maggior parte delle persone. Tuttavia, ho la sensazione che qualcuno non voglia che questo linguaggio diventi comprensibile e accessibile a tutti e quindi lo complica immensamente...
Molte caratteristiche sono stratificate in C++. È ancora il principale linguaggio di sistema e per poter scrivere tutto ciò che si vuole, varie caratteristiche sono conservate in esso.
Da ACMe a OpenCL e alla gestione dei thread.
Se volete un OOP puro, benvenuti in C#.
L'iniziatore dell'argomento probabilmente non ha compreso appieno i vantaggi di OOP rispetto al metodo di programmazione procedurale adottato in precedenza. Prima del metodo procedurale, i programmi venivano scritti usando operatori di salto incondizionato. E i programmi scritti in questo modo erano molto difficili da debuggare e da tracciare la logica del loro lavoro, erano persino chiamati "piatto di spaghetti".
Il principio del mio approccio è il seguente:
1. indicizziamo le chiamate alle funzioni software. Dividiamo le funzioni stesse in quelle che controllano gli eventi (funzioni logiche, - restituiscono sì/no), funzioni procedurali (funzioni esecutive), e funzioni computazionali.
2. Crea il nucleo logico sotto forma di un array globale tridimensionale. Vi prescriviamo gli indici delle funzioni logiche in una certa gerarchia (divisione per l'importanza degli eventi che controllano: eventi globali e locali). Creiamo una sorta di perimetro di questi eventi nel campo del kernel.
3. Indicizziamo le funzioni procedurali e computazionali alle estremità delle catene logiche.
4. Creare un motore logico che gira intorno agli eventi perimetrali nel kernel alla frequenza del timer e chiama le funzioni richieste tramite i loro indici.
5. Ricostruire il programma consisterà solo nel ricostruire specifiche catene logiche o nel costruirne di nuove.
11 a parte l'università.
Naturalmente.
Una questione di atteggiamento. Preferisco scrivere in inglese perché è più conveniente per me in ogni senso. Sostegno, brevità, ricerca delle incomprensioni, comunità.
Direi addirittura che la vostra riluttanza a scrivere in inglese è uno stereotipo, alimentato da una mancanza di volontà di imparare l'inglese correttamente.
Ho letto Dostoevskij in inglese. Non è affatto questo il punto... Il russo è più facile da programmare a livello genetico per me.
Nessun problema, il 47° cromosoma è il potere.
OOP è stato creato dalle persone più intelligenti, i professori. Hanno passato anni a metterlo a punto e a modificarlo per soddisfare le esigenze dei programmatori in modo che fosse più conveniente per scrivere programmi.
L'OOP di MQ è anche raffinato in termini di sicurezza del codice.
Vuoi diventare un profeta della nuova religione? Nessun problema, è il tuo momento dopo tutto.