5 ms·

At some level all software will be too complex to understand easily within one sitting. That is just the nature of life. In my opinion, learning to read someone

At some level all software will be too complex to understand easily within one sitting. That is just the nature of life. In my opinion, learning to read someone else's code is a sign of maturity, the ability to not just jump to churn or replace something just because you don't understand it is very mature. While I somewhat agree there are levels of obscufation, just because something is hard to understand on the first go isn't sufficient for something to be "non-free" in my interpretation, like the b interpreter.

yjftsjthsd-h 4y ago
> While I somewhat agree there are levels of obscufation, just because something is hard to understand on the first go isn't sufficient for something to be "non-free" in my interpretation, like the b interpreter. The GPLv2 contains this sentence: > The source code for a work means the preferred form of the work for making modifications to it. And I think that's really the fundamental question at hand. If the original author(s) actually write in a particular style (I guess the b interpreter is a case of this?) then it's ... kind of annoying IMO, but it isn't nonfree. On the other hand if the original authors wrote another representation and then intentionally obfuscated before publishing it, then that's clearly intentionally aimed at reducing the ability of others to exercise the 4 freedoms and that's a problem. And I do think there's some grey area in the middle; things like $BIG_COMPANY releasing the source code for something, but even if they have no intention of making it hard for others to work with that code it was written for their internal use and it's tied to internal build processes purely as a practical matter.
- not2b 4y ago
  Yes, distributing modifications to GPLed code only in obfuscated form is a clear GPL violation. Distributing ugly and unmaintainable code because that's the only code you have is allowed (and sometimes that happens because the code works just well enough to get an academic paper published and isn't going to be polished any more than that).
montag 4y ago
Eventually, we will rely on machines to help us understand software code. Think "fill in missing code comments with GPT-3." Now add 10 years of focused research to make this more reliable and intelligible. It must be inevitable, right?
- PartiallyTyped 4y ago
  Copilot can fill in type annotations in python, “resolve” some bugs, explain code, “make it more robust”. The features are available in copilot labs, they are obviously very much WIP, but they are definitely not useless.
  - capitalsigma 4y ago
    Type inference really doesn't require ML (and is probably better done without it in order to be robust). I think the Kolmogorov complexity of serious production codebases is very high -- in order to convey what the codebase does, you have to transmit roughly as many bits as the codebase itseld. In most companies, you already have a way to get a "compact, human-readable description" of what the code does -- it's called asking your coworker, or reading your internal documentation. Ramp up is still hard.
    - PartiallyTyped 4y ago
      > Type inference really doesn't require ML This holds only if you have sufficient context, giving what is virtually an untyped function into e.g. mypy will not provide anything meaningful. Even languages with rich type systems like Haskell do require some types - even implicitly - to infer everything else. In contrast, copilot has access to significantly more information when emitting the type-annotated code, including context of what the project is like, how are other functions defined, plus all the prior knowledge accumulated from training. > I think the Kolmogorov complexity of serious production codebases is very high Do serious codebases exceed gigabytes in raw storage? > in order to convey what the codebase does Doesn't this assume no priors / blank slate?
      - 4y ago

yjftsjthsd-h 4y ago

> While I somewhat agree there are levels of obscufation, just because something is hard to understand on the first go isn't sufficient for something to be "non-free" in my interpretation, like the b interpreter. The GPLv2 contains this sentence: > The source code for a work means the preferred form of the work for making modifications to it. And I think that's really the fundamental question at hand. If the original author(s) actually write in a particular style (I guess the b interpreter is a case of this?) then it's ... kind of annoying IMO, but it isn't nonfree. On the other hand if the original authors wrote another representation and then intentionally obfuscated before publishing it, then that's clearly intentionally aimed at reducing the ability of others to exercise the 4 freedoms and that's a problem. And I do think there's some grey area in the middle; things like $BIG_COMPANY releasing the source code for something, but even if they have no intention of making it hard for others to work with that code it was written for their internal use and it's tied to internal build processes purely as a practical matter.

not2b 4y ago
Yes, distributing modifications to GPLed code only in obfuscated form is a clear GPL violation. Distributing ugly and unmaintainable code because that's the only code you have is allowed (and sometimes that happens because the code works just well enough to get an academic paper published and isn't going to be polished any more than that).

montag 4y ago

Eventually, we will rely on machines to help us understand software code. Think "fill in missing code comments with GPT-3." Now add 10 years of focused research to make this more reliable and intelligible. It must be inevitable, right?

PartiallyTyped 4y ago
Copilot can fill in type annotations in python, “resolve” some bugs, explain code, “make it more robust”. The features are available in copilot labs, they are obviously very much WIP, but they are definitely not useless.
- capitalsigma 4y ago
  Type inference really doesn't require ML (and is probably better done without it in order to be robust). I think the Kolmogorov complexity of serious production codebases is very high -- in order to convey what the codebase does, you have to transmit roughly as many bits as the codebase itseld. In most companies, you already have a way to get a "compact, human-readable description" of what the code does -- it's called asking your coworker, or reading your internal documentation. Ramp up is still hard.
  - PartiallyTyped 4y ago
    > Type inference really doesn't require ML This holds only if you have sufficient context, giving what is virtually an untyped function into e.g. mypy will not provide anything meaningful. Even languages with rich type systems like Haskell do require some types - even implicitly - to infer everything else. In contrast, copilot has access to significantly more information when emitting the type-annotated code, including context of what the project is like, how are other functions defined, plus all the prior knowledge accumulated from training. > I think the Kolmogorov complexity of serious production codebases is very high Do serious codebases exceed gigabytes in raw storage? > in order to convey what the codebase does Doesn't this assume no priors / blank slate?
    - 4y ago