It's not a language problem that you need a 4am custom fix.

It can be a language problem if the person who needs to do a 4am custom fix can't understand what the code is supposed to do.

Or to put it another way: I'd much rather be debugging some BASIC code at 4am than some Brainfuck code.

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.

I think the same person who writes unreadable code in Haskell would write unreadable code in most any other adult language.

You write bug-free code? You verify correctness of distributed and concurrent code on type level? What approach do you use: session types, TLA, separation logic? Sounds super cool, that's some seriously bleeding edge stuff! Does your team have open positions?

No. You don't put yourself in that position that you need a fix at 4am. Roll back to a prior version, or shut the service down, or go into a reduced-functionality mode (e.g., readonly) as you can.

Give yourself time the next day to actually think about the problem with a clear head. At 4am trying to debug code, you're far more likely to cause more problems than fix things.

To me, I read this question the same as "Haskell's not useful when you're stuck in a well with a bomb ticking down." The language isn't the problem. It's the situation that's the problem.

Ok, I won't argue with that. If you don't work with mission critical systems -- sure, #1 doesn't apply to you. Play with any language you like.

Mission-critical systems use SRE principles so no one is debugging code at 4am. If you can't solve a production issue without looking at the source code, you'veong since failed at building a mission critical-system.

Even if your app is 100% bug free and fault-tolerant, sometimes an external system feeds it invalid data and you need to figure out how to contain and revert the damage. That was my last on-call involving reading a lot of code under time pressure (thankfully, not alone and not at 4 am).

All commenters who said "It's your own fault for writing crappy code, duh!" perhaps never worked with anything sufficiently complex and expensive.

I can't upvote your comment enough. The use-case for a developer implementing a fix after being pulled out of sleep should be life-and-death circumstances.