| |||||||||||||
Choosing between portability and innovationChoosing between portability and innovationPosted Mar 3, 2011 11:00 UTC (Thu) by Seegras (subscriber, #20463)In reply to: Choosing between portability and innovation by dgm Parent article: Choosing between portability and innovation
> > it doesn't help us create better software or better user experience.
> > Wrong. It *does* help create better software. Every time I try to build my > software with another compiler I discover things that can be done better. > Every time I try to port my code to a new platform I find better > abstractions for what I was trying to achieve.
Absolutely.
I've got to hammer this home some more. Porting increases code quality.
("All the world is windows" is, by the way, why games written for windows are sometimes so shabby when released. And only after they've been ported to some other platform they get patched to be useable on windows as well).
(Log in to post comments)
Choosing between portability and innovation Posted Mar 3, 2011 12:32 UTC (Thu) by lmb (subscriber, #39048) [Link]
That is true: porting increases quality.
However, only to a point, because one ends up with ifdefs strewn through the code, or internal abstraction layers to cover the differences between supported platforms of varying ages. This does not improve the quality, readability, nor maintainability of the code indefinitely.
Surely one should employ caution when using new abstractions, and clearly define one's target audience. And be open to clean patches that make code portable (if they come with a maintenance commitment).
But one can't place the entire burden of this on the main author or core team, which also has limited time and resources. Someone else can contribute compatibility libraries or port the new APIs to other platforms - it's open source, after all. ;-)
And quite frankly, a number of POSIX APIs suck. Signals are one such example, IPC is another, and let us not even get started about the steaming pile that is threads. Insisting that one sticks with these forever is not really in the interest of software quality. They are hard to get right, easy to get wrong, and have weird interactions; not exactly an environment in which quality flourishes.
If signalfd() et al for example really are so cool (and they look quite clean to me), maybe it is time they get adopted by other platforms and/or POSIX.
Choosing between portability and innovation Posted Mar 3, 2011 17:53 UTC (Thu) by nix (subscriber, #2304) [Link]
Linux innovations like this routinely get adopted by POSIX (obviously not things like sysfs, but I would not be remotely surprised to find things like signalfd getting adopted, since it cleans up the horror of signal handling enormously), but new POSIX revisions are not frequent and even after that it takes a long time for new POSIX revisions to get implemented in some of the BSDs (and, for that matter, in Linux, in the rare case that it didn't originate the change).
Choosing between portability and innovation Posted Mar 3, 2011 13:02 UTC (Thu) by epa (subscriber, #39769) [Link] Porting increases code quality.By more than if you spent the same number of hours on some other development task without worrying about portability? Working on portability does have positive side effects even for the main platform, but it takes away programmer time from other things. So you have to decide if it's the best use of effort.
Choosing between portability and innovation Posted Mar 3, 2011 17:54 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
yes, because dealing with portability forces you to think more about the big picture and by seeing different ways that things can be done.
|
|||||||||||||