Is Ruby the Best Language?

I was noodling around with some Ruby the other day, and all of a sudden I ran into a situation where I wanted to do a partial function application. But how do you do that in Ruby? It can certainly be done, but it felt very awkward to me and made my code less readable than the non-partially-applied alternatives. So I didn't do it.

For me, higher-order functions in Ruby are the language's only blemish. It seems almost unfair to ding Ruby for that, because Ruby (at least since 1.9.x) does higher-order functions pretty admirably. It's just not as elegant as the rest of the language.

Ruby has set an extremely high bar. The lack of ceremony in the language makes it extremely readable. The purity of its "everything is an object" stance makes it very writable. And its pervasive methods of introspection make it amazingly powerful.

But why did I even have the urge to make a partially applied function? Because I've been doing a lot of JavaScript lately, and JavaScript is all about the functions.

Ruby and JavaScript take sort of opposite approaches to object properties vs. methods. When you want to reach into an object in Ruby, you always talk to a method. So-called "properties" on Ruby objects are really just getter and setter methods with a little syntactic sugar applied.

In JavaScript, objects mostly only have properties. A "method" in JavaScript is just a property that happens to be a function. (You can define real getters and setters in modern versions of JavaScript, but browser support is not yet pervasive.)

Which approach is better? I would have to say Ruby's. JavaScript seems more fragile in its property-centricity. For example, if you want to pass a method as a callback in JavaScript you have to think about weather it needs to be called as a method or if it is OK to be called as a stand-alone function. If it needs to be called on a particular object you end up wrapping it in another function.

When it comes to JavaScript's advantage - higher-order functions - Ruby sort of cheated. By making a special case of passing a single function (a block), Ruby made the 80% use case extremely easy and simple.

So is Ruby the best language? Well, I probably wouldn't have worried about higher-order functions so much if I wasn't using JavaScript. What other blemishes might Ruby have that I just never run into? I guess it's not surprising that you can only compare languages that you have really used.

But Ruby is definitely the best language that I know.

node.js

I can't stop thinking about node.js.

node.js is Google's V8 JavaScript engine tied together with some non-blocking IO libraries. Those libraries include DNS, TCP, HTTP and file access.

Now, I've been dreaming about a good server-side JavaScript solution for quite a while. JavaScript is an excellent language, and chances are you're using it already on the client side. Why not use it on the server side also? That's not the main reason that node's author (Ryan Dahl) chose it though. He chose it because JavaScript is already very callback-centric, and node is designed to use callbacks in place of multi-threading. Whenever you do something that might take a little while (like hitting the network or disk), you set it up and then pass it a callback. Your callback will know how to handle the data that gets returned. Meanwhile, code keeps executing. This is much better than having one thread running for each connection, because those threads are usually waiting for the network or the database or even disk. When you have all those idle threads you pay a penalty in context-switching and memory overhead.

If you still need more convincing, check out Ryan's slides from his JSConf.eu talk (PDF). They're very readable slides.

It's still early days for node.js. The project (what do you even call it - a server, I guess?) can serve up HTTP very well, but it doesn't give you a framework by itself. Consequently there are frameworks popping up all over for it, following all the patterns of frameworks implemented for other languages. One thing the server is genuinely missing is database support. A PostgreSQL binding is in the works, which sounds great to me. MySQL might be harder because it doesn't have a non-blocking library, but who needs MySQL when you have Postgres? :-P

Network Printer

If you're trying to set up a printer that is attached to the network, do you think you should select the option that says "Local printer attached to this computer" or the option that says "A network printer, or a printer attached to another computer"? Hint: this is Windows.

Scroll down to the bottom of the dialog box for the answer. I can't understand why they don't just relabel the options. I would make a guess, but Al Gore tells me that my sarcasm footprint is already too high.

The Forgotten Half of Computer Literacy

Gruber today noted that the New York Times is adding an API to their campaign finance data (bravo!). He also pointed to an article from 2006 titled "The programmer as journalist: a Q&A with Adrian Holovaty".

The interview is pretty concise and lays out how and why journalism can better be accomplished with help from software. Holovaty breaks down the journalistic process of collecting, filtering and disseminating information and how computer automation can be applied to each step, leading to better journalism. Near the end, he argues that all journalists should have at least some experience with programming, if for no other reason than just to know what is possible.

His points are persuasive, but they're also applicable to almost any field - not just journalism. I believe that everyone should at least know how to write software in the same way that everyone should be able to write in general.

Literacy describes the ability to read and write. When we talk about computer literacy, we usually think of the ability to use software - which I would liken to the "reading" part. We often ignore the "writing" part - the ability to make software. But writing software is incredibly powerful. If you write a page-turning novel, it inspires the imagination of everyone who reads it. If you write an informative article, all its readers are enlightened. Likewise, great software entertains and/or empowers every person who makes use of it.

The analogy holds up pretty well. No - it holds up too well - it's not an analogy at all! Writing software is writing. It might have an apparently arcane grammar, but making software is merely writing down instructions that a computer can understand. And the language is not more complicated than English. Have you seen English? It's the most bastardized, crazy language on the planet! The languages we use to talk to computers are incredibly simple - necessarily so. Computers aren't going to pick the correct meaning of a word out of a dozen possibilities based on context. They're not going to detect our sarcasm in step two of the instructions we give them. They need to be told exactly what to do in the simplest way possible, and programming languages are the way we do that. Consequently, programming languages have only gotten simpler over the years. Strong typing is going the way of the dodo. How often do you need to know what a pointer is any more? All the complicated things are getting hidden away in libraries or abstracted by the VM. There has never been a easier time to become a programmer than today.

I don't believe that everyone has to become a "programmer" any more than everyone has to become a "writer". But everyone should be able to write; a sentence, a paragraph, an essay, a script that their computer executes.

Exercising Git

At work I use SVN for source control, but I've been itching to try out Git. I also recently stumbled across Project Euler, a series of math problems intended to be solved by writing small programs. I think you see where this is going. So - as of a few minutes ago - my Project Euler solutions (such as they are) are up on my github account.

I am a complete Git newb, so I followed some instructions on setting up Git and a new github repository. Since I can see all the code on github, I guess it's working.

My Project Euler solutions have been very fun so far. You're allowed to implement your solution in whatever language you want. I chose Ruby because it is the most expressive language I've found.

My solutions involving factoring primes have been a mixed bag. I think I did ok finding the largest prime factor of 600851475143 (problem 3), but my solution to problem 10 (sum all the primes below two million) was an ugly brute force. I really should have known a better algorithm (I won't say it by name here, but it was referenced in one of the Dark Tower books).

Some of the problems have been quite easy, but I'm only up to problem 17. I've peeked ahead and it looks like they get pretty tough. Sometimes it feels like using Ruby is cheating - for instance, problem 16 is "sum all the digits of 2^1000". Pity the poor C++ programmer!

The tricks I have up my sleeve are mainly inject, memoization and recursion. Recursion is especially helpful in simplifying problems. Memoization can be invaluable when you're performing expensive math. Inject is just plain fun - who wants to write all that boring loop code?

One reason that people might shy away from Ruby in Project Euler is the perceived performance benefit of more low-level languages. That is a complete red herring. When I was writing assembly language in high school, I read Michael Abrash's "Graphics Programming Black Book". One thing I learned was that extremely optimized assembly language will only net you a 2x to 10x improvement over compiled code. "Isn't that a lot?" you say? No - it is nothing compared to the gains you can usually get from improving your algorithms - often orders of magnitude. Using an expressive high-level language like Ruby allows you to concentrate on the high-level algorithms. I was especially proud of my solution to problem 15. I first broke the problem down with recursion. When that ran for more than a minute I realized I was solving the same problem more than once so I memoized it. Now it runs in less than a second even on my super-slow EeePC. Of course, there are much more elegant solutions out there - my solution that I was so proud of was far from the best. It just goes to show how far a good algorithm can take you.

This turned out to be a rambling post - sorry about that. In conclusion, Git and github are great, Project Euler is fun and algorithms matter. Good night!

Banish XSS Forever!

The two biggest classes of web site vulnerabilities are SQL injection and Cross-Site Scripting (XSS). The ever-vigilant programmer can reduce the occurence of these problems, but proper architecture can eliminate them completely.

The SQL Problem Has Been Solved

I couldn't stop myself from referencing the XKCD SQL injection example. But for coders using prepared statements or parameterized SQL, SQL injection is already a bad memory. The problem of unsanitized data getting into your SQL can be avoided by following one rule: Never put any data into SQL. Instead of this:

$sql = "SELECT id FROM usertable WHERE username = '".$uname."';";
$result = pg_query($sql);

You do this:

$sql = 'SELECT id FROM usertable WHERE username = $1';
$result = pg_query_params($sql, array($uname));

Now when a script kiddie pastes some exploit code into my account sign-up page, he can't drop my tables or read all my password hashes. Little Bobby Tables can grow up to live a rich life without incurring the wrath of any more schools.

The XSS Problem is the Same Problem

SQL injection happens when unescaped data is interpreted by your SQL parser. XSS happens when unescaped data is interpreted by the client web browser. It's really the same problem, and the solution is pretty much the same.

I said "pretty much" because in the case of SQL, all the main relational databases have added APIs to allow "data" to be sent seperately from the "query". I don't see browser makers doing anything analogous. But you don't need your database to support parameterized queries natively - you can use a wrapper library that does it for you. Likewise, web site developers can adopt web frameworks that enforce the seperation of markup and text on the server side.

DOM View to the Rescue?

Stay with me here. The "traditional" way to build web pages programmatically was top-to-bottom. First you send your http headers, your DTD, your opening <html> and <head> tags, etc. until you finally send the closing </html> tag at the end. We're treating the web page as a string of text. Just because it is text on the wire doesn't mean we need to treat it that way. We should treat it as a tree, just like the browser on the other end does after it parses all that HTML.

Anyone who writes JavaScript is familiar with the Document Object Model (DOM) that is the web browser's internal representation of the web page. The page is a tree, with the <html> element at the root, and every element or chunk of text as a node. I propose that we write web frameworks that build web pages as trees - never having the programmer output any markup.

This system would start out with a basic empty web page.

html
|-head
| \-title
\-body

Set the title (please don't mind the syntax of my psuedo-code):

head.title.appendtext("Hello World")

html
|-head
| \-title
|   \-textnode value="Hello World"
\-body

Add a footer

body.appenddiv(class="footer").appendtext("© 2008 Me")

html
|-head
| \-title
|   \-textnode value="Hello World"
\-body
  \-div class="footer"
    \-textnode value="© 2008 Me"

Add our main content:

maindiv = body.prependdiv(class="maincontent")
maindiv.appendh1.appendtext("Hello World!")

html
|-head
| \-title
|   \-textnode value="Hello World"
\-body
  |-div class="maincontent"
  | \-h1
  |   \-textnode value="Hello World!"
  \-div class="footer"
    \-textnode value="© 2008 Me"

And so on. When you're done, your framework generates the HTML or XHTML or what-have-you from the tree and spits it out to the client. No markup is ever generated by hand and text can only go into text nodes or attribute values. The markup generator will automatically make the "&copy;" for the copyright symbol and knows how to escape quotes embedded in attribute values as well.

This is the solution I propose - not the sisyphean task of "remember to escape your strings". Maybe I'll build it.

Stack Overflow

I have been having so much fun with the beta of Stack Overflow - a new programmer help site by Jeff Atwood and Joel Spolsky.

If you're interested in the beta, you can get in here (scroll down a bit). Hopefully it will be live to the world soon. I expect scaling issues (not that it's had any yet, but I expect massive popularity).