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 :)

The name

[Anonymous Coward]

A RAD for KDE? It really should have been called k-rad.

Re:The name

[hoggoth]

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

Re:The name

[Brandybuck]

Gno it doesgn't! Gnet real, you're gnot making segnse!

Re:The name

[aminorex]

Great. We've Gained another groaning grump
who gives us guff.

Re:The name

[notamac]

Would you like a McBride with that? :)

Meh?

[mike_sucks]

So how is this different to the GTK/Gnome bindings for Ruby that have been out for years?

Personally, I'd love to see Ruby used as the next-gen language for Free Software application development. It rocks!

Re:Meh?

[OmniVector]

i agree. ruby also just got java bindings via jruby.

i'm looking forward to when we're closer towards a full fledged VM for ruby.. it's been interpreted since its inception as far as i know.

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

Re:Meh?

[E_elven]

As long as we're slinging around personal preferences... I hate QT (and disapprove of their business model -although at least they have one.)

For Ruby GUI stuff, FxRuby (FOX toolkit) is hands-down the most natural-feeling one in a Ruby environment.

Re:Meh?

[Anonymous Coward]

I hate QT (and disapprove of their business model -although at least they have one.)

Um, on what rational basis is 'having a business model' a critism?

For Ruby GUI stuff, FxRuby (FOX toolkit) is hands-down the most natural-feeling one in a Ruby environmen

And on what rational basis do you make this claim? You've evalauted the various toolkits or what? In which case you might like to enlighten us with a bit more detail, about the pros and cons of the toolkits, otherwise we might think you're a troll.

-- Richard

Re:Meh?

[Anonymous Coward]

Personally, I'd love to see Ruby used as the next-gen language for Free Software application development. It rocks!

It's slow, does nothing that Smalltalk wasn't doing better 20 years ago, and has crappy Unicode support to boot.

You might have guessed by this point that I disagree. ;)

Re:Meh?

[tcopeland]

Yup, there's a "tech preview" release of Rubydium right here.

Re:Meh?

[mike_sucks]

But Ruby is new and hip and cool! Anyway, you can't tell me that Smalltalk-80 has good support for Unicode. Wouldn't Squeak be a better option anyway?

Apparently there are Gnome bindings for Smalltalk-80. If so, what are you waiting for, get hacking!

Re:Meh?

[Anonymous Coward]

No, ruby doesn't have crappy Unicode support, and is the Unicode support for current Smalltalks any better? Why are you so hostile to a language which complements the Smalltalk dynamic OOP point of view? Cannot we agree that object oriented imposters such as C#, Java and C++ are our common enemy, if you feel the need to have an enemy?

-- Richard

Re:Meh?

[E_elven]

I said I disapprove of their business model but gave them a credit of at least having one.

FxRuby takes advantage of the standard Ruby features and seems like the smoothest transition between GUI and logic programming (I think GUI programming is painful). All of the toolkits offer basically the same functionality.

Re:Meh?

[Anonymous Coward]

Oh, I'm not saying that Smalltalk is a better choice than Ruby, merely that Ruby isn't a much better choice than Smalltalk.

I find it irritating that every few years someone releases a new scripting language, that is basically just Lisp or Smalltalk with new names for all the wheels the author has reinvented, and suddenly people are talking about how these new amazing buzzwords are revolutionizing programming.

Ruby is a fine language, but it's nothing new. It makes certain tasks very convenient, but it doesn't permit anything that we couldn't do before. It's very well suited to rapid GUI development, and it may well be the ideal language for Gnome applets, since computers are getting faster fast enough that it probably doesn't really matter that it runs an order of magnitude slower than Python and two orders slower than C++, particularly as it's going to spend most of its time waiting for user input anyway. But it's NOT SOME AMAZING NEW THING, it's just a good implementation of the same old concepts that people have been enjoying in academia, and bemoaning the absence of in mainstream languages, for decades!

Rant is over. We apologise for any trollish overtones.

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.

Re:Meh?

[Anonymous Coward]

Well said, excellent post. Can I add that being able to yield multiple results from a block is something Smalltalk doesn't have, and that came from Liskov's CLU language.

-- Richard

still waiting..

[Anonymous Coward]

.. for that perfect development environment (besides vi and the command line, anyway).

I'd love a Ruby IDE or "smart editor" but none of the ones I've used can even highlight synax correctly (ever had a regexp like this? %r{'\"(.*\))>} (just made it up) .. ever named a method with a string used elsewhere in the language? they NEVER get highlighted correctly and I end up just mentally ignoring the highlighting).

Also attaching Ruby to KDE, wow. Ruby is so small and elegant, and KDE is.. so.. large.

I much prefer RubyCocoa or whatever it's called that I used once. The Mac and Ruby are made for one another.

Re:still waiting..

[Anonymous Coward]

QtRuby, the Qt subset of Korundum runs fine on Mac OS X. KDE is only big because it does a lot. The Smoke library, that Korundum uses is indeed very large with nearly 1000 classes and 30000 methods.

The ruby syntax highlighting in the Kate text editor and KDevelop IDE mostly works, apart from 'here' documents. KDevelop also has a ruby class parser, and a basic Qt ruby project template at the moment.

-- Richard

Re:still waiting..

[neoneye]

AEditor can syntax color most Ruby
ScreenShots.

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

[Anonymous Coward]

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

You can do this in Korundum:

calltest = SenderWidget.new(nil, "calltest") { setText 'DCOP Call Test' }

To anyone not familiar with ruby - you can pass a chunk of code to the constructor, so you sort of got you're own customized constructor that does more than the usual one. Or do it this way to pick up the surrounding environment of the thing being constructed:

a = 'DCOP Call Test'
calltest = SenderWidget.new(nil, "calltest") { |w| w.setText a }

I don't think Korundum prevents you from coding in the style you describe in your second point. Note that an important target audience for the tutorial is people who are learning both Qt and ruby, and so KISS is more important than maximum rubyishness.

If you prefer lower case with underscores method name over camel case you can use that. Or you can write

if thing.widget?
#do conditional stuff

if you prefer that to:

if thing.isWidget()
#do conditional stuff

Something like this:

thing.setText("Some text")

can be written as

thing.text = "Some text"

I like the way the ruby-gnome bindings allow you to connect a signal to a block, so it would be nice if a future version of Korundum did something similar.

-- Richard

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.

and so?

[jeif1k]

The Qt/Ruby bindings are probably nice. But how do they bring something that wasn't there before? We have had Qt/Python bindings, Gtk/Python bindings, Gtk/Ruby bindings, wxWindows/Python bindings, and wxWindows/Ruby bindings. All of them are pretty nice and pretty easy to use. Several of them are supported by visual GUI builders. Qt/Rube seems like just another possible combination.

Re:and so?

[Anonymous Coward]

Well you can't write KDE apps with the other ones! And the more great ruby bindings the better..

A by-product of wrapping the KDE api is that you've wrapped the Qt api too. So QtRuby runs fine cross platform on Mac OS X, and would run on Windows too with very little work.

Note that you can use Qt Designer to create UIs, and then you can either compile the .ui file to ruby with the rbuic tool, or you can read it in directly at runtime using the qui extension and the QUI::WidgetFactory.create method.

-- Richard

Re:and so?

[jeif1k]

Of course, you can write KDE applications in Python; that's what PyKDE is for. And PyQt should work on Mac OS X and Windows as well (subject to the usual Qt licensing hassles).

wxPython works on all those platforms, too, and has GUI designers. So does PyGtk.

QtRuby looks like another reasonable binding, but functionally, it is just more of the same. Even the differences between Ruby and Python are negligible these days, since Python has blocks and all those other Ruby feature, too.

Re:and so?

[Anonymous Coward]

Both PyKDE and Korundum are in the kdebindings module and should be part of every KDE release. I'm personally keen that KDE is seen as a great development environment for scripting languages, and not just C++.

Ruby blocks are used much more pervasively than in python, so the 'feel' of the two languages is different. All ruby loops use blocks for instance. I think python blocks can yield multiple results like ruby ones, but they don't take a 'snapshot' of their surrounding environment - ruby blocks are 'closures'. I'm not very familiar with python, so I might be wrong about that though.

Also ruby has continuations and the Continuation.callcc method allows you to do something like the setjmp/longjmp in C, which I don't believe python has.

-- Richard

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:and so?

[CatGrep]

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

You're absolutely right. However, I do tend to prefer Ruby's syntax for blocks over Smalltalk's, but that's a matter of taste.


they're referred to as closures,


In Ruby a block is an anonymous closure.

Re:and so?

[jeif1k]

Python has lambda. So, you might write

map([1,2,3],lambda x: x*x)

Lambda is the standard name for "blocks" in CS.

Python also has list comprehensions, which are less general but more convenient:

l = [x*x for x in l if odd(x)]

Is it ok as a beginner's langage ?

[da5idnetlimit.com]

I'm a Linux user and all I learned from my 1+ year full Debian Desktop is mainly configuring Linux and getting the UI working the way I wanted...

Now I'm looking at some old Windows app and asking myself how hard it can be to build a GUI for some command-line only tools I now have to use...

So, is it ok as a beginner langage ? I mean all experience I have is with HTML and one have to start somewhere...

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.

AOTing the Rubydium to the maximum performance.

[Anonymous Coward]

Ruby is the succesor of Lisp because it can extend new classes or redefine new methods on the fly while than Lisp can create new lists.

Ruby is a powerful language for Artificial Intelligence because of his Dynamic OOP.

Can Ruby create humanoids that create new self-humanoids? WOWWWWWW!!!

open4free ©

Generic languages are not the solution

[Frans Faase]

Every so often a new language is proposed as the solution for the problem of developing applications. However, most of these languages are really generic programming languages. What we really need is a platform that centers around persistant data and views, with built in transaction mechanisms. Instead of a language to program in, we need a language to specify data centric applications.

Re:Generic languages are not the solution

[Anonymous Coward]

Like SQL?

Re:Generic languages are not the solution

[Frans Faase]

SQL is not a specification language, it is a query and data manipulation language, and does not have any transactional properties. It is not what I was thinking about. Most people don't realize that relations databases and object-oriented models are just "implementations" of more general data structures.

Re:Generic languages are not the solution

[Eivind Eklund]

I'm not sure I agree with you. We need a good way to interface with the relational model, but I am uncertain if we need a special language for this.

I'm finding that the logic of my systems goes up into the domain space where I want OO a lot, *and* that they go down into the database where I want the relational model a lot.

I agree with you that embedding SQL or query interfaces strongly based on SQL does not cut it; however, I'm uncertain if a special language will cut it, either.

I'm presently working on an implementation of the relational algebra directly in Ruby. I do this by generating SQL, but having objects representing relations - full relations, not tables - in Ruby. I hope this will help me by giving full flexibility for relational manipulation both for production code and for the unit tests, while keeping the full OO model available for the cases where this is more appropriate.

Eivind.

Note that Korundum has a RubyForge project page...

[tcopeland]

....right here.

The activity graphs show a lot of recent movement, too... good times!

Konundrum? Bury? Lips?

[davidsyes]

My eyes are playing tricks on me.

Korundum works well on *NIX

[davidross]

Well just so people don't think Linux is the only target for Korundum. It works well on FreeBSD, it should work on any BSD, or any system which can compile the kde bindings in fact. I think this is a major jump for Ruby and hope that devlopers will continue to develop Ruby. Using KDE to develop applications makes it easy with the KDE integration. Thank you Alex(lypanov) for doing such a great job and also introducing me to this great software.

I hope in the future there will be even more expansion from what is already with the bindings. This project is certainly a need for the programming community. Happy coding!

--dross

Re:Korundum works well on *NIX

[Anonymous Coward]

Thank you Alex(lypanov) for doing such a great job and also introducing me to this great software.

Thanks for the complements. Note that there are two co-authors Alex 'Lypanov' Kellett and myself Richard Dale.

-- Richard

"fell flat"???

[jeif1k]

How did they "fall flat on their faces"? Python has full lexical closures and bound methods.

They aren't used as much in Python because it also has some other constructs that are often preferred by users (eg list comprehensions).

Re:"fell flat"???

[Abcd1234]

Well, my argument was specifically related to the "lambda" construct which, I'm sorry, is basically useless in it's current form. See the Python FAQ, sections 6.9 and 6.10. Of course, their argument is that "lambda" is simply syntactic sugar, so who cares? Just define a function. My argument is, why bother with a half-assed "lambda" construct in the first place if it's going to be ridiculously broken.

Re:"fell flat"???

[jeif1k]

That FAQ is way outdated. Lambda has access to variables in the enclosing scope. The syntactic restrictions on statements still exist, but (obviously) don't exist for named nested functions.

Generally, I would prefer having a syntactically unrestricted lambda/block in Python, but between iterators, list comprehensions, and functional lambda, the need for any kind of complicated nested block almost never arises.

In the context of how these languages are used, blocks just don't make a significant difference in practice. Writing a Gnome or KDE application isn't any easier in Ruby than in Python because of blocks.

Note that I generally think that syntax and scoping do matter: Perl and Tcl both have huge problems with syntax and scoping, but Ruby and Python do not IMO.

Is Ruby good for numerical computing?

[Latent Heat]

Sooner or later if one wants to adopt a language as a "solution to the programming problem" rather than limiting it is a scripting language, one will want to do numerical computing. And numerical computing means not only partial differential equation solvers, it also means doing any kind of graphics displays more complicated than the rich text-button-control-scroll bar kind of GUI.

To my mind, efficient numerical computing requires an intrinsic array type, because a lot of numerical computing has to operate at high speed on lists of numbers, especially graphics stuff. Interpreted/p-code/JITed languages that have been good with numerics (Matlab, Java) have an array type. Lisp didn't start with an array type but got one by the Lisp Machine/Common Lisp days.

A numerical array type (the built-in list types don't count because of the memory and speed overhead) is a work in progress in Python. The reason I say work in progress is on account of the Numeric/Numarray transition and that not all numeric/graphics packages for Python know about Numeric or Numarray so you take a hit getting lists of numbers in an out of them.

My bottom line for numerical computing (i.e. looking for a Matlab replacement) is 1) some kind of numerical array type that is 2) compatible with graphics routines for plotting graphs as well as bitmaps where I can specify the colors of individual pixels. Python is working on this (for example, TKInter has a bitmap canvas object, but can I get/set the bitmap raster as a Numeric or a Numarray?) Where is Ruby on this?