Hacker News Reader

Comment by h91wka | Hacker News Reader

Haskell is a beautiful research language. Its usecase is to supply subjects for PhDs and MScs, which it fulfills perfectly. Also it's extremely fun to learn and play with.

I would never bring it to the production though, reasons being:

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.

2) It's a research language, and a big part of the research is about control flow. And therefore haskell has _way too many_ ways to combine things: monad transformers of different flavors, applicative functors, arrows, iteratees, you name it. And libraries you find on hackage choose _different_ ways to combine things. In the business code you probably want to combine multiple libraries, and you inevitably end up with unholy mess of all these approaches. Dealing with it takes more time than writing business logic.

3) Developers look at these fancy research papers and try to reproduce them. As a result, very basic things become extremely hard and brittle. I saw a real-live example when applying a transform to all fields of a record took a team 2 days of discussion in slack, because "writing this manually?! it won't scale to record with 100 fields".

4) Architecture is extremely sensitive to the initial choices due to isolation of side effects. Because if you suddenly need to do something as simple as logging or reading a config in a place where it wasn't originally anticipated, you're in for a bumpy ride.

View on HN

I've done commercial Haskell work and it was fantastic. Almost all of the things you mention are problems with technical leadership and not Haskell itself. These problems are all very, very easy to deal with.

1) Many of us have also seen the C++ library or application that busts out the template metaprograms at every opportunity. Haskell is the same. Use restraint when bringing in new libraries and programming techniques. (as an aside, I have yet to encounter a single problem that I thought merited the use of arrows)

2) You also see this in other languages, though to a lesser degree. The same techniques we use with other languages work just as well in Haskell: As leadership, form a strong opinion on the best way to write control flow and ensure that everything uses a consistent style.

3) Are your engineers running around implementing random research papers? This has nothing to do with Haskell.

4) In practice, this is almost never a big problem. Refactoring a pure function to an effectful function is easy and safe. In a production setting, almost all of your functions run in some monad already, so it's pretty rare to run into a situation where you suddenly need to percolate effects through many functions.

> problems with technical leadership

I've never been lucky enough to get a full-time Haskell job (nor did I try), so my experience is based on single-man development & prototyping using the existing stuff found on Hackage. I presume that it may be different for a huge organization that can afford to build the entire ecosystem from the ground up while enforcing design rules (and these rules must be created by an exceptionally brilliant architect!). But in other languages you don't have this situation.

> Many of us have also seen the C++ library or application that busts out the template metaprograms at every opportunity.

C++ and boost set standards a bit low, to be honest.

> Are your engineers running around implementing random research papers? This has nothing to do with Haskell.

Not research papers, just the usual business logic. The problem is that research papers set the code style. Also they are not "my engineers".

> In practice, this is almost never a big problem.

It typically is, because changing internal implementation is reflected in the interface, and for each invocation of the function change has to propagate through _the entire_ call stack to some place running in IO monad or whatever.

> almost all of your functions run in some monad already

You defy your own argument. If that's how you design application, what's the point of bothering with side effect isolation then?

The bulk of real Haskell programs do not choose such granular restriction of side-effects that it's unmaintainable. As always, there are tradeoffs. In most applications, the code at application boundaries live in some Monad that are based on IO.

For Example, Yesod gives you the Handler monad, which is based in IO, and really just exists to provide access to runtime/request information, so at the API handler level you can do anything you need to. But what's nice is that not everything has to live in IO, and so in places where it makes sense, such as a parser, we can say that parser doesn't need IO, because that wouldn't make sense.

And my point here is that just having the ability to separate between IO and non-IO is very useful; we also do not have to split every single effect down into it's own special, separate type; in many cases that would just be overkill.

> You defy your own argument. If that's how you design application, what's the point of bothering with side effect isolation then?

I don't understand this.

If you have a monad like

  do
  ...
  _ <- doSomething arg1
  let result :: Result = pureFun arg2 arg3
  ...

How is that not simpler and better than having that pureFun invoke a bunch of side effects and perhaps even mutate something that you have to be aware of? How does this take away the benefits of side effect isolation?

Because as code evolves you may find you need some logging in pureFun and now you have to go and sprinkle some IO wherever pureFun is used, which may propagate to who knows how many other places.

Of course, I suppose there is always unsafePerformIO, at least for those late-night debug sessions.

Why would I need logging inside a pure function?

Because you suspect that it has a bug and need to see intermediate outputs to verify.

Haskell doesn't work that way at all. If you have variables inside a function, due to laziness their values may or may not ever be computed. Moreover, Haskell compiler sort of reduces the equations so the functions are not imperative and the computations would not happen as you expect them to. Logging would not get you anywhere.

However, you can just log the output if you like without putting IO into the function. I see zero reasons why anybody would push such logging into production. It behaves exactly the same way on your own computer as it would in production - it's just a pure function.

I know that Haskell's lazyness adds an extra layer of complexity to this problem.

However, disregarding the implementation details, here is the abstract problem: I have a program which is reading some complex data structure from IO, applying a complex, pure pipeline to it, and sending the reply back through IO.

Now, say the output is not correct in some way. Your only chance of debugging the issue is to somehow visualize some of the intermediate values, right?

This being a pure pipeline, you don't need to have logging in production. You could just log the input value, and when a bug occurs, run the same input value from the logs through a modified version of the original pipeline with some logging sprinkled throughout - you're right on this side.

Now, I expect that there are many situations where adding the logging in production is still preferable - maybe the pure pipeline is in development and some kind sof issues are frequently occurring, maybe the pipeline takes too long to re-run, so it's just easier to have the logs from the first run etc.

OK Thanks for adding some context!

What I'd do is simply break down the larger pure function into smaller pure functions and sequencing them in the monad.

This way you would still retain purity with your functions but you could log every intermediate step by simply logging their output (and its corresponding input). Would probably make the code more maintainable as well.

From what I understand Haskell has great tooling for function profiling. Unfortunately, I got no experience with these yet so I can't say if they'd help you solve such problems.

Edit: Btw sounds like property based testing might work well as a solution to this kind of problem. It works really well with pure functions.

> Of course, I suppose there is always unsafePerformIO, at least for those late-night debug sessions.

For temporary debug output you should probably consider the Debug.Trace module before unsafePerformIO. It has a simpler interface and doesn't introduce the possibility of arbitrary I/O, just text output (and event logging if that's enabled in the RTS).

This happens less often than you might expect.

If you're able to run the code locally, there is a function called Debug.Trace.trace which writes messages to stdout without requiring IO.

If it's a production issue, all you need to do is figure out what is being passed to your function. It's a pure function, so you can always debug it locally once you've got that.

That's right. Java is advertised as a "workman-like language" (today we should say worker-like) because it doesn't require a guru leader to get a working project built.

At my job, software is only have the engineering, we need to save half our brains for product/business issues.

Java is also advertised as "enterprise" language and it can't even encode in its type system that a piece of data can be missing. Or maybe it can, with Optional<T>, thanks Haskell.

I can't tell I had less problems understanding magic container IoC stuff than most Haskell concepts.

> maybe it can, with Optional<T>

Not even that. Java's optionals are almost useless, needlessly verbose, you still don't have pattern matching, and there's also still null to contend with.

To be pedantic, Java perfectly encodes the information that a piece of data can be missing - any type supports null as a valid value. What it can't do is encode the information that a piece of data CAN'T be missing.

To be even more pedantic, Java's primitive types (int instead of Integer etc.) have this feature. They can't be null.

Many others have replied to your concerns already, nevertheless allow me to add my own experience to the pile, as someone writing Haskell for food:

1) For a team of Haskell programmers reading Haskell code is just the norm. It's the same as for a team of Python programmers reading Python code. Also as a side-note: I never in my 15 years of professional life had a 4am call. Maybe I'm lucky, I don't know. In my experience automated tests, code reviews, sane deployment policies, etc... all minimise the chance of this ever happening. Haskell's powerful type system helps a lot here as it saves you from a whole array of problems upfront. I feel much more confident deploying Haskell code to production than code in any other language.

2) In commercial projects engineers tend to do things in sane and simple ways. This is not surprising really. Just cause you can does not mean you should. It's not Haskell specific but a general principle ie. KISS.

3) "Fancy research papers" at times can actually be really helpful. If you happen to have a problem that someone wrote a paper about that saves you time having to rediscover the solution. Having lots of research papers is imho a great strength of Haskell. That being said KISS from above applies here. If your problem is simple then do it simply.

4) Architecture in general is much less sensitive to change in Haskell than in other languages in my experience as the type checker guides you when you want to change your code. Refactoring in Haskell is pure joy. Re logging/configuration/etc... there are well-known patterns to deal with these as you would imagine, it's not like no one had to solve these problems in Haskell before. There are also tools (eg. Debug.Trace) in case you need some quick ad-hoc printf-style debugging. The same really as in any other language.

I don't want to write about all the pros of the language, others have done so already, just wanted to add my own professional experience to the mix.

Agree with #1. I think Elm is probably the best functional language in this regard. Contains all the important bits yet is small and opinionated enough to be easily readable.

If only weren't web only and run as a private project. An elm like language with llvm backend would be amazing

Elm is like the Go of the FP world. It really works for some people, but others find working in a kneecapped language infuriating.

IMO its the best language for absolute beginners to FP.

I think Elm gets old after a couple weeks when you realize how handicapped it is as a language. Personally, I think something like Reason/OCaml is a great place to start. Haskell is a good choice too but laziness adds an additional hurdle. The core of Haskell is actually pretty simple; it's algebraic data types, parametric polymorphism, and typeclasses.

> If only weren't web only and run as a private project.

Yeah, the way the project is run is troubling.

Elm is copy-paste language (too much, maybe can/will be improved)

I write Haskell commercially, and none of the problems you list are problems my team actually has in reality.

Your comment would be much more interesting and constructive if you actually took the time to refute the individual points instead of just saying that it's not a problem for you.

How do you deal with #4?

How is #4 even a problem to begin with?

If anything, it's the inverse: "isolation of side effects" means the architecture is more flexible and lego-like -- as opposed to a spaghetti mess.

And if you need to change interfaces, you are in for one of the smoothest rides, as the compiler will guide you every step of the way to implementing the change wherever it's needed.

> And if you need to change interfaces, you are in for one of the smoothest rides, as the compiler will guide you every step of the way to implementing the change wherever it's needed.

This is the same in any statically typed language. Actually the quality of Haskell/GHC's error messages are limited by constraint-based type inference and languages that have flow-based type inference do a better job IMO.

> This is the same in any statically typed language

Surely not in any statically typed language. Languages like Java cannot encode the same useful information (or rather, you cannot force them to) as languages like Haskell. Specifically, you cannot make them enforce lack/presence of IO in their types. Most mainstream statically typed languages cannot do that, in fact.

But it's considered good practice in Haskell to keep IO out of the main logic of the program and basically use it as little as possible. Haskell is certainly not an IO-focused language like Go and Rust. The IO monad is almost more of a deterrent than a tool.

That's only partially true. Of course a Haskell program needs to do IO to be useful. The IO Monad is also not a deterrent, where did you get that idea? Haskell is very much IO focused, in fact it's been jokingly called "the world's best imperative language"!

Even then, in Haskell you can say "this doesn't do IO" which you cannot in most languages!

It's also just an example of the expressiveness of the type system, which "most statically typed" cannot enforce or sometimes even express.

> How is #4 even a problem to begin with?

Lets say you are making an RPG where you can equip items. You write a lot of pure functions and behavior for stat adjustments etc. Then the designer comes to you and say that items are no longer constants, every item needs a durability which goes down on use. In Java this would be a few line change, just add a new field in items and add a line to subtract it in relevant places. In Haskell you would need to bubble up the new item change to the global state and properly set it in each part of the code where you use items. If you aren't careful you can easily miss to properly bubble it up somewhere and the item doesn't get updated, or you might have the same item referenced in several places and now you'd have to refactor it to have a global item pool to since tracking down all places that should be updated is not feasible.

Can you provide an example (even in pseudocode, syntax doesn't matter here)?

I don't think that's how you'd handle a state change in idiomatic Haskell. What you propose sounds very error-prone.

Not a Haskell expert, but I think I know what you mean -you are passing items by value to many functions and complain it's not modified in others, when you call them, or you need to compose flow so updates are properly "bubbled".

But with assumption that code was working before and you had for example function: use :: Item -> Item, and you change duration in this function, what else do you need to change to "bubble" new state? I don't get this.

BTW What's the problem with global store and passing only IDs ? I feel like this is probably valid approach and anyway ECS are implemented in similar manner AFAIK - https://en.m.wikipedia.org/wiki/Entity_component_system

As I understand it, a function use :: Item -> Item in Haskell guarantees that it can't change any property of any item;even more so if the function were use :: Item -> Effect, as could be done on the initial assumption that Items can't change.

In general you can't mutate records. Nothing prevents you from making a new one that's slightly different though. It just won't change the already existing one.

In practice this is not actually a problem. It just takes a little getting used to to get yourself out of the 'memory-address as identity' mindset that procedural languages have.

> In Java this would be a few line change, just add a new field in items and add a line to subtract it in relevant places.

And then find out that since items used to be constants all instances of a given type of item are actually the same item object, so modifying one unexpectedly affects them all. Or worse, sometimes items are copied and sometimes they're shared by reference, so whether they're affected depends on each item's individual history.

One of the benefits of Haskell is that it forces you to think through these aspects of the API in advance. A mutable object with its own distinct identity and state is a very different concept from an immutable constant and the design should reflect this. Changing one into the other is not an action to be taken lightly.

>Production code should be understandable by an on-call person at 4 am.

I don't like the "simple language means understandable code" argument being thrown around like it was some obvious fact. I'm currently working on a project whose major component is a byzantine home-grown message passing framework written in pretty much Java-in-C++ (old school OO with liberal use of shared pointers. Not that I would call C++ in any form "simple", but I do think that C++ without template magic is simpler than Haskell with GHC magic, or, say, any Lisp with a lot of macros). Maybe it's a case of grass being greener on the other side, but I'd gladly take a monad transformer stack or a DSL written in Lisp macros over doing the same song and a dance over and over again just to implent a tiny new functionality, or trying to deduce the logic from someone else's sea of boilerplate.

I mean, taking this logic to extreme, one could say that code written in assembly is easy to understand: it's adding a value to EAX now, then it jumps over there...

This being said, Haskell does have something in it that encourages one to design a ballistic algebra that runs in the type system before even pointing a gun at one's foot.

> This being said, Haskell does have something in it that encourages one to design a ballistic algebra that runs in the type system before even pointing a gun at one's foot.

Haskell is not even a total language, so type system doesn't magically divert gun from your feet. You can easily prove False in Haskell (there's a Prelude function for doing this!), enough said. And if you want types keep your feet safe, it's possible of course, at a _great_ cost, and not in Haskell.

I was referencing an old joke; that Haskell programmers allegedly spend so much time polishing their types that they never get around to actually write anything useful.

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

1) 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?

1) 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.

Do you have any evidence to back this up?

In my experience working in the largest Haskell team in the world, dealing with various applications and services in production: none of what you said is close to reality.

All the evidence is out there in Hackage. I backed up my points with some argumentation at least, and you dismissed it based on personal experience that we have no way of verifying. So, not changing my mind yet.

You have hardly backed anything up, I don't see any links in your original post. From my perspective, your thoughts are as anecdotal of that of the other poster.

What links do you need? If you know anything at all about the Haskell ecosystem, you already know where to find all these papers/sites/presentations about arrows, pipes, lenses and what not.

Yes, I know where to find descriptions of language features. That doesn't prove to me that they're often misused or that I might commonly have a problem with code that others have written because of it.

You've recounted your experience and detailed that you have seen issues with things in Hackage, and I won't claim your experience is invalid. I just won't let you claim your experience is that much more valid than someone else's without proof.

At which company is the largest Haskell team in the world?

StanChart, the Cortex team. Equivalent to the Slang/SecDB team at Goldman.

Maybe you could shed some light on how to deal with the issues mentioned?

Especially point 4 sounds very painful. I frequently have to add logging or special case handling at different places in our code base.

In case you need to add logging, you can always close your eyes and use unsafePerformIO anywhere, since from the view of the application, logging is just write-only side-effect.

It's all about how much do you isolate sideeffects from each other. If you go nuts with isolation, you loose flexibility. If you write all your code in IO monad (that means any code can have sideeffect), you are as in other languages where you can do sideeffect anywhere you want.

Thanks for the response. Logging doesn't seem to be an issue then, nice.

I'm still curious as to how to introduce variations though.

Frequently we find that we have to introduce "if (settings['special_x']) then DoSpecial else DoCommon" deep in the business logic to handle special cases that arise.

Assuming the existing function did not depend on the settings, how does one best introduce this dependency on the settings? In our code base we can cheat by effectively having the "settings" dictionary as a global variable, though we try to minimize this obviously. But in a pinch at 4am, that might be enough.

How about Haskell, is there a way to "inject" such settings without refactoring all the way to the top?

unsafePerformIO will work. But again, why bother with side effect isolation, if you need to break it to do trivial stuff.

If you're injecting your settings at the root of your reader monad (which almost all Haskell applications are structured around), how many function calls are you between your monad stack and where you need to thread settings to? 3? Maybe 4? This isn't an issue in practise. It's a 4 line diff.

Source: 3 years of pure FP Scala in prod

Of course you can sneak in Debug.Trace everywhere if you don't compile with -XSafe. But by doing this you basically break your own rules.

Then Haskell failed. To quote from Haskell 2010 Language Report, the primary goal of Haskell was: "It should be suitable for teaching, research, and applications, including building large systems".

Applications and building large systems are explicitly goals of Haskell. Haskell was never intended to be a research language.

"Avoid success at all costs" is also an explicit goal of Haskell.

>Haskell was never intended to be a research language.

Intended and actively tried not to be are two different things...

No, that is not an explicit goal of Haskell. To prove otherwise, please quote from Haskell 2010 Language Report.

You know, it's just possible that the Haskell 2010 Language Report is not the only valid statement of the "goals of Haskell".

To clarify, it’s avoid “success at all costs.”

Rather than “avoid success” at all costs.

It’s a joke in the Haskell community that relates to the language’s early history and its ability to break things without much fuss. Things have settled down a lot more in the last few years, hence the shift in emphasis.

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

You can say the same thing about production Java code buried under layers of frameworks, factories, facades, proxies, aspects, annotations, etc. I don't see why readable, maintainable code can't be written as easily in Haskell as Java, C++, Python - you just have to make writing clean code a priority.

I think this points to a difference that I don't see highlighted enough - influential doesn't mean best.

If you are stuck on a plane are you going to watch citizen kane or something from the last couple of years. What about an Akira Kurosawa movie? They top film critics' lists of the 'best' movies, but really they are some of the most influential movies of all time.

Lisp and Haskell aren't the 'best' languages to use the vast majority of the time, but they heavily influential and have contributed a lot to computer science.

>4) Architecture is extremely sensitive to the initial choices due to isolation of side effects. Because if you suddenly need to do something as simple as logging or reading a config in a place where it wasn't originally anticipated, you're in for a bumpy ride.

Not a serious Haskeller at all, so not sure if this is a terrible practice, but for logging, `unsafePerformIO` could work in a pinch without changing types.

>Architecture is extremely sensitive to the initial choices due to isolation of side effects.

This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation.

It requires you to be perfect at Waterfall ( https://en.wikipedia.org/wiki/Waterfall_model ).

Real-world problems laugh at such idealism.

>Architecture is extremely sensitive to the initial choices due to isolation of side effects.

Only if you choose to isolate all side effects from each other. Actually Haskell makes refactoring really easy, so you can adapt your implemention to changing requirements easily.

Why would I need to refactor anything in this situation in the first place?

In what situation? If you predict everything correctly, you don't have to, but I was referring that you don't have to have everything designed upfront, since refactor is much easier and safer than in other languages.

I wanted to make point that that #4 is not true.

Is that 1% not true or 99% not true?

Amortizing the up-front cost of design, into a continuous cost of refactoring every time the requirements change doesn’t make the original claim false.

You are still paying the price of rigidity.

> This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation.

This is simply bs. Haskell is actually a language (that I know of) where, IMO, your initial choices matters least. And that's because it's gives you great refactoring experience.

'Great refactoring experience' relative to what? An imperative language?

Yeah right! I don't have to refactor extensible code.

To most (if not all) production ready languages out there.

Perhaps you didn't understand my point.

Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code.

Why are you spending so much of your time refactoring code? Because your language isn't extensible!

> Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code.

Not a fan of TDD, eh?

TDD has its uses. BDD has its uses. Code first - test later has its uses. YOLO has its uses.

Not a fan of silver bullets.

I don't disagree with the "no silver bullet" quote, but you can't answer every question with that phrase. I also agree re TDD, etc.

But your comment is still odd. Refactoring seems to be a core tenet of modern programming (regardless of TDD). In TDD in particular it's a central part of how you work, and so your remark sounds odd unless you also claim you don't believe in TDD :)

Most languages out there including dynamic ones have built-in IDE support that tracks refactoring down to comments.

Don’t know what the state of Haskell refactoring is now but it looks like until very recently “great refactoring” was “change one thing and then manually fix compiler errors”.

Change one thing and manually fix compiler errors it's what I'm talking about.

Point me to something like that, for, lets say, Python. For example to error when I misuse return value of a function. Or when I decide that this string is no longer a string but a customer name. Or when my function will call IO operation, but it's not allowed to do so. Or when I add new field to a record and its not fully constructed somewhere.

This is what I dislike about Haskell discourse:

- We are a statically typed language with significantly better support for refactoring than anything else out there

- But...

- Let's say Python

Let's say Java, why don't we? A language with significantly better support than "change one thing and manually fix compiler errors".

See IntelliJ's capabilities: https://www.jetbrains.com/help/idea/refactoring-source-code.... (there are 23 subsections)

And even Python's capabilities are significantly better than manually hunting through compiler errors (though obviously not as extensive): https://www.jetbrains.com/help/pycharm/refactoring-source-co...

I guess I took the bait when you "included" dynamic languages, so your little conversation is misleading at best.

On topic: Oh, these are great and I wish Haskell had more of that.

But these are "dumb" actions, really. How about:

* writing terrible code to get something working, then breaking it down and putting it back up as something production ready

* changing core data structure and updating all the code that uses it

* solving some problems in separate projects and combining them together

* copy-pasting code from another project and adjusting it to a current project

All of the above of course without running the program once in between, without changing the desired program's behavior etc.

And no, I don't think you can't do that in Java, I just think that Haskell is better at it.

All of the above are a combination of of trivial automated code refactorings and some manual work because there's no silver bullet:

* writing terrible code to get something working, then breaking it down and putting it back up as something production ready

Automated: Extract method, move code, pull members up/down, rename etc.

* changing core data structure and updating all the code that uses it

Depending on what exactly you're changing. From as simple as automated "update type signatures of all affected functions and methods" to automated "rename" to yes, hunting down compiler errors

* solving some problems in separate projects and combining them together and

* copy-pasting code from another project and adjusting it to a current project

Once again, depending on what and how you combine, using the things from above.

There are more powerful tools than "oh, let's run the compiler for each change and manually fix all the errors". The flow should be "let's run all the automated refactorings and then run the compiler to see if those missed something". And these automated refactorings are often reversible with a simple Cmd/Ctrl-Z.

Ah, yes. And many of these are available even for dynamically typed languages (but not as powerful and sometimes with caveats, for obvious reasons).

Yes, Haskell is worse with those "trivial automated" (due to worse tooling, nothing about the language prevents that), but imo better with those "hunting down compiler errors". And I take easier manual work on hard problems over trivial automation any time.

Java and Python are simply not languages that encourage (or even make possible) writing code that is easy under those changes. In Haskell you have immutability (if something is declared, that's its final value, so I can simply move it around), purity (code that is basically context independent), dumb data structures (no "enterprise boolean" with nontrivial internal state and ceremony to initialize), functional (no code attached to mutable data that may implicitly require data to be in special state), no nulls in flow control (that are invisible to a compiler, so yea good luck moving function around that expects no nulls), ergonomic creation of data/types (so you don't have strings/integers everywhere that are opaque to a compiler).

There is no contest, really. Maybe with some modern languages like Rust or TypeScript, but I haven't tried those.

> And I take easier manual work on hard problems over trivial automation any time.

However, most changes/refactorings I usually encounter are due to trivial problems that can be automated. And I'd love to have those tools for FP where a lot of changes are still just that: rename a function or a field in a data structure, extract a function, rename/move a module, update type signatures etc.

However, it looks like the stronger the static typing, the worse are the tools :) Not enough manpower to take care of them, perhaps?

Yea... that's a trade off, unfortunately, and I won't pick sides here. Stronger static typing has so much potential for tooling, but none of that is reality, sadly.

As for Haskell, I think, it's a combination of manpower (so popularity, really) and the fact that the compiler wasn't developed with tooling in mind.

Thanks for conversation, stranger, and have a nice day!

And same to you, kind stranger!

> most changes/refactorings I usually encounter are due to trivial problems that can be automated

This is interesting because another popular argument against Haskell is "Haskell's type checker can only check trivial properties that can be automated".

Either automating trivial things is valuable or it's not, and the anti-Haskell camp seems not to agree on which!

Automating trivial things is immensely valuable. And yes, Haskell’s type checker can only check a subset of things.

Can you give an example of what you mean by "extensible" here?

Adding a new setter method to a data object buried in 10 layers of abstraction.

In Ruby it's changing the attr_accessor line.

In Haskell objects are immutable, so you need lenses.

Cute how none of this relates to the article. Why do you have a list of straw-man bullet points to rattle off whenever someone says "Haskell"? Who hurt you?

Those don't seem like "straw-man bullet points".

Fine, I'll bite...

(1) "Haskell is unreadable because the business logic gets buried under layers of technobabble." Not observed in practice, and not a property of the language anyway.

(2) List of many things that are supposedly about control flow. They aren't. Also implies that these things are incompatible with each other, which isn't true.

(3) Indeed, some developers try to reproduce research papers out of curiosity some of the time. That's a good thing.

(4) Mostly true, but true in any language, and not due to isolation of side effects.

These are textbook examples of straw manning: representing a caricature of the other side in order to easily argue against it. (But why? Who hurt the poor guy?)

WTF is your oncall person doing reading code at 4am? What state of mind do you expect this person to have at that time? What are they expected to do?

That's a huge red flag.

As for the rest.. I don't think the language was the problem at that team.

What are they meant to do if the world starts burning at 4am? Wait until a reasonable hour? Oncall fires at 4am suck but they're part of running critical services.

You have a runbook. Anything not covered by the runbook escalates to someone who already understands the code.

Are you saying you've never written code and then later came back to it, saying "Who wrote this shit?" and did a git blame, only to find out it was you?

If you can't read your own code, then the language isn't your problem.

Seems like someone never solved a complex problem.

Full on ad-hominem, eh?

and in comparison your comment wasn't?

Who was I attacking? Writing unreadable code isn't a language problem. Even in doc-poor environments, the names and sparse comments should be enough. If not, the language can't help you choose good names.

Good luck remembering complex business logic in your perfectly readable code and all external dependencies (DBs, other microservices, etc.) a few months after you last touched it, and in the middle of the night.

And after a few refactorings.

Most errors have nothing to do with “unreadable code”.

Obviously, I was talking about the situation when it escalated to that person. And if you are going to claim that you know exactly how your code works after a month, then I call bs on that. Not to mention that 1) people leave companies sometimes 2) 3rd party code can break too.

Not obvious.

Look, you've already fucked yourself by needing a 4am custom fix. That isn't a language problem.

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.

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

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.

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.

In the DevOps world, the person who understands the code is the person who got paged for it being broken.

How does that work in practice? In order to page, you should find out if it is the code, and it is indeed broken. I'm guessing all tests passed, so that won't be of much help anymore neither...

In reality, it would be a sysadmin confirming dependencies for this application to run (in the system, network, storage, ...) are functioning as required. If there turns out to be a problem with the application itself, there's no time for development at that point: you roll back. I don't see how the paging developers thing would be able to provide any stability. It's too late for that when you're in production.

In my reality I am the "sysadmin". I am also the "developer". I am the guy who wrote tests (unit and integration). I also configured the CI/CD pipeline.

I am also the guy who puts metrics in place to monitor the health of the system and if any metrics breach alarming thresholds the owner of the service (me!) is automatically paged.

How does a sysadmin know that something is broken anyway, and how does a sysadmin know who needs to get paged? If a sysadmin can make this decision - so can an algorithm.

Much of this is in Google's SRE handbook[1]. The entire notion behind the DevOps concept was to make sure that you don't segregate development and operations.

The people who write crappy code must be the people who wake up at 3am when the crappy code breaks.

>It's too late for that when you're in production.

Bugs will always slip through testing, and things will break even in production. Nobody is perfect - not even Google.

So what do you do when rollback doesn't work, you've tried everything in the playbook but the system/service is still down? Whose job is it to understand how to recover your service? Surely you don't expect the sysadmins to be doing that? They don't understand the system. How could they? They didn't build it.

[1] https://landing.google.com/sre/books/

Just yesterday we got a support call at 2am which quickly escalated to one of my dev coworkers. He had to dig through code to find the problem and push a fix at 3am.

The problem had to be fixed right then as further delays would cause heavy disruptions of the operation for that day, which would have been very bad for our customer.

While support can deal with most issues, it's not entirely uncommon that us devs have to step up and either help fix the issue by analyzing the relevant code, or actually push a fix in the middle of the night.

Reply on news.ycombinator.com