4 ms·

Holy shit, this is the craziest C code I've ever seen!

by gautamcgoel 7y ago

kick 7y ago
Is it? I find it quite beautiful. Have you read the ngn/k source?
- gautamcgoel 7y ago
  No I haven't. I'll take a look. When I said the code looked crazy, I didn't mean to suggest it was bad code. It seems quite dense, I'd really like some explanation for how it works.
  - kick 7y ago
    Courtesy of 'yiyus: https://docs.google.com/document/d/1W83ME5JecI2hd5hAUqQ1BVF32wtCel8zxb7WPq-D4f8/edit?usp=sharing https://docs.google.com/document/d/1W83ME5JecI2hd5hAUqQ1BVF3... Also 'tlack's attempt at it: https://github.com/tlack/b-decoded https://github.com/tlack/b-decoded
- Thorrez 7y ago
  I'm not a fan of it. It looks like minified code. Every variable 1 or 2 letters, very long lines with everything jammed together as much as possible. I would rather have more descriptive and memorable names, and whitespace that aids in understanding the program structure.
  - kick 7y ago
    Short variable names are features, long lines are good (more horizontal pixels than vertical pixels on modern monitors so you keep it all on one screen). Brief and small. Hard to find another C compiler that you can fit in your head, especially one faster/better at generating binaries than LLVM/GCC.
    - mhd 7y ago
      Well, it's not real C, and simplifying a language makes things a lot more easier than having to stick to a lengthy, detailed standard. Not that the compiler ever argues that it does something different than that, it's named "B" after all (never mind the name clash with the original lobotomized BCPL) Some simple Algol-/Pascal-ish compilers used for instruction aren't that much more complicated. Sure, they don't fit in that many lines, but if you consider tokens on a x/y axis, it's not that different. Wirth's Oberon-7 would be a good example for something not toy-like. I do appreciated the terseness, though. APL/K often operate in a specific domain and/or are used interactively, where this is of a big benefit. It does make me wonder how lengthy interleaved string messages would interfere with this. Would a terse language suffer more from the "context switch" between short identifiers and long strings than one where functionsAreWrittenLikeThis in the first place? Probably calls for more variables, otherwise the actual parts of the code are spread too far apart.

Holy shit, this is the craziest C code I've ever seen!

kick 7y ago

Is it? I find it quite beautiful. Have you read the ngn/k source?

gautamcgoel 7y ago
No I haven't. I'll take a look. When I said the code looked crazy, I didn't mean to suggest it was bad code. It seems quite dense, I'd really like some explanation for how it works.
- kick 7y ago
  Courtesy of 'yiyus: https://docs.google.com/document/d/1W83ME5JecI2hd5hAUqQ1BVF32wtCel8zxb7WPq-D4f8/edit?usp=sharing https://docs.google.com/document/d/1W83ME5JecI2hd5hAUqQ1BVF3... Also 'tlack's attempt at it: https://github.com/tlack/b-decoded https://github.com/tlack/b-decoded
Thorrez 7y ago
I'm not a fan of it. It looks like minified code. Every variable 1 or 2 letters, very long lines with everything jammed together as much as possible. I would rather have more descriptive and memorable names, and whitespace that aids in understanding the program structure.
- kick 7y ago
  Short variable names are features, long lines are good (more horizontal pixels than vertical pixels on modern monitors so you keep it all on one screen). Brief and small. Hard to find another C compiler that you can fit in your head, especially one faster/better at generating binaries than LLVM/GCC.
  - mhd 7y ago
    Well, it's not real C, and simplifying a language makes things a lot more easier than having to stick to a lengthy, detailed standard. Not that the compiler ever argues that it does something different than that, it's named "B" after all (never mind the name clash with the original lobotomized BCPL) Some simple Algol-/Pascal-ish compilers used for instruction aren't that much more complicated. Sure, they don't fit in that many lines, but if you consider tokens on a x/y axis, it's not that different. Wirth's Oberon-7 would be a good example for something not toy-like. I do appreciated the terseness, though. APL/K often operate in a specific domain and/or are used interactively, where this is of a big benefit. It does make me wonder how lengthy interleaved string messages would interfere with this. Would a terse language suffer more from the "context switch" between short identifiers and long strings than one where functionsAreWrittenLikeThis in the first place? Probably calls for more variables, otherwise the actual parts of the code are spread too far apart.