Yesterday night Zack Rusin made a guest appearance on The Linux Link Tech Show. He discussed recent developments in the X.Org project, Qt, KDE, his life in Norway and some other Open Source related issues. It is a lengthy interview that should satisfy those who say Zack's not blogging and responding to questions often enough. Download the recorded Ogg file or MP3 file.

Comments

Do you mean star icon on the article (next to the text)? I think that is only a icon represents articles related to "KDE Public Relations and Marketing" - like double gears icon for developer articles, Qt icon for Qt related articles, etc etc... Correct me if I'm wrong ;)

...and TLLTS, nice ~1:45 of interview!
good to hear this nice overview mixed with some interesting insights.

_cies.

p.s.:
zack: the day i became a veg, was the day i decided to learn how to cook. i'm not looking back (by now my roommates aren't either).
guys from TLLTS: what are you guys smoking? i must get some of that shit. ;)

zack says he likes ruby but not too much python one of the reason being its unicode handling, the fact that you need to use a module and stuff. Well last time I checked unicode is kind of a bitch too on ruby, if you want to use strings functions it won't work either you need to use special plugins or modules last time I checked, right?

none at all with a comprehensive solution coming is better than half-assed with a fix maybe coming. sort of explains why ruby resonates with a lot of kde (and other) developers and python simply seems "ok"

Hi Aaron,
I gave up on Ruby for now precisely because it doesn't support Unicode natively while Python does, or so I thought... It has a Unicode data type that's fully interchangeable with raw strings for all of its string-related functions (and also with QStrings, which is cool), and I've been using it a lot to fix encoding fuckups in output from other languages (not just Ruby though)... Am I missing something? Have I been doing something wrong with Python and never known it? c_c
Thanks!

As far as I know, Python does have native Unicode support, but when you define a string it isn't Unicode, unless specified to be so (with the exception of MacOSX where unicode is always used). However, I don't know Python in depth... I am just as puzzled about this as you are.

I've created a couple of linguistics applications with Python that needed really good unicode support and I never had a problem. Should the class that's currently called "string" be called "bytearray"? Sure. Should the class that's currently called "unicode" be called "string"? Sure, that too. Does "unicode" provide everything you may need from a string class including regular expressions? Definitely. There are currently two languages that handle Unicode really well: Python and Java. (And there's, as far as I know, one toolkit that does handle unicode really well: Qt.)

No, Ruby doesn't resonate with _this_ kde developer at all. Ugly syntax, slow, full of hot air... There is nothing in which Ruby improves on its examples, Perl and Python. The reason it resonates with some people is probably that it's new, but then, there'll always be something else that's new for them.

All my ruby loving friends always say: "but ruby-on-rails!"
So the best thing about ruby seems to be that webframework and it is the only reason so many people choose ruby over python. If ruby-on-rails won't exists, I think there would be much less ruby-lovers. I don't know if this people would use python instead, but the killer feature of ruby is not the language or std-lib itself, its ruby-on-rails.
(Well, I don't write web applications, so I use python.)

That's the killer app, but it's a killer app made possible only by the language itself. I'll admit to not being very familiar with Python, so I'll merely speak to the aspects of Ruby that make Rails possible, or at least prettier -- things like blocks and the ability to catch calls to missing methods and do things with them, for example (part of the way dynamic finders are implemented), as well as the ability to extend existing classes (used by Rails to, for example, extend the Fixnum class so one can write `1.day.from_now' and get a DateTime object that represents 24 hours from now). Rails is well-appreciated because it's so readable, and it tends to be readable at least in part because of Ruby's syntax (which for some reason a lot of people seem prone to describing as horrible) and language features.

That said, you won't hear me saying `but Ruby on Rails', you'll hear me saying `if you don't like Ruby, look to Rails to see what it's capable of'. I'm using Ruby for simple scripting, as well. And from the little I've seen of Python, the little inconsistencies in the language (when does one use methods vs functions on objects, for example?) would drive me up the wall (and do, when I'm helping students with their homework). But again, my experience with it is very limited.

As a side note, that has nothing to do with Unicode support in Ruby, which is, indeed, not very good at all. But, the intent, as I understand it, is to address that in Ruby 2, as well as some of the speed issues, and to bring in a new regular expression engine with neat little features like named backreferences. So the future is definitely something to look forward to in the Ruby world.

the ability to catch calls to missing methods and do things with them [...], as well as the ability to extend existing classes

This is a feature every "dynamic" language (should) have, so python has it of course.

Well, for optimisation reasons python does not support changing builtin types (in, long, str) and binding types (if that is the proper term) like QString. But you can of course change derived classes in any way.

Another neat feature of python are generators (the yield satemetn) and with-blocks (since python 2.5).

Generators seem like one specific instance of blocks. I can't say for sure that they are exactly the same. In Ruby, a block is, much the same way, called with yield (and possibly with parameters, such as the statement `yield a, b', which will pass `a' and `b' to the block). Ruby exclusively uses blocks for iteration, however, such that:

for i in (1..10)
p i
end

Is the same as:

(1..10).each { |i| p i }

(Parameters to a block are specified between || symbols, blocks are delimited either by {} or by do/end).

These blocks, combined with mixins, let you do neat things. For example, if you provide the `each' method, which takes a block, you can use the Enumerable mixin to get things like:
* select (return an array of all items for which the block does not evaluate to false)
* inject (pass a variable around as an accumulator to every instance of a block -- i.e., a sum could be `(1..10).inject( 0 ) { |sum, num| sum += num }'
* reject (return an array of all items for which the block *does* evaluate to false)
* collect (an equivalent of Python's map, but done by providing a block to be evaluated; e.g. `(1..10).collect { |number| number * 10 }' to get an array of every number from 1-10 multiplied by 10)
* .. etc.

I'm also a fan of being able to pass parameters to methods without parentheses in certain circumstances (though I understand why some people hate it):

"No, Ruby doesn't resonate with _this_ kde developer at all. Ugly syntax, slow, full of hot air... There is nothing in which Ruby improves on its examples, Perl and Python. The reason it resonates with some people is probably that it's new, but then, there'll always be something else that's new for them."

Well, I think Ruby and Python both have their advantages and disadvantages, and people should make their own minds up which they prefer. I think it's important that we ensure KDE offers first class support for both.

Ruby has open classes, including customisable instances (you can add methods to individual instances), iterators that use blocks and yield, continuations, mixins, no need to pass 'self' to instance methods, and plenty enough things to make _self_ kde developer resonate. Ruby is slow, but UIs built with QtRuby or Korundum are not slow because most of the code that gets called is C++ of cources.

To use Unicode for a QtRuby or Korundum app with Qt Designer, you need to pass a '-KU' option to Ruby, and optionally include a "require 'jcode'" in the code. It doesn't have complete Unicode support, but that is not the same as having no Unicode support.

I find that really funny having written an awful lot of Python with Zope over the years. Python's syntax is bloody awful. The indentation thing was just one of the acts of lunacy (might be good in some circumstances, but not generally). My comfort level goes up when I start using Ruby and Visual Basic (yes, VB) again. If people want to attract VB developers to desktop level programming then you ain't going to do it with Python.

Explicit 'self' parameter to methods is another thing that I dislike, and is possibly worse than the indentation. The keywords 'this' in Java and 'Me' in VB are used when you need them - within scope. And double underscores to indicate private? No, it just won't do. You are also never going to convince a VB or desktop developer of any kind of this:

def sayhello():
return 'Hello, world!'

foo = sayhello

print foo

versus this:

def sayhello()
return 'Hello, world!'
end

foo = sayhello

print foo
Hello, world!=> nil

(Indenting won't come out - guess what's more readable?)

Yes. hello() evaluates to 'Hellow World' in Ruby. Novel concept eh?

"Perl and Python"

Ugly syntax again? Perl?

"The reason it resonates with some people is probably that it's new"

No, it's just that it's plain better - especially if you want to do OO programming. We've gone beyond the initial hype to the stage where everyone asks "Is it really better?" The answer is still yes. Frameworks like RoR simply make web apps easier when compared with Java or .Net. Even Joel Spolsky seems to have had an internal argument with an intern perhaps, about Ruby and RoR, to the point where he's having to badmouth Ruby:

You then get various graphs telling you that Python, or something else, is more in demand than Ruby and that you shouldn't be using it neglecting to point out that Ruby is a relatively young language and framework.

Is Ruby slow in places and does it need to be improved? Yes. Will it be? Considering the interest and development on Ruby, I'd say yes. Does it mean that we should use Python instead? No.

Ok, ok, ok. Let's all calm down. I don't say ruby is bad, I only say python is good and it's definitely not significant worse then ruby and I also think ruby is not significant better than python: python and ruby are much the same. I don't know a lot about ruby, but it seems that both languages are approximately same good.

Things like len(obj) and __* to make something private are ugly indeed. It would be cool if this would change in python 3.0.

But I actually like that you can distinguish a function call from passing a function/callable object as parameter. How do you pass a non-argument function in ruby as a parameter? Or is ruby like haskell sideeffect free?

Then I have to google what things like mixins and blocks are. First heard of them in this thread.

I read on wikipedia what those features are: I think in one way or the other they are all supported by python. I don't know if the syntax for those features is "better" in ruby but that depends on taste anyway. So the decision between python and ruby is a decision by frameworks/available libraries and taste. :)

"I don't say ruby is bad, I only say python is good and it's definitely not significant worse then ruby"

Well, no it's not significantly worse. Think of this in the context of developing desktop apps, and a VB developer coming over to develop KDE apps in a decently clean OO language that's easy to pick up. That's how I'm looking at this.

"Things like len(obj) and __* to make something private are ugly indeed. It would be cool if this would change in python 3.0"

I really hope so. All we're talking about here is syntax really. There may be some design decisions in terms of how Ruby views things in an OO world that may come out later when we can more adequately compare Python and Ruby.

At the moment, syntax arguments get in the way. Python needs to do a bit better there.

I come from a C/asm/C++/Java background. So Python's take on OOP makes the most sense to me. Function or method calls without brackets just don't feel right at all. While people who are used to VB or Smalltalk might find Ruby a more natural fit.

"I thought the same, then I tried Python and after 15 minutes I was used to it. Braces and 'end' statements look like clutter to me now."

Hands up, yes. I never thought too much of it myself, even when I first started using Python. However, for a VB developer looking to develop some KDE apps in an equivalent language? That's a tough one. We don't want a VB clone by any stretch, but something with enough reasonably clean and English-like syntax with emphasis on decent OO development.

I was a VB developer (3, 5 and 6) when I first met Python, seven or eight years ago. I took to it like a duck to water. It was the equivalent language for the equivalent purpose. Already in 1999, with PyKDE, python the best and most productive way to develope gui applications on Linux.

Of course, Python wasn't just the vb-on-linux that it appeared to me at first: it was the stepping-stone to higher things, like coding C++, which means regularly waiting twenty minutes to see if a bit of code I wouldn't have had to write had I used Python does or does not cause a crash.

> I come from a C/asm/C++/Java background.
> So Python's take on OOP makes the most sense to me.

Interesting. I come from a asm/Java/C/C++/Perl background, and I find Ruby's OOP much more natural... sort of like Java without the misjudgements.(Like no primitive types!) I've never really gotten into Python despite a few tries. It feels like another Perl to me, and while I love Perl as a crazy testbed... I already know one perl.

But I have had very little need of unicode support, so that is a difference that might make python worthwhile.