[Haskell-cafe] Engineering Value of Functional Programming

[jo at durchholz.org]

On 07.12.24 19:20, Jerzy Karczmarczuk wrote:
> Joachim Durchholz observes (in reaction to Mostafa Touny):
> 
>> application programming is finding, integrating and using the best 
>> libraries for the project. 
> Hmm. Nothing more?

Heh. I might have overlooked something.

 > No original algorithm design?

I haven't done that in decades for any application programming.
Never for UX, almost never in the backend.

The vast majority of backend(!) programming work is "please transform 
data A, combine it with B, and we'll deal with performance issues when 
they arise".
Frontend work is more about correct validation and layout so it matches 
what the UX designer wanted.

The biggest sort-of algorithmic work I did in the past 10 years was 
integrating a test system with standalone application.
The biggest technical obstacle was to implement a table structure so the 
test system knew that the fields it was seeing in the UI were really 
part of a table. No real algorithmic work, the interfaces were all 
predefined, I just had to implement them, and I believe I used some Map 
data structures provided by the language's standard library.
The main challenge was a correct implementation of the 
incompletely-specified API of the test system. That's not algorithmic 
work, that's experimenting until it works(TM).

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

Algorithmic is needed if the performance is bad and neither caching nor 
adding a map helps. Even O(N²) is often accepted because N is usually 
limited to some fairly low number, if the system ever scales up enough 
that this starts to bite you, you'll have to refactor and even partially 
rewrite it anyway.

> And who worked out those "best libraries"?

Specialists.
Not application programmers.

Nobody codes a new ray-tracing engine anymore, unless for an ICFP contest.
Which _is_ fun, but application programming does not do that kind of 
task. Application programming is about collecting data, doing some O(N) 
calculations on it, and shoving it to the next place, plus obviously UX.

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

Well, I've been in the industrie (hah!) for decades now, and that's what 
I observe.
As an application programmer, you still need to know about O limits (and 
most know horribly little about that kind of stuff), but algorithms - 
that's specialist work.

The last time I saw the lead programmer do algorithmic work was when our 
design had data in different services that had to be updated 
transactionally.
It was an attempt at reimplementing two-phase commit within a single 
phase, which couldn't work; the better solution was shifting service 
responsibilities slightly so the transaction would run within a single 
service.

You may find that disappointing, but it's what all those people do once 
they hit the industry - except those few who actually hit a job where 
advanced work is actually needed.

Regards,
Jo