Ruby, Rails, C and Web Services
Much has been going on now…
So far this semester I’ve started programming C, started looked at web services, and also started using Ruby + Ruby On Rails. Now there’s only LaTeX (and maybe C#) left on my semester wishlist :)
So to combine all these technologies I have explored the possibilities of using C inside Ruby by creating a small C program (using SQLite) and wrapping it in Ruby classes. These Ruby classes will then be used in a simple web service handled by Ruby On Rails / Action Web Service and the web service will be demonstrated with a Java/Swing GUI.
So what have I learnt along the way? Well, Ruby is, different. In the beginning the differences just seemed strange but now, after a day or two I get a warm feeling in the stomach when I write something in Ruby. Most of the do I like Ruby? depends on how much I like it compared to other languages, and Python in general. That’s because I’ve done similar stuff in Python.
The one thing I really like about Ruby is that everything is an Object. Well, everything is, and every class inherits from the Object class. I’ve heard this before, when reading about Python, but hey can you do this in python -3.abs.to_s and end up with the string “3″? Not in my shell anyway…
Consider this:
def print_if value
(1..5).each {|num| print num if num.eql? value}
end
It is that kind of thing that seemed weird but gives me the warm feeling today.
Ruby is truly object oriented while Python feels semi object oriented and Java, oh well, we have primitive types, how nice…
Ruby on Rails? Once again, Ruby on Rails vs. TurboGears. The first impression is that Rails seems more stable, more glued together. Just the fact that I had to restart the TurboGears development server whenever I made a typo (syntax error) in the controller, but not with Rails gives me this impression. However, that I manually have to create my database tables in Rails (ActiveRecord) but not in TurboGears gives a different impression. I think the big difference in the end is that I read a book on Rails while just using the docs on http://www.turbogears.org/ for TurboGears. It might also make a difference that TurboGears was at version 0.7 when I used it (now 0.8 / 0.9 alpha).
C? Oh, well… C is, fast? Tedious? Annoying? C is a lot. The fact that I have to write 200 lines for accessing a SQLite data base and actually doing something could make one weep. “But it’s fast to run, not to write.” Yeah, I realise that. Well, I have become sort of used to C by now, and I do tend to feel sick when I hear words like VM or interpreted language but I will not vote for building desktop applications in C :), or web service components for that matter.
So what is my conclusion?
Rails vs. TG? Oh well, if you know Python en enjoy Python, go for TG. If you know Ruby and enjoy Ruby, go for Rails. If you know PHP and enjoy PHP, grow up. Ok, I guess PHP could be nice inside a decent framework, but… then again.
Web services in Rails? Well, it took less than 5 minutes to set one up in the development environment… Seems just as easy as in Visual Studio (latest? version). The only difference would be that I don’t have the Web service button that does it for me. I have to do some horrible typing. Well, I enjoy typing more than using the bloody mouse… From what I have read it would also be rather easy to deploy a Rails web service.
Ruby? Oh well, I think i’m in love. Yes, I know it’s an interpreted language, but hey, whenever will you find the perfect love anyway? The fact that two days after I opened my first Ruby guide (which by the way was the hilarious why’s poignant guide to Ruby) I have created half of “Sunkhak GBG” (see Sunkhak for an idea about what it will be), created a sample webservice and wrapped a C program inside two Ruby classes tells me Ruby is quite easy to learn and understand as well.
May 30th, 2006 at 21:44
For the record, in Python, everything is an object, too.
>>> type(1)
>>> issubclass(int,object)
True
>>> isinstance(1,object)
True
>>> dir(1)
[’__abs__’, ‘__add__’, ‘__and__’, ‘__class__’, ‘__cmp__’, ‘__coerce__’, ‘__delattr__’, ‘__div__’, ‘__divmod__’, ‘__doc__’, ‘__float__’, ‘__floordiv__’, ‘__getattribute__’, ‘__getnewargs__’, ‘__hash__’, ‘__hex__’, ‘__init__’, ‘__int__’, ‘__invert__’, ‘__long__’, ‘__lshift__’, ‘__mod__’, ‘__mul__’, ‘__neg__’, ‘__new__’, ‘__nonzero__’, ‘__oct__’, ‘__or__’, ‘__pos__’, ‘__pow__’, ‘__radd__’, ‘__rand__’, ‘__rdiv__’, ‘__rdivmod__’, ‘__reduce__’, ‘__reduce_ex__’, ‘__repr__’, ‘__rfloordiv__’, ‘__rlshift__’, ‘__rmod__’, ‘__rmul__’, ‘__ror__’, ‘__rpow__’, ‘__rrshift__’, ‘__rshift__’, ‘__rsub__’, ‘__rtruediv__’, ‘__rxor__’, ‘__setattr__’, ‘__str__’, ‘__sub__’, ‘__truediv__’, ‘__xor__’]
>>> class myint(int):
… def __add__(self,other):
… return int.__add__(self,other)+1
…
>>> a = myint(5)
>>> a + 1
7
>>> b = myint(5)
>>> a + b
11
>>> str(abs(-a))
‘5′
Back in 1991 Python was not object oriented, and every thing was not an object, but hey, it was in 1991. Python has since evolved and has a fully object oriented structure since 2002 and the Python 2.2 release (of course, object orientation was there before but there was a difference between ‘types’ and ‘classes’).
May 30th, 2006 at 22:06
Yeah, well, i know, they say that everything is an object.
It just does not feel all that object oriented with lots of functions such as isinstance(1,object) instead of i.e. 1.isinstanceof(object)
I guess you also would do:
foo = 1
isinstance(foo,object)
and not
foo = 1
foo.isinstance(object)
On the other hand, I haven’t used Python enough to really be in any position to criticise the language or it’s constructs.