Ruby is lol Object Oriented. That's why you can do -5.abs. In Java you would have to do Math.abs(-5), but Ruby is lol Object Oriented so you don't have to do that shit.
Unless you want to do say 1012.log10. Sorry, seems you have to do Math.log10(1012) after all.
Name:
Anonymous2006-03-11 7:22
Ruby's documentation leaves room for improvement.
"The options parameter is a hash of options, taken from the list :force, :noop, :preserve, and :verbose. :noop means that no changes are made. The other two are obvious."
No, fuckers, it's not obvious, and the other THREE should still be documented.
Name:
Anonymous2006-03-11 10:28
>>1
In Ruby you can add extra methods to any class you like. Number doesn't have a log10 method? Well: class Number
def log10
Math.log10(me)
end
endUnlike Java you don't have to rely on Sun implementing all the functionality in the classes you use. You add your own as necessary, without stupid subclassing.
Name:
Anonymous2006-03-11 10:29
>>3
Er I meant "self", I don't know why I wrote "me".
Name:
Anonymous2006-03-11 10:33
>>3
I am well aware that I can add methods to existing classes. That doesn't excuse the fact that the original libraries are inconsistent. Or make the babbling about lol lol object orientation any less annoying.
Name:
Anonymous2006-03-11 11:21
>>5
If you don't like OO then stop using Ruby. You troll.
Name:
Anonymous2006-03-11 12:10
PROTIP: Undocumented libraries aren't really usefull, just frustrating. Documents in moon language don't really help eather.
I also don't think the source code of the libraries should be documented in moon language.
Name:
Anonymous2006-03-11 12:11 (sage)
I also don't think the source code of the libraries should be **commented** in moon language.
Name:
Anonymous2006-03-11 19:32
Further observations:
In Ruby, constants start with an uppercase letter. Unless they happen to be nil, true, or false. Sucker.
Name:
Anonymous2006-03-12 0:29
Ruby's libraries are inconsistent, no doubt. There are a fair number of things that really need to be fixed.
However, the semantics of the language are, by and large, quite nice. Considering the trivial issues with the library, it's livable.
Name:
Anonymous2006-03-12 8:04
One could make the case that putting log10 in the Math module is actually a good thing. In maths, we never say x.log10, we say log10(x). As Ruby supports "mixins" you can just include Math in your project and you can call log10(x) any time you like. Ruby may be purely OO, but it doesn't ram it down your throat, unlike certain other languages...
Name:
Anonymous2006-03-12 8:22
The object oriented way, x.log10, etc. looks a lot better when chaining things together IMO.
Name:
Anonymous2006-03-12 17:09 (sage)
>>11
When working with ruby, you want to do it the ruby-looking way, not the math-looking way.
Name:
Anonymous2006-03-12 19:33
OO OO lol
a.b(c) is really superior to b(a, c)
>>11 In maths, we never say x.log10, we say log10(x)
We never say x.abs either, we say abs(x)
Name:
Anonymous2006-03-12 21:25
c(b(a(w,x),y),z)
^-- ugly as fuck, need to break it into multiple lines/vars really
w.a(x).b(y).c(z)
^--perfectly fine
Name:
Anonymous2006-03-13 0:25
>>15
if you name your functions like this you'll need a lot more than OO to solve your problems.
>>19
Are you sure ? I think it's a statement. Care to explain ?
Anyway, in pure OOPL 'if' should be a method, like Boolean class in Smalltalk has #ifTrue: and #ifFalse: methods.
(1 > 0) ifTrue: [ '1 is greater than 0' printNl ] !
As far as I know in Ruby 'if' is just a reserved word.
Name:
Anonymous2006-03-13 7:13
>>23
It's an expression, I'll demonstrate. If it were a statement you could only do: if(foo) {
a = 1
}else{
a = 2
}
Name:
Anonymous2006-03-13 8:52
Hm closest I can get to your crazy OO.if method is:
class TrueClass
def if(trueProc, falseProc)
trueProc.call
end
end
class FalseClass
def if(trueProc, falseProc)
falseProc.call
end
end
Name:
Anonymous2006-03-13 13:18
>>20
Ew. Don't tell me this doesn't suck. Besides, what's the obsession with pure OO?
Chocolate is good. Let's make food pure chocolate?
Name:
Anonymous2006-03-13 13:55
>>26
I rather like that approach, though it takes an unusual mathematical background to appreciate, and having to use explicit blocks is ugly -- I'll take functional programming over blocks any day.
But the point of this thread is just a reaction to the boasting of the Ruby fanboys.
Name:
Anonymous2006-03-13 15:23
>>27
I'd rather take the we support everything and are open 24 hours approach.
Name:
Anonymous2006-03-16 8:44 (sage)
I'd rather go to /b/ than take this bs here!
Name:
Anonymous2006-03-19 11:01
Ruby really needs to clean up and document their stdlib properly. Ruby fags: PERL WAS DOCUMENTED, WHY COULDNT YOU STEAL THAT INSTEAD OF $. $| $/ $\ $" .
Oh wait I know you use operator overloading instead so we can't figure out what types you are using til we run it.
>>32
Perl in a nutshell: #$%&&&#("#$%&%(%#$&(//%&"%&$/($E(#"W45
Name:
Anonymous2006-03-19 18:04
Perl's documentation is godly compared to Python, even if Perl itself is nasty.
Fucking hell, what is wrong with the Python bunch? You don't need to be a genius to write good documentation.
Name:
Anonymous2006-03-19 18:16
youre all homos who can only program one-liners to prove stupid points on the interweb
get fucked losers
Name:
Anonymous2006-03-19 22:43
>>34
I've studied Perl, PHP and Python, and my feeling is that PHP's >>> Python's >= Perl's.
Name:
Anonymous2006-03-20 1:28
Python's better than Perl's? I can't see it.
Python's API is a lot more fluid than Perl's, and Perl's documentation provides more examples. Python's is also so rigidly organized that it makes it a pain to dig through without a search engine. It also does a marvellous job of often forgetting to mention relationships, which is a major detriment in an OO language.
In the end it amounts to this: if I have a problem I can usually find a solution for Perl in a couple minutes (which is often, thanks to the mess Perl is). If I have a problem in Python, often it takes several hops around the documentation to determine what's going on. I no longer use Python's official documentation, it's so bad.
Name:
Anonymous2006-03-20 2:05 (sage)
PHP's documentation really is the best, which is good because nobody can remember the inconsistent function names and argument orders.
If I have a problem with some Python code, I generally just read it to find out what it's doing. Then I wonder why the fuck the authors chose to do it that way.
Name:
Anonymous2006-03-20 20:24
Oh, that brings up another pet peeve of mine: not only does the documentation suck, the python bunch don't comment much either. They expect you to read the code. Oh, wait, I don't have time for stupid minutiae in your code.
Talk about lack of discipline. They're no different from the perl and ruby twits in this regard. Maybe even worse.
Name:
Anonymous2006-03-21 7:11
>>41
I don't have enough experience working on others' Python code but the couple of projects I looked at have no documentation. I like how Python forces people to indent their code, but I still have to read all the crap if you have a function which accepts parameters like (a, pn, x, lol) and no docstring. It's a pity and not Python's fault though; in fact Python made documentation strings part of the language with the purpose of helping documentation.