vlion - a pursuit of the ineffable

Went to a local software hack group. They've got some ruby on rails project they are using for their group work right now. I pitched in and learned ruby/rails on the fly to add some stupid routes. It was awesome.

Came home, shook out ruby/rails on the mac, got postgres.app installed, got my BEAST game's pages shook out a bit better.

I need to get some sort of task tracker rolling for BEAST, I think.

The well-known QUIKTRAN system is based on interpretation of FORTRAN statements. The FORTRAN program under debugging may be modified freely by insertion and deletion of statements. A form of nonconditional breakpoint capability is included in the sense that a statement can be inserted at any point in the program which, when reached, has the effect of transferring control to the user. Capability for examining and modifying variables is present, as well as a variety of modes of tracing (print all assignments to variables in a given portion of the program, all assignments to selected variables, all control transfers within a specified region, etc.). Furthermore, extensive run-time diagnostics made possible by the interpretive mode are provided, and several unusual "bookkeeping" features, similarly based on interpretation, are available, such as the AUDIT command, which generates information as to which portions of the program were never executed, which variables were never set, or set but never used, during a given execution of the program.

from Evans and Darley, AFIPS 1966

My code has run real slow for my thesis.

But, I noticed something odd last night. My code was running faster the more I ran it. Obviously something was being cached...
With a little digging

* (time (render-trace "../../programs_of_interest/one-transfer"))

Evaluation took:
  6.003 seconds of real time
  2.025841 seconds of total run time (1.815692 user, 0.210149 system)
  [ Run times consist of 0.153 seconds GC time, and 1.873 seconds non-GC time. ]
  33.75% CPU
  13,178,489,438 processor cycles
  4,899 page faults
  120,938,224 bytes consed
  
#
* (time (render-trace "../../programs_of_interest/one-transfer"))

Evaluation took:
  3.147 seconds of real time
  1.871226 seconds of total run time (1.728549 user, 0.142677 system)
  [ Run times consist of 0.245 seconds GC time, and 1.627 seconds non-GC time. ]
  59.45% CPU
  6,906,955,110 processor cycles
  1,481 page faults
  120,910,704 bytes consed
  
#
* (time (render-trace "../../programs_of_interest/one-transfer"))

Evaluation took:
  1.888 seconds of real time
  1.807235 seconds of total run time (1.773451 user, 0.033784 system)
  [ Run times consist of 0.048 seconds GC time, and 1.760 seconds non-GC time. ]
  95.71% CPU
  4,143,453,818 processor cycles
  5 page faults
  120,905,696 bytes consed
  
#

Notice the page faults! They really sucked up the time.

I've been using Common Lisp fairly seriously for about a year or so, and recently I've rewritten part of my Master's thesis project in Common Lisp (from Ruby).

How is it?

The parens rapidly become not an issue. Maybe it's a personal thing, but the very regular syntax frees me to think about my semantics. Some people seem to favor irregular syntax. I don't personally understand that; forgetting semicolons, commas, or other elements is a common screwup in other languages for me. Lisp takes that away. Regular syntax (instead of wondering what the right Thungus is to put There) makes things better. Maybe this would be less of an issue if I didn't have so many languages floating in my head; I have used Perl, Python, Ruby, Bash, Lisp, and Make in serious fashion in the past year; I'm going to be learning Objective C and Haskell in the next year.

The library situation is pretty much as good as Perl or Python. Xach's Quicklisp serves quite well in this regard, and I expect it to be the comprehensive Lisp archive for the next decade. Lisp's fully dynamic nature allows redefinition of functions and reloading of modules, which is totally awesome. I'm not sure what other languages support that. Perhaps Erlang?

Macros have made my code shorter and better maintainable. I have almost no repetitive blobs of code. What I do have, I *could* rewrite, but would sacrifice clarity. I have had bugs with my macros, which have not been wholly obvious at first. You definitely need to open up your cleverness to debug them. What is fully evident is that a master Lisper can do portable things with macros that in other languages, require the compiler writers to implement.

The lack of a mainstream-sized community is something I feel. I participate in Stackoverflow and Reddit's Lisp areas, as well as read comp.lang.lisp, and there are generally only may be 5-10 regulars, which are shared between all 3 elements. The IRC channel is pretty good though, although it's infested with "Do it Right The First Time" people, like a parody of the "Worse is Worse" essay at times.

Sequences are put together in a 'so-so' fashion. There are vectors, and there are lists, and functions are not clear which type they take (and they might take both). I expect there's a library that manages this, but I haven't searched for it, preferring to learn the language from the ground up.

The FORMAT (Lisp's printf) function is crufty and weird.

LOOP works, after a fashion, and is unquestionably one of the weakest parts of the standard; I expect I shall investigate other iteration macros after the thesis is finished. Possibly the ITERATE library...

I haven't used any database connectors yet, so I can't comment on them.

Lisp shares the Image model with Smalltalk; this is a model where the REPL persists over a long time. Python and Ruby have their interactive mode, which (as they implement it) is a weaker version. So a common deployment strategy is to deploy a Lisp executable together with an image to be loaded into Lisp at run-time. That's pretty off-the wall compared to the Algol-derived world which has a hard line between compilation & application.

In terms of speed, Common Lisp is a bit slower than C++ for heavy computation - in the hands of an expert. This is in stark contrast with other dynamic languages, which usually are a joke for heavy in-language computation and require a C extension.

Typing is weird - I think it's close to Perl 5's typing - and I don't have 100% of a handle on how to write explicitly-typed code. Usually it's done in an optimization context.

Integration with the shell is "okay", and really requires external libraries to fully handle cleanly. I have put together a few functions which are pretty sweet for that.

In general, Common Lisp usually works like a language that's been designed, instead of organically grown with weird and annoying gaps in it. In this, it works like the C++ STL or the C stdio.

I'm trying to put together a project to document the systems provided by Quicklisp. git is the popular SCM solution and of course quicklisp itself is hosted on github.

Gorram git on Windows. The GUI is dysfunctional and unexplorable. The two-step commits (if I asked you to commit, go find what I changed and commit it!!). The requirements to have a SSH key on github. The installation of a *custom* git shell.

This is not sane in a modern environment. The driving principle of many- most?- high-quality interface designs is "Simplicity on the outside, complexity comes as you dig deeper". git just fails. Hard.

I'm going to keep using it for this project, because it's rude to ask people to use Mercurial/bitbucket (the better solution), when they've already invested time and energy into github for Quicklisp.

Props to the U of Idaho ACM - they animated a skyscraper.

http://www.vimeo.com/16159414

Windows 7 has proven itself to be quite excellent so far on my laptop.

The outdoor landscape backgrounds are pretty much some of the best photography I've seen in a while. I'm basically stunned by those visuals every time I see them.

Once my desktop has W7 on it, I will be fully transitioned into a 64-bit operating world. Well. Mostly. I have an older machine kicking around with Ubuntu on it, but it is likely to disappear when I boost my desktop's RAM. 8 GB is my desire for the desktop, but it might be better to hold off on that until I have moved down to New Mexico and have stabilized there - the desktop is sorta my play machine and I don't need to burn money on it.

Just found out it that timestamps on the files I've been grading are in UTC instead of PST.


Hoo boy. Time to regrade.

I also have 40 pages of denotational semantics to read and understand.

Looks like it's going to be a hard-workin' weekend.

I've picked up some old lisp code I had; I have the kernel of a genetic programming program half-written. I think I'll try and make progress on it, then work on my taginator project.

Ah well. May have to retreat into WoW for a bit if things get too stressful.

So it turns out svn post-commit hooks actually execute user-side. That's annoying. A commit can take a while as I run post-processing code for metrics.

A hack solution is to attempt to write a dirtyfile out to ~/temp on post-commit. This solves the wait time issue, since the time gets offloaded to Cron.

Another issue is I write code on 4 different operating systems and commit into the repo on all of those. What's going to happen when I commit from Windows to the Linux host server? I'll have to test that in a bit. First I want the *nix solution fixed, then let's see what SmartSVN does.

Obscure fact: John Clark in 1845 created a device to compose Latin Hexameter:
http://www.minervaclassics.com/eureka.htm