Disqus - Latest Comments for RobertDober

Re: PragDave: Pragdave 2.0

RobertDober — Thu, 07 Jul 2016 14:58:03 -0000

Just stumbled upon this, and want to take the opportunity to say thanx. For the books, the inspiration, the ideas. I guess without your books I might not have learnt Ruby, and Elixir neither.
But with Elixir your code thought me even more.
All the best for your new projects which might turn out new inspirations!!

Re: Understanding Elixir Macros, Part 6 - In-place Code Generation

RobertDober — Fri, 18 Dec 2015 16:01:39 -0000

This is just so helpful for understanding macros. A small update: It seems that with modern versions of Elixir we need to replace
|> List.unzip
|> List.to_tuple
with
|> Enum.unzip

Re: Debugging Elixir

RobertDober — Wed, 09 Dec 2015 02:52:02 -0000

This is just hillarious, thank you so much...

Re: Ruby Best Practices - The Double Dispatch Dance

RobertDober — Sun, 21 Jun 2009 07:20:06 -0000

Aaron

why not going a step further, e.g.

class MyProxy
extend VisitorForwarder # I am sure you will find a better name ;)

visit_forwards :as_string, :as_form_object # this does Rails like conversion to camel case

# and you need a more general
visit_forwards as_string: StringLikeClass, as_form_object: MySophisticatedForm

end

Cheers
Robert

Re: Ruby Best Practices - "And your Mom, too." Ruby-talk best practices.

RobertDober — Tue, 16 Jun 2009 14:22:39 -0000

Sure James,
I am fully aware that, when I make such a suggestion I am only one voice, and I am making it just in the hope to inspire other people to speak out. If they fail to do so, it simply means that there is no consensus that this is a good idea, and it shall indeed go forgotten. Maybe I am pushing it a little bit sometimes, but I was one of those who thought that RT needs a FAQ some time ago, we were a minority then and obviously more so now. Well at least I tried.
But I still think that your post is almost too good to go *only* to the BLOG ;).
Ty 4 your time
Robert

Re: Ruby Best Practices - First Design Considerations

RobertDober — Sat, 13 Jun 2009 10:20:27 -0000

exactly like you, to see how the VM's deal with GC and object allocation nowadays. But I have to admit that I might also not find the time to do it...

Re: Ruby Best Practices - First Design Considerations

RobertDober — Sat, 13 Jun 2009 09:58:44 -0000

As I pointed out to Robert it was not the optimization thought that worried me but the "premature" part. I believe that VM construction today will make such considerations futile if not dangerous because they might as well achieve the contrary. Furthermore those things are very difficult to benchmark in a testing environment, that is why I might be tempted to benchmark the final product in two versions. I also would guess that JRuby and Ruby1.9 might have some very substantial differences for GC performance.
Maybe I should have said this boldly: GC can be your friend and not your enemy!
http://rubyconf2008.confrea...

Re: Ruby Best Practices - First Design Considerations

RobertDober — Sat, 13 Jun 2009 09:34:47 -0000

No claim and no facts whatsoever :).
But are you not doing premature optimization here? I mean if you were aware of a heavy penalty like 50% or more than it would be clever to think twice, but IIRC ( and I might as well not) you might expect a 10~20% performance hit at most. Please also note, that unless you tune your GC very finely, the long lived objects will be "collected" into the long time space at least once, this might cost you something of your 15% gained.
Maybe we can do some benchmarking at the end of the project?

Re: Ruby Best Practices - First Design Considerations

RobertDober — Sat, 13 Jun 2009 04:13:50 -0000

Robert
I noticed that you were worried about short lived objects, but is that not in general a very efficient way to program given a good generational GC? IIRC JRuby already benefits of such, but I am not sure about Ruby-1.9.
Cheers
Robert