3 ms·

Functional languages often fall into the trap of making hard things easy at the cost of making easy things hard and then no one uses them.

by Sevii 8y ago

bjourne 8y ago
Funny, I'd say it is exactly the opposite. :) FP makes easy things almost trivial but hard problems almost impossible. E.g writing quicksort is trivial in Haskell, writing an implementation of quicksort that runs efficiently in Haskell is very hard.
- Jtsummers 8y ago
  However, efficiency should be secondary to ease of reading/writing and validity of the program (wrt target application) for most programs (obviously efficiency is a primary concern for certain embedded domains, network applications, and game engines). The nice thing (from my view) about functional languages (particularly those of the ML family, but also the logic languages like Prolog) is that the semantic distance between specification and implementation is very short. This means you can rapidly describe your problem domain and translate that to a reference implementation. If performance is critical, you can then work on improving the efficiency of this implementation, or write the program (or parts of it) in a separate language. When it comes time to verify the second program (with a larger semantic gap between specification and implementation) you can run both, ignoring timing, and observe whether they produce comparable output (within whatever constraints you need for your application, so equal or within some error bound). When your specification changes, you can modify the reference implementation first (where reasoning about the problem ought to be easier) and then work on your deployed system. This does introduce overhead in that you're maintaining two systems, but if you're doing good V&V you're already building a comprehensive model of your deployed system. Why not have a model that can generate your test procedures and target results for you rather than hand building everything?

Functional languages often fall into the trap of making hard things easy at the cost of making easy things hard and then no one uses them.

by Sevii 8y ago

Functional languages often fall into the trap of making hard things easy at the cost of making easy things hard and then no one uses them.

bjourne 8y ago

Funny, I'd say it is exactly the opposite. :) FP makes easy things almost trivial but hard problems almost impossible. E.g writing quicksort is trivial in Haskell, writing an implementation of quicksort that runs efficiently in Haskell is very hard.

Jtsummers 8y ago
However, efficiency should be secondary to ease of reading/writing and validity of the program (wrt target application) for most programs (obviously efficiency is a primary concern for certain embedded domains, network applications, and game engines). The nice thing (from my view) about functional languages (particularly those of the ML family, but also the logic languages like Prolog) is that the semantic distance between specification and implementation is very short. This means you can rapidly describe your problem domain and translate that to a reference implementation. If performance is critical, you can then work on improving the efficiency of this implementation, or write the program (or parts of it) in a separate language. When it comes time to verify the second program (with a larger semantic gap between specification and implementation) you can run both, ignoring timing, and observe whether they produce comparable output (within whatever constraints you need for your application, so equal or within some error bound). When your specification changes, you can modify the reference implementation first (where reasoning about the problem ought to be easier) and then work on your deployed system. This does introduce overhead in that you're maintaining two systems, but if you're doing good V&V you're already building a comprehensive model of your deployed system. Why not have a model that can generate your test procedures and target results for you rather than hand building everything?