Korundum Brings eXtreme RAD to Linux

anonymous writes "The Free Software community is on a quest for the next generation development environment. Is it .Net, is it Java? Many (including Havoc) are quick to dismiss some of the gems invented by the Free Software community itself. Yes, Ruby is an incredibly consistent and clean language designed specifically to incorporate many of the best features and ideas of predecessors. Absolutely everything in Ruby is an object and practically everything can be redefined or extended on the fly. The effects and resulting power of such flexibility can be quite astounding to those who have adapted to contemporary language limitations. Now, the Ruby environment has been seamlessly integrated into KDE through Korundum, meaning that well-integrated and first-class desktop citizens for Linux can be sketched and developed in an extremely short time. Caveat: No explicit compilation is required and programming seems so easy it feels like cheating."

Comments

Rubydium JIT too

[Anonymous Coward]

According to OSNews, another KDE developer has announced the Rubydium JIT.

Count in one new Ruby fanatic

[weeksie]

I've been using Ruby a short time and will say that without a doubt it is the nicest language I've used for development of anything. period. Now of course some people work differently and prefer different languages but I have fallen in love with it.

After a long, long time mired in the quagmire of Java configuration files and the like I finally gave it a go with a small project (an app server). It took me roughly a tenth of the time it would have in Java and I'll gladly shoulder the cost of slower execution speeds with a little more processor power :)

Re:The name

[hoggoth]

I am KSick of this KStupid KNaming Konvention.
It McReminds me another McStupid McNaming McConvention.

Re:Meh?

[mike_sucks]

Apart from the fact that these bindings are for KDE, of course.

The point being that the existence GTK/Gnome bindings for ages have failed to change the primary language for building Gnome apps, so there's little chance that these Qt/KDE bindings will usher in a new era of anything, either.

There needs to be some consensus in the community about such things and given we can't even agree on the One True text editor, it is unlikely we're going to agree on a next-generation application development language.

Solution: Use whatever you feel like.

Re:Meh?

[Anonymous Coward]

JRuby is a ruby implentation for the java JVM, it isn't a binding. The current ruby implementation isn't a byte code interpreter, it evaluates the AST at runtime. Alex Kellett the QtRuby/Korundum co-author is working on a ruby JIT project called Rubydium.

-- Richard

Aaargh

[Estanislao Mart�nez]

Maybe the code in the Qt/Ruby tutorial linked indirectly from this article (through this page) isn't representative of the bindings. But if it is, I will be terribly disappointed.

One of the best features of Ruby is code blocks. I've skimmed through maybe half of that tutorial, and there are no code blocks in sight.

Now you may wonder why should anybody care about this. Well, simple: there are many, many ways of using Ruby's blocks to make code easier to understand. In the case of a GUI toolkit, I can think of two offhand:

1. Callbacks. The quickest, simple way to implement a callback is to pass a block as a closure to the widget at construction time.
2. Representing the embedding of GUI components inside one another. The tutorial code as written works by assigning a variable to a newly instantiated container, then creating contained pieces and including them inside the container by calling methods on the previously created container. All of the pieces occur in the same level of indentation, and the formatting does not make obvious the containment hierarchy of components.

   Creating contained components in a code block passed to the container is no harder at all; in Ruby, just make the container's constructor yield self to its block. And what you gain is much nicer than what most people will give credit for: the code that creates the contained elements is visibly "inside" the code that creates the container. Once you're attuned to this convention, it becomes easier to see the structure of the GUI and the code from the indentation in the source.

Re:Aaargh

[Brandybuck]

The quickest, simple way to implement a callback is to pass a block as a closure to the widget at construction time.

It may be simple, but it isn't optimal. I'm going to need named callbacks, multiple callbacks, and mutable callbacks. Ruby blocks to not offer me this. The first two cases I use all the time. The third I use ocassionally, but when I need it I really need it.

Blocks are very nice things, but they are not omnipotent.

Re:Aaargh

[Eivind Eklund]

I think you've missed an essential feature of Ruby blocks: You can pass a named block through method(&proc_object).

This makes it possible to handle all of your cases beautifully, even if blocks[1] had been the only core feature.

Eivind.

[1] Technically, passing the callback in the block slot of the method in question. Blocks is a syntactic structure.

Re:Is it ok as a beginner's langage ?

[tcopeland]

> is it [Ruby] ok as a beginner langage ?

Yup, it's perfect. And actually, Alexey just started a forum for Ruby beginners. Might be a good place to ask questions...

Re:Is it ok as a beginner's langage ?

[CatGrep]

So, is it ok as a beginner langage ?

For a tutorial, check out Why's Poignant Guide to Ruby, or if that's just a bit too bizarre you might have a look at this Ruby tutorial.

Re:and so?

[CatGrep]

since Python has blocks and all those other Ruby feature, too.

I have yet to see anything in Python that is equivilent to the expressiveness and power of Ruby's blocks. (but I'll admit, I haven't kept up with all the latest changes in Python, maybe they've added something recently)

In Ruby blocks are used extensively in the standard libs because Ruby had blocks from day one. Blocks are full closures in Ruby and they can contain any code (as I recall there are restrictions on lambda code in Python).

I have a feeling that when Python folks talk about blocks they have something somewhat different in mind than Ruby's blocks.

For example, in Ruby you could do:

def process(items)
items.each {|item|
r = yield item
#do something with r
}
end

section = "Foo" #just to demo the closure'ness
process(['a','b','c']) {|i|
puts "in section: #{section}"
puts "...Processing #{i}..."
#a bunch more code
return result
}

So we say that the process method takes a block (the part between { and } ).
Just curious: how would this be done in Python?

Re:and so?

[Abcd1234]

First off, this concept is by no means unique to Ruby, so give credit where credit's due. The whole concept of "blocks" as first class objects was stolen from Smalltalk, which has had this concept since the beginning (back in the 80s). And, of course, this concept was basically taken from Lisp and other functional languages, where they're referred to as closures, or lambda expressions. And plenty of other languages have inherited this feature as well, including Perl (but not, unfortunately, Java... *damn* I wish Java had closures).

Python, OTOH... you're absolutely right. Again, they tried to inherit from Lisp with the lambda construct, and in the process, somehow fell flat on their faces. I quite like Python for many reasons, but this is one bit of brokenness that I've never been able to understand.

Re:Meh?

[Eivind Eklund]

I beg to disagree with Ruby doing nothing better than Smalltalk.

Ruby and Smalltalk both think of everything as an object and have a "bullet list" of main language features that are similar, true.

However, they have a quite different environment integration, a quite different syntactic style, a different programming culture, leading to them being different in practice, with different strengths and weaknesses.

To be more specific:

Environment:

• Ruby programs run from standard files, where they go from line 1 in the script being started to finish. Smalltalk generally work as an image where the programmer edit "everything", and then select an arbitrary place to execute from when the user use it as a program. Using something as a program generally involves a so called "image extraction", where the programmer point at a place to start, and then the compiler extract everything necessary to run from there (and probably a bit extra).
• Ruby works quite easily with external libraries, having a standard fashion to create bindings (easy, since Ruby only has one real implementation). Smalltalk doesn't - there's variaton from implementation to implementation.
• Ruby works easily with external commands, having several standard ways to execute operating system commands. Smalltalk has no standard way, requireing different ways depending on which implementation you use.
• Ruby has standard libraries for network programming. Smalltalk doesn't.

Syntactic style:

Smalltalk has a very, very simple syntax and set of control structures. It was implemented because Alan Kay felt that Lisp ended up with too many "special forms" (similar to for, if, while, switch, etc in C). Basically, Smalltalk has one operation: Send a message to an object. If is implemented by having methods for true and false on an "if object".

Ruby, on the other hand, has a rich set of control structures and syntax, in the spirit of most contemporary languages (C, Java, Python, Perl, etc). It has even added string interpolation and regular expressions to the syntax, making it very easy to deal with these constructs. (Regular expressions is, BTW, another thing that Smalltalk has no standard support for. See e.g. http://www.smalltalk.org/articles/article_20040917 _a1.html for a discussion around this.)

The Programming Culture:

The Ruby programming culture is fairly heavy on metaprogramming and library use. People use standard tools for editing files, version control, searching through the code, etc. Documentation is generally stored as standard comments in the code. If you want to make them browsable or make it possible to do easy lookups in them, you run separate tools to extract them (rdoc to extract to HTML and ri, ri to look up).

The Smalltalk community use special code browser for going through the code. This works on parse trees and the heavily normalized form of Smalltalk. If you want to add comments, this has to be done separately, and is stored separately from the code. You cannot use a standard text editor to edit the code and comments. On the other hand, the normal form of Smalltalk makes it very easy to write tools that work on the code, and this is standard practice. On result of this is the "Refactoring browser", making it possible to do refactorings directly, instead of having to do the manual edits necessary. However, there is very little use of metaprogramming, as that gets in the way of the paradigm. Version control is also handled internally in the Smalltalk image.

End result:

Ruby lets the programmer leverage the habits and tools he or she is used to, while Smalltalk only lets the programmer leverage abstract programming knowledge and the tools that are built into Smalltalk.

The tools that are built into Smalltalk are generally very, very good, but this requirement form a barrier to the wide adoption of Smalltalk. If the entire world was in Smalltalk, it might be a better place, but as it is, the world is not in Smalltalk. The end result is one more thing that Ruby is better at that Smalltalk: Getting programmer adoption. There are presently about 300,000 pages found by a search for "smalltalk language" - against 1.1 million for "ruby language".

Eivind.