Joachim Durchholz observes (in reaction to Mostafa Touny):

application programming is finding, integrating and using the best libraries for the project. Hmm. Nothing more? No original algorithm design? No cooking of specific (problem-oriented) data structures? And who worked out those "best libraries"?

Further reading makes me curious what is Jo's  definition of the "methology", since the fragment:

/.../ that's not methodology, just practical experience, since the type system are given anyway so there's no methodology to teach. -- is something I find a bit distant from the world of teaching.

Jerzy Karczmarczuk (France) -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

Joachim Durchholz:

...

And who worked out those "best libraries"?

*Specialists. Not application programmers. *

...

No cooking of specific (problem-oriented) data structures?

Domain objects, yes. But these are very straightforward; they may even be associated with computations, but that's just processing, there's usually no loops except for summation. Computing a histogram would be the limit of what you'd do there, usually. Essentially, you map everything to primitives, records, lists, and maps, *and that's all you need*. As you wish, but don't forget love... You know, it can also be mapped to

Jo, did you ever teach  CompSci in a comprehensive context, so that it was (could be) useful to read some History? Well, I've been formed as physicist, so some examples. Almost whole CERNLIB has been created, implemented and analysed before Eru Ilúvatar created the race of Specialists. The accelerator users NEEDED intelligent code for their applications, and there were no Wizards in the neighbourhood. *Quicksort* has been invented by Tony Hoare between 1959 and 1961 (publication).  When he studied in Moscow, he was offered a work on a translation project, and needed a good method to process dictionaries.  It was thus an */application/* project, and in such a way TH *became* specialist! Interesting story... The Mercury Autocode was less then useful to reasonably implement sorting and TH, who in 1961 studied Algol 60 (in Brighton) found recursion. Partly thanks to him, the recursive algorithms began to proliferate, also in numerical realm; you might know that at the beginning Algol had no recursion, since some specialists within its Committee were against, saying that this was useless, only slowed down the programs. Well, the anti-recursionists continue until today... The first interesting "computer experiment", the dawn of simulation, with some new algorithms, is the FPUT work (Fermi, Pasta, Ulam, Tsingou, 1953). Will you call them "specialists" (surely of something) and not "applicative programmers"? Actually, the team had one true programmer, Mary Tsingou. All of you probably know who was Fermi or Ulam... Monte Carlo: Nicholas Metropolis was a physicist. What "best libraries" invented by "specialists" could he look for, while participating in the Manhattan project? The algebraic language Schoonschip with its wonderful rewriting system, is the creation of Martinus Veltman. Do I have to remind you what was his principal specialty? (and the successor of Schoonschip, Form was created by a physicist, Jon Vermaseren; Reduce: by Hearn, physicist as well). Do you think that Stephen Wolfram began his carreer  as a specialist in computer science? Verify. OK, I stop here. primitives. Will then it make you happy? I am sorry, I don't want to be impolite, but I am afraid that you don't master this subject. Such objects as Graphs in hundreds of different favours find themselves beyond your "limits of utility"??  Do you know what data structures are needed in, say, robotics,  in inverse kinematics?

Nobody codes a new ray-tracing engine anymore, unless for an ICFP contest. Do you really think that graphic/imagery/synthesis algorithms for the Film Industry people are primitive, assembly-style instructions, without loops etc., and everything stagnates? Ray tracing?? Do you know what organization of concurrency is needed in the implementation of real-time recursive radiosity? (and this is not so recent!)

Well, I wish you the best. But, please, learn something off your present limits, you might find many interesting topics. Jerzy Karczmarczuk -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

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 :

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

Thank you all for your comments. The closest thing I found related to project management and haskell was Serokell's blog: https://serokell.io/blog/haskell-in-production I feel there is a space for designing new project management methodologies based on type and category theory. Let me know if anyone is curious to explore that. Best, Mostafa Touny

Thank you, Serguey. I like Haskell as a theory but I would remind myself that a good mathematician or a good engineer looks for solving the right problem using the right tools. I am trying to figure a methodology that boosts re-usability and cheap modifications using haskell, types, and categories. Any experience or guideline would be appreciated. Sincerely, Mostafa Touny