Edit: This post recently re-surfaced on hacker news and caused a bit of a stir, mainly because of a slightly sensational/misleading title (was “Why is Clojure so slow?”). I wrote this before Rich Hickey’s Clojure/Conj 2011 keynote was published, in which he talks about most of my concerns (and outlines possible solutions).

Clojure is great in many ways, but one thing it can’t be accused of is being particularly fast. What I mean by fast here is the speed at which Clojure programs execute. This is a well-known issue in the Clojure community and has been discussed on the mailing list and Stack Overflow.

This is a follow-up post to my previous “Scheme in Clojure” post.

This time we implement a Scheme interpreter as an external DSL. This means that we consider the DSL as completely foreign to the host language, so we need to write our own parser (or reader as it’s called in Clojure) and interpreter. I have to admit that this is a bit of an academic exercise because the internal DSL version I wrote about previously is both smaller (less code) and faster (as fast as any other Clojure code). However, this can serve as an example of how to write parsers in Clojure and it also highlights how elegant and succinct such a parser/interpreter can be. And of course, it’s pretty darn fun :-)

Asynchronous workflows is a very powerful feature of F#, and recently I wanted to explore the state of the JVM and in particular Clojure when it comes to replicate the functionality. In this post I’ll share some of my findings and I’ll include some background material to explain the problems.

Let’s start with an example of a webclient using “async” in F#.

let download url = async {
  let request = HttpWebRequest.Create(Uri(url))
  let! response = request.AsyncGetResponse()
  use stream = response.GetResponseStream()
  let! res = asyncReadToEnd stream
  return res
}

The magic here is that you can write continuation-style code in a sequential manner. This combines the scalability of asynchronous programs with the readability of sequential code. So, what lessons can we learn from this code and how would we do this with the JVM and Clojure? First of all, this is not the same as using futures over blocking calls;

I find myself working with DSLs quite a bit, and thus I write a few parsers. Some languages are better than others for parsers and pattern matching is a technique that makes writing parsers a true joy. I will not go over the basics of pattern matching here, rather show how F#’s active patterns can be used to take pattern matching to the next level.

The traditional steps of a “parser” are roughly lexical analysis (tokenizer), syntactic analysis (parser) and then evaluator (interpreter). In this post we’ll focus on the parsing step of a simple DSL. A parser typically consume a list of tokens and produces an Abstract Syntax Tree (AST), ready to be passed on the evaluator/interpreter.

If you give someone Fortran, he has Fortran.

If you give someone Lisp, he has any language he pleases.

– Guy Steele

Replace Fortran with whatever language you are currently using, and the quote still holds true today. Lisp has been around for a long time, and it’s built-in flexibility is still unmatched by other languages. In this post we will look at key Lisp concepts such as code-is-data and powerful macro semantics.

I recently looked into Tail Call Optimisation/Elimination (TCO) and the implications for 3 modern languages, namely F#, Clojure and Scala. In this post I share my findings. If you’re new to the subject or just looking into some of these languages I hope this post can be of some use to you. I will mix code snippets in the 3 languages freely (and without warning! :)

TCO is a well documented topic in books and articles about functional programming, and the TCO in .NET and the lack thereof in the JVM has been debated “to death” on various programmers’ boards. I don’t intend to add any fuel to the fire here, rather some background and practical implications.

This article serves as a follow-up to my previous post on symbolic execution, which can be found here. In this article, we will delve deeper into the details of KLEE and LLVM, discussing a potential practical application for a symbolic executor. We will also address some limitations and drawbacks associated with this approach.

If you’re interested in the changes we made for KLEE and LLVM, you can find them on GitHub.

One limitation of symbolic execution, as well as dynamic code analysis in general, is that the code under analysis needs to be buildable and linkable. Consequently, it is more challenging to analyze subsystems or code snippets compared to using a lint tool. Another complication arises from the fact that the symbolic executor’s virtual machine must also comprehend and model the system calls used by the code. This makes the tool OS-dependent, as it requires emulating all calls that “escape” the executor. Cadar, Dunbar, and Engler explain how this can be achieved for Linux by analyzing GNU coreutils in [1].

GNU and Richard Stallman were a real catalyst for the open source movement and its crown jewel: the Linux kernel. Not only did Mr. Torvalds’ early Linux releases had nearly 100% GNU “user-land”, he also decided to release it under the GNU Public License (GPL). GNU and Stallman are forever linked with the birth and popularization of open source, and innovated both technically and legally by turning copyright laws on their head with the copyleft licenses. The Free Software Foundation, the custodians of the GPL, is a constant source of spicy statements about the state of the software industry.

When people think about .NET development, they think of C#. Sure there are other languages (VB, ASP.NET etc) but .NET and C# are very tightly linked (just drop an .NET assembly in reflector for technical proof). If you’re writing a new Windows application (and it’s not a high performant game), chances are you are reading WPF books right now.

One of the promises of .NET when it was released was “the great language independent” runtime, making all these languages interoperate in joyful bliss. Technically this still holds, but in practice it’s all about C#.

Given the fact that I worship at the SICP altar, it should come as no surprise that I follow the recipe outlined in chapter 4 of said book; implementing a Scheme interpreter in every language I am trying to learn. Over the years it has turned out to be a very useful exercise, since the problem is just “big enough” to force me to drill into what the languages have to offer.