6 ms·

It seems like there's been a crash in the FP language market: Scala, F#, ... Clojure. Anyone any idea why? Scala 3 almost looks attractive.

wrnr 5y ago
what do you mean, the FP job market?
nicoburns 5y ago
Perhaps because a lot of the idea have been picked up by other languages with bigger ecosystems: Swift, Kotlin, Rust, etc?
- Zababa 5y ago
  Swift itself has almost no market share in the web space, just like Scala, F#, Clojure, OCaml have almost no market share in the Apple ecosystem. Scala also wasn't used in the android ecosystem, which is I think still the major user of Kotlin. On the other hand, Kotlin is also on the server now, but I don't know if it's replacing Java or Scala (maybe both?). Another thing is that Java itself is adopting lots of functional programming features (records, pattern matching recently). I don't think I've seen any mention of migration from F#, Clojure, OCaml, Haskell, Scala, ... to Rust, but maybe it's easier to pick up than C++ when high performance is needed by teams already used to a ML-like?
toomanyducks 5y ago
In my experience, OOP is taught to basically everyone in schools (AP CS is usually in Java, and so was my DSA class) which makes the jump into FP hard to wrap your head around: I've tried a few things in Haskell, and I kept trying to use weird facsimiles of objects in places they should not go. And then Rust came along and wrapped a ton of FP concepts into easy to conceptualize OOP packages, and that reduced my motivation to actually learn FP properly. Still slowly trying to learn these things, though, I don't think Rust really managed to capture all the advantages.
- R0b0t1 5y ago
  FP is also just not as suitable for solving many common CRUD problems as an OOP or imperative design is. A FP solution will be some combination of more verbose, slower, harder to maintain, and less flexible.
  - Zababa 5y ago
    I don't think that's true. I've used Phoenix with Elixir and it was a joy to use, easy to understand and pretty fast. More verbose and harder to maintain, I don't think it's true for statically typed functional programming language, the compiler does a lot of work that would be tests in other languages, and they're usually quite terse. For the "slower" part, it depends. Slower compared to what? Most will be faster than Ruby or Python, most will be slower than C++, they're usually in the ballpark of Java (by that I mean with less features but faster than Spring, at least these are the results on TechEmpower). For the less flexible, I don't know what you mean by that. Harder to extend since you don't have reflection/dynamism? That may be true, but for me these mechanism usually make a codebase harder to maintain.
    - R0b0t1 5y ago
      > For the "slower" part, it depends. Boy does it depend. Sometimes you'll get a pathological memory allocation that makes your haskell solution the slowest possible. It's this kind of stuff that makes avoiding FP languages a good idea in usual production. You've turned "do X" into "track down compiler implementation details and fix them." > For the less flexible, I don't know what you mean by that. I'm going to suggest you lack experience, then. OOP is optimized for the lowest common denominator. That is usually sufficient. You can do amazing things with FP, but it's not usually necessary, and usually gets in the way of accurately describing what your computing machinery is doing.
      - Zababa 5y ago
        > Sometimes you'll get a pathological memory allocation that makes your haskell solution the slowest possible. It's this kind of stuff that makes avoiding FP languages a good idea in usual production. Isn't that mostly due to Haskell being lazy? OCaml is strict and has more predictable performance for example. > OOP is optimized for the lowest common denominator. Again, I'm not sure what you mean by this. OOP can be a bit too good at hiding the data flow. One of the most popular book in the OOP space, Clean Code, suggests separating objects into "data structures" and "proper objects", with the former having lots of data and not much functions, and the latter the opposite. That sounds to me like using objects means you have to be more careful that when using types and plain functions. > You can do amazing things with FP, but it's not usually necessary, and usually gets in the way of accurately describing what your computing machinery is doing. The same could be said about OOP, especially with the design pattern parts. You can write very complex code in FP, and you can write very complex code in OOP. The heavy use of reflection eschewing type safety is a good example of complex code in OOP. If you want to look at easy to understand FP, Elm is a good example. React as a whole is also an example of people moving to FP practices because it's easier to understand.
gwmnxnp_516a 5y ago
It seems that some functional programming languages are hard to sell to management due to the limited adoption, talent pool concerns and integration with existing systems and code. In the case of Clojure, despite being able to run in the JVM, Clojure has a unfamiliar lisp syntax to most Java developers and is dynamically typed which makes the life of IDEs harder since dynamically typed languages are hard to refactor, hard to figure out which types a function returns and so on. In the case of Scala, Kotlin seems to eating its launch due to be borned with full tooling support from Jetbrains and endorsement by Google on Android. In addition Kotlin is FP enough without over-engineering and compiles faster than Scala. Regarding the F# the problem might be that most tutorials about .NET platform are in C# and most codebases are in C# and Microsoft does not promote F# in the same extent as C#. Moreover C# is getting more in more functional features. More and more languages are adding support functional-programming features, including Java, C#, Swift, D Language (DLang), Rust and also C++11, C++17 and C++20.

wrnr 5y ago

what do you mean, the FP job market?

nicoburns 5y ago

Perhaps because a lot of the idea have been picked up by other languages with bigger ecosystems: Swift, Kotlin, Rust, etc?

Zababa 5y ago
Swift itself has almost no market share in the web space, just like Scala, F#, Clojure, OCaml have almost no market share in the Apple ecosystem. Scala also wasn't used in the android ecosystem, which is I think still the major user of Kotlin. On the other hand, Kotlin is also on the server now, but I don't know if it's replacing Java or Scala (maybe both?). Another thing is that Java itself is adopting lots of functional programming features (records, pattern matching recently). I don't think I've seen any mention of migration from F#, Clojure, OCaml, Haskell, Scala, ... to Rust, but maybe it's easier to pick up than C++ when high performance is needed by teams already used to a ML-like?

toomanyducks 5y ago

In my experience, OOP is taught to basically everyone in schools (AP CS is usually in Java, and so was my DSA class) which makes the jump into FP hard to wrap your head around: I've tried a few things in Haskell, and I kept trying to use weird facsimiles of objects in places they should not go. And then Rust came along and wrapped a ton of FP concepts into easy to conceptualize OOP packages, and that reduced my motivation to actually learn FP properly. Still slowly trying to learn these things, though, I don't think Rust really managed to capture all the advantages.

R0b0t1 5y ago
FP is also just not as suitable for solving many common CRUD problems as an OOP or imperative design is. A FP solution will be some combination of more verbose, slower, harder to maintain, and less flexible.
- Zababa 5y ago
  I don't think that's true. I've used Phoenix with Elixir and it was a joy to use, easy to understand and pretty fast. More verbose and harder to maintain, I don't think it's true for statically typed functional programming language, the compiler does a lot of work that would be tests in other languages, and they're usually quite terse. For the "slower" part, it depends. Slower compared to what? Most will be faster than Ruby or Python, most will be slower than C++, they're usually in the ballpark of Java (by that I mean with less features but faster than Spring, at least these are the results on TechEmpower). For the less flexible, I don't know what you mean by that. Harder to extend since you don't have reflection/dynamism? That may be true, but for me these mechanism usually make a codebase harder to maintain.
  - R0b0t1 5y ago
    > For the "slower" part, it depends. Boy does it depend. Sometimes you'll get a pathological memory allocation that makes your haskell solution the slowest possible. It's this kind of stuff that makes avoiding FP languages a good idea in usual production. You've turned "do X" into "track down compiler implementation details and fix them." > For the less flexible, I don't know what you mean by that. I'm going to suggest you lack experience, then. OOP is optimized for the lowest common denominator. That is usually sufficient. You can do amazing things with FP, but it's not usually necessary, and usually gets in the way of accurately describing what your computing machinery is doing.
    - Zababa 5y ago
      > Sometimes you'll get a pathological memory allocation that makes your haskell solution the slowest possible. It's this kind of stuff that makes avoiding FP languages a good idea in usual production. Isn't that mostly due to Haskell being lazy? OCaml is strict and has more predictable performance for example. > OOP is optimized for the lowest common denominator. Again, I'm not sure what you mean by this. OOP can be a bit too good at hiding the data flow. One of the most popular book in the OOP space, Clean Code, suggests separating objects into "data structures" and "proper objects", with the former having lots of data and not much functions, and the latter the opposite. That sounds to me like using objects means you have to be more careful that when using types and plain functions. > You can do amazing things with FP, but it's not usually necessary, and usually gets in the way of accurately describing what your computing machinery is doing. The same could be said about OOP, especially with the design pattern parts. You can write very complex code in FP, and you can write very complex code in OOP. The heavy use of reflection eschewing type safety is a good example of complex code in OOP. If you want to look at easy to understand FP, Elm is a good example. React as a whole is also an example of people moving to FP practices because it's easier to understand.

gwmnxnp_516a 5y ago

It seems that some functional programming languages are hard to sell to management due to the limited adoption, talent pool concerns and integration with existing systems and code. In the case of Clojure, despite being able to run in the JVM, Clojure has a unfamiliar lisp syntax to most Java developers and is dynamically typed which makes the life of IDEs harder since dynamically typed languages are hard to refactor, hard to figure out which types a function returns and so on. In the case of Scala, Kotlin seems to eating its launch due to be borned with full tooling support from Jetbrains and endorsement by Google on Android. In addition Kotlin is FP enough without over-engineering and compiles faster than Scala. Regarding the F# the problem might be that most tutorials about .NET platform are in C# and most codebases are in C# and Microsoft does not promote F# in the same extent as C#. Moreover C# is getting more in more functional features. More and more languages are adding support functional-programming features, including Java, C#, Swift, D Language (DLang), Rust and also C++11, C++17 and C++20.