Ho letto molte volte sul web che se la tua lingua non supporta alcuni concetti, ad esempio l'orientamento degli oggetti o forse le chiamate alle 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 loro programmazione. Quali altri problemi pensi possa sorgere da questo?
Uno dei problemi è che potresti trovarti a scrivere un sacco di codice per esprimere qualcosa in un modo che faresti in un'altra lingua, mentre c'è un modo più diretto nella lingua che usi.
Ad esempio, in una risposta su Stack Overflow , ho spiegato come i contratti di codice, concetto utilizzato in .NET. Framework, può essere parzialmente emulato in PHP che non li supporta. Ho finito per scrivere un sacco di codice per niente, poiché la stessa cosa era fattibile con matrici semplici.
Più in generale, ogni lingua ha la sua cultura, le sue migliori pratiche, il suo stile.
Se inizio a scrivere codice C # come fosse C, sarebbe brutto.
Se apprendo Haskell come uno sviluppatore Java che è stato costretto ad usare Haskell, ma non voglio capire i suoi punti di forza e voglio solo clonare i concetti di Java, il codice che scriverò ne risentirà.
ecc.
Non c'è niente di sbagliato nel provare a migliorare la lingua (ad esempio, migliorare C # introducendo unità di misura come in F #), ma se lo fai troppo, dovresti scegliere una lingua diversa che soddisfi le tue esigenze.
La riduzione della leggibilità è già di per sé un problema: riduce drasticamente il numero di persone che potrebbero potenzialmente mantenere il tuo progetto senza una formazione approfondita da parte tua.
Inoltre,
Non è una buona idea come appare sulla carta.
Esempio 1: se sei abbastanza grande, puoi ricordare i giorni in cui C era il nuovo bambino in città. I programmatori Pascal e Ada non hanno gradito le parentesi graffe aperte e strette di C. Hanno #defined begin e end per aprire la parentesi graffa e la parentesi graffa, e voilà! CADA! Il risultato sfortunato era brutto dal punto di vista di Ada o C.
Esempio 2, personale: una delle cose che mi è veramente piaciuta del Common Lisp Object System sono i metodi before, after, and around. Possono venire in modo molto utile in più posti. Così 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 nel posto giusto nel codice. Ciò impone agli sviluppatori che derivano dalle mie classi di essere un po 'estranei alla programmazione in C ++, e forse alla grossa programmazione in C ++. Non importa quanto questo requisito sia ben documentato, le persone semplicemente non hanno seguito le linee guida perché non si adattavano perfettamente al paradigma C ++.
What problems can arise from emulating concepts from another languages?
Può essere proibitivamente difficile. Immagina di provare a implementare LINQ da C # nella tua applicazione Java. O che ne dici di aggiungere solo chiusure lessicali a una lingua? Dovresti praticamente scrivere un nuovo compilatore, che ti dà praticamente un nuovo linguaggio.
Oppure, per i casi in cui non devi implementare la tua lingua, immagina semplicemente di provare ad 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 funziona come oggetti di prima 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 memorizzati in modo esplicito nella classe di implementazione. È molto più digitante, e molto più difficile da leggere, che spesso non ne vale la pena.
Leggi altre domande sui tag programming-languages concepts idioms