Camping vs. Sinatra
librelist.com
librelist.com
* Current code @ 3.499k - http://github.com/camping/camping/blob/master/lib/camping.rb
* Last WayBackMachine archive of _why repo @ 3.9k - http://web.archive.org/web/20080527003153/code.whytheluckyst...
I've never before felt interested in using a Ruby framework, having recoiled from Rails in consternation (though to be fair, I wasn't quite ready for a framework). I really like the idea of a mnmlst framework. I've looked at the Sinatra and camping websites before... now I'm intrigued enough to try a project in each.
Oh, don't worry. I know what every single byte in Camping does:
$ git-rank-contributors -v | head -n 5
_why <why@whytheluckystiff.net>: 11384 lines of diff
Magnus Holm <judofyr@gmail.com>: 10122 lines of diff
Jonas Pfenniger <zimbatm@oree.ch>: 1829 lines of diff
Manfred Stienstra <manfred@gmail.com>: 168 lines of diff
Sean Busbey <sean.busbey@gmail.com>: 116 lines of diff
Besides, there's plenty of other (techarch, Bluebie, DaveEveritt, zuk and busbey are the first who come to my mind) who post frequently on the mailing list and know plenty about Camping.Is there some backstory I'm missing?
The goal of this post wasn't to convince you to switch to Camping, but to inform people that Camping is still alive and there are places where it's actually better than Sinatra. The problem is that people have misconceptions about Camping: old, ugly, not maintained (because why left), small community. While I don't care what framework you use, you should at least be aware of the current status of Camping before making a decision. It's more like: "But you know, there are some pretty cool things about Coca-Cola since you last tasted it four years ago".
As for the writing style: I blame my Norwegian heritage and that English isn't my mother tongue. One time in the future though…
His arguments are all valid for programs of a more significant size, but aren't both Camping and Sinatra oriented towards small programs, whereas you'd use something like Rails or Ramaze for bigger projects? This line gets a bit muddied by the increasing number of projects built on Sinatra, although I don't know whether they introduce ways to alleviate the points he made.
Let me remind you that it was just six (unimpressive) reasons Camping is better than you would imagine, not six reasons Camping is a better fit for your project. All I'm saying is that Camping gets so many things right. Not necessarily in very few lines of code or very fast, but nonetheless: I look at Camping code and nod to myself: "Yeah, this is probably the correct way to do it".
Of course, this doesn't matter at all! If we cared about correctness, we would program in Haskell, not some language where monkey patching is acceptable in production code. As long as you're comfortable in Sinatra, you should continue doing that. It's that simply.
Interestingly, camping.rb on the other hand is not very pretty or correct: http://github.com/camping/camping/blob/master/lib/camping.rb, and that's also what makes it so beautiful in my opinion.
Oh well, let me finish with a little quote from _why:
On Sun, May 25, 2008 at 02:47:39PM +0200, zimbatm wrote:
> This is not that hard to do. Maybe I should add some shortening tricks
> document. I propose platterizing to be done only before release.
No, let's not have rules. I don't feel comfortable with having
coding standards or any protocol on Camping. The point of Camping
is to have very ugly, tricky code that goes against all the rules that
people make for "beautiful" code these days. To show that ugly code
can do beautiful things, maybe.
I don't want to demonize anyone here, I just want to express the
ideas that make Camping different. Camping's personality is 80x50.
It is like the little gears of a watch that are all meshed together
into a tight little mind-bending machine. The challenge of Camping
isn't to figure out how to automate obfuscation. The challenge is
to bring new tricks into the code that push Ruby's parser and make
everyone look twice.
Not all code needs to be a factory, some of it can just be origami.
_whyI saw a very interesting comparison between Ruby and Python that sounds like this. Basically, it went like this: "Python's core language is very simple and pretty, and Ruby's is very complex and ugly. Yet, the very ugliness that Ruby allows and Python disallows means that the libraries that are created with the languages that are the exact opposite: RSpec is a thing of beauty, and something similar in Python isn't even really possible at the same level. So I actually like _using_ Ruby, even if I like the Python language more."
Like you said in both your email and here, it's all about what's best for _you_, not what's best 'in absolute.'
There you go. Two simple apps, that really stress what matters to you. Also, beware of frameworks that impose too much on you (http://news.ycombinator.com/item?id=1534153).
And most of all: enjoy playing around.