That "Show your steps"-tipp is great, will try it out!
Any other tipps for getting more correct (I know that LLMs are essentially autocomplete) output?
Additionally: I wonder whether instructions like "think carefully" or "You are an software engineering interviewee at Google." change anything. It feels like a prime candidate for magic thinking, but I do not understand LLMs well enough, such prompts could well improve the answer somehow.
I find CT highly fascinating, worked through parts of 7 Sketches in Composability and have a functional programming background. I see the appeal, but I came to the conclusion that my time is better spent observing, learning about and designing with abstractions like monads, applicatives and so on rather than to learn the theory behind it.
There seems to be a tiny handful of people that can use category theory as a resource to craft something relevant to software (the stereotypical example in my mind being Edward Kmett of Haskell Fame), but I am certainly not one of them, and that is not something that would change with learning more Category Theory (whatever that might mean: Proving some theorems, discovering more categories, ...)
To the author: I am looking forward to a retrospective at a later time. I wish you a good journey, happy diagram-chasing!
Perfect timing! Last week I struggled to write documentation that would leave me satisfied - this framework explains why: I tried to write a reference, how-to and explanation at the same time. And it also offers the solution: Split it into three parts (create them if they don't exist yet).
What you are describing is a Functor, one the two other important Haskell "design-patterns" (Functor - Applicative - Monad). "Mappable" is a good name insofar as it is more familiar to new folks. However, I like the mathematical name as it forces one to embrace the interface as what it is, as opposed to thinking about Functors as collection of data that can be mapped over. Often this is true, but not always.
A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up.
I am gonna be heavily opinionated, take my words with a bit of salt ;)
Here it goes:
1. One understood monads when one is able to write a monadic interface that behaves like any intermediate haskell would expect it to behave. This is not a hard task.
2. Screw the abstract stuff. While fascinating, really few people understand concepts going from abstract to concrete rather than the other way around. And don't get me wrong, I don't think these kind of people are better theorists or problem solvers, they just have to seem a special relationship with symbols. If you are one of those people, you would likely know - in any case, I would encourage to write 3-5 examples of monads in Haskell or Java or JavaScript or whatever language suits you and go from there.
For 99% of people, monads are best understood by a) using and writing many monadic interfaces and b) forgetting about the whole mathematical background.
What a monad offers is: "1: Do A. After A is done, you can inspect the result of A and do either B or C. 2: You can chain monads of the same type together.". Sounds easy? It is because it is!
The big fuzz about Monads is mainly because prior to monads, doing IO was akward in Haskell. Monads offered a convenient way to do IO (and other interactions with the outside worlds, such as databases, networking, ...) and turn up basically everywhere. There is nothing stopping one from introducing a monadic interface in OO-World, and it is partly done (i.e. "orElse" or "then") in some domains. However, bigger gain is to be expected in Haskell, since the type checking system forces the developer to deal with monads in a disciplined way.
-----
I admit being guilty of having only the title prior to writing the comment. But even with only having read just the word 'monad' in the title together with 'lazy', I knew the author would describe 1) some way of lazily evaluating one thing after another and 2) some way of combining multiple lazily evaluated things with each other. After skimming, this is what the article is about. As always, the interesting stuff is not about the concept of a monad (which is pretty easy), but about how to model/code 1) and 2) in a specific context (in this instance, being lazy evaluation).
> After reading one Python book you can write solid programs in Python.
Okay, so our goal is to write a solid program. Let's see...
> Not so in Haskell, you would need to understand also the extensions of the language which are popular
You can simply go with vanilla Haskell2010. Dealing with strings will be a bit cumbersome, dealing with records will be a bit cumbersome, but you are still at 50% the boilerplate of an average java codebase.
> and understand the best practices (what to use to compose I/O and in which context for example)
No! This is what I was aiming at: You don't have to understand these best practises to have a solid program. Throw everything into one massive do-Block and the resulting program will be at least as solid as the solid python program.
> That and understand how to work with complex types in libraries
I concur that Python documentation is heaps better than Haskell documentation, although we are slowly improving. That said, I think the work is not harder: Learning how to speak with a postgres database or do numerical tasks requires times, period. What is different to Python is that the time spent chasing runtime errors is spent chasing compile errors in Haskell.
Adressing the whitespread conception "It is hard to programm in Haskell because it is pure":
If you can write python, you can write Haskell. Don't believe me?
1. Write your program completely in the IO Monad, in a huge do-block
2. Factor out as much pure functionality as possible (= Have as little code in your big IO-programm as possible.)
Start at 1. and iterate 2. as many times as you please. It will already be a program that prevents many traps that would bite you in other langauges. Haskell knows exactly whether you are looping over an array of strings or an array of chars.
(Why all the buzz about pureness, effects and so on? Well, with Haskell you can design with a high granularity and reliability what sideeffect is caused where. But you are not forced to use that feature.)
Other tipps:
- Build small projects.
- Read as few tutorials on monads as possible. You might even get by with 0.
- The trifecta of Haskell typeclasses are the functor, applicative, monad. I would advise you to not try to understand their mathematical origins, but just look up how the are used. They will crop up naturally when you build even small projects and then they will make sense.
Can you exclude that this is a mental health issue? Something like ADHD, autism, sensory overstimulation might lower your productivity in subtle ways. This is also true for some kinds of bodily malfunction.
Yes, we are on the same page there. I think due to depression during my formative years, I have a mix of slight apathy towards expectations and a slightly off motivation system, which leads me to be very lazy - really only doing what is necessary to get a mantainable product and not so much caring about what other people want. Working in two software companies during studies was okay, but I really hope to sell my own software one day!
Of course it all depends on the application at hand, but databases and other system endpoints are something I treat as volatile. However, I don't commit to the madness of replicating a whole database interface in our codebase. Instead, I find it sufficient to bundle all database access in a single point. (i.e. by using a singleton class). That way, later change is much easier and it's a very low investment in maintenance.
I never went through the over-engineer phase personally. I am a very very lazy person, which leads to me to correct balance most of times: Not enough abstraction, I suffer because of too much change to the code base, too much abstraction, and I feel pissed about my risk management. Since I suffer greatly when I suffer, I avoid suffering in my own code as much as possible. What also helps is that I plan most of my algorithms and program designs on paper, actually touching a computer is the last step in that process.
Additionally: I wonder whether instructions like "think carefully" or "You are an software engineering interviewee at Google." change anything. It feels like a prime candidate for magic thinking, but I do not understand LLMs well enough, such prompts could well improve the answer somehow.