Development quotes of the week [LWN.net]

Development quotes of the week

Posted Nov 25, 2020 9:50 UTC (Wed) by Vipketsh (guest, #134480)
Parent article: Development quotes of the week

What irks me about this "progress" is that these libraries basically do the same thing for 20+ years during which time they went through numerous incompatible changes to their API. Surely a reasonable API would can be found in a few tries and with decades of experience ? Yet these things "progress" but essentially always keep doing the same thing.

I was developing a some GUI around the time when gtk3 started being widely available and had to port stuff from gtk2 to gtk3. All in all the port wasn't /so/ hard, but the changes to the API and the reasoning behind them was dump and, even though the devs I'm sure didn't think like this, were essentially stuff just to make churn in downstream projects.

The example I still remember is that there was an API to retrieve the size of a window. In gtk2 you passed the object (window) and a pointer to a 'size' structure with width and height members. In gtk3 this was changed to a pair of functions: one to retrieve the width and the other the height. It's the exact same thing, only different. To make matters more annoying the rationale for the change was that "structures in API is bad practice". So, I have to fix all my code based on someone else's theory. Not very enjoyable.

In summary the gtk devs decided to preemptively and definitely break all applications to avoid a potential break in the future. How is this "progress" or even reasonable ?

to post comments

Development quotes of the week

Posted Nov 25, 2020 12:11 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

Part of the problem is that other parts of the ecosystem change and the toolkit has to adapt too. On the hardware side, fast GPUs, HiDPI screens, touchscreens, VR/AR, various input gadgets and form factors. On the human side, more people using the software for more things means extra accessibility needs, more font rendering features, more flexible translation systems, better streamlined UX and adapting to the UX trends in other computing ecosystems. On the software side, a larger variety of software with a wider variety of use cases and a wider variety of widget needs. On the development side, folks discovered that certain types of APIs lead to mistakes in application code, so they redesigned the APIs to prevent those things from reoccurring.

Development quotes of the week

Posted Nov 25, 2020 14:31 UTC (Wed) by Vipketsh (guest, #134480) [Link]

I understand things change and thus the underlying libraries need to change too. For some reason there those projects which can, for the most part, add modern features without breaking old applications, while others have to break stuff. Linux is a prime example -- applications statically linked decades ago still run today. X had a time when it was actively developed, new features where added, and all of its user facing interfaces continued to support older applications. I just don't understand why that has to be so different today.

Mind you, I very much agree with the sentiment that "structures in API is bad practice" and various other bad practices -- if you are designing an API from scratch. It's completely different however if the API already exists and has thousands of users. In this case the "possible mistakes" have to be weighed against the cost of change. Especially the example I gave. The "error prone" API was in place for years with apparently no issue, so clearly it wasn't such a big and immediate problem to fix.