5 ms·

FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. Switching without having sufficient background first is prob

by wyager 5y ago

FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. Switching without having sufficient background first is probably not a good idea though.

Jare 5y ago
That's the problem with "uncommon": how do you obtain that background and how do you learn what you're doing? (of course, not just you - you, the entire team, and future hires)
- throwaway81523 5y ago
  The same way you learn anything else that is difficult: time and practice, and start with fundamentals. You can't put it on any work-related critical path until you have it down solid.
  - Jare 5y ago
    I mean in the context of an existing company / team of nontrivial size. Most cases I know of, the uncommon language was there from the days of it being a personal or 1-person project. For other types of tech (e.g. infrastructure) sometimes the new/different capabilities are such a defining feature that the lack of familiarity is not as scary. But in programming languages, you can fundamentally do pretty much anything in existing and well known ones.
    - throwaway81523 5y ago
      Have fun writing a web app in assembly language ;). Yes it's been done, but not often, and for good reason. Haskell is sort of a special case: it's best suited for writing compilers, but has been pressed into just about everything else because people are into it for its own sake. Yes if you're running a C++ shop and someone leaves behind a small program in Haskell, you're probably better off reimplementing it than becoming or hiring a Haskell guru just to maintain that thing. That's a question of whether to learn Haskell, not how to learn it. In the case of the linked article, the author was the one who decided to get the company involved with FP, and gave his thoughts on whether it was worth it. I can certainly support the idea that someone juggling all the plates required to keep a company running, has no time to embark on a deep and nerdy self-education project in something as abstruse as FP. Better to keep it at the level of a side interest or hobby until you're comfortable with it, before even thinking of doing anything important with it.
- wyager 5y ago
  My previous employer would teach new employees to use a functional language from scratch and people would be productive in 2-3 weeks. I don’t think it’s actually that difficult in reality.
- whateveracct 5y ago
  a good attitude and some elbow grease most "failed" FP projects I've seen mostly lack the former - often due to managers or engineers that come on the project after it first hits prod then comes the rewrite to add a notch in said managers' and engineers' belts then the original FPers leave and now there's systems in prod with little to no people who can work on it. that rewrite suddenly got a lot more business-critical! the original FPers weren't as PM-savvy, so the rewrite is successful despite having less functionality and still taking a year or more. doesn't matter - the savvier managers and engineers know how to set goals & milestones that they know they'll hit and can say that they hit when evaluating the project's success This is just a summary of my years of experience as an FP professional. I've seen this happen 3+ times across 3+ companies. --- Haskell is by far the most worth-it skill I've cultivated. It wasn't easy but I really do do a 10x job on my personal projects in large part due to it. It's just not a good language to use in a corporate setting. It's better to get paid big bucks to be less productive. Save the technical brainpower for things you yourself find valuable :) (and I sneak Haskell in all my jobs anyways - scripting, for instance - so I still develop my Haskell knowledge on company time & dime, despite the language being all-but-banned by the higher-ups)
- lmm 5y ago
  You have to put a bit of time and effort into deliberate training, like most companies used to do for most positions.
alisonkisk 5y ago
"knowing what you're doing" is extremely hard in FP, as per the experience of many many productive imperative/OO programmers who tried.
taeric 5y ago
This somewhat annoys me. "Knowing what you are doing" is time efficient. Regardless of what tooling you have.
- brightball 5y ago
  The flip side is maintainability, which gets much simpler long term with FP.
  - taeric 5y ago
    Do you have evidence showing this? The few long term maintained programs I am aware of are decidedly not what one would call modern functional. (Granted, the most ported and maintained software I know of is either Linux or SCUMM.)
  - hvs 5y ago
    This is a statement that requires some sort of citation. Extraordinary claims and all that.
    - brightball 5y ago
      20 years experience with OO code. Over time, OO always leads to entanglement due to inheritance based solutions that seemed like a good idea at the time. Eventually, these become the basis for many other parts of the system. You combine the potential for side effects in the code with a tree that can't easily be changed because of how many other things it will negatively affect and you end up with a code base that is harder and harder to change the larger it gets. In a FP approach, this is a class of problems that you can't easily replicate. Yes there's a learning curve to operating in a FP style, but once you're able to move quickly with it the long term rewards are a byproduct. The OO solution to avoiding this problem is to build with microservices instead, which forces different parts of the system to be isolated and minimizes the negative effects from entanglement...but microservices come with their own maintenance and speed of development headaches as well.
      - 5y ago
bsder 5y ago
> FP is absolutely way more time-efficient for most kinds of projects I absolutely do not agree. FP binds your particular choice of implementation to the code architecture. FP actually makes refactoring in the small trivial and refactoring in the large ferociously difficult. A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time". This is painful. An imperative programmer throws in a global time variable, possibly a local timeout variable and gets on with life. Now, if I'm trying to manage a high-complexity codebase, I will probably eat the FP penalty. Having complete determinism, decoupling, and visibility in, say, a network stack makes debugging possible that will be very difficult with sorta-state smeared across a bunch of variables at various level of hierarchy. However, I accept and acknowledge that I am making a tradeoff.
- yawaramin 5y ago
  > A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time". I mean, 'FP' is so broad a term that a lot of languages fall under that, almost all of which can introduce the concept of a timeout quite easily. E.g. OCaml's Lwt, or Scala's ZIO are two that quickly come to mind.
- dnautics 5y ago
  > FP actually makes refactoring in the small trivial and refactoring in the large ferociously difficult This is not at all my experience, in fact I'd say I encountered the opposite. Large scale refactoring in C++ and python were nightmarish and are a breeze in Julia and Elixir.
- lmm 5y ago
  > An imperative programmer throws in a global time variable, possibly a local timeout variable and gets on with life. Which actually destroys the ability to refactor in the large. You have no idea what might use that global time variable from where or why. Choosing to use FP is choosing to ban yourself from taking on that kind of tech debt (although we should note that most FP languages have an "escape hatch" if you need it - even in Haskell you can always unsafePerformIO). There are definitely times where you want to do that, but I don't think it's right to frame that as the non-functional language making things easier to refactor in the large - rather the non-functional language makes it easier to not refactor in the large because you don't fully decouple things in the large in the first place.
dragonwriter 5y ago
> FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. That may or may not be true, but most programmers don't and aren't really all that interested in learning. Most know what they are doing in a handful of Algol-derived mostly-imperative OO-ish languages and aren't comfortable goony much afield from that.

by wyager 5y ago

FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. Switching without having sufficient background first is probably not a good idea though.

Jare 5y ago

That's the problem with "uncommon": how do you obtain that background and how do you learn what you're doing? (of course, not just you - you, the entire team, and future hires)

throwaway81523 5y ago
The same way you learn anything else that is difficult: time and practice, and start with fundamentals. You can't put it on any work-related critical path until you have it down solid.
- Jare 5y ago
  I mean in the context of an existing company / team of nontrivial size. Most cases I know of, the uncommon language was there from the days of it being a personal or 1-person project. For other types of tech (e.g. infrastructure) sometimes the new/different capabilities are such a defining feature that the lack of familiarity is not as scary. But in programming languages, you can fundamentally do pretty much anything in existing and well known ones.
  - throwaway81523 5y ago
    Have fun writing a web app in assembly language ;). Yes it's been done, but not often, and for good reason. Haskell is sort of a special case: it's best suited for writing compilers, but has been pressed into just about everything else because people are into it for its own sake. Yes if you're running a C++ shop and someone leaves behind a small program in Haskell, you're probably better off reimplementing it than becoming or hiring a Haskell guru just to maintain that thing. That's a question of whether to learn Haskell, not how to learn it. In the case of the linked article, the author was the one who decided to get the company involved with FP, and gave his thoughts on whether it was worth it. I can certainly support the idea that someone juggling all the plates required to keep a company running, has no time to embark on a deep and nerdy self-education project in something as abstruse as FP. Better to keep it at the level of a side interest or hobby until you're comfortable with it, before even thinking of doing anything important with it.
wyager 5y ago
My previous employer would teach new employees to use a functional language from scratch and people would be productive in 2-3 weeks. I don’t think it’s actually that difficult in reality.
whateveracct 5y ago
a good attitude and some elbow grease most "failed" FP projects I've seen mostly lack the former - often due to managers or engineers that come on the project after it first hits prod then comes the rewrite to add a notch in said managers' and engineers' belts then the original FPers leave and now there's systems in prod with little to no people who can work on it. that rewrite suddenly got a lot more business-critical! the original FPers weren't as PM-savvy, so the rewrite is successful despite having less functionality and still taking a year or more. doesn't matter - the savvier managers and engineers know how to set goals & milestones that they know they'll hit and can say that they hit when evaluating the project's success This is just a summary of my years of experience as an FP professional. I've seen this happen 3+ times across 3+ companies. --- Haskell is by far the most worth-it skill I've cultivated. It wasn't easy but I really do do a 10x job on my personal projects in large part due to it. It's just not a good language to use in a corporate setting. It's better to get paid big bucks to be less productive. Save the technical brainpower for things you yourself find valuable :) (and I sneak Haskell in all my jobs anyways - scripting, for instance - so I still develop my Haskell knowledge on company time & dime, despite the language being all-but-banned by the higher-ups)
lmm 5y ago
You have to put a bit of time and effort into deliberate training, like most companies used to do for most positions.

alisonkisk 5y ago

"knowing what you're doing" is extremely hard in FP, as per the experience of many many productive imperative/OO programmers who tried.

taeric 5y ago

This somewhat annoys me. "Knowing what you are doing" is time efficient. Regardless of what tooling you have.

brightball 5y ago
The flip side is maintainability, which gets much simpler long term with FP.
- taeric 5y ago
  Do you have evidence showing this? The few long term maintained programs I am aware of are decidedly not what one would call modern functional. (Granted, the most ported and maintained software I know of is either Linux or SCUMM.)
- hvs 5y ago
  This is a statement that requires some sort of citation. Extraordinary claims and all that.
  - brightball 5y ago
    20 years experience with OO code. Over time, OO always leads to entanglement due to inheritance based solutions that seemed like a good idea at the time. Eventually, these become the basis for many other parts of the system. You combine the potential for side effects in the code with a tree that can't easily be changed because of how many other things it will negatively affect and you end up with a code base that is harder and harder to change the larger it gets. In a FP approach, this is a class of problems that you can't easily replicate. Yes there's a learning curve to operating in a FP style, but once you're able to move quickly with it the long term rewards are a byproduct. The OO solution to avoiding this problem is to build with microservices instead, which forces different parts of the system to be isolated and minimizes the negative effects from entanglement...but microservices come with their own maintenance and speed of development headaches as well.
    - 5y ago

bsder 5y ago

> FP is absolutely way more time-efficient for most kinds of projects I absolutely do not agree. FP binds your particular choice of implementation to the code architecture. FP actually makes refactoring in the small trivial and refactoring in the large ferociously difficult. A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time". This is painful. An imperative programmer throws in a global time variable, possibly a local timeout variable and gets on with life. Now, if I'm trying to manage a high-complexity codebase, I will probably eat the FP penalty. Having complete determinism, decoupling, and visibility in, say, a network stack makes debugging possible that will be very difficult with sorta-state smeared across a bunch of variables at various level of hierarchy. However, I accept and acknowledge that I am making a tradeoff.

yawaramin 5y ago
> A good example would be a program that runs fine suddenly now needs a "timeout" on an operation. FP implementations now need to thread the notion of time from somewhere near the top of the implementation the whole way down the chain to the function that needs "time". I mean, 'FP' is so broad a term that a lot of languages fall under that, almost all of which can introduce the concept of a timeout quite easily. E.g. OCaml's Lwt, or Scala's ZIO are two that quickly come to mind.
dnautics 5y ago
> FP actually makes refactoring in the small trivial and refactoring in the large ferociously difficult This is not at all my experience, in fact I'd say I encountered the opposite. Large scale refactoring in C++ and python were nightmarish and are a breeze in Julia and Elixir.
lmm 5y ago
> An imperative programmer throws in a global time variable, possibly a local timeout variable and gets on with life. Which actually destroys the ability to refactor in the large. You have no idea what might use that global time variable from where or why. Choosing to use FP is choosing to ban yourself from taking on that kind of tech debt (although we should note that most FP languages have an "escape hatch" if you need it - even in Haskell you can always unsafePerformIO). There are definitely times where you want to do that, but I don't think it's right to frame that as the non-functional language making things easier to refactor in the large - rather the non-functional language makes it easier to not refactor in the large because you don't fully decouple things in the large in the first place.

dragonwriter 5y ago

> FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. That may or may not be true, but most programmers don't and aren't really all that interested in learning. Most know what they are doing in a handful of Algol-derived mostly-imperative OO-ish languages and aren't comfortable goony much afield from that.