Feels a lot like saying “our current programming model doesn’t work anymore because everything is hard (because all the easy stuff has been figured out already), so let’s throw it all away and start over” and the circle repeats itself until we get to all the hard parts again.
in my experience, it truly doesn’t matter which paradigm you use, just pick ond and get good at it. All this talk about FP… is there really anything it actually ‘fixes’? Or is it just ‘different’? I mean come on… stating that nobody has figured out building complex apps in an OOP way. That’s just silly 
What is this, 1999 all over again?
We always do it anyway.
I’ve heard that claim for years. See also: the year of linux on the desktop
Beautiful ideology but unless universities stop teaching imperative programming languages, functional languages are never going to catch up.
Fun to read, I liked it, but reads more like a general JS tips’'n tricks. But seriously, the returning question for me is… what does “it” (is there even an “it”) fix? If the only thing is “boilerplate” than fine, but that for me doesn’t make it anything special. Boilerplate in itself is not a big deal, maintainability (e.g.) is.
I think the post is a bit a mess of buzzwords and skewed metaphores. It talks about functional & reactive like it’s the same thing, but it’s not. Meteor is mostly imperative written, but it’s reactive in the way it pushes updates to the clients.
Also, while functional programming has some really cool applications and certainly deserved more attention than it did a few years back, it’s been around for just as long as imperative ones and it’s not the answer to all world’s problems. If your current application sucks, it’s not the fault of the language, it’s your fault and it’d probably would have sucked written in functional style as well.
It’s also strange the article mentions concurrency in the title, but it doesn’t really discuss the subject in the post. Concurrency in user interfaces has been tried a lot in the past and always turned out very, very cumbersome and hard. I still think the reactor pattern with a single threaded event loop is the best approach for a user interface. And with web workers you can offload the very few long-running tasks one would have in a user interface.
It’s really the opposite these days. Imperative languages are trying to catch up by implementing functional constructs. Just look at the splash lambdas made in both java and C# to clean up anonymous delegates.
I think he meant catch up in usage statistics, not in technical possibilities.
I was discussing usage.
It’s far different this time. Look at the react explosion. It’s all coming from functional programming. The Internet was an embryo 10 years ago compared it what it is now. Hacker News and the language specific forums like EchoJS and the js subreddit have brought us all together in a way that hadn’t happened yet when we are still using php or Java. The pace at which we as programmers can congregate around a “winner takes all” programming paradigm is exponentially faster than it ever has been. Truth is functional programming already has taken off, and it’s just a matter of time before we are properly doing it in a typed functional language like Haskell or a dynamic one like ClojureScript.
If ur saying things like “just pick your paradigm” and generally standing up for OOP–if ur at all like I was before invested the time–u likely haven’t done the research on functional programming. My recommendation: do the research or stubbornly and fearfully stay in the dark. Ur just gonna feel more and more anxiety as everyone else levels up their skills while U stay clenching OOP.
In short, the business of side effects is a big deal. Eliminating them allows for whole new worlds of programming–many new opportunities. My prediction is functional programming is the basis for the visual coding paradigm of the future. Whether it’s visual or not, the next layer of our technology stack will be built on functional programming. All the platforms like Unison, Lamdu, Eve, Subtext are either built in Haskell or built in their own functional language based on Haskell. Go here real quick before you start disagreeing about the actuality of this future:
Scan to the bottom of that page and see which projects influenced it. I’ll leave it up to you to find the functional theme in all of em. In short, purity is a prerequisite for code, i.e. functions, to behave as dependable building blocks–and that’s why functional programming is the future. What’s going on with React right now getting us all to actually start using functional programming in our daily routine is the calm before the storm, or rather the little baby waves before the big ones hit. It’s the clue. Never before has this much activity behind functional programming happened. Never. If you are using react you are using the best parts of functional programming today! You are using a very precisely engineered ware designed to take the best parts of functional programming. If ur using Redux, ur implementing functional programming yourself, not just using an abstraction heavily based on it. It’s up to you if you wanna keep your eyes open and think this is just a blip not going anywhere. It’s going somewhere my friends, this is the just the beginning. How could it not? Every day, there’s something new slightly better than the last.
For those even more interested, this came out this week:
https://news.ycombinator.com/item?id=10926038
It has tons of links to projects working on the Bret Victor-inspired visual coding future. It includes the projects I mentioned above, and many more. Also, consider “visual coding” a blanket term used to describe generally coding of the future.
Anyway since Bret Victor started releasing his talks and research about 4 years ago, everyone has been working on implementing the ideas he presented. Everyone is getting closer, and one of these platforms is finally gonna hit the spot and it will be here soon. How could one not with so many separately working on the same problem. The funny thing is that Cycle.js apps likely could be built completely in a flow-based editor like http://noflojs.org ! Its creator is working on the integration. If you study Elm and then look at Unison (which is built in Haskell), it starts to become eerily clear that typed Elm apps could be visually coded like building blocks, and it wouldn’t be a toy.
In addition to everything above, I recommend you leave Meteor and go build your next app using ClojureScript and Om Next or Re-Frame. You can essentially use one language and one platform for the whole stack like you are accustomed to in Meteor. It’s of course Clojure. Their database, Datomic, is built the same guys behind Clojure and ClojureScript and Om Next. It has true first class support for subscriptions. Way better than RethinkDB, and of course way more performant than oplog hacked together subscriptions. Om Next combines the best of relay and redux into a single simpler interface for a single database optimized for subscriptions.
Lol. The functional future is here if u wanna open ur eyes. If u don’t, continue using subpar tools that cause more headaches. This stuff is better. It’s out, available and ready for ya. Learn ClojureScript today and throw OOP away. It interfaces with anything off NPM, so you don’t have the lack of ecosystem problem.
Over n out
Lol don’t lose hope my friend. The point is this: js is flexible to keep up–at least for a while–and meteor is poised to be that path. Meteor is in a unique position in that it’s one of the only unifying voices around the full stack of technologies. ClojureScript by its very nature is way more opinionated and has less options. JS is full of so many options–if there is a source that can unify and congregate around the obvious direction of the future, it stands to win big. That’s the only reason I’m still in Meteor land. If Meteor can ride the wave of this functional future well, it’s gonna do damn well for itself as well as us all. It very would could become the best option for plain JavaScript. I’ve used meteor for a long time and that’s why it’s so important to me, but I’m very worried they can pull it off. This could easily be the fork in the road where another technology more fundamentally addresses the changes of the day and rides the big wave to the finish line [to a 10 year+ lifespan like rails or jquery]. That would be sad for Meteor, given it seems to be in the midst of completely rethinking itself. Provided the winner can still exist in plain JavaScript, right this very moment is the time Meteor is supposed to get it right. They mess this one up, and we will be using something else a year from now. As it is Om Next is the path I’m taking for any future consumer apps I build.
As already mentioned - in Object you are keeping properties and functions compute results based on these properties. That is nice and such, but if something external touch these properties than you got unpredictable results.
Functional programming dont have persistent state, it is always just that 1 iteration, so when made right it should be 0 side effects, that means perfectly predictable and testable => maintainable.
As old Unix dev I always loved shell for composing small programs together where every 1 of them is doing just 1 thing but very performant and right. So pipe-ing cat/awk/sed together is functional programming - and it is with us for quite long.
You get results from first, they are OK, pipe them to 2nd program, fix issues and when u r getting ok results, pipe them to 3rd etc. And always you focus only on next small iteration. Test it with all test input feeds you have but still you focus on that small piece of logic.
With current million components per page, you cant focus on all of them in same time, you need to somehow decompose it all to small blocks.
I have recently started to work with Neo4J and when you are writing queries walking these graphs nodes and relationships, you are thinking functionally too. Find nodes with this label. Done. Pipe them to this filter. Done. Pipe it to finding all nodes which have this relation. Done. And composing these functions together to get results.
The patterns and principles of FP are usied everywhere, but Web seems to be lagging behind. Not anymore.
The 1 way flow without side-effects and with time travel functionality is debugger’s dreams. And with automatic testing you have some much higher confidence to know if you have broken something by last change.
People use node graphs to generate shaders for graphics cards all the time these days. Why not FP?
oh my. didn’t remember to check this thread. Thanks for the reply @faceyspacey. Don’t be mad, but didn’t read the whole bunch 
Don’t get me wrong m8. If you are fan of all this FP stuff, then by all means, do your magic. But don’t get evangelic about it
By the words you use, I can see your very passionate about this. Which is great. But you can call me old school all you want, but I’m fairly certain that the whole FP stuff isn’t a magic pill that will solve all world problems (in development) and make everything great. I’m sorry, that’s just not how it goes If it works, great! If people want to use something else, fine! They all have their merits. Again, pick one way and be consistent and good at it. It should all work out just fine.
Now back to the important subjects!
Ben, this is a thought-provoking comment! In my opinion, making everything easy(/hard?) by not relating to or hiding concurrency, or even refuse that concurrency is needed at the conceptual level (“all we need is callbacks and an event loop”), is throwing the baby out with the bathwater.
You are of course right about Turing: basically every paradigm can implement anything. Since this thread arose my attention 168 days after the previous comment because it had “concurrency” in the title, then that’s what I wonder about. How does the Meteor framework handle concurrency? At a possibly lower level? Or will you need opsys help? Or will react.js satisfy all the (quasi/real)-concurrency you need? By the way, concurrency always is quasi (there is a scheduler somewhere), but parallelism is true multi-core. Or are there any other obvious ways? Or is it a no-case, not in scope for the applications you’re building? The latter would seem rather strange (and interesting) to me.
I have tried to raise the question again in a new note (here). I am excited to learn what this community’s answers are.