> Imperative programming is like building assembly lines, which take some initial global state as raw material, apply various specific transformations, mutations to it as this material is pushed through the line, and at the end comes off the end product, the final global state, that represents the result of the computation.
This isn't the best analogy as functional and imperative languages are both often used in a procedural fashion. If I simply replaced "global state" with "immutable arguments", this analogy fits functional programming as well. The fact that the arguments would be copied, however, would be implied.
> Each step needs to change, rotate, massage the workpiece precisely one specific way, so that it is prepared for subsequent steps downstream. Every step downstream depend on every previous step, and their order is therefore fixed and rigid.
This is more about tight coupling than imperative vs. functional paradigms. In general, imperative methods can be just as loosely coupled as functional methods. It basically comes down to what sort of data you're handling.
> Because of these dependencies, an individual computational step has not much use and meaning in itself, but only in the context of all the others, and to understand it, one must understand how the whole line works.
This, again, can be true of functional languages as well. You cannot always guarantee that a method is individually useful given the data at hand.
There is some faulty assumption that functional programming is never imperative. Functional programming has nothing to do with declarative/imperative programming styles. The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together.
If you need to compare functional programming against something contrast it against OOP, which is a different architectural approach.
>> functional and imperative languages are both often used in a procedural fashion
Exactly.
The most common ELI5 definition of functional programming I get from other developers is that you're piping multiple statements together into a single chain of processing [input(s) > multiple levels of processing > output(s)], without having to explicitly declare variables to hold the temporary inputs and outputs between each sub-statement within the chain. I know just enough to understand that this isn't the "proper definition", but that workflow is true enough that it's what many people associate functional programming with.
The problem with that particular definition is that it tries to make the primary benefit of functional languages seem to be this piping/chaining mechanism. Yet these languages are still written procedurally, executing multiple such pipes in sequence. You still have variables holding the inputs and outputs of each chain, so you can pass them to other unrelated chains. It reduces the overall number of statements and the manual variable/memory management required, but each statement is simply a compressed version of multiple statements merged into one, enforcing "fake immutable" variables for the inputs/outputs within the chain. You don't really have "immutability"; you simply have automatic variable management between sub-statements in a chain.
Now, show me a functional language where the entire program is written as a single piped chain, and I would classify that as its own genre. Literally, the entire program would have to be written top-down as a single block of code that chains every single required input from the top-level, all the way down to a single output, without using a single explicitly declared variable. Only the first line of code would be unindented at the first column, with all other lines having to be indented as part of that primary block. Now that would satisfy me as being "unique" or "different than procedural".
What is the primary metric of a functional language? Is it to write write golf code[1] that folds 10 "procedural statements" into a single 3-line "functional block"? To me that's not "functional programming"; that's just writing less code by chaining multiple operations into smaller blocks, reducing the complexity of having to explicitly declare more global or widely scoped variables.
Random thought association: is perl's well-known Schwartzian transform (@sorted = map { ... } sort { ... } map { ... } @unsorted), applied as a concept to an entire language, what makes a "functional language"? To me, that doesn't seem like enough of a scope change to warrant a different language "type".
Why compose classes, abstract base classes, etc. when you can compose simple functions!
It's true that abstractions in functional languages can seem foreign and hard to understand, but generally they have some purpose, being grounded in mathematical practice. OO abstractions and patterns OTOH, taught essentially in "elementary school" which possibly makes them seem easier to understand, do a very poor job of solving more problems than they create.
Learning a functional language is often a transformative experience that lasts throughout a career, whether you even use functional languages or not. It might make you do something as simple as partitioning which functions have side effects and which don't, even if the type system doesn't enforce it. Or use a form of quick/fuzz testing, even if it's not the standard test suite. Or make parts of the data immutable for scalability, auditability, etc. Or...
There really are few things as satisfying as developing a large codebase in a functional language. A lot of the frustrating maintenance work just goes away. But even if you don't, functional principles can yield similar benefits in imperative languages.
My apprehension comes from lack of seeing it in the wild (i.e. scaled businesses).
Google primarily uses C++/Java. Facebook: Hack. Twitter tried Scala and as far as I know, abandon it and went to Java. LinkedIn definitely tried Scala, failed, and went to Java. Square is Ruby/Java.
I'd like to have something to point to as a success story of a company at scale with functional programming. Anyone know of one?
> Twitter tried Scala and as far as I know, abandon it and went to Java.
This is incorrect. One of the former VPs said he would not use Scala. Twitter uses Scala massively and has published and continues to maintain several open source Scala projects.
> LinkedIn definitely tried Scala, failed, and went to Java
This is incorrect. A newly hired VP insisted on moving the front end from Scala to Java. In the offline backend stack Scala is used extensively. Check Kafka, Samza from LinkedIn or better yet ask current LinkedIn employees.
Apart from these Spotify, Foursquare, ebay, several banks use Scala. FP is huge in financial institutions, check K/KDB+. Jane Street etc. Thats where most FP programmers work. Also verizon, jet.com and walmart.com. There are several dozen large companies using FP.
FP is mainstream now. Traditionally, it was financial institutions using some flavor of ML/Haskell. With Scala/Clojure on the JVM, Si Valley has moved into FP in a big way.
The reason why you see this pattern is not because in functional programming vs. OOP, functional losses.
The reason for this pattern is because companies look for easily replaceable developers.
To get into functional you need to be good at abstracting the business domain, this requires seniority which is hard to find. Most of the time, when you are working using functional programming you are implementing the business vocabulary. Entry level developers are not good/interested in this. Their worries are in how they can use Angular 2 in this project, or why we need to still use SQL Server instead of converting to {insert the newest database technology}.
It is easy to find (and replace) junior developers that are happy because they created something with the latest technology and it provides the immediate value intended. It sounds good, but it misses the point.
Software development in a company happens to support/enhance the business. This means that it has to stand the test of time, not only in reliability but also in adaptability. The only constant in software is that it will change. Here is where building a vocabulary that represents the business subjects pays off. Change now is a definition-change and, unless the business is pivoting, definitions rarely change; instead, they have constant adjustments. Functional shines in creating a vocabulary and having this adaptability.
Of course, you can adapt using OOP, but the question is not if adaptability is possible, it is instead how to make changes at the lowest risk.
I think the end result is going to be companies adopting functional concepts. I can't find the article right now, but Carmack wrote about how even though he was not sure if he would write a whole game engine in something like Haskell, just learning to think functionally improved his C coding.
Java has had lambdas and streams for awhile now. A pretty common design pattern has also become anemic domain models operated on by groups of functions, which fits in the spirit of functional programming. Modern java can, and is used in a functional style.
On the JS side, functional concepts are everywhere. Given how heavily FB and Twitter are invested in JS, I don't think they have abandoned functional programming at all.
Finally, IMO Scala is actually a pretty poor example of a language that can be used at scale. Without a highly enforced set of rules it can quickly become a write once/read never language. I'm sure there are exceptions, but given the choice between scala and java 8+, I would go with java. Clojure may be an option though.
MapReduce, which Google built for indexing the entire web, along with many other big data tasks, is an example of something that could only have been invented by someone familiar with the principles of functional programming:
Imperative/object oriented languages are often more practical for real-world use (MapReduce itself I believe is written in C++), however it's the ideas of functional programming that matter most. Those with experience working in functional languages are at an advantage over developers who've never had that exposure, because they have a wider range of mental tools at hand with which to solve problems.
Bleacher Report went from 150 servers to just five (yes, that is not a typo, that is a 1/30 reduction) moving from Ruby on Rails to Phoenix on Elixir (née Erlang, but we should just call it "BEAM" at this point): http://www.techworld.com/apps/how-elixir-helped-bleacher-rep... They also handle 8x as much traffic. With 1/30 the number of servers.
Ruby is OOP. Elixir/Erlang is purely functional (although dynamically-typed... some will prefer typed... but the results speak for themselves).
If you are a long-time developer like me and are just coming across this, this news should strike you somewhere between "astonishing" and "pure fucking magic."
Here's the deal- Paradigm shifts, most people only see them AFTER they've finished. If you want to be ahead of the curve on this one and you want to reap the benefits, go functional (Haskell, Clojure, OCaml, F#, Elm, Erlang/Elixir). Today. That is my #1 piece of advice right now. (Well, that, and to avoid Scala and Go. Scala is just too overly complicated to keep your cognitive load down as a developer, and Go... Well, the name even says it: "Go!" As in, "don't stay!" ;) Go will suffer the same long term problems that all OOP/procedural langs share, compounded by its idiotic take on error handling /opinion)
Functional Programming, as the article points out, can be universal to many languages. You don't have to use an "FP" language to enjoy "FP" benefits.
JavaScript, for example, is ubiquitous in the industry, and, especially with the advent of ES6, can be written quite functionally. ReactJS is also widespread and can also enjoy an FP approach.
Erlang is used at WhatsApp. One of the interesting things there is that for the amount of users and messages handled they had a very small backend team. They have credited Erlang and its features as one of the keys to their success. It means less code (mostly related to minimal impedance mismatch from language to problem domain), debug-ability, reliability, fault tolerance, less ops overload and so on.
I personally find it much easier to navigate and fix bugs in an Erlang code base than in the equivalent C++/Java/C# one. It mainly boils down to how state is updated. When I see NewState = update(Value, State) it is clear what is happening. In OO code, I usually need to remember what object inherits from, what are is the instance state so far (what other members have been called) and how it got there. I find that much harder to handle, for example.
Or even better, how about empirical research to back up the claim that functional programming is "better"? Does the use of functional language result in fewer bugs at less cost? Compared to what (C, Java, Ada, Lisp)? I don't have an opinion on it but I would like to see the bold claims backed up by actual evidence instead of assertions.
From the article "in this case for massive distributed systems Functional Languages are the right tool
...
Immutability at scale is really important because it allows you to go from 30k members to a staggering 2.5 Million+ and not even feel blip within 3 months, like we did here at Jet from the end of July to October. That’s powerful!"
Wings3d.com is written in Erlang, a functional programming language. Additionally any business that scales will be using functional constructs, because they parallelise trivially. Google uses MapReduce for instance. Visual Studio rewrote their compiler to use immutable constructs, and so on.
You can do functional programming in many languages. Using functional programming or having a "success story" with it doesn't mean you need to use "functional only" -language or Scala.
For example: I've been developing for the last 3 years for the iOS and we been using FP and FRP almost everywhere with different teams and companies. Compared to the standard OO or Apple -way of doing things we have been able to make much better tests, stability/maintainability of the apps has increased etc.
Facebook/WhatsApp is using erlang for their messaging backend. Erlang itself was invented at ericsson labs, they are one of the biggest suppliers of telco backend equipment.
The Quant firm Jane Street uses Ocaml and built Core [1], an alternative to the Ocaml standard lib. I wouldn't be surprised if their business domain benefits from FP.
Also demonware [2], which is owned by Acitivision/Blizzard and manages online game lobbies for all their titles (ie Call of Duty series across all platforms), uses Erlang. They switched from C++ to Erlang before Call of Duty Black Ops was released. They said if they hadn't decided to switch before the release the company would have never been able to handle the 5 months of user growth the game brought to their platform [3].
Plenty of people use functional languages in the wild, though sometimes, like Jane Street, they don't do it for the same reasons that are normally stated as being the reasons functional programming is better.
This is a good video, from Jane Street, on why they use OCaml:
I have read a lot of articles about learning functional programming to make you a better programmer with conventional OO or imperative languages - but this does not make sense to me.
The argument is "learn these concepts that are not available in other languages to make you better at those languages". Can anyone explain?
Broadly speaking, imperative programming allows one to start coding a solution before one understands the problem.
Functional programming is generally more abstract in its approach to modelling the problem. If you get the model wrong, you will not end up with a working solution, forcing you to rethink your model.
While imperative programming allows you to reiterate towards a solution as you start to understand the problem better as you work towards it, it's obviously better and faster if your initial model of the problem is more accurate.
Functional programming forces you to create a viable model of the problem before you start. If you can extend that discipline over to an imperative language, you will need less iteration and the resulting solution will likely be more elegant.
The argument is not (or shouldn't be) about concepts, but about paradigms and discipline.
I think the most apparent example is that people recognize patterns like `fold` and `map` everywhere once they've seen functional programming.
This can be implemented in any language I guess. Most often you'll see explicit & imperative loops being refactored to shorter, descriptive code with anonymous functions, folds, filters and maps
Many people doing OO have trouble structuring their classes, splitting functionalities and responsibilities properly.
OO kind of lets you do anything you want, allowing you to store data anywhere and having any kind of flow you want. It's very easy to do something that "just works", and while there is a lot of value in that, you can keep bad habits for very long.
FP is a lot more constraining, and will force you to adapt how you think to fit said constraints.
Having to think differently offers a different perspective on code architecture, that will eventually give you ideas applicable beyond FP languages.
A quick example that can be faked in any language is a pure function [1]. The functions only inputs are the set of arguments, and from those arguments returns a side-effect free result. A pure function is easy to test and easy to reason about.
Contrast a pure function with an impure function that uses an objects internal state plus the arguments passed in to further tweak the state an/or return a result. It is immediately obvious the second is much harder to test and reason about. It becomes even more challenging when the object is thrown into a large system with a lot of moving parts.
Even before I really started learning about true functional programming, I had been writing 'pure' functions for years because they just made sense. Even internal private methods are simpler as pure functions. Shared state is evil for many reasons and should be avoided if possible.
Working with functional languages has made me value and seek out simplicity in my code. Before I write a loop or create another class I'll often ask myself if there is a more simple way to solve the problem - and oftentimes there is.
You can take those concepts and use them in your designs in languages where they're missing, even if you don't use FP or logic languages where they're "native".
Does anyone have a solid place to start with functional programming? Don't really care too much about the language it's associated with but would really like to jump into learning the concepts behind it.
> If a company hires software engineers, there’s a good chance that critical parts of their business exist in the form of computer code. Therefore the growth of that business is closely linked to the maintainability of that code. Businesses adapt and grow constantly, they perpetually change. New features and new offerings to customers are added every day. Existing features are revisited, strategies are revised, whole business models are pivoted.
There are advantages to functional programs, but I wouldn't say they're any easier to change than imperative programs. In fact, it's often more work to change a program where all functions depend purely on their arguments. Instead of adding a single imperative state update, you have to add a new argument to a whole group of functions and thread state through them appropriately.
(And besides, most functional programming languages apart from Haskell support mutable state (e.g. ML ref cells, Scheme set!) -- pure functions aren't fundamental to the functional paradigm.)
I wish someone would one day write a more objective article, such as "Why some aspects of functional programming are useful while some other aspects are an inconvenience to produce good code".
i'll say on any post here that's even slightly related: learning functional reactive programming (in my case via Bacon.js) improved my code, and my thinking about code, by orders of magnitude. Now, the only bugs are related to me not fully understanding/encoding the business logic and i can make complicated changes with extreme confidence, and as you can see i'm eager to tell people about it.
Functional programming is here already and even in OOP languages. What really matters though - is why we should be using languages like Clojure, Haskell, and Ocaml.
This misguided blogger thinks that object-based programming is necessarily about members and inheritance. It isn't. It's about message-passing and uniform interfaces and bundles of state and behavior. It's about ravioli code and modules and separation of concerns.
[+] [-] msimpson|9 years ago|reply
This isn't the best analogy as functional and imperative languages are both often used in a procedural fashion. If I simply replaced "global state" with "immutable arguments", this analogy fits functional programming as well. The fact that the arguments would be copied, however, would be implied.
> Each step needs to change, rotate, massage the workpiece precisely one specific way, so that it is prepared for subsequent steps downstream. Every step downstream depend on every previous step, and their order is therefore fixed and rigid.
This is more about tight coupling than imperative vs. functional paradigms. In general, imperative methods can be just as loosely coupled as functional methods. It basically comes down to what sort of data you're handling.
> Because of these dependencies, an individual computational step has not much use and meaning in itself, but only in the context of all the others, and to understand it, one must understand how the whole line works.
This, again, can be true of functional languages as well. You cannot always guarantee that a method is individually useful given the data at hand.
[+] [-] austincheney|9 years ago|reply
If you need to compare functional programming against something contrast it against OOP, which is a different architectural approach.
[+] [-] developer2|9 years ago|reply
Exactly.
The most common ELI5 definition of functional programming I get from other developers is that you're piping multiple statements together into a single chain of processing [input(s) > multiple levels of processing > output(s)], without having to explicitly declare variables to hold the temporary inputs and outputs between each sub-statement within the chain. I know just enough to understand that this isn't the "proper definition", but that workflow is true enough that it's what many people associate functional programming with.
The problem with that particular definition is that it tries to make the primary benefit of functional languages seem to be this piping/chaining mechanism. Yet these languages are still written procedurally, executing multiple such pipes in sequence. You still have variables holding the inputs and outputs of each chain, so you can pass them to other unrelated chains. It reduces the overall number of statements and the manual variable/memory management required, but each statement is simply a compressed version of multiple statements merged into one, enforcing "fake immutable" variables for the inputs/outputs within the chain. You don't really have "immutability"; you simply have automatic variable management between sub-statements in a chain.
Now, show me a functional language where the entire program is written as a single piped chain, and I would classify that as its own genre. Literally, the entire program would have to be written top-down as a single block of code that chains every single required input from the top-level, all the way down to a single output, without using a single explicitly declared variable. Only the first line of code would be unindented at the first column, with all other lines having to be indented as part of that primary block. Now that would satisfy me as being "unique" or "different than procedural".
What is the primary metric of a functional language? Is it to write write golf code[1] that folds 10 "procedural statements" into a single 3-line "functional block"? To me that's not "functional programming"; that's just writing less code by chaining multiple operations into smaller blocks, reducing the complexity of having to explicitly declare more global or widely scoped variables.
Random thought association: is perl's well-known Schwartzian transform (@sorted = map { ... } sort { ... } map { ... } @unsorted), applied as a concept to an entire language, what makes a "functional language"? To me, that doesn't seem like enough of a scope change to warrant a different language "type".
[1] https://en.wikipedia.org/wiki/Code_golf
[+] [-] patrickmn|9 years ago|reply
It's true that abstractions in functional languages can seem foreign and hard to understand, but generally they have some purpose, being grounded in mathematical practice. OO abstractions and patterns OTOH, taught essentially in "elementary school" which possibly makes them seem easier to understand, do a very poor job of solving more problems than they create.
Learning a functional language is often a transformative experience that lasts throughout a career, whether you even use functional languages or not. It might make you do something as simple as partitioning which functions have side effects and which don't, even if the type system doesn't enforce it. Or use a form of quick/fuzz testing, even if it's not the standard test suite. Or make parts of the data immutable for scalability, auditability, etc. Or...
There really are few things as satisfying as developing a large codebase in a functional language. A lot of the frustrating maintenance work just goes away. But even if you don't, functional principles can yield similar benefits in imperative languages.
[+] [-] zinxq|9 years ago|reply
Google primarily uses C++/Java. Facebook: Hack. Twitter tried Scala and as far as I know, abandon it and went to Java. LinkedIn definitely tried Scala, failed, and went to Java. Square is Ruby/Java.
I'd like to have something to point to as a success story of a company at scale with functional programming. Anyone know of one?
[+] [-] random314|9 years ago|reply
This is incorrect. One of the former VPs said he would not use Scala. Twitter uses Scala massively and has published and continues to maintain several open source Scala projects.
> LinkedIn definitely tried Scala, failed, and went to Java
This is incorrect. A newly hired VP insisted on moving the front end from Scala to Java. In the offline backend stack Scala is used extensively. Check Kafka, Samza from LinkedIn or better yet ask current LinkedIn employees.
Apart from these Spotify, Foursquare, ebay, several banks use Scala. FP is huge in financial institutions, check K/KDB+. Jane Street etc. Thats where most FP programmers work. Also verizon, jet.com and walmart.com. There are several dozen large companies using FP.
FP is mainstream now. Traditionally, it was financial institutions using some flavor of ML/Haskell. With Scala/Clojure on the JVM, Si Valley has moved into FP in a big way.
[+] [-] jorgeleo|9 years ago|reply
The reason for this pattern is because companies look for easily replaceable developers.
To get into functional you need to be good at abstracting the business domain, this requires seniority which is hard to find. Most of the time, when you are working using functional programming you are implementing the business vocabulary. Entry level developers are not good/interested in this. Their worries are in how they can use Angular 2 in this project, or why we need to still use SQL Server instead of converting to {insert the newest database technology}.
It is easy to find (and replace) junior developers that are happy because they created something with the latest technology and it provides the immediate value intended. It sounds good, but it misses the point.
Software development in a company happens to support/enhance the business. This means that it has to stand the test of time, not only in reliability but also in adaptability. The only constant in software is that it will change. Here is where building a vocabulary that represents the business subjects pays off. Change now is a definition-change and, unless the business is pivoting, definitions rarely change; instead, they have constant adjustments. Functional shines in creating a vocabulary and having this adaptability.
Of course, you can adapt using OOP, but the question is not if adaptability is possible, it is instead how to make changes at the lowest risk.
[+] [-] matwood|9 years ago|reply
Java has had lambdas and streams for awhile now. A pretty common design pattern has also become anemic domain models operated on by groups of functions, which fits in the spirit of functional programming. Modern java can, and is used in a functional style.
On the JS side, functional concepts are everywhere. Given how heavily FB and Twitter are invested in JS, I don't think they have abandoned functional programming at all.
Finally, IMO Scala is actually a pretty poor example of a language that can be used at scale. Without a highly enforced set of rules it can quickly become a write once/read never language. I'm sure there are exceptions, but given the choice between scala and java 8+, I would go with java. Clojure may be an option though.
[+] [-] peterkelly|9 years ago|reply
https://static.googleusercontent.com/media/research.google.c...
Imperative/object oriented languages are often more practical for real-world use (MapReduce itself I believe is written in C++), however it's the ideas of functional programming that matter most. Those with experience working in functional languages are at an advantage over developers who've never had that exposure, because they have a wider range of mental tools at hand with which to solve problems.
[+] [-] rhaps0dy|9 years ago|reply
Erlang was developed for Ericsson phone switches with a large proportion of uptime.
Whatsapp also use Erlang.
[+] [-] pmarreck|9 years ago|reply
Ruby is OOP. Elixir/Erlang is purely functional (although dynamically-typed... some will prefer typed... but the results speak for themselves).
If you are a long-time developer like me and are just coming across this, this news should strike you somewhere between "astonishing" and "pure fucking magic."
Here's the deal- Paradigm shifts, most people only see them AFTER they've finished. If you want to be ahead of the curve on this one and you want to reap the benefits, go functional (Haskell, Clojure, OCaml, F#, Elm, Erlang/Elixir). Today. That is my #1 piece of advice right now. (Well, that, and to avoid Scala and Go. Scala is just too overly complicated to keep your cognitive load down as a developer, and Go... Well, the name even says it: "Go!" As in, "don't stay!" ;) Go will suffer the same long term problems that all OOP/procedural langs share, compounded by its idiotic take on error handling /opinion)
Elixir: http://elixir-lang.org/
Phoenix: http://www.phoenixframework.org/
[+] [-] dentemple|9 years ago|reply
JavaScript, for example, is ubiquitous in the industry, and, especially with the advent of ES6, can be written quite functionally. ReactJS is also widespread and can also enjoy an FP approach.
[+] [-] rdtsc|9 years ago|reply
I personally find it much easier to navigate and fix bugs in an Erlang code base than in the equivalent C++/Java/C# one. It mainly boils down to how state is updated. When I see NewState = update(Value, State) it is clear what is happening. In OO code, I usually need to remember what object inherits from, what are is the instance state so far (what other members have been called) and how it got there. I find that much harder to handle, for example.
[+] [-] BaronSamedi|9 years ago|reply
[+] [-] plinkplonk|9 years ago|reply
From the article "in this case for massive distributed systems Functional Languages are the right tool ...
Immutability at scale is really important because it allows you to go from 30k members to a staggering 2.5 Million+ and not even feel blip within 3 months, like we did here at Jet from the end of July to October. That’s powerful!"
[+] [-] noelwelsh|9 years ago|reply
[+] [-] hacker_9|9 years ago|reply
[+] [-] illuminati1911|9 years ago|reply
For example: I've been developing for the last 3 years for the iOS and we been using FP and FRP almost everywhere with different teams and companies. Compared to the standard OO or Apple -way of doing things we have been able to make much better tests, stability/maintainability of the apps has increased etc.
[+] [-] maze-le|9 years ago|reply
[+] [-] andrzejsz|9 years ago|reply
[+] [-] marnett|9 years ago|reply
Also demonware [2], which is owned by Acitivision/Blizzard and manages online game lobbies for all their titles (ie Call of Duty series across all platforms), uses Erlang. They switched from C++ to Erlang before Call of Duty Black Ops was released. They said if they hadn't decided to switch before the release the company would have never been able to handle the 5 months of user growth the game brought to their platform [3].
[1] https://github.com/janestreet/core [2] https://www.demonware.net/ [3] https://news.ycombinator.com/item?id=14120506
[+] [-] haskellandchill|9 years ago|reply
[+] [-] tombert|9 years ago|reply
[+] [-] jackmott|9 years ago|reply
This is a good video, from Jane Street, on why they use OCaml:
https://www.youtube.com/watch?v=kZ1P8cHN3pY&t=109s
[+] [-] Insanity|9 years ago|reply
[+] [-] 0xdeadbeefbabe|9 years ago|reply
[+] [-] divs1210|9 years ago|reply
[+] [-] neukoelln|9 years ago|reply
[+] [-] mattferderer|9 years ago|reply
[+] [-] joneholland|9 years ago|reply
[+] [-] sandGorgon|9 years ago|reply
[+] [-] munchor|9 years ago|reply
[1]: https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...
[+] [-] bischofs|9 years ago|reply
The argument is "learn these concepts that are not available in other languages to make you better at those languages". Can anyone explain?
[+] [-] craigsmansion|9 years ago|reply
Functional programming is generally more abstract in its approach to modelling the problem. If you get the model wrong, you will not end up with a working solution, forcing you to rethink your model.
While imperative programming allows you to reiterate towards a solution as you start to understand the problem better as you work towards it, it's obviously better and faster if your initial model of the problem is more accurate.
Functional programming forces you to create a viable model of the problem before you start. If you can extend that discipline over to an imperative language, you will need less iteration and the resulting solution will likely be more elegant.
The argument is not (or shouldn't be) about concepts, but about paradigms and discipline.
[+] [-] stabbles|9 years ago|reply
This can be implemented in any language I guess. Most often you'll see explicit & imperative loops being refactored to shorter, descriptive code with anonymous functions, folds, filters and maps
[+] [-] ht85|9 years ago|reply
OO kind of lets you do anything you want, allowing you to store data anywhere and having any kind of flow you want. It's very easy to do something that "just works", and while there is a lot of value in that, you can keep bad habits for very long.
FP is a lot more constraining, and will force you to adapt how you think to fit said constraints.
Having to think differently offers a different perspective on code architecture, that will eventually give you ideas applicable beyond FP languages.
[+] [-] matwood|9 years ago|reply
A quick example that can be faked in any language is a pure function [1]. The functions only inputs are the set of arguments, and from those arguments returns a side-effect free result. A pure function is easy to test and easy to reason about.
Contrast a pure function with an impure function that uses an objects internal state plus the arguments passed in to further tweak the state an/or return a result. It is immediately obvious the second is much harder to test and reason about. It becomes even more challenging when the object is thrown into a large system with a lot of moving parts.
Even before I really started learning about true functional programming, I had been writing 'pure' functions for years because they just made sense. Even internal private methods are simpler as pure functions. Shared state is evil for many reasons and should be avoided if possible.
[1] https://en.wikipedia.org/wiki/Pure_function
[+] [-] disease|9 years ago|reply
[+] [-] Jtsummers|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] jackmott|9 years ago|reply
Have you noticed that these articles almost never do?
they have argument from authority and anectdote. Language research is still in the phase of bad humors and blood letting.
[+] [-] crush_xc|9 years ago|reply
[+] [-] panic|9 years ago|reply
There are advantages to functional programs, but I wouldn't say they're any easier to change than imperative programs. In fact, it's often more work to change a program where all functions depend purely on their arguments. Instead of adding a single imperative state update, you have to add a new argument to a whole group of functions and thread state through them appropriately.
Patterns like monads and monad transformers can make this easier, but massive stacks of monad transformers have their own issues (http://blog.ezyang.com/2013/09/if-youre-using-lift-youre-doi...).
(And besides, most functional programming languages apart from Haskell support mutable state (e.g. ML ref cells, Scheme set!) -- pure functions aren't fundamental to the functional paradigm.)
[+] [-] hota_mazi|9 years ago|reply
[+] [-] disantlor|9 years ago|reply
[+] [-] jorgeleo|9 years ago|reply
https://www.infoq.com/presentations/Simple-Made-Easy?variant...
[+] [-] aglavine|9 years ago|reply
[+] [-] iLemming|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] BuuQu9hu|9 years ago|reply