Hilarious. Hopefully this will end the endless flood of 'Beating C' posts. https://www.google.com/search?q=site%3Anews.ycombinator.com+...
Beating a C brainfuck compiler in rust/d/etc in 3 2 1...
Beating C with one line of Brainfuck
81–90 of 91 posts
Re: Beating C with one line of Brainfuck
#82Earlier quoted context omitted.
Note that: #define OUTPUTS 0 char outputs[OUTPUTS] = { }; is not valid C (or C++) - zero length arrays are not a thing in either language,
what it is being used for? I can't figure what that fwrite part does
That fwrite writes the contents of output to stdout.
output probably contains all the output that doesn't depend on input (which this program doesn't have).
Re: Beating C with one line of Brainfuck
#83I love how this blog only has this single post and it's dutifully tagged #shitpost. Thanks for sharing, I got a good chuckle out of it.
> and it's dutifully tagged #shitpost
This should be mandatory for all "beating X in Y lines of Z" format posts.
Re: Beating C with one line of Brainfuck
#84Earlier quoted context omitted.
For a #shitpost, one need only observe the fastest run of program A being faster than the slowest run of program B, to declare A is faster than B. With a sufficiently powerful static evaluator, you could embed the input into the program and get an even faster runtime.
> With a sufficiently powerful static evaluator, you could embed the input into the program and get an even faster runtime. If you feel the need to cheat, you could do something like I used for dumb_cat [0] and dump the resulting executables into a cache somewhere. [0] https://git.sr.ht/~shakna/dumb_cat
Wait... is that a Sourcehut user in the wild?
Re: Beating C with one line of Brainfuck
#85I love it!!! It is a great parody on latest trends in "my favorite xy language is faster than 'c/c++", each time I see one of those, it sends shivers down my spine. Your language, that was made in c/c++, can hardly be faster than the language it was written in. Whatever optimizations it has, you can still make them in c/c++ with enough knowlidge, but probably you can optimize it some more (staring at c++ template met…
>Your language, that was made in c/c++, can hardly be faster than the language it was written in.
You're making the mistake of associating the performance of a program to be purely be a product of the language. It is not difficult to write inefficient code in any language.
Re: Beating C with one line of Brainfuck
#86Earlier quoted context omitted.
I'm somewhere in the middle. I love my C compiler. At the same time I recognize the limitations of a lanuage that is now well in it's 5th decade. The problem is that we have so much tooling and of such high quality that it is hard to switch to anything else. For myself mostly because of habit, existing libraries and speed of compilation. The edit-compile-test cycle length is a very high factor in my productivity. Go…
> in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick Note however that even the those languages promoted as "safer" and "better" at the end typically use the C implementations of cryptographic routines (or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"). I see…
> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"
The point with being able to do this though is that sometimes you really do need to use unsafe code, but you still get to isolate the unsafe parts of your codebase from the safe parts of it, and you do so in a way that is defined by the language itself rather than in an ad-hoc way.
The language and the compiler enforces safety for the rest of your codebase, which in most cases makes up the vast majority of the codebase, and for the unsafe parts of the codebase where it doesn’t, you have a much more limited and clearly defined surface of code that you and everyone else looking at the code will know that needs to be handled with extra care, and which can and should be audited extra thoroughly.
Re: Beating C with one line of Brainfuck
#87Earlier quoted context omitted.
> in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick Note however that even the those languages promoted as "safer" and "better" at the end typically use the C implementations of cryptographic routines (or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"). I see…
> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise" The point with being able to do this though is that sometimes you really do need to use unsafe code, but you still get to isolate the unsafe parts of your codebase from the safe parts of it, and you do so in a way that is defined by the language itself rather than in an ad-hoc way. The language and the c…
And in the specific case of cryptographically secure code, you may well need to be paying attention to extremely low level details like the number of instructions being executed on different branches, the states of various buffers and caches, etc. It may well be that it doesn't make sense to expose control over these things to the high level layer where it's irrelevant 99% of the time.
Re: Beating C with one line of Brainfuck
#88Earlier quoted context omitted.
Has anyone used Rust to write an interpreter for INTERCAL yet?
Of course. [0] [0] https://github.com/birkenfeld/rick
Oh good. Though it's a shame that the test suite is a `test.py` file instead of `cargo test`; it would have been extremely satisfying to know that the Rust project would run the test suite for an INTERCAL compiler on a regular basis as part of Crater.
Re: Beating C with one line of Brainfuck
#89Re: Beating C with one line of Brainfuck
#90Earlier quoted context omitted.
> With a sufficiently powerful static evaluator, you could embed the input into the program and get an even faster runtime. If you feel the need to cheat, you could do something like I used for dumb_cat [0] and dump the resulting executables into a cache somewhere. [0] https://git.sr.ht/~shakna/dumb_cat
Wait... is that a Sourcehut user in the wild?
Of course. I love what Drew has built. I'm much happier (as a paying customer) with it as a platform than most of the others.