4 ms·

Third party code is a risk and should always be carefully managed and properly isolated. This applies regardless of programming language. Of course the web pe

Third party code is a risk and should always be carefully managed and properly isolated. This applies regardless of programming language. Of course the web people and their "frameworks" is just another demonstration of how bad relying on third party code is.

chubot 3y ago
Not true, taking on C or C++ dependencies has different potential consequences than taking on Java or Python dependencies
- mgaunard 3y ago
  Which are?
  - chubot 3y ago
    Non-local bugs due to memory safety. If I have a function def f(x) return ... in Python or Java, those functions will work regardless of what other modules I import. (modulo monkey patching in Python, though you can defend against that) In C you don't have these guarantees -- foreign code can stomp on your code. This is probably why C does not have an NPM-like culture of importing thousands of transitive dependencies -- because that style would just fall down. Also a minor issue, but C doesn't have namespaces (for vars or macros), so it's a bit harder to compose foreign code. Also compiler flags don't necessarily compose. Different pieces of C code make different portability assumptions, and different tradeoffs for speed.
    - mgaunard 3y ago
      So your argument is that C does not have strong module encapsulation, then you argue that Python does. That is just plain false, since a Python module can trivially be tainted by what you import before, and the Python environment is widely known for its dependency hell. Meanwhile C modules, once compiled, can be fully isolated from what you link against them, depending on build and link settings. Non-local bugs is just a matter of sharing state across a module boundary. Memory errors is just a very small subset of the possible bugs you can have in a program, and preventing them doesn't magically solve all the other more important bugs.

chubot 3y ago

Not true, taking on C or C++ dependencies has different potential consequences than taking on Java or Python dependencies

mgaunard 3y ago
Which are?
- chubot 3y ago
  Non-local bugs due to memory safety. If I have a function def f(x) return ... in Python or Java, those functions will work regardless of what other modules I import. (modulo monkey patching in Python, though you can defend against that) In C you don't have these guarantees -- foreign code can stomp on your code. This is probably why C does not have an NPM-like culture of importing thousands of transitive dependencies -- because that style would just fall down. Also a minor issue, but C doesn't have namespaces (for vars or macros), so it's a bit harder to compose foreign code. Also compiler flags don't necessarily compose. Different pieces of C code make different portability assumptions, and different tradeoffs for speed.
  - mgaunard 3y ago
    So your argument is that C does not have strong module encapsulation, then you argue that Python does. That is just plain false, since a Python module can trivially be tainted by what you import before, and the Python environment is widely known for its dependency hell. Meanwhile C modules, once compiled, can be fully isolated from what you link against them, depending on build and link settings. Non-local bugs is just a matter of sharing state across a module boundary. Memory errors is just a very small subset of the possible bugs you can have in a program, and preventing them doesn't magically solve all the other more important bugs.