I made a number of Google searches of the forms below and summed the results (previous posts averaged the results):

"implemented in <language>"
  "written in <language>"

Naturally this is of very limited utility, and the numbers are only useful when comparing relatively within the same search since the number of results Google returns can vary greatly over time.

¹ combines Lisp, Scheme, Common Lisp, Arc & Clojure
² combines OCaml, (S)ML, Caml
³ summed separate searches for sml and ml

I made a number of Google searches of the forms below and averaged the results:

"implemented in <language>"
  "written in <language>"

Naturally this is of very limited utility, and the numbers are only useful when comparing relatively within one column since the number of results Google returns can vary greatly over time.

¹ combines Lisp, Scheme, Common Lisp, Arc & Clojure
² combines OCaml, (S)ML, Caml
³ summed separate searches for sml and ml

I made a number of Google searches of the forms below and averaged the results:

"implemented in <language>"
"written in <language>"

¹ combines Lisp, Scheme, Common Lisp, Arc & Clojure
² combines OCaml, (S)ML, Caml
³ summed separate searches for sml and ml

• 650 KLOC plus 150 KLOC of open source code
• 100 people on the team, 70 programmers
• SBCL for the QPX product
• Clozure CL for the reservations product
• Availability requirement: four 9’s => less than 53 minutes downtime per year
• Latency agreement
  • 90% of requests w/in 300 ms
  • 5% of requests w/in 600 ms
  • 5% of requests w/in 1,200 ms
• Java presentation layer, Common Lisp stateless business layer, Oracle data layer
• Daniel is very positive about Clojure
• Some links from the talk:
  • Survey of Common Lisp Implementations
  • International Lisp Conference 2009 Discusison Forum
  • Dan Weinreb’s Blog

After bumping into a number of local programmers who expressed an interest in functional programming, I thought it might be a good time to start a local group that focused on functional programming languages, so I did a couple days ago.

TriFunc.org is a group for programmers who are interested in functional programming languages and live near the Research Triangle area of North Carolina.

If you live in the area and have an interest in functional programming languages, feel free to dive in and start participating in the Google Group discussions. Once we reach a critical mass, I expect we’ll produce a meeting schedule, etc., but that will depend on where the group wants to take this.

The 2008 Programming Language Plan didn’t go as well as I hoped, so I’m regrouping for another go at it. I did make progress learning some Logo and teaching it to my daughters, and I worked through seven chapters of “Programming in Haskell” which was very enjoyable, but I also spent way too much time trying to decide which language(s) to learn without actually learning them.

I have now decided which languages I want to learn this year, so I figured I’d post this blog entry. In some respects, things haven’t changed much from last years plan, but my decisions are much less tentative which is encouraging. I’m glad to switch from information gathering to actually learning a few languages.

Motivation

When I switched from C++ to Java in 1996 and noticed a large increase in productivity; however, it didn’t occur to me to consider whether switching from Java to another language might also give me a similar boost in productivity. The job demand for Java was high during the 10 years I used it, and I was getting paid for my time vs. what I produced, so the oversight wasn’t too costly.

When I switched from Java to Ruby in 2006 I experienced a comparable, if not greater, boost in productivity as I had with the switch from C++ to Java. This time I considered the effect of programming language choice on productivity more carefully and began to wonder about the optimal programming language for me. As a small business owner, my primary consideration is productivity, not popularity or the interchangeableness of programmers.

I don’t think a perfect programming language exists in general, but I think there is an optimal language for me given my particular circumstances, the problems I want to solve, the type of software I want to develop, my way of thinking, my aesthetic tastes, etc.

The Problem

There is a cost to research programming languages to determine the optimal one, and there is a cost to switch programming languages, so the benefit of a new programming language needs to exceed those costs.

Additionally, a significant catch-22 exists in that to truly determine if a language is optimal, one must reach a level of proficiency with the language. There isn’t enough time to learn all of the candidate languages, so some filtering mechanism must be used first to narrow the choices to a reasonably small set. This filtering mechanism is theoretical by nature, but I think the subtle practicalities of a language have a significant effect on productivity.

I have a long term perspective for this task, so I don’t mind investing time researching programming languages, and I also don’t mind if I need to develop/acquire supporting libraries before being ultimately more productive than I am currently with Ruby and Rails.

The Process

I briefly entertained the idea of going about this research in a more systematic, scientific way. That might be a reasonable approach, but due to the following:

• My laziness
• The high degree of subjectivity in programming language choice
• The lack of consensus among programming language researchers

I ended up with a fairly ad-hoc approach involving examining the following areas and trying to absorb enough information to formulate a plan:

Efficiency

Programming language efficiency is becoming increasingly important to me as Moore’s law loses steam, and power & cooling issues become more prominent.

On the one hand, Ruby is near the bottom of the pack with respect to efficiency, but the productivity has been outstanding, and at the volume of transactions I’ve needed to deliver thus far, performance hasn’t been a problem.

On the other hand, if programming languages exist (and I believe they do) that have similar or greater power than Ruby but are compiled instead of interpreted, that would be an advantage.

Benchmarks are notoriously controversial with respect to the degree in which they predict performance, but I don’t think they’re irrelevant. One popular benchmark site is: Programming Language Shootout. I also created some micro-benchmarks of my own to test performance.

One negative result of Ruby being inefficient is the disparity in performance of code written in Ruby vs. library code, or extensions, written in C. This creates counter-intuitive scenarios where a piece of code that appears less efficient is actually more efficient because of the use of built-in code implemented in C. I don’t like thinking in those terms; I would much prefer that user written code in the language is much closer to the efficiency of built-in library code.

Concurrency

With the flattening of CPU MHz and proliferation of CPU cores, I think concurrency may continue to grow in importance. Although I develop mainly server side web applications which can take advantage of multiple cores by virtue of having multiple independent processes, I would prefer to have better concurrency mechanisms in the language/libraries directly.

Joy

I think I first heard joy used, in the context of programming languages, in the Ruby community – probably from Matz himself. I have to agree that programming in Ruby has been more joyful than previous programming languages.

I’m not sure exactly why this is, but I expect it has something to do with the effectiveness and productivity of Ruby, but it may be helped by the incredibly friendly Ruby community.

Fundamental Nature

My preference is for a programming language to minimize arbitrariness and to maximize orthogonality. In other words, I would prefer the language to have a minimal set of core concepts/axioms/operators/etc. that are built upon systematically.

Community

Whether my optimal language is mainstream or not is irrelevant to me, so I don’t need the programming language community to be large (and in fact, being too large is a detriment), but I do think it should be active enough that there are people available to help answer questions, write libraries, maintain/improve compilers, debuggers etc.

To this end, I spent time on various usenet groups, IRC channels and blogs. Occasionally asking questions, but mostly observing the dialog and interaction among the community members.

Education

What educational materials are available?

I tend to prefer learning from books, so searching Amazon to see what books are available, how well they’re received, etc. was helpful. Although I prefer books typically, in the exploratory stages, it’s cheaper to go through online materials, so searching the web for free PDFs was useful. The existence of a few good texts is also an indication of the vitality of community.

Productivity

Ultimately, I’m after the most productive language for me; however, I think productivity is the factor that requires the most proficiency with a language to judge, so it was the most difficult factor to research prior to learning a language. I was limited to anecdotal stories, case studies, personal testimonies, etc.

Licensing

I prefer open source licensing because I think programming languages with proprietary licensing are more likely to die.

The Final Candidates

I began with Ruby as the point of reference irrespective of Rails and other libraries. Even though Rails is an important factor in my current productivity, since I’m taking a long term view, I didn’t want to exclude a fantastic language simply because it’s lacking something that Ruby was also lacking N years ago.

Due to the cost of researching, learning and switching to a new programming language, I only considered languages that had the potential of offering a significant improvement in one or more areas without losing too much in other areas.

The candidates I eventually selected fell into two groups. Both groups have strong functional capabilities, good efficiency, and long, successful track records. I believe that even the best programming language designers make serious mistakes which can only be identified with the hindsight of years of use. It’s possible that someone is about to release a brand new language that has the potential to be the most productive for me personally; however, I’m not willing to take the risk to learn it.

The Lisp Family

Lisp has a very long track record of success and adaptability. In fact, if I was forced to program in a single programming language from now on, I would probably choose a Lisp since I think it would have the greatest likelihood of being able to adapt.

The Lisp family has dynamic typing which I’ve grown to love with Ruby, but most also allow type declarations for efficiency. Lisp also appears to have a more fundamental nature than most languages. I’ve heard it said that Lisp was more discovered than invented.

I first became interested in Lisp when I learned that Ruby was influenced by it. My interest was reinforced by some of Paul Graham’s essays & books. I like the exploratory and dynamic nature of developing Lisp – this is mostly from reading comments of others, but I’ve tasted a small part of this when evaluating Lisp code in Emacs and having it be available immediately.

Logo is first on the list simply because it’s both a Lisp and a great language for teaching children how to program, so I can kill two birds with one stone.

Scheme is next because it’s a natural sequel to Logo and I still want to work through “The Structure and Interpretation of Computer Programs”. The fact that Paul Graham chose mzcheme to create his Arc language is a good “letter of recommendation”. Scheme feels the most fundamental, simple & clean thus far.

Common Lisp is after Scheme due to its eminent practicality and completeness. It has plenty of warts, but also plenty of power and functionality. It’s been called a great, big, ball of mud – but in a good way ;)

Lastly, is Clojure. It’s last in the Lisp family because I want to learn Scheme & Common Lisp first so I’ll be better equipped to judge Clojure. This will also allow more time for Clojure to mature. Clojure has a focus on functional programming & concurrency that is symbiotic with the Java platform. The latter provides a quick start and access to Java libraries, the JVM infrastructure, etc., but my preference would be to not be dependent on the JVM in the long run. I’ll withhold judgment until I’ve learned it and used it for a while.

The ML Family

I’m least familiar with the ML family and with functional programming in general. I’ve spent most of my career studying and using imperative, object-oriented programming languages.

I think the ML family is worth studying because:

• Functional programming may be beneficial with respect to concurrency.
• Prog. Lang. researchers seem to be enamored with ML family.
• There are enough anecdotal testimonies of productivity to warrant further study.

Standard ML is an important functional language that differs from Haskell in that it’s impure, i.e. it allows side effects, and it’s strict, i.e. not lazy. It shares Hindly-Milner static typing with Haskell. The community seems rather tiny, and I expect that if I go with a static typed language it will likely be Haskell, but I wanted to learn Standard ML first because of its historical importance and to be able to compare an impure/strict language with a pure/nonstrict language.

Haskell is probably the most different programming language from what I’m used to. This, in and of itself, has some advantages with respect to gaining new perspectives and ideas. In some ways, it’s a language that has taken things to extremes with respect to functional purity and laziness.

The community is very active. It offers a great compiler (GHC), software transactional memory, a decent base of libraries, etc.

At this early stage, I’m skeptical of static typing, functional purity and laziness, so becoming proficient in Haskell is a great opportunity to be able to determine how I feel about those.

The Plan

Rather than go through the candidates sequentially, I’m going to try and make progress on two tracks concurrently to allow me to compare concepts from both families:

I’m curious to find out how I feel about these languages after I’ve achieved some skill with them, but I think becoming proficient in the Lisp and ML families will be time well spent. At minimum, I’ll be better equipped to compare other languages.

"implemented in <language>"
"written in <language>"

I’m very curious to see how these stats change over time, so I’ve added a calendar item to recompute them in six months. Leave a comment if you’d like to add a programming language to the list, and I’ll update this article and it will be included in the recomputation six months from now.

¹ combines Lisp, Scheme, Common Lisp, Arc & Clojure
² combines OCaml, (S)ML, Caml
³ summed separate searches for sml and ml
Update 4/23/09 added C#, Tcl per comment requests.

This one was too much fun for words in re how cool it is programming
with Lisp. I would like to see this in Ruby, Clojure, Qi, and
Scheme. The precise fun part tho is typing it all in in the final form
versus dividing the thing up into steps to get intermediate results,
ie, a test of one's mastery of one's language. Non-functional
languages I guess have no choice but to stop and assign temporaries.

Given:

(defparameter *pets*
  '((dog ((blab 12)(glab 17)(cbret 82)(dober 42)(gshep 25)))
    (cat ((pers 22)(siam 7)(tibet 52)(russ 92)(meow 35)))
    (snake ((garter 10)(cobra 37)(python 77)(adder 24)(rattle 40)))
    (cow ((jersey 200)(heiffer 300)(moo 400)))))

Write:

(defun digest-tag-population (tag-population pick-tags count)...)

Such that:

(digest-tag-population *pets* '(dog cat snake) 5)

=> ((DOG CBRET 82) (DOG DOBER 42) (CAT RUSS 92) (CAT TIBET 52) (SNAKE
PYTHON 77))

...the rules being:

- consider only the populations of tags (the first symbol in each
sublist) found in the parameter pick-tags, a list

- take only the  most populous of the union of the populations

- return (tag name population) of the most populous in this order:

    firstly, by position of the tag in pick-tags
    second, ie within a tag, in descending order of population

(defun subseq-ex (st e s)
  (subseq s st (min e (length s))))

(defun digest-tag-population (tag-population pick-tags count)
  (flet ((tagpos (tag) (position tag pick-tags)))
    (stable-sort (subseq-ex 0 count
                   (sort (loop for (tag population) in tag-population
                             when (tagpos tag)
                             append (loop for pop in population
                                        collecting (list* tag pop)))
                     '> :key (lambda (x)
                               (caddr x))))
      '< :key (lambda (x) (tagpos (car x))))))

(defparameter *pets*
  '((dog ((blab 12)(glab 17)(cbret 82)(dober 42)(gshep 25)))
    (cat ((pers 22)(siam 7)(tibet 52)(russ 92)(meow 35)))
    (snake ((garter 10)(cobra 37)(python 77)(adder 24)(rattle 40)))
    (cow ((jersey 200)(heiffer 300)(moo 400)))))

#+test
(digest-tag-population *pets* '(dog cat snake) 5)

And here is my Ruby version:

PETS = [
  [:dog, [[:blab, 12], [:glab, 17], [:cbret, 82], [:dober, 42], [:gshep, 25]]],
  [:cat, [[:pers, 22], [:siam, 7], [:tibet, 52], [:russ, 92], [:meow, 35]]],
  [:snake, [[:garter, 10], [:cobra, 37], [:python, 77], [:adder, 24], [:rattle, 40]]],
  [:cow, [[:jersey, 200], [:heiffer, 300], [:moo, 400]]]
]

def digest_tag_population tag_population, pick_tags, count
  tag_population.select {|e| pick_tags.include?(e[0]) }.
    inject([]) {|memo,obj| obj[1].each {|e| memo << [obj[0], e[0], e[1]] }; memo }.
    sort {|a,b| b[2] <=> a[2] }[0,count].
    sort_by {|e| [ tag_population.map{|p| p[0]}.rindex(e[0]), e[2] * -1] }
end

digest_tag_population(PETS, [:dog, :cat, :snake], 5)

Within the function:
Line 1: select elements that match the pick tags
Line 2: map to a list of tuples of the form [:dog, :blab, 12]
Line 3: sort the list of tuples by population and select the first count of them
Line 4: sort by tag position, population

Output:

[[:dog, :cbret, 82],
[:dog, :dober, 42],
[:cat, :russ, 92],
[:cat, :tibet, 52],
[:snake, :python, 77]]

I think Ruby compares very favorably. What do you think? Feel free to submit a version in another language.

The motivation for the split is the feeling that a lot of my non-technical family & friends grow weary of weeding through a lot of techno-geek material to find anything interesting, and folks who read my blog for technical info probably don’t want to weed through the silly videos, etc.

Wordpress has worked fine for my blog thus far, but I want to take the opportunity to develop my personal blog in a new technology more for the learning experience than necessity. I haven’t had time to select the appropriate technology, so I have a bit of analysis paralysis.

The candidates are:

• Ruby on Rails: I currently develop primarily in Ruby on Rails, so in that respect it would be the logical choice and easiest way to get started; however, it wouldn’t have the benefit of learning a new technology.
• Arc: I had high hopes for Arc when Paul Graham first released it. I still think it has potential, but that potential is limited by Paul’s interest level and available time. It’s been over 3 months since the last release and that was only a small incremental improvement. The forum seems dead, and the fact that Arc went through a 5 year blackout period makes me wonder whether it will be a dead-end language and a waste of valuable time.
• Common Lisp: I am leaning toward a Lisp, so if Arc doesn’t pan out, Common Lisp would be a good fallback language. It’s much more mature with robust implementations. It doesn’t provide a nice batteries included experience though, and I’ve been reluctant to collect the necessary libraries from various sources to allow anything remotely similar to Ruby on Rails with respect to ease of development. I think it may have a greater long term potential though, so it may be worth the effort.
• Scheme: The PLT web server may give me a head start on a Lisp based web site, and Arc is based on MZScheme, so it’s on the short list.
• Haskell: I know very little Haskell (even less than Lisp which is not much), but I’m intrigued by many aspects of the language. GHC seems to be a great compiler that produces well performing programs. My initial impression is that it will take more effort to learn than a Lisp, but in terms of brain stretching, it has a lot to offer. There is a Haskell based web server available, but like a lot of fringe languages, it appears to be pretty rough around the edges.

I have a vacation coming up, so I think I’ll use some of the down time to do some research and make a decision. Look for the blog bifurcation to happen in the latter half of June. If you have any opinions on the matter, please add a comment :)

1. Install the emacs-snapshot-gtk package
2. Edit ~/.Xresources to have
   Emacs.font: Bitstream Vera Sans Mono-10
3. xrdb -merge ~/.Xresources

Before discussing how to get nice fonts for emacs, it might be reasonable to ask, “why emacs?” I haven’t fully answered that question myself, but had I not been able to get nice, readable fonts on emacs, I probably wouldn’t continue researching it. For the info on getting nice fonts to work, scroll down to “Nice Fonts” below.

After many years of using large IDEs to develop software, I switched to vim about a year and a half ago when I began developing with Ruby on Rails. Although the learning curve for vim was a bit steep, I quickly got to the point of being more productive with vim than I was with my previous IDE, and I’m continually learning features of vim that save me time and effort.

Ok, if vim is so great, why am I considering emacs? In a word, Lisp. Emacs, has great Lisp support. For the little bit of Lisp dabbling I’ve been doing, vim has been fine, but from what I’ve seen demonstrated with emacs and slime, I think it’s worth researching. Another important factor is that emacs is scripted with elisp, a dialect of Lisp. I’ve never taken the time to read up on vim scripting, but scripting emacs with elisp seems easy. Type in some elisp code into the scratch buffer, evaluate it, and it’s integrated immediately into emacs. I haven’t written any vim scripts in a year and a half, but within a few hours of researching emacs, I had implemented several elisp scripts (from source obtained online).

Here’s one to simulate the % command in vim which moves the cursor to the matching paren:

(defun match-paren (arg)
  "Go to the matching paren if on a paren; otherwise insert %."
  (interactive "p")
  (cond ((looking-at "\s(") (forward-list 1) (backward-char 1))
	((looking-at "\s)") (forward-char 1) (backward-list 1))
        (t (self-insert-command (or arg 1)))))

(global-set-key "%" 'match-paren)

Here’s one to simulate the vim o and O commands which open a new line either below or above the cursor and position the cursor properly indented, so you can start typing immediately. I use this quite often in vim:

(defun bja-open-line-below ()
  (interactive)
  (end-of-line)
  (open-line 1)
  (next-line 1)
  (indent-according-to-mode))

(global-set-key [?C-o] 'bja-open-line-below)

(defun bja-open-line-above ()
  (interactive)
  (beginning-of-line)
  (open-line 1)
  (indent-according-to-mode))

(global-set-key [?M-o] 'bja-open-line-above)

After my brief exposure to emacs, I think vim is more concise. In other words, it appears that vim can accomplish a given task with fewer keystrokes than emacs. I’m curious to see how hard it is to extend emacs to have some of the niceties I’m used to with vim. Maybe I can have the best of both worlds – the conciseness of vim and the extensibility and Lisp support of emacs. Lennart Borgman passed on a link to vimpulse.el, so I’ll take a look at it soon.

I swapped my caps-lock with my left control key a long time ago, so the emacs chording isn’t quite as much of a problem, but I still wonder if vim might be easier on the hands/wrists since it requires very little chording.

I know some famous lispers use vi(m) for Lisp development, so I don’t think emacs is a must-have. Also, if I end up using a commercial Lisp such as Lispworks or Allegro, I may consider returning to an IDE for lisp development. So, at this stage, I’m still very much a vim user who is researching emacs.

UPDATE:Well, sometime between the original post and now I became a die-hard GNU Emacs user, so I figured I’d update the post :)

Nice Fonts

But enough of that, how do you get nice fonts on emacs? I had heard that the new version of emacs (22) provided anti-aliased fonts, but apparently I was mistaken. I spent hours Googling and rebuilding emacs to no avail – quite a frustrating experience. Then I posted a question on the gnu.emacs.help usenet group and received a helpful reply in a few minutes which did the trick. Here’s the thread.

Here’s what I did:

cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co emacs
cd emacs
./configure --enable-font-backend --with-gif=no
make bootstrap
make
sudo make install

After that, I was able to use the ‘Bitstream Vera Sans Mono-10′ font, and it looks great!

emacs -r -fn "Bitstream Vera Sans Mono-10"

The -r flag is for reverse video. I much prefer a black background. After making emacs from the cvs sources, it reports its version as 23.0.60.2.

After editing my ~/.Xresources file to have the following line:

Emacs.font: Bitstream Vera Sans Mono-10

And running the command:

xrdb -merge ~/.Xresources

Emacs automatically uses that font at startup.

During my hours of Googling, I had seen the page with the correct information here. But in my haste, I read the statement, “Note: Since the emacs-unicode-2 branch which had the xft support is merged into trunk, the current page is obsolete.“, and somehow got the impression that the entire page was obsolete, but apparently that is not the case.*

Fortunately, the helpful folks on gnu.emacs.help set me straight – thanks guys!

*UPDATE: I edited the wiki page referenced above, so the “obsolete” notice is further down the page.