[Haskell-cafe] Engineering Value of Functional Programming

Matti Nykänen matti.johannes.nykanen at gmail.com
Sun Dec 8 07:41:39 UTC 2024


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.


Serguey Zefirov kirjoitti 7.12.2024 klo 20.35:
> 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20241208/5cd1cd86/attachment.html>


More information about the Haskell-Cafe mailing list