[anfelor]

Perhaps contrary to most people in this thread, I think you should avoid learning lenses or category theory too early. These are great tools, but they take months or even years to master and are not required to write useful code in the language.

I find Haskell very useful for my projects, but to achieve this I restrict myself to the basic subset of the language (Haskell 2010, no fancy extensions such as type families or GADTs) and use few libraries aside from the core libraries. New features and libraries always carry a high learning curve in Haskell and less popular libraries can be buggy. Instead, you will often be more productive just writing the required functionality from scratch (and it will teach you more too!).

At Jane Street, I saw my coworkers learn functional programming in just one week. (some still struggled with monads in the second week -- if that is you, I can recommend Phil's paper: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...). If you are learning Haskell in your free time and with no one experienced to help, it will obviously take you longer. If you have questions, feel free to post on the Haskell IRC or Reddit. Just don't worry that you need to read another tutorial before getting started :)

[doctorpangloss]

    type JokeM a = IO a

    askQuestion :: JokeM String
    askQuestion = do
      putStr "How do you know someone works at Jane Street? "
      hFlush stdout
      getLine

    tellPunchline :: String -> JokeM ()
    tellPunchline _ = putStrLn "They tell you!"

    janeStreetJoke :: JokeM ()
    janeStreetJoke = askQuestion >>= tellPunchline

    main :: IO ()
    main = forever janeStreetJoke

I don't know this feels kind of verbose to me.

[tmountain]

I like this advice, but I would suggest adopting a prelude that has better defaults than what the language ships with.

[edude03]

Is there one you'd recommend?

[TwentyPosts]

...what are lenses? Never heard of those.

[turboponyy]

As with anything Haskell, one could simply reply with "here's the formal definition."

But in easily digestible terms, it's a way to narrow your view over a collection to a subset that satisfies some property, and perhaps perform some operations on that subset.

This video presentation (with a very humorous audience dynamic, might I add) serves as a great introduction by example: https://youtube.com/watch?v=QZy4Yml3LTY

[Zambyte]

I'm going to watch the video, but I'm having trouble understanding how lenses are different from filter, and perhaps map. Is it just a combination of filter and map?

[matt-noonan]

No, it's quite different. A super rough but somewhat accurate starting point is to think of a lens as being like the `.foo.bar.baz` in `myobject.foo.bar.baz`: a way to describe some "location" inside of a data structure, in a way that allows for getting and setting. But lenses are also data, so they can be stored in variables, manipulated, and so on. It's a very useful concept, and very much not required or helpful when learning Haskell. It's also not a core Haskell concept in any sense, just something that has been built on top of Haskell as a library.

[lgas]

Also helpful to note that the "location" can be virtual. For example you could have a lens into the hours field a string that contains an ISO-8601 formatted date, so you could do something like

    let s = "20240722T193456.789-0800"
    putStrLn $ 19840206T193456.789-0800  -- prints "20240722T203456.789-0800"

and they can be composed, so if you have some other lens that gets from your outer structure to an ISO-8601 formatted date string field, let's call that lens `fieldLens` then `fieldLens . hours` will get from your outer structure to the hours field of that date field.