I like to think of a programming language like a lever:
"Give me a lever long enough and a fulcrum on which to place it, and I shall move the world." - Archimedes
Sounds like an ideal use-case: complex, well-defined rules and procedures that must be modeled in a fool-proof way. I think the issue for most people who dream about using Haskell at work is that their use-case doesn't have these kinds of needs, and so the tradeoffs (hiring difficulty, third-party API support, etc.) just don't make sense.
I really really love Haskell, but I wonder if it's a rational decision to use it in comparison to an eager ML (OCaml, F# or SML). Much simpler languages. The amount of language extensions plus laziness make the learning curve of Haskell quite steep!
Still, I love this. Keep up the good work.
I think that during the 2020s we will see a lot of efforts to move software errors to compile time with fancier type systems (dependent, linear, etc). I'm betting on a slightly different approach than Haskell, which I think is too complex and will never fit all use cases. I think the best approach is to have a great language to quickly build DSLs and formal verification methods (ranging from lightweight like property-based testing or type systems to heavyweight like abstract interpretation or theorem proving). So, essentially Racket (Lisp) + lots of formal techniques in a nice package.
(Why "3"? Because the one thing that has bitten me is the old division operator. They were right to kill it with fire. The new "/", just like Haskell's one, always gives floats, which is good for estimates and consistently and obviously bad for money.)
Doesn't Haskell's operate on the Fractional type class? Which includes Rational. Or some money type you wrote yourself.
(And also throwing exceptions on adding dollars to generic ints — that one would be a compile-time error in Haskell, which is of course a good thing. Is this not only a good thing but a critical one in financial context?)
Stuff like that could also cause data corruption. I don't think xvilka was referring to just miscalculations from less strict typing around numbers.
Also, buckminster is right about /.
ghci> :i (/)
class Num a => Fractional a where
(/) :: a -> a -> a
ghci> :m + Data.Ratio
ghci> :i Fractional
instance Integral a => Fractional (Ratio a)
instance Fractional Float
instance Fractional Double
Here's a comment I did in the past about Haskell's treatment of numbers:
Matches my limited experience with Haskell. You get some bad bugs that you don't get in Python because all the stuff like len([1,2,3]) gives int (≡ Haskell's Integer), and 0.1 + 0.2 means the same thing every time. But I'm really interested in the opposite direction: bad bugs you get in Python but not in Haskell.
import qualified Data.ByteString as B
import qualified Data.ByteString.Char8 as C
main = do
let x = 100
print (x * x)
let y:_ = B.unpack (C.pack "foo")
--let z = x * y
Some of the options we discussed...
- Is your plan to sell the company in a year or two? Then you will probably write a lot of throwaway code, and speed of development of basic stuff is most important. If you want this, I'll hire you a team of Python or NodeJS or Ruby programmers.
- Is your plan to have software that supports your company over the long term, but the goal of the software itself is more around cost savings? Is the software development team going to be a cost centre? If so, you will end up with a revolving door of programmers coming in for short periods of time to work on it? If you want this, I will hire a team of Java or Go or C# programmers.
- Do you want to build very technically complicated software as a differentiation strategy? Then you will be looking at a team of very smart software developers who love their craft with a passion that will be a bit foreign to non-technical staff. If you want this, I'll hire a team of Haskell / Lisp / Ocaml / F# programmers.
At the time, the rest of the leadership team wanted the last option, so that's the software team we built. As far as I remember it worked quite well, I remember that there was only one significant bug that made it into production.
You can see the backgrounds of the Haskell team here - https://iohk.io/team/#cardano
I've found the one general thing is a strong academic background. I joined the Haskell team as a test engineer coming from several years in software engineering (Python and C#) to learn more about Haskell and Formal Methods. Unfortunately there aren't any jobs up at the moment so I can't show the reqs, however there's a compiler engineer role that requires Haskell. https://iohk.io/en/careers/fk03jlb/functional-compiler-engin...
The first time was at Uber, where a side project I had started in Haskell proved to be something we needed, so I spent a year building on top of that.
My second time was at LeapYear, whose stack was (and I believe still is) predominantly Haskell.
Both good experiences - happy to elaborate on either.
It's probably easier to join an organization that is already positive towards it.
Find a small, relatively independent project and make the case to try it out.