Earlier quoted context omitted.
What's Scala's superior alternative to builder patterns? You can have lots of final members in a constructor in Java, too..
State monad and/or lenses when appropriate, which is made quite pleasant to use with for comprehension's syntactic sugar.
Ask HN: Which functional programming language is the popular enterprise choice?
61–70 of 91 posts
Re: Ask HN: Which functional programming language is the popular enterprise choice?
#62Earlier quoted context omitted.
Scala is not a functional programming language, it is OO first and foremost. It has better support for functional programming than Java 8, Python or Smalltalk. And that in itself is great.
Java 8 has lambdas and lots of streaming functional comprehensions like map, filter, fold etc. That sounds like all the functional stuff Scala has, right? What's it missing? Also, since when does 'functional' mean 'algebraic types'? Aren't those completely different things? Are common LISP and Scheme 'not as functional as scala'?
Re: Ask HN: Which functional programming language is the popular enterprise choice?
#63Re: Ask HN: Which functional programming language is the popular enterprise choice?
#64Earlier quoted context omitted.
Very steep learning curve. Months to years to become good at it rather than the weeks to months of the Java/C# style enterprise languages. Needs a more "math like" mindset rather than a step-wise stateful mindset like typical imperative programming languages. If you're not good at abstract math you may never get comfortable with Haskell.
Have you seen C++14 or the complexity of Java stacks like Spring? These also take months or years to learn. At least learning some new abstract math is knowledge that will be useful for the rest of your life.
Re: Ask HN: Which functional programming language is the popular enterprise choice?
#65Earlier quoted context omitted.
State monad and/or lenses when appropriate, which is made quite pleasant to use with for comprehension's syntactic sugar.
You mind pasting an example? I typically find higher kinded types, monads etc to be more of a pain than the problems they're solving (builders & constructors not really that painful IMO), but am really trying to keep an open mind.
(for {
_
This code will take an event, set it's duid, contexts and url. If you squint hard enough it almost looks like: originalEvent.duid = ...
originalEvent.contexts = ...
originalEvent.url = ...
The thing that's cool about lenses is that they compose nicely. E.g., the contexts lens is defined as: val contexts: Lens[Event, Seq[EventContext]] = query >=> getterMLens("cx") >=> Lens.lensu(...)
This means that first we take the query lens, compose it with a lens that gets the "cx" parameter, then do the actual work of decoding the "cx" param.Re: Ask HN: Which functional programming language is the popular enterprise choice?
#66Earlier quoted context omitted.
Do you know why Jane Street chose OCaml over Haskell? They have similar performance, right?
Jane Street started using OCaml in the mid-2000s, when Haskell wasn't (or, at least, wasn't perceived as being) up to snuff in terms of performance. Haskell has come a long way in the past 10 years. In 2015, Haskell is almost as fast as OCaml, albeit less predictable and therefore possibly still less desirable in certain financial settings. Haskell has a better concurrency story, though.
Re: Ask HN: Which functional programming language is the popular enterprise choice?
#67Elixir might pick up some mind share, similar to ruby but still keeps its erlang roots.
I don't think it's quite there, yet. Everything's in place, and Elixir is a wonderful language, but it hasn't been quite battle tested yet. On the other hand, Erlang is pretty ubiquitous behind-the-scenes, and I wouldn't be surprised if some enterprises do develop their internal software in it. On the third hand, since Elixir uses Erlang's runtime, it'll be subject to less required battletesting for the same reasons…
They are. Though of the 4 examples you gave, only Scala's really being used to build systems, though Clojure's being used by some who don't mind forgoing static typing. Groovy's a scripting language used for short test and build files, and for Grails. I don't think JRuby ever got used much in production.
Re: Ask HN: Which functional programming language is the popular enterprise choice?
#68Earlier quoted context omitted.
Have you seen C++14 or the complexity of Java stacks like Spring? These also take months or years to learn. At least learning some new abstract math is knowledge that will be useful for the rest of your life.
I agree with you and have said that in the past myself. However, most people know at least one imperative language already and that gives them a big step up in learning the frameworks. Learning Haskell is like starting over from scratch. And, at least for me, having completed an undergraduate hard science engineering degree, I'll never be good enough at math to really grok Haskell like I do many of the imperative lan…
Re: Ask HN: Which functional programming language is the popular enterprise choice?
#69If you consider Scala functional, I think it wins the popularity contest: used by startups and established companies (Linkedin, Twitter, Meetup, Verizon, Morgan Stanley, Autodesk, HuffPo, etc, etc...) and is not "we use it in a dark corner where nobody cares" and more like "betting the whole farm on it".
I would "bet the whole farm" on Haskell before Scala. That's not to make a dig at Scala. It's way better than Java. It's also really complicated, and the need for JVM compatibility is a big part of that. Then you have the compile speed issues, the problematic tool chain, and the fact that average Java programmers, given Scala, will create unmaintainable nightmares. I'd use Scala over Haskell when I wanted JVM interop…
Re: Ask HN: Which functional programming language is the popular enterprise choice?
#70Why hasn't haskell become popular?
The language is more restrictive and sometimes it's harder to get something working. Of course the payoff is immense, you end up with much more maintainable and composable code. However I'm not convinced that many enterprises care much about these properties, as they are often more of a long term win. People also have an emotional attachment to their existing tools and paradigms.
Actually, you have it backwards. Enterprises care a great deal about long term maintenance and have large codebases. However, they are also very conservative and prefer the tried and tested approach.
Startups don't typically care about maintenance because, for the most part, they are going for a binary win/lose outcome where in a win they have so many resources that 5x higher maintenance costs are ok, and in the lose they close up shop/pivot and throw the code out. And startups are usually more open to taking a chance on new/different tech.
If there were 3-4 large enterprise companies with 200kloc+ Haskell projects in use I feel Haskell could see long term 20-30% uptake in the enterprise. But few enterprises will take the risk of being one of the first.