@root42 that's the feeling I got from last book I purchased about C#: that people who wrote it had no intent of me actually learning it...
Of course, introducing new APIs every so often does not help...
@root42 that's the feeling I got from last book I purchased about C#: that people who wrote it had no intent of me actually learning it...
Of course, introducing new APIs every so often does not help...
@root42 (ah, and the fact that the API I'm after is arcane and obscure and tries to cover everything doesn't help either -- https://www.enlightenment.org/develop/efl/start)
@PypeBros Yes, but that is another problem, with makes the book problem even worse. There is something to be gained from stability in software. Change for change's sake is not a good thing. There is merit in refactoring and innovation, but if you actually sit down and think, before implementing something, you can create something that lasts for many years. Making the need for constant breaking changes a non issue.
@root42 agreed. It shocked me that people kept (and increased) using Python in production environment when the "2to3" transition started ...
Now, admittedly, switching from C64 Basic to GW-like Basic and then to Q(uick)Basic wasn't very pleasant either, so maybe it's been there from the beginning but I just wasn't watching
@PypeBros Sure, change is necessary, and software evolves. But you can try and make APIs stable and mostly backwards compatible. Change should be gradual, and APIs should be mostly stable. But I guess software architecture is not the most important thing these days...