Welcome to the State of the Waterbear. I want to talk about what has happened in the past year, what is coming soon (or not so soon) and solicit feedback. This year has seen work from two groups of UCOSP students, who have made some great contributions. These followed on a major rewrite to use custom elements for the blocks and change how the runtime worked, which caused some grief, especially for the first group of students.

The custom elements rewrite still has a few pieces on the cutting room floor, so I’ll get to those first.

• Custom Elements issues

Cut and paste is still missing. That is coming up as soon as I finish work on selecting items and moving the selection point.

• Cut and paste issues
• Selection issue

Undo and redo kind of work, but I want to make them work flawlessly. That is probably a month or so off yet.

• Undo/redo issues

Text preview is gone and probably not coming back in the form it was in (continuously updating). The problems with it were: a) took too much screen real estate, b) wasn’t actually usable (you couldn’t cut and paste the text and expect it to run), and c) it was distracting. The current runtime doesn’t even generate a text representation to execute, it iterates through the blocks and calls functions attached to them directly. All that said, I do want to bring back a text representation which is cut-and-paste runable (and makes a better serialization format), but it will be generated on request (via menu or button), not continuously in a panel of the IDE.

• Text code export issue

The idea of Waterbear as a wrapper language has gone through some transition, at least in my head, and I’d love to hear what others think. Trying to maintain multiple languages in the main branch just meant I wasn’t testing all of them very thoroughly, and since my attention is pretty much on the JavaScript side, the others tended to be in some state of brokenness. So I want to embrace the JavaScript runtime in the browser, and add an optional Node server (as Martyn did for Minecraft) which is a gateway to other languages and runtimes: Java robotics, Minecraft, Arduino, etc. But the blocks would still live in the JavaScript world and would talk to the Node server via websockets, so we could have 2-way communication between Arduino and JavaScript, among other things. That is where I see things headed, and again, I would love to get feedback on this.

• Node server issue

Of course, everyone is free to for Waterbear and wrap whatever you like, and I’ll document how to do this. It’s probably easier than before, but I’m not going to try to pull every language into into the main repo. I will be adding things like (long-awaited) typed arrays and other goodies to help support other languages though.

• Typed array issue

The work to wrap Processing I am pulling into the main repo, in a way. My goal is to support building anything you could build in Processing.js or its successor P5.js (except 3D, at least for now), but not necessarily by wrapping that library. Waterbear has its own ways to do some things (like loops), but I want to make sure it is at least as capable as those libraries so we can build rich applications with it.

• Processing support issue

There have been a couple of interesting features which were introduced in the previous UCOSP term and which I rolled out to the main site and then retracted. Both built-in tutorials and the debugging interface were awesome and well worth having, but their implementations ended up scattered throughout the internals of Waterbear and it was going to be a maintenance nightmare. Instead, I am rewriting the runtime slightly so that debugging can be mostly an add-on, without invasively changing the code, and (importantly!) not carrying a runtime cost when you’re not running the debugger. Likewise, I’m committed to making Waterbear very easy to embed and relatively lightweight, so that it can be embedded in tutorials wherever they are written (blog, wiki, web page, e-book) with an interface to configure them from the containing page (choose a subset of blocks to work with, load a script, run a script, etc.). So both of these features are coming back and will be better than ever, but aren’t ready just yet.

• Debugging issues
• Tutorial issues

Some progress has been made on getting Waterbear working on mobile. It’s really close on tablets, but still needs a lot of work on phones. The selection work in progress should make supporting phone-sized screens a lot better. The dream of being able to code while on the subway will soon be a reality!

• Mobile Issues

Some other areas that are on my agenda, but waiting for some of these other things to be done first:

• Support Multiple Documents
• Collaboration
• Saving and Versioning Scripts
• Refactoring and faster code entry

Lastly, one of this term’s students worked hard to modernize the IDE and make it both more usable and better looking. It isn’t quite finished, but I’ve put it up to get early feedback and guidance while we finish it up. We still have to re-implement resizing the panes and add a button for running scripts full-screen (and a bunch of work for mobile), but I’m very curious what others think of the direction it is taking.

• New IDE Preview
• New IDE Issues

The year has seen a lot of other work, adding and fixing blocks, consolidating and renaming blocks, adding tests, adding examples, blog posts, and of course, the addition of a blog to post in.

Please do get in touch with feedback on how things are going with Waterbear, either on the issues listed above, the mailing list, on twitter as @waterbearlang, or on Slack: https://waterbearlang.slack.com. To join the Slack discussion, email me dethe@livingcode.org so I can send you an invite.

–Dethe