La programmazione funzionale non è intrinsecamente inefficiente. Non c'è motivo per cui la semantica del linguaggio debba corrispondere strettamente al modello di esecuzione sottostante, anche se una corrispondenza più stretta rende sicuramente più facile la compilazione.
Ad esempio, Haskell è già in grado di fornire buone prestazioni in questo momento, ma l'ottimizzazione è un problema da non perdere: è difficile scrivere il codice Haskell che verrà compilato in modo affidabile con codice macchina ben ottimizzato. Il problema non è che Haskell sia un linguaggio funzionale , ma che Haskell abbia una semantica abbastanza complessa e di alto livello, in particolare caratteristiche insolite come la valutazione pigra. Altri linguaggi funzionali sono molto dinamici e non dispongono di un sistema di tipi che consentirebbe la generazione di codice efficiente, ad esempio JavaScript.
Ma i linguaggi FP non dispongono di quelle semantiche complesse , ad es. la famiglia linguistica ML ha linguaggi imperativo-funzionali tipicamente staticamente digitati come OCaml. Oltre a dover gestire le chiusure, la compilazione di OCaml non è fondamentalmente diversa dalla compilazione C. E C ha anche caratteristiche problematiche che limitano la sua efficienza sull'hardware attuale, ad es. puntatore aliasing.
Se le lingue funzionali hanno una funzionalità problematica w.r.t. esecuzione efficiente, è la necessità di Garbage Collection . Per esempio. strutture dati immutabili, chiusure e continuazioni sono tutte vantaggiose se:
- i dati non referenziati possono essere raccolti con parsimonia a basso costo
- probabilmente: i dati possono essere copiati a basso costo, ad es. attraverso copy-on-write (CoW)
- un modello esecutivo che non presuppone l'esistenza di uno stack
Queste sono cose che potrebbero in linea di principio essere spostate nel silicio, ad es. un chip MMU con hardware GC e un indirizzamento virtuale incorporato che supporta CoW. (Sì, sono a conoscenza delle pagine di CoW, ma qui non è abbastanza granulare.) Tuttavia, ciò implicherebbe un modello di memoria radicalmente diverso rispetto a quello utilizzato oggi. Dubito che questo sarebbe più efficiente dello stato attuale della tecnica, ma potrebbe consentire un'esecuzione più efficiente di programmi funzionali e orientati agli oggetti rispetto all'hardware corrente.
Ma ciò non accadrà, semplicemente perché le economie di scala favoriscono lo status quo. C'era una volta l'hardware di programmazione funzionale: Lisp Machines . Questi sono praticamente scomparsi, a causa del calo della domanda Lisp e dei microprocessori (come i chip x86): i microprocessori sono già abbastanza veloci. Costruire grandi compilatori è più economico rispetto allo sviluppo di chip competitivi. Per ragioni simili, le JVM hardware non sono mai state catturate (anche se le piattaforme Java lo hanno fatto, vedi Android e molti feature phone).