pragmatic dæmonology

Why You Should Care About The 𝛑-Calculus

2012-08-16T16:49:49Z

An acquaintance who is well-respected in the field of machine learning has heard second hand through a friend of mine about my Fury language project, and I'm told that he would like to know why anybody should care about the 𝛑-Calculus [and its cognates] in the field of computer language design. As my Fury language is an attempt to embed a functional programming language inside an abstract machine based on a weird process calculus related to the 𝛑-Calculus, his question is probably worth a journal item to detail my thoughts.

Here goes.

Have a look at the Tiobe list of popular programming languages. In August 2012 as I write this, their list of the 20 most popular programming languages went in descending order as follows: C, Java, Obj-C, C++, C#, PHP, Visual Basic, Python, Perl, Ruby, Javascript, Obj-Pascal, Lisp, Visual Basic .NET, Transact-SQL, Pascal, LUA, Ada, PL/SQL, and MATLAB. All of these languages have one thing in common that I wish to focus your attention upon.

They were all designed originally for executing programs on a single core or central processing unit (CPU).

There are several reasons for that. Many of these languages were designed when single-core machines were typical and symmetric multiprocessing was rarely seen outside the laboratory environment. Most of their designers were familiar with multiuser multitasking operating systems (OS), but these were most often implemented by time-sharing kernels on single-core machines, in programming languages that naturally model computation as a single [interruptible] thread of execution.

Importantly, programs for these time-sharing single-core systems were typically written in languages that model software as a single thread of execution, using inter-process communication (IPC) primitives provided by the OS to communicate between separate tasks, and in some cases to handle interrupts from system hardware.

What these languages did not do very well is deal with any kind of multiprocessing.

And why should they? As I said above, multiprocessing systems were rare and expensive. All the interesting commodity hardware was single-core, plenty fast, and getting faster at such a rate that, for as long as most practitioners alive could remember, the best way to speed up your program was to buy a machine with a faster system clock.

Yeah, well— as you may have noticed, that game is over. The phone in my pocket is a dual-core symmetric multiprocessor. The computer on my son's desk at home has eight [mostly symmetric] cores. Meanwhile clock speeds have flattened, computers aren't getting faster at single-threaded execution like they once did, and if you want code to finish working sooner, then you need to write it so it keeps all the cores busy at once.

With most of the languages on that Tiobe list I mentioned above, that's the opposite of easy, because— they were designed expressly for a world full of single-core machines.

To explain why that makes a difference, I need you to know a little bit of computer science theory. (Don't worry, I won't be breaking out the math symbols.)

Basically, all those programming languages originated as applications of a theory of computation called the 𝛌-Calculus. That's important because the operational semantics of the 𝛌-Calculus— the theory of how a machine operates to evaluate an expression, i.e. to execute a program— assumes a single processor that executes deterministically.

A single-core machine running a time-sharing operating system kernel that handles non-deterministic hardware interrupts can easily constrain that non-determinism within the OS kernel, leaving user programs to continue behaving as if they have a virtual single-core machine all to themselves. A multi-core machine naturally executes programs in parallel, non-deterministically, but it's easy to keep that non-determinism constrained the same way you constrain hardware interrupts. As long as your programs are written so they assume a single deterministic processor that only occasional gets interrupted for interprocess communication, an operating system can be ported without much difficulty to a multicore machine.

This is mainly how the world of mainstream programming languages has been constructed even still to this day. It all goes back to the single processor operational semantics of the 𝛌-Calculus. To get around this effectively, you need a language designed from the start for executing programs that account, at a basic level, in the operational semantics of the language, for the non-determinism of a symmetric multi-core machine.

Put another way, instead of languages that express the execution of instruction flows with the occasional interruption for interprocess communication, we need languages in which computation is the continuous flow of reduction and expansion in communicating process expressions.

There are some languages like that, but they aren't very common right now, and almost nobody uses them. I like to use the word "processual" to describe those languages, in order to distinguish them from functional and other kinds of languages. When I look at the Tiobe list for August 2012, I don't see a language that isn't based on 𝛌-Calculus until I get down to #37, where I find Erlang, which is notable because it's based on an early process calculus, called the Actor model, which only showed up in academic circles in 1973. The progenitors of all those C-family languages in the top 5 at Tiobe were ossified and part of the critical infrastructure well before then.

If you clicked through to the 𝛑-Calculus page at Wikipedia, then you may have noticed that it's a lot newer than the Actor model. Milner, Parrow and Walker only published the really groundbreaking papers after the C language had already been frozen into carbonite by the International Standards Organization (ISO).

The 𝛑-Calculus is an important advancement over the Actor model for two reasons: A) it introduces a "choice operator" (represented as summation in the literature) that allows for reasoning about the behavior of a non-deterministic system of communicating processes; and B) it admits an embedding of the 𝛌-Calculus, which means a one-way systematic translation from a functional language to a processual one is a perfunctory matter.

Are there processual languages based on variants of the 𝛑-Calculus you could try out now? Yes, there are some: JoCaml, Pict, Alice are some examples. None of them are anywhere on the Tiobe list. Erlang is the most well-known poster child of the family, mainly because it's older than all the others. My Fury language is a long way yet from being ready to hold up in comparison to them.

Probably the thing you need to look at right now to see why a symmetric multiprocessing is a such huge problem is the way the Glasgow Haskell Compiler (GHC) provides support for symmetric multicore systems. I don't like to include Haskell in the set of languages designed with operational semantics from a process calculus— because it wasn't: System-F is a typed 𝛌-Calculus— but the GHC team has done something really remarkable in extending the language for symmetric multiprocessing. They did it by extending the runtime system in a way that looks pretty familiar to anyone who has looked under the hood inside a processual language.

What the GHC team did to extend the Haskell runtime for symmetric multiprocessing is impressive, but you still need to use explicit functions that start parallel computations, and the system doesn't help you break problems up into blocks of serialized control flows that can be run in parallel— that, you have to do yourself. Still, the GHC runtime is awesome, and in my opinion, it is hands-down the best tool available today for exercising all the cores you have at once. Now, what we need is a good high-level language that uses that runtime system the way its original architects meant for it.

I hope this essay helps to explain why you should care about the 𝛑-Calculus, and look for it in the programming languages of the future. (I also still harbor the vague hope that my Fury language might be one of them.)

comments

Fury — Important: Name Has Only One 'R' In It

2012-08-16T02:54:12Z

Not two. One.

Processes in Fury do communicate with one another. They do not yif. That is all.

comments

Fury — Unicode Identifiers and Operators

2012-08-01T01:45:57Z

I took a break from my eternal struggle with the Expression Problem to scratch an itch that has been bothering me for a while concerning my prototype implementation of the Fury language: I want source code files to be encoded in UTF-8, so— at the very very least— comments can include characters other than Basic Latin and the Latin-1 Supplement.

That means the lexical analyzer needs to parse Unicode characters.

ZOMG, that means I have to let the Unicode 6.0 standard have its way with me. Unicode is a notorious hive of sin and depravity, and I have not looked forward to getting it all over me. Because I knew— I knew— I would be unable to resist the temptation to add support for identifiers in non-Latin scripts and defining operators with mathematical symbols.

Over the last few days, I started to refactor my existing lexical analyzer, which used ocamllex, to use Alain Frisch's excellent ulex instead. In the process, I vastly simplified it, by reducing the number of different types of token it can recognize down to a very small and manageable set of very general morphemes.

While I was working on this side project, I had a couple of insights I think are worth posting about here.

1. Programming Languages Are Excellent Poster Children For The I18N Problem

Any new programming language that still expects people using it to write all their comments and define all their terms in the Basic Latin encoding is... well, let's be honest: colonialist. Ordinary people whose first language does not use a Latin alphabet— and there are billions of them, I shouldn't need to remind anyone— have grown accustomed to using localized software within an internationalized system for just about everything they do with a computer. Everything but driving a compiler.

It's well past time that programming languages caught up to this state of the world.

The insight I had is that a programming language is both an implementation and a specification of syntax and operational semantics. It's not enough for the implementation to support localization (L10N), the specification needs to support an internationalized view of its user community. For example, my Japanese colleagues should be able to write their application using Japanese orthography in their comments and identifiers, while they make use of frameworks and programming interfaces maintained by other colleagues who are using English, Cyrillic or Chinese orthography.

To do that successfully, I think you need a language that has both A) an internationalized lexical system, i.e. the concrete syntax needs to comprehend all the major orthographies in the Unicode standard; and, B) reasonable support for constraining the syntax at module interfaces and documentation sections so that frameworks can be published in one or more specific locales without limiting their utility in locales for which they have not yet been localized.

This is extremely difficult.

For example, in which locales does the Fury preamble need to be adapted. Yes, English will obviously be the first because it's my native language, but which ones after that? What happens when Arabic or Hebrew lands on the list of locales to support? Do we allow all the directional arrows to be reversed and teach the parser to read right-to-left? Why shouldn't that be okay?

Another crazy problem to contemplate is what to do when displaying source code for a module written in one locale that calls into modules written in one or more other locales. What does it look like when I'm writing in the U.S. English locale and I make a call into a function defined in a module that was only published for Arabic locales?

let c ≔ (مرحبا 5) ⧐ num

Can you read that? Well, I can't read Arabic, but I can read Fury, and what this says in Fury is that 'c' is a freshly bound nym referring to the result of a function named "مرحبا" applied to a constant argument "5" constrained to a numeric type. What makes it hairy is that Arabic is written right-to-left, so function application will proceed in that direction. Surrounding the expression with parentheses makes it easier to read once you know how the Fury syntax is adapted for Unicode bidirectional text.

You may be asking: does this guy really think people want to be typing operators defined as mathematical symbols and identifiers written in orthographies they don't understand just to open a file, read some text, process it and write a new file? I certainly don't think that. A vanishingly small fraction of programmers would be interested in that.

I do, however, agree with the authors of Learning Perl that the principle goal of a programming language designer can be stated this way: "Simple things should be easy, and difficult things should be possible." I want it to be easy to use interfaces defined in a rich orthography that includes mathematical symbols and such, without having to work too hard at typing them. I also want it to be possible for multilingual programmers to use interfaces defined and documented only in strange foreign language orthographies.

This leads to my second insight, because that was where I figured out how to do both.

2. If Your New Programming Language Has No REPL, Then You're Doing It WRONG

There is a terrifying annex to Unicode 6.0 that describes how text has to be treated when used as identifiers and pattern syntax in programming languages. Cursory study of that document leads me to the conclusion that developing multilingual programming frameworks for publication in localized versions is a more general case of the specific problem of making it easy for programmers to use and define interfaces that include the rich variety of mathematical characters in the Unicode database.

As usual, Guy Steele was here first with his work on the Fortress project. One of the things Fortress showed well is that you can define a presentation syntax and a drafting syntax with an automated bidirectional transform between them, and this turns out to be pretty workable.

Where I think that trick really pays off is when you have an interactive Read-Evaluate-Print loop at your disposal. When editing a source file means loading it into an interactive editor that lets you type digraphs (or trigraphs, or longer polygraphs, if necessary) that are presented back to you as the equivalent presentation format text while you are editing it, that's when I think programmers won't mind hacking on code that looks like this:

type t ≔ ∀𝛼 𝛽. [Eq 𝛼, 𝛽 ≥ foo 𝛼] 𝛼 → 𝛽

Suppose you can easily type that same line above like this instead:


  type t := [Eq a, b >= foo a] a -> b

Moreover, when you do type it like that, it appears in the source code file as the former after you save it to persistent storage. Which ideally happens as soon as the REPL reads it, evaluates the definition, compiles it into JIT binary, and makes it available for you to start testing it.

Or not.

Maybe you don't prefer the mathematical symbols that your professor of Wingnut Studies at example.edu insists on using. Maybe you're editing the source code in an editor that only supports Basic Latin. In either case, you turn off the rich text presentation format in your view of the source code. It should be that easy. It really should.

I'd like to believe that it can be that easy. Maybe I'm not alone. So, anyway, that's why I've started to think that I need to implement an interactive shell first, then flesh it out later with a compiler toolchain.

comments

On The Mattering Of Words In Programming Languages

2012-02-28T02:11:24Z

Professor Bob Harper at CMU.Edu is always worth reading, but his post on February 9 cuts especially close to home. (Clearly, I need to buy his book.)

In my hobby project [mentioned previously], I have tended to be fussy almost to the point of obsession with getting my terminology straight. For example, I tried to avoid misusing the word variable in the war Professor Harper has highlighted on his blog. This is why Fury has neither "types" nor "variables" at present; what it has instead are "shapes" and "items" which are each similar to their more common corresponding terms, but they are most emphatically not types and variables as those terms are formally defined by mathematicians. (I'm expecting that Fury will get proper types and variables once I get past the effort to define its basis sublanguage.)

Professor Harper's remarks about references and channels in process calculi are really insightful, and I hope to collect my thoughts on them for a later post. For now, I want to comment about his proposal to use the word assignable to denote the concept that programmers usually call by abusing the word "variable" instead. I have a bone to pick with that, and I hope to use this post to explain why Fury is using the [admittedly weak] "item" instead. [It's not just that "item" is shorter than "assignable" when written out, and therefore makes a good keyword.]

I'd like to start by pointing out that memory allocation, may not actually admit assignment. It could be located in read-only memory or a special purpose register. The data returned by the get operation could be different each time the program executes it. The data written by the set operation could be decoupled from what is returned by the get operation. To model these cases, I've adopted some unusual terminology in Fury.

The shape of scalar word items in Fury includes a pair of qualifiers that convey the reading and writing semantics for the memory occupied by the item. For reading, scalar word items are stable by default, which means that every subsequent get operation is expected to return the same scalar data as the one immediately following initialization or a set operation. Alternatively, a scalar word item can be declared volatile to denote that get operations cannot always be expected to return the same scalar data as previous operations on the same item. For writing, scalar word items are adamant by default, which means that set operations are forbidden, i.e. the item is not "assignable" to use Professor Harper's term. Alternatively, a scalar word item can be declared mutable to denote that set operations are permitted.

By splitting this concept up into a pair of qualifiers, one for reading and one for writing, it's possible to cover the range of possibilities one usually finds in operating system software. For example, a mutable and stable item is one that admits assignment, whereas an adamant and volatile item is one that acts like a read-only hardware status register. Likewise, an adamant and stable item acts like constant program text or data, and a mutable and volatile item acts like a read-write hardware status/control register, or perhaps a storage cell requiring atomic read/write operations for signaling between thread-parallel processing units.

How did I choose some of these words? Well, I knew that "volatile" would probably convey a meaning that programmers would recognize, but what's the antonym? I settled on "stable" because it was short. Likewise, "mutable" is easily recognizable, but what's the antonym of that? I don't like "immutable" because, well, what does "immutable and volatile" mean again? I settled on "adamant" instead, because "adamant and volatile" conveys the proper concept.

In any case, the default for items is "adamant and stable" mainly to give the memory collector room to breathe. It doesn't mean that a reference to one acts like a variable. As Professor Harper correctly notes, just because two items contain the same adamant and stable data, it doesn't mean that references to them are interchangeable. I dreamed up another stupid word to refer to these things that are associated with items but aren't variables (and aren't necessarily assignables either), but I'm running out of room in this post to talk about that.

comments

Peanut Butter Honey Spice Cookies

2012-02-06T03:52:12Z

Leo and I made these together while everyone else we know was watching Superbowl XLVI. Pure awesomeness. The fresh ground peanut butter seemed to make a big difference, so think twice before attempting to substitute.

Ingredients: 1/2 cup unsalted butter, 1/2 cup honey from the farmer's market, 1/2 cup brown sugar [packed], 1/2 cup fresh ground peanut butter from the bulk aisle at the grocery museum store, 1 fresh egg, 1 tablespoon vanilla extract, 2 cups all-purpose flour, 1 tablespoon ground ginger, 1 tablespoon ground cinnamon, 1/2 teaspoon each baking powder, baking soda and salt, rice bran oil for greasing the baking sheets.

Procedure: Beat the egg. Mix the cold butter, honey, brown sugar, cold peanut butter, vanilla extract and the beaten egg in a mixing bowl with a spoon. Be forceful. Sift flour, ginger, cinnamon, baking powder, baking soda and salt together, then stir into the bowl to produce a cookie dough. Chill the dough for two hours minimum. Roll into balls about the size of a walnut, and place them about two inches apart on a baking sheet brushed with rice bran oil. Dip a fork in sugar, and use it to flatten the balls into a cookie shape with a criss-cross pattern on the top. Bake at 375F for 10 minutes.

comments

Still waiting for The Fall of WorseIsBetter™

2012-01-23T01:36:12Z

I have some thoughts about how to design a good general-purpose programming language for contemporary 32-bit and 64-bit commodity hardware architectures, and Fury is my unpublished personal project to explore those ideas. In this post, I'm going to start explaining the elements of what passes for my design theory. Let's get started.

First off, let's talk about the C language family. Much has been written about the many apparent deficiencies of the C language and its various descendants, but there is a reason that C, together with its cognates C++ and Objective-C, have dominated The TIOBE Index since the start of its history. Probably the best explanation for that is the infamous Rise of Worse Is Better essay, by Richard P. Gabriel. The C language, as that essay explicitly argues, is a classic example of the WorseIsBetter™ approach to programming language design, and a lot of the code our everyday lives depend on is written in C, so the way I figure it: you have to be a particularly egotistical bastard to think you can whip out a new programming language and do better— er, worse— on your first try than Kernighan and Ritchie.

On the other hand, the Rise of Worse Is Better is controversial for a reason. It's not obviously true, for one thing. It's also not obviously false. We might need a team of professional philosophers to help us sort out the question.

For my part, I think the WorseIsBetter™ approach to software design is a lot like the "Nobody Ever Got Fired For Buying From The Industry Leader" theory of equipment provisioning. It amounts to a concerted effort to turn software development risk into a negative externality. That works up to a point, usually the point where the whole system collapses in a market failure or an ecological disaster. The value of TheRightThing™ as an engineering approach is that it amortizes those risks by paying to insure against them up front. Maybe you like living without carrying any insurance, but I don't. So, that's why I'm interested in working on finding the TheRightThing™ in a programming language design.

Now, I think the C language and its cognates are pretty damned impressive. They're like the software engineering equivalent of the petroleum fueled energy economy. One person trying to offer up an alternative to C is like your kid sister trying to build a 1:1 scale solar-powered city in her back yard treehouse. Not going to happen, but it's cute to watch her try.

I'm dreaming of a better world here at Pragmatic Dæmonology, so the next post will be about what I think an alternative to the C language should be, given the realities of our contemporary environment. Let me collect my thoughts some more, and I'll write that up.

comments

On The Choosing Of Names For Vanity Programming Languages

2012-01-22T06:24:39Z

I'm one of those sad, old coders who amuses himself by trying to write a compiler for a vanity programming language, i.e. one that probably nobody will ever use, but which scratches an itch in the designer who tries to make it. I've been hacking away at this project for a long, long time— so long, that I'm too embarrassed about it, actually, to even look at the history to see when I created the original repository.

Some people play Sudoku. I write vanity programming languages. Don't hate me because I'm quirky.

I've given this language about four different names so far, and each time, somebody else has published a completed toolchain with the same name before I was even getting something up that could print "Hello, world!"

Very frustrating.

First, it was going to be called π0, but that didn't fly. You'd think that would be a safe choice, but no. Then, I called it Redwood. Also duplicated. So, I thought, hey— Sequoia is a better name, actually. So did Stanford. They would. The current name I'm using is Fury. Any takers on betting I'll get to keep that one for more than a year?

It doesn't help that my employers (a certain formerly stripey-fruit technology company) are especially sensitive about their senior engineers moonlighting on open-source projects, which means I don't get to push my updates to Github or Bitbucket and post announcements on Reddit. When other people search the web for names that are already in use by vanity programming languages, they probably won't find mine. Somebody else will take it, and I'll have to rename again.

Do you have any idea how many obscure and esoteric programming languages are actually kicking around out there? It's shocking. If I have to rename again, I swear I'm going to name it PL/MNBN and say that's an abbreviation for Programming Language / Must Not Be Named.

Anyway, Fury is coming along slowly, but progress is happening. I'm ready to start blogging about it now, so I will probably get significantly more posty than I've been over the last few months. (Assuming my ongoing personal life issues don't evolve into a full-blown catastrophe.) I'll start by describing my goals for the project, which are superficially quite similar to— but in truth very different different from— the goals of projects like Rust, Deca and Clay. I'll also describe what features of other languages have influenced and continue to influence my designs.

I'm having a lot of fun. By posting my designs— but not code— on my Dreamwidth weblog, I hope to avoid trouble with my corporate lords and masters, while simultaneously staking out some territory in the vanity programming language namespace, so that I can avoid the impossible-to-pronounce PL/MNBN.

comments

Personal Life Update

2011-09-08T17:47:18Z

I may or may not have more to say here later to update friends and family about certain difficulties I'm currently experiencing in my personal life, but for now, I would ask everyone: please be patient and open-minded if you hear anything second-hand, especially if you hear anything about me which unsettles you.

Please, don't reach any personal judgments without first speaking with me directly about whatever is on your mind. I'll be happy to respond, either in person or over live interactive media, e.g. telephone, jabber, etc., (but not email or social networks like Dreamwidth) about anything you hear, about which you may feel strongly that I should explain myself.

Also, please don't be surprised if all of my online profiles suddenly evaporate from the Internet one day, without notice, and without any forwarding locators. If that happens, then rest assured: it's just me taking some reasonable precautions to protect my family from potential problems in the future, and not a sign of any kind of unfolding immediate emergency, and when everything gets resolved one way or another, I will come back out and hopefully be mostly like my normal self again.

Thanks, everyone, for all your support and friendship.

comments

More On Mercurial vs. Git (with Graphs!)

2011-03-31T19:11:20Z

Two days ago, I posted a very wordy essay in which I tried to explain why I think Git is badly broken, and why everybody should instead use Mercurial until the Git developers fix it. Okay, I wasn't quite that harsh, but I came close.

People on Reddit complained that my written technical language is too confusing, especially because it introduces new terminology to make its point. They demanded graphs, with nodes and edges and circles and arrows and everything. So, I slaved over a hot graph editor for a few hours, and came up with the two graphs below which I hope will illustrate the problem.

Below, I've drawn a simplified graph of a Git repository change history with three currently defined branches, master, release and topic. Before you Git enthusiasts complain that it's contrived to show an unrealistically bad case of change history complexity, let me assure you this is a simplified example. I have access to a real-world Git repository where there are six currently running release branches and about forty currently running topic branches with several hundred previous branches that have now been deleted from the authoritative server.

Here's the graph. Can you tell me on which branch ab3e2afd was committed? What is the earliest change in the release branch? Where did the topic branch start?

I know. It's not fair. I didn't let you see the commit logs. Believe me, you don't want to see them. They're no help. You'd think the domesticated primates would put helpful clues in them to tell you the answers to these questions, but they never do. Sometimes, even worse, they lie.

A more clever rebuttal to my question is to ask in return, "Why do you need to know?" Let me answer that preemptively: A) I need to know which branch ab3e2afd was committed to know whether to include it in the change control review for the upcoming release; B) I need to know which change is the first change in the release branch because I'd like to start a new topic branch with that as my starting point so that I'll be as current as possible and still know that I can do a clean merge into master and release later; and C) I need to know where topic branch started so that I can gather all the patches up together and send them to a colleague for review.

Much of the craziness that drives Git users to get into heated arguments about "rebase" vs. "merge" is about trying very hard to make sure developers rewrite the history in their local clones sufficiently well that the change history graph on the authoritative shared repository doesn't look like that graph above.

Mercurial users, in most cases, don't have this bizarre urge. Here's why:

See the difference?

Every node in the graph is colored to indicate the name of its Mercurial branch. All the guesswork is gone. You know there was a branch named temp that got merged into release but not master. It's probably marked "closed" now that it isn't needed anymore.

Some of the early work on the topic branch went into temp before merging into the release branch. Later, the release branch merged back into the ongoing topic branch.

All this is possible because Mercurial stores the name of the branch in the changeset header. Git should do this too, and it doesn't. Instead, Git encourages its users to fake up a history that looks "clean" but isn't really accurate.

The saddening thing is that so many Git users seem to have a conceptual block against even recognizing there is a problem here. They embrace the need for historical revisionism that their tools force on them, and they call it a virtue.

I dread to contemplate the possibility of moving a certain large and venerable proprietary operating system source code base out of an old legacy version control system and into the hot new DVCS that all the kids are talking about. I predict I'm going to have to show this weblog posting to a lot of people.

comments

Why I Like Mercurial More Than Git

2011-03-29T18:39:05Z

After working for over a year alternating between two projects, one that uses Git for its version control and another that uses Mercurial, I have finally achieved sufficient mastery of both toolchains that I now feel comfortable defending my judgment that Mercurial is the superior of the two systems. I think Git has one glaring deficiency that makes it the inferior tool, and I hope to describe the required remedy in this weblog posting.

The tools are very similar, and many of the distinguishing differences come down to a matter of taste in my opinion. Some may consider it a deal-breaker that Mercurial expects its extensions to be written in Python, whereas Git admits extensions written in just about any language you care to imagine, but the usual approach is to write them in a shell language. That's not a deal-breaker for me. Many other differences are either consequences of that fundamental distinction, or they are cosmetic in nature. It also bothers me not at all neither that Mercurial has no index, nor that Git has the index. The difference between the Git stash and Mercurial patch queues is similarly trivial to me.

The big difference, the deal-maker for me, is in how each tool goes about meeting the fundamental requirement for any version control system: how it handles source code merging. Quite simply, Mercurial is better at merging than Git.

I need to introduce a bit of terminology here to make my point. Because the literature for Git and Mercurial use the word branch to mean crucially different things, I'm going to avoid the word here entirely so as to prevent confusion. For the concept described in the Git literature with the word branch and in the Mercurial literature with the word head, I shall use the word lineage. I shall use the word family when referring to the concept the Mercurial literature uses branch to describe, which is a name that distinguishes a related set of lineages.

Mercurial is superior to Git because it records family history in the repository, while Git does not. In every other significant respect, a Git repository stores the same information as a Mercurial repository. This is why it is possible to convert a Git repository into a Mercurial repository then back into a Git repository without losing any information. It is not possible to perform this round-trip starting with a Mercurial repository (in the general case) because the family history must be discarded in the conversion to Git. (In the conversion to Mercurial, the entire Git repository can be regarded as one monolithic family, and indeed this is how the excellent Hg-Git tool presents its Mercurial view of Git repositories.)

It turns out that having the family history recorded in the repository— and thereby copied around with clones, pushes and pulls— is really important when reviewing the history of a project. A hint of this importance shows up in the cultural difference one observes between Git and Mercurial users.

Among Git users, it's common to see people arguing vociferously that proper workflows involve judicious use of the "rebase" command to reduce the incidence of merging in the repository history. This is because Git only records the lineage of every change, not its family. When all you have to review in the history of a change is its lineage, you don't want to be distracted by a lot of merges between different lineages in the same family. In a Mercurial repository, because the family history is recorded in the repository with every changeset, the urge to keep every lineage pure from ancestor to descendant isn't quite as strong.

In any sane Git workflow, there are two different ways to join a pair of divergent lineages, "merge" and "rebase," and you'd better choose the right one at every opportunity or your whole team will lose valuable momentum dealing with their frustration with your bad version control hygiene. Always use "rebase" when the lineage in your local clone is divergent from the lineage in the upstream, i.e. more authoritative, clone. You do this so that the upstream clone can do a "fast-forward" merge when it pulls your change. It's important in Git for the merge not just to proceed without conflict; it must be a fast-forward merge in order to keep the authoritative lineage "clean" of any evidence of your divergence.

Basically, what's going on here is that Git encourages its users to adhere to a convention whereby lineage and family are equivalent concepts. This leads to an aesthetic concern for "clean history" where every merge of two or more lineages is a record of the merging of the families corresponding to the lineages. Any family with more than one lineage has a "dirty" or "unclean" history. Figuring out the family history of any change in a Git repository where developers have not strictly adhered to this policy means a lot of guesswork. Consequently, some Git repository administrators set flags that enforce this convention, which leads to further confusion among users. "Why can't I push? Oh, you mean I should have rebased instead of merging? Foo."

If you have a fetish for clean pedigrees, or you are using the Hg-Git bidirectional bridge, there is the standard "rebase" extension. It allows you to adopt a workflow that minimizes the incidence of merging between lineages in the same family. There is, however, not any compelling reason to do so: the repository retains the family history. It's easy to review which changes belong to which family whatever lineage they may have. Mercurial users therefore have no reason to be particularly diligent about maintaining "purity" of lineage histories, as Git users do.

I wrote at the outset of this article that I believe Git should be improved to remedy the deficiency I'm describing here. There are couple ways it could be done. One way would be to adopt Mercurial's style of annotating every node in the graph with a family name. Another way— perhaps a more straightforward and "git-like" way— of dealing with it would be to annotate every edge in the graph with the family name (derived from the branch name of the ancestor node in the repository where the commit occurred). You'd probably need a distinguished name for the case where the family history is lost to antiquity.

In any case, this is my argument for why Mercurial is superior to Git. You're welcome to your opinions, of course, but this one is mine. I'm open to persuasion that I'm DoingItWrong™, but it took me a long time to arrive at my judgment here, so please think through the arguments you want to make to me before you comment. Thanks.

[Note: this article has been revised for clarity since its initial publication. The original draft improperly assumed the reader has a familiarity with Mercurial "branch" semantics. Some redundant assertions have been removed.]

comments

IPv6 Doesn't Have As Much Address Space As You Think

2011-02-12T03:12:32Z

Here's how I know I'm reading something about IPv6 that wasn't written by an expert: it contains a line somewhere in it that spells out exactly how many addresses can be represented in 128 bits. Hint: it's a galactic size number, and people who quote it to you usually want you to believe that such a large number of addresses couldn't possibly be exhausted as quickly as the comparatively smaller range of IPv4 addresses. Sometimes, they even try to boggle your mind with analogies involving how many addresses per gram of matter in the solar system, etc.

Well, I'm here to explain why those people need to put on their thinking caps and cogitate a little harder. The IPv6 address space is finite and it's NOT consumed one address at a time.

Sure, the address space in IPv6 is a lot larger than in IPv4, but that space isn't used the same way. Here's the thing: when you've got only 32-bits in a nice flat allocation space, the temptation to start encoding information in your IP addresses is pretty manageable. People just don't try to do much of that because there aren't really a lot of bits with which to do it. Not much information can be encoded in the spare bits of a 32-bit IPv4 address.

With IPv6 addresses, on the other hand, there's a very real temptation to start encoding things in various subfields of the addresses. And the IPv6 addressing architecture is probably the first place where you see that happening. Most IPv6 addresses are divided into a 64-bit network identifier and a 64-bit interface identifier. The network identifier can be divided further into fields assigned by the RIR, then by the LIR, then finally comes the subnetwork identifier.

There are working groups inside IETF that have succumbed to the siren call to encode information in the bits of IPv6 addresses. Teredo, 6to4, IRON and NAT64 are some examples of protocols that embed IPv4 addresses in bits carved out between a short prefix assigned by IANA and the subnet identifier. The Host Identity Protocol wants to encode cryptographic material in IPv6 addresses using a protocol called ORCHID. These are just the IETF efforts I know about that eat surprisingly large blocks of IPv6 address space by encoding things into subfields.

I predict once the vast teeming masses of Internet application developers really start cranking on IPv6 adoption, the street will find many new and interesting uses for that large address space, and the Internet registries will be inundated with demand for blocks of sufficient size to support their designs. Once you start trying to cram useful information into IP addresses, you pretty quickly discover that the number of available addresses isn't as galactic as those news articles and blog posts you're reading would like you to believe. Now, I feel certain that the experts at the NRO and the regional Internet registries know all this, but I suspect the rest of the Internet engineering community is developing some unhealthy misconceptions as interest in IPv6 spreads.

So... people... please stop gushing about how it's "inconceivable" that we might ever exhaust the free pool of IPv6 addresses like we've now run out of free IPv4 addresses. It's pretty easy to conceive how it could happen, and it would be a good idea to bear that in mind when developing your address plans.

comments

Evaluation Strategies

2010-12-18T08:06:01Z

When you're designing a new systems programming language— as one does when one is a systems programmer who has reached a certain age without having done anything to contribute to the academic literature— one of the first decisions you need to make is to choose an evaluation strategy.

Novices often choose eager call-by-sharing without considering other options. It's the strategy used by all the major programming languages in use by practitioners everywhere, and if it was good enough for the language in which you're going to write your interpreter, it ought to be good enough for the language you're designing, right?

More experienced language designers— usually the ones planning to write a compiler rather than an interpreter— are often aware that several different eager evaluation strategies are available, e.g. call-by-reference, call-by-value, etc., because they've seen them in other languages besides the one they're going to use for writing their compiler. Traditionally, these designers are drawn toward call-by-value because that's the evaluation strategy in most machine languages.

Long the domain of advanced language designers only, the realm of lazy evaluation strategies is becoming more well-known now with the increasing popularity of languages like Haskell. (Once again, the Knights of the Lambda Calculus were there first with the S programming language.)

However, if you're a crazy language designer— and who isn't?— then you want to reach into the big happy fun bag of non-deterministic evaluation strategies.

Why? Because in the not too distant future, pretty much all the interesting hardware platforms where you might want your code to run will be multicore shared-memory machines, and every last one of those evil critters is just an everlasting gobstopper of total bugfsck non-determinism. We're all going to need better programming languages soon, because lowering a deterministic evaluation strategy onto non-deterministic stock hardware is like flying a nuclear-powered zeppelin into the Hindu Kush: technically possible, but probably not a worthwhile expenditure of wealth and natural resources.

Spinlocks and mutexes and semaphores, oh my zomg, you just don't even want to know the full horror. Trust me.

Turns out researchers have been playing with non-deterministic evaluation strategies for a long time. Practitioners almost never get to play with them. The languages based on them are exceedingly obscure, but you can get libraries that encode "explicit futures" for most of the popular languages with practitioners, but that's like telling a Haskell programmer that you can get lazy evaluation in C++ with a template library.

Keep an eye out for lightning bolts after you roll that apple into their party on Mt. Olympus.

But even the Ancient and Illuminated Order of the Starry Monad do not have implicit futures or promise pipelining. And they will not get either of those any time soon. Their whole language has the deterministic evaluation strategy baked into the cement foundations of the Spineless Tagless G-machine. Same problem with Erlang, whose designers did the same thing to the Actor model.

I like the idea of call-by-future evaluation, but it strikes me as overly eager. I like what call-by-need can deliver as a deterministic evaluation strategy, and I want the moral equivalent in the realm of non-deterministic strategies.

I think what I want is something I'll call the call-by-contingency evaluation strategy, where computation of a future value only begins when an algorithm similar to strictness analysis— which I'll call entailment analysis for lack of a better name at the moment (yes, I'm aware that phrase means something else outside computer science)— reports that an action contingent on the resolution of the future is entailed.

I further want call-by-contingency by default, and I want the programmer to be able to refine contingencies by annotating expressions with explicit entailments, just like Haskell programmers can explicitly force values to head-normal form.

My problem, of course, is that the literature on the call-by-contingency evaluation strategy and entailment analysis for promise pipelining doesn't currently seem to exist.

Oh my. I may have sailed off the edge of the world.

comments

Not Slagging On Programming Languages

2010-12-10T17:38:07Z

Oh, here is a fun coder meme. I think I'll play along. What's the nicest thing I can say about every programming language I've ever used?

Presented in roughly chronological order, as I can remember them:

Data General Business BASIC: Mostly compatible with the variant of BASIC that David Ahl used in BASIC Computer Games, and will forever remind me of the characteristic odor of freshly punched paper tape and a warm ASR-33 teletypewriter.

6502 Assembly: Can be transcribed by hand into machine code and loaded with the keypad of a KIM-1 microcomputer by a semi-obsessive nine-year-old without too much difficulty.

Apple Integer BASIC: Toss up. A) Fast. B) The REPL doesn't require loading from audio cassette tape. C) One of the few languages in which I never found an error in the interpreter/compiler.

Applesoft BASIC: Mostly capable of representing floating point arithmetic operations.

The Apple Pascal system: More than just a programming language, it's an entire alternative operating system. Also, an excellent introduction to sadomasochistic bondage and discipline for young teenage boys.

HP Pascal/iX: An excellent language for exploiting the MPE operating system for tactical advantage over one's classmates in an undergraduate Computer Science for Jocks course.

MS/DOS Batch file: With judicious use, can occasionally be used effectively to save typing at the MS/DOS command prompt.

K&R C: Doesn't even try to pretend at type safety.

make: A surprisingly lightweight and efficient domain-specific language for modular software construction projects compared to almost all the alternatives developed before or since.

ANSI C: The language of what should be regarded as the single most important module of source code ever written: route.c, the BSD network routing table.

FORTRAN 77: Capable of representing floating point arithmetic correctly. (Also, one of the few languages in which I never found an error in the interpreter/compiler.)

C shell: Marginally better than the MS/DOS Batch file language at reducing the workload of typing input at the Unix command prompt.

Bourne shell: A) More reliably available in the Unix search path, and B) compatible with cross-platform scripts than any other shell language interpreter. Finally, C) it has a fairly concise syntax, which discourages most average specimens of the dominant species of domesticated ape on this planet from trying to decipher and modify any programs you write in it.

C++ (GNU Compiler Collection v1.x): When you find an error in the compiler, the opportunity to attempt to fix it yourself is always available.

Perl (5.x): If you don't like the syntax, then you're invited to create one of your own.

C++ (ISO/IEC 14882:1998): All the proof anyone should ever need that the world desperately requires the creation of something like the Industrial Workers of the Worldwide Web (IWWW)— "the longer the picket line, the shorter the strike!"— so that programmers everywhere can join together and fight the injustices perpetrated by the cultural hegemony of programming labor management, and thereby save succeeding generations from the scourge of the ALGOL family of programming language syntaxes, which countless times in our lifetimes has brought untold sorrow to humankind.

Java (J2SE 1.2): For those poor benighted coders who have been traumatized by their repeated exposure to previously developed instances of ALGOL derivative languages, Java is an excellent and timely introduction to the wonders of accurate garbage collection— 36 years after John McCarthy invented it.

C99: At the time of this writing, C99 remains the only high-level language in which it is possible to write a hardware interrupt handler without soiling one's professional reputation for pragmatism in the craft of programming.

Objective Caml: Superior to Standard ML in every way. Also, written by tenured French academics whose first reflex on seeing some new and interesting piece of running compiler technology is always to say, "It's nice seeing it work in practice, but how does it hold up in theory?"

Scheme (R5RS): Antiquotations are easily defined and used, owing to the fact that Scheme is a Lisp, and Lisp has a syntax so thin as to be almost entirely invisible— except for all the ticks and parentheses.

Haskell (GHC 6.10.x): The look on your coder friend's face after they see the statistical performance comparisons by language, and then you say to them, "It has no directly mutable variables and you have to use a monad to do any I/O." It's like that scene in The Matrix where Morpheus offers Neo the choice between the blue pill and the red pill.

OMake: By dispensing with the need to remain compatible with make, while retaining most of the syntactical features that keep it lightweight and efficient, OMake is able to fix all the stupid and annoying problems with make that made abominations like autoconf, imake, Apache Ant™— and practically anything included in a system with the word studio or environment in its name— seem like a good idea.

Twelf: Easily the most esoteric programming language that I would say was worth the time and energy I needed to learn it.

What's the nicest thing you can say about every programming language you've ever used?

comments

In Praise Of Executive Pragmatism

2010-12-08T01:33:38Z

Over at TalkingPointsMemo.com, ~~Josh Marshall~~ David Kurtz watches the President of the United States announce to God and C-SPAN that he really is a champion of center-right compromise, and not someone who wants to be seen "really thinking about ideal positions," and decides that this is A Seminal Moment.

What we saw and what I think we'll see borne out by subsequent events is Obama revealing in a very public way the choice he has made between the two political personas he has simultaneously inhabited throughout his candidacy and his presidency. He has tried to be both pragmatist and progressive savior. And even when he stopped trying to be the savior after he was elected, he was at a certain level content to let supporters continue to project that persona on to him.

Today, he very clearly and loudly said: that savior persona is not me. I am the pragmatist. And you know what, I don't have a whole lot of patience for the idealists. I share their ideals, but I don't share their approach and I'm not going to get bogged down in recriminations over not living up to some abstract ideal.

I have to object here.

The President may not want to be viewed as the person we all recognize in that iconic Shepard Fairey print anymore, but he's got a long row to hoe before he's going to qualify as a good pragmatist.

Let's do a bit of academic review. Pragmatism is a philosophy related— but not identical— to utilitarianism, only pragmatism has more of an emphasis on epistemology. It says that the truth of an idea can be measured by the reward obtained by making practical use of it. Carrying a pragmatic approach to the truth into the realm of moral philosophy is where the relation to utilitarianism arises, for its posits that the truth of a moral proposition can be measured by the welfare to society obtained by the practical application of it in questions of moral judgment. There's more, but I think that will do for now.

With that in mind, it's my opinion that the President is a lousy pragmatist. I would say his progressive critics have generally had empirical evidence on their side when presenting the pragmatic argument for their policy preferences. His conservative opponents are the ones rejecting all pragmatic arguments in favor of what I will charitably describe as idealistic demagoguery aimed to serve only the interests of the narrowest and most privileged of their partisan constituents.

The President made a special point of describing the so-called "public option" policy proposal from this year's health insurance reform debate as a "purist position" useful only for making us "feel good about ourselves and sanctimonious about how pure our intentions are and how tough we are," but it was the pragmatic alternative. A sanctimonious purist would have insisted that nothing less than wiping out the private health insurance industry in one fell stroke of the signing pen would suffice. It was pragmatists— in the opposing party, no less, before they were driven away by a wave of irrationality that still seems not to have crested— who original proposed the so-called public option.

The capitulation on the public option was only one of the President's landmark failures in pragmatism. A pragmatist would have given more weight to the pragmatists on the CEA who told him that the 2009 stimulus needed to be much larger. A pragmatist would have recognized that the war in Afghanistan is throwing good blood and treasure after already unacceptable losses, and he would have found a practical way to wind up the U.S. deployment of military resources by now. A pragmatist would not be ordering the Department of Justice to defend his unlimited power to kidnap and assassinate anyone, anywhere in the world, including American citizens, without any judicial oversight, even after the fact— in a word, he wouldn't be demanding executive impunity.

Because it isn't practical to expect the grant of executive impunity to result in any improvement to the overall welfare of society, c.f. my earlier discussion about the meaning of the word pragmatism.

If the President wants to proclaim his undying devotion to the philosophy of pragmatism, then I'm here to encourage him to do so. However, I have yet to see any evidence that the President is any kind of pragmatist. He is certainly neither the hero of the working class that many progressives may have hoped he would turn out to be, nor the great pragmatist philosopher-king that liberal scourges of the progressives— like ~~Josh Marshall~~ David Kurtz at TalkingPointsMemo.com— are still hoping against hope that he'll turn out to be. In fact, it would be his conservative opponents who, by the actions if not their words, would seem to have the most accurate appraisal of him. No, he's not the bearded Marxist that Glenn Beck viewers think is threatening the preciousness of their bodily fluids by merely being Black in the Oval Office. If you look at what his opponents do, and not what they say, it's clear that they view him— quite rightly— as a punk. Somebody they can kick around, ruthlessly and without mercy, and who will reliably keep coming back, again and again, asking for another go.

From my viewpoint, the President is merely Yet Another Senator Who Should Have Retired From Public Service Rather Than Run For Higher Office [YASWSHRFPSRTRFHO]. The sooner we get a real wave of pragmatism to wash over the U.S. capital, the better.

Alas, I expect to be waiting a long time for that.

Update: In an earlier revision of this essay, I mistakenly attributed the views of TalkingPointsMemo.com's Managing Editor, David Kurtz to the name at the top of the masthead, the Editor and Publisher, Josh Marshall. I regret the error.

comments

Concurrent, Parallel, Real-time Garbage Collection is HARD

2010-12-05T07:40:54Z

At least, that's what I'm gathering from searching the literature on the subject [Postscript].

The Glasgow Haskell Compiler purports to have one, but opinions differ about how good it is. If you're a Haskell partisan, it's the best thing that's ever been. If you're like me, however, then you might want to set the bar a little higher: it needs to be good enough to scale up to around sixteen cores (or more) and it better not be exorbitantly costly on a uni- machine. I'm not sure the GHC people have shown us the best that can be done.

I mention this here, now, because I'm toying with an approach to this problem space that I now believe hasn't been tried by anyone else yet. (My hobby project language is vaguely similar to ML at the level of its runtime system, so this is what drives my interest in the subject.) I've studied both the Glasgow Haskell Compiler and the Doligez-Leroy algorithm, and I think I can see some ways to improve on them both. Without going too far into the weeds— and running the risk of embarrassing myself by talking too much like I know what I'm doing, when I'm hopelessly clue deprived— I'll just drop a short note here to describe what I'm investigating. Later, I'll post in more depth what I've discovered.

The basic idea: use Cheney-on-the-MTA as the creation space in application threads, then promote to a shared heap that uses a generational copying collector, and use a Baker's Treadmill for allocating only the "large" objects and any objects with language-mutable reference fields, which in my language should be the exception to the general rule. I don't know whether this will work very well, but I'm pretty sure nobody else does either. Maybe I'll get enough time to be the first one to figure it out.

Update: Okay, after a bit of futzing around, I think I need to refine my basic idea further. I'm going to have updatable closures everywhere, so reserving the Baker's Treadmill for the mutable fields basically makes the copying collector not terribly interesting. For the shared heap, I'll probably go with a generational variant of the Huelsbergen-Larus algorithm, but I'll still use the Baker's Treadmill as the oldest generation, and for allocating "large" and "foreign" objects. I suspect that will work very well.

comments

Coming From Vox.com

2010-09-13T19:04:12Z

Thanks to ckd, I have a trial account here now. This is to replace my account on Vox.com.

I have pseudonyms elsewhere, and it's not hard to connect them to me by examining my social network, but I would ask you not to do that unless you have a compelling reason to do so. If you're one of my friends, then you're probably better off following me at one of those places, rather than here, because you're unlikely to see anything here that you don't already know about from following me elsewhere.

I plan to use this journal for promoting my fiction and anything else I'd like the great Internet overmind to remember with my name attached to it for posterity. As a result, it's unlikely to be a place where I post frequent updates about my idiosyncratic observations on whatever random bullshit is the popular obsession at the moment. I'm currently using Twitter for that, and you'll note that's not a publicly accessible feed.

You may also be interested to find my public profile on LinkedIn. I also have a personal information profile at Verisign Labs. What you will not find here is anything at all related to my employers. Just to be explicit about it: I do not represent them, and everything I write here is my own viewpoint and must not be attributed to my employers past or present.

comments