Hopscript: Hopscotch Text Language (Concept)

Not sure if I can do it by then, but I don’t mind if you guys get a head start on this

You can also search for just the UUID in the web explorer and it will match an ID result

2 Likes

Thanks for the tip!

It should be maybe ~100ish lines of code, excluding config files, so if you have maybe 30 minutes to spare to rush an initial design just to get your main ideas out, that would be fine.

Otherwise, totally ok if you can’t make it by then, though. :+1: It’s a bit short notice, and if not a lot of us can make the due date then we could definitely push it forward.

I know you wanted to see what other people had in mind, too.

3 Likes

It might be great for advanced coders!

1 Like

I think you can use hopscotch on a mac with an m1 chip…

1 Like

You can’t run Hopscotch on a Windows machine.* (That is, without a well-tuned VM and/or the right hardware, and even then it’d be a breach of Apple’s terms of service)

Hopscotch is generally not very accessible on non-iOS platforms, and a programming language would open lots of opportunities with cross-platforming.

3 Likes

I have public personal info on my GitHub account?
Ooh I did not know. I’ll go ahead an unpublic that momentarily when I have the chance.

does it make a difference if you are older than 18?

Oh this actually might be very difficult for me personally if I have to use an alt account.

I’ll try and build the whack-a-mole game with my Swift concept. That sounds like a lot of fun!

4 Likes

I wish it did. Unfortunately, this is a forum rule because there are a lot of kids on this forum, and if one person breaks the rules, then eventually it’s something that kids see and copy.

Yeah, I wish it was more convenient to have alts. I still have to figure out how to add an SSH key for my HS account.

That does sound fun! If you think it’s a good proof of concept, you can go ahead and do that.

5 Likes

Ah! I just realized Swift does not have anything like turtle graphics. Ohno this bodes unwell for me

(BezierPath time…)

3 Likes

First of all, thank you for your wisdom! I’m sorry for not getting back to you right way, with the sudden avalanche of long posts and ideas made before yours.

This will have to be a long-term project in order to even exist, and so I’m hoping we can get started and going with iteration right away. Keeping a grip on the mental model of the language is very important with how the syntax is handled. I want it to be easy for existing block coders to transfer over to Hopscript for the benefit of their projects by replicating Hopscript’s syntax to the block based syntax in HS as closely as possible.

As you said, this language is for Hopscotch coders, based around Hopscotch. So this can be our main focus, to build a language that is easy to use after using Hopscotch. But it’s interesting that you bring this up, because really, shouldn’t it be easy for even a non-Hopscotcher? If both languages have the same philosophy to create ease of use, that is…

I’ll have to think about who we’re marketing to, or who we would habe to market to, other than just the Hopscotch community, if we want this language to be just as usable from even a new audience.

In regards to the MVP (minimum viable product), all of the core movement-related, trail-related, color, variable and control/loop blocks will probably be part of the MVP - if not, less blocks than this. Coding the compiler will prove to be a challenge once we finish iterating on the syntax and actually get to building it. (Hopefully, Awesome_E and Petrichor can help with their extensive knowledge of the internal JSON format.)

Lastly - yes, it looks like I meant to say “textual” in the title rather than “typed”. And hopefully we can add custom features and extend the language in the future.

Thank you for your kind wishes!

4 Likes

Ah, and if you see any way to help, feel free to lend us a hand if you’d like to. Your previous experience with making compilers would make your help very valuable.

Would it bother you if we tagged you in case we need some additional guidance?

3 Likes

(You’re very gracious; I realized after I posted it that my “tips” are easily perceived as violating the assume-that-others-are-as-smart-as-you rule)

I want Hopscript to succeed but with the school year starting I’m going to have less time for all things HS, so I can’t commit to anything. Feel free to tag me, but please don’t think that non-responsiveness means disinterest or discouragement; I’ll still be rooting for you from my quiet corner.

I forgot another piece of advice - try to avoid re-inventing wheels, aka shamelessly copy/steal whenever possible. “Innovative” is not a virtue. For Hopscript, I might consider copying “tosh”, which is what someone else already made as a text-based Scratch:

I learned about tosh by web searching for: text based scratch
It looks like tosh is not actively maintained (and Scratch itself seems to reject a text-based alternative), but so what - tosh is still a concrete working example of how to build a text-based language around a block-based language, so it contains copy-able wisdom about how to do that. I’m curious how it answers questions like:

  • Is the surface language basically reading off the graphical language, or is it trying mimic the syntax of other text languages (very much the former, it seems, which is a fine way to conform to principle of least surprise)
  • how is order-of-evaluation in arithmetic expressions defined (graphical languages intrinsically have zero ambiguity here, while the possible ambiguity of text representations seems to be an enduring topic of interest on nerdy math)
  • is the user experience of it primarily via a web app (even if self-hosted), or file interacting on the command-line shell?
  • if it is controllable from the shell, is everything self-contained in a single multi-part file, or is there a set of files that have to be gingerly moved/renamed in concert?
  • whatever variable scoping exists within scratch, is its textual representation easily comprehended?

I would scale the Hopscript MVP down, and just focus on the simplest Logo subset of HS (trails via move forward and turn, with repeat N time, but no arithmetic expressions or conditionals). Even with super-simple toy language, prototyping the infrastructure for compiling it, and generating informative error messages when things go wrong, will be humbling but informative (I just realized that one of the reasons I like to procrastinate from work by doing HS is that there are zero compiler warnings or errors. HS just goes).

Okay, back to my quiet corner…

5 Likes

Use a iOS emulator @Rawrbear

Great idea! I was literally thinking if the same thing! A hopscript language would be great but it would be nice if you could use other languages such as python. Like repl, you could have different files of different languages.

1 Like

I’ve had the same idea before, a text-based language that compiles into Hopscotch projects! Here’s some of my thoughts/things to consider:

  • Parsing the language: If we want to get this working, we will inevitably have to write some sort of parser for Hopscript. Over the past few days, I’ve actually been working on writing a parser in TypeScript for a language that I came up with, so I would be able to write some sort of parser for Hopscript in whatever language we decide to go with.
  • AST representation of the language: I think the parser should create an AST, or Abstract Syntax Tree, which is essentially a tree structure that represents the program’s contents. An AST would allow us to perform operations on the source code with relative ease, such as optimizations. It would also allow us to easily implement different abstraction mechanisms.
  • Compiling into an actual Hopscotch project: In the compilation process, once the AST is in a place where we are ready to convert everything into a Hopscotch project, we would probably want to create an intermediate representation of the project’s contents, a sort of virtual project if you will. Once that is done, we take that form and convert it into the actual JSON project. Essentially, the compilation process would look something like this:
    • Parse the original Hopscript code into an AST.
    • Perform abstractions on the AST (inlining functions, converting while loops into nested abilities, etc).
    • Optimize the AST, using techniques such as Constant Folding and removing unused code and abilities.
    • Convert the now-optimized AST into a “virtual project” of sorts, which will have the actual structure of a Hopscotch Project.
    • Convert the virtual project into an actual Hopscotch project file.
  • Importing the compiled projects into Hopscotch: How will we implement importing compiled Hopscript projects into the app? I know there is a folder in the Files app which contains all of your project files, but is there an easier way to do this than having the user copy the project file into that directory?
  • Abstractions and Hopscotch’s code execution: A lot of the time, Hopscotch will only execute 1 block per rule per frame. This can cause projects to be slow, and it is probably once of the most nuanced things about Hopscotch as a whole. How will Hopscript work in terms of this code execution model? How will abstractions such as inlined functions and while loops interact with this? Will we have to implement these in a very specific way in order to make it as functional and intuitive as possible?
  • Handling custom images in Hopscript projects: How will images be handled in Hopscript projects? Since images for projects are stored separately from the project itself, will those have to be imported separately?
  • Use of subscriber-only features in Hopscript projects: How will Hopscript integrate with subscriber-only features, such as beta blocks and custom images? Will we just support those out of the box, even for non-subscribers? Does Hopscotch even allow non-subscribers to upload projects with subscriber-only features?
  • Hopscript web editor: I believe it would be best for there to be a web editor for Hopscript, with some sort of live previewing system via the web player. This would make Hopscript much easier to use. For the web editor, I was thinking we could use the Monaco code editor (which is used in VSCode). Because of the fact that the web uses JavaScript, I think it would be best to implement Hopscript in either JavaScript or TypeScript.
  • IDE extensions/tooling for Hopscript: I think users should also be able to use Hopscript in an IDE, without being forced to use the web editor to take full advantage of live previewing and other features. I think an ideal IDE to create an extension for would be VSCode, since it also uses Monaco. This would enable us to write tooling for both the web editor and the Hopscript VSCode extension at once, since they would both use extremely similar technologies. Additionally, we would probably need to add syntax highlighting and other language features for VSCode. We would also need to add a way to preview the project from the IDE, either with some sort of localhost server that VSCode automatically opens, or maybe an Electron app that displays the project as an entirely separate application.
15 Likes

First of all, hey, long time no see! Welcome back. I’m glad you’ve considered some of these points yourself, too.

Would you like to help with any of the programming and design, by chance? I could add you to the organization we made. If not, that’s totally okay.

I’ve assigned to make a syntax overview project here - Hopscript: Hopscotch Text Language (Concept) - #67 by Rawrbear

Your AST knowledge would be a missing puzzle piece of our team, and so your help would be really valuable to us for that!


I’ll be short with the technical aspects of this post, haha: much of your expertise shown in this post is low level. Right now, I’ve told our current team to focus on displaying their perspectives on the syntax and how it should work with purely a simple-to-use philosophy. It’d be great if you could offer some tips on how to make the Hopscript compiler scalable (ie. providing insight on how to add new Hopscotch features, or implementing custom language features with blocks). We have people that can work with the JSON structure right now, but being able to convert between Hopscript to AST and JSON is important. and it’d be great if you helped us with that when the time comes!

In terms of custom images – at least on a usability perspective, it’d be great if we could just keep an assets/ folder or something like that, and the compiler could handle all of the images. We could reference images in the code with IDs, maybe. Definitely something to discuss.

Subscriber only features are touchy. They’re how Hopscotch makes their money, and I want that to be sustainable for THT! I don’t think we want to mess with it as a source of income that they have.

However: this is totally something that would be good to implement, because without advanced editor features, the language would be incomplete in terms of exposing every feature. I suppose we could exclude advanced-specific stuff, or maybe we could include some sort of EULA for the language and say that you can’t use advanced features without paying for a subscription first.

You can’t actually open or publish projects with subscription-only features, but that might not stop people from running the code through drafts and then just buying a month to publish, or something. So we need to ask Yuanyuan for permission to implement those. I suggest we ask once we get further into the design process, and then we can ask for permission to implement later on.

A web editor would be great! I’ve used Monaco a little bit before, and I know the API is a little bit undocumented if I recall correctly. But we could definitely take a shot at it when the time comes. VS Code support alongside that would be great too. And I totally agree, VS Code would be a great IDE environment - we could figure out how to make a live server for HS projects, as well as to implement syntax highlighting, and maybe eventually linting. Literally all we’d need for a live server is just to open up a localhost:port page in a pop-up browser.

8 Likes

Thanks for your post! And no worries; your post should be very useful to us.

Tosh is a language with a seemingly very minimal philosophy, from the surface level: just to be “text based”, and to “be quicker to make projects”. The syntax seems to be designed with ease of use in mind and easy-to-write code, without having to drag and drop blocks.

This is what it says on the front page:

Tosh is a text-based editor for Scratch projects.

Use it to get started with text-based coding,
or just to make Scratch projects faster.

Not to come across as rude - I respect the developer(s) for making Tosh - but I personally don’t think this front page philosophy of Tosh is specific enough for it to be heavily adopted. It has some great features, though, such as ease of use.

A philosophy is really important because it lets you take one core aspect of your programming language into one elevator-pitch-length intro, such as, “Hopscript is a text-based language for Hopscotch that’s easy to learn and use for anyone.” Then you can base every single part of what you’re designing around a philosophy like this, making it really easy to design and have a basis for what you’re making.

But your post has made me re-think some things about the process… like, maybe we should get some external feedback about the language before even designing anything, then take it and put together a core philosophy for why this language to exist.

As Steve Jobs has said all the time in interviews, he just needs smart people that can come together and work with one vision in mind, and then everything else comes in place to make something great.

For instance, I could go into specifics of how the language could be designed. Every feature, every caveat, every step of the build process. But that would be one very long post, and it might not even fit into a 30k character reply. (I wrote a post before this which I deleted, because it was long and too specific. It did cover each of your points specifically, but it wasn’t well tied together with what I wanted to say about how I view a design process.)

Rather, by having one or two core beliefs, all of those things can then be discussed around those beliefs. And the core philosophy is formed from user feedback and everyone’s beliefs for a language they would use. It’s kind of like a rulebook.

I’ll have to think about this some more. Thank you for your help and guidance!

4 Likes

Hey @JonnyGamer, do you have an alt account that you could use for the organization, by chance? It’d be great to make your proof of concept repo public again haha.

Please take ownership of your repo again - I’ve made it private within the organization because of PI reasons. Since you’re an admin, you should be able to see it.

I’d like to post the link to the organization again, but right now I know I shouldn’t because of exposed PI, and I don’t want to break any rules.

Sorry about that… I just wanted to get everything set up tomorrow. But as soon as this is cleared up, I think this should be a lot of fun to make.

If you’d like to keep your info there, maybe you could let a leader know or something as an exception, but this is blocking my ability to involve you in any organization activity right now, unfortunately.

2 Likes

Yeah I’ll transfer ownership back to JonnyGamer no worries!

2 Likes

Great! Let me know if anything changes so I can add you back. Thanks!

Nothing personal (pun partially intended), just rules unfortunately

1 Like

Lol


Ok I just did it
(it says it may take a few minutes)

1 Like