OSDev.org

Imperative programming, which is used by the majority of programming languages today, is a sort of recipe - a series of steps. Put ingredients in a bowl, mix, bake. Put a toothpick in it, if the toothpick isn't dry, wait another 5 minutes, repeat, let cool, cut into slices.

Functional programming describes what something is. You can accomplish the same things, but the wording is very different: brownies are a baked batter mix whose toothpick comes out dry. Batter mix is a combination of the ingredients.

For me, using functional languages makes it more about the language then the particular problem your trying to solve. I use languages that I notice the least. For example, C, Go, and Perl. I wouldn't learn Lisp (save for Emacs / Vim), as I don't think functional programming would help me solve a real-world problem.

nexos wrote:For me, using functional languages makes it more about the language then the particular problem your trying to solve.

I don't completely agree on that, but there is some truth in your statement: often people don't use functional programming just to solve a problem, but because of the way it's possible to solve that problem with that paradigm. A trivial example is recursive vs iterative algorithms: some problems like in-order visit of a BST have a super simple and elegant recursive solution, while the iterative algorithm is not so simple to read, write and maintain (suppose you might need some tweaks). Note that recrusive solutions are generally much closer to the FP world compared to the iterative ones.

nexos wrote:I use languages that I notice the least. For example, C, Go, and Perl.

I consider C my "native" language as I've been using it since I was very young and it probably feels more natural to me than any other language, but... do I notice it? Hell, yeah. I mean, it's great and it feels completely natural to me, but I can still compare it to other languages as well. It's the same for human natural languages: at the beginning, you speak only your own native language and don't notice its properties/pros/cons, but after you learn a few other languages, you start comprehending your own language at a different level.

So, briefly, IMHO every language is noticeable and inevitabily affects our thinking model.

nexos wrote:I don't think functional programming would help me solve a real-world problem.

Imperative solutions typically perform much better than FP ones, but some people might find it comfortable to do some prototyping or writing scripts with FP-like code. It depends a lot on the problem you're trying to solve. FP is very bad for system code where side-effects are the key, but it might offer simpler/nicer solutions when dealing with some purely computational (algoritmic) problems. Don't get me wrong: I'm a C/UNIX guy and I'd prefer people to write highly optimized imperative code for production instead of "wasting" CPU cycles to do extra object copies as it happens with FP techniques: I hate when people try to force FP everywhere. I just wanted to point out that understanding something about FP and its benefits could be useful for a SW engineer, in general. Even if pure FP is not widely used, some FP ideas have been adopted by many OO or multi-paradigm languages like C++, Java and Python: things like map(), filter(), reduce() and stateful lambdas (closures) came from the FP world.

For kernel development, FP won't help not so much I guess but, hey, you don't know for sure what you'll going to do for the next 30 years

I wanted to post something like this but didn't want to get too much in troll argument

But yes sometime also the how matter, it's why we have type system, and proof of correctness etc Sometime the noticeable part is to help structuring the program, avoiding bugs, and facilitate proof of correctness.

I'm not that much into full functional langage because i tend to find them obtuse for many things, for me this paradigm really works well for computation, like if you only deal with first class value its fine, the copying doesn't cost much, and the paradigm works well.

but even using imperative langages, i often find myself leaning toward functional style, because it avoid states management, and programs are easier to prove correct. Imperative / OOP can quickly become a mess and hard to really understand and make some bugs hard to spot.

Even carmack made a good case for pure functions