Quali problemi possono sorgere dall'emulazione di concetti da altre lingue?

12

Ho letto molte volte sul web che se la tua lingua non supporta alcuni concetti, ad esempio l'orientamento agli oggetti o forse le chiamate di funzioni, ed è considerata una buona pratica in questo altro contesto, dovresti farlo.

L'unico problema che posso vedere ora è che altri programmatori potrebbero trovare il tuo codice troppo diverso dal solito, rendendo difficile la programmazione. Quali altri problemi pensi possano derivare da questo?

programming-languages concepts idioms

— Julio Rodrigues
fonte

3

La gente ti prenderà in giro, per prima cosa :-)

— Karl Bielefeldt,

Una volta ho tradotto un parser di funzioni nidificate da D a java ma ammetto che non è il pezzo di codice più pulito che abbia mai scritto (una grande funzione con un'interfaccia e diverse classi che la implementano definita al suo interno)

— ratchet freak

23

Uno dei problemi è che potresti trovarti a scrivere un sacco di codice per esprimere qualcosa in un modo che farai in un'altra lingua, mentre c'è un modo più semplice nella lingua che usi.

Ad esempio, in una risposta su Stack Overflow , ho spiegato come i contratti di codice, concetto utilizzato in .NET Framework, possono essere parzialmente emulati in PHP che non li supporta. Ho finito per scrivere un sacco di codice per niente, poiché la stessa cosa era fattibile con semplici array.

Più in generale, ogni lingua ha la sua cultura, le sue migliori pratiche, il suo stile.

Se comincio a scrivere codice C # come se fosse C, sarebbe brutto.
Se comprendo Haskell come sviluppatore Java che è stato costretto a usare Haskell, ma non voglio comprenderne i punti di forza e voglio solo clonare i concetti di Java, il codice che scriverei soffrirà.
eccetera.

Non c'è nulla di sbagliato nel cercare di migliorare la lingua (ad esempio migliorare C # introducendo unità di misura come in F #), ma se lo stai facendo troppo, dovresti forse scegliere una lingua diversa che si adatti effettivamente alle tue esigenze.

— Arseni Mourzenko
fonte

+1 Buona risposta, e grazie per i termini di ricerca aggiuntivi con l'aggiunta di unità di misura a C # come in F #.

2

Come uno che una volta ha lasciato il lavoro per essere stato costretto a usare Java, i miei 2 centesimi: uno non può essere costretto a usare Haskell, uno se ne innamora e poi ti risucchia fino al punto di non ritorno. Haskell è come un bel buco nero in cui vuoi solo cadere - e diversamente da un vero buco, vivi ancora per raccontare la storia :)

— Cetin Sert,

dovresti forse scegliere un'altra lingua ... tranne quando non hai scelta, come JavaScript lato client. (Anche così, non avere scelta non è una scusa per implementare l'emulazione OOP basata su classi in un linguaggio prototipo. È molto più efficiente imparare semplicemente come funziona il linguaggio.)

— kojiro,

@kojiro: o un altro lavoro. Ho avuto lo stesso problema quando sono stato costretto a usare PHP e ho cercato costantemente di modificare il linguaggio, incluso scrivere il mio compilatore. Una soluzione meno folle è stata quella di cambiare lavoro e iniziare a lavorare solo su progetti che non utilizzano PHP.

— Arseni Mourzenko,

1

@Cetin Sert: d'accordo, Haskell è un linguaggio eccellente. Ma se qualcuno non vuole impararlo e non capisce la programmazione funzionale, sarebbe difficile apprezzare Haskell.

— Arseni Mourzenko,

10

Il calo della leggibilità è abbastanza un problema in sé: riduce drasticamente il pool di persone che potrebbero potenzialmente mantenere il tuo progetto senza una lunga formazione da parte tua.

Inoltre,

L'implementazione del paradigma straniero può costare di più rispetto ai potenziali risparmi derivanti dal suo utilizzo
Il tuo adattamento della funzionalità straniera potrebbe essere difettoso, aumentando i costi di manutenzione
Il tuo adattamento della funzionalità esterna può spingere il tuo stack tecnologico oltre i limiti richiesti dall'implementazione nativa.

— dasblinkenlight
fonte

2

Una volta ho dovuto emulare il dispacciamento dinamico C ++ (tabelle virtuali, ecc.) In vanilla C, e ho riscontrato esattamente questo problema: i programmatori C che non capivano il dispacciamento dinamico non erano in grado di contribuire o mantenere il progetto.

— comingstorm

4

Non è una buona idea come appare sulla carta.

Esempio 1: se sei abbastanza grande, potresti ricordare i giorni in cui C era il nuovo bambino in città. Ai programmatori di Pascal e Ada non piacevano le parentesi graffe aperte e chiuse di C. Hanno definito begine endper aprire parentesi graffe e chiudere parentesi graffa e voilà! CADA! Lo sfortunato risultato fu brutto dal punto di vista di Ada o C.

Esempio 2, personale: una delle cose che mi è piaciuta molto del Common Lisp Object System è che sono metodi prima, dopo e intorno. Possono tornare molto utili in più punti. Quindi ho emulato questo concetto in C ++ in alcuni posti selezionati. L'unico modo per emulare questi costrutti in C ++ è richiedere allo sviluppatore di una classe derivata di chiamare il metodo della classe genitore con lo stesso nome nella posizione corretta nel codice. Ciò poneva un requisito per gli sviluppatori che derivavano dalle mie classi che era un po 'estraneo alla programmazione C ++ e forse contro la grana della programmazione C ++. Non importa quanto sia ben documentato questo requisito, le persone non hanno seguito le linee guida perché non si adattavano perfettamente al paradigma C ++.

— David Hammen
fonte

2

Quali problemi possono sorgere dall'emulazione di concetti da altre lingue?

Astrazioni che perdono.

— Jim G.
fonte

Potrebbe essere utile includere alcuni dettagli nella risposta. L'articolo si riferisce a un caso in cui un'astrazione non riesce a catturare una significativa ottimizzazione delle prestazioni, ma direi che problemi più grandi derivano da un comportamento incoerente e da garanzie incoerenti; un esempio di quest'ultimo sarebbe il tentativo di C # di emulare i outparametri in un framework che non li supporta realmente; C # presuppone che ogni funzione scriverà sempre su tutti i suoi outparametri, ma i metodi non C # chiamati dai metodi C # non offrono tale garanzia.

— supercat,

1

Può essere proibitivamente difficile. Immagina di provare a implementare LINQ da C # nella tua applicazione Java. O che ne dici di aggiungere chiusure lessicali a una lingua? Dovresti praticamente scrivere un nuovo compilatore, che ti dà praticamente una nuova lingua.

Oppure, per i casi in cui non devi implementare la tua lingua, immagina di provare a implementare metodi di raccolta usando funzioni di ordine superiore (come la mappa) in una lingua che non ha blocchi di codice o funzioni lambda o chiusure o funzioni come prima oggetti di classe. Ogni funzione di ordine superiore deve essere dichiarata come interfaccia e implementata in modo esplicito e tutti gli stati che sarebbero stati acquisiti in una chiusura devono essere esplicitamente archiviati nella classe di implementazione. È così tanto scrivere extra, e molto più difficile da leggere, che spesso non ne vale la pena.

— psr
fonte