Ruby, like Perl, still allows you to redefine your classes at runtime: that alone was enough to ruin the language for me. At least perl warns you when you redefine a function; I got no such warnings from Ruby.

Erm, did you have warnings enbled?

gamera:~ 835> cat boink.rb
class Foo
  def bar( )
    puts "bar"
  end
end

class Foo
  def bar( )
    puts "baz"
  end
end
gamera:~ 836> ruby -w boink.rb
boink.rb:8: warning: method redefined; discarding old bar
[download]

Apparently not; I was using a tutorial that was redefining classes as it went.

Apologies to Ruby for the undeserved criticism. But is there some way to freeze the class definition so it can't be changed at all?

I dislike giving other people plenty of rope to hang me with.

Yup.

---------------------------------------------------------- Module#free
+ze
     mod.freeze
----------------------------------------------------------------------
+--
     Prevents further modifications to _mod_.
[download]

And there's also Object#freeze which prevents modification of individual instances (preventing you from adding singleton methods to them).

My perspective:

• The number of bugs is linear with the amount of code. Powerful constructs that reduce the amount of code you need to write therefore reduce the number of bugs in your code.
• Powerful features can be wrapped in nice generalised packages for everyday use. There’s a difference between being Damian and being a user of Damian’s modules.

A lot of the stuff in Class::* would be impossible, were it not for breakable encapsulation.

Makeshifts last the longest.

The number of bugs is linear with the amount of code. Powerful constructs that reduce the amount of code you need to write therefore reduce the number of bugs in your code. And shuffle it inside the constructs themselves, which are harder to debug, since they're powerful and complicated. You still don't win; you end up maintaining ugly libraries full of someone else's notion of "cool" or "powerful" constructs, and now the userspace problem has been halfway abstracted into a less-comprehensible language, in a half-tested toolkit.

I've been down that road. I don't like it. It's made me suspicious of the whole "powerful code is good code", because usually someone's idea of "power" really is "ugly, complicated code that tries for too much at once". Sometimes it's not, and those people do good work; but it's the exception, not the rule.

Powerful features can be wrapped in nice generalised packages for everyday use. There’s a difference between being Damian and being a user of Damian’s modules.

Not really -- if you end up having to debug one of Damian's modules to fix some obscure bug in the middle of the night, you still have to know what the hell he did and how he did it. And then you'll probably wish he was less clever and used fewer obscure tricks, so that you could see the bug and FIX it, and go HOME, instead of fretting over how the classes and the closures and self-rewriting language constructs are conflicting in some wierd and unpredicted way.

If you gamble on complex, powerful code you'ld better be sure you get it right the first time, because maintanance sure is a nightmare when the call to do_deep_magic() fails.

And as the guy who has to fix stuff, I get grumbly when it's me that has to fix it. I don't like beautiful and elegant code. Sure, maybe you're a genius with knots, and you can make a sailor jealous with your bowlines. And maybe you think it's a conceptualy elegant and powerful notion to solve the problem of cable management with the cables themselves. But to me, it's still a mistake to make your network cables look like a some elaborate piece of celtic knotwork that's an absolute pain to untangle at 3:00 am when the same job can be accomplished in an inelegant, ugly, but obvious way using cable ties and conduits that can be fixed on a moment's notice late at night.

I've seen so many "code as art" projects that were an abject nightmare to deal with not to scream internally every time someone starts chuffing their chest, and touting words like "elegance", or "powerful constructs", or "higher order" anything.

Maybe I'm just a grump. But I've seen a lot of stuff like that, and I keep having to clean up after young, bright eyed kids who think they know what they're doing, but can't quite nail it -- they bustle in on contract, fire buzzwords around, generate a lot of cute, complicated code, get bored, leave before they can be fired ( or get fired), and leave me to clean up the mess.

That's no fun.

It’s a question of whether you want to spend 3 days writing something that you could have gotten done in an hour using a Damian module. Sometimes, having magic available makes the difference from “too much effort to implement at all.”

And personally, I don’t take the notion of magic lightly. I rarely ever implement the first thing that comes to mind either (in this, I seem to be in a minority). I wouldn’t use Damian magic without a good reason for it. I wouldn’t use Ingy magic at all. I’d never use a source filter in production. And on and on.

I know to discipline myself. I resent it deeply when the language assumes I don’t and puts itself over my judgement.

Makeshifts last the longest.

I think your definitions are either overloaded, or perhaps even altogether broken. Simplicity and power are not mutually exclusive, yet you seem to be saying they are. I actually tend to find exactly the opposite -- the simplest things are very often the most powerful. (As a concrete example, consider a unix pipeline. Hooking the output from one program to the input from another is extremely simple, yet allows for amazingly powerful constructs.) I guess it might just be a matter of definitions, but I have to take issue with yours.