I dont understand. Warp is great and all but it kinda just does everything in spurts. if you convert everything to JS and have nothing that pushes an update to the screen until the full script finishes wouldnt it be so much better. similar to scratch run without screen refresh. its just ironic how snap! allows much more complex Ideas but those ideas cant be run at a good speed.
good luck: it was in 2021…
its why the forums and people on snap start making js codes and extensions instead of native projects
Snap! is mainly intended to be an educational teaching language.
Over the years, it has been sped up considerably but is still not intended to be a production language like JavaScript/C/Rust etc
Anybody wishing to move to programming in other languages is more than welcome to do so.
Complaining about the speed of Snap! or keep talking about JavaScript is not as welcome 
this is so condescending. asking why there cant be a system for running functions that dont have anything to do with display is not unwelcome.
You are obviously a quite competent programmer and have produced some really clever Snap! code.
I was pointing out the reason for Snap! existence in case you were unaware of it.
No offence intended
This is basically you, you, you, and 2 other people. I have made really big snap projects with 0 js, and so have many other people. If you want to go do JS more than you want to do snap, go do JS :)
Here’s something that (might) help:
It’s similar to the “compile” option in MAP, KEEP and FIND FIRST ITEM. If it can compile the code (with JIT) then it runs that compiled version. Else it’s just a normal WARP.
It’s not a bad question, but I think we have a good answer: We don’t want a bug in your program to result in an uninterruptible infinite loop.
We really envisioned WARP as a way to make a pen drawing look atomic, like this:
The WARP “stamps” a square on the stage, so you don’t see the sprite jumping around.
Speeding up lengthy computations is another use case, but that one is less important than keeping Snap! code interruptible.
Ah fair. Is there any way that you would be able to stop the loop and not actually refresh the screen. How do other systems and programs deal with this. I believe in Java if a loop is going for too long it force stops it.
EDIT: call stack
I believe that in most systems the code that handles UI events (such as clicking a stop button) doesn’t compete with user threads, and anything analogous to WARP only affects user thread scheduling. But I couldn’t swear to it.
do you think snap! would be able to implement a true run without screen refresh with a max call stack either set by snap! or as an input to prevent infinite loops
You can’t rely on stack depth as a measure of process complexity; an iterative structure such as REPEAT UNTIL doesn’t grow the stack, but can still run forever if the tested condition is never satisfied.
And even a recursive structure won’t grow the stack if it’s tail recursive.
But in any case, why look for a proxy for runtime, when you can just use the runtime itself?
Saying it another way, your issue isn’t that we guard against infinite loops inefficiently; it’s that you don’t want us to do it at all! ;~)
does this only work for the hofs?
That just gave me an idea (and it works!):
For a test I put a wait 10 seconds block in the c-shape, and sure enough there were no haloes or response from buttons until 10 seconds had passed.
I think I did that once
I’ve read a bit of the SNAP! source code, so I do know that compiled HOFs are attempted to be converted into JIT functions
interesting… so can this be applied to super long functions and if so can we add a callstack to stop it
Being able to stop it requires the screen to refresh, along with running other scripts. What you want won’t allow for that.
As Simon, Brian and others have already mentioned, Snap! is designed to be educational and explorational. Usually when you learn a programming language and you make a mistake your program simply crashes, because once you start running it, you as the user are literally out of the loop. Snap, on the other hand, tightly integrates the runtime into the IDE, in fact, the IDE is the runtime and the debugger, it’s a window onto the actual processes inside Snap. I’m not sure how many people actually know, let alone appreciate this. Learners (and educators) simply take it for granted (and then fuzz around how it’s “laggy” or “slow”, which, I guess, is great, because they don’t even realize the technical feat behind the system that gets them to a point where they feel empowered to complain about such things).
That said, there are a number of tools and techniques that put you as the learner / project author in charge of the granularity at which you can interact with a script. And that granularity / atomicity affects how “fast” elements of computation are evaluated.
Here’s a rough demo of different programming styles supported by Snap. Each script produces a list of a hundred thousand random numbers:
The scripts vary wildly in terms of expressivity, paradigm and performance. In general it’s impossible to beat hyper. Often “compiled” is nowadays slower than regular HOF, and recently the gap between regular loops and warp has become less for non-visual / animating operations.
So, to answer your question: No. I am not at all interested in turning Snap into a “game engine”.
Here’s a rough demo of different programming styles supported by Snap.
Wow, this is really helpful! I love it that HOF beats imperative. :~D I knew that hyperblocks would do this fastest, but I didn’t realize it was by such a huge factor.