Alieniloquent


"Newsflash: Go is Experimental"

December 15, 2009

Saw a rant today about Go. I was genuinely impressed with the amount of piss and vinegar the author managed to conjure up over this. He’s more upset about this language than I am excited about it, and I wrote a library in it and an article about it already. He brought up some valid points, but overall, he completely missed the mark.

The author brings up two major gripes with Go: it has an ugly syntax, and it lacks innovation. I’ll cede both points, but with a few reservations. Go is experimental. It’s not complete yet. In fact, the language is still changing. The Go authors released it so that other people could see what they were working on, but even they don’t suggest using it for anything critical. Go is not intended to replace Java, or even C++ (though maybe). It’s an upgrade to C.

Ugly Syntax!

I’m not a huge fan of Go’s syntax. It’s a curly-brace language. I do, however, understand why the syntax looks like it does. It is a similar reason to why JavaScript looks like Java. I don’t have a direct line into the Go authors’ thoughts, but I’d wager they wanted something familiar. So we end up with another curly-brace language. I forgive them.

That said, I’d love to hear what the author suggests as alternative syntaxes for the statements he calls out. In fact, I’m sure the Go authors would love to hear any constructive suggestions he might have on a better syntax for these things. I know that the mailing list has frequent discussion regarding ways to improve the syntax. The Go authors are willing to consider changes, especially changes that are proposed along with patches that show how to implement them.

I do want to call him out on his hate of the condition initializer. That new syntax, along with multiple return values allows programmers to replace C code like this:

int result = someCall();
if result < 0 {
  /* Handle Error */
} else {
  /* Do something with result */
}

/* Or worse... */

if (result = someCall()) < 0 {
  /* Handle Error */
} else {
  /* Do something with result */
}

With Go code like this:

if result, err := someCall(); if err != nil {
  /* Handle Error */
} else {
  /* Do something with result */
}

Notably, in the Go code, both result and err are scoped to just inside the if statement. They don’t clutter the surrounding block. I’ll talk more about this pattern in the part about exceptions.

Innovation?

I will take the author’s statement that Go lacks innovation, and go one step further. Go offers no real innovation over other languages that exist today. The three things that the author calls out aren’t really innovative. Analogs to both channels and goroutines have been present in Erlang for twenty years. The interface-only inheritance is just a way to apply the duck-typing concepts of Ruby and Python to a statically type-checked language. There is nothing new to see here. Move along.

The point the author fails to see is that Go is not meant to innovate programming theory. It’s meant to innovate programming practice. This is an upgrade to C. It’s a language that applies the innovations of the last thirty years to the systems world, where the state of the art is still portable assembler. So no, the language isn’t introducing brilliant new ideas. It’s taking tested old ideas, and introducing them into a new arena.

Exceptions

Oh no! Go doesn’t have exceptions. Everybody knows that every modern language has exceptions. You can’t write real programs without non-local transfer of control. Wait? What’s that you say? C doesn’t have exceptions? People still code in that unusable language?

Don’t get the wrong idea. I think exceptions are useful. I use them in languages that have them. I also strongly dislike the C idiom of returning out-of-band values to indicate errors (thus requiring that some value be out of band). However, I think Go has a reasonable way to handle this. Using multiple return values, named return variables, and the comma-error pattern, a decent error reporting facility can be created without exceptions.

Here is an example:

func magic() (result int, err io.Error) {
  if err = moreMagic(); err != nil {
    /* Calculate result */
  }
  return;
}

This allows the error from moreMagic to propagate up without reserving an out-of-band result value. It provides no more syntactic overhead than explicit exceptions in Java (and arguably less).

The argument was made that people can fail to check return codes. People can be just as stupid in languages with exceptions. I’ve lost count how many times I’ve seen this in Java:

try {
  /* Do something that might blow up */
} catch {
}

The catch block is empty on purpose. People do that. They catch all exceptions and then do nothing with them on purpose. You can be an idiot in any language.

Generics

I’ll be honest. I’ve hated every implementation of generics I’ve seen in non- functional languages. That is to say, C++, Java, and C#. They are a poor attempt at implementing the polymorphic types that ML-derivatives have enjoyed for decades. The syntax for them is inevitably terrible and the semantics just as awful. However, plenty of modern languages don’t have generics.

The author is whining because the language doesn’t have his favorite language feature.

New Jersey style

The author wants to suggest that the Go authors subscribe to the New Jersey school of programming. He suggests that his two favorite features (exceptions and generics) aren’t in the language because the Go authors were too scared to implement them. He even cites the Language Design FAQ as proof.

If this were a reading report, I would give it a grade of D, maybe a C- if I felt charitable. Why? Because the author of the article clearly had nearly no comprehension of the FAQ. He suggests that the Go authors decided not to include the features because they couldn’t figure out how to implement them. When the truth is, Go is incomplete and they cannot figure out how to include exceptions or generics yet and are open to suggestions.

Just like with his syntax improvements, I’d encourage the author to post to the mailing lists with suggestions on how to implement exceptions and generics in such a fashion that they fit in with the philosophy of the language. The Go community is interested in those topics. The discussions are happening right now.

TL;DR

Go is incomplete and experimental. Even recently it went through a fundamental syntax change (making semi-colons optional virtually everywhere). The Go authors are very willing to listen to suggestions that are backed up with code. So, what I have to say to the author is: nut up or shut up.

Fixing My Markup

December 9, 2009

Several years ago when I created the current design for this blog, I made a rather unfortunate choice of markup for my code snippets. I decided to enclose them in <div> tags like this:

<div class="code"></div>

I’m really not sure why I did that, although I have a vague recollection that it had to do with my CSS not working otherwise.

There was an unfortunate consequence of that: I had to use &nbsp;s in order to get indentation right inside the code blocks. Well, let me tell you, that is a pain in the ass. Needless to say, it demotivated me from writing blog articles with code snippets. This is a blog about programming. You can practically hear the long silence that follows.

Well, I’ve been more and more motivated to blog stuff lately. However, I wanted to fix this issue with my markup. It turns out that whatever issues I had run into before are gone. This markup works:

<pre class="code"></pre>

All I needed to do was go through my nearly 140 posts and change tags and remove &nbsp;s. Yeah, that sounds like fun. Ruby to the rescue! After an aborted attempt to use the AtomPub API (which gave a 302 to a 404), I spent a little bit of time poring over the api documentation. Then I whipped up this little script:

require 'xmlrpc/client'

wp = XMLRPC::Client.new_from_uri('http://example.com/xmlrpc.php')
user = 'yeah'
pass = 'right'
blogid = 42

posts = wp.call("metaWeblog.getRecentPosts", blogid, user, pass)
posts.each do |post|
  newtext = post['description'].gsub(/<div class="code">(.*?)<\/div>/m) do
    "<pre class=\"code\">#{$1.gsub('&nbsp;',' ')}</pre>"
  end
  next if post['description'] == newtext
  post['description'] = newtext
  wp.call("metaWeblog.editPost", post['postid'], user, pass, post)
end

I ran it, held my tongue just right, and voila. Every post that had the old markup now has the new markup. Just like that.

Cargo Cult on Rails

August 20, 2009

I’ve been coding in Ruby for a long time, and I love the language. It has all the object-oriented power of Smalltalk, the functional power of Lisp, and the concision of Perl. It is so powerful that it enables programmers to devise entirely new ways of writing software, and that is the hallmark of a good language.

The trouble is that some of these new ways of programming aren’t good ways of programming. Over the last five years we’ve seen the ascent of Ruby on Rails and the Rails Way of doing things. I’ll be the first to admit that Rails revolutionized web development. But it has taught an entire generation of web developers to think like a cargo cult, and that’s not good.

Convention Over Thinking

Rails’ mantra of convention over configuration is brilliant. I love it. But somewhere along the line the message got skewed and people started thinking that everything should be a convention. Every web app should be written exactly the same, and the only thing that changes is the bits between the browser and the RDBMS. Rails is the glue that holds it together, and you just need to describe the data.

The trouble is, that kind of thinking is just plain wrong. As the folks at Twitter discovered, not every problem is a nail that can be hammered. Sometimes they’re screws, or bolts, and they need different tools to fasten them down. That’s why writing software is hard. It requires thinking. If you’re not thinking to see if the conventions are actually correct for your application, then you’re doing it wrong.

Rockstars and Groupies

The Rails community seems to love its rockstar programmers. Big personalities like DHH, Ezra, and Yehuda are practically worshipped. When they speak their minds its taken by many as gospel truth. Because conventions are so important, they need somebody to tell them what the conventions are, so the rails groupies flock to their rockstars to be told how to write their applications.

People, that’s just sick. You need to be thinking for yourselves. Who cares what DHH thinks? What do you think? Your application should not look like some celebrity programmer tells you it should. Your application should be custom-built to solve the problems in your domain. You are the expert in your domain, so look no further than yourself.

Framework-Driven Development

What it comes down to is that Rails developers are just that: Rails developers. They’re not software developers, at least not most of them. Their entire software devlopment world is built up around this framework. They only know how to do things the Rails Way. Their framework dictates how their systems are designed instead of the problems the systems are designed to solve.

The real irony here is that this is exactly the kind of problem Rails was running away from. Five years ago, you couldn’t write a Java-based web-app if you were just some developer who happened to know Java. You had to be a Struts developer or a J2EE developer because you needed to know the deep inner workings of the framework you were going to use. Now Rails is the same way.

Congratulations, Rails, you’ve turned into your parents.

Using emacsclient on Mac OS

July 1, 2009

There’s this feature of TextMate that a lot of people like: the mate command. It opens up the file or directory you pass to it in your running TextMate instance.

This sort of feature isn’t anything new. Emacs has had this feature for a long time. You just add this snippet to your to your init.el:

(emacs-server)

Then you can use emacsclient to send files to it the same way. However, on my mac this wasn’t working. The trick, it seems, is making sure you use the correct emacsclient.

About a year ago, Emacs.app was merged into the main-line GNU Emacs. So you can build a completely Cocoa-based version of the very latest GNU Emacs right out of CVS. If you do that, an emacsclient executable is included in the application bundle.

You can write a little shell script, we’ll call it eopen:

#!/bin/sh

# Send the file to our running Emacs and bring it to the foreground.
/Applications/Emacs.app/Contents/MacOS/bin/emacsclient -n "${1}" \
  2> /dev/null \
  && open -a Emacs

# If that failed, then open a new emacs visiting the file.
if [ $? -ne 0 ]; then
  EOPEN_DIR="${PWD}" EOPEN_FILE="${1}" open -a Emacs
fi

Now, you’ll notice that in the failure case, my script sets some environment variables and just opens Emacs. Those environment variables aren’t anything special. In fact, unless you add some code to your init.el all you’ll get is a fresh Emacs open to whatever default buffer you usually see.

So, add the following to your init.el:

(let ((dir (getenv "EOPEN_DIR"))
      (file (getenv "EOPEN_FILE")))
  (if dir
      (cd dir))
  (if file
      (find-file file)))

Then, when you have those environment variables set (such as in the shell script), emacs will open up a buffer on the file or directory passed in as an argument to the script. This hack is there so that you can use eopen to open non-existent files in addition to existent files (open complains if the file does not exist). Subsequent calls to the script can just use emacsclient.

An example of defadvice in Emacs

June 25, 2009

For decades there’s been a war between zealous users of various editors. The truth is, though, that it is completely unfair to compare editors such as vi, Textmate, or BBedit with Emacs. Why is it unfair? Emacs isn’t an editor, it is a programming environment. Today I want to share an example just how powerful this distinction is.

It’s better to compare Emacs to Smalltalk. It has a very small core written in C, but almost all of the functionality you think of as Emacs is written in Emacs Lisp. Emacs is really just a Lisp interpreter with a lot of primitives built in for shuffling text around on the screen. This has a lot of awesome implications for people who want to build tools for programming.

For example, some people like to have a window pane that shows them the file structure of their project. Textmate does this. With nav you can have that in Emacs. However, it always puts the navigation on the left-hand side of the frame.

One of my co-workers wanted his nav to show up on the right-hand side. So I started by typing C-h k nav RET and that brought up the help for the function nav which puts the navigation buffer on the screen.

(defun nav ()
  "Run nav-mode in a narrow window on the left side."
  (interactive)
  (if (nav-is-open)
      (nav-quit)
    (delete-other-windows)
    (split-window-horizontally)
    **(other-window 1)**
    (ignore-errors (kill-buffer nav-buffer-name))
    (pop-to-buffer nav-buffer-name nil)
    (set-window-dedicated-p (selected-window) t)
    (nav-mode)
    (when nav-resize-frame-p
      (nav-resize-frame))))

A quick terminology note. In Emacs-speak, operating-system windows are called frames. A frame can be split into multiple windows.

Doing the same for some of the other functions (split-window-horizontally, other-window, pop-to-buffer), I was able to determine what this function was doing. The call to split-window-horizontally leaves the right-hand window active, so the call to other-window hops back to the left-hand window (but only because all windows were deleted before the split). Then from there on out, everything assumes that it’s in that left-hand window and alters its behavior.

So, all we need to do is delete the line I bolded above and it should work. Because this is Lisp, I just copy the whole function into a buffer called *scratch*, make my edit, and evaluate the code. So, now when I type M-x nav RET I call my new function that does not call other-window. Sure enough, it shows up on the right-hand side.

However, I do not want to duplicate all the rest of that code. Emacs has an awesome facility to assist me, and it’s called defadvice.

;;;;;;;; To launch nav on left side: M-x nav RET
;;;;;;;; To launch nav on right side: C-u M-x nav RET
(defadvice other-window (around other-window-nop))
(defadvice nav (around prefix-nav)
  (if current-prefix-arg
      (ad-activate-regexp "other-window-nop"))
  (unwind-protect
      ad-do-it
    (ad-deactivate-regexp "other-window-nop")))
(ad-activate-regexp "prefix-nav")

This is essentially monkey-patching by another name. When I activate this advice it gets called instead of the function it’s advising, then at the point I call ad-do-it, the original function (and any previously defined advice) gets called. In the above code, I have two pieces of advice. One simply turns other-window into a no-op, and the other turns that on and off, but only if you use the universal prefix.

You can do this for any function in the system. Even the functions that get called when you hit individual keys. That is why Emacs is so powerful. It’s not an editor, it’s an environment.

Changes

June 22, 2009

I’m back!

My Spring got swallowed up by the tail-end of my last semester at UNO. Now it’s Summer and I’m living in San Francisco.

That’s right, I’m in San Francisco. I was planning on moving out here mid- July, but circumstances conspired such that I moved out here a week ago. I already have an apartment, and I’m getting settled in. I was hoping to get around and visit more of my friends in Omaha before I left, but hey, I’ll be visiting.

I am going to be blogging here again now that my brain isn’t getting drained (filled?) by school. My wife and I are also starting another blog to talk about general life stuff.

"Pet Paradise Part 1: Algorithms"

March 20, 2009

So Jay Hannah over at ODynUG has issued a programming challenge. Far be it from me to turn that kind of thing down. I am going to be doing this in Erlang.

Before I dive into coding on this, I want to give some thought to the algorithms I want to use in order to solve the problem. The way I tend to approach this is to consider what other problems I’ve solved, and see which this one looks the most like. Given my strong mathematics background, I tend to draw on theory-laden ideas. In this particular case I’m going to use graph theory. I plan to construct an interval graph, do some processing on it, and then find a coloring. I’ll then examine each color class, and find the one that produces the largest revenue.

The first step is to turn the raw demand data into an interval graph. In this graph, each individual demand will be represented by a vertex. An edge will be added to the graph between each demand that overlaps in time. At this point, we’re paying no attention to cats, dogs, small cages or large cages. All we want to see is how the demands overlap in time.

The second step is to group together the vertices that represent demands that can be met simultaneously. So picking a vertex, we’ll traverse all of its edges, and if we can combine two vertices in to one that represents them both, then we’ll do that. This presents an interesting problem, as the order in which we traverse the vertices makes a difference as to how many can be combined. However, it’s more likely that we’ll be able to combine demands if they have fewer pets or if their pets are smaller, so I’m going to traverse them in increasing order of pet quantity and size.

Next, we’ll find a coloring for the graph using the greedy coloring algorithm. To use this algorithm we need to pick a vertex ordering. Since the number of colors used can at most be one more than degree of the most connected vertex in the graph, and the greedy coloring algorithm relies on looking at the colors of previously colored neighbors, it makes sense to order the vertices in decreasing order of degree.

Armed with a coloring, we simply sum the rates for all of the demands in each color class, and then select the color that gives us the biggest revenue. The demands in that color are the ones that get accepted, the rest get rejected.

There are some drawbacks to this approach. For one, the graph coloring problem is NP-complete, so we cannot always be certain that the coloring we produce is the optimal coloring. Also, because of how we’re combining demands together, it is possible that a different combination would yield higher revenue. However, this algorithm should perform fairly well.

Back From The Dead

March 20, 2009

Okay, so I died a little.

I’ve been so busy, and writing on my blog has really just slipped my mind. Let alone working on side projects like blogerl or VUE.

Anyway, I’m back. I’m going to try and post at least once a week, if not more. I’m going to start off with some posts explaining how I’m going about solving a programming challenge for ODynUG.

Layout, design, graphics, photography and text all © 2005-2010 Samuel Tesla unless otherwise noted.

Portions of the site layout use Yahoo! YUI Reset, Fonts & Grids.