how do we code extensions like you can for scratch
Extensions are just libraries. Look at SciSnap, for example.
if you wanna make it do stuff you cant do in normal snap, use the javascript block, because the src_load primitive doesnt allow other links sometimes for security
but i want something with real code. for example griffpatches physics engine extention runs instantly because it wasnt made with blocks.
use javascript
its not just "use js" its more complicated then that
its the only way
griffpatch even used js in his extension because scratch extensions are powered by JS
if you wanna make a extension with things not in snap, use a mix of blocks and js
Snap is powered by javascript as well, and the thing is, snap has it too, it's hidden in the advance settings under "JIT compile" Which is all "turbowarp" is as well.
A lot of people are unaware of what scratch does behind the scenes to assist their users whereas snap! just does a lot of it straight up and faster, but because they then try to write scratch code in snap! and snap doesn't assist anywhere near as much or at all in comparison to scratch, and thus it seems "Slow"
Like, in griffpatch's video's on his dropper technique and how they built a fast image scanner and how they did it... it's all kludge and duct-tape.
Whereas Snap! just has the V of costume V block. Which just straight up gives you the list instantly.
I've long given up hope on an SAP SNAP! Course Three...(I'm sure it's coming eventually) but if it were to be done, I'd build upon the stuff in the first two courses and then use it to build an actual full 3D game engine, because while the amount of data has increased, from Wolf3D to fortnite, most game engines are pathtracing algorithm's with a painters algorithm on top for distance sorting. Ray Tracing is just then adding more bounces, but using data from the previous bounce to direct the next bounce.
Now, that's the simple version and omits a LOT of steps and is mostly wrong, but the basic framework is already in the two snap sap courses.
Now, I also want to clarify. Snap! is not javascript. Snap is it's own, very powerful language, it just happens to use javascript as most browsers all use javascript.
.
I'm not sure whether the question you're asking is technical or political.
To start with the latter, if you're asking how to build a Snap! extension and have it supported by us as an official extension, the way TurtleStitch is, it helps if you have a large user community and a reasonably long history of maintaining your extension, so we know that it's something people want and that it won't become unusable down the road. It also helps if you have a prior relationship with us; for example, the EDC "microworld" restricted environment code (not what the word "microworld" really means!) is supported because the same people at EDC were part of the team that developed our Beauty and Joy of Computing curriculum.
TL;DR: We are very picky about our collaborators, especially because you don't need our blessing to develop your extension independently.
Okay, on to the technical question. Part of what it means to be a Snap! extension is that what you develop fits well into Snap!. To take an extreme example, if you develop a Snap! block that, when clicked, pops up a separate window, and thereafter the user interacts just with your code and your UI, that's not a Snap! extension. An extension is a library, a collection of blocks that make sense as a toolkit with which users can build Snap! projects with some new capability.
Many extensions can be written entirely in Snap!, without JS at all. Ones that deal with special hardware, such as a robot, might require JS, although maybe not even then, since we have the URL block and many hardware devices provide an HTML interface these days.
All else being equal, it's better if you write Snap! code rather than JS code, because one of our guiding principles is that users should be able to look at the insides of libraries, and even of Snap! itself, and understand how they work. The "blocks all the way down" feature of the coming version 10 is something we've wanted from the very beginning, an idea we learned from Smalltalk, which is written in Smalltalk.
Sometimes there will be core functions that are just too slow to be practical when written in Snap!. The paradigmatic example for us is the higher order functions MAP, KEEP, and COMBINE; we originally wrote those in Snap!, not in JS, and they were fast enough for the applications people were writing in the early days. Then came media computation, and first class costumes and sounds. The underlying data (pixels or samples) are just too massive for HOFs written in Snap!. So, reluctantly, we rewrote them in JS. But with "blocks all the way down," we can have our cake and eat it too, with fast HOFs that users can still edit to see how they work.
All this is to say that instead of just importing a big hunk of JS code, it's better if you restrict the JS to where it's really needed.
If you're asking how to interface with aspects of the Snap! user interface, e.g., how to put some new kind of widget on the stage, you have to ask more specific questions.
why is map still slow then
If you're such a coding hotshot that you can't wait to contribute "real" JavaScript I'm sure you can read and understand ours, and also Snap's architecture.
yours is blocked on my chromebook. i wasnt taking shots at snaps!
I don't understand these two sentences, can you explain them to me?
You were asking
to which I suggested that instead of making a claim disguised as question expression your superior coding skills you read and understand our code. There is even a full documentation on how to write your own extensions. Lots of people do it.
My code is not superior. The code for snap! is way beyond me and I'm not saying that its bad. I just feel certain things can be optimized, IK its not priority and that's why its not done. I'm sorry if what I said came off as a complaint.
If you're going to do timing experiments on MAP, right-click on the block and choose "compile."
wym
You were making empirical claims, which I presume to be based on experiment, about the relative speed of two approaches to a problem.
that was another topic
Oh maybe you're right. You just asked why MAP is "so slow," which kind of implies some standard of comparison.
sry