
Why do we keep building rotten foundations? - nkurz
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/
======
BinaryIdiot
As someone who follows Semantic Versioning like the bible when my API changes
I find it incredibly interesting that there is an open source community
willing to go about it in such a backwards way. Why wouldn't it be GTK
4.0-ALPHA, GTK 4.0-BETA, GTK 4.0-RTM in which case RTM is the final release
that's stable? Why would you release an API as an X.0 that is _unstable_?

Maybe I'm not as "with it" as I thought with open source communities but I've
just never seen this (and I'm sure there are edge cases but GTK is big; seems
like something important you'd want to be more stable than not that adheres
strictly to semver).

~~~
wvenable
I think I understand it. The X.0 is basically the start of a new technology
branch -- it's radically different than what came before which is why it's a
new major release. And of course any new radically different piece of software
will not be stable, so X.0 represents the most unstable version of this new
technology and theoretically X.Y where Y is the latest point release is then
likely the most bug free and stable.

Perhaps this makes more sense in a world where software never needs to be
finished.

~~~
xg15
> _Perhaps this makes more sense in a world where software never needs to be
> finished._

(warning, rant follows)

I think this hits the core of the matter. This kind of release cycle - and API
design - reflects a way of thinking where the _complete ecosystem_ is expected
to be constantly change. Why bother to keep a stable API if "everyone" has
automated updates and all programs that could potentially use your API have a
full-time development team behind them, ready to instantly react to every
announcement you do.

Backwards compatibility? Not-for-profit one-man projects? Long-lived software?
Naaah, were in the era of the cloud now.

Updates are important and at least security-critical software should obviously
be maintained. However I think this shift currently goes a lot further than
necessary, making constant flux the new normal and articles like this show why
this is a bad idea.

~~~
digi_owl
Cloudcuckoolanders seems to be a fitting description of many of the people
involved with Gnome/Freedesktop these days...

------
jwatte
In this case: Because it's more fun and personally rewarding to do new stuff,
than fight the hard compatibility fight.

In startup API cases: Because it takes 10x longer to build a solid foundation,
and you don't yet know whether that's worth it -- time to proof is more
important. And once you have proof, well, you can't change it easily...

~~~
throwanem
> it's more fun and personally rewarding to do new stuff, than fight the hard
> compatibility fight

Thirteen years ago:
[https://href.li/?https://www.jwz.org/doc/cadt.html](https://href.li/?https://www.jwz.org/doc/cadt.html)

And we're _still_ complaining about the very same problems _in the very same
project_.

 _Edit:_ God dammit, jwz. Sorry, everybody. Should be safe now, I hope. (I
can't see the troll for myself, so I don't know for sure, but if this thing
strips the header like it claims to do, that should solve it.)

~~~
xeromal
NSFW: Picture of a testicle

~~~
throwanem
What?

~~~
kuschku
JWZ redirects all accesses with Referer: news.ycombinator.com to this image
[NSFW] [http://imgur.com/32R3qLv](http://imgur.com/32R3qLv)

~~~
mosselman
Haha, some might argue that he has a point.

------
appleflaxen
The GTK project is hard to understand. They develop with a philosophy that is
almost the antithesis of the kernel (which basically says "changes that break
programs are bugs"). It would be fine for an application being used directly
by end users, but for a library and gui system it is bonkers. I have tried to
compile a gtk-based app from source, and had no end of difficulty just because
my library release varied by a point-version.

It left a really crummy taste in my mouth.

I really like GTK, and once it's compiled it's great, but these aspects are
really painful.

~~~
makomk
The GTK project basically got taken over by a bunch of Gnome developers who
care less and less about non-Gnome users. Many major non-Gnome projects
haven't even managed to make the jump to GTK 3 yet (which also seems to be
roughly where the project jumped the shark); Firefox only switched a few
months ago and GIMP is still thinking about it.

~~~
audidude
Every sentence here is inaccurate, so you might want to check your sources.

1) (It's GNOME in upper case)

2) gtk+ was not "taken over" by a bunch of GNOME developers. gtk+ always was
largely shouldered by the GNOME project. Those that show up to play are at an
advantage.

3) Switching to gtk+ 3.x was hard precisely due to the longevity of gtk+ 2.x.
It managed to stick around for 10 years and exposed all private structures in
public API. So people got used to doing bad things that following PIMPL helps
avoid. So they did, making the transition harder.

4) Firefox's has very little incentive to change a working code-base. The
ultimate incentive was HiDPI and Wayland support. Thing's that couldn't just
be shoe-horned into gtk+ 2.x.

5) GIMP is not "still thinking about it". The sad state is that GIMP is being
mostly worked on by one person (with some occasional help). It's a very large
code-base which was very entrenched in gtk+ 2'isms that we moved away from
(like public structure access). There is a nightly flatpak for 3.x if you'd
like to test it and file bugs.

~~~
makomk
The main benefit of not exposing private structures in public API is that it
lets you avoid breaking the ABI every version; if you're going to do that
anyway, well. And no, I'm not exaggerating how long it's taking projects to
move to gtk+ 3.x - Mozilla has been working on this since 2011, with lots of
fun issues around widget styling and drawing (which is apparently poorly
documented and keeps changing in ways that break applications). The removal of
public structure access was the least of their problems. Even after all that
effort, new gtk+ 3.x releases are still breaking stuff in Firefox and other
apps. For example, scrollbars and check/radio buttons don't show up in Firefox
with gtk+ 3.20 due to major changes in how widget drawing and styling works:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1234158](https://bugzilla.mozilla.org/show_bug.cgi?id=1234158)

------
tomc1985
I am so sick of this mentality that seems to raise aesthetic distractions,
"new features!!!111", and pointless, frequent version changes over code
quality and reusability.

It is a sign that this area of commercial software dev has been almost
completely subsumed by marketeers and business hacks; while they may not
control GTK (though I honestly don't know/care who does), it is clear that
their influence (gotta have the latest new and shiny!) has crowded out other,
more prosaic concerns (like stability and compatibility).

A lot can be said about Microsoft's code, but I have always admired just how
much effort they go through to preserve API compatibility. (Going so far as to
version specific functions and including older versions so as to not break
stuff -- TwiddleBit1(), TwiddleBit2(), and so on.

But on another note it's a problem with we programmers as well. We're so
distractable... you can see it everyday here on HN... "Show HN" is virtually a
graveyard of half-baked, re-hashed ideas implemented in shiny new frameworks.
Unicorns trying to take over the world write long-form blog-posts describing
their tech (but leaving out enough details to let you try it yourself or
duplicate it!) to keep us programmer-types distracted and submissive ('it's
better they gawk at code than question our motives') with their pointless
show-and-tells.

Also... I am god damn sick and tired of dealing with updates! Stop updating
your damn code so much!!!!!!!!!

Or even better... get it right the first time! (It can be done!)

~~~
tomc1985
Or... "Make software boring again!"

~~~
noam87
This is t-shirt worthy.

------
jlundborg
I am actually very excited about this direction for Gtk. If Qt is the stable
and serious cross-platform UI library for corporate stuff, why not let GTK be
the awesome experimental UI library that breaks everything every 6 months, and
keeps pushing the limits on what a free software UI can be? I'm a very happy
Gnome 3 user, and I hope they keep pushing to build a usable, simple and
pretty user experience, despite the endless stream of this kind of grumpy
know-it-all attacks.

Hey, if it was so easy to design an API that is "thought through properly",
show us the spec already - there are plenty of hackers around to build it. If
it actually worked like that.

~~~
xg15
Having a more "experimental" project seems like a good idea. But if the API
breaks all 6 months, I think it's hard to use such a library unlike your
project is a "show HN" style experiment as well that is expected to live only
a few months.

------
digi_owl
Between this and GTK3 i really wish someone would take GTK2 and run far far
away from the Gnome gang.

~~~
whacker
I can imagine some of the complaints with gnome, although I feel its gotten
far better, what exactly are the problems with gtk3 vs 2+?

------
whack
After reading the headline, I was actually expecting the article to go in a
totally different direction. Most of the time, when I see software with rotten
foundations, it's there to preserve backward compatibility. The maintainers
all see the rot, they want to fix it, they want to clean it all up, they want
to do things right. But they can't do anything that would change the API or
break user space in any way, and so, they continue supporting the rot
indefinitely.

The alternative of course, is to fix the rot and prioritize long term benefits
over short-term pain. The downside is that this could break backwards
compatibility. This is the path Python chose when they went from Python 2 ->
Python 3, and the resulting schism was so great, that they have promised to
never do this again. More often than not, this is the same experience that
every software project goes through. Breaking backwards compatibility is so
disruptive, that even living with a rotten foundation seems preferable.

Given the blog title, I would have expected that author to argue that fixing
the rot is preferable over almost anything else. Instead, he seems to be
making the exact opposite argument. He's making the argument that breaking
backwards compatibility is so bad, that we should never do it, no matter how
rotten the existing API might be.

Of course, he wouldn't actually frame it that way. If you asked the author, he
would simply ask _" Why can't you just build the API right the first time?"_
One might as well ask the question: _" Why can't you just build a software
without any bugs?"_ Let's see...

1) To err is human and people will make mistakes. Both in implementation
(bugs), and in design (bad APIs).

2) Building safeguards against mistakes is expensive, in time and effort.
Building 100% robust safeguards against mistakes, is extremely expensive.

3) There's only so much you can learn in a lab, or from a beta. If you don't
have any regrets from 2 years of live data, then you haven't learned anything
at all.

Every project strikes its own balance along the speed vs stability, and
improvement vs backwards-compatibility axis. And there is no intrinsically
wrong answer. Just because what your ideal balance differs from the balance
that the project chose, is no reason to insult and condescend to them. And
yelling at someone for being human and making mistakes, just sounds childish
more than anything.

~~~
panic
You can have backward compatibility while fixing the foundations. The trick is
to add a "compatibility layer" that works well enough for existing clients,
then slowly phase it out. Apple in particular is very good at this. They've
gone from 68k to PPC, PPC to Intel, "Classic" Mac OS to Carbon to Cocoa,
32-bit to 64-bit, Obj-C to Swift, and so on by maintaining compatibility for
old programs on top of new foundations. Unfortunately, these compatibility
layers aren't very fun to write and can be difficult to test and maintain, so
people (in open source projects especially) tend not to be very interested in
the concept.

~~~
erlehmann_
You do not have to phase out any kind of compatibility layer, if your
implementation is forwards compatible. Implementing protocol negotiation and
extensibility serves this purpose. Examples for forwards compatible systems
are HTTP (upgrade header), XML (namespaces), X11 (extensions).

------
wpietri
I'm not a GTK user, so maybe I'm missing something here. And I certainly agree
with the version number complaints. But these quotes trouble me: "what GTK
really needs to do is sit down and flesh out a decent API" and "And if you’re
having to mess with your API on a continual basis, you’re doing it wrong.
Like, the whole software development thing, all wrong."

I think there's an conceptual error here. There are a lot of bad reasons to
change software, but I think there are two really good reasons: 1)
circumstances change, and 2) we have learned something. Or conversely, I think
the only time software can have a static design is when circumstances are
static and you never learn anything.

There's this common notion that if people just sit down and think really hard,
they will design the perfect thing. That's a mirage. The iPod went through
more than a hundred physical revisions before launch. And it has changed a
great deal in the 15 years since. Is that because Apple didn't just sit down
and think enough? Nope. Even the humble paperclip evolved over decades. If
perfect software ever happens, that belongs to a future age.

~~~
teacup50
Apple? They're the people that shipped transparent CPU emulation mechanism to
keep their ABI working and avoid breaking customers.

Twice.

~~~
im_down_w_otp
As someone who went through the the 68k -> PPC -> x86 transitions with
shockingly minimal fuss (also even the MacOS -> OS X + Classic transitions) I
wish I could upvote this comment a thousand times.

------
onli
I really like that. We are getting closer and closer to having Qt as being the
dominating user interface toolkit anyway, and GTK self-destructing can only
further this along.

~~~
davidgerard
Yes, my first thought at those blog posts was "From the Qt Marketing
Department at GNOME".

------
jkot
Use QT if you want stable API. GTK3 breaks compatibility even at minor
releases.

~~~
kuschku
Sadly, both Firefox and Chromium still run on GTK3. Especially Firefox is
annoying, as their recent update to Gtk 3.20 broke a lot of things for me.

If they could just use Qt instead... but nooo...

~~~
digi_owl
I jumped to the extended support channel, knowing it would come. Ironically
this means that Firefox on Windows have better backwards compatibility (XP)
than Firefox on Linux.

If push comes to shove i am pondering moving to Seamonkey.

~~~
qu4z-2
Why is that ironic? Windows makes backwards compatibility a priority, Linux...
doesn't. Well, Linux does, but the userspace not so much.

~~~
kuschku
Well, the userspace actually isn’t that bad either – if you stay away from
Gnome and Gtk. The KDE and Qt side of userland tends to be a lot more stable –
I’ve got a version of Skype here using a Qt version from several years ago –
which still runs nicely, and without issues, and with the old version even
automatically using the theme I’ve set in Qt5.6.

------
microcolonel
I like GTK+, but this release schedule horrifies and disgusts me.

If you're going to break the ABI, just increment the number. I get that they
want to break the ABI incrementally so that they don't end up with what has
become of GTK+ 2.x; where half the applications people use are still on 2.x
and so don't have smooth scrolling or new windowing system support.... but I
just don't think this is the way to fix that.

------
jdub
Much as I disliked the proposal in the original post (which was later
clarified by the GTK+ developers), it is telling that the respondent did not
bother to research the reasons behind GTK+'s two API/ABI breaks in its 18 year
history.

------
gato1313
Interesting thread: thanks.

I have a gtk2 app I built over many years (gtkmm2.4 to be precise) that I have
not ported to gtk3. It is a sophisticated app that uses pulgins (webkit,
mplayer, custom, etc). I was thinking maybe I shouldn't spend effort in
porting to gtk3. I'm considering going UI free like mpv dose with their video
player. Does anyone here have experience in this area and develops plgins for
browsers. What are the interesting technologies in this area?

------
erikb
I would laugh about it if I wouldn't have done the same stuff the first time I
built something for other people. Do they have a completely new team at gtk
dev?

------
scotchmi_st
There is a partial solution to this problem- API _schemas_. Define a schema
for your API and make it public, then have API methods auto-generated directly
from that. For example, for web APIs, there's jsonschema- [http://json-
schema.org/](http://json-schema.org/) from which you can auto-gen functions in
a given language. That way, the parameters around the API such as the URI of
an endpoint can be changed from version to version without completely
destroying the logic on top of it. It doesn't always solve the problem
completely, but it can make it much more tractable.

~~~
Sanddancer
Include headers /are/ API schemas. The big problem being discussed here is ABI
compatibility. Needing to recompile one's software every six months, or have
.so.hell is not fun at all.

------
shmerl
I was very annoyed by GTK 3.20 wreaking havoc. Firefox scrollbars went
missing, until fixed much later (in 48 beta)... I wish they'd just switch to
Qt already.

------
Filter
If GTK had the same status in Linux distributions as the Win16/Win32/etc API
does in Windows then Linux distributions would carry every API-incompatible
version of the library necessary (and maintain old ones).

As it stands, GTK more closely resembles the "Microsoft C++ Redistributable"
situation in Windows -- an awkward hybrid of library and API.

------
kazinator
> _Since when does “X.0” not designate a stable release?_

Oh, approximately since Microsoft gained a lead in personal computing in late
1980-something, and decreed that henceforth, systems shall be expected to be a
broken mess until version 3.x.

------
rurban
Now I understand the new attraction for KDE with its new plasma release. They
script in javascript. I already quit GNOME with its GNOME 3 iteration
desaster. So the fish doesn't only stink at the head, also at its tail. Didn't
know that, thanks.

Liked this comment: Well, in the words of my two favorite software dev related
quotes:

> ‘How could the wise man build his house on the sand? How could the wise man
> build his house, where there is no foundation?’ — Eek a Mouse, Noah’s Ark

> ‘The only way a wise man would build his house on the sand is if it was just
> a hut and he was really high and really enjoyed building new huts.’ — random
> youtube comment on the above song (sadly I forget who the sage was that
> wrote that)

------
Animats
This is why: [1]

[1]
[https://www.youtube.com/watch?v=lecHdtywAAU](https://www.youtube.com/watch?v=lecHdtywAAU)

------
kr0
That's what semantic versioning is all about

------
mosselman
Ironically written on/in Wordpress.

~~~
jordanlev
For all of wordpress's problems, backwards compatibility and API stability
definitely isn't one of them! Their dedication to backwards compatibility is
very impressive (and probably the biggest factor as to why the technical
underpinnings are still such a mess after all these years).

------
Sir_Cmpwn
I'd like to take a moment to mention that the GNOME developers (who run the
Gtk project) are literally insane. They're pushing this new batshit crazy Gtk
versioning scheme, for one, but there's more. They're pushing around the
Wayland scene with crazy design choices for Wayland compositors that affects
the entire Wayland ecosystem and disrupts other projects hoping for cross
compatability. _The GNOME developers honestly and sincerely do not see a point
to having any non-Gtk3 software work on the GNOME desktop_. I'm not kidding,
ask one of them and they will concur. They also broke everything with GNOME 3,
and though they've managed to produce a pretty nice DE by 2014 or so they've
spent the last couple of years removing features that people actually use once
they deem them "obsolete". They also don't see any point in having any Gtk3
software work on systems without systemd or dbus, which I think is nuts even
though I use systemd. GNOME is legitimately insane.

~~~
im_down_w_otp
I think you literally mean figuratively.

~~~
Sir_Cmpwn
No, I mean literally at this point. I've talked with them a lot and they are
honestly convinced that awful choices are good choices and don't understand
how anyone would feel otherwise. I don't know anyone who doesn't work on the
GNOME project that thinks any of their ideas are good ones.

------
moptar
For all the complaints, this sounds like a great deal for the Gtk developers.
They don't have to plan ahead of time which version is going to be the stable
one. If one ends up working well and they want to start on new ideas, they can
just leave it unchanged, declare it to be the stable one and move on.
Developers are people too and they would want a system that makes it easy for
them.

Is it really a problem for application developers either? When you start your
project, just pick the latest stable version and stay with that throughout.
You can ignore all the subsequent updates and be sure that your stable
version's API won't change.

The unstable versions are surely just for people who want to play with the new
features early, not people who are worried about compatibility.

~~~
tremon
_Developers are people too and they would want a system that makes it easy for
them._

I don't want the world to be composed of people that are only there to make
the world easy for themselves.

