Friday, October 17, 2008

Everlasting Lovingkindness

Reading Psalm 136 (ESV), I see this:

Give thanks to the LORD, for he is good, for his steadfast love endures forever.
Give thanks to the God of gods, for his steadfast love endures forever.
Give thanks to the Lord of lords, for his steadfast love endures forever;
to him who alone does great wonders, for his steadfast love endures forever;
to him who by understanding made the heavens, for his steadfast love endures forever;
to him who spread out the earth above the waters, for his steadfast love endures forever;
to him who made the great lights, for his steadfast love endures forever;
the sun to rule over the day, for his steadfast love endures forever;
the moon and stars to rule over the night, for his steadfast love endures forever;
to him who struck down the firstborn of Egypt, for his steadfast love endures forever;
and brought Israel out from among them, for his steadfast love endures forever;
with a strong hand and an outstretched arm, for his steadfast love endures forever;
to him who divided the Red Sea in two, for his steadfast love endures forever;
and made Israel pass through the midst of it, for his steadfast love endures forever;
but overthrew Pharaoh and his host in the Red Sea, for his steadfast love endures forever;
to him who led his people through the wilderness, for his steadfast love endures forever;
to him who struck down great kings, for his steadfast love endures forever;
and killed mighty kings, for his steadfast love endures forever;
Sihon, king of the Amorites, for his steadfast love endures forever;
and Og, king of Bashan, for his steadfast love endures forever;
and gave their land as a heritage, for his steadfast love endures forever;
a heritage to Israel his servant, for his steadfast love endures forever.
It is he who remembered us in our low estate, for his steadfast love endures forever;
and rescued us from our foes, for his steadfast love endures forever;
he who gives food to all flesh, for his steadfast love endures forever.
Give thanks to the God of heaven, for his steadfast love endures forever



Think about these statements for a second: ...to him who struck down the firstborn of Egypt, for his steadfast love endures forever...

This doesn't sound like our definition of love, does it? Here we see God enacting judgment against the Egyptians, by striking down their firstborn. Here's how Webster defines love (the first of several): strong affection for another arising out of kinship or personal ties

Do you ever wonder if our definition of love falls dramatically short of reality?

Saturday, October 11, 2008

Dynamic Inheritance in Perl

Ok, I discovered this little tidbit while working on a relatively extensive project in Perl. I came across an issue where I had several OS-based "abstract" classes written in Perl (yeah, I know -- OOP in Perl is nothing but trouble), and I needed to inherit from one of them. The trick, however, was to do it dynamically, depending on the OS I was currently working on.

Casting scalars to functions and even classes is a pretty simple thing.

Consider the following example in foo.pl:

#!/usr/bin/perl

my $func = shift;
my $result = &$func(@ARGV);
print "$result\n";

sub add {
my ($x, $y) = @_;
return $x + $y;
}

sub subtract {
my ($x, $y) = @_;
return $x - $y;
}


The result of executing this code is fairly simple:

# perl foo.pl add 1 2
3
# perl foo.pl subtract 2 1
1

It's also possible to cast a scalar to a package/class type, allowing more flexibility on which objects or modules are called at run time.

Consider the following two files, foo.pl, bar.pm, baz.pm:

foo.pl:

#!/usr/bin/perl

my $pkg = shift @ARGV;
require "$pkg.pm"; # only load the package specified on the command line

my $class_ref = $pkg->new();

$class_ref->to_string();

bar.pm:

#!/usr/bin/perl
package bar;

sub new {
my $proto = shift;
my $class = ref $proto || $proto;
my $self = {};
bless ($self, $class);
return $self;
}

sub to_string {
my $self = shift;
return "bar says hello!\n";
}

1;

and baz.pm:

#!/usr/bin/perl
package bar;

sub new {
my $proto = shift;
my $class = ref $proto || $proto;
my $self = {};
bless ($self, $class);
return $self;
}

sub to_string {
my $self = shift;
return "baz says hello!\n";
}

1;


Now, execution looks like this:

# perl foo.pl bar
bar says hello!
# perl foo.pl baz
baz says hello!


Of course, there are some severe consequences of doing such practices. But, in my opinion, none of them compare to what else you can do with Perl's "cast-ability."


Consider the following hiearchy: Class linuxFoo is a class, specific to the Linux OS. Class solarisFoo is also a class, specific to the Solaris OS. Class Foo wants to inherit from either, but only does so in accordance to the OS it's currently running from. Here's the code:
linuxFoo.pm:

#!/usr/bin/perl
package linuxFoo;

sub new {
my $proto = shift;
my $class = ref $proto || $proto;
my $self = {};
bless ($self, $class);
return $self;
}

sub to_string {
return "This is Linux-based functionality!\n";
}

1;

solarisFoo.pm:

#!/usr/bin/perl
package solarisFoo;

sub new {
my $proto = shift;
my $class = ref $proto || $proto;
my $self = {};
bless ($self, $class);
return $self;
}

sub to_string {
return "This is Solaris-based functionality!\n";
}

1;

Foo.pm:

#!/usr/bin/perl
package Foo;

sub new {
my $class = shift;
my $os = $^O; # this gets the OS, in case you don't know

# require the correct module, and use it as the parent
my $pkg = $os . "Foo";

require "$pkg.pm";
our @ISA = $pkg;

my $self = $class->SUPER::new();

bless ($self, $class);
return $self;
}

sub to_string {
my $self = shift;
return $self->SUPER::to_string();
}

1;


and test.pl:

#!/usr/bin/perl

use Foo;

my $class_ref = Foo->new();

print $class_ref->to_string();


The result of running this script on two different operating systems (linux and solaris) is as follows:

# perl test.pl # on linux
This is Linux-based functionality!
# perl test.pl # on solaris
This is Solaris-based functionality!


Now, why is this a bad idea??


Creating function references on the fly via string values is always iffy. It requires a full-knowledge of the underlying code in order to correctly identify which methods are required. Though it's possible to abstract this out to some extent (forcing function/method names to use a value which is immutable for the system--e.g. the OS type), it still creates a brittle interface in which to work.


Dynamically creating and using modules is likewise a bit iffy as well. Should a module need to be refactored in the future (or is replaced with a different one), this forces the programmer to update the string which is used to create it.


Either way, the ability to use a string value to execute a function or use a module is tenuous at best. Dynamic inheritance, however, is downright dangerous. Users can take objects and randomly redefine their hierarchical structure however and whenever they want. Languages such as Java and C++ (to name a few) prevent this by statically typing their classes at compile-time. This forces the contracts imposed by inheritance and interfaces (e.g. interface methods are always implemented, inherited methods are always present via the parent, etc.).


Dynamic inheritance throws it all out the window. If you have a Dog object, it can randomly inherit from a Wheel object. Not only this, it can inherit from a Wheel after it's already inherited from a Fire Hydrant. Ok, the rule of odd and bizarre inheritance structures is present in all languages. But redefining the structure at any point in the code, without compile-time checks, makes Perl a fun, but screwy and dangerous language to program in.


...of course...some would say not to do OOP in Perl, which is why I'm transitioning to Python...

Reformation Technologies

Well, I've done a few other blogs in a few other places, and this is probably my final resting place. It hasn't been worth paying for the previous services, so I'll work with something free for once.

This blog is devoted specifically to discussing issues of technology and religion, specifically, Christianity.

While I don't necessarily consider myself to be "Reformed," I have been steadily deriving more and more of my theology (as a born-again Christian) from the Protestant Reformation and the early church fathers. Issues such as Calvinism, Amillenialism, Covenant Theology, and other such issues are fair game here.

I'm also a programming junkie, so I will use this blog for discussing various technologies and programming tips, tools, and techniques.

Other posts might be devoted to my family occurrences and whatnot, for those in my family who live farther away.