3 ms·

The C version is 41 lines, and 1749 bytes. The Rust version is 295 lines, and 8289 bytes. The point of the Incunabulum is not really what it does (it's a REPL

The C version is 41 lines, and 1749 bytes. The Rust version is 295 lines, and 8289 bytes. The point of the Incunabulum is not really what it does (it's a REPL with a handful of half-implemented J verbs and no error checking), but the style it demonstrates. I think that rewriting a similar program in another language without even attempting to reproduce the style is rather missing the point. If you're interested in Rust, why not figure out what a semantically-compressed style looks like for it?

tomp 7y ago
How much of that is due to the C preprocessor though? In theory, you could run the same preprocessor for Rust code (if you figure out some sensible macro shortcuts).
- clarry 7y ago
  Not much at all. It's a completely apples to oranges comparison, with the rust version having some error handling, support for longer identifiers, tests, relatively idiomatic style with line breaks and indentation where you expect it, variables and type names longer than one or two characters, etcetra. You could compress it massively before going for the preprocessor. In fact, a few of the preprocessor macros just make the C version longer (when measured in lines) than it would be without those macros if lines were allowed to be as long as in the rust version (<70 chars vs 100 chars). The printf macro (used only three times) actually makes the C code longer both in bytes and lines (or equal length in lines if you retain the 70 column limit). There's really only one macro (DO) that expands enough to save lines, but just barely. The shorthand for return saves quite a few bytes (but not so many lines) given that it's used everywhere.
empath75 7y ago
But why though. It’s a terrible way to write code.
- dang 7y ago
  Please don't post shallow dismissals: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html This topic in particular tends to get flooded with a few shallow clichés as soon as it arises. This is to be avoided, because they have the effect of turning a thread into the same generic argument as the last N times it came up, which is tedious. Better to respond to the specifics of a topic. Alternatively, if you want to learn, ask curious and neutral questions. But please don't pick one of the low-hanging bombs and toss it; the results are predictably boring. Not picking on you personally—we all have this reflex, and it's actually fine in in-person conversation, but bad for internet forums.
dirkt 7y ago
And the style (or the missing comments) is really what makes it hard to read. I am fine with higher-order functions (I do that in Haskell all the time), and letters for variables, but please, please, give your functions meaningful names. Or add a comment that explain what they do. Code is not only for the person writing it (who perfectly knows what the letters mean, at least for a short time after he or she wrote it). It's also for others who have to read it some day.

tomp 7y ago

How much of that is due to the C preprocessor though? In theory, you could run the same preprocessor for Rust code (if you figure out some sensible macro shortcuts).

clarry 7y ago
Not much at all. It's a completely apples to oranges comparison, with the rust version having some error handling, support for longer identifiers, tests, relatively idiomatic style with line breaks and indentation where you expect it, variables and type names longer than one or two characters, etcetra. You could compress it massively before going for the preprocessor. In fact, a few of the preprocessor macros just make the C version longer (when measured in lines) than it would be without those macros if lines were allowed to be as long as in the rust version (<70 chars vs 100 chars). The printf macro (used only three times) actually makes the C code longer both in bytes and lines (or equal length in lines if you retain the 70 column limit). There's really only one macro (DO) that expands enough to save lines, but just barely. The shorthand for return saves quite a few bytes (but not so many lines) given that it's used everywhere.

empath75 7y ago

But why though. It’s a terrible way to write code.

dang 7y ago
Please don't post shallow dismissals: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html This topic in particular tends to get flooded with a few shallow clichés as soon as it arises. This is to be avoided, because they have the effect of turning a thread into the same generic argument as the last N times it came up, which is tedious. Better to respond to the specifics of a topic. Alternatively, if you want to learn, ask curious and neutral questions. But please don't pick one of the low-hanging bombs and toss it; the results are predictably boring. Not picking on you personally—we all have this reflex, and it's actually fine in in-person conversation, but bad for internet forums.

dirkt 7y ago

And the style (or the missing comments) is really what makes it hard to read. I am fine with higher-order functions (I do that in Haskell all the time), and letters for variables, but please, please, give your functions meaningful names. Or add a comment that explain what they do. Code is not only for the person writing it (who perfectly knows what the letters mean, at least for a short time after he or she wrote it). It's also for others who have to read it some day.