This is precisely the kind of thing I've been doing in Ruby. That's what I was getting at when I said it was dynamic.
It's possible to re-define a class, function, method, etc. at run-time, as often as you'd like.
The thing about Ruby is that, while it looks a lot
like languages people are often used to, it has
"stolen" these sorts of things from other languages.
I think, basically, Matz is a pragmatist. He's
taken everything that other people seem to have
gotten right and put them all together... he's
not finished yet, of course:-).
Interestingly, it looks like Python is going the
same way. Every time someone mentions something
nice from Ruby, someone from the Python community
jumps in and says "that's planned for the next
version".
That's definitely not intended as a "we got it
right and everyone else is following us" comment.
What I mean is that both languages are moving
closer together. I believe the next version of perl will have some of these things, too.
I say, play with as many languages as you can
and choose one that you feel comfortable and
productive with.
While I, personally, hate perl's "line noise",
I say if you're happy with that and you get work
done, use it. I also say, however, that you should
never pick one language and just stop there.
I think that in, say, 20 years, very likely none
of us will still be writing in any of the languages
we currently love. Of course, C is still around after more than that, but very few people still
write in pure C.
If we didn't create and experiment with new languages we'd all still be writing assembler or
fortran or cobol.
Sorry, my point was that the "require" happens at
run-time, based on the result of the test.
In other words, it's not a compile-time thing,
as it would be in C/C++/Java. Someone else
pointed out that's possible in Python, too.
I guess Ruby is just the first place I've seen
it, so I'm overnthusiastic:-).
Yes. Ruby is totally dynamic. It's the only language
I know about (and that doesn't mean there aren't
others) where you can do things like...
if familiar
require 'freddy'
else
require 'frederick'
end
(Sorry about the strange format of that, but I
couldn't get a pre tag to work in/.; can someone
tell me how to get preformatted stuff into HTML posts?)
The "require" is similar to C's #include or Java's
"import".
So, this code potentially pulls in completely
different definitions of things depending on a
run-time variable.
One might ask whether this is useful in practice?
I've used it to allow
dynamic changes to a long-running program without
having to shut it down and re-start it.
When you say all the entries fail, it would
appear that they're all versions of the same
program (ie, just iterative attempts to improve its performance).
A much more important thing in this kind of
competition is whether the programmer can handle
the problem. The fact that one person who decided
to write it in Ruby didn't get it 100% (and some
of them did reasonably well), doesn't mean the
programming language is broken.
He/she obviously put a fair bit of time into it
(I presume, from the number of entries), but they
may simply have not had the right background for
that specific task.
I just wish everyone who's posting messages like
"why do we need another language" would
download Ruby and have a go. Surely, that must
have been what people said about C++, perl, java,
python at one point.
After doing so, I then wish that if they liked or
didn't like it, they'd give specific reasons, rather
than wishy-washy ones. You might be surprised by how receptive the developer is to suggestions for
improvements to Ruby.
That way, even if the person who tried Ruby and
didn't like it never ended up using it, the Ruby
community could still gain something.
These people have been told they should comment
their code. So, they do when they can.
When you
see this kind of thing, it normally means the
person who wrote the code didn't have a clue
what they were doing in the uncommented code,
hence they had no way of writing anything.
If you're managing someone like this, just
ask them to comment that code and then see
whether it makes sense. If you can't understand
it, throw the code away and get someone who
can really code to rewrite it.
Hopefully, the person who wrote the original
will eventually realise that fluffing their
way through isn't going to cut it and will try
to learn from the rewritten code and/or ask
for some help next time they hit something they
don't know how to do.
Re:Because O'Reilly spent too much $$$ promoting
on
Why not Ruby?
·
· Score: 1
If there's more than one Ruby book in English, please
let we Ruby hackers in on it:-).
The only such book I've ever heard of is Programming
Ruby from Addison-Wesley.
There are a couple of other books from O'Reilly, but currently only in Japanese.
Of course, I'm not sure we need a hundred books
on Ruby. The one we have is excellent, the
on-line support from newsgroups and mailing lists
is fantastic and the language is just so darned
intuitive that most of the time you can guess how something works, without needing to read about it.
I guess some books on things like doing database
or web development or using library X might be
nice.
Re:Ruby is still too new
on
Why not Ruby?
·
· Score: 1
Actually, there's already a DBI module that supports pretty much any database.
I believe it may even have been designed to look like perl's.
Re:What value does it add?
on
Why not Ruby?
·
· Score: 1
No. In fact, it doesn't even do anything that assembly language or machine code can't do. Pathetic, eh:-) ?!
Seriously, though, I don't know anyone who's played with Ruby who hasn't thought it was very nice and an incredibly productive language to work in.
Admittedly, some of those people still write perl or python, or whatever, because they're forced to at work or because they need some library that's not available (yet) for ruby.
But many of those still write ruby for fun, when they can, because it really is very productive and intuitive.
Slashdot Mirror
to arbitrary objects in Ruby, too.
Of course, Ruby is also OO.
It's possible to re-define a class, function, method, etc. at run-time, as often as you'd like.
The thing about Ruby is that, while it looks a lot like languages people are often used to, it has "stolen" these sorts of things from other languages.
I think, basically, Matz is a pragmatist. He's taken everything that other people seem to have gotten right and put them all together ... he's
not finished yet, of course :-).
Interestingly, it looks like Python is going the same way. Every time someone mentions something nice from Ruby, someone from the Python community jumps in and says "that's planned for the next version".
That's definitely not intended as a "we got it right and everyone else is following us" comment. What I mean is that both languages are moving closer together. I believe the next version of perl will have some of these things, too.
I say, play with as many languages as you can and choose one that you feel comfortable and productive with.
While I, personally, hate perl's "line noise", I say if you're happy with that and you get work done, use it. I also say, however, that you should never pick one language and just stop there.
I think that in, say, 20 years, very likely none of us will still be writing in any of the languages we currently love. Of course, C is still around after more than that, but very few people still write in pure C.
If we didn't create and experiment with new languages we'd all still be writing assembler or fortran or cobol.
In other words, it's not a compile-time thing, as it would be in C/C++/Java. Someone else pointed out that's possible in Python, too. I guess Ruby is just the first place I've seen it, so I'm overnthusiastic :-).
(Sorry about the strange format of that, but I couldn't get a pre tag to work in /.; can someone
tell me how to get preformatted stuff into HTML posts?)
The "require" is similar to C's #include or Java's "import".
So, this code potentially pulls in completely different definitions of things depending on a run-time variable.
One might ask whether this is useful in practice? I've used it to allow dynamic changes to a long-running program without having to shut it down and re-start it.
A much more important thing in this kind of competition is whether the programmer can handle the problem. The fact that one person who decided to write it in Ruby didn't get it 100% (and some of them did reasonably well), doesn't mean the programming language is broken.
He/she obviously put a fair bit of time into it (I presume, from the number of entries), but they may simply have not had the right background for that specific task.
I just wish everyone who's posting messages like "why do we need another language" would download Ruby and have a go. Surely, that must have been what people said about C++, perl, java, python at one point.
After doing so, I then wish that if they liked or didn't like it, they'd give specific reasons, rather than wishy-washy ones. You might be surprised by how receptive the developer is to suggestions for improvements to Ruby.
That way, even if the person who tried Ruby and didn't like it never ended up using it, the Ruby community could still gain something.
These people have been told they should comment their code. So, they do when they can.
When you see this kind of thing, it normally means the person who wrote the code didn't have a clue what they were doing in the uncommented code, hence they had no way of writing anything.
If you're managing someone like this, just ask them to comment that code and then see whether it makes sense. If you can't understand it, throw the code away and get someone who can really code to rewrite it.
Hopefully, the person who wrote the original will eventually realise that fluffing their way through isn't going to cut it and will try to learn from the rewritten code and/or ask for some help next time they hit something they don't know how to do.
The only such book I've ever heard of is Programming Ruby from Addison-Wesley.
There are a couple of other books from O'Reilly, but currently only in Japanese.
Of course, I'm not sure we need a hundred books on Ruby. The one we have is excellent, the on-line support from newsgroups and mailing lists is fantastic and the language is just so darned intuitive that most of the time you can guess how something works, without needing to read about it.
I guess some books on things like doing database or web development or using library X might be nice.
I believe it may even have been designed to look like perl's.
Take a look at ...
Ruby DBI
Seriously, though, I don't know anyone who's played with Ruby who hasn't thought it was very nice and an incredibly productive language to work in.
Admittedly, some of those people still write perl or python, or whatever, because they're forced to at work or because they need some library that's not available (yet) for ruby.
But many of those still write ruby for fun, when they can, because it really is very productive and intuitive.