Now that Hal, David B, Curt, and others have some spare time:
I'm an old-school, procedural programmer. I skipped C++ and Java, and went
straight from PL/I to Ruby. Wow, times have changed!
So I haven't developed the idioms that powerful languages like Ruby make
possible: reflection, method_missing-isms, binding, continuations, lambdas,
blocks, etc. My code still looks like it used to, only prettier.
I've seen some articles on metaprogramming online, but none are both (a)
soup-to-nuts walkthroughs and (b) Ruby-specific. Besides, I think this is
a topic worthy of a book-length screed. Ideally, it'd assume basic
knowledge of Ruby syntax and of programming in general, but not of dynamic
programming. Maybe write it with a C programmer in mind.
Doing that without looking at the answers first will show you most of
the useful metaprogramming ropes. Coming straight from PL/I (JCL in
the house!) will be a bit of a cold splash, but I think it is a good
(if tough) intro.
···
On 11/5/06, Jay Levitt <jay+news@jay.fm> wrote:
Now that Hal, David B, Curt, and others have some spare time:
I'm an old-school, procedural programmer. I skipped C++ and Java, and went
straight from PL/I to Ruby. Wow, times have changed!
So I haven't developed the idioms that powerful languages like Ruby make
possible: reflection, method_missing-isms, binding, continuations, lambdas,
blocks, etc. My code still looks like it used to, only prettier.
I've seen some articles on metaprogramming online, but none are both (a)
soup-to-nuts walkthroughs and (b) Ruby-specific. Besides, I think this is
a topic worthy of a book-length screed. Ideally, it'd assume basic
knowledge of Ruby syntax and of programming in general, but not of dynamic
programming. Maybe write it with a C programmer in mind.
Now that Hal, David B, Curt, and others have some spare time:
I'm an old-school, procedural programmer. I skipped C++ and Java, and
went
straight from PL/I to Ruby. Wow, times have changed!
So I haven't developed the idioms that powerful languages like Ruby make
possible: reflection, method_missing-isms, binding, continuations,
lambdas,
blocks, etc. My code still looks like it used to, only prettier.
I've seen some articles on metaprogramming online, but none are both (a)
soup-to-nuts walkthroughs and (b) Ruby-specific. Besides, I think this is
a topic worthy of a book-length screed. Ideally, it'd assume basic
knowledge of Ruby syntax and of programming in general, but not of dynamic
programming. Maybe write it with a C programmer in mind.
Anyone wanna write this next?
Jay Levitt
--
Chris Carter
concentrationstudios.com
brynmawrcs.com
We do need an advanced Ruby text. I think a lot of what it would
cover would be metaprogramming. It would also be nice if it covered
things like functional programming (kind of like the "Higher Order
Perl" book). I'd like to be involved in writing some chapters for a
book like that (esp metaprogramming and DSL chapters)... but I wouln't
want to write a whole book as it's just way too much work for one
person (with not much return, really). However, "many hands make the
work easier" - if we got 4 or 5 people together to work on an
advanced Ruby book it would likely get done a lot faster and it
wouldn't seem like an impossible task. Are there other potential
authors who feel the same way?
Phil
···
On 11/5/06, Jay Levitt <jay+news@jay.fm> wrote:
Now that Hal, David B, Curt, and others have some spare time:
I'm an old-school, procedural programmer. I skipped C++ and Java, and went
straight from PL/I to Ruby. Wow, times have changed!
So I haven't developed the idioms that powerful languages like Ruby make
possible: reflection, method_missing-isms, binding, continuations, lambdas,
blocks, etc. My code still looks like it used to, only prettier.
I've seen some articles on metaprogramming online, but none are both (a)
soup-to-nuts walkthroughs and (b) Ruby-specific. Besides, I think this is
a topic worthy of a book-length screed. Ideally, it'd assume basic
knowledge of Ruby syntax and of programming in general, but not of dynamic
programming. Maybe write it with a C programmer in mind.
Actually, if Martin Fowler wants to write another book, he should expand
"Refactoring" and translate it into Ruby.
Seriously, though, I'm not sure a whole book on metaprogramming,
Ruby-based or otherwise, is either necessary or useful at this point in
the technology cycle. There are quite a few articles on the subject.
What I'd rather see a book on is dealing with *concurrency* in Ruby.
Dual-core and quad-core chips aren't going away. Francis? You're our
resident expert, I think ...
Actually, if Martin Fowler wants to write another book, he should expand
"Refactoring" and translate it into Ruby.
Seriously, though, I'm not sure a whole book on metaprogramming,
Ruby-based or otherwise, is either necessary or useful at this point in
the technology cycle. There are quite a few articles on the subject.
What I'd rather see a book on is dealing with *concurrency* in Ruby.
Dual-core and quad-core chips aren't going away. Francis? You're our
resident expert, I think ...
But concurrency in Ruby is still green threads, so that would have to be either concurrency with YARV, or concurrency with separate Ruby processes communicating in some way.
I second the request for a book on metaprogramming.
Still, the links provided are a great start, thanks all!
+1 on both counts.
Anybody writes that book, I'm buyin' in.
--and 5 or 6 authors is a /great/ idea.
Make it a tiny book--5 or 6 chapters, one chapter
on each of the cool topics.
:_)
Well, there's Ruby non-blocking IO methods. There's also the sensational EventMachine library.
James Edward Gray II
···
On Nov 7, 2006, at 8:23 AM, Ola Bini wrote:
But concurrency in Ruby is still green threads, so that would have to be either concurrency with YARV, or concurrency with separate Ruby processes communicating in some way.
Actually, if Martin Fowler wants to write another book, he should expand
"Refactoring" and translate it into Ruby.
Seriously, though, I'm not sure a whole book on metaprogramming,
Ruby-based or otherwise, is either necessary or useful at this point in
the technology cycle. There are quite a few articles on the subject.
What I'd rather see a book on is dealing with *concurrency* in Ruby.
Dual-core and quad-core chips aren't going away. Francis? You're our
resident expert, I think ...
But concurrency in Ruby is still green threads, so that would have to
be either concurrency with YARV, or concurrency with separate Ruby
processes communicating in some way.
That was actually my purpose in making the suggestion ... to stimulate
debate about concurrency in Ruby, the major differences between the
current 1.8 and proposed 1.9/2.0 concurrency tools, the way other
languages deal, successfully or unsuccessfully, with concurrency, etc.,
etc., etc.
I think Erlang is the horse to challenge in this race, or perhaps, on a
more theoretical note, the Pi-calculus. And right now, EventMachine
appears to be Ruby's horse in the race, which is why I suggested that
Francis write the book.
On a related note, some Scheme folks have implemented "Erlang-like"
lightweight processes. Here's a link to the paper; I've got the software
installed but haven't had a chance to experiment with it.
Seriously, though, I'm not sure a whole book on metaprogramming,
Ruby-based or otherwise, is either necessary or useful at this point in
the technology cycle. There are quite a few articles on the subject.
What I'd rather see a book on is dealing with *concurrency* in Ruby.
Dual-core and quad-core chips aren't going away. Francis? You're our
resident expert, I think ...
But concurrency in Ruby is still green threads, so that would have to be
either concurrency with YARV, or concurrency with separate Ruby
processes communicating in some way.
I've done concurrent Ruby processes, with System V IPC shared memory (to
shove video around and do the control from Ruby). It did the job on a
hyperthreading dual Xeon (4 virtual CPUs on linux, a dozen Ruby processes or
so). The code is owned by my employer, tho.
A wrapper around sys V has been done by others, too; mix in a bit of dRb and
I think you're rolling (except when you want Erlang-level of performance).
Anyone have experience with grid?
Bye,
Kero.
PS: You could easily do these performance chapters:
- system V
- grid
- Yarv
- embedded systems
- fast libraries (narray comes to mind)
- hints for optimizing ruby-code (?)
and I'm sure there's more.
--and 5 or 6 authors is a /great/ idea.
Make it a tiny book--5 or 6 chapters, one chapter
on each of the cool topics.
Umm, please no. I'd prefer a coherent in-depth text, preferrably one
that eschews "cool" as much as possible. Even if Ruby makes wome witty
hacks easy and lets them hobble along without breaking for quite a
while, metaprogramming is not an easy topic, even -with- the amazingly
direct access to the object model Ruby gives you it's error-prone, and
I'd hate a superficial book that would make it look simpler than it is
and spawn the Ruby/meta equivalent of VB6.
On a related note, some Scheme folks have implemented "Erlang-like"
lightweight processes. Here's a link to the paper; I've got the software
installed but haven't had a chance to experiment with it.
On 7 Nov 2006, at 15:34, M. Edward (Ed) Borasky wrote:
That was actually my purpose in making the suggestion ... to stimulate
debate about concurrency in Ruby, the major differences between the
current 1.8 and proposed 1.9/2.0 concurrency tools, the way other
languages deal, successfully or unsuccessfully, with concurrency, etc.,
etc., etc.
A wrapper around sys V has been done by others, too; mix in a bit of dRb and
I think you're rolling (except when you want Erlang-level of performance).
As a matter of fact, that's exactly what I want! Erlang or Termite Scheme lightweight processes, thousands of them, on thousands of nodes!
