Nella sua più pura, la programmazione funzionale riguarda la definizione di un insieme di tipi di dati, privo di comportamenti, e quindi la definizione di un insieme di funzioni "libere" su quei tipi di dati, che possono essere liberamente estesi a seconda delle necessità. Questo di solito viene fornito con una sorta di meccanismo namespace / module, quindi nonostante il fatto che le funzioni siano gratuite, non sono globali nel senso che esiste un singolo namespace per tutto ( nota: so quasi nulla su Swift , quindi se non ha un meccanismo di namespacing per le funzioni libere e se effettivamente rientrano in uno spazio dei nomi globale, allora direi che è qualcosa da scoraggiare e trovare la lingua che manca in questo senso ).
Ora, supponendo che tu abbia dei namespace, è una buona idea? Suppongo che sia abbastanza buono, dal momento che funziona per molte persone (e di solito sostengono che funziona meglio dell'alternativa). È un buon modo per modellare le cose in generale, e di solito è un modo migliore per modellare concetti astratti che si sentirebbero forzati a essere schiacciati nelle gerarchie delle classi OO. Detto questo, ha i suoi difetti come illustrato dal problema di espressione , dove FP ricade esattamente sulle "funzioni facili da aggiungere, lato difficile da aggiungere casi ". Non a caso, questo significa che molte cose che sono dos in FP non sono in OO e viceversa.
Ecco perché i recenti linguaggi OO / FP ibridi, Swift uno di loro, sono pronti a rivendicare una sorta di via di mezzo tra i due. Ma dove questo terreno di mezzo è, e ciò che è solo Haskell / Java scritto in un'altra lingua varierà caso per caso.