How did you folks in the snap team develop snap I need some ideas and some tips and stuff for my new mod called blockal it’s an rewrite of snap but in p5.js
The Snap! team are against discussing the internal workings of the Snap! code
They strongly encourage using this forum for discussing the use of Snap!, not what the code it's written in does.
Okay sorry
Also can you maybe check out my new blockal thing it is an rewrite of snap if I made it and in p5.js the url is https://unrulymundanebinary.barbarabou.repl.co/
I too, prefer to talk about Snap! here 
Ok sorry but did you like it at least??? But if you still prefer to talk about snap you do not have to answer 
Also could you test something for me
Gang, this is my fault; @awdeni asked me this (in a reply to a private message in which I yelled at them about something else :~) ), and I said "start a new thread with this" because I didn't want to waste the following, which I'm guessing will be lengthy, on just one person.
Well, first of all, Snap! is about 99% Jens's work, and the overall design is 100% Jens. (He credits, among others, John Maloney for ideas in the initial Scratch implementation and Dan Ingalls and other Smalltalk developers.)
So I looked at p5.js, which I had never seen before. It has some welcome syntactic simplifications, plus the weird idea of having two main procedures called SETUP and DRAW, of which first SETUP runs once then DRAW runs (by default) forever. That feels weird to me because it forces you to use one control structure that they like. In JS (or basically any language) you can say
function main() {
setup();
for (;;) {
draw();
}
}
if you happen to want to organize your program that way. So I'm not sure why you chose p5.
But anyway, the implementation language is really the least of your worries. How closely do you mean to follow the internal structure of Snap! ? Are you proposing to reproduce each internal procedure of the implementation? Or, at the other extreme, do you mean to pay no attention to how Snap! works internally and design it yourself?
Quite a number of people have announced their intention of reimplementing Snap!, but hardly any actually pull it off, and the few who do are more experienced than I think you are. Here are what I think are the main tasks involved:
-
The evaluator. Imagine Snap! as a text language with no graphics capability. You'd still have to convert a program from a big string of text into actions for the computer to carry out. This is a semester course in any university computer science curriculum.
-
The whole theater metaphor for graphics, and its associated object hierarchy: the stage, sprites (actors), costumes, and so on. This isn't entirely separate from the core language interpreter, because the latter has to handle multiprocessing so that sprites can act in parallel.
-
Widget handling. In Snap!, this is the job of Morphic. Jens argues that it has to be Morphic, and in particular not the DOM graphics provided by browsers, in order to support "lively" programming, which means that you can modify a script while it's running, and it'll smoothly keep going with the new code. (You can insert blocks, delete blocks, change the values of inputs, and so on.) Others have disagreed, but I can't think offhand of a lively non-Morphic implementation. Gang? Am I forgetting one? (How lively was Nathan's version?)
-
FIrst class procedures. This is actually very little code, if you fully understand how this feature works and what it implies for the evaluator. (I argue that it should actually make the evaluator smaller, because it avoids a lot of special case kludgery.) But getting to "fully understand" is a substantial task in itself. (It's a big chunk of the course I used to teach at Berkeley.)
- No number, because it's a zillion little tasks, but getting the details right for every task domain. How is a costume represented internally? What operations on costumes must the language provide so that users can implement the other ones in Snap! itself? Ditto sounds. Ditto lists. (Linked lists or dynamic arrays?) What about colors? The trivial solution to each of these design problems is just to provide all the Javascript primitives as Snap! primitives. But that's not an ideal solution, because generally Javascript exposes to its users how the hardware works (e.g., colors in RGB because that's how monitors work--although not printers by the way), whereas we aspire to being a high-level language, meaning that we give users a way to express the problem they're trying to solve without having to think about how computers work at all. (If sprite A and sprite B both have an Alonzo costume, is that two copies of Alonzo in memory, or one shared copy? The user shouldn't have to know the answer, but the implementor has to decide on an answer.)
So, given all that, I wouldn't jump into a complete reimplementation. I'd focus on one part of Snap! and figure out how you could improve it. (For full credit, make the code smaller and more powerful for users!)
If I were going to make a Snap! mod, for example, I'd turn the color library into fast JS-coded primitives, and ditto the APL library.
I'm guessing you're not old enough to be able to read the best CS book ever written, Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Jay Sussman with Julie Sussman. (The link is to the full text online.) So meanwhile, learn Scheme, God's programming language. You probably won't write your eventual complete reimplementation in Scheme; you'll use JS, same as we did, because you'll want it to run in a browser. But you'd better be thinking in Scheme if you want to finish the project in a reasonable amount of time.
There.
I chose p5.js cuz it is easy and an challenge cuz it only has shapes and images and others
And I read a lot of things like adult novels and stuff
But they also have mouseDragged and others
Well, okay, read SICP! Give it a try.
Okay
And also the way scratch converts all those blocks into code is it uses the vm and morphic uses processes or snap does at least
Is Scratch lively? In the sense described above?
And I think it is lively but it originally origina5ed from squeak it uses the ScratchVM and ScratchGUI and ScratchBlocks which is a little extensive but at one time you cannot pack a bunch of code into one
So I agree morphic.js is a little of an better choice but I used prototypes and ES syntax!
So I see how to give MOVE an input but it's the only one. I take it you haven't gotten to the others yet?
Yep
And I’m still working on making it actually do move like if I enter 100 it does move 100