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.
I came up with this trick (reviewing other PRs, after thinking how I would to it) to speed up learning technology at my working place where we don't have enough man power to do mentoring.
> I'm sure there's a lesson there somewhere.
There sure is: Having one goal and being able to allocate all/most resources towards that goal. The problem is that this is not sustainable. Times of crisis usually ends and then what? Then we are back at square one with "How do we allocate our scarse resources between these really important 4-5 goals?"
Concluding: It is certainly refreshing how efficient groups can be once a crisis forces all attention towards one single goal. (Perhaps unfortuntately) that is not a reliable (crisises are usually not predictable) nor sustainable (other goals tend to get neglected in crisis mode).
So does buying more lottery tickets. Surely, the odds at being lucky are better than in playing lottery. However, they are much less predictable than people assume. We tend to systematically overestimate our own influence and underestimate external factors.
Starcraft saved my A-levels, when I realized that school can be considered a game with points and stuff... Turns out that lecture participation had a great ROI! Now, if my future product will have any success, then part of it will be due to the lessons that SC2 ingrained deep into my fabrics of thinking. Besides the countless hours of fun and memories.
I feel that the christian God fits this bill especially well, when you look at him a bit more abstractly: He is able to give purpose (does care and is something absolute rather than mending to what one particular human beliefs), is interested in staying in contact with his creation (as opposed to deistic Gods), values existence so high that 1) it should be contiued eternally and 2) not in a replaced, but a renewed form. Many christians, many opinions, but I feel confident in this faith. I can recommend C.S.Lewis, who is great about putting God, heaven, hell in terms that make sense and don't reek of religious fanaticism.
I would be Buddhist if I would not be christian, but I am glad I can be christian. If what I believe is true, then boy are we lucky!
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.