lupineshadow: Yeah for sure.
The future of programming is functional programming because if you want bug-free software with maximal verifiability then separating pure/impure functions is the first and most important step.
I think, if not taken to extremes, it is the better way to do software, but I'm less confident than you about it being the future of programming (not because it wouldn't be better, but because the world is imperfect).
I tried to ship functional programming at the previous two places I worked at with little success.
For a bit, I was hoping Javascript might be the first really mainstream language that veers in that direction (except for types, it was flexible enough to support it), but then Typescript became all the rage (probably thanks to devs coming from OO languages like Java or C# wanting something familiar to look at) and now the direction of the language is very much OO.
There are two kinds of software professionals: Those who learn and those who get married to whatever was trendy when they first learned their craft (just look at the significant number of developers still going apesh*t about php, that was hot back in the beginning of my university years circa 2002, but in the following 2 decades, some people learned jack sh*t about better alternatives... I loved php too back in 2002-2003, I've moved on).
Too many people in the second category learned OO in school. It will take at least a generation to unlearn that, but even so, existing momentum might make it longer.
Atm, the best I got for you, at least for servers, are microservices. If people write sh*t code (and lets be honest, a lot of people do), make the code less important by breaking it down into small individual codebases with clear api contracts that are easily replaced cogs in a big machine. Hopefully, less of those 100k+ lines monolith where you got to live with the god awful technological choices of the less able forever and ever.
My apologies if I sound demeaning, but I've seen a lot.
lupineshadow: As much as I agree with you and would love to agree with you in a thread about best programming practices, I just think it's out of place here where the biggest problems/'bugs' with this tool is the change in functionality in the undocumented backend of GOG which seems to be an abandoned unofficial API that has stopped living up to its contract.
I think discussing the principles of functional programming is rarely out of place, and I think its relevant to the particular problem that was discussed for updates.
Concerning the broader problem of the api, I'm really wondering if leveraging the Galaxy api might be the better alternative. GOG seems more eager to maintain that properly and my understanding, from what I could discern, you can leverage it to download offline installers too?
If so, I think the main issue might be the login: from what I recall from talking with Sude, cookies don't cut the mustard with the Galaxy api and you need some other token that is hard to obtain if you don't do a proper login.
I think at that point, you'd need a full blown rendering engine to extract that which is harder to achieve cross-platform (something that is of importance to me).
I started learning Rust recently and I'm contemplating whether I could possibly leverage this project to do it (seems promising):
https://github.com/tauri-apps/tauri