IEEE asked me to write an article on Functional Programming… it’s geared to CTOs like me, so it’s light on FP details and more geared toward larger picture, business issues: Why Functional Programming Should Be the Future of Software Development - IEEE Spectrum
6 Likes
What other features did you think of mentioning/explaining that you ultimately chose not to include? I’m a bit surprised that your article doesn’t mention Algebraic Data Types.
2 Likes
The article had a word limit so I had to pick and choose.
Also I was trying to aim it to CTOs by focusing on the benefits that affect the bottom line. Not all CTOs keep their hands in code like I do. But we all worry about business efficiencies, budgets and ROI.
FP has 2 major problems, barrier to entry, which I hope my book helps to mitigate, and decision makers are ignorant of the benefits.
My goal in this article was to try to convince the decision makers, who are usually more business-oriented, by appealing to the things they value. If the decision makers believe that they will benefit from adopting a technology, more developers will get the chance to move to that technology.
At least that’s my theory and was my intent. Hopefully, I did something to educate and tip the scales in FPs favor.
6 Likes
I love this article, you hit exactly the right points. This is the most persuasive case anyone has yet written for adopting functional programming. I followed you on Twitter so I can retweet this as soon as you post it.
1 Like
This short promo copy from Platonic Systems is also good. Functional Programming | Platonic.Systems
2 Likes
This GitHub post is also good, but not as clear and succinct as yours. Functional programming is finally going mainstream · GitHub
The original FP polemic by John Backus has stronger prose than your article. I like Backus’ undisguised contempt but 50 years ago his prescription was much less clear than yours. He didn’t yet have a clear idea of what FP was. https://dl.acm.org/doi/pdf/10.1145/359576.359579
1 Like
@cscalfani Great article. A little bit of history, motivation for FP, etc. Congrats are in order.
We started down the road of adopting functional languages three years ago, beginning with another pure functional language called Elm because it is a simpler language. (Little did we know we would eventually outgrow it.)
Would you care to expand a little more on this? In which ways did you outgrow Elm? What were the initial assumptions that adopting Elm would be more appropriate than, perhaps, PureScript? And what was the solution (if one was actually required)?
2 Likes
There are many things about Elm that make it a great learning language but not a great production language. I can’t list them all here, but I’ll try to touch on as many things that come to mind and not in any particular order.
Elm Architecture
The biggest problem with Elm is that the language is coupled with it’s Architecture. It’s sort of like the old Henry Ford quote, “You can have a Model-T in any color as long as it’s black”. You cannot divorce Elm from it’s architecture. It is this architecture that doesn’t scale well at all.
In PureScript, you can use many different libraries include one like the Elm Architecture. We use Halogen and have built quite an extensive component library. The ability to maintain independent component state is really great.
Comparing this with Elm and you’ll find that state for any “component” leaks. Everything is global state. Yes, it’s still pure, but the state is EXPLICITLY passed to EVERYTHING all of the time. This seems fine for simple and small applications, but does not scale.
Decoders and encoders
When I wrote an API in a Haskell server, I wrote about 4 lines of code to create the encoders and decoders. If I had written this in PureScript, it might have been 12 lines of code.
Those same encoders and decoders in Elm were over 700 lines of code.
Typeclasses
Too many times we’ve need to have a Eq instance of for a Data Type that we defined in Elm. There is NO support for this. If it’s not a small handful of Types that come with the compiler then you’re SOL.
There’s not even an escape hatch so you can hack something together. (There actually is if you’re one of a select few who have access to elm/experiment or whatever it’s called). This means that you CANNOT have your Type as a key in a Dictionary.
No Private Libraries
There is zero support for private libraries. You can put your libraries in Github, but not a private Gitlab server. And there is no hope of future support of this.
No runtime crashes
Elm purports that it has NO RUNTIME CRASHES. Well, just try to compare 2 records that have a field that’s a FUNCTION. It’ll crash every time. Looking at the comments in the code where the crash code is called, it appears that Evan planned to return to issue in the future, which leads me to my next issue.
The Doubtful Future of Elm
I posted over 2 years ago on Reddit asking if 0.19 was the last version of Elm (https://www.reddit.com/r/elm/comments/habwwd/is_elm_019_the_last_version_of_elm/) and I’m afraid I was right.
There are no fixes for Elm bugs and no one is working on the compiler. Yes there is a community of people writing Elm code, but there is no leader or group who’s responsible for moving the technology forward like there is with PureScript.
When Phil Freeman left that position, he had in place a group of talented and dedicated people to take over moving PureScript forward. Evan had his inner circle, but he still was the only one who called the shots. It wasn’t a democracy. Evan has gone AWOL and his band of merry men have been scattered by the wind.
Richard Feldman is working on his own FP language. I suspect his hopes are to replace Elm at NoRedInk someday. I don’t know the whereabouts of the others, but I suspect they’ve all moved on to other things.
I am responsible for over 250K lines of Elm code in production ATM and I fear a future change in the browser that breaks Elm. Right now, ANY Chrome extension that mutates the DOM will crash an Elm app and there is no hope that anyone will fix that bug in the VDOM.
When we moved to the M1 Macs, you couldn’t install Elm because M1 didn’t exist when 0.19 came out. Luckily, there’s a patch that someone made to make it installable. I can’t remember if there’s a native version of the compiler or if you must run it under Rosetta 2.
These are just signs that Elm’s age is showing and it’s only a matter of time before it breaks beyond repair. I don’t want to be responsible for that codebase when that happens and I’m doing all I can to prepare the company to rewrite the application in PureScript.
I would advise anyone who will listen to not embark on any Elm production projects.
Hope this answers your questions. Let me know if it does not.
11 Likes
@cscalfani Thanks for the very detailed response. It answers more than I could have wished for.
All the things you pointed out are of great import. I’m actually a little shocked.
3 Likes