alan dipert

The Most Officialest SkiFree Home Page!

Tue, 24 Apr 2012 08:43:00 -0700

The Most Officialest SkiFree Home Page!:

The history and implementation of SkiFree.

A Sigh of Datomic

Thu, 08 Mar 2012 06:25:20 -0800

Over a year ago I had the great pleasure of working with the Datomic team through my wonderful employer, Relevance, while the project was still secret. Datomic, which was released on Monday, is a new kind of database with a unique and powerful set of properties.

I believe Datomic makes new kinds of applications possible and old kinds of applications easier, and I encourage you to try it out.

My experience working on and around Datomic was incredibly formative technically and professionally. The only downside has been the agony of waiting to talk with people about it and to apply it to public projects and products. I’m excited and relieved that Datomic is now in the open.

As a technical influence, Datomic solidified a perspective on computing that I was first exposed to through Clojure, also designed by Rich Hickey. I have found this perspective - which might be loosely characterized as emphasizing simplicity, immutability, and the importance of data - a powerful tool by itself, irrespective of either Clojure or Datomic. It is this perspective that Rich elaborates on in his Strange Loop 2011 keynote, Simple Made Easy.

Simplicity, immutability, and data are powerful ideas to think about software in terms of, whether you are creating something new or assessing something that already exists.

As a software consultant at Relevance, I divide my time between creating solutions and choosing existing solutions in order to solve problems. Combined with deliberate thought, research, and discussion with colleagues and clients, these ideas have helped me do both things better, to the extent that it sometimes feels like cheating.

Professionally, my involvement with the Datomic team taught me many things, the most influential of which was perhaps the importance of questions to problem solving.

I work in a totally intangible world of software, trade-offs, conceptions, and domains that has technical, social, and financial dimensions. This world disappears when I try to imagine it all at once, which is my first instinct when I try to solve a problem within it.

Specific questions and their answers are a tool for considering this intangible world one piece at a time in the context of a particular problem. If you ask and answer enough of them for yourself, you can build a practical mental model of the intangible. This model allows you to make sensible decisions and form grounded opinions. Questions are a big piece of the problem solving approach Rich discusses in his “Hammock-driven development” keynote at Clojure Conj 2010.

It’s not always easy to ask questions, especially if you know it will be hard to find the answer, or if the answer might be unfavorable. But, unless you value your ego over your ability to solve problems, you should never hesitate.

Rich Hickey, Stu Halloway, Justin Gehtland, and the rest of the Datomic team did not hesitate, and now the world has a new database of singular vision and capability.

Structural Editing Redux

Fri, 10 Feb 2012 08:48:00 -0800

I gave a quick lightning talk at the most recent TriClojure about structure editing. Structural editing is an idea I can’t seem to shake, and my efforts to wrap my head around its implications continue.

After the meeting, I followed up with a few interested parties about my discoveries, and thought to post them here for the benefit of the wider Internets:

The blog post that originally got me thinking caused me to write my own blog post, and a little while later I published a gist of a simple structural editor for Clojure using zippers.

The code in the gist has a lot of bugs. In particular, the zipper function I’m using doesn’t handle vectors or hash maps gracefully. I’ve thought about tightening the REPL loop so that every key press instantly triggers zipper movement.

The whole structure editor thing has also turned me on to the idea of touch/tablet IDE for Lisps - form bubbles that can be nested, similar to the Scratch project (but data). I think this might ultimately be a better way to represent structure and sequence than characters and parentheses.

Once I found out about Interlisp (pdf), I went nuts, but information and screenshots are hard to come by. Rich Hickey told me once that there is a video floating around somewhere of the Interlisp-D UI in action, but I’ve never been able to find it.

I’ve investigated what it would take for a real-time structure editor, and I think it’s a very hard problem. Synchronizing data structures with their pretty-printed representation on a character display is no small feat. Bernard Greenberg (pictured below) documents some approaches in his history of the implementation of Emacs.

More recently, Michael Fogus pointed me at Nokolisp, an old Lisp for DOS that features an interesting-looking structure editor, among other features (like “uncompiling” functions!)

My current thinking on the implications of a structural editor goes beyond convenience of representation and into the idea of programs constructed by query. I imagine a world where code is stored and shared structurally instead of with text. Programming with available libraries then becomes querying instead of explicitly programming.

As the programmer types, their editor might search these libraries in real-time and do things like suggest improvements using probability heuristics, or suggest substitution of their code with available library code that is a structural match. This is an extension into a networked world of some of the ideas built into Interlisp.

Code as truly data also abolishes the need for git or other text-based source revision tools, as source would be stored at the granularity of expression - not the character or line.

"Bass was used very infrequently until their later songs, and live shows often saw Remmler playing..."

Thu, 28 Jul 2011 20:44:44 -0700

“Bass was used very infrequently until their later songs, and live shows often saw Remmler playing some simple preprogrammed rhythms and melodies on his small Casio VL-1 keyboard while Behrens played his drums single-handedly while eating an apple.”

- Wikipedia - Trio (Band)

Discover Lisp in Your Web Browser with Javascript

Sun, 03 Jul 2011 08:59:00 -0700

This post is available as a PDF

Many ideas introduced originally in Lisp, such as conditional execution (the if-then-else construct), garbage collection, and first-class functions¹, can be found in modern non-Lisp programming languages.

Other ideas pioneered by Lisp, like the idea that programs can be composed solely of expressions, and homoiconicity, or the idea that a program can be written in its own data structures, are rarer.

Learning a Lisp dialect, whether it’s Clojure, Scheme, or Common Lisp, is a great way to see for yourself how powerful all of these ideas can be when combined.

An even better way to understand the ideas is to implement your own Lisp²³.

After we explore some fundamental concepts, we’ll look at how a language like Javascript works.

Then, we’ll build our own small Lisp to Javascript compiler on top of Javascript in about 32 lines of Javascript code.

Expression vs. Statement

Programs in languages like Javascript are composed of two things:

statements
expressions

Lisp programs are composed only of expressions.

Both statements and expressions are, in some sense, instructions for the computer to do some piece of work. The difference between them is that a statement does not return a value, but an expression does.

Consider Javascript’s if-then-else statement:

if (x > 10) {
  alert("x was bigger than 10!");
} else {
  alert("x was not bigger than 10!")
}

We call alert inside both the then and else bodies of the expression because if does not return a value. If it did, we could pass it directly to a single alert call, as this wishful pseudo-Javascript demonstrates:

alert(if (x > 10) {
  return "x was bigger than 10!"
} else {
  return "x was not bigger than 10!"
});

If we eliminate statements from our wishful pseudo-Javascript entirely, there’s no longer a need for the return operator. It’s assumed that values “return” themselves:

alert(if (x > 10) {
   "x was bigger than 10!"
} else {
   "x was not bigger than 10!"
});

Javascript actually provides an if-then-else construct that returns a value, the ternary operator⁴, but it is seldom used and often discouraged⁵.

With expressions, it’s possible to write code in the imperative style the first example demonstrated. The opposite, writing expressions in terms of statements, is not.

If we agree that “power” means “possibility”, then languages like Lisp, which are based on expressions instead of statements, might be considered powerful.

Homoiconicity

Homoiconicity is a property of a programming language’s syntax, and means that programs in a language are expressed using that language’s own data structures. The property of homoiconicity is key to the way Lisp empowers the programmer to fabricate and manipulate syntax.

Homoiconicity might be understood by exploring the properties of source code and interpretation of that source code in a non-homoiconic language first.

Javascript, while influenced by Lisp in other ways⁶, is not homoiconic, and its popularity, availability, and conventional syntax make it a candidate for exploration.

Implementing Javascript

How a Javascript Interpreter Works

Consider this fragment of Javascript code, which passes the sum of 1 and the product of 2 and 3 to a web browser’s alert function:

alert(1 + 2 * 3);

When a browser passes this code, or data, as a string to its Javascript interpreter, something like the following happens:

The interpreter lexically analyzes⁷ the string, turning it into a stream of tokens. Tokens are objects in source code upon which other constructs are defined, such as function names, operators, and literals like numbers or strings. The tokens in the above fragment might be:
- alert
- (
- 1
- +
- 2
- *
- 3
- )
- ;
The interpreter parses the token stream, attempting, recursively, to match the pattern of tokens to known language constructs. For instance, when the interpreter sees the function name alert followed by (, it knows to expect zero or more tokens that must be succeeded by a closing ).
The interpreter evaluates the constructs it found from the inside out:
- 2 * 3 happens first, because, * has higher precedence than + and because the interpreter knows it needs a value or identifier to pass to alert.
- The product, 6, is returned.
- 1 + 6 is evaluated, returning 7.
- Finally, alert(7) is evaluated, and a message is displayed.

If you were to write your own Javascript interpreter or compiler, you would need to implement a lexical analyzer, a parser, and an evaluator in order to complete the above steps.

Even if you were to implement your interpreter in Javascript, you’d have a long way to go, because none of these functions are provided by Javascript interpreters to Javascript programmers.

Javascript provides the eval function, but it accepts only strings, and you need to create source code strings yourself. Creating source code strings to pass to eval is effectively compilation, and done correctly could be as difficult as writing a compiler.

The task is not as daunting if we take the Lisp approach and build our programs in a data format richer than strings. Let’s meet the problem half way, and invent a Javascript syntax based on Javascript data.

A Homoiconic Javascript Subset: JSONScript

S-expressions

Consider this alternative representation of the code fragment, in a language we just invented, JSONScript:

['alert', ['+', 1, ['*', 2, 3]]]

Unlike the earlier example, which was a string that required multiple phases of analysis to understand and run, the above code is written using data structures native to Javascript: string, number, and array.

JSON, which stands for “Javascript Object Notation”, is a notation for expressing data in terms of Javascript data structures. JSON is expressive enough for us to use it to represent code for a simple programming language.

We could easily write a function called compile_jsonjs that converted this representation into a string that could be passed to eval, because:

We don’t need to write a lexical analyzer or parser: our code is already rich enough to express how it should be evaluated.
compile_jsonjs doesn’t need to know about operator precedence because we’re using s-expressions.

S-expressions, short for “symbolic expressions”, are a convention for writing code that allows us to represent a function call with an array. This convention is also known as prefix notation. The first element of the array is the function, and subsequent elements are arguments to that function that are evaluated first.

S-expressions leave no ambiguity about the order in which functions must be applied. In the original example, the expression 1 + 2 * 3 evaluated to 7 because it’s in the Javascript specificaton that * must evaluate before +.

In JSONScript, we express our intent to multiply first by making ['*', 2, 3] an argument to +.

S-expressions don’t have to be arrays. 42 and "hamster dance" are also s-expressions, because they also evaluate, but to themselves.

Lisp uses lists instead of arrays as s-expressions, but the idea is the same.

Some Implementation Details

There are at least two implementation details we face in implementing compile_jsonjs:

In JSONScript, as in Lisp, there is no distinction between function and operator. Functions, whether they are alert or *, must only appear as a string and as the first element of an array.
- compile_jsonjs needs to recognize functions that Javascript considers to be operators, and return the correct syntax for them.
In Javascript, functions are identified by symbols, not strings. For instance, this syntax is not correct: 'alert'(7).
- compile_jsonjs must return function names as symbols.
- Conflating symbol and string is necessary but has unfortunate implications. For instance, it will be impossible to pass a function name as an argument to a function in JSONScript.
- Adding the ability to pass function names as arguments equires us to go beyond JSON as our source data format, because JSON permits symbol literals only as an object field names.

Building the Compiler

We’re now equipped to reason about how compile_jsonjs will work.

First, we check if the input is an array.
If it is an array, we:
- Compile the arguments
- Check if the first element is an operator like * or +
  - If it is an operator, interpose the compiled arguments with the operator, and concatenate everything into a single string. compile_jsonjs(['+', 1, 2]) should return "1+2".
  - If it’s not an operator, like alert, we return a function call. compile_jsonjs(['alert', 'hello']) should return "alert('hello')"
If it isn’t an array, we return it as a string. compile_jsonjs(42) should return "42".

The Implementation

Next, we can translate our plan into code. We know that compile_jsonjs will need helper functions for:

Testing if an object is an array: This is how we’ll determine at the beginning of compile_jsonjs whether we’re compiling a function call or a literal. Literals are data that evaluate to themselves, like numbers or strings.
Testing if an array contains a particular object: We’ll need to make a list of functions that are Javascript operators, because we must emit different Javascript syntax for them.

The first helper function we need, isArray(), isn’t available on some browsers, and is actually difficult to write in a widely compatible way.

So, we can borrow it from the underscore.js⁸ library:

var isArray = function (obj) {
  return Object.prototype.toString.call(obj) === '[object Array]';
}

Next, we need a function for testing if an object is in an array. Such a function is also not available in some browsers, but we can implement it like so:

var inArray = function(array, item) {
  for(var i = 0; i < array.length; i++)
    if (array[i] === item) return true;
  return false;
}

With these functions in place, we can finally write our compiler:

var compile_jsonjs = function(expression) {

  var operators = ['*', '+'];

  if (isArray(expression)) {

    var func_name = expression[0];
    var func_args = expression.slice(1);

    var compiled_args = [];
    for (var i = 0; i < func_args.length; i++)
      compiled_args.push(compile_jsonjs(func_args[i]));

    if(inArray(operators, func_name)) {
      return compiled_args.join(func_name);
    } else {
      return func_name + "(" + compiled_args.join(',') + ")";
    }

  } else {
    return expression.toString()
  }
}

The full source listing, which you can copy and paste into a web browser’s Javascript console, follows:

var isArray = function (obj) {
  return Object.prototype.toString.call(obj) === '[object Array]';
}

var inArray = function(array, item) {
  for(var i = 0; i < array.length; i++)
    if (array[i] === item) return true;
  return false;
}

var compile_jsonjs = function(expression) {

  var operators = ['*', '+'];

  if (isArray(expression)) {

    var func_name = expression[0];
    var func_args = expression.slice(1);

    var compiled_args = [];
    for (var i = 0; i < func_args.length; i++)
      compiled_args.push(compile_jsonjs(func_args[i]));

    if(inArray(operators, func_name)) {
      return compiled_args.join(func_name);
    } else {
      return func_name + "(" + compiled_args.join(',') + ")";
    }

  } else {
    return expression.toString()
  }
}

Trying it Out

We can test our compiler by seeing what code it generates with our JSONScript fragment:

compile_jsonjs(['alert', ['+', 1, ['*', 2, 3]]]);

And we can evaluate our compiled code by passing that result to eval:

eval(compile_jsonjs(['alert', ['+', 1, ['*', 2, 3]]]));

Going Further

JSONScript probably isn’t a language you would want to use for your next programming project, but hopefully you now have a better understanding of what Lisp is and why it is different.

Further extending JSONScript will help you understand Lisp even more.

You can begin by adding support for other Javascript operators.

Next, you might implement lambda and quote. These will allow you to define functions in JSONScript, and to pass arrays to functions without evaluating them.

Once you have lambda and quote, you can implement other special forms, using Paul Graham’s The Roots of Lisp as a guide⁹.

If you’re feeling particularly ambitious, you might consider adding support for one of Lisp’s most famous and unique features - macros, or functions that:

are run before evaluation
do not evaluate their arguments
return JSONScript code

What Made Lisp Different by Paul Graham ↩
The Roots of Lisp by Paul Graham ↩
Lisp in Small Pieces ↩
Wikipedia: Ternary operation (Javascript) ↩
jQuery Core Style Guide: Blocks ↩
Popularity by Brendan Eich ↩
Wikipedia: Lexical analysis ↩
_.isArray in underscore.js ↩
The Roots of Lisp by Paul Graham ↩

"Choking hazard! This is an expensive puzzle cut to exacting tolerances. Children leaving teeth marks..."

Sun, 13 Feb 2011 19:58:34 -0800

“Choking hazard! This is an expensive puzzle cut to exacting tolerances. Children leaving teeth marks on the pieces are apt to be choked.”

- Bill Gosper

“It has the singularity of outsider art, though the...

Mon, 22 Nov 2010 18:20:48 -0800

“It has the singularity of outsider art, though the conscious rejection of spatial dynamics could only come from an intimacy with the conventions of picture-making.”

An XML Rant

Wed, 17 Nov 2010 19:09:00 -0800

This rant is brought to you by my reaction to Daniel Lemire’s post, “You probably misunderstand XML”

In school I took a class called “Data Interchange” or something, that taught primarily XML and the ecosystem around it. We learned about XSD, RELAX NG, XSLT, XPath, JAXB, SOAP, and lots of other things I thought to be loads of horrendous bullshit at the time. I hated that class.

I made a special effort to go, though. I was on a personal mission to point out every counterexample to, failing of, and argument against XML that I could. ”It’s the illegitimate half-brother of the holiest representation of all time, the S-expression, and it’s slower than shit to boot!” I cried.

I’ve learned a lot since then. The biggest thing I’ve learned is that it’s easy to dismiss any technology with cultural baggage on religious terms. It’s also easy to conflate your hatred of some technology, like SOAP, with some other technology, like XML, that is only loosely or incidentally related. Without assessing pragmatically to yourself whether SOAP sucks because it uses XML, or SOAP just plain sucks, you have not adequately justified your hatred.

The more you work without asking yourself these questions, the more likely you are to commit the cardinal sin of anyone in the computing profession who gives a shit about what they do - use the wrong tool for the job.

What’s much harder, and much more useful, is to take a pragmatic approach to determining a technology’s deficiencies and capabilities. I still don’t do this enough. This was one of the themes of Rich Hickey’s “Hammock Time” talk at the first Clojure Conj.

But it’s not what led me to later realize the legitimate use cases for XML. I digress.

What I later realized about XML as I programmed more is that the intrinsic structure, semi-structure, or non-structure of the data you are working with is only part of the question, and only leads you to a conclusion - well, opinion, mostly - on how to best represent it. The more complicated the domain, the more complicated your opinion, and the hairier the ultimate representation.

As you bang out your implementation, the less intuitive but really insidious part of the question lurks: “Will people in the future working with this thing I created be able to use it and modify it for their own needs? Will they know my intent well enough to improve upon it, or determine if some variant of it is “valid” in the sense that it is true to my original opinion, on which other consumers of this thing may depend?”

For domains that are simple in the ontological sense, it seems really dumb to use XML, because that question doesn’t seem worth addressing.

That’s because you’re confident other people could sit down, read a few your examples, and be comfortable adapting and extending your stuff. JSON and YAML are great for applications that fit this scenario, especially when you don’t have to worry about transport to or from places outside of your control. Like on a web app, when you’re doing Ajax stuff with your own backend.

Sometimes though, you need to transfer data between applications - applications that are coded by different people, who might have different perspectives of the underlying domain that the data being transported is derived from. And that’s when you need to look into XML, because of all the formats out there, it has the most tooling and documentation around writing schemas. XML schemas let you express your understanding of the domain, and how you chose to interpret pieces of it, declaratively, in an almost human readable format. More readable than BNF in my opinion, anyway.

It’s easy to know when you’re doing it wrong. Is your code littered with assertions about the structure of data coming from some outside source? Are there failure cases for your application that can be triggered by malformed data sneaking in? Do you have tons of unit tests around this?

If you do, you might be comfortable. You might feel good. But what about the other guys? If you have multiple developers working multiple code bases, all of which depend on some common interchange format, then the data on Bob’s box running application Q actually depends on the unit tests running on Sally’s box running application Z. You can commit another cardinal sin and duplicate the tests, version and integration-test all of these apps together, or you can suck it up and investigate a transfer format that supports schemas. Depending on your transport and other requirements, this might be XML, or it might be something like Thrift.

Schemas are not the answer to every question, and, like any tool, they can be the wrong one for the job. But in my limited experience, there’s a place for XML and it is easy to overlook because of your own cultural bias.

Sending Small Secrets with Perl

Mon, 15 Nov 2010 22:30:03 -0800

Suppose you’d like to send a short message, like an account number, to a friend, but have no secure way to transfer it and can’t hand the number off in person.

If there’s something that only you and your friend know, and this something in text is at least as long as the secret you’d like to send, you’re in luck.

Using your shared secret, Perl, Base64, and the XOR cipher, you can communicate small secrets securely.

An Example

Alice needs to send a 7 digit account number, like 9876543, to her friend Bob over e-mail. Alice knows that Bob’s first phone number was 555-4241 . To encode the account number using this shared secret, she can Base64 encode the result of XORing “5554241” and “9876543”.

On her computer, she runs this small Perl script:

perl -MMIME::Base64 -e 'print encode_base64("5554241"^"9876543")'

which returns the string “DA0CAgcAAg==”

Next, she composes an e-mail to Bob:

Hey Bob, here is that account number. Run the following command, substituting the asterisks for your first phone number, no area code, and without the dash: perl -MMIME::Base64 -e ‘print “*******”^decode_base64(“DA0CAgcAAg==”)’

When Bob gets the message, he runs the command on his machine:

perl -MMIME::Base64 -e 'print "5554241"^decode_base64("DA0CAgcAAg==")'

which prints 9876543.

alikins

Sun, 29 Aug 2010 20:09:17 -0700

alikins

"The canoe is hollowed out of a single, gigantic hardwood log. When they go stroking out to see in..."

Sat, 21 Aug 2010 19:39:42 -0700

“The canoe is hollowed out of a single, gigantic hardwood log. When they go stroking out to see in their big dugout canoe and you’re sitting outside looking at them paddling towards you, you think they’re coming out with their forks to have you for dinner. They couldn’t speak English and Mike couldn’t speak their language. They paddled by and said something like “Om Gowa Mungie Wung Ow.” Mike smiled and said, “Yeah man, hang ten.” They thought that was great, they went stroking out saying, “Hang ten, hang ten.” The only English word they know is “Hang Ten.” That has to be unique.”

- The Endless Summer

"A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing..."

Sat, 21 Aug 2010 11:42:52 -0700

“A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”
Knight turned the machine off and on.
The machine worked.”

- Tom Knight

"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a..."

Thu, 18 Mar 2010 12:32:19 -0700

“The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. For three centuries, mathematics and the physical sciences made great strides by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties by experiment. This paradigm worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence.”

- Frederick P. Brooks, Jr., No Silver Bullet: Essence and Accidents of Software Engineering

The S-expression Editor

Sat, 13 Mar 2010 06:40:00 -0800

The other week I was reading about Bard, a new Lisp dialect, and ran into this:

“Historically, and in most other Lisp dialects, source code is explicitly or implicitly not text; it is s-expressions. Text is just a print representation of the s-expressions.”

Emphasis added. This got me thinking.

for lisp, text editors are overkill

Good text editors like vim and Emacs are really good at everything having to do with text editing. In fact, they’re so good at such a wide variety of things, that their features wildly exceed the sort of operations one really needs to do when working on Lisp programs.

For instance, even the idea of a “newline” (or any other character the average Reader considers whitespace) doesn’t really have any meaning in s-expression land outside of quoted strings. Everything in the editor about them needn’t be accessible to the programmer.

So, what if instead of accepting text as our source editing medium, we operated directly on data structures? That is, what if key strokes performed some operation directly on the program’s data, and the editor simply pretty printed a nicely formatted representation of the current program following edits?

This is my idea, and I’m not sure it hasn’t been done before.

some pros

Plugins: Plugin functions don’t have to worry at all about dealing with or parsing text. They’re handed the data structure representing the current program (or arbitrary s-expression), along with a function representing the “point” or cursor location. They transform it somehow, and return the new data structure. The point might be stored as a zipper partial.
Visualization: By separating editing from representation, it becomes simpler to develop alternative visualizations. I think there might be a lot of interesting work to be done here, with things like contours, bubbles, and snippets. For some cool ideas along these lines, check out Michael Weber’s Emacs hackery page.
Universal formatting: Since the programmer is no longer dealing directly with shareable, revisionable text, the text visualizer would serve also as the exporter when it came to source control and storage. In the case of Clojure, this would effectively make the *code-dispatch* dispatch table for clojure.contrib.pprint the gofmt of the language.
Evaluation: SLIME-like evaluation for Clojure would be trivial, assuming this editor was written in Clojure.

some cons

Comments: Comments, and anything else in source code normally stripped by the Reader, would be completely lost. This means that any such data would have to be metadata, something which seems cumbersome at best. Maybe not.
Another editor?: Both vim and Emacs, and particularly Emacs with Paredit, have served me exceptionally well when it comes to editing Clojure. I’m not sure a new editor is warranted; but the idea of an editor written in Clojure that takes advantage of STM (for undo) and zippers (for commands and plugins) sounds pretty appealing.

status

I’ve started playing with SWT in an effort to build a prototype. I’ll github it soon. In the meantime, does anyone know if this has this been done before? Are there unsurmountable pitfalls that make the idea pointless? Thanks in advance!

*update*

I learned recently that the INTERLISP programming environment featured just such a structural editor. Code was data, all the way down, and this was the late 1960s. Screen display and output files were pretty-printed serializations. Based on what I’ve read, this capability took INTERLISP the IDE to a level of capability that blows away anything we have today.

The wisdom of the ancients…

go: git precommit hook for gofmt

Wed, 10 Mar 2010 20:27:58 -0800

go: git precommit hook for gofmt :

It’s no surprise I like Ruby, and gofmt is a great idea I wish Ruby could enforce. Instead of forgetting to run it constantly, let’s have git run it. In your .git/hooks/pre-commit:
#!/usr/bin/env ruby
Dir["**/*.go"].each do |go| if File.basename(go) !~ /^_/ puts "gofmt #{go}" system("gofmt...

Ruby with enforced gofmt… ah yes, Python :)

NCSA Mosaic on Github

Mon, 08 Mar 2010 11:09:05 -0800

In 1994, when I was in fourth grade, my dad brought me along with him to see a friend of his in the CS department at the University of Buffalo. My dad’s friend, Bill Rapaport, was running NCSA Mosaic on a Sun workstation. I vividly remember the moment he brought up the Louvre’s website and a beautiful full color image of the Mona Lisa was magically beamed across the ocean from Paris, and onto the screen.

My dad had shown me gopher before, but nothing was ever in color. In fact, everything I’d seen about computers up to that point seemed pretty boring.

The moment I saw the Mona Lisa in full color on a computer monitor was one of only a handful of moments that led me to where I am now, which is a state of continual curiosity and wonder about these things, these machines, these computers.

Thanks in great part to the work of others, I was able to pretty easily get Mosaic to compile and run on my machine, and to relive for a moment my childhood renaissance.

What is the Mosaic, the Mona Lisa, that we can show children today?

If you’re on GNU/Linux-Ubuntu (or something else, and you know your way around your package manager) you can compile and run NCSA Mosaic yourself: http://github.com/alandipert/ncsa-mosaic

Xerox Alto

Sat, 13 Feb 2010 15:35:46 -0800

Xerox Alto

Rich Hickey talks about the Clojure in Clojure project

Sat, 30 Jan 2010 15:33:05 -0800

Rich Hickey talks about the Clojure in Clojure project

Passing Methods like Blocks in Ruby

Sun, 17 Jan 2010 09:30:00 -0800

Ruby’s Functions

Ruby has four flavors of function, each with various nuances: methods, blocks, Procs, and lambdas.

A Simple Example

The object Array has a bunch of methods on it that take blocks. Normally, you write these blocks inline:

[1,2,3].map{|x| x+1} # → [2,3,4]

But what if you have a method you’d like to pass to map?

def addone(n)
  n+1
end
[1,2,3].map(addone) # → Doesn't work

The above example doesn’t work because map is expecting a block. We’re not passing it one; instead, we’re invoking addone with no arguments and attempting to pass the result of that invocation to map.

To get a value representing the addone method, we can use Object.method, which takes the symbol of the name of the method as an argument:

def addone(n)
  n+1
end
[1,2,3].map(method(:addone)) # → Still doesn't work

That still doesn’t work, but we’re close. Map expects a block, but we’re passing it a Method. The key to this conversion is the unary ampersand &, which will convert anything to a Proc that has a to_proc method, and then convert any Proc to a block.

Let’s give it another shot:

def addone(n)
  n+1
end
[1,2,3].map(&method(:addone)) # → [2,3,4]

Voila! The point? This is just another way to consolidate and modularize code. If you find yourself writing the same block over and over, and if it makes sense, you can write a method and reference to it.

Getting Complicated

Here’s a Polish notation calculator that groups operators and arguments as S-expressions, with Arrays:

def evl(exp)
  if exp.is_a? Array
    exp.slice(1..-1).map(&method(:evl)).inject(exp.first)
  else
    exp
  end
end

evl(3) # → 3
evl([:+, 4, 5]) # → 9
evl([:+, 1, 2, [:-, 10, 7]]) # → 6

If the input to evl is an Array, evl maps every element of the Array except the first to itself, and then reduces the resulting Array with the first term, which should be a Symbol representing a binary function. evl takes advantage of the fact that inject automatically casts Symbols to blocks.

This example is different from the one above, in that &method(:evl) occurs inside of evl, which doesn’t actually work in Ruby 1.8.7. It seems to work in 1.9.1, though.

Lazy Sequences in Javascript

Wed, 13 Jan 2010 23:14:00 -0800

I’ve played around a bit more with the Lazy Function Definition pattern I mentioned in my last post, and implemented a Javascript object for creating lazy sequences. Here’s what the fibonacci sequence looks like, a nearly direct port (minus destructuring) of Christophe Grand’s Clojure version:

function fibo() {
  return new LazySeq(
    function(pair){
      return [pair[1],pair[0]+pair[1]];
    },
    [0,1])
    .map(first);
}

fibo().take(10);
//0,1,1,2,3,5,8,13,21,34

LazySeq.map is itself lazily applied, and values are only actually “realized” with either LazySeq.take or LazySeq.nth.

For the LazySeq code, check out the Gist. It doesn’t include my crappy Array.prototype.reduce implementation, but you could easily substitute in Underscore.js’s reduce. Happy Javascripting!