Fibonacci is basically the "Hello, World" program of functional programming--it's trivial but succinctly summarizes several disparate language features. The reason you see it so often is that you are (naturally) reading introductory articles. I imagine if you didn't know anything about imperative programming, the endless stream of "Hello, World" and contrived OO examples (Dog is an Animal...) would also seem onerous.
Lists, on the other hand, are actually very useful in functional programming. Lists and their corresponding higher-order functions are the equivalent of loops in imperative languages.
The real issue you're seeing, though, is that you have to start small to understand everything. This is true of everything, not just functional programming. I remember learning C++ and being really frustrated that all I ever wrote were silly command-line programs; however, I could hardly have jumped into UI development with practically no understanding of the language.
However, most practical applications require you understand the very basics: recursion, list operations, types... An article that just jumped into something like FRP (Functional Reactive Programming, a really awesome approach to making UIs) would just confuse you unless you've spent at least a little bit of time with Fibonacci and friends.
Ultimately, the only way to know if functional programming is better for some problem you have is to first understand its fundamental building blocks.
> Ultimately, the only way to know if functional programming is better for some problem you have is to first understand its fundamental building blocks.
Without understanding anything about event loops or closures, you can look at http://www.nodejs.org and think "hey wow, that looks just like what I need!"
Why can't the same hold about programming languages? Why do the functional programming aficionados insist that I get all turned on by a quicksort before telling me how immutability with remove all my multithreading headaches?
I mean, F# for example, has a communication system (Agents) which I find really gorgeous on first glance. These help solve real problems, and can do something you can't really do well in C#.
I think the main difference is in scope: to use node, you basically write code as you normally would in JavaScript, which is not entirely dissimilar to languages almost everybody is familiar with. It is different, but not by much. Writing a program, particularly anything interesting, in a language like Haskell is entirely dissimilar from anything most people have used. F# is probably also like this, but I'm not familiar enough with it to be sure.
The point of trivial examples like quicksort is just to illustrate the fundamental differences--mostly advantages--of using functional languages. Using a functional language will change every aspect of your code, so even examples like this are illustrative while being simple enough to fade into the background.
Languages like Haskell do have a ton of cool features, but they are all overshadows by how different they are. Once the fundamental differences are thoroughly explained, other goodies can emerge. For example, look at snap, a really fast web framework for Haskell. It's even faster than node.
Lists, on the other hand, are actually very useful in functional programming. Lists and their corresponding higher-order functions are the equivalent of loops in imperative languages.
The real issue you're seeing, though, is that you have to start small to understand everything. This is true of everything, not just functional programming. I remember learning C++ and being really frustrated that all I ever wrote were silly command-line programs; however, I could hardly have jumped into UI development with practically no understanding of the language.
However, most practical applications require you understand the very basics: recursion, list operations, types... An article that just jumped into something like FRP (Functional Reactive Programming, a really awesome approach to making UIs) would just confuse you unless you've spent at least a little bit of time with Fibonacci and friends.
Ultimately, the only way to know if functional programming is better for some problem you have is to first understand its fundamental building blocks.