Programming » James Gottlieb

CAR, CDR, CONS, Oh My!

Posted by james at 10:34 am OokOok No Responses » Tagged with: Distributed computing, Languages, Programming

Oct 052012

English: Stream (Photo credit: Wikipedia)

While I am trying to round out the content management aspects of OokOok this year, I’m starting to think ahead to next year’s work on databases and processing. Part of the goal is to offer a platform that lets you take advantage of parallel processing without requiring that you be aware that you’re doing so. Of course, any such platform will be less powerful than hand-coding parallel code in C or using your favorite Hadoop library. Less powerful is better than not available. I want OokOok to make available capabilities that would otherwise be hidden away.

Map/reduce seem like the simplest way to think about parallel processing. We have two kinds of operations: those that look at one item at a time (mappings), or those that have to see everything before they can finish their calculation (reductions). Reductions can get by seeing one item at a time if they can keep notes on a scratch pad. We could put operations then into two slightly different camps: those that need a scratch pad (reductions) and those that don’t (mappings).

Declarative Perl

Posted by james at 7:40 pm OokOok No Responses » Tagged with: Catalyst, Moose, Perl, Programming

Sep 152012

I’m making rapid progress in getting OokOok to a stable programming scheme. I haven’t made a lot of changes in its capabilities, though I did add the ability to archive themes and projects as Bagit files yesterday, I’ve been working on making the important stuff declarative. By hiding all the details behind a veneer of relationships, I can fiddle with how I manage those relationships without having to touch every relationship every time I make a change in the underlying schemas (and schemes).

For those used to an older style of Perl programming, this might come as a surprise. For those who have dealt with things like MooseX::Declare and CatalystX::Declare, you’ll be shaking your head at my foolhardiness in jumping into making an OokOok:Declare that hides the details of how to construct certain types of classes.

Behind the scenes, OokOok consists of controllers, models, views, REST collections/resources, SQL result objects, a template engine, and tag libraries for the templates. Almost two hundred classes in all.

If I built all of these the usual Perl way, there’d be a lot of boilerplate code around. By moving to a declarative approach, I can isolate all the boilerplate in a few core meta-classes. When the boilerplate has to change, I only have to touch one place. Everything else comes along for the ride.

For the rest of this post, I want to walk through how I use some of these declarative constructions. I won’t get into the scary details of how to make declarative constructions in Perl (at least, not in this post).

An Adventure!

Posted by james at 4:01 pm Digital Humanities, MITH No Responses » Tagged with: JavaScript, Programming

Mar 152012

In my last post, I talked some about the need to look across projects and find common elements that could be factored out. I’d like to start a series of posts in which I talk about some of the work I’m doing at MITH in developing some foundational libraries that we are using to build digital humanities projects. Along the way, I’ll discuss some of the philosophy behind those libraries and our approach to the projects.

Today, I want to walk through the design of an example application I’m working on that implements the classic Adventure game as a JavaScript web application. I’m not finished with it yet, but the framework is there. I’m just adding content and tweaking some behavior now, such as handling darkness. You can go into the hut, pick up the key, and then go down and open the grate to get into the cave.

Coding and Digital Humanities

Posted by james at 11:33 am Digital Humanities 5 Responses » Tagged with: Digital Humanities, Programming

Mar 082012

Miriam Posner’s post, “Some things to think about before you exhort everyone to code,” has touched off a series of conversations on twitter and elsewhere. My own feeling is that she’s nailing some things square on the head and, fortunately, doesn’t conclude saying that we should banish coding from the digital humanities. We just need to be careful how we cast the need for coding.

I’ve tossed around a nugget in my mind for the last few weeks, and Mariam’s post is making me focus more intently on it: A digital humanist afraid of the digital is like a scholar of French literature who is afraid of French. You can’t be a digital humanist if you don’t understand the digital. That doesn’t mean you have to be able to code any more than being a scholar of French literature means you have to be able to write French literature. You just have to be able to understand the nuances of what you’re studying and how you are studying it. Otherwise, how can you properly interpret the results?

Thinking Through Some Functional Ideas

Posted by james at 6:48 am Digital Humanities 1 Response » Tagged with: Histogram, Languages, Mathematica, Programming, Prolog

Mar 172011

I’m working through some ideas on how to move the Utukku/Fabulator expression language more into a descriptive, functional style. I want to be able to have the programming be exposed as an editorial statement showing how certain calculations are done or inferences are drawn. The computer’s interpretation of the data can be as important as a person’s, and knowing what the person was expecting the computer to do can be as important as knowing what the person thought they wanted the computer to do.

With that in mind, I want to walk through a few possible ways of constructing phrases and inference rules to see how they go. Since my stereotypical example seems to be a concordance, that’s where I hope to end up.