A long time ago I was given the chance to chose which library I would use in my projects in a 3D graphics class. I could use either PEX, the PHIGS extensions for the ubiquitous X Window system, or OpenGL, some upstart library from who knows where. I said this was a long time ago. I chose PEX due to its connection to the X Windows powerhouse. We know how that rivalry turned out.
A few proposals for handling concurrency and parallelism have made it into the standardization discussion. Two in particular have caught my attention. One calls for the inclusion of OpenMP extensions into the language. Another proposes parallel versions of the functions in which are targetable to a specific type of parallel architecture. These two appear to have the most weight behind them with none other than Oracle and IBM championing OpenMP and Microsoft and NVidia standing behind the parallel algorithms.
Are those of us who know concurrency is the future–-and aren’t convinced an investment in the future of C++ will make us the new century’s COBOL programmers before then–-presented with a similar pickle now? Could both make it into the standard, or should we pick our winner and invest in the preparation needed to take advantage? Would you even trust me if I told you which I thought would win judging from my past PEX decision?
- An Introduction to Lock-Free Programming: “the lock in lock-free does not refer directly to mutexes, but rather to the possibility of “locking up” the entire application in some way, whether it’s deadlock, livelock — or even due to hypothetical thread scheduling decisions made by your worst enemy. That last point sounds funny, but it’s key. Shared mutexes are ruled out trivially, because as soon as one thread obtains the mutex, your worst enemy could simply never schedule that thread again.” As they keep adding more and more cores to processors, being able to handle concurrency becomes even more important, but the more I think about it, the less I think that we know how to deal with the problem. I suspect that Erlang’s approach using message passing of blocks of immutable data is the long-term answer, but I see the syntax of that language being too big a hurdle for most folks to leap over.
- Design Patterns: When Breaking the Rules is Okay: “We know what buttons should look like, how they should behave and how to design the Web forms that rely on those buttons. And yet, broken forms, buttons that look nothing like buttons, confusing navigation elements and more are rampant on the Web. It’s a boulevard of broken patterns out there.” I think that we’re on the cusp of a new Cambrian Explosion of new UI/HCI approaches, and I hope that we all can keep a solid grounding in the fundamentals as we invent this next new wave of computing.
- bpython: A replacement REPL for Python, adding things like syntax highlighting, autocomplete, rewind/undo. Similar to iPython, but less heavyweight.
- music-21: a Toolkit for Computer-Aided Musicology: Very interesting Python library out of MIT for dealing with music at the symbolic level. I especially like the example below — one of the first bits of code that I ever wrote was a piece of BASIC to calculate 12-tone matrixes to save myself time in undergrad music theory. (Yes, of course I spent more time writing the code than I would have spent doing things by hand…)
For example, we can create an instance of the row from Alban Berg’s Violin Concerto, use the show() method to display its contents as text, and then create and print a TwelveToneMatrix object.
>>> from music21 import serial
>>> aRow = serial.RowBergViolinConcerto()
>>> aMatrix = aRow.matrix()
0 3 7 B 2 5 9 1 4 6 8 A
9 0 4 8 B 2 6 A 1 3 5 7
5 8 0 4 7 A 2 6 9 B 1 3
1 4 8 0 3 6 A 2 5 7 9 B
A 1 5 9 0 3 7 B 2 4 6 8
7 A 2 6 9 0 4 8 B 1 3 5
3 6 A 2 5 8 0 4 7 9 B 1
B 2 6 A 1 4 8 0 3 5 7 9
8 B 3 7 A 1 5 9 0 2 4 6
6 9 1 5 8 B 3 7 A 0 2 4
4 7 B 3 6 9 1 5 8 A 0 2
2 5 9 1 4 7 B 3 6 8 A 0