What do u hate about ruby

[docetes]

hi all,


i assume this being a ruby forum everyone loves ruby but what do u hate about it?

There must be some drawbacks.
Some little thing that niggle at you when u use it.

just thought it might spark some interesting posts

cheers,
Dave

[sweatje]

That I love Ruby's syntax, but I still don't find myself as productive as I do with PHP.

And that Ruby is even further away from a corporate standard than PHP, and is therefore even harder to introduce into an "Enterprise" environment.

[IAIHMB]

1) How slow it is.
2) Poor unicode support.
3) How far some have got their heads up their arses in #ruby-lang.

Based on my comments you can probably figure out that I prefer Python over Ruby. However, I don't think Ruby is a bad language, it was my first step out of the C style hell.

[Fenrir2]

1) method aliases like collect
2) blocks are not first-class
3) poor keyword argument syntax

[rossriley]

I Don't like the multi-line comment syntax

[Majglow]

That I love Ruby's syntax, but I still don't find myself as productive as I do with PHP.

And that Ruby is even further away from a corporate standard than PHP, and is therefore even harder to introduce into an "Enterprise" environment.

I would just like to say that I find myself way more productive than with PHP. Also, as for the "corporate environment" it just takes time. It's starting to be adopted. I know a couple of fortune 500 companies that are starting to use ruby / rails for critical apps. It's mostly a question of people there realizing the potential... and how much respect the developers get from managers.

[vgarcia]

It runs like crap on Windows (Rails, not necessarily Ruby) so my chances of being able to actually use it at work is near nil (you try telling a Windows software company to switch its server platforms).

[Hartmann]

I've just never been able to get used to some of the syntax or naming of functions.

[pjleonhardt]

It runs like crap on Windows (Rails, not necessarily Ruby) so my chances of being able to actually use it at work is near nil (you try telling a Windows software company to switch its server platforms).

what about it runs like crap on windows?? I've had no problem with it on Windows, but I've only been using it for a few weeks...

My biggest problem with rails (not ruby) is I have trouble porting my apps to my host from my local development machine. This is probably more of a problem with the way my host is set up though..

I'm not a big fan of the Ruby manual

[The New Guy]

CRAP ERROR MESSAGES!!!!!!!!!!!!!!

[Luke Redpath]

1) method aliases like collect

I actually use collect more than map

2) blocks are not first-class

to_proc not good enough eh?

3) poor keyword argument syntax

What keyword argument syntax? Heh, its easy enough to implement using a hash with symbol keys (which is what I'd imagine a native implementation would look like anyway).

http://www.lukeredpath.co.uk/2006/7/...-easy-defaults

[Luke Redpath]

It runs like crap on Windows (Rails, not necessarily Ruby) so my chances of being able to actually use it at work is near nil (you try telling a Windows software company to switch its server platforms).

A small quote from RailsConf last week (actually by Martin Fowler originally):

"If you can't change your job...change your job".

[vgarcia]

what about it runs like crap on windows?? I've had no problem with it on Windows, but I've only been using it for a few weeks...

Try deploying in production on an IIS server and without Apache or lighttpd as a proxy. It's possible, but the fact is Windows is a second-class deployment platform for Rails and it seems like Zed Shaw is the only person doing anything about it.

A small quote from RailsConf last week (actually by Martin Fowler originally):

"If you can't change your job...change your job".

Let's check the local RoR jobs:

ONE. And it's a 6-week contract. Mortgage > fun job unfortunately

[bonefry]

I don't like its performance.

One of the ways I start learning a new language is by picking up my old and trusty algorithms and data-structures book, and then I start translating those into the new language to familiarize myself with the language's primitives.

With Ruby it was a big dissapointment, as you can imagine.

But on the other hand ... it is now my #1 scripting language because there's no other as productive.
I have a dozen cron-jobs written in Ruby that are in production.
I also have mixed PHP-Ruby applications ... just for fun

And I love the productivity of Ruby on Rails ... but I still use PHP and Java for serious websites ... and yes, it has something to do with fear of unknown problems that may appear, or fear of performance issues.

But that may fade in time, and I really hope performance improves, because its a wonderfull language.

[Luke Redpath]

Performance should hopefully no longer be an issue come Ruby 2.0, but as to when its due...who knows.

[Fenrir2]

I actually use collect more than map

I used to use collect but after a little Haskell I'm used to map now.

to_proc not good enough eh?

It isn't ;-). Blocks should be first class so you can do this:

foo({|a,b| ...})

What keyword argument syntax? Heh, its easy enough to implement using a hash with symbol keys (which is what I'd imagine a native implementation would look like anyway).

http://www.lukeredpath.co.uk/2006/7/...-easy-defaults

That's pretty good but the native keyword argument syntax of Ruby 2 is better IMO.

[Luke Redpath]

I'm really not sure what the point would be in having blocks as first class objects - they are essentially syntatic sugar for procs IMO. When ever you do this:

def takes_a_block(foo, bar, &block)
end

takes_a_block('something', 'something else') do
  #whatever
end

The & in front of the block argument calls to_proc anyway, so you are always dealing with a proc. The & shortcut for to_proc is also what lets you do things like:

# long way
names = @users.collect { |u| u.name }

# short way
names = @users.collect(&:name)

As long as you have the cool Symbol#to_proc extension (its in Rails and the Ruby extensions project, and Ruby 1.9 I think).

You can do this:

def foo(block_one, block_two)
  puts "One is a #{block_one.class} and two is a #{block_two.class}"
end

foo(proc{|x| ...}, proc{|x| ...})
#=> "One is a Proc and two is a Proc"

OK its not quite as clean, but its better than Proc.new. Having Procs as first class objects is the key I feel, not having blocks as first class objects. It would be like asking for parentheses as first-class objects; they are only syntax constructs.

[EasyMarketer]

Quit confusing rails with ruby
Ruby kills php in speed in coming out of a database
Php just has faster text processing.
Quit comparing them please, they are better for different purposes.

[Luke Redpath]

Quit confusing rails with ruby
Ruby kills php in speed in coming out of a database
Php just has faster text processing.
Quit comparing them please, they are better for different purposes.

I don't see anybody confusing the two.

Ruby *is* slow (and it is slower than PHP). In fact, out of the many dynamic scripting languages out there, Ruby probably comes near the bottom of the list in terms of speed.

[vgarcia]

Quit confusing rails with ruby
Ruby kills php in speed in coming out of a database
Php just has faster text processing.
Quit comparing them please, they are better for different purposes.

Even if PHP is faster so what? You just have to know when to use the right language for the job. If you need super performance then Ruby probably won't help you (for now, who knows with 2.0), but at the same time, very few dynamic languages would help at that kind of scale.

[hgilbert]

what I hate about Ruby?

... the fact I can't program in it

[Fenrir2]

Then change that hgilbert; learn Ruby!.

I'm really not sure what the point would be in having blocks as first class objects

It's good to have first class things. It's consistent and more dynamic. First class Classes are good because you don't need factories anymore.

For example:

p = {|a,b| ...}

That should be possible: there is not reason for blocks not being first class. Easier to understand.

It doesn't matter much in practice because you can use lambda but it's just one of those not-optimal things.

[Sgarissta]

Then change that hgilbert; learn Ruby!.



It's good to have first class things. It's consistent and more dynamic. First class Classes are good because you don't need factories anymore.

For example:

p = {|a,b| ...}

That should be possible: there is not reason for blocks not being first class. Easier to understand.

It doesn't matter much in practice because you can use lambda but it's just one of those not-optimal things.

But how would you distinguish an empty block with no arguments, and an empty hash?

p = { }

[Fenrir2]

{||}

[Sgarissta]

{||}

Except that now you've got two sets of syntax for blocks without arguments, and i'd hate to have to write do || end everytime I wanted a "normal" block without arguments.