[Haskell-cafe] What *not* to use Haskell for

[Belka]

(1) Function as a system of N concurrent inputs and 1 output is easy essence.
How about function as N concurrent inputs and M concurrent outputs? I think
it's not native to lambda calculus. So "system's programming" (if we ever
had such paradigm) would solve this issue, while criticizing all FP.

(2) For me, I hope this category (What *not* to use Haskell for) won't
include SOA. That's what I'am currently trying to decide.

(3) I think if CPU's would be lambda-based, not imperative, and paradigm be
stronger, most of the "why *not* to use Haskell"'s would be solved, and
imperative would be in opposition instead.. with it's enthusiasts. =) They
would have good answers for your question.
-- 
View this message in context: http://www.nabble.com/What-*not*-to-use-Haskell-for-tp20436980p20755239.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.