RAD with Ruby

Amit Upadhyay writes "KDE's award winning integrated development environment KDevelop, has integrated support for Ruby, an excellent and easy to use object oriented scrpting language. If you are looking for a good programming tool for quickly developing a professional one off application, Ruby (with KDE bindings) maybe just the thing for you. There is a quick tutorial and an online book to get you started. You may also want to read a quite informative comparison of Python with Ruby. If you are web developer or write enterprise applications with JAVA etc, take a look at Ruby on Rails(api), they have a nice blog too. KDevelop provides a GUI builder and Debugger for rapid application development(RAD) with Ruby, which is getting better. There is a nice tutorial on using KDE libraries with Ruby. And if you have lots of code in C/C++, extending Ruby to use them is easy.
"

Comments

Ruby Rules!

[Mr Foobar]

And Python and essp. Perl just plain drools...

Ruby will be easy for any Perl user to learn, and it really is OO from the bottom up, not just bolted on like Perl's so-called OO.

And Ruby's OO makes much more sense than Java's and Python's OO. I can't explain it, but I can't think OO in Java or Python, and I can in Ruby.

Another scripting language

[putko]

I'm quite partial to scsh.
I mention this because I understand Ruby's semantics are like Scheme (but the syntax is different, or we'd call it a Scheme).

The intro from the scsh paper (Olin Shivers) convinced me to try it out:

"Shell programming terrifies me. There is something about writing a simple shell script that is just much, much more unpleasant than writing a simple C program, or a simple COMMON LISP program, or a simple Mips assembler program ..."

He's not talking about a simple shell program (like "rm -fr /") -- but something with variables, control flow, conditionals, etc.

Crossplatform Ruby

[beware1000]

I actually wish I had had these details all in one place when I was looking afew months back (abit of googling eventually showed all those pages).
Personally, I have found if you are really interested in RAD w/ Ruby + QT is fine for linux.

But Wx is cross platform and free! and tools like VisualWx which has support for WxRuby certainly help.

Unfortunately it is only on windows atm AFAIK

Re:Ruby seems on the right track.

[guet]

Just out of interest, which web developement systems use thousands of XML configuration files?
There must be some awful uses of XML config files out there, because a lot of developers complain about it.

I don't know much about it, but seems like they could have a use in some circumstances, and allowing users to edit those rather than strings in the code might be a Good Thing. This depends of course on them having a decent end-user XML editor, clear and succinct XML, and tools for processing XML for the programmer.

Re:KDevelop

[Anonymous Coward]

KDevelop uses the Kate interface from KDE, which can handle any number of editor plugins (kvim, ) for example. I think the lack of a KEmacs, so to speak, stems mainly from the fact nobody has written it.

Re:wx..Ruby?

[Anonymous Coward]

Have a look at the WxRuby homepage. I've used this before for coding up a frontend for a Ruby game and it has worked very well for me. I was also able to package it up into one binary via RubyScript2Exe and ExeRb which was important for me.

Why reimplement Ruby?

[kahei]

Well, the trouble is that Ruby is a great language in search of a good implementation.

The current Ruby implementation has various weaknesses -- primitive text support is the most mentioned one (you can't step through a string char by char, I kid you not). Lack of native threading (it uses weird homemade application-level threads) some concurrency issues (it's C with lots of static variables -- I may be very out-of-date here though) and integration problems (it's very much designed with a 'C and UNIX and nothing else' mindset) are also problematic.

Thus, a port of Ruby to the Java or .net runtime, that kept the language intact but performed text processing, threading etc via those runtimes, would be absolutely amazing. The .net one stalled, though -- maybe the Java one is doing better.

Re:Why reimplement Ruby?

[kahei]

(this goes for both comments above)

I'm referring to stepping through a string character by character -- I should have said that rather than 'char by char', which is open to misinterpretation. I meant 'text character' rather than a C 'char' type, which can indeed be done with 'each_byte'.

For instance, a lot of strings contain Asian characters that are intrinsically more than 1 byte long, or combining characters which consist of a 'main' character and 1 (for most european languages) or more (for the nightmare that is Vietnamese) accent marks. To ruby, it's all just bytes -- if 64 A7 03 A7 04 means an 'a' with an acute accent and a dot, ruby will cheerfully give you those 5 seperate bytes and let you implement the concept of a character yourself.

There are various libraries for Ruby that extend the string class to handle text in different languages and encodings, but this is still nothing like as good as just being able to get, set, read, write, and match characters, as I can in most other high-level environments. Unfortunately, while the concept of a text encoding is built into ruby, it is hardcoded with knowledge of a few particular encodings and it only uses them for IO -- in internal processing, it's welcome to the wonderful world of each_byte.

All this would go away (along with many other issues) if there were an implementation of Ruby for some modern runtime environment such as Java.

This situation and the discussions behind it is one of the things that inspired me to write this essay (which may or may not be interesting, I just mention it):

http://www.jbrowse.com/text/unij.html

Someone please tell me what I gain over Python?

[_am99_]

I learned Python last winter and have not looked back to Java despite being a Java programmer since it was in wide-distribution.

And since Python makes win32 programming easy for those who don't use Visual Studio, I have learned to be a Windows programmer over the last couple of weeks.

What do I gain over Python by switching to Ruby? I see a lot of explainations, but as far as I can tell, in addition to the awesomeness of Python's language and libraries, these are the things that I need that I can't seem to find in Ruby(but might not be looking in the right place):

1) Java byte-code compiling (jython)
2) full win32 APIs
3) full win32 COM access
4) Complete Object Database implementation (ZODB)
5) List-comprehension

Someone please educate me on the advantages of Ruby over Python. Cause right now, it is hard to imagine a better language than the snake!

Re:Someone please tell me what I gain over Python?

[Anonymous Coward]

Python is okay. I'd hardly call it "awesome" but it's kinda like the Java of open source. Gets the job done and there are lots of libraries (and lots of half-baked code).

Ruby does have some *language* improvements over Python. For instance blocks and a lighter syntax, and also a real (and only ONE) object model.

Ruby also has a much nicer community. The Python community has essentially become the Perl community (arrogant and self-important).

I like how you list "List-comprehension" as a *FEATURE* of Python. It's a strange little arbitrary syntactic wart on the language. In Ruby you can write your own control structures.

Also I don't know why you list "complete object database implementation" (a third-party system) as a language feature either. Ruby has libraries that give it *transparent* object persistence! For instance you just load the object and change a field, and the change is persisted. I'm sure Python has the same thing.

Since you seem like a Windows dude you might not be interested in Ruby's Unix-centric view. When you upgrade to a Powerbook you might like it. :-)

But for now just check out that Rails video on the Rails web site, it's just 10 minutes. Then try and implement the same thing in Python.

Re:Someone please tell me what I gain over Python?

[the quick brown fox]

The advantages right now are mostly not pragmatic, but aesthetic. Programming with anonymous functions, closures, and higher order functions is more convenient in Ruby. The OO model seems better thought out.

JVM implementation: http://jruby.sourceforge.net/

Win32 support:
http://www.rubycentral.com/book/win32.ht ml

Object DB: http://www.garret.ru/~knizhnik/dybase.html (I don't know anything about this one, just found it on Google)

List comprehension: Ruby blocks are a more general (and IMO more elegant) mechanism. For example,

[x*2 for x in mylist]

becomes

mylist.map{|x| x*2}

Note that in the Ruby version, x*2 doesn't need to be a simple expression; it could be any number of statements, and the return value would be used. So you could do this (using do/end instead of curly braces):

user_ids.map do |user_id|
result = webservice.lookup(user_id)
if result.success
return result
else
return nil
end
end

That's a pretty stupid example, but you get the idea.

It's not controversial, I think, that Python's bigger userbase and greater number of libraries give it an edge over Ruby for many real-world projects. But Ruby is suitable for a surprisingly large number of situations, and some people feel strongly that the elegance of the language makes it worth using whenever possible.

Re:Short version...

[Ian Bicking]

As for the Python vs. Ruby soapbox: I think it'a a valid component of the news because the two languages are fighting for mindshare in the same pool of savvy OO-script developers.

Not really; if you are a savvy OO-script developer, you are using Ruby or Python or something like it already, you've made your choice. Both languages are trying to pull new developers from other languages, like C or Java. As such, I think they actually help each other -- the potential pool of new people is still very large. Once you've gotten as far as using Python (if you have a statically typed, compiled background), it's a small step to use Ruby, and vice versa. A Python developer should feel quite comfortable with Ruby, compared to most other languages (and vice versa).

Or, if Python gets a good CLR/.NET implementation, the process and lessons will be very applicable to Ruby. Ditto Parrot. Ditto SWIG. And so on.

Re:Ruby seems on the right track.

[Ian Bicking]

Python Is Not Java is a good description of how to approach programming differently when using a dynamically-typed language. Pretty much everything it says applies to Ruby as well. One of the things it mentions is that in most cases where Java programmers use XML, it's to make up for the deficiencies of Java, and you express the same things using Python (or Ruby) source code, which is easier to work with and more general than any XML configuration.

Re:Why Ruby?

[slamb]

That example really shows off why I hate object-relational mappings (Ruby's or any other). It looks like each of those lines of code requires a round trip to the database. In fact, this one requires three:

role.add_permissions(Permission.find(2), Permission.find(3))

If you put some actual thought into the queries you make, you can do much better. For example, what you'd really like to do is see what permissions the user has. So:

select distinct perm.id, perm.name, perm.serial
from user_roles user_role
join roles role on (user_role.role_id = role.id)
join permissions_roles perm_role on (perm_role.role_id = role.id)
join permissions perm on (perm_role.permission_id = perm.id)
where user_role.user_id = :p_user_id

That query allows you to go straight from the user ID to the actual useful information about permissions in a single database round trip. Notice that I used joins. These are things that object-relational mappings seem to neglect. And the foundation of the relational model.

SQL is not hard. Why must everything be an object? I love object-oriented programming, but this isn't a good use of it.

Re:Why Ruby?

[slamb]

From where I stand (don't know Ruby, rarely use SQL) the Ruby example is easy to understand, and the SQL example is far from obvious.

To someone who uses SQL frequently, the code I gave is obvious. (It'd be even more so if slashdot allowed me to indent it properly.) And most people making code to access a RDBMS will have used SQL recently, because they just designed a schema to access. The tool doesn't do that for you.

With object-relational tools, you need to know more than you did before. There's much more complexity and bloat in the system. And the resulting SQL is crap. There's no benefit.

"Premature optimisation is the root of all evil"

More accurately, "premature micro-optimization is the root of all evil". You will save a lot of effort by choosing an efficient high-level design right away. Passing around objects that tie you to an object-relational tool like this one is not an efficient high-level design.

The point is that unless some analysis shows that that particular piece of Ruby code causes an unacceptable bottleneck within the context of the application (from the point of view of the user), then stick with the code that is shorter, simpler, easier to write and easier to maintain.

Yes, that particular piece of Ruby code would cause an unacceptable bottleneck. In many organizations (including mine), the database server and the webserver are not the same. Imagine every round trip taking 50ms and you'll begin to understand. The number of round trips must be O(1) for acceptable performance, and the closer to 1, the better. That's not true for the Ruby code. It makes m + n round trips, where m is the number of roles for that user, and n is the number of permissions for that user. So if that's 20 (depending on how granular permissions are, that's not unlikely), that will add a second per hit. Ugh.

I guess part of what you are saying is that there are existing (old) technologies that are better in some sense if only people would take the time and effort to learn about them, rather than chasing the flavour of the month. If that is part of your message then I whole-heartedly agree. I like fvwm!

In part. But mostly, it doesn't make sense to add on layers of complexity unless they accomplish something for you. This layer does not, and it does take away your performance.