4 ms·

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, a

by 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.

by 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.