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