There are quite a number of blog posts out there that posit variations of idea that Git has mutable history. For example, Patrick Thompson, in a post about Git versus Mercurial, says, “git provides you with tools to go back in time and edit your commit history.” Dustin Sallings, in a similar post, says, “The culture of mercurial is one of immutability…. git is all about manipulating history.”
Well, this isn’t quite true. It may look like this at first glance, because Git has the unfortunate property of hiding its clean interior behind a rather messy and inconsistent user interface, but a closer look will give us a better understanding of what’s really going on.
On his blog Good Math, Bad Math, Mark Chu-Carroll tried to answer the question What is math? He’s rather lyrical, going on about music being mathematical and so on, something with which I used to agree wholeheartedly. But the comments were interesting and eye-opening.
There’s a great deal of back-and-forth about how mathematical music is, and whether the math found in music is interesting.
In comment 3, woupiestek writes:
François Berenger recently brought to my attention a relatively new systems programming language called Go, a project started a couple of years ago by Robert Griesemer, Rob Pike and Ken Thompson. With luminaries like this designing it, this is certainly going to be something to keep an eye on.
It’s got a somewhat C- or Java-like feel, but tries to give the ease of programming you get from Ruby or Python. As they say in the FAQ:
Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing. Finally, it is intended to be fast: it should take at most a few seconds to build a large executable on a single computer.
In a recent TSAC meeting, Travis brought in rather interesting little problem: parsing Roman numerals. It’s more difficult than it looks, at least if you want to write beautiful code.
In a change from things beautiful, here’s a post about something not-beautiful. A recent message on the Haskell web-devel list asking about the meaning of the word “gateway” triggered this rant.
CGI stands for “common gateway interface,” and is basically:
a web server invoking another program,
with a specifically defined set of environment variables set to various values related to the request and the program’s location in the filesystem,
communicating further information via sending it to the program’s stdin, and
receiving a header and body response on the other end of the program’s stdout, which it then may process before returning it to the HTTP client.
I don’t know how old it really is, but certainly for the last decade at least, since the rise of perl and Java, there’s been a constant debate about “static” versus “dynamic” typing systems.
I’ve seemingly flipped back and forth myself. I spent the ’90s doing things like tcl and perl hacking, started full-time in Java in ‘99, and even switched an entire company off Python and on to Java1. After that, Ruby snuck in to solve some of the frustrations of Java, and before I knew it I was doing all of my work in it. Then came Haskell. From the “usefulness of the type system” point of view, Haskell is really on the opposite end of the spectrum from Java, with Ruby in the middle, but you have to be somewhat less naïve than average to see this.
A couple of friends and I recently decided to write a mailing list server in Haskell. We’ve taken some derision for this1, with people telling us that there are plenty of them out there already, but we also have a couple of fairly powerful forces motivating us to do this. One is, of course, to learn Haskell better, and nobody can really argue with that. But another is that there are certain features missing from other mailing list managers that I feel are important.
久しぶり (“hisashiburi”) in Japanese means, more or less, “Long time no see.” And it’s been more than eight months since my last post; so much for the promised next one on DSLs!
As it turns out, the pressures of programming full time, running a business on top of that, and making a little non-computer time for myself leave little time for my “mostly for fun” computer-related activities, such as mailing lists, TSAC, and of course this blog. I will admit I’ve been spending a noticable amount of perhaps less-productive time posting to the TLUG mailing list; I’m thinking I should try to redirect a bit of that here.