Are Haskell Erlang good for writing software end-to end ? I know Erlang is good for developing fault tolerance programs who can handle concurrency well. But what Erlang suggest is you can use NIF(Native functions in 'C') if your program is CPU bound. Haskell is good in concurrency i think but also good in developing programs which can handle complex logic inside. Again for networking or IO bound Haskell(people on site) suggest to use native languages.
From DevOps or maintenance point of view, maintaining software for two languages can be a problem.(You already don't get people who understand functional languages and also you don't get people c/c++ easily).
Are most functional languages good at abstraction but for CPU/IO bound need to use native calls? If that is the case, this could be a major hindrance to their use?
Easier solution is then to use Scala or Clojure which are JVM based. (At least people will be convinced!).
At the risk of sounding very dumb, I'm gonna say that my intuition tells me that using purely functional languages in a large project or team is going to be extremely difficult. In my experience, functional code is very hard to maintain, unless you are very experienced with the language. This can become costly for larger teams, since most people are primarily used to imperative languages. If you want to do this, I would start out with a less 'pure' language, like Scala.
Please take into account I don't have experience with functional languages outside of hobby projects, and even then it's mostly just with Haskell. This is just what my gut tells me.
posted 4 years ago
Thanks. IMO, more than difficulty, its maintenance, enhancement that can cause a problem. Haskell,Erlang are niche languages but will be used as general purpose or on larger scale if organizations find those to be on par with other languages like C++/Java in terms of all aspects. else their popularity will always remain limited. Scala/Clojure has advantage of JVM so i think their usage in existing projects or new projects will be welcome.
Stephan van Hulst wrote:At the risk of sounding very dumb, I'm gonna say that my intuition tells me that using purely functional languages in a large project or team is going to be extremely difficult.
As someone with 25kloc Clojure in production, I'll say that we're finding maintenance of our Clojure code a lot easier than our previous OOP code base. The Clojure code is substantially shorter, uses higher level abstractions and expressivity, and the immutable data / pure function approach means far fewer bugs, far easier concurrency, and code that is generally much easier to reason about and to debug.
That said, it does seem that working with a (large) Functional code base requires smarter programmers -- because you're dealing with more abstractions and you generally have to think more about your solutions (because you can't just bash out some "obvious" simple imperative code). On the other hand, Functional code lets you do a lot more with less code and fewer developers, because it is much more expressive than mainstream (OOP) languages. We've seen about a 2-5x "compression" with Clojure compared to previous languages we've used. Some folks claim Clojure is 4-10x shorter than Java. That makes our code base equivalent to 100-250kloc Java.
Haskell has the additional benefit of a very strong type system that eliminates another whole class of errors, above and beyond those eliminated by pure functions and immutable data.
I know several companies (here in the Bay Area) that have extensive code bases written in Clojure, Haskell, Elm etc, and they all seem pretty happy with their decision to use FP. Facebook's new spam filtering system is written in Haskell, as an example.
I spent the morning putting in a comma and the afternoon removing it.
-- Gustave Flaubert, French realist novelist (1821-1880)
I recently had an interview with these guys who are using Clojure for a commercial music streaming service. They're very happy with the benefits of FP and Clojure for their business and have published tech articles and videos etc about how they're using Clojure. They're also hyper-Agile, lots of TDD and extremely rapid deployment, and they feel Clojure plays a key role in enabling this kind of efficiency.
It's certainly true that they look for smart engineers and their own people seem to be a pretty clever bunch. They recruit people who have the kind of engineering skills they need for their application area, even if they haven't used Clojure, then train them in Clojure, as they feel a good developer can learn Clojure reasonably easily. Unfortunately, I can't tell you more about how this skills acquisition process works, as I didn't get the job!
No more Blub for me, thank you, Vicar.
Stephan van Hulst
posted 4 years ago
Interesting stuff guys!
It's never done THAT before. Explain it to me tiny ad: