FP is going mainstream. In the same way that mainstream OO wasn't pure OO in the manner of Smalltalk but instead hybrid languages like C++ and Java (and more recently Python), mainstream FP isn't Haskell but languages like JS (w/ Typescript), Scala, Kotlin, Rust, Swift, and friends taking core ideas from academic FP and presenting them in way that works better for industry.
I almost think the Swift/Rust approach is the right one for 99% of practical cases. In these languages I end up writing a lot of functional code, but it's important to have an escape hatch to just make the computer do what I tell it when I need to. Especially when using libraries which are not themselves functional.
The pessimist in me thinks that going mainstream means it will be less useful for screening applicants/keyword searching job postings. Sort of repeating what agile has brought us.
Those languages aren't FP though. They aren't even close. Kotlin advertises itself as 'multi-paradigm', like C++.
One reply observes they don't have pure functions which is rather fundamental to most modern definitions of an FP language. But they also use imperative flow control in which statement ordering matters, their APIs are object oriented, there's no lazyness, type inference is intentionally limited.
I don't think they've really borrowed many ideas from academic FP. Most such ideas were in fact explicitly rejected.
Tooling is such a huge factor. I'd love a functional language that had build tools as nice as rustup and cargo.
Indeed I'd place Rust as an example of a language that got it right. Sure, Rust isn't functional, but it's confusing on first usage, so close enough :D
In all seriousness, the big issue that functional languages have to get over is that most programmers are not great mathematicians, so declarative programming feels very weird and confusing. With Rust the big issue is all the rules about memory. How did Rust solve it?
For one, they made the language as familiar as possible. Rust's syntax is extremely close to C/C++, even if the semantics aren't. As much as PL people claim syntax doesn't matter, it does. ReasonML is a project with a similar philosophy.
Next, they put a lot of work into documentation and explanations, especially at the compiler level. Rust's compiler messages are fantastic and often anticipate beginner mistakes. I'd love a functional language that detects when the code looks kinda imperative and gently guides you towards the functional option.
And finally, they had a killer app like Wadler mentions. Performant memory safety is pretty hard to argue against. Even a manager could see the potential upsides. I wonder what sort of killer app one could create for functional languages? Reason with ReasonReact could have robust UI as one, but that's still not as good of a sell as performant memory safety.
Performant memory safety is not that big of a feature. GCs are fast enough unless you have real time constraints.
If have real time constraints, you probably do not care about memory safety that much, unless your system is safety critical.
If your system is safety critical, you are using lots of tooling for validation beyond memory safety - and probably some form of model based code generation. That tooling just does not exist for newcomer languages.
> I'd love a functional language that had build tools as nice as rustup and cargo.
For what it's worth, speaking from experience on Ubuntu, stack for Haskell has worked just as flawlessly for me as cargo has for Rust. (I might get some flack for this, but I'd encourage one to ignore the existence of cabal as much as possible for Haskell in 2020 and beyond.)
I think languages by themselves rarely become popular. There is some killer feature that a language offers which makes a certain class of problems very easy to solve. For example, Rails did it for Ruby, Go's stdlib makes it very easy to write performant network services, Java's promise of platform-independent code, huge stdlib and a free compiler and (later) free IDEs when almost all other compilers and IDEs were paid, C# - Microsoft's deeply integrated ecosystem, Rust's memory safety and the promise of fearless concurrency.
Functional languages are lacking such killer features which makes them 10x more productive for widely faced problems. I am learning Clojure to learn more about the functional paradigm, but I don't see any particular type of software that I could do with it which I couldn't achieve with Java, Go, JS or Python all of which I already know well enough.
I think you could argue that type-safe STM is such a feature for Haskell. It's something that I really miss when using threads or async essentially anywhere else. I would probably jump for Haskell over Rust as a result for heavily concurrent or multithreaded programs. Rust is memory safe, but it can't express purity and it can't enforce that STM transactions should be safely retryable.
I would also argue that Elm offers close to a 10x factor for certain types of front-end web applications. It's a very closed system, which is a matter of great controversy, but in areas where you can exist within that system it is a dramatic leap forward compared to anything else in my experience.
If you consider Erlang/Elixir functional languages, I would argue that BEAM can offer close to a 10x factor for certain types of distributed or concurrent applications as well.
You mentioned Clojure, though, and I don't know what the killer 10x feature would be there.
I partially agree, but I wouldn't say: "a certain class of problems very easy to solve". Instead I'd say: "which have a product that first delivers on a new market use case".
As someone who loves Clojure, I make this correction, because for example, Clojure has no such product, and in that sense it isn't very popular. Yet I can still use it to solve many class of problems easily and often faster than it takes me in other languages.
For example, Ruby got big because it delivered on a new kind of web framework just at the time they were becoming popular.
Go became popular only because it has a runtime with more modern tuning, prioritizing responsiveness over performance just when that started to become the new priority due to the shift to software as a service.
Python became popular only once it gave rise to NumPy and the plethora of data-science libs it offers.
Java became popular because it delivered on the first enterprise grade virtual machine.
JavaScript because it was embedded in the browser.
Etc.
Which takes me back to Clojure. Since you say you are learning it. I'd say for me Clojure's special in that it focuses not on any product as such, but instead on the language itself. Using it is more about one's enjoyment and productivity. The key part is, it gives this enhanced language while letting you choose what existing product you want to use it with. That's the hosted nature of it. In that sense, it provides a more enjoyable interface to some of the best products. So you can use Clojure's better syntax, core functions and abstractions and language semantics and extensibility and expressiveness and interactivity with existing high quality products like everything the JVM or JS offers, with some extras like .Net, Erlang, subset of C++, etc.
Disclaimer: I like Clojure, so am biased. Not everyone will find its syntax, functions, abstractions, interactivity, and expressivity to their liking, and if not, Clojure does not have a killer product and thus provide little value.
I suggest trying elixir instead of clojure. Webdev is extremely productive in it. There's also a new reactive web framework called Phoenix liveview that's eye-poppingly powerful. (Yes you can do similar things with blazor but I promise you when something goes wrong with your blazor code you will have either a security regression or a hair tearing out session because it's relatively hard to grok what c# is doing under to hood to transform your code)
We should draw a distinction between FP as religion and FP as tool kit.
FP as religion has failed to gain acceptance because it imposes too much cost on the user. I have to rethink my whole stack in terms of category theory AND deal with your terrible ecosystem? Hard pass.
FP as toolkit, on the other hand, has been a smashing success. Most of the core ideas of FP are mainstream now and some of the latest advances in non-FP ecosystems (React, for example) are based on FP ideas.
FP ideas have been seeping into the mainstream for quite some time now.
The oldest: GC was originally invented for Lisp. It's common now.
Type inference was big in FP before it made the jump to language like Java or C++ much more recently.
Generics were a natural idea in a typed FP context. Mainstream languages got them, now.
I'm looking forward to algebraic data types becoming really common. (The simplest explanation is that they are C-style unions with tags to tell you which case you are in. The compiler enforces that the tags correspond to how you use them.) Some mainstream languages are starting to add them.
Exactly. You can use FP ideas in pretty much any language (and most people do who like reliability). People who do not see value in immutability do all sorts of tricks to avoid the pitfalls of sharing mutable state. One example is in Java design patterns when they recommend creating a copy of the object you are handling. I can't remember the exact name of this pattern, but it is kind of funny.
> 'Much of the attractiveness of Java has little to do with the language itself, but with the associated libraries ... (Much of the unattractiveness is due to the same libraries)'
Programs are incentivized by need, and businesses and users are the primary consumers of programs. If FP and OOP both satisfy those needs nearly indistinguishably, but one of them is easier for the vast majority of programmers, then guess which one everyone is going to use?
Working for a company has taught me that people will try to get away with doing as little as possible when it comes to satisfying a business need.
I think in the current crop of languages, the "functional language" concept has shifted its purpouse:
1 GP languages have adopted FP enabling features, so we can do FP just fine in many mainstream languages, and it is infact very common (see eg React, Ramda popularity on frontend and many recent FP features in Kotlin, Java, C++, etc).
2 At the same time FP leaning languages are more popular than ever, to the point it would be ridiculous to claim "nobody uses functional languages" given the visible positions of Clojure, Erlang/Elixir, ReasonML/Ocaml, F#, Scala, etc on the scene.
I think adding 1+2 together tells us that FP is on a real streak. People choose use FP langauges, not because of their capabilities, but because of the mindsets, ecosystems and culture they promote, along with promising to consistently pave the way for FP problem solving instead of often falling back to imperative.
(1) keeps cropping up but these new languages are hardly "FP" or even using "FP" features. I think we give FP research way too much credit.
Pure functions? No, none of those languages can even express the concept except maybe C++ with the const keyword (which is as old as Haskell itself).
Immutable data structures? Even very modern languages like Kotlin don't really have them. You can define a data structure where the fields are immutable after construction but it's not transitive. There are read only collections but not immutable collections, without doing extra work. Maybe immutable collections will turn up at some point, there's a proposal to add them, but it'll just be a library not a language feature.
Type inference? New languages don't use full blown Hindley-Milner TI, they do much more limited TI that's designed to strike a balance between readable error messages, documented APIs, IDE performance and so on. Meanwhile the concept of TI is obvious and required no inspiration from anywhere - anyone who ever looked at source code will be struck by the repetition required.
Generics? C++ templates started being discussed in 1985, and it's again a pretty obvious concept that would occur to anyone who wanted to offer type safe collections.
I honestly can't see the huge impact FP supposedly had on mainstream programming. All the ideas its advocates try to claim for their own are either not used, or are obvious but usually not implemented the same way. My guess is if Haskell had never existed modern languages would look exactly the same.
Maybe another reason is: there is two kinds of software, one is programms which process input data and transform them to output data. And then there is software which operates hardware, like steering of the stepper motors of a robot, or the firmware of a washing machine.
Functional languages are (rightfully) immediately dismissed for these kinds of problems.
Then there is a grey zone: GUI programming, this is almost hardware progamming and FP have been trying but not doing well in this domain (might be wrong though).
Hardware programming doesnt come up often IT departments, so maybe this is a blind spot, but basically you are loosing a big share of the market.
Ps: something special might be with the erlang telco system, but i have no idea about it
If WASM had access to the DOM, I imagine we'd start seeing a replacement of JS and a democratization of web languages. I however dread the day I get to read a full-stack C/C++ webpage.
Conjecture: programming will become split between “just build my app” and an elite set of programmers who do the most demanding work, eg cloud infrastructure for Amazon, Google etc. The latter will mostly use FP, the former will use JS et al.
I think the reason most coders (and I include myself) don’t use FP is that we don’t have enough training in it, we often don’t have a strong mathematical background, and we have an imperative mindset. It’s harder to learn those things, it’s a different way of thinking than we use in our day to day lives - much like mathematics is difficult for most people to grasp, because it doesn’t come naturally to them. Humans are not theorem provers.
As competition for jobs soars and wages plummet (hello, remote work revolution!), more of the top X% of coders will be forced to learn FP to maintain their competitive advantage, and you’ll end up with a lot more people using it. Some of that will trickle down, but most of us will be writing JS rather than Haskell for the rest of our lives.
Lists like this strike me as somewhat meaningless. Those companies probably also use bash scripts, hardly represents a significant chunk of the product. How much of their codebase is in Clojure?
We have had these discussions for many years (even pg wrote about Blub IIRC), but the real reason (IMO) is that language choice matters far less than we like to think.
What business we choose to build with the language will outweighs the impact of language choice a hundredfold.
Our decisions on CI/CD, our discipline on building clean architecture with whatever language we like matters more.
In short, the things that make development a productive and enjoyable experience are linked less to the language than to the skill and professionalism of the development team - and "weird" languages tend to have more skilled and professional developers working in them, so the causality / correlation tends to get mixed up.
The upshot is, worry less about learning Lisp at work, and more about fighting your corner on why we should rewrite that 3,000 line monster engine module that we all call each day but making changes to it is a nightmare.
> "What business we choose to build with the language will outweighs the impact of language choice a hundredfold."
This is on one hand a truism that actually adds nothing to the discussion. In achieving success, of course the business matters. Even more so the best simplifications come from understanding the business domain, not from the tools used.
---
On the other hand it's also patently false. Build a web browser in Ruby. Build an operating system in JavaScript. Build your average web app in C/C++.
The tools used have inherent limits, being optimized for certain domains and not others, can make us more productive, can lower the defect rate and can keep us happy enough to see the project released.
In my experience _some_ static FP languages can lower the defect rate, can make certain problems easier to tackle, can make the code easier to maintain and refactor and due to performance being reasonable, they tend to be more general purpose than other languages — this trait being a consequence of static typing, making performance good enough, coupled with the languages themselves still being high level enough.
---
> "learning Lisp at work"
Ah, I see the problem ... many of you thought Lisp is some sort of secret sauce. It isn't, it never was, Lisp is a freaking mess.
The real problem in our industry is not applying the scientific method for advancing it. We thus rely on fashion and salesmen to sell us magic pills.
>What business we choose to build with the language will outweighs the impact of language choice a hundredfold.
This isn't always the case. If I tried to build a HFT company using Ruby for literally everything, it's almost guaranteed to be a completely failure, not only because it's extremely difficult to write allocation free low level code in pure Ruby, but also because anyone I tried to hire with relevant experience to build the platform would be like "WTF, why are you building a HFT platform entirely in Ruby, that's such a stupid idea, no way I'm working on that".
Or for that matter if I decided to start a company to build a web browser in pure Ruby.
That's basically the crux of it, syntax matters a lot less in language adoption. Most mainstream languages benefit from a "killer" app, feature, software-class or platform, which is what sees Swift become hugely popular because of iOS, Java/Kotlin getting a boost from Android, Browsers popularizing JS and many games & OS Software still written in C++ for its zero overhead abstractions.
Ecosystem, native libraries, community, knowledge, tooling, familiarity, domain suitability, hireability and overall general dev productivity & UX matters a lot more in language adoption.
I'm not seeing any big draw card from a Killer App that clearly highlights its superiority over more popular alternative languages. There's many niche areas where FP shines like implementing compilers, statistics & math models, but I don't see much appeal in mainstream usage where it adds enough value over dominant languages to overcome its deficiencies in other areas. A clear example is AI which is an area that FP would excel at but is still dominated by Python & its dominant ecosystem.
The value proposition of pure FP languages also gets diminished as mainstream languages adopts FP language features.
Language choice matters. But, except for specific cases, and within an usually wide margin, it matters less than you think. http://www.paulgraham.com/avg.html
Yes, you'll shoot yourself in the foot if trying to write a website in C++ or maybe Java. But between Python/Ruby/Modern PHP, they will probably work fine.
And the main issue I think is that, while some languages like Haskell (or Elixir, though it seems much better than Haskell) or Lisp or F#, etc might excel at some places, their advantages won't compensate for their disadvantages in the 80% of cases you don't need them (this is comparing with the modern language landscape - and even Java now is much better than Java 20yrs ago).
I love this phrase from the article above: "The safest kind were the ones that wanted Oracle experience." though I think there's a deeper meaning: they're not safer because they're using Oracle. They're safer because they're picking Oracle (hence showing that their world view is narrow). Sure, they could be geniouses in disguise and picking Oracle for that 1% where it really is way better than the competition, but most likely they aren't.
Amen. Or as Jobs said,
"You've got to start with the customer experience first and work backwards to the technology. You can't start with the technology and try to figure out how you're gonna sell it"
My feeling right now is i disagree with this. I think there is a certain amount of clarity in functional languages that more imperative languages are striving for as they develop maybe. You seem to be able to express more for less in most functional languages. Out of curiosity, do you yourself work well and quickly in functional languages?
CI/CD is also separable from this issue, i think. But the thing that you can do well with it which is write and regularly run tests is not.
My thinking is the main problem is people just aren't exposed to functional languages enough and get stuck working to line theirs and other peoples' pockets before they have had enough exposure.
I also have some gripes with the actual document which i will post in a top-level reply.
FWIW if you're not using algebra to write your software you're not quite doing FP just yet.
Doing math on software to make new software is the overlooked part of FP in my opinion. You hear about "first-class functions" and "referential transparency" a lot but not as much about "equational reasoning".
I like framing FP and OO as technologies, and technology takes money and time to improve. The technological aspect comes from the ability of language and IDE teams to translate your programming style into an efficient program.
I think there is a fundamental reason. The computer is inherently mutable. As a result, the basic abstractions of operating systems are mutable.
Thus, except for nicely contained problems such a text transformation (see Pandoc for an awesume use of Haskel), interfacing with the computer and the rest of the world becomes an impedence mismatch. Yes, monads are awesome, but you shouldn't need a math PhD, to print "Hello World" to the screen and understand what it is doing.
The other issue is performance. Yes, performance is generally good enough, except when it is not, and when it is not, it is not obvious why you are having issues or what you can do to fix them. This once again comes to the abstraction mismatch between the mutable computer and the pure functional language.
JS has some properties that are typically associated with functional languages but is missing others. But then again, so does Java if you're willing to ignore the lack of syntactic sugar for them, so what do definitions even mean anymore.
[+] [-] noelwelsh|5 years ago|reply
[+] [-] skohan|5 years ago|reply
[+] [-] giantDinosaur|5 years ago|reply
[+] [-] suls|5 years ago|reply
[+] [-] ilaksh|5 years ago|reply
You also didn't mention F# or ReasonML.
Or are those too much like FP for your point?
[+] [-] thu2111|5 years ago|reply
One reply observes they don't have pure functions which is rather fundamental to most modern definitions of an FP language. But they also use imperative flow control in which statement ordering matters, their APIs are object oriented, there's no lazyness, type inference is intentionally limited.
I don't think they've really borrowed many ideas from academic FP. Most such ideas were in fact explicitly rejected.
[+] [-] IshKebab|5 years ago|reply
[+] [-] _hardwaregeek|5 years ago|reply
Indeed I'd place Rust as an example of a language that got it right. Sure, Rust isn't functional, but it's confusing on first usage, so close enough :D
In all seriousness, the big issue that functional languages have to get over is that most programmers are not great mathematicians, so declarative programming feels very weird and confusing. With Rust the big issue is all the rules about memory. How did Rust solve it?
For one, they made the language as familiar as possible. Rust's syntax is extremely close to C/C++, even if the semantics aren't. As much as PL people claim syntax doesn't matter, it does. ReasonML is a project with a similar philosophy.
Next, they put a lot of work into documentation and explanations, especially at the compiler level. Rust's compiler messages are fantastic and often anticipate beginner mistakes. I'd love a functional language that detects when the code looks kinda imperative and gently guides you towards the functional option.
And finally, they had a killer app like Wadler mentions. Performant memory safety is pretty hard to argue against. Even a manager could see the potential upsides. I wonder what sort of killer app one could create for functional languages? Reason with ReasonReact could have robust UI as one, but that's still not as good of a sell as performant memory safety.
[+] [-] gridlockd|5 years ago|reply
If have real time constraints, you probably do not care about memory safety that much, unless your system is safety critical.
If your system is safety critical, you are using lots of tooling for validation beyond memory safety - and probably some form of model based code generation. That tooling just does not exist for newcomer languages.
[+] [-] nilkn|5 years ago|reply
For what it's worth, speaking from experience on Ubuntu, stack for Haskell has worked just as flawlessly for me as cargo has for Rust. (I might get some flack for this, but I'd encourage one to ignore the existence of cabal as much as possible for Haskell in 2020 and beyond.)
[+] [-] StreamBright|5 years ago|reply
You do not need to be a mathematician to appreciate declarative programming.
[+] [-] pritambarhate|5 years ago|reply
Functional languages are lacking such killer features which makes them 10x more productive for widely faced problems. I am learning Clojure to learn more about the functional paradigm, but I don't see any particular type of software that I could do with it which I couldn't achieve with Java, Go, JS or Python all of which I already know well enough.
[+] [-] nilkn|5 years ago|reply
I would also argue that Elm offers close to a 10x factor for certain types of front-end web applications. It's a very closed system, which is a matter of great controversy, but in areas where you can exist within that system it is a dramatic leap forward compared to anything else in my experience.
If you consider Erlang/Elixir functional languages, I would argue that BEAM can offer close to a 10x factor for certain types of distributed or concurrent applications as well.
You mentioned Clojure, though, and I don't know what the killer 10x feature would be there.
[+] [-] didibus|5 years ago|reply
As someone who loves Clojure, I make this correction, because for example, Clojure has no such product, and in that sense it isn't very popular. Yet I can still use it to solve many class of problems easily and often faster than it takes me in other languages.
For example, Ruby got big because it delivered on a new kind of web framework just at the time they were becoming popular.
Go became popular only because it has a runtime with more modern tuning, prioritizing responsiveness over performance just when that started to become the new priority due to the shift to software as a service.
Python became popular only once it gave rise to NumPy and the plethora of data-science libs it offers.
Java became popular because it delivered on the first enterprise grade virtual machine.
JavaScript because it was embedded in the browser.
Etc.
Which takes me back to Clojure. Since you say you are learning it. I'd say for me Clojure's special in that it focuses not on any product as such, but instead on the language itself. Using it is more about one's enjoyment and productivity. The key part is, it gives this enhanced language while letting you choose what existing product you want to use it with. That's the hosted nature of it. In that sense, it provides a more enjoyable interface to some of the best products. So you can use Clojure's better syntax, core functions and abstractions and language semantics and extensibility and expressiveness and interactivity with existing high quality products like everything the JVM or JS offers, with some extras like .Net, Erlang, subset of C++, etc.
Disclaimer: I like Clojure, so am biased. Not everyone will find its syntax, functions, abstractions, interactivity, and expressivity to their liking, and if not, Clojure does not have a killer product and thus provide little value.
[+] [-] dnautics|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] jierenchen|5 years ago|reply
FP as religion has failed to gain acceptance because it imposes too much cost on the user. I have to rethink my whole stack in terms of category theory AND deal with your terrible ecosystem? Hard pass.
FP as toolkit, on the other hand, has been a smashing success. Most of the core ideas of FP are mainstream now and some of the latest advances in non-FP ecosystems (React, for example) are based on FP ideas.
[+] [-] eru|5 years ago|reply
The oldest: GC was originally invented for Lisp. It's common now.
Type inference was big in FP before it made the jump to language like Java or C++ much more recently.
Generics were a natural idea in a typed FP context. Mainstream languages got them, now.
I'm looking forward to algebraic data types becoming really common. (The simplest explanation is that they are C-style unions with tags to tell you which case you are in. The compiler enforces that the tags correspond to how you use them.) Some mainstream languages are starting to add them.
[+] [-] StreamBright|5 years ago|reply
[+] [-] asp_net|5 years ago|reply
https://thomasbandt.com/who-cares-about-functional-programmi...
[+] [-] csours|5 years ago|reply
[+] [-] wiineeth|5 years ago|reply
[+] [-] anonytrary|5 years ago|reply
Working for a company has taught me that people will try to get away with doing as little as possible when it comes to satisfying a business need.
[+] [-] rumanator|5 years ago|reply
Aka productivity.
[+] [-] fulafel|5 years ago|reply
1 GP languages have adopted FP enabling features, so we can do FP just fine in many mainstream languages, and it is infact very common (see eg React, Ramda popularity on frontend and many recent FP features in Kotlin, Java, C++, etc).
2 At the same time FP leaning languages are more popular than ever, to the point it would be ridiculous to claim "nobody uses functional languages" given the visible positions of Clojure, Erlang/Elixir, ReasonML/Ocaml, F#, Scala, etc on the scene.
I think adding 1+2 together tells us that FP is on a real streak. People choose use FP langauges, not because of their capabilities, but because of the mindsets, ecosystems and culture they promote, along with promising to consistently pave the way for FP problem solving instead of often falling back to imperative.
[+] [-] thu2111|5 years ago|reply
Pure functions? No, none of those languages can even express the concept except maybe C++ with the const keyword (which is as old as Haskell itself).
Immutable data structures? Even very modern languages like Kotlin don't really have them. You can define a data structure where the fields are immutable after construction but it's not transitive. There are read only collections but not immutable collections, without doing extra work. Maybe immutable collections will turn up at some point, there's a proposal to add them, but it'll just be a library not a language feature.
Type inference? New languages don't use full blown Hindley-Milner TI, they do much more limited TI that's designed to strike a balance between readable error messages, documented APIs, IDE performance and so on. Meanwhile the concept of TI is obvious and required no inspiration from anywhere - anyone who ever looked at source code will be struck by the repetition required.
Generics? C++ templates started being discussed in 1985, and it's again a pretty obvious concept that would occur to anyone who wanted to offer type safe collections.
I honestly can't see the huge impact FP supposedly had on mainstream programming. All the ideas its advocates try to claim for their own are either not used, or are obvious but usually not implemented the same way. My guess is if Haskell had never existed modern languages would look exactly the same.
[+] [-] andi999|5 years ago|reply
Ps: something special might be with the erlang telco system, but i have no idea about it
[+] [-] mrobot|5 years ago|reply
Training -- Schools should be covering the training problem in this PDF, and i think that would help a lot.
Availability -- GHC is no longer an 'adventure' to install
Packagability -- Can't you just build standalone programs with most FLs?
Popularity -- Aren't they getting more popular?
"They don't get it" -- I don't think the example given of "i need some documentation and stability" applies anymore.
[+] [-] dloss|5 years ago|reply
https://www.microsoft.com/en-us/research/publication/scripti...
EDIT: Add link
[+] [-] LockAndLol|5 years ago|reply
[+] [-] randomsearch|5 years ago|reply
I think the reason most coders (and I include myself) don’t use FP is that we don’t have enough training in it, we often don’t have a strong mathematical background, and we have an imperative mindset. It’s harder to learn those things, it’s a different way of thinking than we use in our day to day lives - much like mathematics is difficult for most people to grasp, because it doesn’t come naturally to them. Humans are not theorem provers.
As competition for jobs soars and wages plummet (hello, remote work revolution!), more of the top X% of coders will be forced to learn FP to maintain their competitive advantage, and you’ll end up with a lot more people using it. Some of that will trickle down, but most of us will be writing JS rather than Haskell for the rest of our lives.
[+] [-] dotemacs|5 years ago|reply
https://clojure.org/community/companies
[+] [-] random32840|5 years ago|reply
[+] [-] lifeisstillgood|5 years ago|reply
What business we choose to build with the language will outweighs the impact of language choice a hundredfold.
Our decisions on CI/CD, our discipline on building clean architecture with whatever language we like matters more.
In short, the things that make development a productive and enjoyable experience are linked less to the language than to the skill and professionalism of the development team - and "weird" languages tend to have more skilled and professional developers working in them, so the causality / correlation tends to get mixed up.
The upshot is, worry less about learning Lisp at work, and more about fighting your corner on why we should rewrite that 3,000 line monster engine module that we all call each day but making changes to it is a nightmare.
[+] [-] bad_user|5 years ago|reply
This is on one hand a truism that actually adds nothing to the discussion. In achieving success, of course the business matters. Even more so the best simplifications come from understanding the business domain, not from the tools used.
---
On the other hand it's also patently false. Build a web browser in Ruby. Build an operating system in JavaScript. Build your average web app in C/C++.
The tools used have inherent limits, being optimized for certain domains and not others, can make us more productive, can lower the defect rate and can keep us happy enough to see the project released.
In my experience _some_ static FP languages can lower the defect rate, can make certain problems easier to tackle, can make the code easier to maintain and refactor and due to performance being reasonable, they tend to be more general purpose than other languages — this trait being a consequence of static typing, making performance good enough, coupled with the languages themselves still being high level enough.
---
> "learning Lisp at work"
Ah, I see the problem ... many of you thought Lisp is some sort of secret sauce. It isn't, it never was, Lisp is a freaking mess.
The real problem in our industry is not applying the scientific method for advancing it. We thus rely on fashion and salesmen to sell us magic pills.
[+] [-] logicchains|5 years ago|reply
This isn't always the case. If I tried to build a HFT company using Ruby for literally everything, it's almost guaranteed to be a completely failure, not only because it's extremely difficult to write allocation free low level code in pure Ruby, but also because anyone I tried to hire with relevant experience to build the platform would be like "WTF, why are you building a HFT platform entirely in Ruby, that's such a stupid idea, no way I'm working on that".
Or for that matter if I decided to start a company to build a web browser in pure Ruby.
[+] [-] mythz|5 years ago|reply
Ecosystem, native libraries, community, knowledge, tooling, familiarity, domain suitability, hireability and overall general dev productivity & UX matters a lot more in language adoption.
I'm not seeing any big draw card from a Killer App that clearly highlights its superiority over more popular alternative languages. There's many niche areas where FP shines like implementing compilers, statistics & math models, but I don't see much appeal in mainstream usage where it adds enough value over dominant languages to overcome its deficiencies in other areas. A clear example is AI which is an area that FP would excel at but is still dominated by Python & its dominant ecosystem.
The value proposition of pure FP languages also gets diminished as mainstream languages adopts FP language features.
[+] [-] raverbashing|5 years ago|reply
Yes, you'll shoot yourself in the foot if trying to write a website in C++ or maybe Java. But between Python/Ruby/Modern PHP, they will probably work fine.
And the main issue I think is that, while some languages like Haskell (or Elixir, though it seems much better than Haskell) or Lisp or F#, etc might excel at some places, their advantages won't compensate for their disadvantages in the 80% of cases you don't need them (this is comparing with the modern language landscape - and even Java now is much better than Java 20yrs ago).
I love this phrase from the article above: "The safest kind were the ones that wanted Oracle experience." though I think there's a deeper meaning: they're not safer because they're using Oracle. They're safer because they're picking Oracle (hence showing that their world view is narrow). Sure, they could be geniouses in disguise and picking Oracle for that 1% where it really is way better than the competition, but most likely they aren't.
[+] [-] Toine|5 years ago|reply
https://youtu.be/FF-tKLISfPE
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] mrobot|5 years ago|reply
CI/CD is also separable from this issue, i think. But the thing that you can do well with it which is write and regularly run tests is not.
My thinking is the main problem is people just aren't exposed to functional languages enough and get stuck working to line theirs and other peoples' pockets before they have had enough exposure.
I also have some gripes with the actual document which i will post in a top-level reply.
[+] [-] leandot|5 years ago|reply
[+] [-] StreamBright|5 years ago|reply
[+] [-] carapace|5 years ago|reply
Doing math on software to make new software is the overlooked part of FP in my opinion. You hear about "first-class functions" and "referential transparency" a lot but not as much about "equational reasoning".
[+] [-] threatofrain|5 years ago|reply
[+] [-] RcouF1uZ4gsC|5 years ago|reply
Thus, except for nicely contained problems such a text transformation (see Pandoc for an awesume use of Haskel), interfacing with the computer and the rest of the world becomes an impedence mismatch. Yes, monads are awesome, but you shouldn't need a math PhD, to print "Hello World" to the screen and understand what it is doing.
The other issue is performance. Yes, performance is generally good enough, except when it is not, and when it is not, it is not obvious why you are having issues or what you can do to fix them. This once again comes to the abstraction mismatch between the mutable computer and the pure functional language.
[+] [-] dang|5 years ago|reply
[+] [-] femto113|5 years ago|reply
[+] [-] SCdF|5 years ago|reply
[+] [-] LockAndLol|5 years ago|reply