Re: [tlug] Alternatives to sed + awk

[Josh Glover <jmglov@example.com>]

On 9 March 2011 18:04, Stephen J. Turnbull <stephen@example.com> wrote:

> Josh Glover writes:
>
>  > class String
>  >   def bar; reverse end
>  > end
>  >
>  > my_string = 'foo'
>  > my_string.instance_eval { def baz; reverse }
>  >
>  > puts 'Ruby is insane' if foo.bar.baz == foo
>
> I think that's actually more ugly than naughty.

For sure. It was a contrived example to show that Ruby gives you some
powerful meta-programming tools; using them responsively is up to you.

> So *that* kind of "power" *subtracts* from expressiveness.

One use of Ruby's power tools that certainly adds to expressiveness is
defining a domain-specific language without needing a parser. Lisp is
also good for that, in fact most non-trivial Lisp systems are built of
one or more DSLs woven together (at least according to Paul Graham and
"The Scheme Programming Language"--I have no experience writing
production Lisp).

> Adding methods to instances seems philosophically pointless.

It is quite useful for unit testing, when you don't add methods but
modify them. :)

> If you want to provide an operation on an instance, it seems to me
> that you either want to systematically create more similar instances,
> in which case you should subclass (or monkey-patch the class), or
> you don't, in which case use an ordinary function.

Or a lambda. :)

As far as I can recall, I think the only times I've used instance_eval
to add something to a specific object was to aid in debugging. More
experienced Ruby hackers like Zev and Kevin/Alain might know of other
good uses.

instance_eval itself is a wonderful thing, though. My example of
defining a method on a single instance is probably getting in the way
of understanding it: instance_eval takes a block and executes the code
inside it in an object-local binding (i.e. self is the object on which
you called instance_eval). So you can do stuff like this:

def test_crappy_class
  crap = CrappyClass.new
  assert_equal 0, crap.instance_eval{@example.com
  crap.increment
  assert_equal 1, crap.instance_eval{@example.com
end

class_eval does the same thing, but on a class object. Rails uses
class_eval to provide accessors for model objects automatically based
on a database table layout, in some way that is roughly equivalent to
this:

tables.each do |table|
  columns = columns_for table
  columns.each do |column|
    table.to_class.class_eval "def #{column}; @#{column} end; def
#{column}=(val); @#{column} = val end"
    end
  end
end

> Interesting.  Except Emacs isn't written in C, it's written in Lisp --
> and the amount of Lisp that is written in Lisp, not C, increases in
> every version.  I would suspect that neither is FireFox written in
> C++, not at the level that most of the add-ons target.

Right, Firefox is basically an application platform now. Except for
the C core, most of it is XUL and Javascript.

> The comment that Graham doesn't mention C is on target, but that's not
> surprising.  He doesn't mention assembler, either.  These aren't
> languages in the sense that Graham means.

Yeah, Graham was talking about something else to be sure. But it was
odd that in talking about languages that have survived for a long time
(and are likely to survive genetically much longer), C did not come
up. Lisp certainly is a marvel, but so is C. :)

> It's not really obvious to me that any of the programs that Adamson
> mentions are actually written in C, anyway.  They're written in "Xt" or
> "GTK+" or "wxWidgets" or whatever.

That is an interesting view. I can't say that I disagree, which may
actually be a strength of C. One wouldn't be able--IMO--to say the
same about a program written in Java, regardless of which widget
framework you were developing on. The Java-ness is just so
pervasive... *shudder* ;)

> This is especially true of Lisp, where pretty much every large program
> is written in a language which shares the very basic "an expression is
> a list starting with a function and followed by expressions" syntax,
> but most expressions are functions with very specific requirements on
> the arguments, thus looking a lot like syntax.

Yup. Lisp is really nice for letting you build what you need without
imposing many syntactic restrictions on you; it lets you impose them
on yourself. ;)

>  > As does Paul Graham:
>  > http://www.paulgraham.com/hundred.html
>
> avg.html is probably more to the point. :-)

Heh heh.

-- 
Cheers,
Josh