
Hello Ian and Mario.
We have retina screens, GPU accelerated rendering and magical auto-completion.
Who's "we"? 1 and 2 are constrained by money. 1 and 3 are also constrained by personal preference.
I need a _big_ screen because I also do photo processing beside coding, and I can't afford 2 screens, one big and another high density.
Command shell is a very old and peculiar human interface — if human at all. They had 80 character wide screens and visibly lagging connexion. We have retina screens, GPU accelerated rendering and magical auto-completion.
You might have that. I, as a blind braille display user, have one line of at most 80 characters. When I am traveling, I typically only have 40 characters. Given these constraints, I still consider a command line interface superior to any sort of buttonized nonesense. But thats just me, apparently.
This is not how I expected my message to be understood. I did not mean to imply that every Haskell programmer has or should have a retina screen and a high performance GPU — only that, as a profession, we have way better tools now than back then. In humanities, it is usual for there to be either a normal distribution or a Pareto distribution in any large enough sample of data. So, unlike in precise sciences, a counter-example does not refute a proposition. What matters is that there is a trend. And there is a trend associated with larger and finer displays. It dawns on even the most _«old school»_ people by now. See for example a letter on Linux Kernel Mailing List.[1]
When I tile my terminal windows on my display, I can have 6 terminals visible at one time, and that's because I have them three wide. And I could still fit 80% of a fourth one side-by-side.
And guess what? That's with my default "100x50" terminal window (go to your gnome terminal settings, you'll find that the 80x25 thing is just an initial default that you can change), not with some 80x25 one. And that's with a font that has anti-aliasing and isn't some pixelated mess.
I have no specific insight about how to optimize readability for people that listen to code[2] or sense it with their hands. What I am sure of is that there are better ways to go about it than dwelling in the past. [1]: https://lkml.org/lkml/2020/5/29/1038 [2]: https://www.vincit.fi/fi/software-development-450-words-per-minute/

Am 21.09.20 um 12:05 schrieb Ignat Insarov:
I did not mean to imply that every Haskell programmer has or should have a retina screen and a high performance GPU — only that, as a profession, we have way better tools now than back then.
In humanities, it is usual for there to be either a normal distribution or a Pareto distribution in any large enough sample of data. So, unlike in precise sciences, a counter-example does not refute a proposition. What matters is that there is a trend. And there is a trend associated with larger and finer displays. It dawns on even the most _«old school»_ people by now. See for example a letter on Linux Kernel Mailing List.[1]
What you and Mr. Torvalds forget is that there is a reason why newspapers are written in relatively small columns. Even scientific papers are often printed in two column mode. Typesetting has been done since a few 100 years and has for the most time been an analog technique, so it mostly wasn't limited by available resolution. The point is that humans aren't good at reading text when the line length exceeds roughly 80 characters because when you jump from the far right to the far left of the text, it gets hard to correctly identify where the next line starts. A value of 60 is ideal for non-indented text. Thus considering indentation that is not too deep, say (usually) not exceeding 5 levels a 4 spaces makes 20 chars, which means max. line length is ideal at 80 and should not exceed 100 (or 90 with 2 spaces for indentation). I can view files in fullscreen mode if forced to do so by the author of the code but I hate it. This has nothing to do with being old-school.
When I tile my terminal windows on my display, I can have 6 terminals visible at one time, and that's because I have them three wide. And I could still fit 80% of a fourth one side-by-side.
Using a laptop with max. 15 inch display? How old are you? People over 50 years or so usually have trouble reading such small print, no matter how great the resolution. So (apart from the arguments above) screen size often limits how much text can be displayed in a readable fashion. Cheers Ben

What you and Mr. Torvalds forget is that there is a reason why newspapers are written in relatively small columns. Even scientific papers are often printed in two column mode. Typesetting has been done since a few 100 years and has for the most time been an analog technique, so it mostly wasn't limited by available resolution. The point is that humans aren't good at reading text when the line length exceeds roughly 80 characters because when you jump from the far right to the far left of the text, it gets hard to correctly identify where the next line starts. A value of 60 is ideal for non-indented text. Thus considering indentation that is not too deep, say (usually) not exceeding 5 levels a 4 spaces makes 20 chars, which means max. line length is ideal at 80 and should not exceed 100 (or 90 with 2 spaces for indentation).
I can view files in fullscreen mode if forced to do so by the author of the code but I hate it. This has nothing to do with being old-school.
This is a fair objection. Absurdly long lines are uncomfortable. In defense, we have: - Syntax highlighting. - Blank lines. - Indentation. - Ragged right edge. - Infinite canvas. This makes lines multiform, so losing the line seems less likely. Further, code is not read like prose — you skim much more, the zig-zag pattern of the usual reading is gone. It seems to me that all this together gives enough freedom that shortening identifiers is not a necessity anymore. I am not aware of any research that substantiates this opinion though.
When I tile my terminal windows on my display, I can have 6 terminals visible at one time, and that's because I have them three wide. And I could still fit 80% of a fourth one side-by-side.
Using a laptop with max. 15 inch display? How old are you? People over 50 years or so usually have trouble reading such small print, no matter how great the resolution. So (apart from the arguments above) screen size often limits how much text can be displayed in a readable fashion.
Linus Torvalds is exactly 50. In any case, this is all adjustable. I zoom in when my eyes are tired.

+1 I am working on a project looking at formal verfication for an open-source real-time operating system called RTEMS - rtems.org http://rtems.org/. I use Haskell to do rapid prototyping of various tools we are building, ultimately to be delivered in python. RTEMS coding standards for both C/C++ and Python mandate a maximum line length of 80, for pretty much the reasons stated by Ben below Regards, Andrew
On 21 Sep 2020, at 20:36, Ben Franksen
wrote: Am 21.09.20 um 12:05 schrieb Ignat Insarov:
I did not mean to imply that every Haskell programmer has or should have a retina screen and a high performance GPU — only that, as a profession, we have way better tools now than back then.
In humanities, it is usual for there to be either a normal distribution or a Pareto distribution in any large enough sample of data. So, unlike in precise sciences, a counter-example does not refute a proposition. What matters is that there is a trend. And there is a trend associated with larger and finer displays. It dawns on even the most _«old school»_ people by now. See for example a letter on Linux Kernel Mailing List.[1]
What you and Mr. Torvalds forget is that there is a reason why newspapers are written in relatively small columns. Even scientific papers are often printed in two column mode. Typesetting has been done since a few 100 years and has for the most time been an analog technique, so it mostly wasn't limited by available resolution. The point is that humans aren't good at reading text when the line length exceeds roughly 80 characters because when you jump from the far right to the far left of the text, it gets hard to correctly identify where the next line starts. A value of 60 is ideal for non-indented text. Thus considering indentation that is not too deep, say (usually) not exceeding 5 levels a 4 spaces makes 20 chars, which means max. line length is ideal at 80 and should not exceed 100 (or 90 with 2 spaces for indentation).
I can view files in fullscreen mode if forced to do so by the author of the code but I hate it. This has nothing to do with being old-school.
When I tile my terminal windows on my display, I can have 6 terminals visible at one time, and that's because I have them three wide. And I could still fit 80% of a fourth one side-by-side.
Using a laptop with max. 15 inch display? How old are you? People over 50 years or so usually have trouble reading such small print, no matter how great the resolution. So (apart from the arguments above) screen size often limits how much text can be displayed in a readable fashion.
Cheers Ben
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Software Foundations & Verification Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ --------------------------------------------------------------------

I use Haskell to do rapid prototyping of various tools we are building, ultimately to be delivered in python.
Off topic: Do you feel the code comes out better when you do it that way? I'm going to share a story I've shared a couple of times, but no one really saw it. I wish it was about a more real word application, but unfortunately I haven't had the opportunity to write those in more than one language to compare and contrast. I took an intro to game programming class in college as an elective for fun and the professor had us implement this old text based game called Hunt the Wumpus 3 times. The first time was text based, the 2nd time was 2D, and the 3rd was 3D (aside from a semester-long group project). I remember the instructions mandating that it is sufficiently OO (object oriented). I didn't think anything of it at the time and everything seemed fine. Note we using C# at the time because later we were going to use a framework like Microsoft's XNA. I ended up using Monogame which is based on XNA Framework. Basically it's a lower level framework compared to something like Unity. One thing that stood out to me was I was unable to reuse anything from the text based game in the 2D one because it had IO intermingled in the code and depended on blocking to get input from the user. The 2D version was using a game loop and was more event driven. That was my first time doing anything like that and it ended up a buggy mess that barely worked right. The third time in 3D I think I pretty much had to start from scratch again, but I got better at the event driven nature of the thing and it turned out ok (it worked). Fast forward in time and I am learning Rust for fun and decide to implement that same text based game because I want to know what it feels like to program in that language vs C#. I thought it turned out was great until I did the same game in Haskell. Still blows my mind today how that language forced me to think about things differently. If I remember right the Haskell solution was 1/3 the code (measured with tokei) (2 source files and 1 test file vs about 9 source files and 4 test files). All the IO ended up near the main function instead of spread out all over the place, and it's not just concise syntax that reduced the amount of code, but a simpler solution in my opinion. The game logic became just a bunch of pure functions in a small library that moved the game from state to state in an immutable game object. I haven't tried it, but I imagine I would have been able to reuse the game logic in a 2D game because the logic wasn't coupled to and dependent on IO blocking. I think the purely functional nature of Haskell, especially the type discipline around IO effects, drove me to a better solution. It's kind of funny in in retrospect I find it hard not to just blame myself for over-complicating it. Some of that does come down to lack of experience at the time. However, I work professionally in C# and most of the code I see seems like an over-complicated zoo with IO and partial functions everywhere. If your interested you can judge it for yourself: C# text based: https://github.com/willbush/hunt-the-wumpus C# 3D with primitive shapes: https://github.com/willbush/hunt-the-wumpus-3d Rust text based: https://github.com/willbush/wump Haskell text based: https://github.com/willbush/hwump I have the 2D code in a private repo because it's such a train wreck that I didn't want anyone to see it. I really don't care anymore so I can open-source it if anyone reads this far and cares to see it. I later realized the architecture I ran across is basically this: https://blog.ploeh.dk/2016/03/18/functional-architecture-is-ports-and-adapte... On Tue, Sep 22, 2020 at 1:40 PM Andrew Butterfield < Andrew.Butterfield@scss.tcd.ie> wrote:
+1
I am working on a project looking at formal verfication for an open-source real-time operating system called RTEMS - rtems.org. I use Haskell to do rapid prototyping of various tools we are building, ultimately to be delivered in python.
RTEMS coding standards for both C/C++ and Python mandate a maximum line length of 80, for pretty much the reasons stated by Ben below
Regards, Andrew
On 21 Sep 2020, at 20:36, Ben Franksen
wrote: Am 21.09.20 um 12:05 schrieb Ignat Insarov:
I did not mean to imply that every Haskell programmer has or should have a retina screen and a high performance GPU — only that, as a profession, we have way better tools now than back then.
In humanities, it is usual for there to be either a normal distribution or a Pareto distribution in any large enough sample of data. So, unlike in precise sciences, a counter-example does not refute a proposition. What matters is that there is a trend. And there is a trend associated with larger and finer displays. It dawns on even the most _«old school»_ people by now. See for example a letter on Linux Kernel Mailing List.[1]
What you and Mr. Torvalds forget is that there is a reason why newspapers are written in relatively small columns. Even scientific papers are often printed in two column mode. Typesetting has been done since a few 100 years and has for the most time been an analog technique, so it mostly wasn't limited by available resolution. The point is that humans aren't good at reading text when the line length exceeds roughly 80 characters because when you jump from the far right to the far left of the text, it gets hard to correctly identify where the next line starts. A value of 60 is ideal for non-indented text. Thus considering indentation that is not too deep, say (usually) not exceeding 5 levels a 4 spaces makes 20 chars, which means max. line length is ideal at 80 and should not exceed 100 (or 90 with 2 spaces for indentation).
I can view files in fullscreen mode if forced to do so by the author of the code but I hate it. This has nothing to do with being old-school.
When I tile my terminal windows on my display, I can have 6 terminals visible at one time, and that's because I have them three wide. And I could still fit 80% of a fourth one side-by-side.
Using a laptop with max. 15 inch display? How old are you? People over 50 years or so usually have trouble reading such small print, no matter how great the resolution. So (apart from the arguments above) screen size often limits how much text can be displayed in a readable fashion.
Cheers Ben
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Software Foundations & Verification Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ --------------------------------------------------------------------
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
participants (4)
-
Andrew Butterfield
-
Ben Franksen
-
Ignat Insarov
-
Will Bush