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