I am learning Ruby right now, to play with Ruby on Rails, and I don't know yet wether I like it or loathe it, it looks pretty much like the illegitimate child of Perl and Python, which sounds very wrong.
What are your opinions about Ruby?
No, no, Ruby is "the bastard child of Smalltalk and Perl." Not Python, Smalltalk. Let's be consistent in our dissing of Ruby here.
And yeah, I agree completely that that is what it is, but whatever you find useful...
So should I run away while I still have time, or should I pretend I like it until I actually do?
How about pretending to run away until you actually do?
The bastard child of Smalltalk and Perl can't be any worse than the bastard child of Smalltalk and C - hello, Objective-C!
I mean, Perl is messed up from the start, it's not like you could easily make it any more strange.
Hate it. Hate Perl too, though, so it's no surprise.
Love it. It's smalltalk with clear syntax and just the right amount of sugar.
You shouldn't jump straight into rails, though, IMO. Although it's a great web framework, it just doesn't feel like ruby to me.
>>7
I am only learning Ruby so that I can evaluate Rails right now, do you mean that trying out Rails without enough Ruby experience is going to make me waste time, or to make learning Ruby much more difficult?
Ruby is nice, but it looks like it's going to start getting weird syntax in 1.10. Which is a pity.
>>6
What's so similar between Ruby and Perl that it's unsurprising that if you hate one, you hate the other?
How about they start getting rid of some weird syntax first?
Ruby proponents love to joke about semicolons, but then replace that problem with @. There's the really strange ".." vs "..." You can't type variables if you want to. #{} makes some strings look like linenoise. Regex is hamstrung. "end" is questionable.
If you fixed the first three, a significant source of errors would just vanish. Why Ruby replaces s/// with sub/gsub is beyond me. #{} needs to die.
Anyway, Ruby really is superficially quite similar to Perl, which is why I like it. I think of it as Python for Perl coders. If only it was faster (is YARV ready for prime time?).
>>7 It's smalltalk with clear syntax
LOL, what ? Obviously you have never written anything serious in Smalltalk.
>>8 I am only learning Ruby so that I can evaluate Rails
Smalltalk is superior. Take a look at http://www.seaside.st/.
>Smalltalk is superior. Take a look at http://www.seaside.st/.
...that site is kind of b0rked for me.
>>11
So basically your post is stating that smalltalk is superior to ruby, and is backing it up by stating that you have experience in smalltalk and accusing >>7 of not having any?
> Smalltalk is superior. Take a look at http://www.seaside.st/.
Only took like 2 minutes to evaluate it, but I am running away. There are too many big words on the front page and way too little big picture explanation, and of course no real-world example, let alone any large site or commercial site example. Is it really supposed to be used to make real sites?
I hope you can prove me wrong on this.
>>11,14
What does Seaside does better, more, faster or differently that Rails?
> And I can't understand why you want static typing?
Because I don't like it when I mistype a variable, and instead of telling me about it, it silently makes a new one? If it catches something that stupid right off the bat, it saves me wondering why the code doesn't work.
Same applies for @. If I forget the @ in front of the variable, does it tell me about it? Nope, it just makes a new one, because @somevariable and somevariable are different things.
I don't particularly care about the other aspects of static typing, I just want to know if something like the above occurs.
Talking about which, explain to me why sub does two passes.
Okay, Ruby ripped of some ideas from Perl, including regex. GJ! Unfortunately, it didn't include the rather terse s/// syntacitic sugar. Fine, it's not pretty, but I can live with that. However:
i = '\\'
puts i.sub(/\\/, '\\')The result is a single backslash. What about this:
i = '\\'
puts i.sub(/\\/, '\\\\')Should give two, right? No, it gives one. If I want two, I need to use either '\\\\\\' or '\\\\\\\\'. Or I can use:
i = '\\'
puts i.sub(/\\/) { '\\\\' }Least surprise? I think not.
>>16
If you need an object to behave in a certain way, check whether the methods you need are available ("string".respond_to? :split)
If you need an object of a specific class, well, nothing is stopping you from doing "string".is_a? String
Oh, and @somevariable is an instance variable, somevariable is not. They shouldn't be the same.
PS. Static and strong typing aren't the same thing.
That's... Just plain bizarre. Escaping backslashes is a huge pain to get right as it is, and making it even weirder is definitely not a good thing.
> Talking about which, explain to me why sub does two passes.
What do you mean by that?
>>19-20
Could you give me an example of the sort of situation you're talking about? Do you mean doing something like this:
@mister_var = 1
@miszer_var # Oh noes it's returning nil and not raising an errorI know that static and strong typing are different things, my point was that a lot of the issues people usually have with dynamic typing can in fact be solved in other ways.
Close, but a bit artificial.
You might make an error that returns the wrong object, but it's far more likely you'll do something like this:
@color = 10
...
@colour = yield
...
@colorWhoops.
I'd rather that Ruby had something similar to Perl's strict mode and my keyword. Happily enough, Ruby 2.0 apparently will have this (but when it finally comes out is another question).
>>22
Precisely what I said. Apparently the regex engine passes through the string twice.
Don't believe me? Run the posted code and prefix a puts or print in the second expression.
Looks like puts is already there. Just execute it.
>>13 > So basically your post is stating that smalltalk is superior to ruby, and is backing it up by stating that you have experience in smalltalk and accusing >>7 of not having any?
No, not exactly. First I was commenting on >>7 statement about syntax. Because Smalltalk really has best syntax ever, it's very simple, clean and consistent, nothing I have ever seen comes close to it. It is clear that only real reason why someone could not like it is because he has not used Smalltalk for reasonable time.
Then what I was saying was that, if >>1 is learning Ruby just for Rails then as good he could learn Smalltalk for Seaside, because Smalltalk is superior. And I was not backing this up by anything, that's different story for different thread. Feel free to let me know if you would like to hear that story...
As an aside, "simple, clean and consistent" syntax is good for computers, but not for humans. We thrive on redundancy and expressiveness. It is possible to produce turning-complete langauges with a single instruction, which is pretty simple, clean and consistent. Doesn't make it good syntax for programming in, though.
> Is it really supposed to be used to make real sites?
Check out Dable DB [1] ( demo video [2] ), it's one of those fancy and totally useless web applications that kids now days do, but it does look pretty complicate, if something like this can be done than anything else should be possible too, right ?
>>15
I fear that I wont be able to provide any further insight about Seaside, I really don't care neither about it nor Rails.
[1] http://smallthought.com/
[2] http://smallthought.com/clips/lispvan.mov
>>27
I am >>13 and >>1. It sure demonstrates that the system can be used for actual applications, but it just doesn't have "Holy fucking shit I want to use that" factor you can see in this video:
http://www.rubyonrails.com/media/video/rails_take2_with_sound.mov (50MB, 15 min., sound)
I have seen today how it was possible in Rails to put together a form with an autocomplete like Google Suggest that fetches candidates from the database, with only 3 simple lines of code. That's the kind of thing I like having, and I think that unless there's some big issue that has yet to hit me, I'm hooked.
I should receive "Agile Web Development with Rails" from Amazon monday, but thank you for recommanding alternative tools.
Regarding Ruby, I am starting to like it. Learning about the way it does some things was quite the head trip, but then I had no serious experience with a true 100% OO language. I agree that it looks very noisy, though, and since it looks like that comments are against Ruby coders' religious belief, it's a bit difficult to find interesting apps to read. I believe I could get used to it though.
irb(main):003:0> puts "\\".sub(/\\/, '\\\\')
\
=> nil
irb(main):004:0> "\\".sub(/\\/, '\\\\')
=> "\\"Ahem :O. puts interprets the string exactly the way it should. The stray "\" at the end is cut off as it doesn't seem to escape anything.
>>31
Waah, regular expressions and backslashes make my head hurt.
You missed the problem, >>31. Let me clarify:
puts "\\".sub(/\\/, '\\')
puts "\\".sub(/\\/, '\\\\')Result:
>ruby test2.rb
\
\
>Exit code: 0Also, to make it a bit more readable:
irb(main):002:0> "a".sub(/a/,'\\\\')
=> "\\"
irb(main):003:0> "a".sub(/a/,'\\')
=> "\\"Wow, that really makes no sense whatsoever.
Argh. I completely forgot that "\\" is actually a single \, because irb displays a string escaped >_>. Forget what I said about puts cutting off an \.
Also, I found this on the mailinglist: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/99784. So, uh, yeah. >:O.
By the way, what do you need this for, anyway? Just curious.
> By the way, what do you need this for, anyway?
Once I became aware of it, nothing. I'll just use code blocks instead. I'd rather the trap didn't exist though, because (like any language) it's another quirk to be aware of and work around.
Actually, I'd much rather just have s///, but I digress.
I've used this exact construct a number of times. You'd use it when creating string literals that need escaping. In this case, the extra escaping would probably make the code a no-op.
> I don't know yet wether I like it or loathe it
Now ~2 months later I love it, but maybe it's only because of all the concepts it introduced me to or helped me understand better. It's pretty much the only scripting language I use now, and its interactive shell is really great to try out things. I shouldn't have discarded it as some kind of wapanese curiosity when I first heard about it.
I was reading through this thread again and I came across this:
> and since it looks like that comments are against Ruby coders' religious belief
Argh! ARGH! ARGH! I have the same problem with python code. They seem to think they don't need to comment anything!
Recently, as part of my job, I had to interface several python programs together. There were almost no comments in the third-party programs, and the code other people on my team write contains no comments at all, other than the occasional "# XX: fixme". I'm the only person who bothers to comment and document anything.
Sorry guys, I don't give a flip about the details of your code. I just need a general idea of what's going on. Reading every last expression because you're too lazy is a waste of my time.
Tying this back to Ruby: I've found Python a bit of a disappointment. It's a nice language and all, but having fooled around with Ruby first, Python's syntax seems to me to be growing hair everywhere.
>>39
When I wrote that, I didn't know about a lot of ruby idioms, so a lot of 'self-explanatory' code looked like line noise, but now I think that when things are actually commented and documented, then the documentation systems in Ruby and Python are both quite good.
>>40
Yes, when they're actually documented. The problem is that there seems to be a large number of developers who won't comment their code at all. They don't even use doc strings.
Grargh.
Save another developer's sanity: put in a useful comment for every class, method, and unusual paragraph of code.
# XX: fixme
I cannot figure out why to_i returns 0 if it doesn't find a number. We have a language that DEFINES a value for null(nil) AND we have exceptions, but we are just going to straight copy C's atoi because that is what people are used to. Brillant. Also, would it KILL them to call it to_int and to_string?
Also, a specification of the language would be nice.
The only thing worse than programmers who won't comment their code, is programmers who fail to update the comments when the code changes.
I've recently had some serious hair-pulling moments with a (python) library because all the docstrings talk about the API a year ago, while the code has been under active and non-backwards-compatible development for 12 months.
And worse than those are the ones who update the commented algorithm to match the broken code, instead of fixing the code to do what it was meant to.
At one point, php's socket_read($socket, $n); would return $n bytes, but the docs said it would return $n-1.
So they fixed the code.
Not the docs.
>>45
That really belongs in the "PHP programmers are dumb" thread.
RPG tuku-ru XP is cool.
Ruby exists only for it.
I thought I'd resurrect this thread to bitch a little about Ruby's distinction between methods and funcs (and blocks!).
Most sane languages have functions that inherit from their surrounding environment. You'd think Ruby would do something similar. Consider:
def m1( var ) def m2
var
end m2()
endm1( 10 )That looks like a function inside a function (or a method, if you've drunk too much OO koolaid), right? Very Lisp!
You might reasonable assume that the free variable var in m2() refers to the bound variable var in m2()'s surrounding environment, namely m1(). In other words, if you called m1() with 10, then m2() would return 10, thus m1() would return 10.
In reality what you get is:
NameError: undefined local variable or method `var' for main:Object
from (irb):4:in `m2'
from (irb):7:in `m1'
from (irb):10
from :0O snap. How about something simpler:
var = 10def m1
var
endm1()What could possible go wrong here?
NameError: undefined local variable or method `var' for main:Object
from (irb):4:in `m1'
from (irb):7
from :0O shi.
So, this means if I want to do something like no.1 above, I have to use procs:
def m1( var ) m2 = Proc.new {
var
} m2.call()
endm1( 10 )So now we know that methods let you stuff other methods/function/whateverthehellthey'recalled inside them, but without any of the benefits of doing so. In addition, why do I have to do a .call() with a proc anyway? What's wrong with a ()?
Can someone explain to me why methods, procs, and blocks are all different things?
Oh wow, that is a mess. I thought Ruby was supposed to be clean and consistent, but that is just horrible. Between that and 0 being true (and of course the whole thing being really slow, which is what I've been waiting to be resolved before I bother trying), my curiosity about the language is really waning.
PS: from :0!
Oh, it gets better, because I didn't mention how blocks are called.
Method: m1(10)
Proc: m1.call(10)
Block: yield 10
Methods/procs/blocks are just a variation on a theme. Any sane designer would merge all three into the single entity they rightfully should be. The different behaviours (and performance characteristics!) of each of these indicates a fundamental misunderstanding of objects and closures.
Which leads me to conclude that Matz is good at cherry-picking ideas from other languages, but not at synthesizing them. This whole subject is, like, really old news in the PL world.
I'm going to repeat a few things already said here, but I need to bitch about Ruby for a while.
#{}
# is a character solely reserved for commenting. I totally understand the need for using "unique" characters so you can interpolate objects in a string, but find some other characters to do the fucking job. puts "#{foo} - #{bar}, #{moreoffoo}" etc is just dumb.
Incrementals (++ and --)
Someone explained the reason for these not to exist is because in the OO world, an object's incremental increase might not be just "1". Hah? Either way, putting it something that just adds/removes 1 to an object that is a known integer is much nicer than foo +=1 in my loops.
Not so nil
One bad programming habit in other people's code I find pop up is failing to return nil if an error occurs. This means of course, that when I assign the value of an object to a method that causes it, things break only when I try to use the said object, because it has an empty value. Hpricot, is a big one to blame. Acessing a specific element that does not exist in a block of HTML will return "". This result is considered "true", so:
foo = Hpricot(lol_webpage/"div.bullshit".to_s)
Someclass.method(foo) if fooWill always call the method. I've gotta work around it with Someclass.method(foo) if foo = ''.
> Someone explained the reason for these not to exist is because in the OO world, an object's incremental increase might not be just "1". Hah?
"Hah?" indeed. There is no "1" in "++"! Just have it do whatever incrementing means for that goddamn object! If C++ can do it, why the hell can't you? Or is Ruby one of these gimped languages that don't do operator overloading?
> Can someone explain to me why methods, procs, and blocks are all different things?
For one thing, methods belong to an object and procs and blocks don't. For your examples above, if var were an instance variable it would have worked.
Procs and blocks are almost completely interchangeable though, you can set up methods which accept either without ridiculous trickery.
> Incrementals (++ and --)
> Someone explained the reason for these not to exist is because in the OO world, an object's incremental increase might not be just "1". Hah? Either way, putting it something that just adds/removes 1 to an object that is a known integer is much nicer than foo +=1 in my loops.
Their explanation was wrong. It was almost certainly due to laziness.
Doesn't really matter though, because I haven't yet encountered a need to use ++ in Ruby. You have two better options.
If you want to loop, you have a number of ways... for instance:
>> 1.upto(10) do |i|
?> puts i
>> end
1
2
3
4
5
6
7
8
9
10
If you want to increment a variable for some other reason, personally I use a = a.next.
> Or is Ruby one of these gimped languages that don't do operator overloading?
It can do operator overloading but I'm not sure if you can define brand new ones.
> Their explanation was wrong. It was almost certainly due to laziness.
You might be right. Because all this should require is a language feature which defines that "a++" compiles to "a = a.succ". And therefore any class which implements succ would get it for free.
So no, it isn't just integers, becuase...
>> s = "abc"
=> "abc"
>> s = s.succ
=> "abd"
> It can do operator overloading but I'm not sure if you can define brand new ones.
At the very least you can't do it for ++, without changes to the parser.
> If you want to increment a variable for some other reason, personally I use a = a.next.
That's even LONGER than just writing "a=a+1".
> For one thing, methods belong to an object and procs and blocks don't.
Well, yes, I know. I'm claiming that this is a wholly unsatisfactory situation. I can't think of a reason for the artificial distinction between the three to exist. Ignore Ruby for a moment and ponder the difference (or lack thereof) between an object and a closure.
Ruby is the only mainstream language I've seen with such unusual scoping. No matter how you look at it, this is brain-damaged:
irb(main):001:0> var = 10
=> 10
irb(main):002:0> def m1
irb(main):003:1> var
irb(main):004:1> end
=> nil
irb(main):005:0> m1()
NameError: undefined local variable or method `var' for main:Object
from (irb):3:in `m1'
from (irb):5
from :0That Hpricot example is pretty stupid since nil.to_s always returns an empty string.
And someone already mentioned this, but if you're using incrementals for your loops, you're doing it wrong.
Loops are hardly the only place one would use incrementals.
51 mentioned loops specifically. For other uses I prefer += 1 anyway.
Okay, is there is damned good reason why pipes in regex don't work in sub() and only in gsub? For example...
irb(main):001:0> foo = '">29,000'
=> "\">29,000"
irb(main):002:0> bar = foo.match(/">(.*)$/).to_s.gsub(/">|,/, '')
=> "29000"
irb(main):003:0> bar = foo.match(/">(.*)$/).to_s.sub(/">|,/, '')
=> "29,000"They work fine.
irb(main):002:0> bar = foo.match(/">(.*)$/).to_s.sub(/">|,/, '').sub(/">|,/, '')
=> "29000"