| |||||||||||||
|
| |||||||||||||
Choosing between portability and innovationChoosing between portability and innovationPosted Mar 4, 2011 17:44 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: Choosing between portability and innovation by liljencrantz Parent article: Choosing between portability and innovation
I almost agree with you.
the thing is that the API you code to should be flexible and evolve over time, with some of the abstraction layers that others have mentioned being in the API -> platform level
In the end your API may not directly match any of your destination platforms.
the linux kernel does this. Linus has said in interviews that the kernel is not written directly for any type of system, but instead is written for an idealized system that doesn't actually exist, with 'shim code' on every single platform (including x86) to simulate portions of the 'system' the kernel is written for. He says that the kernel is much better as a result of this work.
(Log in to post comments)
Choosing between portability and innovation Posted Mar 9, 2011 17:50 UTC (Wed) by schabi (subscriber, #14079) [Link]
I agree here.
But note that there is a huge difference between writing "non-portable" code targeted for an idealized platform (with a PAL in place to emulate that platform in the real environment), and writing with portability in mind (hundreds of #ifdefs, missing functionality, etc.).
Choosing between portability and innovation Posted Mar 9, 2011 23:44 UTC (Wed) by nix (subscriber, #2304) [Link]
Writing with portability in mind does not imply 'missing functionality' (on platforms capable of it), and *certainly* does not imply 'hundreds of #ifdefs'. Indeed, the latter is generally a symptom of software that was not written with portability in mind, but which had limited portability jammed crudely into it at a later date.
|
|
||||||||||||