Ah, so hard to read. Look, in the web of the written word, it just doesn't work to use flush justified white text on a black background and a scrawny font weight of 300.
All those things do on a web page is make it hard for people to read your (presumably interesting) message.
I even tried to override the font-weight and text-align in the developer tools, but for some reason that didn't work like it usually does, and I didn't have the patience to pursue it further.
If you could please make this look like a normal website - dark text on a light background, no flush justification, and normal font weight - I would be able to read it. Thanks!
Good writeup, short but some interesting comments and links.
I have also had a journey with Haskell. I really enjoy Haskell and have worked hard on developing skills. That said, there often seems to be other languages that seem better for me, for individual projects. Machine learning? Usually need to use Python. Web development? Hard to beat Rails for productivity. Enterprise Systems? It is usually written in Java. Doing ‘research programming’ to explore data and ideas? I usually favor Common Lisp, but sometimes use Haskell.
For me, I think Haskell will always just be a language I very much like but only occasionally use.
I love Ruby but it has been a few years since anyone paid me to write Ruby code. I wrote some Lisp books in the 1980s, so with a steady cadence I have had Lisp jobs. Lots of Java, which I still think is an OK language.
I'm curious, as a C# developer myself. Why didn't you jump over to F#? I've looked at both as a FP next step for my own career, but I haven't made the plunge with either.
Thanks for the write-up. Really hit the spot for me as someone who doesn't want to get pigeon holed into C# forever.
I would recommend Programming in Haskell by Graham over other introductory texts. Not only is it a small read, Graham does a great job of avoiding the mire and excells at teaching critical concepts with simple examples. You're better off reading Programming in Haskell three or four times than reading some of these more intricate or simplified texts once. It will give you a groundwork of the fundamentals, and you will not have incorrect definitions of important concepts.
The key to Haskell is to think like a functional programmer. Most of us are trained to think in ways other than functional programming. This is a skill that takes time to build, and a book can't necessarily impart upon you.
A issue with today's programmers is that they require instant gratification from their programming languages. Remember that it takes a large investment to learn a foreign language. The more you learn, the more you can express. Haskell and FP takes times to master because they are powerful tools that allow you to express complex ideas succinctly.
So don't get discouraged if it seems foreign, it is. With Haskell you can say a lot with a little, and it will pay dividends for years to come.
A issue with today's programmers is that they require instant gratification from their programming languages. Remember that it takes a large investment to learn a foreign language. The more you learn, the more you can express. Haskell and FP takes times to master because they are powerful tools that allow you to express complex ideas succinctly.
That's not a selling point unless the ROI on that time investment is good. It's a problem with the language and not programmers if there isn't a more gentle learning curve.
I regret not listening to people’s advice about this sooner and spending a lot of time looking for the best Haskell IDE / development tools. In the end, everybody else was right and unfortunately, the current state of the available tools is not good enough. The process that most people seem to use, and the one I also adopted is using my favorite text editor with syntax highlighting.
Wonderful. That's like driving a Lamborghini with a school bus steering wheel.
vim|atom|vscode|.. + plugins can provide all ide features that you need, even better since this is a modular approach, swapping some plugins turns your favourite editor into any ide you like, suitable for many different programming languages
No real minuses discussed here so I thought I'd share some from my FP journey, which was SML -> OCaml -> Haskell -> Clojure. Each had its own sort of enlightenment, both in strengths and weaknesses.
IMO an under-appreciated weakness of Haskell is its culture of poor code quality and engineering practices, e.g. in how code is structured, (not) commented, or named.
Example, inspecting a graph in Haskell via fgl, we encounter the foundational Decomp type [1]:
type Decomp g a b = (MContext a b, g a b)
`a` and `b` are types, and in languages geared towards engineering, we would give them actual names: a is a NodeTag and b is an EdgeTag. But in Haskell it is customary to not provide this information, instead falling back on the type checker to ensure the code is consistent. There is not much effort put into useful naming: map vs mapM vs mapM_...
Second example, the simplex algorithm [2]:
addart :: (Num e, Enum a, Ix a, Num a) =>
Array (a, a) e -> Array (a, a) e
addart a = array ((-1,0),(n,m+n)) $ z ++ xsi ++ b ++ art ++ x
where z = ((-1,0), a!(0,0)) : [ ((-1,j),0) | j <- [1..n] ] ++ [ ((-1,j+n),a!(0,j)) | j <- [1..m] ]
xsi = ((0,0), -colsum a 0) : [ ((0,j),0) | j <- [1..n] ] ++ [ ((0,j+n), -colsum a j) | j <- [1..m] ]
b = [ ((i,0), a!(i,0)) | i <- [1..n] ]
art = [ ((i,j), if i == j then 1 else 0) | i <- [1..n], j <- [1..n] ]
x = [ ((i,j+n), a!(i,j)) | i <- [1..n], j <- [1..m] ]
((_,_),(n,m)) = bounds a
this code is astonishingly compact, but totally impenetrable. It has no comments, useful names, etc. This write-only code is typical
Haskell and its culture have significant weaknesses from an engineering perspective.
This is not an representative code snippet. You can find such hard to read and entangled code in any programming language. I think a very good syntax comparison is offered by Rosetta Code, they show code solutions for over 800 programming task in many different languages https://rosettacode.org/wiki/Category:Programming_Tasks
22 comments
[ 4.2 ms ] story [ 63.3 ms ] threadAll those things do on a web page is make it hard for people to read your (presumably interesting) message.
I even tried to override the font-weight and text-align in the developer tools, but for some reason that didn't work like it usually does, and I didn't have the patience to pursue it further.
If you could please make this look like a normal website - dark text on a light background, no flush justification, and normal font weight - I would be able to read it. Thanks!
I just clicked the "reader mode" button that comes shipped with Firefox, Chrome, and Safari and got on with it.
I have also had a journey with Haskell. I really enjoy Haskell and have worked hard on developing skills. That said, there often seems to be other languages that seem better for me, for individual projects. Machine learning? Usually need to use Python. Web development? Hard to beat Rails for productivity. Enterprise Systems? It is usually written in Java. Doing ‘research programming’ to explore data and ideas? I usually favor Common Lisp, but sometimes use Haskell.
For me, I think Haskell will always just be a language I very much like but only occasionally use.
I love Ruby but it has been a few years since anyone paid me to write Ruby code. I wrote some Lisp books in the 1980s, so with a steady cadence I have had Lisp jobs. Lots of Java, which I still think is an OK language.
Thanks for the write-up. Really hit the spot for me as someone who doesn't want to get pigeon holed into C# forever.
The key to Haskell is to think like a functional programmer. Most of us are trained to think in ways other than functional programming. This is a skill that takes time to build, and a book can't necessarily impart upon you.
A issue with today's programmers is that they require instant gratification from their programming languages. Remember that it takes a large investment to learn a foreign language. The more you learn, the more you can express. Haskell and FP takes times to master because they are powerful tools that allow you to express complex ideas succinctly.
So don't get discouraged if it seems foreign, it is. With Haskell you can say a lot with a little, and it will pay dividends for years to come.
That's not a selling point unless the ROI on that time investment is good. It's a problem with the language and not programmers if there isn't a more gentle learning curve.
Wonderful. That's like driving a Lamborghini with a school bus steering wheel.
intero (types and suggestions from ghc): https://github.com/commercialhaskell/intero
hlint (well, lint): https://github.com/ndmitchell/hlint
Both have bindings at least for Vim and Emacs.
IMO an under-appreciated weakness of Haskell is its culture of poor code quality and engineering practices, e.g. in how code is structured, (not) commented, or named.
Example, inspecting a graph in Haskell via fgl, we encounter the foundational Decomp type [1]:
`a` and `b` are types, and in languages geared towards engineering, we would give them actual names: a is a NodeTag and b is an EdgeTag. But in Haskell it is customary to not provide this information, instead falling back on the type checker to ensure the code is consistent. There is not much effort put into useful naming: map vs mapM vs mapM_...Second example, the simplex algorithm [2]:
this code is astonishingly compact, but totally impenetrable. It has no comments, useful names, etc. This write-only code is typicalHaskell and its culture have significant weaknesses from an engineering perspective.
1: https://hackage.haskell.org/package/fgl-5.6.0.0/docs/Data-Gr...
2: https://hackage.haskell.org/package/dsp-0.2.4/docs/src/Matri...
Haskell examples you've attached are better commented than, say, eigen
https://github.com/PX4/eigen/blob/master/Eigen/src/SparseCho...
not to mention openblas
https://github.com/xianyi/OpenBLAS/blob/develop/lapack/lauu2...