Josh On Design

In many of my projects I need to parse something, usually a text based language. Sometimes it's inline docs. Sometimes it's a custom DSL for generating code. And sometimes it's markdown files. My goto tool for this type of work is OhmJS, an open source parser language for JavaScript based on PEGs.

After a few weeks long sprint I’ve got another build ready for Ideal OS. Visually it’s starting to come together nicely. Check it out.

It's been a whole lot of work to get to Mark 4 of Ideal OS. My real goal for this sprint was to have something that at least visually looks like a real operating system. What do you think?

As I mentioned before I’ve gone back to working on the bottom half of Ideal OS. So far I’ve got a messaging protocol, a central server, a few tiny apps, and three different display server implementations. The version I’m calling Mark 3 looks like this:

I've paused my work on Filament for a while to go back and do some more research into low level graphics for IdealOS. As part of that I wanted to emulate a Raspberry Pi on my Mac. The short version is: yes it can be done but it's useless for graphics.

I'm happy to announce Filament 0.4. If the previous release was about new language features, this one is about apis and docs. A language isn't useful if you don't have APIs to do stuff with.

Fundamental Language Changes

I’ve been working a lot on new graphics apis, and new examples to exercise those apis. Things like turtle graphics, which are great for learning recursive functions, and image pixel processing, which are super fun and closer to Raytracing and GPU shaders than you might realize. However, along the way, I’ve discovered some missing features that have forced me to make some tough decisions. Today let’s talk about conditionals, jumps, and lambdas.

I'm happy to show you the next release of Filament, my humanist programming language designed for kids and scientists.

Filament is the humanist programming langauge I've been working on. Filament's focus is entirely on computational thinking and improving the way we use PLs, not on the implementation or performance. It is for thinking about problems, not producing software artifacts. It should be easy enough for children to use, but powerful enough for domain experts. Think of it as Mathematica for kids, scientists, and artists.

This is part of my series on the humanist programming language I’m building called (currently) HL. Read the rest here.

This is part of my series on the humanist programming language I’m building called (currently) HL. Read the rest here.

For years I’ve had this idea of a programming language (really a programming system) designed not for building software, but for exploring ideas. If built, it would be a system where you can easily access data both locally and remotely, process the data in many different ways, and use built in tools to visualize the answers. The current way we code just isn’t very amenable to exploring and thinking (outside of an Emacs Lisp buffer).

I’m happy to finally release a Javascript library I wrote at least four years ago. (I say ‘at least’ because the last commit was 4 years ago, but I don’t remember when or where I wrote the original code it came from). Presenting the parser from TallyCat!

If you havn't seen the news, 25% of Mozilla was laid off this week, including me, so I'm looking for a new job managing an engineering or developer relations team.

Every now and then I trumble around with building visual editors. Sometimes they are for vector graphics, sometimes raster. Sometimes for building GUIs, sometimes for editing JSON structures. These editors are almost always for fun and they never see the light of day. Why build a new editor when the world already has so many. Or at least that's what I tell myself.

At this point I’ve been working on the browser for over a month and I’ve learned a ton about Rust. Sadly, it’s time for me to stop. I’ve taken it about as far as I can.

Rendering. The big payoff. This is where we actually get to see something drawn to the screen. This is where the mini-browser starts to feel real. It’s also where the code is straight forward and the hard part is picking the library.

Now we get to the big dramatic part of building a browser. Layout. Until now we’ve just had a tree of data. This is the part where we position actual rectangles and colors and text blocks. The part where we do line wrapping and worry about font sizes. This is the real deal! Let’s dive in.

Styling in a browser is conceptually very simple. We’ve parsed the DOM into a tree structure of elements. We’ve parsed the CSS into a tree structure of rules.

I have greatly enjoyed the reliability of Rust so far, but a few things really annoy / mystify me. One is the type annotations. I understand that type annotations lets you say what type another type is defined in terms of. The common case is a vector of points, with something like: