Showing posts with label Clojure. Show all posts
Showing posts with label Clojure. Show all posts

Friday, January 13, 2012

What makes Clojure different?

A friend of mine asked me why Clojure matters and what makes it special and why I think it is good for linguists. This post is the edited version of my answer to my dear friend. Since there are very good books on the market (my favourite is Clojure in Action) and the internet is full of good tutorials (4Clojure is esp. good if you like the learning by doing method) my goal is only to give you a rough picture of functional programming.

An example

We are going to solve a "toy" problem stolen from the first chapter of Peter Norvig's seminal Paradigms of Artificial Intelligence. The question is how do you extract first and last names from someone’s full name. Before you think this is too simple and it doesn't worth dealing with, consider names like Robert Downey Jr, Admiral Grace Hopper, and what about Staff Sergeant William "Wild Bill" Guarnere (a character for the Band of Brothers series). Machines should be programmed to solve these problems, and even humans could have problems with names. It took me years to figure out that Martin "Boban" Doktor (a well known Czech Olympic champion sprint canoer) is not a real doctor...
First, we need some data to test our assumptions.
The function 'def' associates the symbol 'names' with names (oh, a vector of vectors). A first name is usually just the first word in a name.
And the last name is the last word in a name.
Let's test our functions. Calling first-name and last-name on my name gives the right answers.
We stored out test data in names, and now it's time to test our functions en mass. The higher order function map helps us in doing so. Map takes a function as its first argument and applies it to every member of its second argument.
Oooops, the program is having serious problems with "titles" or prefixes. Calling last-name on names gives interesting results too. Our program is not that bad, it captures the basic logic of identifying first and last names, but affixes cause problems. The first name should be the first word in a name if it is not a prefix. Let's store the affixes in vectors.
We want to test if the first word of the full name is a member of the titles. We need a function that tests membership.
The function member is recursive. First, it test if its second argument is a sequence. The second if gives us a terminating condition, if x and the first element of the second argument are equivalent, it returns the whole second argument. Otherwise it tests the membership again on the rest of the sequence (i.e. everything but the first element of the original sequence). Now, we can redefine our first name function. If the first word of the full name is in the list of prefixes, call first-name on the rest of the full name, otherwise return the first word of the full name.
Testing our new function shows it works correctly.
We can redefine last-name similarly.
Storing names in vectors of strings is very unnatural (at least for humans, I guess machines don't care about these issues). Wouldn’t it be nicer to type names like "Zoltán Varjú" instead of ["Zoltán" "Varjú"]?
First, we need new test data, which is a vector of strings.
We want to use our first-name and last-name functions. Can we split a name into individual words? clojure.string provides us a split function (that's why we put (:use [clojure.string :as str :only [split]] :reload) into ns) which splits a string into a vector of strings at a given point. The space character delimits the parts of a name. Our source code looks like this now:
Now we can test split from clojure.string.
Let's define a split-name function just to save ourself from repetitive strain injury caused by excessive typing.
Finally, we test if our functions work on splitted names.

Notes

I have to note, you can make the code more concise and idiomatic. I hope you can see 1) how can you solve a problem with functions and by combining them 2) you have a basic idea of what is recursion 3) how can you go from a basic problem to an acceptable solution.

What makes Clojure different?

Norvig lists eight features that make Lisp different:
  1. built-in support for lists
  2. automatic storage management
  3. dynamic typing
  4. first-class functions
  5. uniform syntax
  6. interactive environment
  7. extensibility
  8. history (see Paul Graham's essays, What Made Lisp Different and The Roots of Lisp)

Clojure is a Lisp on the JVM which makes it unique. The Java Virtual Machine makes it portable, reliable and secure, but there is a new JavaScript based version called ClojureScript. Slime is an excellent development environment, leiningen makes project automation easy. Java interoperability means Clojure has got a great collection of libraries for almost everything.
However Clojure is not for complete beginners. The Clojure community is very open and supportive, but asking the right question requires some sort of maturity. As this Reddit thread explains you shouldn't be a Java expert to pick up the language, even you can learn what you have to know on the go. But you should know at least one 'conventional' language like Python before you start learning Clojure. More propaganda in our Why Clojure lx? post.

Friday, November 25, 2011

Hints for newbies

We received emails from interested folks who are new to Clojure. We hope they can find enough information about setting up a convenient environment for working with us so that they can provide us feedback. Here we give them a few tips. Please share your experiences in the comments!

Installing Clojure requires some expertise, this means you should be comfortable with your operating system. The easiest way to run Clojure, is downloading the clojure.jar file, and using the java -cp clojure.jar clojure.main command from the command line. However, this isn't the most effective way. Finding information about how to install Clojure on your platform is not impossible with a search engine. Ubuntu users find everything in Clojure on Ubuntu, please note the clojure github repo has been moved to https://github.com/clojure/clojure and clojure-contrib also moved individual repos, so don't follow the description literally!
You'll also need to install Leiningen. Why? As you can read on its repo “Working on Clojure projects with tools designed for Java can be an exercise in frustration. With Leiningen, you just write Clojure”. We are going to use Java tools, and the Clojars community repository provides us with these tools. Although using Leiningen to include various Java libraries into our projects looks very tedious (have a look at the sample file), but taking some time before getting into coding can give us goodies like the Stanford parser, OpenNLP, WEKA.
If you haven't found your text editor of choice, emacs with SLIME is the stuff you need. The Clojure, Swank, and Leiningen with Emacs on Linux shows you how can you set up your development environment.
We won't speak about version control, but you using version control is good house keeping technique. If you are new to this theme, and haven't committed yourself to a tool yet, have a look at git, and github, and read the git community book.

Wednesday, November 16, 2011

Why Clojure lx?

The NLTK is a natural choice for students of linguistics and computer science. It has matured into a stable project, its users are very active, and it is now used outside of academia. Those who are into functional programming can use the Scheme Natural Language Toolkit, or learn from the Natural Language Processing for the Working Programmer, and those who needs the JVM can turn to ScalaNLP. So why brother with Clojure?

First of all, we are NOT proposing a new framework/library here! Our main goal is to examine what Clojure offers to linguists. Although more and more linguistics departments offer courses in statistics and probability theory, the vast majority of students graduate with some background in discrete maths, mostly taught in an implicit way through a class in syntax and/or semantics (and the same is true for philosophy education). Using computer programs to test our scientific ideas is becoming a common practice in sciences, and this is true for linguists too. Stefan Th. Gries distinguishes linguistic computing from computational linguistics; following him, we think linguistic computing will become a common methodology used in the language sciences.

So, what's the difference between computational linguistics and linguistic computing? Well, there is no clear boundary! We'd say computational linguistics (or natural language processing) is a kind of applied science and engineering, and as such it is more “goal oriented”. Norvig's recent critique of Chomsky shows that commercial success is a measure of ideas, but despite the proliferation of statistical methods linguists are still doing research on rule based systems like HPSG, minimalism, etc., and new interdisciplinary research themes have emerged like Parikh's idea of the social software (and game theoretic semantics and dynamic epistemic logic, among others). But what is “pure” research today can become applied research tomorrow. To foster communication between pure and applied research, between linguistic computing and computational linguistics, we need a lingua franca.

As Clojure is the Lisp for the JVM, it is a convenient language for linguists. In the not-so-distant past, Touretzky wrote his Gentle Introduction to Symbolic Computation, an excellent book for beginners in the humanities. Gazdar and Mellish Natural Language Processing in X (where X stands for Prolog, Lisp or Pop11) is a good introduction to finite state techniques, grammars, parsing and it even has a chapter on question answering. We don't deny that these techniques are old, but they are still part of the well-educated linguists' body of knowledge. Also, although Norivig's PAIP is a real gem, one cannot argue against the “old” AI paradigm without seeing the past, and those ideas are still important for linguist, philosophers and cognitive scientists. Logic programming is a natural pair of functional programming. The basic techniques of computational linguistics can be expressed in logic programs, and although they have their computational limitations, these little programs has got unquestionable educational value.

Porting the classic into Clojure is not a novel idea, as some Google searching shows that people are turning the classic Lisp books like PAIP or the Structure and Interpretations of Computer Programs into modern Clojure. The core.logic library opens up the possibility to do the same with the Prolog literature.

The most common argument against NLTK is that you can't use mature, industry standard tools like the GATE framework, Stanford core, and openNLP. Clojure's Java interoperability solves this problem. If you are into machine learning, Weka, MALLET and etc. are at your service. The Incanter package provides an R-like statistical library.

With these tools in your hand, you can test your ideas in a language that's very close to what you learned about formal languages. Using Java libraries is like using rapid prototyping material when you are a marble sculptor. And as your works end result can be shared with the computational linguists, you can get more feedback, and even help from the greater community.

That's why we think that Clojure lx is an idea worths exploring. We'd like to test ourselves! Can we use Clojure to express our simple ideas? How easy is it to use Java libraries for a project? If you would like to join us, please send an email to zoltan.varju(at)gmail.com. We welcome everyone, linguists and Clojure hackers, philosphers, digital humanists, everyone who is interested!

About us
Zoltán Varjú – computational linguist at Weblib LLC, @zoltanvarju, Számítógépes nyelvészet
Richard Littauer – MSc computational linguistics student at the University of Saarland, @richlitt

Special thanks to
Neil Ashton - @nmashton