You wouldn’t know it from reading this blog but I actually do write
software on occasion. I’ve been changing the way I do things in
general, ditching old bad habits for new ones (always the optimist,
that never changes). To death with Stinking Linux Thinking:
simplicity and spending more time on the shoulders of giants is a
better way to get things done.

I do all my development now on OpenBSD-current, and one of the ways I
want to be different is by contributing more. At the very least I can
contribute a port of something when I need it and it isn’t there, but
getting involved in general (by action, not just words) is a constant
goal of mine, albeit mediated by my own wierdness. Whenever
opportunities present themselves I’m trying to take them up as
challenges instead of skulking off to do something else. Since I’ve
been meandering back towards Perl as my HLL/non-systems implementation
language (C being the latter) I’ve been trying to modernize and see
what The Cool Kids are up to.

Practically speaking, this means slogging through porting a bunch of
Perl modules to OpenBSD that I want to use, if only indirectly. Most
of them are deep dependencies that I’d honestly rather not have, but I
want some the modules that do the depending, so there’s nothing for it
but to port them, although I’m beginning to think there might be a
better way in some cases… I just don’t want my first instinct to
be screw it: this sucks when I run into tangled nests of
dependencies I’m not all that happy about. Instead I’m trying to
understand why and how this has happened and see what constructive
results I can get out of it… this is totally boring and not nearly
as much fun as getting drunk and cussing, I’ll admit. It’s like I’m
turning into Bob Ross or something (“let’s write a happy little class,
with a happy, simple little API… just get it on the canvas there,
next the the fluffy, happy clouds”; soundtrack: Heroin by the Velvet
Underground).

It’s been a few years since I was constantly hacking in Perl. I feel
like I’ve been in a far away land where spaces were all-important but
what was between the spaces was somehow less important. Now I’m back
in The Land of Radiant Code Density where sigils and strictures reign
supreme. The camel is a warm-blooded animal, after all, unlike the
snake.

A few things really strike me, perhaps just belatedly because I hadn’t
been keeping up on so-called Modern Perl (wait, I thought Perl was
permanently post-modern, no?).

Hey… I’m not that type of {guy,variable,object}

There seems to be an ever-growing pile of modules that attack the
“problem” of typelessness in Perl on many levels, frequently taking
exactly the same outer (sugar) approach while using radically
different approaches internally… maybe. Or maybe it’s just the
worst case of NIH ever, I don’t know. Function::Parameters
vs. Kavorka (vs. other stuff, I think, I started to glaze over a
bit). Type::Tiny vs. … nothing, it chooses instead to subsume
everything else rather than fight (I guess?). Do you want type
signatures in your functions? Return types? Real classes? Fake
classes that you can’t tell are fake? All of the above? You can have
it all, in the same address space, maybe even without knowing what
you’ve done.

It seems like typeless languages always end up growing a serious case
of type envy over time; likewise, strongly typed languages frequently
grow mechanisms to shrug off the Tyranny of Types. I guess it’s just
another instance of curly vs. straight: the peoples always want
whatever they don’t got, thus: hair salons.

Moosient Madness

Moose’s impact is absolutely enormous, and the set of modules that are
answers to / arguments with / augmentors of Moose is just crazed.
Moops is especially nuts in my opinion, but I admit I don’t have a
good feel for how much any given region of the extended Moose venn
diagram is actually inhabited by real software that uses it and not
pet projects that are more evangelical in nature. There are many ways
in which the Moose venn diagram and the ad-hoc type system diagram
interact as well; Moose’s psychic footprint extends well beyond mere
OO (although pure OO types will tell you there is no place beyond
“mere” OO).

I’m working on drawing The Definitive Diagram of Moosient Confluences.
I just need a bottle of single malt to do it; please donate, it’ll be
great, I swear.

Just Do It… even if it Makes No Sense (TMTOWTDI, remember?)

The Linux mindset (“just do{} it” perhaps?) has metastasized in parts
of the CPAN namespace to the point where it’s difficult to comprehend.
I specifically am thinking of the Alien::* way of interfacing with
external libraries. Modules like Alien::GCrypt for instance (which
something I need depends on) are especially problematic. The idea
here is Alien::Foo is some kind of dynamic, on-the-fly,
don’t-worry-about-the-details Perl interface wrapper to libfoo,
whatever that is. If libfoo is installed on your system, it loads it
with DynaLoader or something and does a magic elf dance. If it isn’t
installed (and this is the problem), the source code is DOWNLOADED on
the fly (what?), compiled while you wait (wait… What!?) and the
resulting .so/.dll/.dynlib/.nippon_goo files are stuffed lovingly into
some hidden directory where Alien::Foo will find them with DynaLoader
and It All Just Works so Don’t Worry ’bout The Guvament (okay,
seriously… WHAT!?).

My problem with all of this is that there is frequently already an
interface to the library in question. In the case of libgcrypt, for
instance, there is not one, but two Perl interfaces besides
Alien::GCrypt, which really leaves me wondering: why? Both of the
other interfaces are the traditional XS-based link-it-up-at-build-time
kind of interfaces that Perl supports so well. And yet, the module I
really want for my own use (Protocol::OTR) depends on several
Alien::*-style interfaces.

Here’s the rub in this (and at least one other) case: Alien::Base
provides common code to check if a library is installed, and it uses
pkg-config to do so. This is great as long as the library involved
uses pkg-config. You’d think this is sort of a de-facto standard
at this point, but it turns out there is or was hostility towards
pkg-config in certain quarters… like the land of GnuPG, where
libgcrypt hails from. Libgcrypt ditched pkg-config support
sometime in 2005, yet Alien::GCrypt blindly tries to use pkg-config
to find libgcrypt; as far as I can tell this will fail 100% of the
time on all platforms (success!?), which means the code that downloads
the source if necessary and compiles it on the fly comes into
play… which is not going to fly under OpenBSD, for what I consider
good reasons. Ports are not supposed to do things like download stuff
on the fly when you build them. I think this is sane and sensible,
for the same reason I think software that phones home for updates is
poorly considered.

This is where my “let’s just f’ing port it, then” attitude runs into a
wall that I must climb by non-technical means, and I’m always bad at
that. I’ve probably spent more time writing this dumb post than
engaging the relevant community (the gnupg-devel mailing list) to see
if they would mind (re)sprouting pkg-config bits. The thing is, I
can kind of see their point in a way, or I could see it in 2005. I
can also see how it might be considered annoying for someone to ask
for a “feature” request like that (please re-add something you ditched
for what you thought was a good reason a long time ago) because some
new, clueless interface wants to do something that you don’t support
(using pkg-config to find libgcrypt).

No matter what, I have to do something to make progress. I just had
never found myself in this position before…