When I was struggling with XML parsing in Ruby, the consensus was to try out libxml. I got on the devel mailing list in preparation for giving it a shot. Unfortunately, this exchange on the mailing list has changed my mind:

I’m curious about the development status of libxml.
My application still core dumps fairly regularly though not in any way
that has proven useful for tracking down problems.
Is there any active development looking into the memory problems?
What is the status of libxml and libxsl for ruby 1.9?
Thanks.
__
Marc

I have been unable to continue work, my personal life not allowing. However,
the amount of effort that I have put into this has not cleared the library
of all its problems and it really needs active shared involvement of more
than just a single developer. This is sort of asking for manna, but the
number of people using this library and the number of issues with it are too
much for a single developer needing to make a living.

Dan

Since I don’t feel like becoming the developer of libxml right now (I’ve got plenty of other stuff on my plate), I’m going to pass on trying it out.

Hopefully, Hpricot really will handle namespaces as nicely as Garrick says. Otherwise, I’m going to have to rewrite my app in Groovy/Grails and install a bunch of new infrastructure to support it (e.g. JVM, Tomcat/Winstone). That would be unfortunate.

Popularity: 5% [?]

Cite.

Nothing interesting — just reporting that I text and drive on occasion. And (randomly) that I don’t try to dig my phone out of my pocket if it’s ringing.

But I figured I’d mention it.

(BTW, this interview was prompted by a Twitter from @jojeda.)

Popularity: 1% [?]

In a conversation lamenting the delay in conversion between academics and practice, @mfeathers on Twitter said:

We’ll see. I think dynamic typing is a classic “worse is better” scenario. Won’t win arguments. Will win longevity.

To which I replied:

Yeah, we’ll see. I’m really hoping not — dynamic languages really do suck for long-term maintenance. Ask the old Perl hackers.”

Then a realization hit me. Actually, it’s less of a realization and more of a hypothesis which needs testing. I’m curious to know what other people think.

Despite what a certain curmudgeonly ex-coworker of mine might claim, huge Perl scripts are a maintenance nightmare. They’re really a pain. Ranging from surprising overrides of $_ to wrong arguments being passed around to funky results from eval to magical exceptions, the major Perl applications I’ve worked on have had a lot of pain. The best helper to solve this problem is perl -c, use warnings; and use strict; — in other words, bringing more restrictive syntax and typing into the system. Prototypes even help, despite their unpopularity.

Yet there’s a major maintenance win with Ruby/Rails as opposed to the Java web frameworks I’ve worked on. So that cognitive dissonance hit me, and then I realized what the difference was: the configuration over convention. There’s less code to write in Ruby/Rails as opposed to the Java web frameworks, but that has more to do with all the magical injection than the language features themselves.

And there’s no reason that kind of magic can’t be done in the context of a statically typed language, provided some preprocessing to pull out the boilerplate.

At that point, you could have your cake and eat it, too.

Thoughts?

Popularity: 1% [?]

Write a game which randomly generates a number between 0 (inclusive) and 100 (exclusive), and then prompts the user for a number: if the user guessed the number, exit; else, tells them if they should guess higher or lower.

And do it in as few characters as possible.

(Ruby impls particularly desired.)

Popularity: 4% [?]

Seems like I was a bit hasty in my condemnation of Ruby XML parsing: Hpricot apparently handles namespaces okay through the magical .%() syntax. This tip is shared by Garrick Van Buren based on a Ruby.MN mailing list conversation.

I’ll let you know how well it works out for me.

Popularity: 1% [?]