Only a person from the team who wrote the code to begin with should create an emergency fix. Since any developer from that team already knows Haskell, from having worked on the code base, the criticism is ridiculous.
We're all on the same team at work (there's only the six of us), but that doesn't mean I know all the details of my coworkers work. It's also not uncommon that the dev available at 4am is not the one who wrote the code himself.
As I pointed out in my previous post, I do feel the language can be a non-trivial factor in allowing a dev like myself to be confident in developing a fix for my coworkers code at 4am.
However I don't know Haskell, so I have no idea how it fares in this regard.
I can understand not knowing the details of your coworkers' modules. This has been true everywhere I worked. However.....
Where I work now, on-call was long ago relegated to nothing more than a routing task. The on-call person takes the initial call, figures out who best can solve it, and contacts the person. The guy on my team who writes only in Javascript and Python would NEVER be in the position to make a critical fix overnight in a Java module. For those of us who work in Java, reading the language is trivial but understanding what the module is supposed to do from a high level is non-trivial. People who work in Haskell daily would be the same.
This is what I tried to call out. A Haskell developer called at 4am would have no more problem reading Haskell code than I would have reading Java code. While a Javascript developer should NOT try to issue a critical patch in a language (s)he doesn't work in, regardless if the language is Haskell, Python, etc. Any organization requiring you to do so is poorly managed.
> This is what I tried to call out. A Haskell developer called at 4am would have no more problem reading Haskell code than I would have reading Java code.
Do you agree there's a spectrum here (with stuff like Brainfuck being on one end)? If so, I think it's a valid question to ask about a language.
Maybe Haskell is just as easy as Java, maybe it is slightly more difficult, maybe it is slightly easier.
For example, you can't really do embedded DSL's in Java, but you can in Haskell. If my coworker had used that and I had not yet had time to study it, could it be I would struggle a bit more with grokking his code? I dunno, at least to me it seems possible, but since I've not really used Haskell it might be entirely different.
"Do you agree there's a spectrum here (with stuff like Brainfuck being on one end)?"
I'm in complete agreement with you. My contention is that a person who works with a certain language, even Brainfuck, all day every day is going to be able to read it as easily as a person who works in a more "popular" language like Java: even if it's at 4am. Anyone who doesn't work in the language shouldn't be reading it with the goal of implementing a critical fix at 4am. That person should contact a team member who does work in the language.
I'm contending that the 4am scenario, as posed by the parent commenter, is a process issue not a language issue. If a manager requires that whoever answers the phone at 4am fixes the problem, even if the person has no knowledge of the language or requirements of the module, then his/her employees should be running to another job because that manager is bad for your health and livelihood.
Well yeah reading Brainfuck is rather easy after all, it's just a few symbols. Understanding what the code does and what it's trying to do is something else, and there I think language matters a whole lot.
For example, const helps me a lot when trying to understand C++ code. If I see a const reference, I know this bit of code I have in front of me can't modify whatever it is referencing. My language at work doesn't have const references, so I'm never quite sure if a call does modification as a side effect or not. This is the kind of stuff that I think can matter when trying to fix something at 4am.
Now, Haskell as I understand it is rather pure, so side effects like that are not a big issue. But on the other hand it allows for embedded DSL's from what I understand, which perhaps could be an issue if my coworker were to get creative. Though as I said I have no background to judge Haskell on this, I just thought it was a valid thing to be concerned about.
