I made a text based scratch coding language that compiles to Scratch (.sb3) files.
I know there are already better text based scratch programs, but I wanted to try my hand my making one, mostly because it seemed cool.

I've spent the past month or two making my own language — ScratchScript

Try it out here:
https://scratchscript.quuq.dev

Here's the code:
https://github.com/redspacecat/ScratchScript

Most original ATs project: /j
The syntax for hat blocks is a bit weird. In my opinion, they look too much like regular blocks. Why not use curly braces for those?

Other than that, this seems neat.

Edit: Where can I find the source code for the compiler? Never mind, it's in /files/js/app.js. You may want to split the compiler off into its own file for separation of concerns.

Redstone1080 wrote:

Most original ATs project: /j
The syntax for hat blocks is a bit weird. In my opinion, they look too much like regular blocks. Why not use curly braces for those?

Other than that, this seems neat.

Edit: Where can I find the source code for the compiler? Never mind, it's in /files/js/app.js. You may want to split the compiler off into its own file for separation of concerns.

I know the hat blocks syntax it a bit weird. I was going to use curly braces for that, but I added them late and it seemed like a lot of work. I'll add that in some future update.

What do you mean by “You may want to split the compiler off into its own file for separation of concerns.”? app.js basically just does compiling and a bit of other stuff. editor.js handles most of the other features.

redspacecat wrote:

What do you mean by “You may want to split the compiler off into its own file for separation of concerns.”? app.js basically just does compiling and a bit of other stuff. editor.js handles most of the other features.

At least from my point of view, app.js is supposed to handle frontend stuff, because of the name. However, it also contains the compiler, which I found confusing. You could move the compiler to a separate “compiler.js” file, which would be a lot cleaner and less confusing. This is basically what separation of concerns is:

Wikipedia wrote:

In computer science, separation of concerns (sometimes abbreviated as SoC) is a design principle for separating a computer program into distinct sections.

Redstone1080 wrote:

~snip~
At least from my point of view, app.js is supposed to handle frontend stuff, because of the name. However, it also contains the compiler, which I found confusing. You could move the compiler to a separate “compiler.js” file, which would be a lot cleaner and less confusing.
~snip~

I'll do that

Edit: done

why is the variable syntax
and not something like this

aspizu wrote:

why is the variable syntax

setVar("correct", 0);

and not something like this

$correct = 0;

Because that's more complicated to implement

If you are not using a library to parse the code, I would suggest implementing a lisp syntax.

aspizu wrote:

If you are not using a library to parse the code, I would suggest implementing a lisp syntax.

The parser is already written, and works with the current syntax. There is no reason to rewrite it to parse a lisp-style syntax.

bump

bump

bump

Have you thought about implementing converting SB3 files to ScratchScript? May try it out myself.

Spy-One wrote:

Have you thought about implementing converting SB3 files to ScratchScript? May try it out myself.

I've thought about it, and it seems fairly difficult. I might try it though, it would be very useful.

redspacecat wrote:

Spy-One wrote:

Have you thought about implementing converting SB3 files to ScratchScript? May try it out myself.

I've thought about it, and it seems fairly difficult. I might try it though, it would be very useful.

True. I've been experimenting with something like ScratchScript for a bit; I call it Felis, it would basically be the same thing but with a much different syntax + it allows for much more advanced stuff (custom, like being able to make shapes or 3D stuff); essentially stream lining development.

Spy-One wrote:

redspacecat wrote:

Spy-One wrote:

Have you thought about implementing converting SB3 files to ScratchScript? May try it out myself.

I've thought about it, and it seems fairly difficult. I might try it though, it would be very useful.

True. I've been experimenting with something like ScratchScript for a bit; I call it Felis, it would basically be the same thing but with a much different syntax + it allows for much more advanced stuff (custom, like being able to make shapes or 3D stuff); essentially stream lining development.

Cool, I'm looking forward to it.

Alright; so I got around to learning the syntax thourougly and made a 3D renderer using ScratchScript. Honestly; very intuitive and easy to use, some confusion of course and not too readable at times but other than that it's pretty good.

https://scratch.mit.edu/projects/1208723389/

(Note; there are a few changes in the project I made manually regarding brevity and performance, since ScratchScript doesn't seem to have custom blocks yet)

Some suggestions I would make:

1: Definitely add custom block support, it'll streamline stuff a lot and allow for much more complex stuff to be made and tested using this.

2: Increase readability. I don't want to try to force a certain syntax on you but the empty line being a separator for scripts doesn't give much freedom in general, and also makes it *really* hard to read through and debug your scripts.

3: Add easier ways to handle lists and variables

4: Possibly some formatting and error underlining?

Custom block support is most important imo; with run w/o screen refresh, it could really elevate the usefulness of this. Tbh that's the only thing putting me off using this full time; but yeah this is amazing. Good job.

Spy-One wrote:

Alright; so I got around to learning the syntax thourougly and made a 3D renderer using ScratchScript. Honestly; very intuitive and easy to use, some confusion of course and not too readable at times but other than that it's pretty good.

https://scratch.mit.edu/projects/1208723389/

(Note; there are a few changes in the project I made manually regarding brevity and performance, since ScratchScript doesn't seem to have custom blocks yet)

Some suggestions I would make:

1: Definitely add custom block support, it'll streamline stuff a lot and allow for much more complex stuff to be made and tested using this.

2: Increase readability. I don't want to try to force a certain syntax on you but the empty line being a separator for scripts doesn't give much freedom in general, and also makes it *really* hard to read through and debug your scripts.

3: Add easier ways to handle lists and variables

4: Possibly some formatting and error underlining?

Custom block support is most important imo; with run w/o screen refresh, it could really elevate the usefulness of this. Tbh that's the only thing putting me off using this full time; but yeah this is amazing. Good job.

Thanks for the useful feedback. I'll try to implement it when I get back to a computer.

aspizu wrote:

why is the variable syntax

setVar("correct", 0);

and not something like this

$correct = 0;

in my honest opinion the former syntax looks cleaner and easier to understand as well as implement. you have a function, two arguments, and all you gotta do is set them. just because goboscript does it differently, doesn't mean every single compiler now has to do the same.

redspacecat wrote:

Spy-One wrote:

Alright; so I got around to learning the syntax thourougly and made a 3D renderer using ScratchScript. Honestly; very intuitive and easy to use, some confusion of course and not too readable at times but other than that it's pretty good.

https://scratch.mit.edu/projects/1208723389/

(Note; there are a few changes in the project I made manually regarding brevity and performance, since ScratchScript doesn't seem to have custom blocks yet)

Some suggestions I would make:

1: Definitely add custom block support, it'll streamline stuff a lot and allow for much more complex stuff to be made and tested using this.

2: Increase readability. I don't want to try to force a certain syntax on you but the empty line being a separator for scripts doesn't give much freedom in general, and also makes it *really* hard to read through and debug your scripts.

3: Add easier ways to handle lists and variables

4: Possibly some formatting and error underlining?

Custom block support is most important imo; with run w/o screen refresh, it could really elevate the usefulness of this. Tbh that's the only thing putting me off using this full time; but yeah this is amazing. Good job.

Thanks for the useful feedback. I'll try to implement it when I get back to a computer.

have you added it yet?