I’ve been using some open source software called THREE.js, and I like it a lot. It’s a software library that provides a common way for programmers to specify three dimensional objects and scenes in a web page.
Some coders don’t like to use such libraries. They say “Why should I use somebody else’s stupid library, when I can write all that stuff myself?” But the real advantage is that an entire community of programmers ends up following the same conventions.
It doesn’t even matter much what those conventions are. The important thing is your code and my code will work together, because we’ve both agreed to use something like the THREE.js software library.
Which is all great, until those conventions change. Now, officially, software libraries are not supposed to alter the names of things without a lot of warning. It’s kind of like trying to move a railroad track while the trains are running. Bad things are likely to happen.
Alas, THREE.js has done this to us several times. For example, some months ago somebody decided that the shape called “Cube” should instead be called “Box”, so they just renamed it. Which is great, except that if you had any cubes in your little webpage scene, your page just broke.
On the whole, I’m happy with the open source approach. It builds community, everyone shares their work freely, and the energy is more about creativity and openness than about somebody else getting rich. And it’s not like renaming a “Cube” as a “Box” is the end of the world.
At least not yet. One day, several decades from now, when everybody is seeing everything through those little cyber-contact lenses or retinal implants, some hotshot programmer is going to come up with a better word for “Box”.
And all around the globe, in a single instant, all of the buildings in the world will disappear from sight.
Nice post! It’s the dichotomy between getting something accomplished (using existing libraries) versus “Standards” which are highly painful to create but when they exist are vital to keeping those digital buildings standing several decades from now.
You can’t imagine how humbling it is when someone like Ken Perlin uses the library you maintain 🙂
We do try hard to not break. The Cube to Box name suggestion actually came from Eric Haines (from realtimerendering.com fame) but the approach for avoiding breakage with that change was probably not the best. I actually wonder how it broke as it wasn’t supposed to break (unless you were doing instanceof THREE.CubeGeometry).
Anyway, now you have my email. Please, feel free to ping me directly whenever something breaks so we have more cases in mind when evolving the API.
Mr.doob: Gosh, I’m blushing now. 🙂 I was indeed invoking instanceof THREE.CubeGeometry. I am probably trying too much to use THREE.js (which is a fabulous library!) to do things that it might not have been intended to do, and that might be leading to problems. For example, after the latest update, I needed to remove all my calls to computeCentroids() (because that no longer exists, and is no longer needed), and also to change my references saying material.program to instead say material.program.program. I guess, reading your comment, that I was never supposed to be accessing those things in the first place. Yet they were visible, and I had needed them to get some things done.
I see… The reason instanceof stopped working was because I wanted to show a warning message when people used CubeGeometry. That was a bad decision.
I think you’re using the library correctly. However, in order to improve the library sometimes we need to change things and is hard to think about all the consequences of a change.
The solution for this is to report that something broke, so we can fix it or add a workaround in the next version.
Thanks, will do.
In case I haven’t mentioned it enough times yet, THREE.js is an awesome library!!!!
*blush* Glad you like it! *blush*
Interesting point, except =p
You are not thinking outside the box (or cube) when it comes to generational software changes.
By the time we are all using contacts with electronic pathways on them to spy the world with data overlays, I’d imagine that software repositories would also get an upgrade with adaptive intelligence to automagically propagate changes from a committed main branch throughout my project(s) as well.
Your point supposes that no such changes to repositories, or alternative ways of doing open source within a non-production controlled systems, would ever change from there here and now.
Still, fun to think about.
Cheers.
1. Version-specific includes
2. Immutable infrastructure
3. Unit tests
If you include specific versions of libraries, move version of library and code together (keeping the old alive until the new is bedded in via #2), and have good test coverage, then you should be able to test the new version of the library thoroughly before deploying.
Frankly, whatever warning you get about interface changes will not change the above statement.