An imperative programmer tries to learn Haskell
in all the years of using imperative programming languages, my brainâs adapted to that paradigm of human-computer interaction and itâd be far too much effort, for little or uncertain reward, to really become productive in a pure functional paradigm.
Iâd like to know what variety of imperative programming Thane has experienced. Monolithic? or OOP? Because I suspect itâs something about distributed state that makes OOP quite a different mindset. My background before I met Haskell was monolithic imperative; I didnât suffer the brain-twisting that seems to have put off Thane.
I found the first few paragraphs at âSetupâ/âHello Worldâ rather wanting to have the cake and eat it.
Itâs really odd to me that all the Haskell tutorials I could find didnât start by describing the tooling and how to navigate the basics of building a standalone Haskell application. In fact, they seems to focus pretty much all of their attention on the language and its use via GHCi.
Is tooling a differentiator amongst languages? Isnât it much of a muchness to do essentially the same job irrespective of language or paradigm? Then if somebody wants to quickly get a feel for how different Haskell is, the tooling is only a distraction â even if itâs a breeze to get going. And Haskell seems not to be:
I was a little taken aback at the complexity of the Haskell installation process. âŚ
Only after writing my first âHello worldâ application manually did I discover the existence of and how to use cabal, and how it wouldâve made my life a little easier to initialize and build standalone Haskell applications. Although, I couldâve done with some simple way of adding dependencies via the CLI, because I couldnât really figure out the.cabalfileâs syntax.
Why is someone whoâs dipping their toe in the water worrying about building standalone applications? cabal does indeed add to the huge learning curve. Just edit a text file and feed it to GHCi; put import statements to grab the dependencies; worry about versioning later.
Yes.
Does that make the authorâs perspective make more sense?
âonly making valid program states representable in codeâ
(was the motivation stated in the first paragraph) Is that perspective influenced by tooling?
The reason for giving up on Haskell didnât seem to be that ghcup/cabal/stack/HLS need a functional mindset rather than imperative. Do they?
Perhaps we should just stop making more language features, and concentrate on getting the tooling more like Rust/Go(?)
If Thane was approaching Haskell with a view to changing jobs or choosing a platform for a new project, tooling would be more of a factor. But that wasnât stated as an objective.
Or perhaps it was an all-round unpleasant experience, and the article is an after-the-fact rag-bag of reasons?