Sorry for the long response! Lots of questions asked in a short post. I want to be as detailed as I can be to avoid confusion in this post, but I’ll make a TL;DR right now because it’s long haha.
So you suggested a possibility for code compilation on the other topic:
There could definitely be an npm command line tool! I think this would be very usable, because some of the Hopscotch community has been delving into web development lately. I also think that because Hopscotch projects run independently on the web, the languages match up in that regard as well. (One may also consider npm support with code editors from the App Store, or from a SaaS website people may use for coding.)
I think a faster language like Rust would still be less convenient to use than JS anyways, in a collaborative context, because I think the majority of programmers on this forum know enough Node to get by–and if not, then it’s really easy to learn. It also allows (-1 members?) testers to look into the compiler code and try to bug it out, haha.
Personally, I think VS Code is a widely-used editor, and there aren’t a lot of amazing environments for writing code on the go (besides Codespaces, I guess) – and the mobile app exists for that reason already, of course – so let’s say we target the scripting language towards desktop users for now. There could definitely be VS Code tooling for the language, and maybe even lint support along the lines, if someone decides to try their hand at that in the future at some point. I guess coding syntax highlighting for the language would be worth looking into as well before then.
I’d imagine that the easiest approach to creating an IDE-like toolchain within VS Code is to provide an extension that lets you compile a project with the NPM compiler, and then open the output in a web browser in your browser, preferably offline. I think you have experience with that sort of thing!
And then, here’s the cool part:
Later on, after the actual language and compiler is written, there could be a Hopscript to block interpreter to be used on the web somehow, if we intend to make the language be visually identical to that of Hopscotch’s. That could be another interesting way to introduce the block coding aspect to other platforms, as well as the language itself! – and there could be a Code.org-like toggle between text coding mode and block mode. But this would be a plan after the language itself is completed.
So there are a couple ideas:
- Objects that act as classes, held in scenes, which can all be held in files
- Files that act as objects, and folders that act as scenes?
Well, let’s think about this ergonomically. We want to use files to separate major chunks of code.
I think it could be worth using files as individual objects, because the code inside of objects can be quite massive at times. This answer can also be different depending on the custom functionality we intend to add to the language, like libraries and functions. Definitely something to discuss among more experienced programmers though, haha.
So, I think libraries could be written as Hopcode. The code could be compiled into a project, and maybe there could be some sort of interface assigned (ie. protected in Java) as well as private/public functions? I’m not sure exactly how custom we want it, but maybe we could take a Java-like approach to it - scan the objects within a compiled Hopcode-compatible binary and see what functions have been exposed for use, I guess. And then from there, the name of the library, etc. could be stored within a meta file, which is packed into a separate object within the compiled library binary. Does that make sense?