This is in fact a timely question! (Hope it wasn't homework...)

As someone said somewhere, "Now it is the time for Functional Programming to fail", just like any other software design relig... methodology before it.

Some recent books which try to address these issues are:

• Alexander Granin: Functional Design and Architecture. (Manning, 2024)
  Still in my "to read" stack, to which I unfortunately "Keep on Pushin'" (like the Impressions sang)...
  
• Robert C. (a.k.a. "uncle Bob") Martin: Functional Design. (Addison-Wesley, 2024)
  NOTE: This is a really bad book! But it serves to show that the big publishers and famous authors are beginning to smell money to be made in FP, and that is encouraging!
  

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.

On a somewhat related note:

• Recall Alan Perlis' Epigram #59 of Programming:
  "In English every word can be verbed. Would that it were so in our programming languages."
  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...
• ...but perhaps a nightmare for the newcomer? At least the book
  Felienne Hermans: The Programmer's Brain. (Manning,2021)
  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.
  

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.

Haskell does reduce time between introductions of defects and their discoveries. Many defects do not pass compiler type checks, for example.

Monadic code allows one to combine local state and safe and atomic communication between different (parallel) parts of the program.

сб, 7 дек. 2024 г. в 15:45, Mostafa Touny via Haskell-Cafe <haskell-cafe@haskell.org>:

Dear Haskellers,
I hope my email finds you in a good shape.

Software engineers usually deviate away from Haskell, in the name of rapid development.

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.

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.

Discussion.
- Do you agree category and type theory could reduce projects costs?
- Is it true, no guideline is designed for demonstrating their worthiness?

Sincerely,
Mostafa Touny
https://mostafatouny.github.io/
_______________________________________________
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.

_______________________________________________
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.

-- 
Matti Nykänen