General Development Archive

I'm a programmer. I write games. Games programmers get a lot of respect, but none of them, not me, not Carmak, and not Abrash. None of them deserve the honour which I want to bestow on David Horne. This is because David Horne wrote the greatest program ever written: 1k chess on the ZX81.

David Horne is not an urban myth. David Horne achieved what many would even now consider impossible. He wrote a chess game, with AI, that ran on a poorly documented, buggy machine that contained only 1k of memory.

Hollywood is a multimedia-oriented programming language that can be used to create graphical applications very easily. It was designed with the paradigm to make software creation as easy as possible in mind. Thus, Hollywood is suited for beginners and advanced users alike. Hollywood comes with an extensive function library (encompassing almost 700 different commands) that simplifies the creation of 2D games, presentations, and applications, to a great extent. It has been in development since 2002 and hence is today a very mature and stable software package.

We've spoken in the past about teaching Clang to fully support Windows and be compatible with MSVC. Until now, a big missing piece in this story has been debugging the clang-generated executables. Over the past 6 months, we've started working on making LLDB work well on Windows and support debugging both regular Windows programs and those produced by Clang.

Ori is a distributed file system built for offline operation and empowers the user with control over synchronization operations and conflict resolution. We provide history through light weight snapshots and allow users to verify the history has not been tampered with. Through the use of replication instances can be resilient and recover damaged data from other nodes.

Today we announce Go 1.4, the fifth major stable release of Go, arriving six months after our previous major release Go 1.3. It contains a small language change, support for more operating systems and processor architectures, and improvements to the tool chain and libraries. As always, Go 1.4 keeps the promise of compatibility, and almost everything will continue to compile and run without change when moved to 1.4.

Five years ago we launched the Go project. It seems like only yesterday that we were preparing the initial public release: our website was a lovely shade of yellow, we were calling Go a "systems language", and you had to terminate statements with a semicolon and write Makefiles to build your code. We had no idea how Go would be received. Would people share our vision and goals? Would people find Go useful?

Earlier this week, coder and game designer Jonathan Blow gave a presentation on his Twitch channel outlining his thoughts on why and how programmers might go about building a new programming language specifically for game development.

"We are literally killing ourselves every project, deathmarching to get games done," said Blow, during a Q&A segment. "It just really doesn't have to be anywhere near that bad -- at least for programmers."

I always find it more effective to learn new programming concepts by building projects using them, so I decided to do the same for Apple's new Swift language. I also wanted to see how well it would interact with my open source GPUImage framework. As a result, I made GPUImage fully Swift-compatible and I've built and committed to the GitHub repository a couple of Swift sample applications. I wanted to write down some of the things that I learned when building these.

The μg Project aims to provide a free, fully compatible replacement of the often used proprietary GAPPS package by Google.

I gave a talk in 2007 that explained 8088 Corruption in detail, and in that talk I explained that displaying FMV using CGA in graphics mode would be impossible. This is because CGA graphics mode uses 8x the amount of video memory that 8088 Corruption was handling. Even a simple calculation assuming 24fps video reveals that the amount of data needing to be updated per second (24fps * 16KB = 384KB/s) is outside of the IBM PC's capability: CGA RAM can only be changed at a rate of 240KB/s, and most hard drives of the era operate at roughly 90KB/s. It sure felt impossible, so that's why I said it.

Then I thought about the problem for 7 years.

I was at the OpenStack Summit this week. The overwhelming majority of OpenStack deployments are Linux-based, yet the most popular laptop vendor (by a long way) at the conference was Apple. People are writing code with the intention of deploying it on Linux, but they're doing so under an entirely different OS.

But what's really interesting is the tools they're using to do so. When I looked over people's shoulders, I saw terminals and a web browser. They're not using Macs because their development tools require them, they're using Macs because of what else they get - an aesthetically pleasing OS, iTunes and what's easily the best trackpad hardware/driver combination on the market. These are people who work on the same laptop that they use at home. They'll use it when they're commuting, either for playing videos or for getting a head start so they can leave early. They use an Apple because they don't want to use different hardware for work and pleasure.

A large research project in the physical sciences usually involves experimenters, theorists, and people carrying out calculations with computers. There are computers and terminals everywhere. Some of the people hunched over these screens are writing papers, some are analyzing data, and some are working on simulations. These simulations are also quite often on the cutting edge, pushing the world’s fastest supercomputers, with their thousands of networked processors, to the limit. But almost universally, the language in which these simulation codes are written is Fortran, a relic from the 1950s.

Every programmer occasionally, when nobody's home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It's a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.

This file is Good Code.