Yep, Java is a good choice. I've noticed it to sometimes outperform C, perhaps due to automatically parallelizing things that aren't explicitly multithreaded.
And speaking of which, Vyxal should have a flatten flag. Which converts strings in the input to char lists. Putting f in the Header is not quite the same thing, because programs can still push the original input.
It already has something that's kind of the other end of this, the s flag for output.
Also, is there a good reason for not allowing, for example, ⟨1₀₁⟩ to be equivalent to ⟨1|₀|₁⟩? i.e. allowing nilads to be self-terminating within a list.
By the same token, it should be possible to e.g. use ₍₀*² to both multiply a number by 10 and square it.
[Discord Relay] cjquines#0001: in my view, the point of using a golfing language to do code golf isn't about making a language that has the fast/best/whatever solution, but about composing built-ins to express a solution in an elegant way
[Discord Relay] cjquines#0001: a golfing language fails if it cannot express the solution i have in my mind in a straightforward way
[Discord Relay] cjquines#0001: well… that's not quite it, actually
[Discord Relay] cjquines#0001: part of the reason i like vyxal is because of how active its development is
[Discord Relay] cjquines#0001: so many contributors! so many prs!
[Discord Relay] cjquines#0001: unrelated: my wishlist includes categorizing our billion elements into things so it's easier to learn elements other than through search
@VyxalBot Speed matters, because it allows more ambitious programs to be tested more thoroughly than would otherwise be possible. And allows them to be demonstrated with test harnesses consuming less CPU power. And some things just couldn't be demonstrated in the time limit try-it-online sites have with the language being too slow.
Example: tinyurl.com/rudolph-Java-v0-62 - My Java implementation of this algorithm takes 3.85 seconds to execute on TIO. But my Pyth implementation of it - codegolf.stackexchange.com/a/198173/17216 - takes 51 seconds for the 129 byte version, and the 126 byte version takes 17 minutes, and obviously can't finish within 60 seconds.
We're going all in on niche practicalities for an esolang
We have a custom SE chatbot, github organisation, style guide, syntax highlighter, stylish and highly optimised tool tips, actually mandated PR reviews, 99% automated prod updates, automatic pypi updates and more
So a debugger doesn't seem that much of a stretch for us
It might be if this was Jelly or 05ab1e but we're different
We do the things that significantly improve quality of life
Because when life gives you lemons, you don't make lemonade...no,you give them back to life and demand to see life's manager. We burn people's houses down with the lemons because we make them combustible lemons gosh dang it!
@PyGamer0 i was considering writing a post on compilation lol
> A JIT compiler can be faster because the machine code is being generated on the exact machine that it will also execute on. This means that the JIT has the best possible information available to it to emit optimized code. If you pre-compile bytecode into machine code, the compiler cannot optimize for the target machine(s), only the build machine.
Why don't we get rid of the repr with the ⟨ 1 | 2 | 3 | 4 ⟩? Especially with nested lists, it's so hard to read. I'm getting tired of putting in P flags constantly lol
⟨0|1⟩→{←₍t∑:→ h?≤|← h,} prints the Fibonacci sequence until reaching the input number, as intended. But why does ⟨0|1⟩{₍t∑:h?≤|:h,} not do so, even though 0{›:?≤|:,} and 0W{›:h?≤|:h,} both print consecutive numbers from 1 up to the input? Am I misunderstanding how while loops work, or did I find a major bug in them?
And how come k≈:t$∑W:t$∑W:t$∑W keeps calculating the next Fibonacci up each time a :t$∑W is appended to it, but k≈{:h,:h?≤|:t$∑W} and k≈{:t$∑W:h?≤|:h,} print OEIS A002605?
On another note, why does k≈⁽+dḞ generate Fibonacci? Why is it possible to omit the ; lambda-closer? What is the d doing? For some reason even k≈⁽+2*Ḟ works, and I'm confused because there's no multiplication of 2 in the generation of Fibonacci numbers. What does it mean?
And why is 1⁽+dḞc (1-indexed Fibonacci) much, much faster than k≈⁽+dḞc (0-indexed Fibonacci)?
@emanresuA um... okay... but that's not an explanation at all
Do you understand why it works, and if so, could you please explain it?
Okay, so that does explain it, thanks.
I was misinterpreting the documentation of ⁽, ‡, and ≬... I thought 1, 2, and 3 were the number of arguments, not the number of bytes of code they took.
@Steffan So is ⟨0|1⟩⁽+dḞc being fast and k≈⁽+dḞc being slow caused by the bug that you just fixed?
