Tag Archives: webgl

This is why C is a useful language

My colleague Wilson Page tweeted a couple days ago which was the most useful language we knew after JavaScript:

Since I like to add interesting information to conversations, I looked at the answers first, to make sure no one had mentioned the answer I had in mind. And surprisingly enough, no one had indeed mentioned my suggestion: C!

Wilson also asked for the reasons why I would suggest C as a useful language. I tweeted some:

but Twitter’s interface is horrible, and I feel they deserve a whole entire post, sooooo…

This is why C is a useful language

All the operating systems we interact with on a daily basis are built with C at some point. If not directly built with C, they are built using C inspired/derived languages, such as C++ or Objective C.

There are newer languages such as Java, C#, Rust or Swift that try to build on the experience of C programming, and try to solve the most common errors–often memory allocation and string handling. If you understand how C works, you understand the motivation for these new languages. You also understand better security issues–when someone talks about buffer overflows and about dumps, it doesn’t just sound like obscure jargon to you. Things make sense.

As web developers we are usually happy in our top level abstraction layer: the browser or node.js, or maybe even Electron. But if you try to dig a little bit deeper you’ll soon stumble upon binary stuff. Which is more often than not C (in node.js’s case) or, again, a C-derived language. Understanding how to interface with these parts is great! And often, modules that bind a library or API to JS are not entirely documented. Being able to look at code and understanding it is a great advantage. Not only does it empower you as a user, it could even help you modify the bindings and make them do whatever you need, by using your knowledge of the two worlds: JS and binary. This is the same case with Ruby, Python, … you name it.

You can do really powerful and superoptimised things in C; a frequent example is processing lots of data with little overhead. Normally, in our abstracted world we delegate tasks such as dealing with the stack or allocating and deallocating memory to the script interpreter of choice. In C you have to be aware of this, which can be a huge hassle, but if you understand those aspects you can manipulate them to your advantage. Allocate the right amounts of stack memory and inline a bunch of calls and you can churn away lots of data without having to incurring on that overhead I mentioned above.

Much of that kind of data crunching code is very simple conceptually–just a bunch of integer arithmetic operations. Which is also why it’s relatively easy to also transpile to highly optimised JavaScript via things such as Emscripten and Asm.js. See? JS and C–it all ties together neatly.

Another example of why knowing C will open doors for you is WebGL shaders. They are not written in C, but their syntax and semantics are very similar. They are relatively small programs that are designed to be run in parallel in many GPU cores at the same time. They are also uncannily similar to data crunching algorithms as in being essentially a lot of arithmetic operations. But you need to understand the limitations: using the proper data and operator types, no dependencies with the results from other calculations, no loops, costs of accessing memory for texture reads/writes, etc. You have to be quite close to the ‘metal’, but in exchange you get incredible performance.

Likewise, if you want to get into hardware programming, you’ll probably go through an Arduino first, but once you outgrow their IDE you might want to remove that layer and go to the next one: it will be written in C, and you might be able to save on a few Kbs of memory by removing abstractions here and there. Software for embedded systems is often written in C or C-derivatives which gets then compiled into some kind of binary or “transpiled” and written to programmable hardware.

And if you remove C you find Assembler. C is the closest to Assembler code without being Assembler. As I said, it exposes much of the metal, so much that you can often find bits of Assembler embedded inside C code. You would think that this is for when you get really specialised, but not really. The Linux kernel has many parts written in C + assembler. Many written in assembler only, as e.g. the boot sequence. There are even operating systems entirely written in Assembler, such as MenuetOS.

Learning Assembler might probably be totally useless on a day to day practical basis, but it will enlighten your understanding of general computing, and concepts such as registers, RAM, instruction sets, CPU cores and memory speed will not sound alien to you anymore, and again, you understand what limitations exist. When you stop thinking of a computer as a “black box that does things” and understand all the different subsystems and how they relate to each other, you start thinking about programming in a completely different, more nuanced way.

And at some point you will reach the epiphany moment, and realise that it is actually a miracle that anything works at all, with so many layers and moving parts written by so many different people. And understand why the Web is such a great space to be in, and why abstractions are good because otherwise we would all be trying to debug why our mallocs are failing and not getting anything done!

Happy programming in whatever language you like! \o/

How to organise a WebGL event

I got asked this:

Going to organize a series of open, and free, events covering WebGL / Web API […]

We ended up opting for an educational workshop format. Knowing you have experience with WebGL, I’d like to ask you if you woudl support us in setting up the materials […]

In the interest of helping more people that might be wanting to start a WebGL group in their town, I’m posting the answer I gave them:

I think you’re putting too much faith on me

I first learnt maths and then OpenGL and then WebGL. I can’t possibly give you a step by step tutorial that mimics my learning process.

If you have no prior experience with WebGL, I suggest you either look for a (somewhat) local speaker and try to get them to give an introductory talk. Probably people that attend the event will be interested in WebGL already or will get interested after the talk.

Then just get someone from the audience excited about WebGL and have them give the next talk

If you can’t find any speaker, then you’ll need to become one, and for that you’ll need to document yourself. I can’t write a curriculum for you, as it will take way more time than I currently have. WebGL implies many things, from understanding JavaScript to understanding 3D geometry and maths, to how to set the whole system up and running on a browser.

Or can start by learning to use a library such as three.js and once you become acquainted with its fundamentals, start digging into “pure WebGL” if you want, for example writing your own custom shaders.

Or another thing you could do is get together a bunch of people interested in WebGL and try to follow along the tutorials on WebGL or the examples on three.js. So people can discuss aloud what they understand and what they don’t, and help and learn from each other.

I hope this helps you find your way around this incredibly vast subject! Good luck and have fun!

Now you know how to do this. Go and organise events! EASY!

It’s actually not easy.

Audio for the masses

The video above is from LXJS – the Lisbon JavaScript conference, which happened more than a month ago. I gave this talk past week again at VanJS, so I decided it was time for that belated write up on this talk.

If you want to follow along, or play with the examples, the slides are online and you can also check out the code for the slides.

As I’ve given this talk several times I keep changing bits of the content each time depending on what the audience seems more interested in, plus I also sometimes improvise stuff which I don’t remember when writing the final write up, so if you were at any of the talks and see that something’s missing or different now you know why! I’ve also added a section at the end with frequent questions I’ve been asked, hope that’s useful for you too.

Continue reading Audio for the masses

Speaking at OneShotLondon NodeConf

“Just turn it into a node module,” and other mantras Edna taught me

The story of leaving behind a random mix of Python + php + bash + makefile + Scons scripts to totally embrace using Node, modules, standard callbacks, browserify, and friends to build toys that bleep and bloop with MIDI, WebGL and Web Audio.

As you can maybe deduct, this might not be your average super expert node.js talk, but a story of learning with a non-appointed mentor and an spontaneous community, and improving and making the most out of node.js—and how it informed and shaped the rest of my coding philosophy, both inside and outside of Mozilla.

I must confess that I’m really humbled and flattered to be amongst this amazing line up of true node experts.

UUUUUUUHHH THE EXPECTATIONS!—feeling a bit like an impostor now.

Next next Saturday 19th of July. See you there? 🙂

Invest in the future: build for the web!

I spoke at GOTO Amsterdam a few weeks ago. I was really thrilled to be back in the Netherlands after so many years! So thanks to Sergi Mansilla, who curated the HTML5 track, and the organisation in general for bringing me there!

The talk wasn’t recorded, but I made a screencast just in case you really want to listen to me. I am also posting the outline/notes I wrote, and they differ in places because I don’t read them during the talk (I don’t even have them handy) and I sometimes went a bit off topic, but that’s the beauty of improvisation!

Here are the slides, and the slides source code just in case you wanted it too.

On to the notes-expect some MASSIVE GIFs and amazingly clever photomanipulation! tee hee hee!
Continue reading Invest in the future: build for the web!