| |||||||||||||
The monoculture of meritocracyThe monoculture of meritocracyPosted Nov 14, 2012 18:38 UTC (Wed) by alankila (subscriber, #47141)In reply to: The monoculture of meritocracy by helge.bahmann Parent article: Crowding out OpenBSD
You missed the point.
(Log in to post comments)
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.
|
|||||||||||||