Should (How should) Snap! be more popular, etc

i dont think snap's goal is to be a better version of scratch. i mean, they are obviously inspired by scratch, but they go different way. no need to become better version of something, just become better themselves.

you see, you are not clear again. that already exits yeah, it is not stable, but thats what we have. what other stuff you mean? turbowarp has a bunch of other extensions so making that converting to Snap! would require a lot of work. if you dont use external extensions you can convert them though.

The thing is that Snap! was destined to be less popular than Scratch since the start, mainly because Scratch has devolved into a social media app rather than a coding app.

We (and by we I mean the Snap! Developers like bh) don't want Snap! to become a website only used for playing games (those of which our Snap! users have made) and socializing. I sometimes go on Scratch to play games rather than code. We want Snap! to be more about coding and not about the socializing aspects.

Snapp is an extention to Snap! that converts Snap! Projects into .exe files. But like @luna.judah said, it's not stable. For example some things might not download, some things might be corrupted on the .exe file after the conversion, yeah it's just...yeah.

i bet you almost no one around programmers knows about Snap! thats an issue! i want to go and proudly say imma snap dev :sweat_smile: :sob:

And you can say that here :sunglasses:

WE CONSTANTLY DEBATING HERE :sob:

:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
:man_facepalming:
PLEASE STOP THIS IS GETTING OUT OF HAND REALLY QUICK!

i believe they meant something like snapinator to convert their scratch projects to snap. but yeah, it wont work good not only because snapinator misses some block implementations, but also because snap is less efficient in stuff scratch is good. my light simulation initially was made for scratch, and actually runs faster there. when i was porting it to snap i tried converting it with snapinator, which came out to be terrible. it almost converted it correctly though. i fixed some blocks and yet the thing was very slow so that it would take hours to render 1 frame. thanks for scratch being advanced i refactored the code for snap so made it faster many times, but still initially i was in hope that the porting will make it faster, but eh.

@slate_technologies, yes Snapp isn't stable, but that could be fixed. Plus, I wasn't talking about Snap! to .exe, I was talking about Scratch/Turbowarp/"insert other Scratch extension/Scratch related thing here" to Snap! And yes, @luna.judah is correct that a converter to Snap! exists for Scratch 3.0, but it isn't stable. That could be fixed as well. Plus, we could POTENTIALLY circumvent a lot of work by HAVING those extensions in Snap!
EDIT: While I was typing this, @luna.judah actually stated it a bit like I said it, but yeah, I agree Snap! also needs to be more efficient.
EDIT 2: It changed again while I was reading it.

after finishing refactoring Snap! for older browsers support i will look into optimizing the code. i know almost nothing about js, but i am good at prompting and for some reason GPT-4 is good with JS so lets hope it works. stay tuned i guess.

Ah. OK. Optimization is good, I suppose. Hopefully the optimization applies to both the OG code and the refactored code.

Also, I didn't know that GPT-4 was good with Javascript. What do you think would need to be optimized? And would this affect Snap! or would this be like Snap! was with Scratch?

well, to be fair it is not as good at creating stuff. just at refactoring and optimizing.

What do you think would need to be optimized?

no idea as i never looked much into snap's code. it would be actually hard to make snap as fast as scratch because of it being more advanced. like, in scratch variables are much more simple. they are just strings. while in snap their variables can be any types of objects which slows down it much. i wish we had different types of variables in snap just for optimizi... wait... its actually a good idea for making a library xd

Ok. Will it affect Snap!. or would this be like Snap! is with Scratch?

? So what's the answer? Will it affect Snap!, or would this be like Snap! is with Scratch?

Hey, @luna.judah. Will the optimization affect Snap!, or would this be like Snap! is to Scratch?

huh? you dont have to spam. wdym by

like will the Snap! be the same speed as Scratch? i guess it can be? with using compiling too ofc.

have you ever heard of snappinator

I'm exaggerating, of course, but countries that don't use Scratch mostly don't have the infrastructure to teach with Snap! either.

Actually I love when kids come to Snap! on their own initiative. They generally write more interesting projects, ask better questions, and are the superstars of our community. (Note that I said "generally"; there are kids who start using Snap! in school and get really interested and become superstars, and there are kids who come to Snap! on their own, but do "remix this project and add your name.")

But we're talking about popularity of educational programming languages, and the use of Scratch in schools gives them a huge advantage that we'll never match, even though we're used in some schools too.

Haha, we didn't choose them, they're the colors we inherited from Scratch 1.4. :~) But if it's eye-burning you're worried about, how can you like white backgrounds? That's what burns my eyes.

More seriously, that sort of thing isn't what prevents people from liking Snap!, not if it's advanced ideas they want. Imho we have no real competition among visual languages when it comes to ideas. Afaik nobody else (except of course for Snap! mods) has first class procedures, not even App Inventor, which is very respectable about presenting other big ideas. (In saying this, I'm not counting exact visual equivalents to text languages, such as Greenfoot.)

There's a chicken and egg problem about popularity. Because everyone knows about Scratch, they attract big donations from rich people, companies, and foundations. And therefore, they can afford a large team of full-time programmers, a large team of moderators, and all the storage and bandwidth in the world. In our world, otoh, even Jens isn't a full-time Snap! developer, because SAP wants him to spend a lot of his time writing curriculum, running workshops, and speaking at conferences. And Jens is still paying for storage out of pocket. So we're limited in what we can do. In particular, we have no public relations department. Adult CS professors know about us, because we speak at those conferences. We're doing okay at becoming known to secondary school teachers. But kids? I wouldn't know how to begin. We do better in Germany, because Jens and Jadga do know how to begin. They're on social media, for one thing. And, as I said, they are in part paid to put video on the web. And because other people, CS professors, write textbooks using Snap!.

I don't think this is a flame war; hardly any posts are ad hominem attacks, for example. I think there's been a lot of confusion about what people are intending to say, partly because there are crossing discussions on somewhat different topics, and partly because people aren't always so good at expressing themselves, because, you know, they're kids, and they're programming nerds. :~P

Yeah that's not exactly what we want to be popular for! I'm especially nervous about the occasional "I got banned from Scratch so I'm here now," because quite often when someone gets banned it's for a reason. But, that aside, we don't want to be a substitute for Scratch for whatever reason. We want to be your first choice!

Real-world programmers, no; not unless they have adolescent kids. But we're pretty well known among programming language researchers. :~)

Ok, we need to get back to the actual OG topic.