pl patterns

The Question

A skilled sculptor can form any shape. A skilled programmer can make any program. The only question is, what?

I think this rings true with anyone who has spent 10 years in the field. After a certain point, you start to realize, there’s nothing you couldn’t program. Sure, there are challenges. How do you get it to be fast enough? How do you allow it to scale big enough? But at the end of the day, after having faced challenging problems in the past and eventually overcoming them, you begin to realize that it’s no longer a matter of whether you can make it, but more… what’s worth making in the first place?

Paul Graham said, “Once you know what to make, it’s mere effort to make it, and most decent hackers are capable of that.”

No matter what your craft, after a certain amount of practice you become a master craftsman. But the tradition of creating a masterpiece to cross the line from apprentice to master has faded away.

Deep down, we who love the craft still want this. And we wonder, what is worth making?

The result of our work can either be that awful thing in the park no one wants to look at, but has to, or David.

Related: The Purpose
Photo by jasontheaker.

How to Convert a Local Branch in Git to a Remote SVN Branch

This is a little more obscure git-svn recipe I derived today. Thought I would share it.

Basically, I was prototyping a new feature on a local branch in git. Later, I decided I wanted to push that local branch into an svn branch so that my svn comrades could see it. So I started with a local branch following svn trunk with purely fast-forward commits. And the following did the trick.

Create the svn branch.

svn cp <url-to-svn-repo>/trunk <url-to-svn-repo>/branches/final-remote-name
git fetch        # Sync w/ remote svn repo.
git branch -r    # This should list final-remote-name.

Make a new local branch with your feature that follows the new svn branch.

git checkout local-feature-branch   # This is the local branch where your prototype feature is committed.
git checkout -b final-local-name    # This makes the local branch derived from your local feature branch that will eventually become the branch that tracks the remote svn branch.
git svn info     # This will say you are following trunk.
git rebase remotes/final-remote-name

Verify.

git log         # All of your feature commits should be on top, followed by the commit that created the svn branch, followed by trunk commits.
git svn info    # This should now say you are following the svn branch, final-remote-name.

If everything looks good, push all your feature commits to the remote svn branch.

git svn dcommit

You can optionally delete the local feature branch that is following trunk, so you don’t use it by accident.

git branch -D local-feature-branch

Basically all it amounts to is a rebase, with some svn trickery.

So again, all together now…

svn cp <url-to-svn-repo>/trunk <url-to-svn-repo>/branches/final-remote-name
git fetch
git checkout local-feature-branch
git checkout -b final-local-name
git rebase remotes/final-remote-name
git log         # Check your commits.
git svn info    # Check you are following the svn branch.
git svn dcommit
git branch -D local-feature-branch    # Delete old local branch.

I hope someone finds this useful.

Related: How do I make git-svn use a particular svn branch? - Stack Overflow

Blub by Convention (In Defense of Arc)

The entire Arc language is just a few Scheme macros. …Or so the criticism says.

I can’t use Common Lisp. mapcar, lambda, destructuring-bind, etc. These are things I use all the time, yet they have some of the longest, most unnecessary names.

Scheme is the Java of Lisps. define, begin, list-ref, etc. It was seemingly designed to be as descriptive as possible, and in doing so, also became as verbose as possible.

Yes, it’s true that I can redefine all those things. But at that point I’ve created Arc. So if you see the pain of using mapcar and list-ref, then in a nutshell, you see the need for Arc. Period.

In the same way that Perl has functional programming features, but the community and conventions don’t use it that way, which means the libraries aren’t designed for functional code, hindering your use of it, so too are Common Lisp and Scheme hindering. The conventions hinder the use of its full potential.

Lisp is potential. Untapped potential. Arc is an attempt at tapping it.

The blub paradox implies that once you truly get the features of Lisp — first-class continuations, condition-signals and restarts, macros, serialization of code to syntactically valid code — all the imitation features like function objects, exceptions, Ruby’s catch/throw, the C-preprocessor, and serialization to XML are… disappointing at best. Atrociously unusable at worst. This is why Lisp is more powerful than non-Lisps.

But Arc is better than other Lisps because Lisp by definition is flexible. And flexibility is a double-edged sword. You can define anything to be anything — both in a good way and a bad way. Arc was specifically designed to pull out common patterns and be as concise as possible. If it’s true that Arc is just a bunch of macros, then these macros that I would have had to define myself in Common Lisp or Scheme are part of the core language or conventions of Arc. So instead of only me knowing about those macros, all Arc programmers know about them.

Code that does not follow a convention is more difficult to integrate with code that does, so much so, that the fact that libraries exist using a convention is a huge incentive to use the same convention. Additionally, if I write code that does not follow the convention, people who maintain my code inevitably re-write it in their own image. It happens slowly over time perhaps, but inevitably. Every one of those names (mapcar, lambda, list-ref), and dozens more in the core language and standard libraries, is a kludge. But if I redefined them, the first thing someone else touching my code would do is look at it, say “wtf!”, and delete my redefinitions and change everything back to the canonical use. In Arc, on the other hand, instead of my code degrading to the conventions of Common Lisp over time as I move on and others take over my code, it holds the high caliber of the conventions of Arc.

However, if you actually succeed at changing all those kludge names in Common Lisp, you will have improved the language by an order of magnitude. And when you improve something by an order of magnitude, you haven’t made something better, you’ve made something new. (Hence, Arc is genuinely new.)

Basically, non-Lisps are blub compared to Lisp because they limit what you can abstract. However, once you have a dialect of Lisp, there are so few visible barriers to abstraction. Instead, non-Arc Lisps are blub compared to Arc because the conventions adopted by the community — and lack of a ability to change those conventions — create barriers to flexibility, removing one of the very features that makes Lisp so great.

Put another way, non-Arc Lisps are blub by convention. The macros that make Arc Arc are a big deal because they are an attempt to change the convention.

What I am getting at is:

1. Many languages could be better than they are if they used different conventions.
2. It’s damn-near impossible to go against the conventions.
3. Conventions are difficult to change, more of a way of thinking of the community.
4. It’s worthwhile to push good conventions into the core language/libraries, and if you do that, you’re essentially making something new.

This has little to do with Arc, except that Arc is an example where someone (Paul Graham) tried to do #4 because of 1 through 3.