31–40 of 49 posts
Earlier quoted context omitted.
Is that why nobody uses it anymore? Only thing I know about it is that it used stack like expressions. (kinda like RPN but for everything)
I think nowadays more interpreters/compilers are being written for FORTH than stuff in the language itself.
So the Ruby guys have an unfair advantage. As a non-Ruby guy hope they fix this. But it still feels bad. I only found that site a few days ago and it looked all flashy compared to codeforces but now - It raises severe questions about its accuracy. Kinda like Chrome dinosaur high scores.
If they allowed FORTH it would be even worse -- everything in FORTH is redefinable -- you could make 1 equal to 2 if you want.
Uh, oh. You're the James T Kirk of CodeWars. It's like beating the kobayashi maru...
But also like James T Kirk, he was banned for cheating after beating the test. :)
"Ruby is love, ruby is jazz."
Yeah. No, thanks.
Earlier quoted context omitted.
They could just add a test that makes sure trivial comparisons still work.
sure that would work too :)
Or only return "true" on the 2nd call to the comparison?
Just some random ideas.
I'm surprised that the test for pass/fail is within the interpreter, rather than a string match against the stdout of a sandboxed interpreter.
For instance, if you ask me to write a program that computes the first 100 digits of pi, I can just have it print a string literal.
Anything that has no inputs, or that has a small input space, or that is known to be tested with only a few known input cases, can be cheated by cooking the output.
A "cheat-resistant" way to verify that something is working is to choose problems that have a large input space, and randomly probe the space.
Famous examples of this kind of cheating have occurred in compiler benchmark. A compiler can recognize that the program being fed to it is a known benchmark, and produce an optimization of the benchmark as a whole. I.e. "if the abstract syntax tree of 279 nodes is exactly this particular one, spit out this canned piece of code which 'translates' it."
The code does not execute properly. Try to figure out why.
int multiply(int a, char *b) {
return a b;
WTF? Who the hell multiplies a char pointer with an int? Why not just a char? Do I need to multiply the pointer address or the value the pointer points at? Do I need to check for NULL?
Why not write proper code instead of solving these "puzzles"?
I'm surprised that the test for pass/fail is within the interpreter, rather than a string match against the stdout of a sandboxed interpreter.
Earlier quoted context omitted.
I think nowadays more interpreters/compilers are being written for FORTH than stuff in the language itself.
Kinda like BrainF * I see. Turing complete but a readability nightmare. Maybe I should try to write one for FORTH like for BrainF *. Was an interesting exercise especially the loops.
https://www.forth.com/embedded/#Annotated_example_source_cod... contains a version of the canonical washing machine program.
\ Top-level control
: WASHER ( -- ) WASH SPIN RINSE SPIN ;