Whatever. My point is, if you're going to complain about the speed of MAP, make sure you're compiling it.
how much faster does compile make it
Depends on the function you're trying to map, but usually a lot. Try it.
Discussion such as "why is map slow" and then musing about experimental JIT-compiling etc. make me all queasy. The reason why I suggested you "read the code" and "learn about architecture" is so you find out yourself about these things. Of course it's easy to make things super fast, computers are fast. What's special about Snap, though, hmm? Any ideas? See, we're getting incredulous requests from fellow developers at SAP as to how we managed to pull of parallelism in Snap. They can't believe that it's possible with JS, and want us to teach them. That's something to start looking into. Everything is easy when you only have a single process. That's the root of so many questions here. In your other programming languages you usually don't multi-task. Think about what a higher-order-function actually is, and what you can imagine to go inside the ring. Think about it!
edit: Oops, I've addressed this to the wrong person, duh, I was referring to @avi_shor
agreed. im sorry if i offended. jens you actually scrare me because of how much you know and how straightforward you are lol.
stop it, you're not offending me. When you say
to which the usual suspects suggest to
and after Brian patiently explained our implementation strategy, and you still inquire about things being "slow" you gotta accept my hint about concurrency and my invitation to "Think about it!" yourself 
1 last question. why isnt compile automatic
worked faster but my computer thought the site wasnt responding during the process
JIT-compilation was an experiment that has been superseded and eclipsed by hyperblocks. Compiling to JavaScript isn't really much faster than just running the thing in JavaScript in the first place. Snap is both a programming language and a live authoring environment that offers you to build complex programs running in parallel processes. If we just "run" stuff in JavaScript it'll be super fast, unless it goes on for a long time. Chunking matters, because we need to yield every process to other processes - including you, the user (!) - also get a chance to interact with the project, e.g. to press the red stop button. If your - very fast - Griffpatch engine chokes on an unexpectedly big costume (remember, Scratch doesn't let you change the stage dimensions) while you're developing it you will not be able to even stop the project. Instead you'll have to kill the tab that runs Scratch or Snap, and that way you'll often loose a lot of work, and it will be extremely frustrating. This is not about things like "efficiency" or how to design a "fast engine". Geez. It's about being friendly to learners that have to take CS in school and don't yet know that it's at least as fun as playing football or the guitar.
So, since you've proven yourself to be a capable mathematician, think about this: A higher order function such a MAP repeatedly applies a function to data, the trick being that it doesn't know anything about that function, except that it assumes it to be monadic, i.e. taking exactly one argument. MAP has no idea what that function actually does or how it works. When you're a mathematician such details aren't important, because the beauty of math is that it abstracts processes into timeless expressions. But when you're a programmer, time does matter (as you yourself keep pointing out). Since MAP can call any function Snap needs to make sure that whatever that function does won't just end up blocking user interaction to Snap. And that requires a lot of design and a lot of computation.
ohhhh. so does compile turn that off
yes, precisely. Compiling comes at the price of risking hard "hangs" and loosing all your work, which is why I'm not enthusiastic about it. Hyperblocks doesn't have that issue, because we only hyperize functions that we know for sure will terminate within reasonable time.
ahh ok
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.