> I'm beginning to feel that the real advantages of FP are being obfuscated by unusual syntax. Or that unusual syntax is precisely motivated by trying to seaml

> I'm beginning to feel that the real advantages of FP are being obfuscated by unusual syntax. Or that unusual syntax is precisely motivated by trying to seamlessly and naturally express FP code. Either that or they were just being intentionally obtuse... come on, man. Which sounds more likely of these two? I'd personally never want to program in a language with the semantics of Haskell, and the syntax of a C-like language. > With better references and immutable variables, we should be able to split calculations up over several lines and have the compiler figure out how to optimize it into basically FP code. Or just dive the code up into whatever temporary and intermediate steps that you need with let-in expressions and where-declarations? I mean, why not? If what you want the compiler to process is FP code, then just divide it up like you would divide up FP code. FP /= one liners.