[02:15] <_ion> Any freenet 0.7 users?
[07:50] <_ion> http://johan.kiviniemi.name/software/random-background/random-background
[07:56] <Keybuk> hmm?
[08:08] <_ion> Sorry, that was offtopic. :-)
[08:08] <_ion> Just something i wrote just now.
[08:08] <Artanicus> seems you realy like ruby.. (:
[08:09] <Keybuk> I've yet to learn ruby
[08:09] <Keybuk> on first glance, it seems a little Python like, but without the nice syntax
[08:24] <_ion> keybuk: Some propaganda: http://johan.kiviniemi.name/stuff/python-ruby/ :-)
[09:09] <Keybuk> To get away with less typing, many Python programmers resort to making variables
[09:09] <Keybuk> (and methods) public even when there's no reason for them to be public.
[09:09] <Keybuk> that's not true
[09:09] <Keybuk> Python actively discourages private anything, with the "programmers are consenting adults" theory
[09:11] <Keybuk> __ is just a name-mangler
[09:11] <Keybuk> class Foo:def __*(foo)
[09:11] <Keybuk> just makes the method called __Foo_foo
[09:11] <Keybuk> so in your example, world.__World_double() is an entirely legal call to get at the "private" method
[09:13] <Keybuk> in general, that seems to be just a comparison of syntax though
[09:13] <Keybuk> what's different about the /language/
[09:13] <Keybuk> ie. what can I do in Ruby that I cannot do in Python?
[09:27] <LarstiQ> _ion: I'd also disagree with that section on private methods, it doesn't reflect python reality
[09:28] <LarstiQ> _ion: on len(obj) vs obj.len(), not sure if that is the reason, but len() will try a couple of different approaches
[09:31] <Keybuk> len is a built-in function
[09:31] <LarstiQ> _ion: also problems with "self", notation of instance variables and an example of a class
[09:31] <Keybuk> it just calls obj.__len__()
[09:31] <LarstiQ> Keybuk: afaik, it can handle __len__ not being there if it has __getitem__
[09:31] <Keybuk> it's a shame they didn't just make it a default len() method, but then early Python wasn't as "everything is an object" as modern python
[09:32] <LarstiQ> but yes, that might have something to do with it too
[10:42] <_ion> 0) "Python actively discourages private anything"  yes, therefore i like Ruby more. :-) If you like Python more, that's your right. 1) Everything you can do in Ruby, you can do in Python, C, Haskell, Java, Lisp, 68000 asm etc. They are just different. Well, Python doesn't support closures. That's actually a very big win in my opinion. Some people don't regard them as useful (often Python advocates, it seems), and that's their right.
[10:42] <_ion> That page is just my personal opinion, and everyone has (and should have) one. :-)
[10:43] <Keybuk> "closures" ?
[10:44] <_ion> http://martinfowler.com/bliki/Closure.html
[10:45] <LarstiQ> python does support closures afaik
[10:45] <_ion> Creating and referencing functions inside a function does not equal a closure.
[10:45] <_ion> http://mail.python.org/pipermail/python-list/2004-July/229478.html
[10:45] <Keybuk> http://ivan.truemesh.com/archives/000392.html
[10:46] <Keybuk> that page gives you the Python examples
[10:46] <Keybuk> ok, so Ruby has first-class closures
[10:46] <_ion> If you read that page, you'll notice all the examples are oneliners.
[10:46] <Keybuk> what does Python have that Ruby doesn't?
[10:47] <_ion> That is not very handy. Python has lambda, but it doesn't support multiline code.
[10:47] <_ion> Well, currently Python is faster.
[10:47] <LarstiQ> explicitly by choice.
[10:47] <Keybuk> is everything in Ruby also an introspectable object?
[10:47] <_ion> Ruby 2.0 will have a new, fast VM.
[10:47] <LarstiQ> _ion: I'm fine with opinions, but your examples are not how one would write python code, so it's not a fair comparison.
[10:48] <LarstiQ> Keybuk: yes, and you can change the builtin types
[10:48] <_ion> Those are examples of how i would write python code. :-)
[10:48] <Keybuk> so functions are objects, which you can add methods to, or replace?
[10:48] <LarstiQ> _ion: right, you're more writing ruby in python then
[10:48] <Keybuk> so to make some Ruby code up
[10:48] <Keybuk> class Random
[10:48] <Keybuk>   def initialize
[10:48] <_ion> larstiq: No. I first learned Python, then found Ruby.
[10:49] <Keybuk>     @foo = @bar
[10:49] <Keybuk>   end
[10:49] <Keybuk>   def bar
[10:49] <Keybuk>     ...
[10:49] <Keybuk>   end
[10:49] <LarstiQ> _ion: so? It's not pythonic
[10:49] <Keybuk> end
[10:49] <Keybuk> Random.new.foo
[10:49] <Keybuk> does that work?
[10:50] <LarstiQ> Keybuk: one thing that python has is more libraries
[10:50] <Keybuk> LarstiQ: meh, Python's standard libraries SUCK
[10:50] <_ion> @bar (an instance variable) and Random#bar (a method) are different.
[10:50] <_ion> class Random
[10:50] <Keybuk> the most irregularly inconsistent mish-mash of crack on earth
[10:50] <_ion>   attr_reader :bar
[10:50] <_ion>   def initialize
[10:50] <_ion>     @bar = 42
[10:50] <_ion>   end
[10:50] <_ion> end
[10:50] <_ion> Random.new.bar returns 42
[10:50] <LarstiQ> Keybuk: that may be, ruby has less available
[10:51] <Keybuk> _ion: that's not what I mean
[10:51] <Keybuk> could I go  #foo = #bar
[10:51] <Keybuk> ie. create a new method foo that's a copy of the bar method?
[10:52] <LarstiQ> ruby has a distinction beween instance and module attributes, (and private/public), which is something I don't like
[10:52] <Keybuk> (and ruby doesn't appear to be able to spell "initialise" :p)
[10:52] <_ion> class Random
[10:52] <_ion>   def bar
[10:52] <_ion>     42
[10:52] <_ion>   end
[10:52] <_ion> end
[10:53] <_ion> Random.class_eval { alias :foo :bar }
[10:53] <Keybuk> _ion: can I do Random.foo = Random.bar
[10:53] <_ion> Random.new.foo  # 42
[10:53] <Keybuk> right
[10:53] <Keybuk> so it appears that a major feature Python has over Ruby is that everything, including methods, is an object
[10:53] <Keybuk> and that everything is introspectable
[10:53] <Keybuk> Ruby appears to lack that
[10:55] <Keybuk> a method in Python is just an object of a particular type that implements a __call__ method that executes the attached Python bytecode, etc.
[10:55] <Keybuk> oh, another way of doing closures in Python, apparently:
[10:55] <Keybuk> def foo(self, a, b, c):
[10:56] <Keybuk>   def closure():
[10:56] <Keybuk>     return a
[10:56] <Keybuk>   some_call(closure)
[10:56] <LarstiQ> that would be _the_ way to do closures?
[10:56] <LarstiQ> although 2.5 has partial()
[10:56] <Keybuk> that has the same "is executed in the namespace of the calling function" requirements
[11:00] <Keybuk> of course, the key point about any language is the applicability of that language for certain tasks
[11:00] <Keybuk> if you're doing low-level systems programming, then you write it in C
[11:00] <Keybuk> if you're doing any kind of text munging, you write it in Perl
[11:00] <Keybuk> Python seems to be winning for rapid tool and application creation
[11:01] <Keybuk> there's a battle between C# and Python for "best GUI development" language
[11:01] <Keybuk> I've not yet seen anything that makes web apps easy
[11:03] <Keybuk> Perl, PHP and Python all seem equally bad at it
[11:03] <Keybuk> Ruby on Rails seems popular this week
[11:03] <Keybuk> though I must admit, from looking at the code of Typo, I can't see why
[11:04] <LarstiQ> heh, Typo is in ruby and Typo3 in php? Joy :)
[11:10] <Seveas> Keybuk, ever looked at django for webapps?
[11:11] <Amaranth> django is the shit
[11:11] <Amaranth> and it's been around quite some time so it's not just a fad
[11:11] <Seveas> (the django lead dev uses ubuntu ;))