thatmattbone.com

I had the chance to meet Richard Stallman on Friday.  He was speaking at the NA-CAP conference at which I volunteered.  All in all, very interesting, and last night I ended up joining the FSF. 

It seems I’ve been in a LaTeX-chatter-whirlwind this past week: someone emailed me about TeX today, I discovered jsmath, this article was on reddit a few days back, and my boss and I were chatting about TeX on Friday. Since I haven’t actually been writing anything lately, I have no need for TeX at the moment, so I’ll just rant.

MS-Word is useless. When writing in word, you’re forced to think about ‘look and feel,’ but when it’s all done, your document will still look like crap (see the aforementioned article for something of intellectual merit on this). Take some time, learn how to use LaTeX (or something as simple as LyX or TeXmacs), and thank yourself later. You’ll write better when you aren’t constantly fretting over the appearance of your document, and it’ll look better when typeset by the brainy TeX algorithms.

Also, if you must collaborate on a document, use a wiki or Google docs, and then paste your nearly complete product into your TeX editor. Emailing a word doc to your colleagues or posting to a website is not collaboration. No one is going to read it, and if they do, they aren’t going to comment. It is too painful.

It’s called bottom up programming, the foundation of which is small composeable methods.

Several months ago I assigned my data structures students a little recursive puzzle as part of a somewhat longterm assignment. The assignment is due soon, and I thought I’d take some time to write up a solution in Lisp for my own enjoyment.

Now, I’ve been putzing around with Lisp for some time, but this is really the largest thing I’ve written outside of the Practical Common Lisp examples. To be fair, at 56 lines it’s not ‘large’ by any stretch of the imagination. Still, it’s been fun, and I’ve noticed some things.

Programming in SLIME is a pure joy. I find myself writing very short functions and testing them at the REPL repeatedly; Lisp really does facilitate bottom-up programming. Originally I thought this approach was more of a convention, but it turns out to be an emergent property of the language and programming environment. Functions without side-effects are quite easy to test, and SLIME lets you recompile and test at will. Though I think the mutable-state-objects so prevalent in Python really keep us from leveraging the power of the Python REPL, it might be worthwhile to encourage a Lispy-bottom-up approach in Python, too. Maybe some additional tools and a bit more dedication to this style are needed (it’s not the same emergent property as seen in Lisp itself), but the benefits would be worth it. Syntax and macros aside, the ability to tinker with the code I’m writing while I’m writing it is a huge win. Lisp makes this much simpler.

I’m going to think about this some more…I believe the ease of the REPL has pedagogical implications, too (I mean, where’s the Java REPL?).

Presentation software is linear; presentations are non-linear. Most of my ‘presentations’ are in the academic setting where I either lecture or give an overview of a project I’m working on. In either case, it is useful to evaluate the attention and interest of the audience and alter the presentation on the fly. This may be as simple as spending more time on one particular idea, but it may also require referring back to previous diagrams that capture the spirit of the presentation in a high level view. Traditional presentation software does away with this give and take, and instead forces an ordering of slides (ideas) on presenters and ‘presentees’. Sure we can go back to previous slides, but this is tedious as the software does not take this into consideration.

I think one solution comes from wiki software. Imagine a presentation as a set of wiki pages (small, maybe 10-12 pages). The pages would not only contain normal slide material (maybe we shouldn’t use bullet points, but that’s for another day), but also links to other slides. The perfect presentation software would parse these wiki pages, presenting each as a slide in a graphical cluster ala Exposé. Links would be represented as simple lines drawn between the slides, and some nice graph theory would place the important slides (those with more in/out links) closer to the center of the screen. Selecting a slide from this global view would bring it into the traditional full screen mode, and as the wiki and therefore the slides are completely flat, there would be no meaning to ‘next’. Instead, presenters would navigate by selecting a link on the slide or returning to the global view with a key stroke and selecting a slide from there. The global view would remind us of what we’ve seen and let the presenter return to previous ideas as needed.

I should mention that there are many others with thoughts on PowerPoint. After Chris Grubbs Michael Greene mentioned the work of Edward Tufte, I spent more time thinking about this issue. Tufte’s article, ‘PowerPoint Is Evil’ serves as a nice starting point, and I think that we could gain a lot by spending more time considering how to display information.

It often seems that whatever we see in Apple’s products today, we’ll see in PCs tomorrow. So with the introduction of the 8 core Mac pro, we’re already getting into some serious multi-core territory. And while it’s been harped on frequently, everyone is right; with many more cores we’ll need much more concurrency.

More and more, I’m coming to the conclusion that shared state multi-threading, at the very least, is an improper abstraction, and at the worst, is barely an abstraction at all. An interesting piece over at Raganwald today talks about dealing with mutable collections in these environments, drawing inspiration from functional languages such as Haskell. The posting talks about using a ingenious copy-on-write approach to speed up reads across multiple threads (I wonder, is this STM?). And while this technique is a leaps and bounds ahead of locking the entire data structure on each and every read and write, I wonder if we’re still not approaching this from the proper perspective.

Lately I’ve been interested in the Actors model as an alternative to this shared state business. Though I’ve much more to learn, it seems that the spirit of the actors model is interacting processes (lightweight threads really) that communicate via message passing. The actors react to incoming messages and change state, fire off new messages, etc. The important thing, however, is that shared-state is gone (shared-nothing). When done properly, the actor only explicitly calls code that is entirely within its scope (thread local, if you will) and uses messages to carry out all of its other work. Though this shared-nothing model is used in Erlang without objects, with some discipline it’s not necessary to throw out OOP.

While the terminology seems to have faded, in Smalltalk you don’t ‘invoke methods’ but rather ‘send messages’. We can use this idea when thinking about actors in a more familiar Java-esque object oriented setting. Consider an actor-object: an object with it’s own thread that responds to incoming messages. An actor-object can still hold references to local objects and ‘invoke methods’ on them, but these references should be totally encapsulated and never leaked to other actor-objects (a stronger form of composition for the UML inclined). That is, the actor-object though it likely could, shares nothing with other actor-objects in the system by way of object references. One actor-object wishing to collaborate with with another must use the ‘message sending’ concept. Notice that all concurrency issues are abstracted away. The actor-object has only one thread that is woken up when messages arrive, and this is the only thread that ever executes the actor’s code.

Much of this can be implemented today on the JVM using Scala, it’s actors library, and some discipline. However, we must ultimately decide whether or not this approach is any simpler (or more productive) than standard shared-state/locking approach. Eventually we may throw out the OOP model altogether (referential transparency and concurrency anyone?), but until then we should remember that OOP, while no cure-all-snake-oil, has a lot of warm brains and bodies behind it. We should, at the very least, strive to simplify concurrency in this nearly ubiquitous approach. We need out of the multi-core-concurrency-crisis.

As an aside, I’ve been dealing with these problems (and using Scala) in my work on CN. I hope to post more of my thoughts as I continue to tackle the concurrency beast.

The HOP project is simply amazing. It’s a programming language for building ‘web 2.0′ apps, and it just so happens be very lispy. Go, run the demo. I was shocked at what could be done with stupid ajax tricks. The demo feels like a flash app, but it isn’t.

Hooray for s-expressions!

As a graduate student who has done most of my programming in object oriented languages such as python and java, I sometimes fear that while I am well versed in the theory of good design, am I not missing something?

In particular, it seems that functional programming is an interesting and invaluable component of computer science that should be included in any degree program. However, my programs have not offered such a course. Fear not. Thar interweb comes to the rescue.

For those who have a secret Lisp fascination, Practical Common Lisp is available online, for free. Want a bit more theory? The infamous Structure and Interpretation of Computer Programs (SICP) from MIT is also available online; morever, videos of SICP lectures are available here and here.

So, maybe you go to a Java School, but this doesn’t mean you should limit yourself.