5 ms·

The code is interesting: https://github.com/jart/cosmopolitan/blob/master/tool/viz/memzoom.c https://github.com/jart/cosmopolitan/blob/master/tool/viz/me... Fe

The code is interesting: https://github.com/jart/cosmopolitan/blob/master/tool/viz/memzoom.c https://github.com/jart/cosmopolitan/blob/master/tool/viz/me... Feels really old school. Looks like something from people used to write DOS programs.

mcdonje 4y ago
Really digging the retro vibe of the code, man.
- naikrovek 4y ago
  if you mean the straight-forward nature of the code, I agree. I think we over-complicate code today because we are promised ease of maintenance, or high-level declaration, or something else, and I don't think those promises have ever come true, except in very small textbook-type examples.
chris1993 4y ago
It's a work of beautiful clarity
eatonphil 4y ago
First off, Justine is a better programmer than I. But, and I don't mean this as a humblebrag, the use of all global variables for state makes me uncomfortable. If this is good C code (not saying it isn't) then maybe that's why I'm not a C programmer. Whatever the case, Justine is great.
- jart 4y ago
  That's a good instinct to have. 99% of the time we're writing something like an object library that's part of a much larger program. To use global variables in such code would impose difficulties on the application as a whole, with regard to things like threading, pollution of the linker symbol table, etc. But when you're writing small main.c programs like this one which don't use threads, globals can be a real advantage. In gdb, you can easy inspect their values. You can look at the linker output manifest listing to see how they're being arranged in your binary. If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style. It's just not one that scales to large monolithic programs that most companies prefer to create. So over the years a cultural aversion to it was developed in many style guides.
  - charcircuit 4y ago
    >If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style. The original UNIX programs weren't known for good style or being big free
    - charcircuit 4y ago
      bug free
    - jart 4y ago
      Then why is everything based on UNIX then? (Or at least fated to be, via WSL.) If you want a real jewel, check out the v6 rand() function. It's an example of a function so bad that world-class experts on the subject of randomness have been falling over themselves for decades in academic papers talking about how to fix it.
      - donut 4y ago
        I'm reminded of the thesis that worse is better: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html :-)
      - charcircuit 4y ago
        >Then why is everything based on UNIX then? It's not based off UNIX's code. UNIX based system's popularity can essentially be attributed to network effects. For most use cases it's good enough that it's not worth switching to something better because you lose the mountain of resources (both technological and human) that exist in the UNIX ecosystem.
  - dekhn 4y ago
    I typically split any single main.c app into two parts: a library which depends on no shared State and a driver program that wraps around it. It's a lot harder to build than a monolithic main.c but in my experience it allows more people to build off of your application.
- elteto 4y ago
  The "rule" that I've sort of figured out from reading old C code is that global state in the file that contains main() is ok.
- marcodiego 4y ago
  For a well written code that is less than 1000 lines in a single file using very few abstractions, that number of global variables is not a problem.

mcdonje 4y ago

Really digging the retro vibe of the code, man.

naikrovek 4y ago
if you mean the straight-forward nature of the code, I agree. I think we over-complicate code today because we are promised ease of maintenance, or high-level declaration, or something else, and I don't think those promises have ever come true, except in very small textbook-type examples.

chris1993 4y ago

It's a work of beautiful clarity

eatonphil 4y ago

First off, Justine is a better programmer than I. But, and I don't mean this as a humblebrag, the use of all global variables for state makes me uncomfortable. If this is good C code (not saying it isn't) then maybe that's why I'm not a C programmer. Whatever the case, Justine is great.

jart 4y ago
That's a good instinct to have. 99% of the time we're writing something like an object library that's part of a much larger program. To use global variables in such code would impose difficulties on the application as a whole, with regard to things like threading, pollution of the linker symbol table, etc. But when you're writing small main.c programs like this one which don't use threads, globals can be a real advantage. In gdb, you can easy inspect their values. You can look at the linker output manifest listing to see how they're being arranged in your binary. If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style. It's just not one that scales to large monolithic programs that most companies prefer to create. So over the years a cultural aversion to it was developed in many style guides.
- charcircuit 4y ago
  >If you look at a lot of the old original UNIX programs that were written back in the day, a lot of them looked very similar to this. So it's a great style. The original UNIX programs weren't known for good style or being big free
  - charcircuit 4y ago
    bug free
  - jart 4y ago
    Then why is everything based on UNIX then? (Or at least fated to be, via WSL.) If you want a real jewel, check out the v6 rand() function. It's an example of a function so bad that world-class experts on the subject of randomness have been falling over themselves for decades in academic papers talking about how to fix it.
    - donut 4y ago
      I'm reminded of the thesis that worse is better: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html :-)
    - charcircuit 4y ago
      >Then why is everything based on UNIX then? It's not based off UNIX's code. UNIX based system's popularity can essentially be attributed to network effects. For most use cases it's good enough that it's not worth switching to something better because you lose the mountain of resources (both technological and human) that exist in the UNIX ecosystem.
- dekhn 4y ago
  I typically split any single main.c app into two parts: a library which depends on no shared State and a driver program that wraps around it. It's a lot harder to build than a monolithic main.c but in my experience it allows more people to build off of your application.
elteto 4y ago
The "rule" that I've sort of figured out from reading old C code is that global state in the file that contains main() is ok.
marcodiego 4y ago
For a well written code that is less than 1000 lines in a single file using very few abstractions, that number of global variables is not a problem.