| |||||||||||||
The monoculture of meritocracyThe monoculture of meritocracyPosted Nov 14, 2012 9:53 UTC (Wed) by mpr22 (subscriber, #60784)In reply to: The monoculture of meritocracy by aryonoco Parent article: Crowding out OpenBSD If you think abstraction layers always reduce readability and maintainability, I look forward to seeing your explanation of how a GUI application written in raw Xlib calls is more readable and maintainable than one written using a toolkit.
(Log in to post comments)
The monoculture of meritocracy Posted Nov 14, 2012 17:13 UTC (Wed) by alankila (subscriber, #47141) [Link]
*sigh* I'll bite.
Take a look at the size of some commonly used toolkit, oh, GTK+3. That's 14 megabytes of compressed source, though some part of this is bound to be data. Whatever. 14 MB, I'll run with it.
Now suppose you write a hello world application: that's 14 MB + your own source, probably no more than 1 kB. Now write xlib application: it's probably a bit longer with respect to your own code, but eliminates 14 MB of code you did not need. Now, if you wish to understand the total system, you need to understand all your own code, all of GTK+, and then all of Xlib, and whatever is underneath it. If you don't have GTK+, you eliminated that much abstraction you did not need to understand.
Therefore: if I am allowed to stipulate that complexity can be counted this way, any additional code you add is a net loss, because it makes the total system more complex, no matter how pretty the world constructed in the cocoon of this new abstraction. But is this a valid argument? I don't really think so. GTK+ is probably allowing you to avoid having to deal with Xlib entirely, so you never have to learn any bit of it and yet get applications that run in X. And of course it gives you nice features like themeability practically for free. It's actually something better than Xlib for most programmers (which is why practically nobody writes raw xlib programs).
All of this is besides the point. My personal experience when dealing with abstractions that simply wrap some other functionality, is that they always make things worse. Let's call this the "driver pattern". These drivers are never quite as nice as the abstraction's API is, and the abstraction hides information from me which I generally need to make the application work well. Maybe I don't get good error reporting, or can't access all the functionality, or whatever. So I believe criticism of the driver pattern is often justified, because it rarely actually helps; rather, it seems to me that a lot of people are simply deluded to only count the upsides and wave away the downsides.
The monoculture of meritocracy Posted Nov 14, 2012 18:14 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
I challenge you to write a "correct" hello world Xlib in 1kB. "Correct" means: interacts correctly with modern Window & Compositing managers (think resize, think WM hints, think liveness pings, ...); has anti-aliased rendering of the "Hello World" string. For style points: make the "hello world" string selectable for copy/paste.
Once you have banged you head on the table trying to do that and come up with the required ~8000-16000 lines of xlib code, try the same thing with GTK and appreciate that this is really possible in less than 100 lines of source code. You may or may not want to revisit your POV on abstractions...
The monoculture of meritocracy Posted Nov 14, 2012 18:38 UTC (Wed) by alankila (subscriber, #47141) [Link]
You missed the point.
The monoculture of meritocracy Posted Nov 14, 2012 22:53 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
My point is: If you want to get any work done in reasonable time, you have to rely on a lot of leaky abstractions (There are errors that can be caught at the Xlib level, that cannot be caught at the gtk level -- but frankly, no user cares). Prefer to fix an abstraction if it offers almost what you want, but not quite (or file a bug) than working around it.
The second aspect that I did not mention so far: Abstractions help making software better by introducing well-defined interfacing points for testing. A class doing nothing else but wrapping a file descriptor and operations on it is mockable for unit tests. A bare file descriptor is not.
The monoculture of meritocracy Posted Nov 16, 2012 4:33 UTC (Fri) by alankila (subscriber, #47141) [Link]
I have nothing against using abstractions, as long as they are good ones. It's just that not all abstractions are good ones. This kind of discussion is really impossible to conduct properly without either drilling down on the features of good vs. bad abstractions, or talking about specific examples and why or why not they might succeed in what they do.
"A bare file descriptor is not."
Indeed. I quite think that libraries are better than file descriptors as abstractions for functionality. For instance, on java side you usually have a stream, and can easily replace it by your own class. C libraries, in contrast, often want file names or file descriptors, which is frankly inconvenient and irritating.
Heretical, I know.
The monoculture of meritocracy Posted Nov 14, 2012 22:47 UTC (Wed) by jonabbey (subscriber, #2736) [Link]
See http://blog.aerojockey.com/post/iocccsim for a very short Xlib based flight simulator. ;-)
The monoculture of meritocracy Posted Nov 15, 2012 8:13 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
And :
1 it's not < 1k 2 the little text rendered does not satisfy modern constrains (could not check the WM interaction from screenshots)
So it's obviously not an exercise in avoiding unneeded abstractions, since it is not feature-comparable to something that would have used those abstractions.
The monoculture of meritocracy Posted Jan 10, 2013 19:42 UTC (Thu) by zlynx (subscriber, #2285) [Link]
Missing features in abstractions: definitely true for Xlib.
I worked with a project a long time ago that ran on Solaris. It was nifty, and when the X server shut down for any reason (crash, disconnect, shutdown) the application just kept running and you could just go back to the application's command terminal and type "display :0.0" and it would put the GUI right back where it had been. You could put copies of the GUI on as many displays as you liked.
Try doing THAT with GTK.
The monoculture of meritocracy Posted Jan 10, 2013 20:20 UTC (Thu) by nix (subscriber, #2304) [Link]
Indeed, Emacs can do this today (it's how I normally use it). But don't try doing that with Gtk, indeed: it'll coredump.
There's an open bug about this.
It's eleven years old.
which is unfortunate Posted Jan 10, 2013 21:47 UTC (Thu) by renox (subscriber, #23785) [Link]
That is what is annoying me so much with many criticisms related to X: in fact in many case, they should be directed towards the toolkits not against X..
|
|||||||||||||