Buone pratiche: applica un paradigma a un linguaggio che non è adatto a questo

For example, what happens if a coder tries to code in purely functional-style paradigm in OO-paradigm language(Java)? Will it work?

Non bene.

Le parti di una lingua sono spesso tagliate su misura per rendere facili i comportamenti comuni. Una volta che cambierai i comportamenti comuni, quel disegno (di solito) non si tradurrà nei nuovi requisiti.

Also, is applying wrong paradigm to language unfitting to it a bad practice or not?

In genere è una cattiva pratica. I linguaggi di programmazione hanno due scopi principali:

1. Dire al computer cosa fare.
2. Dire agli altri programmatori cosa sta facendo il computer.

Quando inizi a deviare dai normali idiomi di un ambiente di programmazione, inizi a deviare da ciò che altri programmatori conoscono / aspettano / capiscono. Poiché quasi tutti i progetti di programmazione in questi giorni coinvolgono team, è considerata una cattiva pratica rendere il codice difficile da leggere, ampliare e mantenere.

Puoi quasi sempre calzare un paradigma in un linguaggio che non supporta quel paradigma, ma avrai bisogno di molti hack e il codice risultante sarà una combinazione di brutto, complicato, inefficiente, non idiomatico, ecc.

Questo mi porta alla seconda parte della domanda: è una buona idea? Generalmente no, poiché causa molti aspetti negativi che non valgono alcun vantaggio che il paradigma può avere per il problema dato (vedi sopra). Tuttavia, faccio un'eccezione se un paradigma offre grandi vantaggi per l'attività e può essere seguito con ragionevole facilità, vale a dire, gli aspetti negativi di cui sopra sono accettabili.

Dipende davvero da quale lingua e da quale paradigma, principio o modello stai cercando di emulare.

Direi che la migliore pratica è usare la lingua più adatta alle tue esigenze e studiare altre lingue per identificare i modi in cui puoi migliorare lo stile di codifica nella lingua che preferisci. Ma avvicinati sempre a una lingua per i suoi meriti; utilizza i punti di forza e il carattere unici della lingua che hai scelto, piuttosto che provare a calzare un paradigma che non è proprio una buona idea.

OO e puramente funzionale non formano una dicotomia. "puramente funzionale" di solito significa semplicemente evitare la mutazione, OO è un termine lanoso che IMO acquisisce solo un po 'di concretezza quando si riferisce al sistema di tipi.

Un po 'troppo semplicistico, il consenso generale è con sistemi di sistemi più grandi, più complessi e più concorrenti, la mutazione è sempre più uno strumento ingombrante.

Se cerchi di evitare l'uso della mutazione, la tua capacità di scoprire comunque la verbosità di java et al diventa molto peggiore. Un sacco di persone incolpano OO, il vero problema che penso si trova più con l'influenza della sintassi C e C. Java ti offre delle chiusure complete, infatti, con le classi anonime, è solo la sintassi che si confronta in modo ridicolo con le lingue che più apparentemente supportano.

Ancora una volta, il punto qui non è che OO e con parsimonia usando la mutazione non si mescolano, è che java è prolisso. Scala penso che sia l'esempio migliore in cui hai un sacco di espressività e un OO che francamente è OO più puro di java.

link Un'interessante intervista a Martin Odersky, creatore di Scala (e generici di Java).

Dal punto di vista opposto, il sistema di tipi di Haskell ti consente di fare molto di ciò che OO realizza, specialmente con le estensioni. Anche se la teoria del tipo sottostante è leggermente diversa, l'utilizzo da un punto di vista tecnico del software è abbastanza simile.

Si consideri in Java, un idioma comune è quello di scrivere un tipo di dati astratto tramite un'interfaccia, e quindi chiamare alcuni metodi in esso su una raccolta eterogenea, ma uno in cui tutti gli elementi implementano tale interfaccia. Prima di tutto, puoi scrivere una classe di tipi che fa esattamente ciò che fa quell'interfaccia. In secondo luogo, usando i tipi esistenziali (un'estensione), è possibile creare strutture di dati eterogenee e così via, proprio come con Java. Solo l'uso di una classe di tipo ti dà il polimorfismo, ma solo la spedizione statica. I tipi esistenziali ti forniscono invio dinamico.

link < - ulteriori informazioni sui tipi esistenziali.

quindi tl; dr se scegli una lingua con un sistema di tipi abbastanza strong e una sintassi abbastanza espressiva, puoi smettere di preoccuparti dei paradigmi e fare semplicemente ciò che si adatta meglio al tuo obiettivo.

Non funzionerà perché ci sono cose che non puoi fare a meno di misure draconiane come scrivere un generatore di codice (che sta effettivamente creando il tuo, nuovo linguaggio). Ovviamente, se entrambe le lingue sono completate da Turing, puoi ottenere lo stesso comportamento, ma il codice è così diverso che non è ragionevole dire che stai davvero facendo una programmazione funzionale.

Facciamo un semplice esempio: funzioni di ordine superiore.

Le funzioni di ordine superiore sono parti di base, pane e burro di lingue funzionali. Per usarli, devi essere in grado di passare una funzione come parametro. Java non ti permetterà di farlo. Hai usato il modello di comando. Ciò significa che devi andare a creare un'altra classe per conservare il codice per il tuo comando, invece di definirlo in linea.

Peggio ancora, quando il tuo comando viene valutato, è in esecuzione in un contesto diverso da quello in cui è stato definito. Le variabili che erano nello scope in quel momento potrebbero essere sparite. Pertanto, tutte le variabili necessarie devono essere inserite nell'oggetto comando in modo che possano essere trasportate nel nuovo ambito. Devi farlo manualmente, ogni volta. Se il linguaggio avesse delle chiusure lessicali, il computer lo capirebbe per te.

A questo punto, quale sarebbe, diciamo, una semplice chiamata a mappare con una funzione lambda è diventata un piccolo progetto, e il codice sembra completamente diverso.

Anche peggiora. Cose come un sistema di tipo algebrico controllato al momento della compilazione non succederanno mai per te, mai.

Devi decidere se un pattern di programmazione ha senso nella lingua che stai usando , il fatto che ci sia una soluzione elegante in un linguaggio completamente diverso potrebbe aiutare per l'ispirazione ma non può determinare come strutturi il tuo codice.

Molto spesso non è una buona idea provare a scrivere direttamente codice funzionale, in particolare codice funzionale puro, in lingue OO. Questo sembra essere il consenso qui intorno.

Un'alternativa possibile è farlo "indirettamente", per così dire, usando un linguaggio compatibile binario con il tuo linguaggio OO.

Ad esempio, sulla JVM hai Scala, o, se vuoi più Haskell, hai Frege . Entrambe le lingue possono interfacciarsi con Java. In effetti, il compilatore Frege crea il codice sorgente Java e usa il normale compilatore Java per compilarlo in bytecode, quindi scrivere codice di Frege potrebbe essere considerato il modo più efficiente per scrivere codice Java puro e funzionale non rigido. Mentre Scala compila direttamente in bytecode, per quanto ne so. Ma questo non ostacola l'interoperabilità.

Allo stesso modo, invece di scrivere C # funzionale, puoi provare F #, che è essenzialmente un dialetto ML con supporto per l'interoperabilità .NET e C #.