David's Blague

A newly-discovered (by me, at least) favorite feature of my favorite Perl module: Jifty gives me a nice, easy Ajaxy way to canonicalize (read: make it lowercase) and validate (read: check for uniqueness):

package Testy::Model::Test;
use Jifty::DBI::Schema;
use Testy::Record schema {
    column a => type is 'text';
    column b => references Testy::Model::User;
};

sub canonicalize_a {
    my ($class,$a) = @_;
    return lc($a);
}

sub validate_a {
    my ($class,$a) = @_;
    my $unique = Testy::Model::TestCollection->new();
    $unique->limit(column => 'a', operator => '=',
                   value => $a);
    $unique->limit(column => 'b', operator => '=',
                   value  => Jifty->web->current_user->id);
    return (0, "You already said $a") if $unique->first;
    return $a;
}
1;

Basically, this code automagically converts the input to lowercase (AJAX call), then presents my error message if the person has already typed in that value for a.

Plus, it's all done with as little back-and-forth as I can imagine.

Wow.

I love Perl 6, because it's well on its way to solving all my problems with Perl, and a very large collection of others.

I love Perl 6 because it's not stopping at fixed problems or parity with other dynamic languages.

I love Perl 6 because it's not owned by one flawed personality, but instead by an entire flawed community of personalities.

I love Perl 6 because it's Perl. Except more so. Yet it's not too proud to be other languages if it needs to be.

I love Perl 6 because it's not going to be here until it's ready, and it's not going to be ready until it's good, and it's not going to be good until it's here. And I'm using it anyway, so put that Gordian Knot in your pipe and smoke it.

I love Perl 6 because it feels like trading my Perl 5 hammer for the Perl 6 Leatherman. Which is nice since I occasionally treat problems as a screw or a pipe. Of course, I'll probably still keep the hammer around for nails.

I love Perl 6 because I now get to learn Perl all over again, and I can still use it in the meantime.

I love Perl 6 because it can be readable by humans who do not necessarily speak Perl.

I love Perl 6 because it's the Perpetually Emerging Revolutionary Language.

I love Perl 6 because.

A few weeks back, I posted some thoughts about full stack development. The short version: full stack has its uses, but I'm not a huge fan. I inadvertently left commenting enabled on that post, and Jesse Vincent (as if he weren't already busy enough without responding to my FUD) made a thoughtful, cheerful response:

...or if it's not fast enough or pretty enough, the framework can be improved and all sorts of applications can benefit ;)

Good point. And Jifty (Jesse's full-stack system of choice- e.g. he's the author) is changing my mind about a lot of things. Some of my favorite things about Jifty so far:

1. Template::Declare. I've used (and liked) Mason, HTML::Template, Template::Toolkit, and a few others in production, and they all share something in common: they allow you to mix markup and logic. Well, Template::Declare has shockingly ended all that by eliminating the markup from the equation. Eek! I may never write markup again. Hope I can do everything I need to in CSS...
   
2. Jifty::Dispatcher. Dispatching is another difficult problem for which there are a few reasonably good solutions. But I've never used one as intuitive and powerful as Jifty::Dispatcher. Together with Jifty's native ability to do continuations, performing tasks like selectively requiring a login have never been easier.
3. Jifty::Plugin::*. I'm a bigger and bigger fan of mix-ins as my design pattern of choice when creating a web application. Jifty's Plugins are obscenely easy to use (add a line config.yaml), and not as obscenely difficult to write as one might expect. Good plugin architecture is one of the reasons I've used CGI::Application in the past, and I think Jifty made all the same right decisions.

It's not all candy and roses, but I think it's headed that way. Jifty still wants more $hype, more documentation, and fewer bugs, but those things will all come with time and use. In the meantime, it's nifty and getting niftier.

So, Jesse: mea culpa. I think the system is great and getting better.

Labels: development, software

Here's a 1983 Definition of Cellular Automata that I don't like:

Cellular automata are mathematical idealizations of physical systems in which space and time are discrete, and physical quantities take on a finite set of discrete values. A cellular automaton consists of a regular uniform lattice (or “array”), usually infinite in extent, with a discrete variable at each site (“cell”). The state of a cellular automaton is completely specified by the values of the variables at each site. A cellular automaton evolves in discrete time steps, with the value of the variable at one site being affected by the values of variables at sites in its neighborhood on the previous time step. The neighborhood of a site is typically taken to be the site itself and all immediately adjacent sites. The variables at each site are updated simultaneously (“synchronously”), based on the values of the variables in their neighborhood at the preceding time step, and according to a definite set of “local rules.”

My reasons for not liking it have to do not only with the metaphors used (space, time, physical quantities), but also with the overall approach as signified by phrases like "mathematical idealizations of physical systems." Not only is that not necessarily the case, but also it obfuscates the usefulness of these models.

I've tried writing a hundred different short definitions of cellular automaton, and never gotten it quite right. Here's a recent not-quite-right:

A cellular automaton is a model. It consists of a grid, with a discrete variable in each location on the grid. This is called a cell. The state of a cellular automaton is completely specified by the value of each cell. The neighborhood of a cell is all those cells adjacent to it on the grid. A cell is updated based upon the values of its neighborhood, according to a set of rules.

Still working on making it shorter and clearer.

The Principle of Computational Equivalence is unnecessarily weak. Wolfram stated it thus:

Almost all processes that are not obviously simple can be viewed as computations of equivalent sophistication.

To begin with, "Almost all" doesn't mean anything. Nor does "obviously simple." Here is an alternative conjecture with the meaningless modifiers removed:

All processes can be viewed as computations of equivalent sophistication.

Tell me what's wrong with that.

Everything in the universe (including, and perhaps especially, the universe itself) can be viewed as a computation. All processes in the universe- even those that are "obviously simple" are, or at least can be viewed as, irreducible computations.

The mathematical idealizations that approximate these processes are exactly that: idealizations and approximations.

Having completed committing my talk from the emerging technology conference to pixels, here it is in all its glory, such that I can now move on to the next project. As always, send me an email if you have questions or concerns about any of my hypotheses:

1. Introduction
2. History
3. Mechanics
4. More Mechanics
5. Perl 6 Code
• Rules
• Grids
• Automata
6. Fitting Curves
   
7. Further Inquiry

In my next segment, I'm going to try to make a better determination of whether a cellular automaton running simple XOR rule like the one in this paper can sustain computational universality on a finite grid.

Wish me luck!