Note: Parts II and III are up now.

In the art world there is this idea of anti-art. The goal is to do all of the things backwards or wrong so that you can discover new rights. You have to tear down the world before you can build it again. I’m not entirely sure how it works, but they seem happy with it so I figured I’d give it a go with something that really needs shaking up: the desktop operating system.

Beforwarned. This post is an epic. Not epic in a"'that movie was awesome" sort of way. It's epic in a "3000 stanza poem you had to read in english class" way. Just FYI.

Today we’re going to play with a new toolkit called Thrust. Thrust is an embeddable web view based on Chromium, similar to Atom-Shell or Node-webkit, but with one big difference. The Chromium renderer runs in a separate process that your app communicates with over a simple JSON based RPC pipe. This one architectural decision makes Thrust far more flexible and reliable.

The follow up to last year’s Beautiful Lego, Mike Doyle brings us back for more of the best Lego models from around the world. This time the theme is Dark. As the book explains it: “destructive objects, like warships and mecha, and dangerous and creepy animals… dark fantasies of dragons and zombies and spooks” I like the concept of a theme as it helps focus the book. The theme of Dark was stretched a bit to include banks and cigarettes, and vocaloids (mechanical japanese pop-stars), but it’s still 300+ gorgeous pages of the world’s best Lego art. Beautiful Lego 2 is filled to the brim with Zerg like insect hordes, a lot of Krakens, and some of the cutest mechs you’ve ever seen.

My hatred of C and C++ is world renown, or at least it should be. It's not that I hate the languages themselves, but the ancient build chain. A hack of compilers and #defines that have to be modified for every platform. Oh, and segfaults and memory leaks. The usual. Unfortunately, if you want to write fast graphics code you're pretty much going to be stuck with C or C++, and that's where Amino comes in.

I recently added the ability to set individual pixels in Amino, my Node JS based OpenGL scene graph for the Raspberry Pi. To test it out I thought I'd write a simple Mandlebrot generator. The challenge with CPU intensive work is that Node only has one thread. If you block that thread your UI stops. Dead. To solve this we need a background processing solution.

A post about Arthur Whitney and kOS made the rounds a few days ago. It concerns a text editor Arthur made with four lines of K code, and a complete operating system he’s working on. These were all built in K, a vector oriented programming language derived from APL. This reminded me that I really need to look at APL after all of the language ranting I’ve done recently.

I am unhappy to announce the release of Electron 0.4 beta 3.

What's that? unhappy?! Well......

Last week I had to spend a lot of time in Windows working on a port of Electron. This means lots of Node scripts and Git on the command line. The built in Windows command line is so abysmal that I had to write something myself. And so Photon was born.

Photon is about 250 lines of Javascript that give a command line with ls, cp, mv, rm, rmdir, mkdir, more, pwd, and the ability to call other programs like git. It has a very simple form of tab completion (rather buggy), and uses ANSI colors and tables for formatting. (For some reason there are approximately 4.8 billion ANSI color modules for Node).

The key concept I’ve explored in this series is that the code you see in an editor need not be identical to what is stored on disk, or the same as what is sent to the compiler. If we relax this constraint then a world of opportunity opens up. We’ve been writing glorified text files for 40 years. We can do better. Let’s explore.

Windows 10 seems nice and all, but it doesn’t do anything to make me care. Fortunately Microsoft can fix all of Windows problems if only they follow my simple multistep plan. You’re welcome.

Lately I've been digging into Rust, a new programming language sponsored by Mozilla. They recently rewrote their docs and announced a roadmap to 1.0 by the end of the year, so now is a good time to take a look at it. I went through the new Language Guide last night then wrote a small ray tracer to test it out.

After the more abstract talk I’d like to come back to something concrete. Regular Expressions, or regex, are powerful but often inscrutable. Today let’s see how we could make them easier to use through typography and visualization without diminishing that power.

I’ve talked a lot about ways to improve the syntax and process of writing code. In Typographic Programming Language, Fonts, and Tabs Vs Spaces I've talked about the details of how to improve programming. However, I haven't really talked about my larger vision. Where am I actually going with this?

My real goal is to build the Ultimate IDE and Programming Language for solving problems cleanly and simply. Ambitious much?

Actually, my real goal is to create the computer from Star Trek (the one with Majel Barrett's voice).

Actually, my real goal is to create a cybernetically enhanced programmer.

Okay. Let’s back up a bit.

Put on your asbestos suits, folks. It’s gonna get hot in this kitchen.

No Starch Press is really doubling down on their Lego books. Their latest is a stunner. The Art of Lego Design by Jordan Schwartz is less of an art book and more of a hands on guide. It shows actual techniques used by the Lego artists featured in other No Starch books like Mike Doyle’s Beautiful Lego.

In today’s episode we’ll tour the font themselves. If we want to reinvent computing it’s not enough to grab a typewriter font and call it a day. We have to plan this carefully, and that starts with a good selection of typefaces.

Allow me to present a simple thought experiment. Suppose we didn’t need to store our code as ASCII text on disk. Could we change the way we write -- and more importantly read -- symbolic code? Let’s assume we have a magic code editor which can read, edit, and write anything we can imagine. Furthermore, assume we have a magic compiler which can work with the same. What would the ideal code look like?

This is part 3 of a series on Amino, a JavaScript graphics library for OpenGL on the Raspberry PI. You can also read part 1 and part 2.

For today’s demo we will build a nice rotating display of news headlines that could run in the lobby of an office using a flatscreen TV on the wall. It will look like this:

This week we will build a digital photo frame. A Raspberry PI is perfect for this task because it plugs directly into the back of a flat screen TV through HDMI. Just give it power and network and you are ready to go.

I’ve been working on Amino, my graphics library, for several years now. I’ve ported it from pures Java, to JavaScript, to a complex custom-language generator system (I was really into code-gen two years ago), and back to JS. It has accreted features and bloat. And yet, through all that time, even with blog posts and the goamino.org website, I don’t think anyone but me has ever used it. I had accepted this fact and continued tweaking it to meet my personal needs; satisfied that I was creating something that lets me build other useful things. Until earlier this year.