Category Archives: learning

Video Podcast: London Seminar in Digital Text and Scholarship

The School of Advanced Study at the University of London has just started a video (and audio) podcast series of the full talks from each session of the London Seminar in Digital Text in Scholarship.

Find the podcasts online here, or subscribe via iTunes (there is a link on the page to do so).

The first talk is Jan Rybicki with ‘The Translator’s Other Invisibility: Stylometry in Translation.’ Just another day I wish I lived in London, with all of the great digital humanities related seminars and talks going on. I read this scholar’s paper on the same subject in Literary & Linguistic Computing not too long ago and it was, in a word, awesome.

trusting the computer, and getting there with XSLT

If you are working in a functional, stateless language, but can still get away with for loops in a more conventional way thanks to for-each functions – should you still favor recursion over explicit for loops? Discuss.

Now that I am, as the title implies, “getting there,” I want to reflect a little on the learning process that has been XSLT. In my last post I glossed over what makes it (and functional programming languages generally) distinctive and, for people who are used to procedural languages, unintuitive and hard to grasp at first. This will be a post with several simple points, but that’s quite in keeping with the theme.

The major shift in thinking that needs to happen when working with XSLT, in my opinion, is one of trusting the computer more than we are accustomed to. It all stems from letting go of telling the computer how exactly to figure out when to execute sections of code, and letting it make the decisions for us.

I made a comment recently: “I know I’m getting more comfortable with XSLT because suddenly I’m trying to use recursion everywhere I can, and avoiding the for-loop like a crutch.” As others I talked to put it, this is idiomatic XSLT.*; In other words, it’s one of the mental leaps that you (and I) have to make in order to start writing elegant and functional code (no pun intended) using this language.

What is recursion? In this case, to oversimplify, it’s how XSLT loops.** In a procedural language – C++, Java, most languages other than Lisp dialects to be honest – recursion is clunky and wasteful; telling the computer to specifically “do this for the number of times I tell you, or until this thing reaches this state” is how you get things done. This means that the languages have state, too – you can change the value of variables. This is important for having counters that are the backbone of those loops. If there were no variable to increment or change in another way, the loop would either never execute (such as a while), only execute once, or loop endlessly. None of these things are very helpful.

So how do you get away with counter-based loop, at least of the “for each thing in this set” variety, with a stateless language (all variables are permanent, aka constants) that discourages use of for-each loops in the first place?

The first is much simpler: xsl:apply-templates or xsl:call-template. This involves the trust that I introduced above. With a procedural language it’s hard to trust the computer to take care of things without your telling it exactly how to do it (keep doing this thing until a condition is met) because you’ve had to become so used to it. It might have been hard to get used to having to explain the proverbial peanut butter sandwich recipe in excruciating detail for the sandwich to get made. Now, XSLT is forcing you to go back to the higher level of trust, where you can tell the computer “do this for all X” without telling it how it’s going to do that.

xsl:apply-templates simply means, “for all X, do Y.” (The Y is in the template.) It’s unsettling and worrying, at least for me at first, to just leave this up to the computer. There’s no guarantee that templates will ever be executed, or that they will be executed in order. How can I trust that this is going to turn out okay? Yet, with judicious application of xsl:apply-templates (like, where you want the results to be), it will happen.

Second, the recursive aspect. Keep calling the template until there are no more things left – whether that’s a counter, or a set of stuff. But how to get a counter without being able to change the variable? With each xsl:apply-templates (or call-template), do so with xsl:with-param, and adjust the parameter as needed. Call it with the rest of the set but not the thing that is being modified in the current template. When it runs out of stuff, that is when results are returned. Again, it takes the explicit instruction – xsl:for-each is very heavy-handed – and turns it into “if there’s anything left, keep on doing this.” It may seem from my description that there’s no real difference between these two, and in their end result, there isn’t. But this is a big leap, and moving from instinctively reaching for xsl:for-each to xsl:apply-templates is conceptually profound. It is getting XSLT.

Finally, a note on the brevity and simplicity of XSLT. I’ve noticed that once I’ve found a good, relatively elegant solution to what I’m trying to do (they can’t always be!), suddenly my code becomes very short and very simple. It’s not hard to write and I don’t type for a long time. It’s the thinking and planning that takes up the time. Obviously this is true for programming just about anything, but I find myself doing a whole lot less typing this summer than usual (compared to languages I’ve used such as C, C++, Java, Python).

It’s both satisfying and disappointing at the same time: getting a template that recursively creates arbitrary nested menus wants to make me jump up and high five myself; the fact that it’s only about four lines and incredibly simple makes me wonder if any of it was that hard to begin with. But this isn’t limited to XSLT or even programming: the 90-page thesis seems like more work than the 40-page thesis, but if the shorter one is talking about more profound ideas and/or is simply more well-written, the length and time comparison falls apart. The time spent typing and the length of the output doesn’t tell us as much as we’re used to assuming.

That’s what I have to say about what I’ve been doing this summer, as far as learning XSLT goes. I still can’t say I like it. The syntax is maddening. I haven’t been in this long enough to judge whether it’s the best choice for getting something done within a lot of constraints. But at the very least I’ve finally had that brain shift again, the one I had with Lisp so long ago, to a different approach to problem-solving entirely. And that feeling is profoundly gratifying.

Speaking of a good feeling, I’ve been able to have extended chats with multiple people about XSLT on the U of M School of Information mailing list this summer after someone posted asking for help with it. It’s a good thing I replied despite thinking “I’m not an expert, so I probably don’t have much to offer.” Talking with the questioner and the others who replied-all on our emails was really enlightening, both by getting feedback, hearing others’ questions about how the language works (questions that I hadn’t articulated very well), and also giving my own feedback. There’s nothing like teaching to help you learn. I would not have been able to write this post before talking to my fellow students and figuring it out together. (Or, you would have read a very unclear and aimless post.)

(Very last, I’d like to recommend the O’Reilly book XSLT Cookbook for using this language regularly after getting acquainted with it. If I were continuing on with an XSLT project after this internship, or working on adding more to this one, I’d be using this book for suggestions.)

* Thank you all for reminding me that this word exists.

** XSLT now includes not only the for-each loop, but also the xs:for tag. These do have their appropriate uses and I do use them quite a lot, because my application doesn’t give me a huge number of chances for recursion. I’m being dramatic to make a point.

Cross-posted from the iSchools & Digital Humanities intern blog

my poor laptop, cont’d.

I’m being dragged kicking and screaming into obsolescence, despite having perfectly good hardware and a brand new battery.

This time, it’s not being able to upgrade to Java 1.6 without installing Yellow Dog Linux, following instructions for putting IBM’s PowerPC release of 1.6 on it, and hoping for the best. Ordinarily, I would do just that, but I didn’t know I needed Java 6 for anything until, well, yesterday.

It’s downright embarrassing. I have to borrow a laptop from a kind workshop organizer on Saturday at DH2011 because one of the visualization tools we’re running is a Java app that needs, yes, 1.6.

I’m being pressured toward a newer laptop more and more, apropos of my recent two posts which were more my complaining about something that wouldn’t necessarily force me to upgrade to something less than 5 years old. How frustrating!

(And I never thought I’d regret not having brought my Linux netbook along with me this summer, thinking there’s no way I could need a desktop and two laptops, which is ridiculous – but there is probably a JDK 1.6 sitting on that Ubuntu install. But there are 12 hours between me and the netbook until August. Too bad!)

A random positive note to end this series of posts about my ridiculous computing situation. When I was doing research to find Java 6 for PowerPC, I came across a cottage industry of people helping others install it (and Linux) on their – get this – 64-bit PPC Playstation3! It warms the heart to know that there’s still a phenomenal console out there (and really, it is the best of the three) that uses PPC architecture. Hooray for Sony (and for IBM, which is using 64-bit PPC architecture in their workstations and releasing the JDK for the rest of us).

and thinking about object-oriented programming

I may be enamored with functional programming right now, but I do remember that the first languages I really learned were C and C++. That ++ is one big difference. I was fortunate enough to be learning them at exactly the same time, and so “object oriented programming” meant a lot more to me than a buzzword.

I’ll share another link tonight, and this one is more of a read, but it’s an opportunity to ask something you don’t every day: how does object oriented programming work, and how is it implemented? For example, in ANSI-C?

Object-Oriented Programming with ANSI-C (Axel-Tobias Schreiner, English translation, PDF)

on coding

I can’t count the number of times I’ve heard these in the past year:

“I want help learning how to code.”
“Will I have to learn to code?”
“Do digital humanities scholars need to know how to code?”
“How much do I need to know about coding?”

In every case, I’m left scratching my head: how can I begin to answer this question? What is “coding”?

The Problem

What I want to ask in these cases is simpler than you might think. I want to ask what the problem is. What is the solution that you need? Do you need to display data, to run numbers through formulas, to create a nice desktop software application with a GUI? What is the purpose? We can’t begin to answer these questions without the goal concretely in mind.

Coding

And here is the one word that has come to drive me up the wall. Coding. It’s everything and nothing. I’ve heard it used to refer to everything from HTML markup to large and complex software development projects. Coding is agnostic. It doesn’t specify what’s going on. “Learning to code” could be anywhere from “I want to learn the software development process” to learning the basics of a particular language (enough to get “Hello world?”), learning a language in depth, learning scripting languages for using databases on your Web site, or marking up text using HTML and creating CSS stylesheets to go along with them. But without saying any of these, “learning to code” has absolutely no meaning. There really is no such thing. Learning the fundamentals of good programming, possibly, but a tutorial of how to make a for loop Python is no such thing (and when I dissect the coding question, this is oddly what it ends up being much of the time).

A Little Rephrasing

Having discussed the problem with “coding,” let’s move foward and try to produce a real answer to those questions at the top.

Instead of thinking of this as a kind of mysterious and wide-ranging skill to pick up, that applies to creating things with the computer no matter what kind, I will rephrase it as this: creation. Problem solving through creating something to help you arrive at the solution. We build and create all kinds of things without a computer, without giving it any instructions. We make tools and write and draw. We give instructions to our subordinates.

Putting the two big pieces together: What is your problem, what is the goal, and what do you need to learn in order to create something that will solve the problem? Leave programming language and hardware requirements out of it. What do you need to get done?

Now this is the tough part, in my experience. You have a problem and a goal. (For example, “I have all this data, and I want to discover patterns in it. I want that to be displayed as a map.”) But you need the concrete steps in it. What exactly are we working with? What do we want to do with it? How on earth are we going to make that happen? Lay it out: step 1, step 2, and so on. How are they connected to each other? Annoyed as I was at having to diagram program flow charts when I was in college, I have really appreciated their value later on. Make a map of where you have to go in your solution, including all of the stops, in order to reach your goal.

Going Forward

From there, I don’t want to say that the “coding” that I think people are referring to is trivial per se, but the really difficult part has already been done once the problem is thought out and possible solutions mapped. Learning to implement the solution is orders of magnitude easier, in so many cases, than coming up with robust, quality solutions and the concrete steps needed to carry them out.

My advice to all of those with “coding” questions is this: to follow the above steps, and then go out and get a human or a book that is specialized in what you’d use to solve the problem. Google is your friend, if you don’t have an all-knowing expert at your disposal (and who does?). You are probably not the first person who has had to implement your solution concretely, using a specific technology. They may not have done it in your field, but think of the problem itself and not whether it’s processing data sets from history or from biology. Get a sense of how people approached it: visualization software? A specific programming language? None of the above?

Then go get the book or that human, and put in the time. Programming – not to mention Web design in these days of CSS (yes, I started in 1996, and never quite internalized anything after table-based layout) – has a learning curve. You are not the first one to encounter it, but you can overcome it too. Go through the examples and type them in and run them. Play around with them and modify them, then try to get why you broke it and how to fix it. Even better are books or very thorough tutorials on the Web (so few and far between) that take you through a project just like the one you’re working on.

How Much?

So, do you need to know how to code? Who knows. You need to be able to do – or hire someone to do – whatever the solution to your problem requires. Unless you are looking at a career in software development, no one is expecting you to become a programmer. Do you need help “learning how to code?” I hereby order you to never use that phrase again. You need help in figuring out which technology works for your problem and some advice about where to go to learn it. Now go, and enjoy this excuse for getting to learn something new and making something exciting!

Coda

Obviously, I have some personal bias here. I have a programming background, have done quite a bit of Web design and implementation (including sites that get their information from databases), and have used about 10 programming languages over the years. I’m not an expert in any of them. And I don’t always know what technology is going to help me solve my problem. What I learned, really, is that I’m going to have more or less of a learning curve, I’m going to do a lot of research figuring out what might help me the most, and that I might end up on a forum or emailing or calling someone with what I think is an embarrassingly dumb question. It happens. In fact, I just called up my brother and asked a really stupid question 2 weeks ago, but if I didn’t, it would have taken me weeks to figure out my small mistake that was killing everything. If it’s of any comfort, the first learning curve is going to be immensely harder than any of the ones that come after. Once you first “get it” from making a project work, you are going to have problem-solving and logic skills that will vastly improve your life.

So go forth and learn some new technologies! And never use the word “coding” again.

A Creative Endeavor

… or How I Will Drive Myself Slowly Over the Edge

So people talk about there being some kind of nuanced difference between nerd, geek, and dork. I’ve been sucked into it myself, sadly, and as a result I get a little defensive when I am called anything other than a nerd. By any criteria, I really am, and was way before it became ironic-cool to wear thick plastic glasses. (Just check out my fourth grade yearbook.)

I think my own personal nuance is the difference between dork (no social skills), geek (geeking out over things, becoming obsessed with things), and nerd (likes learning for its own sake and often enjoys academics as a hobby, leading to social ostracism and a joy of doing homework). Well, of course all of these things overlap in any person, but the traits of the last manifest quite clearly in me, for better or worse.

Case in point?

This summer I’m working at an internship in Lincoln, Nebraska, and had to pack one car and go (with all of my cat’s things too, so I lost some space). No bringing my ever-expanding book collection with me. I got a Kindle to read Gutenberg.org books on, but still, it would be nice to have some kind of summer project that isn’t a work assignment. A dual degree will do that to you: any kind of scheduled free time becomes exciting and a chance to either take on something with a limited deadline and feel satisfied, or lay around and do a lot of nothing. I try to do both.

So here is my project. I picked up a copy of Seven Languages in Seven Weeks and decided to work through it in the evenings after work. Yes. I am giving myself seven weeks of programming assignments. I’m going to be learning entirely new languages, some I have heard of and some I haven’t. I get a little cheating on one because I am semi-comfortable in Lisp. Still. I will learn a little of each: Ruby, Io, Prolog, Scala, Erlang, Haskell, and Clojure. I am excited about the prospect and not only do I want to learn because it’s fun and programming is fun for the brain (when it’s not hurting your brain, and when you’re not banging your head on the desk) – but also because I think it will be good for my creativity.

After all, creativity is not limited to one domain. Practicing writing helps me think more freely about photography, keeping a journal helps every aspect of my life, keeping daily notes about my dissertation inspires me to reexamine my artistic life (it helps that I write about authors and practices of writing). And there is something about exercising the brain with logic and problem-solving that is refreshing and at least interesting, and often rewarding, after you (I) spend almost all of my work life reading, and writing about stuff I read. Making art is one kind of problem-solving; programming is another.

Both are all about creativity and stretching the brain a little bit further.

But yes, it is seven weeks of daily programming in a set of languages I haven’t used before. I just taught myself Java in three days and then wrote a non-trivial application in it for a class project, and I’m somewhat exhausted. For my internship, my life is going to be all about getting better with XML and TEI, and then learning how to fit XSLT and XPath into the picture, while working with a servlet, which I have never even had to consider before. Good god, I am all about the computer this summer. It’s great.

I’ll have to stop the extracurricular programming if I feel a nervous breakdown coming on. Until then, onward to Prolog!