4 ms·

One problem in understanding computer science history is the essentially perpetual copyright laws. It's illegal to view or share many important past programs' s

One problem in understanding computer science history is the essentially perpetual copyright laws. It's illegal to view or share many important past programs' source code, a problem not shared by other fields. Imagine discussing literature without being allowed to read it! There are exceptions, but they are exceptions. The rise of open source software is finally letting us view some of that software. But we may never publicly know what some past giants did.

ed25519FUUU 6y ago
Is the actual source code that important? I’m trying to think of what I’m missing. I’m personally more interested in the comments left in the code of some or those old projects than the actual code, which was probably full of bugs and a bit crufty just like the stuff we write today.
- sanxiyn 6y ago
  Yes it is important. Sometimes details matter, and often the only place details can be found is actual source code.
aidenn0 6y ago
Programs source code is just as copyrighted as late 20th century literature. However, it's not generally available (unlike late 20th century literature). If windows sold with the source code (even if you were forbidden from doing anything with it), then we would be reading windows source code in our CS classes.
- detaro 6y ago
  Microsoft even had a "research kernel" they licensed out to unis, and we did read (parts of) that in CS classes. (but still of course very different than actually having the full source of real systems through history available for general study)
  - sjg007 6y ago
    Ride the mach continuum between the micro and monolithic.. not really interesting. Basically opening up user mode device drivers or user mode code in the kernel (sandboxes).
- jonathankoren 6y ago
  No we wouldn’t. Source code is notoriously hard to read if you’re not familiar with it, and optimized source code using internal APIs is even harder. If you’re learning an algorithm, just stick to pseudocode, otherwise youre stuck with MMIX bullshit.
  - aidenn0 6y ago
    I mean Joyce is notoriously hard to read, no?
    - deleted 6y ago
      [deleted]
    - jonathankoren 6y ago
      While there is only one Joyce, please tell me how build 627252 of Windows 3.11 glonkglonk.cpp is a unique example that provides more insight into a heap, than five lines of pseudocode.
      - aidenn0 6y ago
        "Here's 5 lines of pseudocode" "Here's a real-world implementation of the pseudocode. Note this section does not improve the asymptotic case, but has significant constant-factor advantages for small inputs." [edit] I noticed you mentioned "heap" assuming you're talking about the data-structure, that would probably be in a different class than one where you read windows source code. Just like you probably wouldn't read Joyce in a class on composing newspaper articles. I still think it's useful to dissect existing code to get an idea of how complicated it really can be. A CS undergrad may graduate without ever reading or writing a single program over 1kloc. Even from an academia perspective, having a concept that real-world software is usually 100s or 1000s of kloc is likely useful.
      - philipkglass 6y ago
        A typical experience when I re-implement a technique from an academic paper: 1) Read the paper's high level description and pseudocode. 2) Write some test cases. 3) Write code based on the paper's pseudocode. 4) Observe that my test case results do not match what the authors show. 4a) Fiddle repeatedly with possible ambiguities in the pseudocode-to-real-code translation until test cases match publication. This involves a certain amount of mind reading and speculation. "They said argmax, but there are possible singularities... maybe argmax followed by clamping." 4b) Request source code from the authors. Upon receiving it, find that their real implementation diverges in small but significant ways from the pseudocode that was published. They have mixed actual-code algorithm outputs with incomplete pseudocode algorithm descriptions in the paper.
guidoism 6y ago
Fortunately people are putting up some of that early work: http://www.softwarepreservation.org/projects http://www.softwarepreservation.org/projects

ed25519FUUU 6y ago

Is the actual source code that important? I’m trying to think of what I’m missing. I’m personally more interested in the comments left in the code of some or those old projects than the actual code, which was probably full of bugs and a bit crufty just like the stuff we write today.

sanxiyn 6y ago
Yes it is important. Sometimes details matter, and often the only place details can be found is actual source code.

aidenn0 6y ago

Programs source code is just as copyrighted as late 20th century literature. However, it's not generally available (unlike late 20th century literature). If windows sold with the source code (even if you were forbidden from doing anything with it), then we would be reading windows source code in our CS classes.

detaro 6y ago
Microsoft even had a "research kernel" they licensed out to unis, and we did read (parts of) that in CS classes. (but still of course very different than actually having the full source of real systems through history available for general study)
- sjg007 6y ago
  Ride the mach continuum between the micro and monolithic.. not really interesting. Basically opening up user mode device drivers or user mode code in the kernel (sandboxes).
jonathankoren 6y ago
No we wouldn’t. Source code is notoriously hard to read if you’re not familiar with it, and optimized source code using internal APIs is even harder. If you’re learning an algorithm, just stick to pseudocode, otherwise youre stuck with MMIX bullshit.
- aidenn0 6y ago
  I mean Joyce is notoriously hard to read, no?
  - deleted 6y ago
    [deleted]
  - jonathankoren 6y ago
    While there is only one Joyce, please tell me how build 627252 of Windows 3.11 glonkglonk.cpp is a unique example that provides more insight into a heap, than five lines of pseudocode.
    - aidenn0 6y ago
      "Here's 5 lines of pseudocode" "Here's a real-world implementation of the pseudocode. Note this section does not improve the asymptotic case, but has significant constant-factor advantages for small inputs." [edit] I noticed you mentioned "heap" assuming you're talking about the data-structure, that would probably be in a different class than one where you read windows source code. Just like you probably wouldn't read Joyce in a class on composing newspaper articles. I still think it's useful to dissect existing code to get an idea of how complicated it really can be. A CS undergrad may graduate without ever reading or writing a single program over 1kloc. Even from an academia perspective, having a concept that real-world software is usually 100s or 1000s of kloc is likely useful.
    - philipkglass 6y ago
      A typical experience when I re-implement a technique from an academic paper: 1) Read the paper's high level description and pseudocode. 2) Write some test cases. 3) Write code based on the paper's pseudocode. 4) Observe that my test case results do not match what the authors show. 4a) Fiddle repeatedly with possible ambiguities in the pseudocode-to-real-code translation until test cases match publication. This involves a certain amount of mind reading and speculation. "They said argmax, but there are possible singularities... maybe argmax followed by clamping." 4b) Request source code from the authors. Upon receiving it, find that their real implementation diverges in small but significant ways from the pseudocode that was published. They have mixed actual-code algorithm outputs with incomplete pseudocode algorithm descriptions in the paper.

guidoism 6y ago

Fortunately people are putting up some of that early work: http://www.softwarepreservation.org/projects http://www.softwarepreservation.org/projects