Quando una Monade diventa un martello?

2

Mi rendo conto che la mia comprensione precursore su Monads è gravemente carente nei dettagli considerando che la mia conoscenza proviene principalmente da Le Monade di Douglas Crockford e le Gonadi parlano e complicato con il mio handicap Sevear con Haskell (che assomiglia a un gruppo di caratteri non alfa numerici fusi tra le parole inglesi disgiunte e il mio cervello tragicamente svantaggiato).

Detto questo, vorrei chiedere informazioni sulle pratiche di programmazione relative alle Monade e su come potrebbero essere implementate in JavaScript. La presento perché riconosco che la natura stessa del linguaggio può influenzare drasticamente il modo in cui si percepisce un concetto e che a causa del mio background in JavaScript questa domanda potrebbe essere inappropriata se fosse basata su un linguaggio puramente funzionale come Haskell.

Spesso durante la progettazione di un'interfaccia o la codifica di un oggetto mi trovo ad implementare una forma di concatenamento che muta i dati incapsulati. Preferisco questo stile su forme più dichiarative come passare in un oggetto letterale multi-allineato.

function Declarative(options) {
  this.options = options;
}
Declarative.prototype.compute = function() { ... }
var x = new Declarative({
  foo: 'foo',
  bar: 'bar'
});
x.compute();

I versi:

function Chained() { }
Chained.prototype.withFoo = function(v) {
  this.foo = v;
  return this;
};
Chained.prototype.withBar = function(v) {
  this.bar = v;
  return this;
};
Chained.prototype.compute = function() { ... }
var x = new Chained()
  .withFoo('foo')
  .withBar('bar')
  .compute();

Entrambi questi esempi (a parte l'estetica) sollevano qualche pelo sulla mia schiena perché una piccola voce beffarda strilla "Mutabilità molto?" Comincio a pensare che questo potrebbe essere un buon momento per conciliare un modello Monad. Ciò che intendo per questo è che ogni metodo restituirà in breve un nuovo oggetto dello stesso tipo. Quindi aggiungere funzioni di composizione su di esso come la mappa, il binding, ecc. Potrebbe fuoriuscire da un mondo di potenziale come quello che ottengo con Promises e altri tipi di Monad. (Ovviamente avendo cura di seguire le tre leggi Monadiche quando implementate).

Infine, l'altra metà del mio cervello inizia a parlare con "Se tutto quello che hai è un martello, tutto sembra un chiodo". Sospiro. Questo è quando la mia produttività e creatività si infrangono qui su SE curiosi e confusi.

Mentre continuo la mia ricerca per la comprensione (forse guadagnando abbastanza coraggio per contemplare Haskell) chiedo: quando l'idea di Monade (che è la componibilità delle funzioni sugli oggetti (cioè i tipi) insieme all'immutabilità) diventa una buona idea per essere coltivato e modellato? E, quando non è altro che un martello troppo usato?

(Concetti e opportunità di apprendimento accolti, codice di esempio utile)

    
posta Sukima 15.07.2014 - 05:04
fonte

1 risposta

7

È difficile dire esattamente cosa stai chiedendo, quindi questa risposta è mirata a fornire più contesto sulle monadi. Alcuni preliminari sulle monadi:

  • La monaca di Crockford è una pessima fonte per conoscere le monadi (odio dire questo perché è molto più intelligente di me, e quindi probabilmente capisco meglio le monadi, ma IMHO dà un ritratto impreciso delle monadi ). Così sono molti altri "tutorial" di monad . Se non lavori duramente nel tuo percorso attraverso esempi reali, probabilmente non capirai mai le monadi.

  • le monadi non sono né speciali né magiche. Possono essere implementati in molti (la maggior parte?) Tutti i linguaggi di programmazione senza il supporto speciale della lingua / runtime / compilatore / interprete. Non sono la fine di tutto, be-all di programmazione funzionale. Ma per qualche ragione, sono ciò che sentiamo sempre.

  • le monadi non sono uniche. Ci sono molti altri tipi di dati correlati che sono utili a pieno titolo.

  • ci sono alternative alle monadi, a seconda di ciò che vuoi / devi fare. Cerca "sistemi di effetti" e "effetti algebrici".

  • spesso puoi ottenere la maggior parte / gran parte del valore delle monadi senza utilizzarle esplicitamente. Basta implementare i combinatori di cui hai bisogno e sono utili e usarli in modo appropriato. Riconosci i pattern nel tuo codice e li ritaglia, possibilmente catturandoli come combinatori. Se alcuni di questi combinatori corrispondono ai requisiti per unit e join , così sia. Ciò non significa che devi pensare a quello che stai facendo in termini di monadi. (D'altro canto, se si usano le monadi, si beneficiano dei numerosi combinatori già esistenti per le monadi, nonché della scrittura di codice super-generico).

Quando è inappropriato usare le monadi?

  • se devi deformare il tuo tipo di dati o le leggi della monade per "fare" una monade, probabilmente non dovresti farlo, e dovresti invece chiederti perché lo stai facendo

  • se il tuo codice non beneficia dell'uso di una monade, o se in realtà peggiora (sia perché è più lungo, o più difficile da capire, o più difficile da testare, o più difficile da mantenere, ... ecc. ), probabilmente stai usando le monade in modo inappropriato

risposta data 16.07.2014 - 15:29
fonte

Leggi altre domande sui tag