3 ms·
"1) Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, go
by bpyne 7y ago
"1) Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, good luck troubleshooting it under stress. And real systems do break, no matter type safety."
Let's assume that your on call person is a developer. (If the person is not a developer, (s)he is not going to comprehend any language.)
1) If your application is written in Haskell, the on call developer would more than likely have been involved in the code base and reads Haskell. Your assertion about not comprehending it seems suspect.
2) You have a serious process issue if a developer is woken from a sound sleep to track down, correct, thoroughly test, and promote a fix for the bug in the middle of the night. The number of cases in which this happens should be close enough to zero to call it zero.
Your comment sounds like an attempt to cast Haskell as a purely academic language because it fails a (poorly) made up real world scenario. I'm NOT a Haskell-er so I don't feel a need to defend it. I do find the reasoning behind the criticism poorly thought out.
- oarabbus_ 7y ago1) do you mean to imply all languages are equally parseable? 2) You’ve never worked in a company where a bug brought down prod and an on-call has to fix it?
- bpyne 7y ago1) No, that would be ridiculous. My point is that a developer working with Haskell daily to develop an application would have no problem reading it in the middle of the night. The biggest problem for a developer, who may not have written the module in question, is not understanding the requirements for the module. 2) Early on and even then rarely. After working in a hospital writing and supporting an electronic patient chart system, I found it hard pretending that anything short of life and death was serious enough to be woken over.