So... Is functional programming the next big thing, or is it just something that's gonna vanquish soon...

So... Is functional programming the next big thing, or is it just something that's gonna vanquish soon? It seems to me like it's going to be a big turning point in the programming world. What does Sup Forums think about it?

Other urls found in this thread:

en.wikipedia.org/wiki/Determinism
en.wikipedia.org/wiki/Monad_(functional_programming)
wiki.bluespec.com/
twitter.com/SFWRedditVideos

I enjoy F#, but there is no way my team/enterprise will embrace it.

It's a useful style of programming thats existed for a bajillion years. Its just gaining a lot of attention because of hipsters.

it's gaining attention because if your systems are sufficiently formalized you can automatically generate tests or detect bugs/security flaws

FP is catching on like crazy right now, but the thing is that we're not even at peak functional programming yet, there's a lot of concepts that are still only barely catching on in popular languages. I think it still has a ways to go before it "peaks" and only then will we see if it's just hype or if it's actually here to stay.

is right that most functional programming concepts have been around for a long time and people have just ignored them, but a lot of type theory and category theory has only recently been realized by actual programming languages. Also, there is tons of academic shit that gets published as papers but never sees the light of day, will people dig those papers up and realize they're actually onto something? Who knows.

"The computer revolution hasn't happened yet" - Alan Kay

Can someone explain to me what functional programming is?

it sounds like it's just about passing function pointers around, but there's got to be more to it than that with all the self-congratulatory wankery about the elusive "monad" and all the other bullshit I don't understand and am not sure about whether I need to understand it.

Programming that's actually functional rather than just boiler plate code.

functional programming has little to do with pointers, you can write a functional system on a piece of paper using category theory or lisp or whatever other higher order function system and implement it straight on hardware, the core idea behind functional programming is Determinism

en.wikipedia.org/wiki/Determinism

functional programming's goal is eliminating "boilerplate" code and knowing exactly what your system will be doing given its parameters, defining the consequences and constraints of a system in a way that can makes automation easier and encourages code reuse

the original invention of compilers was a functional way of addressing low level hardware programming, the invention of programming languages was a functional way of making it easier for humans to read and write code, and there a different ways to approach functional programming that balance human readability against formal definition

but basically, if you're not programming is some sort of functional mindset you're going to end up not reusing code properly, writing unnecessary code, your programs will be harder to automatically test, or your programs will have undefined behavior

the lambda calculus is one way to do this, encourage human readability and you end up with Lisp, encourage more rigorous specification and you get Haskell, though any mathematical formalism for specifying code that takes into account the algebraic constraints of a program is a form of functional programming

Is it worth learning functional programming than? I'm currently on college for Computer Science and I'm trying to learn new things and trying to trace a professional path, so my question actually is: is it possible to make a living with FP? And if so, is it the same as "common" programming paradigms?

>is it possible to make a living with FP?

some day it may be impossible to make a living /without/ using FP, it is an exponentially more robust way of specifying systems

I am a freelance software developer and use functional programming for all of my projects, and in my previous salaried or contract position used functional programming to automate my work or fix shoddy imperative implementations

>is it the same as "common" programming paradigms?

even imperative languages are converging towards functional programming techniques, pretty much every "new" feature added to more common languages is a shoddy implementation of a functional programming concept, ie C#/Java/javascript have lambdas/closures/higher order functions

Not just lambdas, if you look at e.g. C# async/await, it's basically just monads, same with Java Optionals and Streams. In the last few years we've seen every single language add lambdas because they are obviously extremely useful. I predict that in the future monads will be the next functional feature to catch on. When people become more accustomed to programming functionally generically and w/o side effects, the idea of monads should be easier to grasp.

can you try to explain what a goddamn monad is?

you say async/await/promise etc is basically a monad, but is it? every other source talks about type, and those have nothing at all to do with type

en.wikipedia.org/wiki/Monad_(functional_programming)

Monads are hard to explain because they are intentionally an extremely high level abstraction

A monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.

how about this you fucking mongoloids:

a monad is a class that contains a method which accepts a function as argument, and applies that function to its fields.

IS THAT SO FUCKING HARD?

I don't "get" functional programming
Can someone point to a basic way to help?
Lisp looks cool

I'm learning fp with scala and I don't get clue about functional architecture. Are there any patterns like in oop? Why in books about FP they're using classes? Are there classes and objects in FP? How does typical program written in FP looks like from point of architecture? Is it just functions and definitions of data structures for it(so it looks like procedural code)? Can there be functions in data structures?

Learn you a Haskell for great good or programming in Haskell
Lisp is alright but isn't really a "functional" language, just a multiparadigm language that lends itself to functionality

LISP dialects and Haskell/ML/etc. are completely different things. LISP is good because of "everything is defined by (function ...)" and meta-programming, the others are for great because of their powerful type systems.

Yes, biggest project I wrote was a front-end in PureScript and it looks pretty "procedural" from the bird's eye view. Each file defines some data types and functions that work on these data types... and then you have some logic in your main function glueing it all together.

So no objects? Simply functions and data structures like in procedural programming but just with immutability, hof n sheet?

>class
>method

check out this idiot

this is not a correct definition

if you think about objects and classes long enough you realize they're just lists or lists of lists

functional programming does not require immutability but it does benefit from it

there's no way a majority of 'programmers' out there will be able to handle this.

No fucking wonder Sup Forums loves it.

Yeah, and then you use all the stuff Haskell type system offers to build abstractions.

OCaml is another story, they have modules and objects that are very OOP-like.

Your post explaining functional programming was barely fucking readable, i highly doubt it produces more readable code than object oriented design.

Sounds really really easy to fuck up...

The "method" is not even a method. It exists outside the "class" and is related to it only by its signature.
So yes, that was fucking hard.

This shit will never catch on desu. Its only for self employed developers or those on the spectrum.

So what's the key point? Where is border between functional and procedural code? I can see this difference in oop

Mostly right from a theoretical perspective.

But for me, practically, thinking about writing programs in a functional style encourages highly understandable, testable, and therefore durable code.

A function should do one thing well. A function should not have more than a couple lines.

Show me a beautiful piece of code that isn't simple. It doesn't exist.

t. horse breeders right after the invention of the automobile

I think OOP languages will continue to absorb features from functional languages rather than functional languages becoming popular.

it's normal programming except the goal is for it to work like math.

You don't keep track of where the program is.

Instead, you define things and think of them as mathematical definitions.

It is made with the type of autist who likes generating functions and recurrences and number theory and shit in mind.

You would learn a language like Haskell for fun and never make a penny off of it.

>object orientated
>readable

o i am laffin

> So... Is functional programming the next big thing,
It's one of the big things going forward, not "the next" big thing. It'll probably be relevant until we stop using multi-core or distributed systems or come up with a fundamentally new way to using them somehow.

But it's almost more pic related that is used in production than Haskell.

> It is made with the type of autist who likes
... running a program across more than one machine or more than one core.

That's the actual big thing driving adoption now, not the concern for correctness or even the natural reuseability that functions have (you can't really go wrong with taking pure functions "out of context", they work everywhere).

What papers senpai? I really want to read them but all I know is staring at the sci hub search bar...

Functional always returns a value, never changes it. Using functions. Any tacos

>the goal is for it to work like math

in the sense that math is reliable and easier to automate yes, are all functional languages exactly like Haskell or Coq? No, in Lisp the core element is the s-expression, in Erlang the core elements are messages and processes

>You don't keep track of where the program is.

In proper, systems critical functional programming you DO keep track of program state, but yes, in beginner haskell tutorials you aren't juggling placeholder variables

>It is made with the type of autist who likes generating functions and recurrences and number theory and shit in mind.

You do not need to be an autist to understand functional programming, if Haskell seems too difficuilt for you to understand, Lisp is a language that combines both imperative and functional techniques that serves as a good introduction to functional programming.

>never make a penny off of (functional programming)

I'm 23 and I'm self employed doing functional programming. In my previous positions (been doing professional programming since I was 16) I used functional programming to automate everything and fix issues in imperative systems.


functional programming won't stop being relevant until AI systems can traverse the formal spaces of functional systems automatically and make all of our programs for us based on neural inputs

In Lisp you can create functions that return other functions, but also change the state, there are many gray areas in functional programming.

I think the defining characteristic of functional programming are immutable data, just like mathematics which is static and immutable
Q: Given x = 1 + y and x = 2, what is the value of y?
A: y = x - 1 = 2 - 1 = 1
Test: 1 + y = 1 + 1 = 2 = x

In imperative programming data can change in anytime
x := 2;
y := x - 1; // y == 1
x := 1; // because we can and data is not immutable as it should
(1+ y == x); // FALSE, because x mutated
;
This data immutability along with all the mathematics unlocks interesting qualities, like functions returning functions (see functional analysis), type inference and polymorphism and operator overloading that makes sense (in mathematics you don't deal with trivial shit like types, you just define +:X x X -> X and *:R x X -> X, where X is a set), lazy evaluation (being able to define infinite arrays and treating them like they are calculated even though they are not because they are immutable, just like mathematics) and using recursion and pattern matching (like mathematics) instead of iteration and loops.

Sure, but functions are just another value, as for changing states, I suppose most languages aren't pure anything.

Well, both functional languages and procedural languages have structures modelled on mathematical functions. Where they differ is in how far they take the analogy - procedural languages have intermediate values and are made up of multiple steps, and a functional language function is simply a map of input values to output values without intermediate steps..

Functional programming is characterised by lots and lots of recursion. There's nothing else.

Next big thing since 1950.

functional programming has been around since before the paradigms we use today you retard

>functional programming won't stop being relevant until AI systems can traverse the formal spaces of functional systems automatically and make all of our programs for us based on neural inputs
That would still mean functional programming remains relevant.

You are talking about current humans becoming obsolete, not FP.

You are thinking functions in the bastardised way imperative programming languages taught you and not in the pure mathematical way.

Mathematical functions are objects that describe (not calculate, nor return) how each object of one set correspond to objects of another set. Functions don't mutate anything, they just exist. If you don't understand the properties of a set you just select (select, not create, in mathematics you don't create anything, you just select things from all those that exist) a function that corresponds objects of the unknown set to objects of the known set and eventually you uncover the properties of the unknown set.

The state never changed. Even when the set was unknown the properties of it were well defined and static and they never changed, you just discovered them.

Programmers think they are inventing stuff, creating things the didn't exist before, while mathematician know they discover stuff, things that existed long before them and will exist long after them. Mathematics is all about immutability and never changing state.

>literally can't write an in place algorithm

> in mathematics you don't deal with trivial shit like
a properly defined syntax. Mathematicians wasted each other's time for centuries with that one, particularly when you didn't stay within one or another field only.

Only now that computers will block your path on ambiguous definitions (including types) for which you should just pick the better one we actually get an increasingly (but not yet completely) sane syntax for maths in programming languages.

Should have been done ages ago, though.

It's neither the next big thing nor is it going to vanquish. It's always been very useful in many situations and will continue being, just because of its simplicity, conceptual stability and mathematic approach familiar to anyone decent in maths.

>Mathematics is all about immutability and never changing state.
BS. Very standard maths has variables.

Even if mathematicians very often take the functional approach to describing things, it's not always the case by any means.

>Very standard maths has variables
The variables in math don't change. They are pure and not the ugly mutable things imperative programming language variables are.

When the professor asks you "what is the value of x" you don't change the value of x. x is well known before even you show the problem. What the professor really ask you is to correspond x to a value from the set of numbers.

> The variables in math don't change
They do. You are completely allowed to change a variable inside a function based on an argument to the function or whatever.

That is the same shit as with imperative programming. Elevating conventional maths to being actual FP makes no sense. It is not.

lol

>You are completely allowed to change a variable inside a function based on an argument to the function or whatever.
Nobody does this.

>You are completely allowed to change a variable inside a function based on an argument to the function or whatever.
Once a variable is bound it can't be bound to another value. Keep in mind that a function is just a template for creating an expression, f(1) and f(2) are different entities.

Yes, they do. Both physicists (...ultimately the co-authors of maths 'cause valid standard maths is ultimately designed to always work in actual reality) and mathematicians.

Give me an example.

>'cause valid standard maths is ultimately designed to always work in actual reality

Has already happened . See how this is even something where "i" is reassigned a different value after the initial number 1?

Anyhow, happened a lot of times at uni too, but I no longer have these notes.

The i is bound to different values in different sub-expressions. It's not the same i, it's "scoped" differently.

>Is functional programming the next big thing, or is it just something that's gonna vanquish soon?

It's not the next big thing but it's a nice tool for some problems. And it's not so good for other problems.

Basically functional programming is good when you have fixed "things" and want to easily add "operations" on them. If you add new things, you have to painfully rewrite function definitions.
OOP is good when your operations are fixed and you want to add "things" (with different states) easily, i.e. OOP is much better for programming games. But when you want to add functionality to things, it's often pretty difficult and you have to use interfaces, mixins and/or editing many class definitions.


There is no clear definition for all programming languages. But it's centered about the thought to reduce mutable data (you will always have mutable data, i.e. all I/O is mutable).
This is to reduce "stateful" programming as much as possible.

In "real" functional programming you have no control variables, but things like iterators and generators. Many things are similar, but the way you look at it is slightly different.


Say you want to reverse a string. You can't change strings. But a string is only a list of chars. And you can rearrange those list elements. So mr. Monad comes, breaks this list into char pieces, rearranges those pieces backwards and glue them to a list again. Then we have another string.

Monads are like reachers which enable you to look at "things" in a certain way.

I'm very new to this. I have worked with some 'normal' programming.. Gotten used to classes and how they work, inheritance and such..
I looked for 'lisp' and there are a lot of different versions.. I would like to learn functional programming, where should I start?

This guy is right:
The big difference is, that "normal" programming everything is always a function of time. So you can stop at a given momment and ask: "now what is the value of x RIGHT NOW".

In math everything happens at the same time. Even if you include "time" as a variable t and integrate over it, you don't walk along this line and sequentially raise the value. No, you add everything "at the same time", so to say.

OOP is pretty much only good for giant inefficient corportations that operate on a monkeys-on-typewriters business model and need to prevent incompetent but cheap labor from shooting each other in the foot. In the modern sense, at least; I doubt Alan Kay had Java in mind.
That said, non-functional programming that isn't OO is still usually more versatile than FP.

read sicp

This is the typical writing of functional fanboys that think there is a silver bullet in computation, a "one size fits all" solution. But there isn't.

For some problems a lambda calculus language is just terribly cumbersome while a turing machine handles things much more gracefully.

Let's be honest:
A microprocessor is a stateful thing. You have flags, even flip-flops are basically statefull. At the lowest level your beautiful Haskell programm turn into ugly assembly full of GOTO statements.

I'm not saying functional programming isn't a usefull abstraction, but it's only an abstraction. Look at it like a tool, not like a religion.

>A microprocessor is a stateful thing. You have flags, even flip-flops are basically statefull. At the lowest level your beautiful Haskell programm turn into ugly assembly full of GOTO statements.
Circuits are functional. A transistor implements a pure function. Logic gates are purely functional. Clocks and registers are imperative abstractions over functional constructs.

Enjoy your clockless registerless cpu,

This desu. Still waiting for functional fags to show me some fast and efficient numerical algorithms dealing with matrices and similar.

I'll enjoy my clockless registerless FPGAs. The turing machine isn't as fundamental as you think.

>Is functional programming the next big thing
>next
Uhm, functional programming was big in the 50s and 60s and have somewhat faded into obscurity now.

>or is it just something that's gonna vanquish soon?
It's never going to go away, since many FP concepts are unironically good.

>It seems to me like it's going to be a big turning point in the programming world
The "big turning point" has already been around for some 20 years. All modern multi-paradigm programming languages incorporate functional concepts in varying degrees.

>The turing machine isn't as fundamental as you think.
Yeah it's just by far the most popular model of computation.

But it all starts with the CPU. The CPU has a Clock rate. It runs through his BIOS, loads up libraries, detects hardware..
All in all a very stateful process.

FPGAs are a good example. They are purely logical. But it's better to use them for isolated problems instead of being the "master control programm" in the background.

The most successfull functional langauges are those where you can opt in to use non-functionalcode if you want to. There are only very few exceptions to this, i.e. Prolog being used in flight transfer.

Functional programming tries to avoid all side effects, and that's why it's so great and usefull:
Because it's incredibly difficult to understand all possible states of your code. OOP had to come up with exceptions getting wrapped about difficult parts to intercept "stupid states". And yes, that's hacky and unclean. But often it works much better than you would expect. Sometimes side effects are just the simpler solution.

So personally I think it's important to learn functional programming and to avoid it whenever it makes sense - but not always.

not put it in the box but put a box around it. The floor values and ceiling values are implied.

> In math everything happens at the same time.
Nope. There clearly are sequential steps in there.

But sure enough, I challenge you to show me the device or person who can "make it all happen" at the same time.

I obviously know you can't but I also already almost know it won't *ever* work because as far as we can tell, our maths is even *invalid* at scales lower than Planck time. It fails to describe anything correctly. All necessarily sequential maths ONLY works when individual steps take at least one Planck time unit.

Imperative programmers are the econ majors of compsci.

If you aren't familiar with FP, you aren't a computer scientist.

Yeah, the Church-Turing thesis isn't fundamental at all. Spotted the liberal arts major. Are you gender studies by chance?

>Nope. There clearly are sequential steps in there.

Yes and no. Math functions usually operate on sets. Even if the set are unordered or have a different order.

For example let's talk about the pic here:
What do we have? We have a function that takes an one argument (n) and returns one value: n*(n+1)/2. We have the i (which is "every number in questions") and we have the upper bound (n), but we do not have a accumulator variable. It all happens "concurrent".


This becomes more obvious when we write the sum as integral (a sum is simply a special case integral). And even more obvious when we change from Riemann integral to Lebesque integration.

In the end the formula in the pic as more like calculating an area, very unlike we would make a summation in our head. Humans can only do "procedural" math in their head.

>FP is catching on like crazy right now
It is?

Using it just for the sake of using it.

However, if you want to write something dealing with datastreams, parsers or stateless applications in general, functional languages might be better suited for your needs. For state-retaining programs they suck ass.

Fuck, I meant to write "Using it for the sake of using it is just memeing"

>s functional programming the next big thing
it's been going strong for decades, newfags are just now catching up to it

>A microprocessor is a stateful thing. You have flags, even flip-flops are basically statefull. At the lowest level your beautiful Haskell programm turn into ugly assembly full of GOTO statements.

the irony of this statement is that all the major hardware engineering firms are switching to functional specifications for automated verification

this poster is full of horsehshit

>So... Is functional programming the next big thing, or is it just something that's gonna vanquish soon?
No its not the next big thing, it is already here and the hype is fading slowly.

>It seems to me like it's going to be a big turning point in the programming world.
No, you have bad forecasting abilities. Lisp and haskell have been around since always. They are only useful for certain problems, which are not the kind of problems you encounter in the corporate world, but the ones you usually see in academia, robotics and telecommunications.

Most general purpose languages have lambdas, filter/map/reduce, and function as objects support, but these are not enough to code only in the functional paradigm, because you would need laziness and other features that you can't easily add to an existing language without breaking compatibility.

And then there are the web devs monkeying around react/redux because they think its a better way to code in JS (kek)

And this kind of shit right here is why functional programming will never catch on.

People in general hate maths.

functional programming is the top of the top. No other superior

How do you think you are gonna program all of those processors in a concurrent way. You're gonna have to use immutable datastructures goofus

with mutexes and locks

> tfw they wrote a HDL in Haskell
wiki.bluespec.com/

It's a natural fit.

My company saw a significant increase in productivity and decrease in bugs by switching to just higher order components for certain abstractions.
I'm not sure about other concepts but everyone at my company and client company are in love.

Pure functional programming, sure. First class functions, declarative systems, and composability are all common.

compiler optimizer research is almost completely functional programming these days you fool

Some classes of bugs. I bet you people will be just as stupid as the coders as far as logic errors are concerned.

if your system is formalized from the semiconductor crystal lattice up there ain't much room for bugs m8

>>>/reddit/

Pure functional programming will never hit the mainstream, it's simply not a practical paradigm.

That said lots of languages use functional programming concepts to great advantage, and this is where it has made traction.

There's a reason Haskell is only popular in academia, where you don't have to actually write programs that work, just write about writing programs which may work.

>compilers without inline assembly will never hit the mainstream, it's simply not practical

>Haskell is only popular in academia

haskell is only popular in academia because most programmers are brainlets, or lazy, experts in high speed trading, security analysis, bioinformatics, hardware architecture, AI, and just about every advanced field of systems development are adopting it

LOL, the reason Haskell isn't used outside of academia is because you can't spend a week trying to figure out the magical incantation which will make the compiler generate efficient code, inb4 'look at my fibonacci sequence'.

It's truly something which only works in academia, where you can spend two weeks on how to most elegantly avoid side effects in your code and then impress your teacher.

In the real world you need to create efficient code in a timely manner, because here development cost money.

But muh games