4 ms·

> The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software. False dichotomy; simply don't make abundant use of #ifdefs. Mos

> The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software. False dichotomy; simply don't make abundant use of #ifdefs. Most large, portable projects don't use #ifdefs across the codebase. They abstract the core concepts out into interfaces that can be implemented atop different APIs, and then maintain distinct implementations where necessary. The advantage is that this also insulates you from changes to the underlying system APIs, creates testable code, and provides clean well-defined points of interaction between subsystems.

mseepgood 13y ago
> They abstract the core concepts out into interfaces that can be implemented atop different APIs This is exactly what systemd's D-Bus API is for.
- anonyfuss 13y ago
  D-bus isn't a software architecture and doesn't somehow magically make systemd more maintainable.
bkor 13y ago
Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. Might be fine for a lot of projects, but this is just something to boot up your system.
- anonyfuss 13y ago
  > Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. No. A proper approach to abstraction: - Reduces complexity by reducing interdependency between subsystems. - Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing. - Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on. > Might be fine for a lot of projects, but this is just something to boot up your system. Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable). Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.

mseepgood 13y ago

> They abstract the core concepts out into interfaces that can be implemented atop different APIs This is exactly what systemd's D-Bus API is for.

anonyfuss 13y ago
D-bus isn't a software architecture and doesn't somehow magically make systemd more maintainable.

bkor 13y ago

Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. Might be fine for a lot of projects, but this is just something to boot up your system.

anonyfuss 13y ago
> Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. No. A proper approach to abstraction: - Reduces complexity by reducing interdependency between subsystems. - Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing. - Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on. > Might be fine for a lot of projects, but this is just something to boot up your system. Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable). Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.