<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>This is in fact a timely question! (Hope it wasn't homework...)</p>
    <p>As someone said somewhere, "Now it is the time for Functional
      Programming to fail", just like any other software design relig...
      methodology before it.</p>
    <p>Some recent books which try to address these issues are:</p>
    <ul>
      <li>Alexander Granin: <i>Functional Design and Architecture</i>.
        (Manning, 2024)<br>
        Still in my "to read" stack, to which I unfortunately "Keep on
        Pushin'" (like the Impressions sang)...<br>
      </li>
      <li>Robert C. (a.k.a. "uncle Bob") Martin: Functional Design.
        (Addison-Wesley, 2024)<br>
        NOTE: This is a <b>really bad</b> book! But it serves to show
        that the big publishers and famous authors are beginning to
        smell money to be made in FP, and <u>that</u> is encouraging!<br>
      </li>
    </ul>
    <p>As a recently retired university lecturer of BS... sorry, CS, I
      cannot really claim any deep knowledge of the field, since my
      specialty was in algorithmics and automata.</p>
    <p>On a somewhat related note:</p>
    <ul>
      <li>Recall Alan Perlis' Epigram #59 of Programming:<br>
        "In English every word can be verbed. Would that it were
        so in our programming languages."<br>
        FP (and especially Haskell) goes some way towards that goal by
        not separating functions and control structures as tightly as
        imperative programming languages. Great for the seasoned
        programmer...</li>
      <li>...but perhaps a nightmare for the newcomer? At least the book<br>
        Felienne Hermans: <i>The Programmer's Brain</i>. (Manning,2021)
        <br>
        seems to imply (but does not directly claim) so, because it says
        that we humans rely on "anchors" or words whose meaning stays
        the same while we are learning new concepts.<br>
      </li>
    </ul>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Serguey Zefirov kirjoitti 7.12.2024 klo
      20.35:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABFQQ=BebhYsYJ2A+QejC4Svqr2SP73kpCA37LdDm2ckezxuyg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>The axiom of software engineering is "the longer the time
          between introduction of defect and its' discovery, the bigger
          the cost of fixing defect." This usually comes from "error in
          requirements is the hardest to fix," but is true in general
          too.<br>
        </div>
        <div><br>
        </div>
        <div>Haskell does reduce time between introductions of defects
          and their discoveries. Many defects do not pass compiler type
          checks, for example.</div>
        <div><br>
        </div>
        <div>Monadic code allows one to combine local state and safe and
          atomic communication between different (parallel) parts of the
          program.</div>
      </div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">сб, 7 дек. 2024 г. в 15:45,
          Mostafa Touny via Haskell-Cafe <<a
            href="mailto:haskell-cafe@haskell.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">haskell-cafe@haskell.org</a>>:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
          Haskellers,<br>
          I hope my email finds you in a good shape.<br>
          <br>
          Software engineers usually deviate away from Haskell, in the
          name of rapid development.<br>
          <br>
          In Pure Math, I can see the power of abstraction; It resulted
          in broad applications, with a sustainable and scalable usage
          in all humanity's sciences. Software development should
          benefit as well, avoiding technical debts and refactoring
          costs. Haskell seems more promising as it is empowered by
          category and type theory.<br>
          <br>
          Nonetheless, I cannot find a single management methodology,
          like Eric Ries' lean startup and iterative agile, that
          demonstrates the power of functional programming from the
          perspective of project management.<br>
          <br>
          Discussion.<br>
          - Do you agree category and type theory could reduce projects
          costs?<br>
          - Is it true, no guideline is designed for demonstrating their
          worthiness?<br>
          <br>
          Sincerely,<br>
          Mostafa Touny<br>
          <a href="https://mostafatouny.github.io/" rel="noreferrer"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://mostafatouny.github.io/</a><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"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">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>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Matti Nykänen</pre>
  </body>
</html>