4 ms·

> This is a shame, because it makes for brittle software The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software.

anonyfuss 13y ago
> 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.
msbarnett 13y ago
The choice between 'portability' and 'ifdefs' is a false dichotomy. There are far cleaner ways to achieve portability, and ifdefs are almost always a sign of 'doing it wrong'. See, for example, Kernighan and Pike talking about portability in The Practice of Programming.
- bkor 13y ago
  BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested?
  - anonyfuss 13y ago
    > BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested? You could start by explaining "a bunch of stuff" -- and why it's necessary -- concretely.
  - npsimons 13y ago
    Code coverage tools are available. Porting software to other platforms is just one crude, but very effective way of testing different code paths, some you can't even see (unless you are in the habit of stopping at each compile stage and checking things such as the compiler's assembler output . . . ).

anonyfuss 13y ago

> 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.

msbarnett 13y ago

The choice between 'portability' and 'ifdefs' is a false dichotomy. There are far cleaner ways to achieve portability, and ifdefs are almost always a sign of 'doing it wrong'. See, for example, Kernighan and Pike talking about portability in The Practice of Programming.

bkor 13y ago
BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested?
- anonyfuss 13y ago
  > BSD doesn't support a bunch of stuff. How would you deal with that concretely. How would you ensure that all those different code paths are tested? You could start by explaining "a bunch of stuff" -- and why it's necessary -- concretely.
- npsimons 13y ago
  Code coverage tools are available. Porting software to other platforms is just one crude, but very effective way of testing different code paths, some you can't even see (unless you are in the habit of stopping at each compile stage and checking things such as the compiler's assembler output . . . ).