<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I'd like to understand this issue from the psychological aspect, that readable doesn't mean reasonable that much, while being readable well serves Illusion of control [1] of projects under management, for bosses in Bullshit Jobs[2], we actually need to be in flow state [3] to properly reason about (including reading) an important piece of code. It's not possible with just trivial effort or even in a hurry, even you wrote the code yourself, if not in resonance with the mindset behind the code.<div class=""><br class=""></div><div class="">Within many (usually large) corporate codebase, you can easily read any small unit of code, so as to perceive that all of them are doing really useful things for each's own purpose, but very hard to discover how business goals can be fulfilled by the whole codebase. So long as business consultants and stakeholders don't speak a programming language, code in our PL won't express business logics directly. I had assumed the role of a translator between programmers and business users earlier in my career, i.e. doing requirement analysis & design implementation per ad-hoc basis, I would suggest that there are really big gaps.</div><div class=""><br class=""></div><div class="">I love Haskell and I'd like to say, I don't expect Haskell code being easy to read, but for truly effective definitions of the problem and the solution, Haskell code should be really easier to reason about with the ultimate goal in mind.<br class=""><div class=""><br class=""></div><div class="">[1] <a href="https://en.wikipedia.org/wiki/Illusion_of_control" class="">https://en.wikipedia.org/wiki/Illusion_of_contro</a></div><div class="">[2] <a href="https://en.wikipedia.org/wiki/Bullshit_Jobs" class="">https://en.wikipedia.org/wiki/Bullshit_Jobs</a></div><div class="">[3] <a href="https://en.wikipedia.org/wiki/Flow_(psychology)" class="">https://en.wikipedia.org/wiki/Flow_(psychology)</a> </div><div class=""><br class=""></div><div class="">Compl<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 2020-09-19, at 23:02, Misja Alma <<a href="mailto:misja.alma@gmail.com" class="">misja.alma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">I have been writing Haskell in my spare time for a couple of years now, but when I showed some code lately to a friend he remarked that he didn't find it very readable. Actually I agree, when I look at my own code of a couple of months old I have trouble figuring out too what exactly it is doing.</div><div class=""><br class=""></div><div class="">I'm coming from a Java and Scala background and there, especially for Java, are some generally accepted best practices that make sure that your teammates don't have too much trouble reading your code. E.g. write short functions with a single responsibility, use variable, class and function names that explain what they are meant for, etc.</div><div class=""><br class=""></div><div class="">I think some of those best practices, like short functions with single responsibility, are useful for Haskell as well. But Haskell is a different language than Java and has its own strong points and pitfalls regarding readability, so it probably needs different coding standards as well.</div><div class=""><br class=""></div><div class="">I have been looking on the Internet if I could find some tips about improving readability but all I could find was <a href="http://www.haskellforall.com/" class="">http://www.haskellforall.com/</a>. Although there are some useful tips in there, this site seems to be aimed at making Haskell easier to read for newcomers from other languages. What I am interested in are tips from real projects that are built by real teams.</div><div class="">Does anybody have any tips, or are there some sites or books that I could read about this topic?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Misja</div><div class=""><br class=""></div></div>
_______________________________________________<br class="">Haskell-Cafe mailing list<br class="">To (un)subscribe, modify options or view archives go to:<br class=""><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">Only members subscribed via the mailman list are allowed to post.</div></blockquote></div><br class=""></div></div></div></body></html>