Rados³aw Bu³at wrote:
I don’t believe you :P. Show us the code. Did you use RubyInline or something?
see post from 1:14 am — rubyinline
You could also look into The project to concert ruby to obj-c which is
compiled. Am I dreaming? I can’t remember the name
Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/
Radosław Bułat wrote:
On Sat, Feb 7, 2009 at 3:42 PM, Peter H. [email protected] wrote:
Haven’t tried it under JRuby though, you might experience better performance
there.JRuby is faster than 1.9 even without warming. ~2s for jruby, ~2.8s
for ruby1.9.1. With warm up it goes down to ~1.2s and with --fast flag
to ~0.75s.
Nice 
- Charlie
On Sun, Feb 08, 2009 at 03:22:20AM +0900, Igor P. wrote:
cycle, and indeed to the complexity of the project. Mere execution time
of an application represents only a tiny fraction of what is truly
measured when comparing procedural language like Perl and object
oriented Ruby. If you compare the two languages in this respect Perl
doesn’t come even close to where Ruby stands. In fact I believe if you
look at performance issues from this angle, Ruby stands out very proudly
as the best performing programming language of all times.
You talk as though Perl were something like Java or C++. It’s not.
Development can be incredibly fast with Perl. It’s just suited to
different environments and tasks than Ruby.
For the most part, it’s ridiculous to talk about which language’s
implementation is faster, in and of itself. The only time runtime
performance really matters that much is when you have a specific task
for
which run time performance is of great specific importance – and, even
at those times, a better algorithm is usually worth a lot more
performance gain than a faster language implementation. Because of
this,
I agree that runtime performance should never be the sole determinant
when choosing which language to use for a given project. In many cases,
any language in widespread use is going to be fast enough for your
needs,
and as such runtime performance should be somewhere near the bottom of
the list of criteria.
. . . but I really don’t agree with your assessment of Perl’s
development
cycle as something that “doesn’t even come close” to Ruby’s.
Furthermore, pigeonholing Perl as a “procedural” language is as unfair
to
it as pigeonholing Ruby as “object oriented” is to Ruby. Both of them
have a lot more to offer. Both provide excellent support for many
traditionally functional paradigm programming; both support object
oriented development; both can be used in a structured, procedural style
when that’s the appropriate technique to employ.
In general, I enjoy programming in Ruby more, these days – but there
are
tasks for which I’d much rather write the code in Perl than in Ruby.
Each has its strengths, and each has its place in my development toolkit
(and neither of them is clearly “faster” in terms of “the entire project
life cycle”, especially considering that different projects have very
different lifecycles).
Chad, I generally agree, however…
2009/2/9 Chad P. [email protected]:
. . . but I really don’t agree with your assessment of Perl’s development
cycle as something that “doesn’t even come close” to Ruby’s.
Furthermore, pigeonholing Perl as a “procedural” language is as unfair to
it as pigeonholing Ruby as “object oriented” is to Ruby. Both of them
have a lot more to offer. Both provide excellent support for many
traditionally functional paradigm programming; both support object
oriented development;
… that statement makes me itch. I try to avoid voicing extreme
opinions, but in this case I have to say: Perl’s OO is a bad joke.
Yes, you can program OO style in Perl and there is /some/ support for
this - but it does not really give you much advantage over doing OO in
C (yes, you can do that: even std libraries do it, see open and fopen
et al).
both can be used in a structured, procedural style
when that’s the appropriate technique to employ.
Right.
In general, I enjoy programming in Ruby more, these days – but there are
tasks for which I’d much rather write the code in Perl than in Ruby.
Each has its strengths, and each has its place in my development toolkit
(and neither of them is clearly “faster” in terms of “the entire project
life cycle”, especially considering that different projects have very
different lifecycles).
IMHO the best arguments for Perl are these
- often it’s installed on a *nix system
- CPAN
Kind regards
robert
Robert K. wrote:
Yes, you can program OO style in Perl and there is /some/ support for
this - but it does not really give you much advantage over doing OO in
C (yes, you can do that: even std libraries do it, see open and fopen
et al).
I haven’t done enough C to say for sure, but I loved Perl’s OO. There
definitely seems to be more there – inheritance via @ISA, constructors
via bless – and while some find it ugly to expose all the
underpinnings, that is one thing I love about Perl.
It’s also one of the same reasons I love Ruby – I don’t have to get my
hands dirty.
Take the simplest example, a method. In Ruby, it’d be:
class Foo
def bar(arg)
…
end
end
In Perl (and forgive my syntax, it’s rusty), it’d be something like:
package Foo;
sub bar {
my ($self, $arg) = @_;
…
}
Now, the Ruby version is much more readable to me, and much easier to
work with. But there is something magical about the way the Perl version
starts from even more basic primitives. Arguments are simply passed in
as an array, which you can either unpack or not, as you like. The
current object is passed in as an argument, meaning this is just another
subroutine – it lets you do tricks like this:
my $foo_like_thing = Bar::new();
Foo::bar($foo_like_thing, $some_other_arg);
Kind of like Javascript’s call() and apply() – and I’m not even sure
this can be done in Ruby. For all the duck typing goodness, I can’t seem
to figure out how you’d unbind a method and rebind it to something of an
unrelated class, unless there’s an explicit tree of inheritance.
Not that this is something I’ve often (ever?) felt the need to do in
Ruby. I’m just using it to illustrate what I like about Perl – that
it’s so completely relaxed about this kind of thing. It gives you the
bare bones of what’s necessary for an object system, and you build
whatever you want on top of it – even with the guts exposed all over
the place.
IMHO the best arguments for Perl are these
- often it’s installed on a *nix system
- CPAN
I’ll agree with that. And for new projects, I will instinctively choose
Ruby. But it’s for other reasons – I like Ruby’s syntax, and I like
everything being an object, and being able to do things like the Rails
Object#blank? hack, and iterators, and…
Chad P. wrote:
. . .
You talk as though Perl were something like Java or C++. It’s not.
. . .
I am saying nothing of that kind!?
The fact that you are lumping Perl together with C++ and Java or Ruby
for that matter speaks volumes, and I simply do not have time to debate
this. But I can not allow myself not to reiterate that Perl is a
procedural language, and that its OO capabilities do not impress me at
all. OO in Perl is worse than C’s GNOME extension. To use OOP in Perl is
just not worth the trouble. I also love Perl but not for it’s OOP but
rather that for which it was designed in the first place, which is
procedural stuff and efficient shell programming that is almost as
powerful as C. However, there are times when even Perl is too convoluted
and a simple Unix shell script will do much better. At the same token I
believe, that to use Ruby as a replacement for shell script as many use
Perl, is a brain damaging proposition. The bottom line is Ruby is an
OOPL and is the most powerful in this domain. With Ruby, scripting is
just an additional bonus, and is not at all what it was designed for.
Arguably Ruby is one of The Best OOPLs, and as I have already said
nothing so far comes close to it, let alone Perl which is nothing more
than super duper scripting language, with a bonus to wrap it in a
reasonable OO paradigm, which, by the way, is rather poorly understood
by those who use Perl the most.
Using Perl on large projects is no longer a desirable enterprise, though
in the past it used to be a knockout when it competed with C. With the
advent of OO, Perl had to be tweaked to provide this alternative,
however that alternative sucks, and that is why Python took over its
domain. Thankfully, Ruby was born to replace these OO concoctions that I
cherish only as interesting OO fossils. On the other hand, what is good
and healthy lives long, and I believe procedural Perl will never die.
Though with some effort you can do anything you could do in Perl also in
Ruby. But isn’t that true for all programming languages. This is known
since the 60’s when COBOL programs were sprinkled with Assembler
procedures.
On 09.02.2009 19:15, David M. wrote:
Robert K. wrote:
Yes, you can program OO style in Perl and there is /some/ support for
this - but it does not really give you much advantage over doing OO in
C (yes, you can do that: even std libraries do it, see open and fopen
et al).I haven’t done enough C to say for sure, but I loved Perl’s OO. There
definitely seems to be more there – inheritance via @ISA, constructors
via bless – and while some find it ugly to expose all the
underpinnings, that is one thing I love about Perl.
It’s not that I find it “ugly”. It’s more that I find it hard to read
and remember whichever you have to do to get a class, inheritance,
methods, data members etc. IMHO Perl makes OO unnecessary hard. There
is a paper written by Larry Wall about the flaws of Perl’s OO which I
cannot seem to find right now.
It’s also one of the same reasons I love Ruby – I don’t have to get my
hands dirty.
“Same reason”? That sounds strange to me.
package Foo;
sub bar {
my ($self, $arg) = @_;
…
}Now, the Ruby version is much more readable to me, and much easier to
work with.
Exactly!
But there is something magical about the way the Perl version
starts from even more basic primitives.
Frankly, I don’t like magic in programming - at least not the kind of
magic that makes it hard to follow a program when reading it. I have
had to maintain too much cryptic code to not highly appreciate
readability.
Arguments are simply passed in
as an array, which you can either unpack or not, as you like.
You can do that in Ruby as well. Just do
def initialize(*a)
what, ever, you_like = a
end
The
current object is passed in as an argument, meaning this is just another
subroutine – it lets you do tricks like this:my $foo_like_thing = Bar::new();
Foo::bar($foo_like_thing, $some_other_arg);
What does this? Does it create a Bar and then initializes it as Foo?
What do we gain from that? Where is the advantage over declaring
classes Foo and Bar and making Bar a subclass of Foo if they are so
closely related? (Or use a module for that matter)
Kind of like Javascript’s call() and apply() – and I’m not even sure
this can be done in Ruby. For all the duck typing goodness, I can’t seem
to figure out how you’d unbind a method and rebind it to something of an
unrelated class, unless there’s an explicit tree of inheritance.
Why would you want to do that? There’s a reason why both classes are
unlrelated, i.e. chances are that the method would not work in the other
class / object. If you want to simply share code then you can use
modules which is a much cleaner and safer way to do it.
Not that this is something I’ve often (ever?) felt the need to do in
Ruby. I’m just using it to illustrate what I like about Perl – that
it’s so completely relaxed about this kind of thing. It gives you the
bare bones of what’s necessary for an object system, and you build
whatever you want on top of it – even with the guts exposed all over
the place.
The problem with this is: you have to build it yourself. If I only
get the basic building blocks and have to reapply them over and over
again to get the same result (a bunch of classes with methods and state)
then I am wasting time. A genuine object oriented language is much
superior.
Kind regards
robert
Robert K. wrote:
the underpinnings, that is one thing I love about Perl.
IMHO Perl makes OO unnecessary hard.
Very true. Most CPAN modules manage it anyway, these days, but I agree
– OO doesn’t have to be that hard.
It is fun, though.
It’s also one of the same reasons I love Ruby – I don’t have to get
my hands dirty.“Same reason”? That sounds strange to me.
I love Ruby because I don’t have to get my hands dirty. I love Perl
because I’m always getting my hands dirty, pretty much out of necessity.
It’s something that’s unique to each, and something that I love about
each, under different circumstances.
Arguments are simply passed in as an array, which you can either
unpack or not, as you like.You can do that in Ruby as well.
Yes, I understand. However, if you look at your example:
def initialize(*a)
what, ever, you_like = a
You’re still explicitly accepting one positional argument – it just
happens to be the magical one that instead matches “zero or more of the
remaining positional arguments”.
For the same reason, I also find it kind of cool that Perl objects are
typically just hashes with methods attached. Ruby objects, while
effectively the same thing, tend to hide instance variables away. I like
that, it’s a cleaner approach, but it is still fun to take a hash of
options, perhaps filter them, and then bless them as an object.
Occasionally, this actually is more convenient. For instance, in Ruby, I
too often find myself writing code like this:
class Foo
attr_reader :some, :random, :args
def initialize some, random, args
@some = some
@random = random
@args = args
end
end
Or worse, let’s say I don’t like positional arguments (and I don’t):
class Foo
attr_reader :some, :random, :args
def initialize options
@some = options[:some]
@random = options[:random]
@args = options[:args]
end
end
Or worse, say I’ve written some setters that do something magical. I
then want to set those if they’ve been passed in:
class Foo
attr_reader :some, :random, :args
def initialize options
self.some = options[:some] unless options[:some].nil?
self.random = options[:random] if options[:random].nil?
self.args = options[:args] if options[:args].nil?
end
end
Yes, I could do some metaprogramming. I should stress that I do prefer
Ruby to Perl, for exactly that reason – if this ever gets too annoying,
I can probably do something like the following, which has probably
already been done somewhere:
module AutoInitializer
def self.included klass
klass.extend ClassMethods
end
module ClassMethods
def auto_init *args
include(Module.new do
attr_accessor *args
define_method :initialize do |options|
args.each do |arg|
if options.has_key? arg
self.send “#{arg}=”, options[arg]
end
end
end
end)
end
end
end
Now my class is only this:
class Foo
include AutoInitializer
auto_init :some, :random, :args
end
That’s arguably better, but a bit more work at the beginning. Still,
it’s worth comparing to the Perl solution:
sub init {
my($class, $self) = @_;
bless $self => $class;
}
Granted, there are better ways to do that. It’s certainly going to get
hairier if there are going to be setters involved. But that is one of
the fun side effects of what, at first, seams like a haphazard,
tacked-on design.
JavaScript is similar, in some respects. Suppose someone passes me in a
hash of options. Well, hashes are objects, so I can just do this:
function Foo(obj) {
for (var property in obj) {
this[property] = obj[property]
}
};
Bam. Not only instant options, but instant extensibility – nothing
prevents a user from passing in a function to override one of mine, thus
creating a singleton descendant of my class.
I’m going to stop now, because this is getting a bit long, and the core
point hasn’t changed – I like Ruby, and I see how this kind of stuff
can be done in Ruby, but I wouldn’t immediately dismiss these other
object systems.
my $foo_like_thing = Bar::new();
Foo::bar($foo_like_thing, $some_other_arg);
The current object is passed in as an argument, meaning this is just
another subroutine – it lets you do tricks like this:What does this? Does it create a Bar and then initializes it as Foo?
No, it creates a Bar, and calls Foo’s bar method on it, if I’ve gotten
the syntax right.
Kind of like Javascript’s call() and apply() – and I’m not even sure
this can be done in Ruby. For all the duck typing goodness, I can’t
seem to figure out how you’d unbind a method and rebind it to
something of an unrelated class, unless there’s an explicit tree of
inheritance.Why would you want to do that? There’s a reason why both classes are
unlrelated, i.e. chances are that the method would not work in the
other class / object. If you want to simply share code then you can
use modules which is a much cleaner and safer way to do it.
Indeed, modules are usually the saner choice. However, I have done this
often in Javascript. Probably the simplest example might be the common
each loop:
function each(array, func) {
for (var i in array) {
func.call(array[i], i);
}
}
each([‘one’,‘two’,‘three’], function(i) {
// now ‘this’ is bound to the value
});
Granted, that’s a toy, but it is more convenient that way. And then
there are the cases where you want to do something clever – say you
have multiple superclasses:
var Bar = {
// one big pile of funcitons
}
var Super = {
// another big pile of functions
}
obj.foo = function() {
if (i_want_super) {
Super.bar.apply(this, arguments);
} else {
Bar.foo.apply(this, arguments);
}
}
Maybe some of those are actually superclasses. Maybe they’re modules,
and you only need a single method, not the whole module.
Either way, I would put the burden back on you. Why is this so
dangerous? Why is it any more dangerous than the other duck typing
tricks Rubyists use every day? Why shouldn’t I be able to do:
a.method(:foo).unbind.bind(b)
when a and b aren’t related, but I happen to know they share a common
theme? After all, what ties the method to the object – isn’t it mostly
going to be calling instance methods, and occasionally accessing
instance variables – so why should ‘self’ be exempted from the “quacks
like” rule?
The problem with this is: you have to build it yourself. If I only
get the basic building blocks and have to reapply them over and over
again to get the same result (a bunch of classes with methods and
state) then I am wasting time.
And then you discover one of the most basic tools in any language: A
library.
Take my above AutoInitializer example. I could complain that I have to
reinvent it every time, but clearly I don’t. I can just file it away in
a file called autoinit.rb, and if it turns out to be original, I can
upload a gem.
Or I can decide to use openstruct instead.
What matters is how powerful those basic building blocks are, and what
it looks like when you’re finished.
On Mon, Feb 9, 2009 at 7:15 PM, David M. [email protected]
wrote:
I haven’t done enough C to say for sure, but I loved Perl’s OO. There
definitely seems to be more there – inheritance via @ISA, constructors via
bless – and while some find it ugly to expose all the underpinnings, that
is one thing I love about Perl.
Are you aware that Perl’s MI via @ISA is probably the worst way one
can implement MI in?
That said I admit that one can write nice OO code in Perl with some
discipline.
Cheers
Robert
2009/2/9 David M. [email protected]:
Robert K. wrote:
IMHO Perl makes OO unnecessary hard.
Very true. Most CPAN modules manage it anyway, these days, but I agree – OO
doesn’t have to be that hard.It is fun, though.
Well, everybody as they like.
attr_reader :some, :random, :args
def initialize some, random, args
@some = some
@random = random
@args = args
end
end
Then you probably haven’t used Struct enough. For me the code above is
just
Foo = Struct.new :some, :random, :args
Or worse, let’s say I don’t like positional arguments (and I don’t):
class Foo
attr_reader :some, :random, :args
def initialize options
@some = options[:some]
@random = options[:random]
@args = options[:args]
end
end
Foo = Struct.new :some, :random, :args do
def initialize(options)
members.each {|m| self[m] = options[m]}
end
end
end
Foo = Struct.new :some, :random, :args do
def initialize(options)
members.each {|m| x = options[m] and self[m] = x}
end
end
def auto_init *args
end
end
end
This is not needed as I have tried to show above.
sub init {
my($class, $self) = @_;
bless $self => $class;
}
But this does not set properties, does it? (My Perl is a bit rusty
nowadays.) If this is the case then this is not a solution to the
same problem.
Granted, there are better ways to do that. It’s certainly going to get
hairier if there are going to be setters involved. But that is one of the
fun side effects of what, at first, seams like a haphazard, tacked-on
design.
Ok, I do not get fun from this - especially when I have to do it
over and over again…
a user from passing in a function to override one of mine, thus creating a
singleton descendant of my class.
→ OpenStruct
What does this? Does it create a Bar and then initializes it as Foo?
No, it creates a Bar, and calls Foo’s bar method on it, if I’ve gotten the
syntax right.
if - LOL If even you do not know…
Indeed, modules are usually the saner choice. However, I have done this
});Granted, that’s a toy, but it is more convenient that way.
And in Ruby it’s already built in.
obj.foo = function() {
if (i_want_super) {
Super.bar.apply(this, arguments);
} else {
Bar.foo.apply(this, arguments);
}
}Maybe some of those are actually superclasses. Maybe they’re modules, and
you only need a single method, not the whole module.
If you need a single method only that should go into its own module.
Otherwise there’s something wrong with how code is packaged IMHO.
Either way, I would put the burden back on you. Why is this so dangerous?
Why is it any more dangerous than the other duck typing tricks Rubyists use
every day?
Because in Ruby hackery (or call it “metaprogramming”) is an add on,
i.e. you can use it in special situations, while in Perl you need to
do it to get basic things (OO) to work.
Why shouldn’t I be able to do:
a.method(:foo).unbind.bind(b)
when a and b aren’t related, but I happen to know they share a common theme?
Because this is an indication that your code is not well structured.
If they share a “common theme” this theme could be packaged into a
module and properly documented. Just moving one method over is an ad
hoc solution which - when applied with only moderate frequency - will
give unreadable and thus unmaintainable code very soon.
After all, what ties the method to the object – isn’t it mostly going to be
calling instance methods, and occasionally accessing instance variables –
so why should ‘self’ be exempted from the “quacks like” rule?
If you need only this single method you can as well use a functional
approach, just define
def foo(obj)
obj.instance_method_a = 1
obj.another_method
end
No need for unbind bind hackery.
The problem with this is: you have to build it yourself. If I only get
the basic building blocks and have to reapply them over and over again to
get the same result (a bunch of classes with methods and state) then I am
wasting time.And then you discover one of the most basic tools in any language: A
library.
Even better: have it already in the standard library or language.
Even if it’s on CPAN already, you still need to add this other
external module to your project etc. You can’t save Perl’s OO that
way.
Take my above AutoInitializer example. I could complain that I have to
reinvent it every time, but clearly I don’t. I can just file it away in a
file called autoinit.rb, and if it turns out to be original, I can upload a
gem.Or I can decide to use openstruct instead.
What matters is how powerful those basic building blocks are, and what it
looks like when you’re finished.
It matters because you might take longer because you need to first
build complex structures out of your basic building blocks because
they are not present in the language. It matters because some poor
maintainer has to read all the code and understand in order to apply
his changes.
Why should I choose a language with broken OO when I want to do OO if
I can have one with good OO, a marvelous clean syntax which has
similar other capabilities (scripted, dynamic, built in regular
expressions etc.)? If this is fun for you then be it. But please do
not try to sell me Perl’s OO as a great thing - because it isn’t.
Cheers
robert
David M. wrote:
Robert K. wrote:
I’m not trying to sell Perl’s OO as the best thing, or
even “better”. But I’m defending it as inherently less
useful than Ruby’s. Someone might as easily say that
Ruby’s OO is inherently less useful than Java’s, because
Java does stricter (static) type-checking.
Could you be more wrong and further from the truth? Perl can not be
defended as a good OOPL, because it simply is not. It lacks so many
things that what you get by using it is redundancy and more work, the
things that good OO is trying to minimize if not eliminate. Secondly,
what you call lack of type-checking can arguably be considered one of
Ruby’s big advantages over those languages that have this feature.
Strictly, from a pragmatical point of view, it makes much more sense
classifying objects based on what they can do rather than to which
“aristocracy” they belong. It is well known fact that Ruby is based on
“meritocracy” and that, semantically and/or philosophically, is
orthogonal to aristocracy! True that OO is all-inclusive and flat with
regards to orthogonal principles, but that makes it dramatically
distinct from pyramid and geriatric hierarchical structures which are
the footprint for all the procedural languages. It takes to much effort
in procedural languages to account for that which they lack!
Robert K. wrote:
Then you probably haven’t used Struct enough. For me the code above is
just
Foo = Struct.new :some, :random, :args
Ah, thanks. That should help.
That’s arguably better, but a bit more work at the beginning. Still, it’s
worth comparing to the Perl solution:sub init {
my($class, $self) = @_;
bless $self => $class;
}But this does not set properties, does it?
It does, actually, assuming you called it with a hash of options. Perl
objects are most commonly a blessed hash.
Granted, you’d probably want to do a bit more sanity checking – the
above won’t complain if you pass a string instead of a hash, or if you
misspell an argument, etc.
What it doesn’t solve is the part where you’d use setters – it’s the
equivalent of directly setting the instance variables.
Bam. Not only instant options, but instant extensibility – nothing prevents
a user from passing in a function to override one of mine, thus creating a
singleton descendant of my class.-> OpenStruct
Maybe I should read the docs, but as I understand it, in Javascript, I
can do this:
f = Foo({
a: ‘some_string’,
b: 12345,
c: function() {
// some method
}
});
I could even do:
f = Foo(new Bar());
thus creating a spontaneous new child of both Foo and Bar. Keep in mind
that both Foo and Bar are classes, each of which may have methods of
their own – in this case, Bar’s methods (or properties) override Foo’s.
To get something even close in Ruby, I’d have to do this:
f = OpenStruct.new
class << f
def c
#some method
end
end
And the other example would look more like this – but only if Bar was a
module, and not a class in its own right:
f = Foo.new
f.extend Bar
And, since it must be a module, it’s not really the same thing. Again,
this could be faked with something elaborate:
class Foo
def initialize(klass)
meta = class << self; self; end
obj = klass.new
obj.methods.each do |method|
meta.class_eval do
define_method method do |*args, &block|
obj.send method, *args, &block
end
end
end
end
end
Note that a subclass of Delegator won’t work here (if it had a chance?),
as that would have Foo override Bar, not vice versa. And even this
doesn’t do what we want, as rather than including methods of both
classes in a kind of poor-man’s multi-inheritance, we’re in fact
delegating to another object.
No, it creates a Bar, and calls Foo’s bar method on it, if I’ve gotten the
syntax right.if - LOL If even you do not know…
I haven’t touched Perl in any meaningful way in over a year. When I took
a break from Ruby for that long, it took awhile for me to get fluent and
sure of my Ruby syntax, also.
Maybe some of those are actually superclasses. Maybe they’re modules, and
you only need a single method, not the whole module.If you need a single method only that should go into its own module.
One method per module! Great idea.
Doing a functional approach is better, but still missing the point.
The point is that the person packaging the code might not know ahead of
time that you need that method, or that it’s a useful method to extract
on its own. That leaves you with a choice of either patching their code
(best long term approach), or copying and pasting, or doing some
really crude hacks, if it’s even possible.
Otherwise there’s something wrong with how code is packaged IMHO.
Probably. But for the same reason I like being able to monkeypatch Ruby
classes, I also like being able to hack Javascript in this way. It means
I can get something working, quickly, without immediately having to dig
into the other code and patch it.
Either way, I would put the burden back on you. Why is this so dangerous?
Why is it any more dangerous than the other duck typing tricks Rubyists use
every day?Because in Ruby hackery (or call it “metaprogramming”) is an add on,
i.e. you can use it in special situations, while in Perl you need to
do it to get basic things (OO) to work.
There are, however, libraries to make the OO less painful in Perl.
To take a Ruby example, Rails likes to autoload classes and modules by
overriding const_missing. I could argue, then, that you need
const_missing to get basic functionality, that of not having to require
a dozen files at the top of each file. But if I’m working on a Rails
app, it’s nicely tucked away for me. When I’m not, I wrote a simpler
version using Kernel#autoload – autoload isn’t sufficient by itself,
but this worked well enough.
And yet, I’ve provided at least a few places where that metaprogramming
(or hackery) is more difficult than it needs to be in Ruby, or sometimes
flat-out impossible.
No, I don’t expect it to be easy – it probably shouldn’t be. But we’re
talking about a language where I can have a method reach up the call
stack and evaluate text in the scope of its caller. It’s a language
where I can redefine pretty much any operator, on pretty much any class
– I can make 2+2=5, if I really want. Or I can define nil.nil? to be
false, or Object#nil? to be true, and make the interpreter crash.
Next to all of that, the ability to rebind a method to an unrelated
class seems relatively sane. You could even have UnboundMethod#bind keep
doing what it does, and add an UnboundMethod#bind! to do the more
“dangerous” thing.
Why shouldn’t I be able to do:
a.method(:foo).unbind.bind(b)
when a and b aren’t related, but I happen to know they share a common theme?
Because this is an indication that your code is not well structured.
If they share a “common theme” this theme could be packaged into a
module and properly documented.
Just as, in Java, I shouldn’t miss duck typing, because if they’re
really related, they should share common ancestry.
Just moving one method over is an ad
hoc solution which - when applied with only moderate frequency - will
give unreadable and thus unmaintainable code very soon.
Again, I’m not seeing how this has any more potential for disaster than
duck typing or metaprogramming. Those have as much capacity for misuse.
Now, not doing that often is probably a good idea – not using
Kernel#eval often might also be a good idea. But I don’t like it when a
tool tells me what I may or may not do, simply because it’s not a good
idea.
Even better: have it already in the standard library or language.
Even if it’s on CPAN already, you still need to add this other
external module to your project etc.
I tend not to build things that don’t rely on at least a few external
modules. I would rather have a language flexible enough to build things
like this as an external library, in the language itself, than one that
has everything built in.
In fact, that’s one complaint about Perl (or PHP) – they both have a
lot built in, and a lot polluting the root namespace, for things that
may have once been very common tasks. I believe Perl has finally moved
the report syntax into a different module – keep in mind, Perl is
called practical extraction and report language, but they decided
reports no longer belong in the core language. I know I’d be (slightly)
happier with PHP if templating wasn’t a part of the core language.
It matters because you might take longer because you need to first
build complex structures out of your basic building blocks because
they are not present in the language.
Unless, of course, they’re already there on CPAN.
It matters because some poor
maintainer has to read all the code and understand in order to apply
his changes.
That’s a bit like saying we shouldn’t use Rails, because any potential
maintainer will have to learn Rails as well as our own codebase. And
that is somewhat true – Symbol#to_proc wasn’t in core Ruby at the time.
But I think it’s reasonable to make the core language smaller, and push
things into frameworks, so long as the syntax doesn’t suffer. (That’s a
big reason I prefer Ruby – syntax.)
I’m not trying to sell Perl’s OO as the best thing, or even “better”.
But I’m defending it as inherently less useful than Ruby’s. Someone
might as easily say that Ruby’s OO is inherently less useful than
Java’s, because Java does stricter (static) type-checking.
On Sun, Feb 08, 2009 at 10:23:15AM +0900, Nico Bonada wrote:
William J. wrote:
“one” is singular, so it’s “best meets his”.
it is unacceptable to a great many readers either to resort to
nontraditional gimmicks to avoid the generic masculine (by using
he/she
or s/he, for example) or to use they as a kind of singular pronoun.
On Sun, Feb 08, 2009 at 08:28:52AM +0900, Igor P. wrote:
and concentrate on educating newcomers about Ruby!
OCaml isn’t any “X-sharp” language. It has decent support for both
functional and object oriented styles, and can in fact do the latter in
significantly fewer (and cleaner) lines of code than C#.
There’s nothing about vi(m) that prevents one from using other
indentation schemes than an eight-space tab effectively. There’s
nothing
about GUIness that makes an editor inherently better or more “modern”.
If you really think the topic should be limited to Ruby, you might want
to start with taking your own advice, and trying to avoid dragging
editor
flame wars and your uninformed opinions about languages other than Ruby
into the discussion.
Igor P. wrote:
things that what you get by using it is redundancy and more work, the
things that good OO is trying to minimize if not eliminate.
Granted…
what you call lack of type-checking can arguably be considered one of
Ruby’s big advantages over those languages that have this feature.
Yes, I realize this. However, you should also realize that both Perl and
Javascript have a few similar features that make Ruby actually stricter
than either. The examples I gave both revolve around the fact that in
Perl and Javascript, functions (or subroutines) are just that. They can
be used as methods, and thus related to an object or a class, but they
are not inherently tied to that object.
In Ruby, however, I can’t use a method from one class on a method from
another class, unless the two classes are related. I also can’t use a
class as a module. In other words, it’s the exact same sort of static
type checking, protect-you-from-yourself mentality as Java.
Strictly, from a pragmatical point of view, it makes much more sense
classifying objects based on what they can do rather than to which
“aristocracy” they belong.
Except that Ruby enforces the aristocracy with respect to which methods
belong to which classes.
It takes to much effort
in procedural languages to account for that which they lack!
Except Perl is not strictly procedural, and Javascript actually has a
very nice prototypal object system.
On Mon, Feb 09, 2009 at 12:09:52AM +0900, Julian L. wrote:
You could also look into The project to concert ruby to obj-c which is
compiled. Am I dreaming? I can’t remember the name
Wait . . . seriously? I need to find this project. That sounds like
fun.
Reid T. wrote:
BAILOUT = 16
if (i == 0)
int iterate (double x, double y)
double temp = 0.0;
if ( zi2 + zr2 > BAILOUT)
{
return i;
}
if ( i > MAX_ITERATIONS)
{
return 0;
}
}
}"
end
end
time = Time.now
Mandelbrot.new
puts
puts “Ruby Elapsed %f” % (Time.now - time)
Using the functional language F#:
0.0400575999999999 on my laptop with 2GHz Pentium.
let bailout = 16.0
let max_iterations = 1000
let iterate x y =
let cr = y - 0.5 and
ci = x and
zi = 0.0 and
zr = 0.0 in
let rec loop zi zr i =
if i > max_iterations then
0
else
let temp = zr * zi and
zr2 = zr * zr and
zi2 = zi * zi in
if zi2 + zr2 > bailout then
i
else
loop (temp + temp + ci) (zr2 - zi2 + cr) (i + 1)
in
loop zi zr 1
let mandelbrot () =
for y = -39 to 38 do
print_endline “”;
for x = -39 to 38 do
let i = iterate
(float x / 40.0) (float y / 40.0) in
System.Console.Write( ( if 0 = i then “*” else " " ) )
done
done
let start_time = Sys.time ()
let _ = mandelbrot ();
print_endline “”;
System.Console.Write (Sys.time () - start_time)
Chad P. wrote:
On Mon, Feb 09, 2009 at 12:09:52AM +0900, Julian L. wrote:
You could also look into The project to concert ruby to obj-c which is
compiled. Am I dreaming? I can’t remember the nameWait . . . seriously? I need to find this project. That sounds like
fun.
i googled, but couldn’t find anything – if you happen to run across it
pls ping
me with the url
thanks,
reid
William J. wrote:
i = iterate(x/40.0,y/40.0) builder.c " int i = 0; endUsing the functional language F#:
0.0400575999999999 on my laptop with 2GHz Pentium.
On same box using all C.
Echo delay is 0s and 20842us -> 20842 microseconds = 0.020842 seconds.
This is
an Intel® Core™2 CPU 6320 @ 1.86GHz box w 2GB RAM running gentoo
with
entire system compiled with CFLAGS="-march=prescott -O2 -g -pipe" +
feature
splitdebug ( everything compiled with debug except mandInC ).
-rwxr-xr-x 1 rthompso staff 7104 2009-02-10 23:36 mandInC
time calc code pulled from the web…
rthompso@raker ~ $ cat mandInC.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
/**
-
this function is for computing the time difference between timeval x
and y -
the result is stored in result
*/
int
timeval_subtract (struct timeval *result, struct timeval *x, struct
timeval y)
{
/ Perform the carry for the later subtraction by updating y. */
if (x->tv_usec < y->tv_usec) {
int nsec = (y->tv_usec - x->tv_usec) / 1000000 + 1;
y->tv_usec -= 1000000 * nsec;
y->tv_sec += nsec;
}
if (x->tv_usec - y->tv_usec > 1000000) {
int nsec = (x->tv_usec - y->tv_usec) / 1000000;
y->tv_usec += 1000000 * nsec;
y->tv_sec -= nsec;
}/* Compute the time remaining to wait.
tv_usec is certainly positive. */
result->tv_sec = x->tv_sec - y->tv_sec;
result->tv_usec = x->tv_usec - y->tv_usec;/* Return 1 if result is negative. */
return x->tv_sec < y->tv_sec;
}
int iterate (double x, double y)
{
int BAILOUT = 16;
int MAX_ITERATIONS = 1000;
double cr = y-0.5;
double ci = x;
double zi = 0.0;
double zr = 0.0;
double zr2 = 0.0;
double zi2 = 0.0;
int i = 0;
double temp = 0.0;
while (1)
{
i += 1;
temp = zr * zi;
zr2 = zr * zr;
zi2 = zi * zi;
zr = zr2 - zi2 + cr;
zi = temp + temp + ci;
if ( zi2 + zr2 > BAILOUT)
{
return i;
}
if ( i > MAX_ITERATIONS)
{
return 0;
}
}
}
int main()
{
int y = -39;
int x = -39;
int i = -1;
struct timeval start, stop, echodelay; // start, stop and echo
delay times
if((gettimeofday(&start, NULL)) == -1)
{
perror("gettimeofday");
exit(1);
}
for (y = -39; y <= 39; ++y)
{
printf("\n");
for (x = -39; x <= 39; ++x)
{
i = iterate(x/40.0, y/40.0);
if (i == 0)
printf("*");
else
printf(" ");
}
}
if((gettimeofday(&stop, NULL)) == -1)
{
perror("gettimeofday");
exit(1);
}
/* compute time delay */
timeval_subtract(&echodelay, &stop, &start);
printf("\nEcho delay is %ds and %dus\n", echodelay.tv_sec,
echodelay.tv_usec);
return 0;
}