Functional programming: A step backward?(blog.jelastic.com)
blog.jelastic.com
Functional programming: A step backward?
http://blog.jelastic.com/2012/07/05/functional-programming-a-step-backward/
2 comments
The essence of this article is, "functional languages have ugly syntax". It uses Erlang and Haskell as an example. That argument says nothing of the functional style, just that "Erlang and Haskell have an ugly syntax" - that's what the article should've been entitled.
Actually, it says to me "functional languages are unfamiliar, therefore they're bad". Particularly the crux of the essay:
Any halfway decent programmer can quickly glean the general intent of most imperative code — even in a language he or she has never seen. While you can certainly figure out what functional routines do by looking at them, it may not be possible in a glance. Unlike imperative code, functional code doesn’t map to simple language constructs. Rather, it maps to mathematical constructs.
What's actually the case is: any decent imperative programmer can quickly glean the general intent of most imperative code; equally, any decent functional programmer can quickly glean the general intent of most functional code. Furthermore, anyone with a decent grounding in merely algebra can quickly glean the general intent of well-written functional code. The same cannot be said of imperative code.
As for ugly syntax... well, I don't know Erlang, but that Haskell is incredibly badly mangled. Haskell can be beautiful -- substantially more so than most languages, I'd say. The same code, reformatted:
Any halfway decent programmer can quickly glean the general intent of most imperative code — even in a language he or she has never seen. While you can certainly figure out what functional routines do by looking at them, it may not be possible in a glance. Unlike imperative code, functional code doesn’t map to simple language constructs. Rather, it maps to mathematical constructs.
What's actually the case is: any decent imperative programmer can quickly glean the general intent of most imperative code; equally, any decent functional programmer can quickly glean the general intent of most functional code. Furthermore, anyone with a decent grounding in merely algebra can quickly glean the general intent of well-written functional code. The same cannot be said of imperative code.
As for ugly syntax... well, I don't know Erlang, but that Haskell is incredibly badly mangled. Haskell can be beautiful -- substantially more so than most languages, I'd say. The same code, reformatted:
-- file: ch05/Prettify.hs
pretty width x = best 0 [x] where
best col [] = ""
best col (d:ds) = case d of
Empty -> best col ds
Char c -> c : best (col + 1) ds
Text s -> s ++ best (col + length s) ds
Line -> '\n' : best 0 ds
a `Concat` b -> best col (a:b:ds)
a `Union` b -> nicest col (best col (a:ds)) (best col (b:ds))
nicest col a b | (width - least) `fits` a = a
| otherwise = b
where least = min width col
I (the author) familiar with functional languages, have implemented a compiler for a small one and such. However, for every day applications that are non-algorithmic attempts to express them using functional constructs have often been a strain. I've been watching projects go late due to this. There are many things, however, that I find much clearer to express in terms of functional programming constructs. But nominal business apps which show a GUI and CRUD from one location to the next or do a fairly simple data transform with a bit of boolean logic? Not so much.
The formatting is a result of the copy-editing process. The code excerpts were all from the beginner tutorials linked from the sites or wikipedia.
The formatting is a result of the copy-editing process. The code excerpts were all from the beginner tutorials linked from the sites or wikipedia.