He didn't ruin the life of the specific girl in the photos. But he incremented the download counter, giving that much more encouragement to the suppliers, letting them know the market was at least one person greater than otherwise.

Maybe after downloading, he was in a conversation where the subject came up and he didn't feel justified in saying, "It's wrong". And so there was one less conversation where it was discouraged. If he justifies it to his own self, the same justification he feels will leak out, just as all the other aspects of his person come through to other people.

All of this adds up to the ruining of the life of a girl - not in the past - but in the future. The next girl.

My comment is hypothetical, because this gent was railroaded, but there exists another fellow for who this does apply. On a macro level, the dynamic holds true. The harm done is that evil propagates itself, and it is worse when it does so in subtle, unquantifiable, yet undeniably real fashion.

What is the justification for (knowingly) having it, and not destroying it? In this case he did destroy it (pay the man respect), and that is why everyone is upset.

It's not a compile time feature. attr_accessor is a method just like any other method, and as such, performs its action at runtime. Slapping attr_accessor in your code is just a method invocation.

Additionally, because in Ruby you can redefine methods at any point in time, what attr_accessor actually does could be different at different points in (run)time, depending if the interpreter has hit code redefining it or not. It's only its default implementation which generates accessors ;-). If you run the code after loading the wrong library, you could see strange effects. Google "monkey patching".

Conceivably you *could* write a C implementation which would either alter your compiled binaries or dynamically compile new ones at runtime to achieve the same effect. When you were done, it would look a lot like an... interpreter.

Being interpreted is very much a property of the language. There's at least two different ways to make this case.

First, I might point out that (although this is changing w/ Jruby & Rubinius) the Ruby language is basically specified by a reference implementation interpreter (MRI). MRI's behaviour *is* ruby.

More importantly, knowing that the interpreter is going to run through your code line by line changes your entire programming paradigm. Most ruby metaprogramming features are *all* about being interpreted.

Eg attr_accessor. It is a method which, when evaluated by the interpreter generates accessor methods for the names passed in. Leaving expressions with side effects in your classes just so that the interpreter can trip over them and do things for you is not a standard programming paradigm in C.

Opening classes and adding methods at runtime? A core feature of Ruby and entirely dependent on being interpreted.

If I wanted to get all fancy and mushy, I would say that writing Ruby is like a dance with the Ruby interpreter.

Ruby is *way* closer to a LISP (MATZLisp, anyone?) than C. Apples and toaster ovens.

Even if you did write a ruby compiler, and said, "Aha! I have a ruby implementation which is not interpreted!" I would say, "What a nice interpreter factory you have written. But why do you feel the need to compile and spit out a new one every time you want to run a ruby program?"

The emphasis is mine but the joke is all his.