ShiftEleven

Previewing Beast: the open source Rails forum

Beast is a nice, light-weight forum written in Rails. From what I can gather, the overall goal is to make something work with only 500 lines of code, and I think that could happen with this. It is open source, and can easily be checked out.

I did check it out and I have to say that I'm impressed. It is using the rails edge and is trying out some of the RESTful stuff all the while adhering to the philosophies of CRUD. I have wanted to look into a good example of a rails project using REST, and this code base is great for that. What's more is that it's not very difficult to wrap your head around all of the code of the site, due to the small code base and nice abstraction of the code.

While reading up on this new forum, I came across a post in which the writer was interested in Beast because of the marketing tag-line, written in under 500 lines. He goes on to raise some points on why that philosophy rubs him the wrong way, but I have different views on his points.

Obscure Code

This certainly can be the case in many instances. I have seen a chat server written in 4 lines of perl code. That thing is a horrible mess. That said, I think Beast suffers no where near the extent on that. It does make use of writing out small methods to the whole line; and being that ruby can lend itself well to being understood when read aloud, it's not that obscure. I will say that in order to read some of these lines, you will have to be somewhat familiar with the idioms of ruby.

Included Libraries

Marc makes the point of noting that just because you have written 500 lines of code, doesn't mean that the project is 500 lines of code is you use frameworks and plugins and other libraries. Mathematically, I agree; however, there is a difference in code that is apart of your project from that code abstracted to external uses. You could also then argue that 50 lines in Java is actually more because you have to think about all of the code that was used to make all of the Java classes as well as that to make the engine but that shouldn't matter. The only thing that really matters is the 50 lines of code that are doing what you need to get the job done.

Arbitrary Restriction

It's true, the number of lines of code really don't matter to a machine; but to make claims that it isn't more useful is untrue. Part of keeping code small is that it keeps it agile. One way to keep the lines of code small in number is to not rewrite functionality. Not repeating your code keeps your edits quick and you have the ability to change functionality faster. While setting the number at 500 may be weird, trying to adhere to keeping extraneous code out is a good thing. Now if the project warrants lifting that 500 line cap and then code stays committed to the 500 limit, therefor kludging up things or doing this half-assed, then that is truly absurd.

Feature loss

I do not think that you have to lose features in order to make this work. I think the restrictions can be liberating. 500 lines of code: that means there cannot be all of the bells and whistles; not until the core code is in place. In order for the forum to work, the core functionality has to be in place, and since the 500 lines are the limit, then it means that the other pieces of scope have to wait. I'm not going to say that Marc's situation of poorly-implemented code can (and often does) happen, but I think with Beast, they have the right approach.

Beast is shaping up to be a really nice forum, something that you can use the ground work for and build higher if need be. It's simple and elegant and a fine example of a rails project.

Notes

Perl Chat written in 4 lines

1#!/usr/local/bin/perl -- minchat: run and telnet to port 5555 - bslesins
2sub p{print@_}$SIG{CHLD}=sub{wait};socket S,2,2,6;bind S,pack(Snx12,2,5555);
3listen S,5;while(accept C,S){if(!fork){open(STDOUT,">&C");p"name:";$n=substr
4,0,-2;$f=fork||exec"tail -f chatlog";open W,">>chatlog";select(W);$|=1;p
5"[$n here]\r\n";while(){p"$n> $_";}p"[$n gone]\r\n";kill 15,$f;exit}}

Comments

comments powered by Disqus