The Limitations of the CPAN

[Ovid]

Crossposted to my use.perl journal.

I'll shortly be leaving my current employer to go work for Kineticode. In the year and a half I've been working here, I've learned some valuable lessons. Perhaps the most important is my first exposure to what can truly be termed "enterprise-class Perl." This isn't my first exposure to coding on such a large scale, but COBOL is such a foreign world that it doesn't count (it was successful partially because of its limitations, not in spite of them.)

What did I learn about large-scale programming with Perl? I learned that I like Ruby. I am no longer convinced that Perl is the best dynamic language for such projects. You've heard the arguments before -- I mostly focus on the poor OO model -- but the strongest counter-argument that I hear is "the CPAN." That's a pretty strong counter-argument. Yet counterintuitively, it's far less persuasive for large-scale projects because those projects are to solve a crucial business problem and that problem is not a reimplementation of CGI.pm.

If I need a general purpose tool that solves a wide range of problems, Perl is an excellent choice, due in large part to the CPAN. However, the core of a large system, the value of a large system, is not in CPAN modules. If it were, everyone could just go out and download them and instantly make money. That is not how the real world works.

The real world is also poorly represented in OO classes as taught in college. (Bear with me as this is relevant to the above.) I remember taking my very first Java class. It was taught by an instructor who seemed to know the language, but was a bit hazy on OO theory. However, this was her very first term teaching and I'll cut her some slack, but she had the problem that I see in many classes. She used examples that don't translate to the real world.

This instructor taught OO design by modeling nouns. A Dog isa Mammal isa Animal. A Firetruck isa Truck isa Vehicle. A BadExample isa DangerousExample. Of course, nouns can still be instructive as teaching tools. Showing why Programmer and Manager roles should not be subclasses of Employee is a great example of OO theory. The reality, though, is that good objects frequently reflect abstract business requirements and as your business is more specialized, your objects are more specialized. Those classes will not be found on the CPAN. They are what truly represents your business value.

This isn't to say that the CPAN is worthless. Modules on the CPAN tend to represent more abstract concepts than Vehicle::Truck::Firetruck and, regardless of the language you use, if there is a large body of prewritten code available and it suits your needs, it may be worth reusing it. However, many of the core features necessary are available in other languages. Today, if we were to rewrite our code from scratch, I think we would reach for Ruby.

Now here's my "ace in the hole" argument: Our Perl is not what you think. Sure, it's easy for me to sit here and say Perl's CPAN isn't the end all and be all when we use it so frequently. However, most (not all) things that we use from the CPAN are either readily available in other languages are are easily cobbled together. The heavy lifting -- those things that are the core value in our code -- has all been built in-house for our needs. Case in point:

# shown here with permission but still munged to hide details
my $dataset = Dataset->new(
    [ qw/rev state title_name xtns polled/ ],
    [ qw/state/ ],
    [ qw/rev/ ],
    $request
);

That little snippet builds a 30 line SQL statement that only shows data the user is allowed to see and creates a dataset that, with a one-line command in our templates, builds a large, paged, sortable report. We can effectively treat our entire database as if everything came from a single table. We just ask for the information we want and how to group and sort it. There is no need to specify the tables we are pulling from or how to join them together. There is also no reason why this needed to be written in Perl.

Of course, we do use an OORDBMS mapper. We wrote our own because the ones that existed when we created ours were in their infancy.

We also use a home-grown xUnit style test suite because Test::Class didn't exist when we wrote our version.

Despite our inventing or reinventing many wheels, we're destroying our only serious competitor in the department I work in. Why? They can't match our productivity. There are actually few companies in the world that can do the specialized data management that we do and that's in large part because of choosing a dynamic language, not because we used Perl.

This doesn't mean that Perl is a bad choice, either. Perl is fantastic, but if you want it to scale, you really need a stronger than average programmer and those can be tough to find. Just because Sally Admin or Joe Web Designer can cobble together a few scripts does not mean that they are qualified to build big systems. Most Perl programmers, in fact, are decidedly not qualified to work on those systems due to the dangers inherent in them. That's why Java has been so successful. Sally Admin may not be qualified to work on the Java system either, but, as she learns, she's less likely to wreak havoc on the system.

This, incidentally, is why I'm bullish on Perl 6. It appears to solve most of my Perl 5 problems. Tim Bunce has already mentioned that he plans to port DBI.pm to Perl 6, a Perl 6 CGI.pm won't be far behind (it might even be first) and I suspect that a few other core tools will quickly get ported. With those in place, and given that the real value in a business is the in-house code, if Perl 6 is stable and runs as fast as we suspect, maybe I won't be eyeing Ruby with such longing.

[dragonchild]

I agree with most of what you're saying, but I'm going to quibble with one thing.

Perl is fantastic, but if you want it to scale, you really need a stronger than average programmer and those can be tough to find . . . Most Perl programmers, in fact, are decidedly not qualified to work on those systems due to the dangers inherent in them. That's why Java has been so successful. Sally Admin may not be qualified to work on the Java system either, but, as she learns, she's less likely to wreak havoc on the system.

I'm not going to disagree with the statement, as it stands. However, I am going to vehemently disagree with the underlying sentiment. I hear it a lot, and it's so patently false it hurts.

If you want an enterprise-level system written in any language, you need a "stronger than average" programmer in that language, and those are always hard to find. Maintaining said system, in any language, takes an average programmer. Extending said system, in any language, takes a "stronger than average" programmer. There are no ifs, ands, or buts.

This problem has been more readily identified with Perl moreso than Java for two reasons, both of which are Perl's fault.

1. Perl is more accessible to the below-average programmer. This has lead many to think that Perl is designed for the below-average programmer, and isn't suitable for anything heavier.
2. Standards. Java has them, Perl doesn't. This means that you can take the average Java consultant off the street, plug them into your app, and you will not notice that the consultant is wrecking your system until they're gone. It's much harder to do the same with the average Perl consultant.
Now, I agree with the reasons behind both those issues, but they are still issues resulting in poor perception. But, it's just perception. The issues in building an enteprise-class application have nothing to do with the language used - they have to do with enterprise-class things. A top-notch COBOL programmer can build an enterprise-class application where an average Java developer will fail. Yet, why isn't COBOL the enterprise-class language of choice anymore?

The point here is that Perl is no more and no less suited to enterprise-class work than any other language. The skills needed to build an enterprise-class application are not language specific. Please stop promulgating that mismeme.

[Ovid]

The point here is that Perl is no more and no less suited to enterprise-class work than any other language. The skills needed to build an enterprise-class application are not language specific. Please stop promulgating that mismeme.

Sorry, but Perl has some significant issues for developing enterprise-class applications that other languages don't always have. For example, I was working on our code and noticed a test failure that I traced down to this line:

    open FOO, $bar;

When I saw that, a quick grep through our source code revealed this problem in a number of places, and not just with open.

Or how about this:

    $object->_private_method

Too bad that overrode a private method in a subclass.

Or how about this:

    $object->{recieved}++;

Whoops! That was unfortunate.

Or how about this:

    sub foo($$);

    # we'll just inherit foo() instead
    # sub foo {
    #     my ($self, $arg) = @_;
    #     ...
    #}

How many people will spot that bug?

Or how about this:

@ISA = $foo ? 'bar' : 'baz';

That's really fun to debug in a persistent environment.

And how about the fact that I signature-based method dispatch is not supported in Perl, so I have an entire class of bugs that simply doesn't exist in most other languages?

If any of those above examples seems contrived, I assure you that I've been bitten by every single one of them. Further, they lead to very subtle, frequenly intermittent bugs that are difficult to track down. In large systems, this compounds the problem. Most of the above issues are non-existent or a snap deal with in Ruby or Smalltalk.

[dragonchild]

For every one of those that you mention, I can name a similar issue in C/C++. As I don't know Ruby or Smalltalk, I cannot speak to those languages, but I'm sure they have similar issues. There are whole classes of bugs, in every language, that simply don't exist in some other language. Heck, Ovid, that's a major reason why new languages get written - to solve a class of bugs that some other language is rife with.
• Do you hate malloc()? Well, write a language that manages your memory!
• Do you hate dealing with variable typing? Write a language that's weakly typed!
• Do you hate having to write all your code up front? Write a language that does runtime compilation!
• Do you hate being constrained by awkward calling semantics? Write a language that doesn't have any!

And so on and so forth. The point is that Perl was designed to deal with whole classes of bugs and issues. Perl6 will be dealing with whole classes of issues that Perl5 has. Please note that many of these issues are problems other languages would love to have to deal with. They're "high-class issues". Kinda like having to decide between going on a free cruise and having to choose between your girlfriend and your best friend. It's a problem, but it's one most people wouldn't mind having.

I have also been bitten by most of the bugs you describe. I'm not disregarding them. And, I'm sure that Ruby solves many of them. Ruby should - it's designed by a former Perl hacker, who probably had many of the same frustrations you are expressing.

The thing you have to realize is that no language will protect you from typos, 3am hack sessions, or just plain old stupidity from your coworkers. I'm going to guess that you've been the lead developer for some time and have been very frustrated with the stupidity you've had to deal with. *shrugs* It's not Perl's fault ...

• ... your coworkers can't be bothered to read the documentation for open or to use lexical filehandles (which solves the problem).
• ... someone chose to use hashrefs for your objects and use direct access when there are literally hundreds of better solutions on CPAN, such as Class::MethodMaker.

Am I making any sense?

[stvn]

I will not disagree with you that those are all insidious bugs which in other languages would not exist, but I think this only supports dragonchilds point more. Bad programmers in perl are bad programmers in java are bad programmers in COBOL, etc etc etc. All your examples are, IMO, not examples of what is wrong with perl, but what is wrong the individual programmers who wrote them. Sure these particular problems might not exist in Java, but Java has it's own set of "bad programmer" mistakes which can be just as evil to debug and fix.

I don't believe you should blame the language, as much as you should blame the programmer. Disciple and experience would have solved all the problems you mentioned.

[rrwo]

Remember that Perl allows people who know what they are doing to do what they want. Which is great when you know what you're doing. It's bad when you don't have any standards. It's worse when other people on the project don't know what they're doing and don't have any standards. And in that case, it doesn't matter what language.

[coreolyn]

The point here is that Perl is no more and no less suited to enterprise-class work than any other language. The skills needed to build an enterprise-class application are not language specific. Please stop promulgating that mismeme.

I have to diagree with this point much as I don't want to, the plain fact is that TMTOWTDI creates far to much distraction from productivity for Managers to accept and feel comfortable with. Perl has everything it takes to be enterprise class, however, more coders code that path of least resistance rather than with the big picture in mind.

[dragonchild]

Perl has everything it takes to be enterprise class, however, more coders code that path of least resistance rather than with the big picture in mind.

At my last place of employment, a Java developer wrote some code to pull data from the database. That code, because the structure was copied everywhere, ended up in every single place data was pulled from the database. Because of this code, this company ended up spending $400,000 on a new server with no discernible improvement.

What was this code, you may ask? It was the path of least resistance. Something along the lines of:

1. Get a list of IDs from the database
2. Iterate through that list, creating an object for each ID
3. Each object, potentially, will populate objects it has, using the same method

So, what would have been a cinch to code up using a very minimal knowledge of SQL ended up costing at least a million dollars in unnecessary upgrades and lost productivity. All because a programmer didn't bother learning how to use the tools he was using.

I've seen this "bug" in at least three languages, two of which are considered enterprise-class (Java and C/C++). I've also seen it in Perl. The path of least resistance is a human bug, not a software one.

[jacques]

Perl is more accessible to the below-average programmer.

The popularity of PHP suggests otherwise.

[dragonchild]

Just cause PHP is more accessible has nothing to do with the fact that Perl is still extremely accessible. :-)

[kvale]

It seems that you don't like Perl 5 for OO programming in the large, but you like Ruby for some unspecified reason, and you seem to vaguely favor Java as well. You also decry the lack of proper OO training in the schools. And CPAN seems darn near useless as well. Having a bad week? :)

I can't discuss the problems you see with the Perl 5 object model, because I don't know what they are. So I'll address the useless nature of CPAN.

The main problem you seem to have with CPAN is that the modules that would have been useful to you in your most recent enterprise project were in their infancy or not available. That is unfortunate, but I think it proves the opposite point you intended to make. You wanted to use CPAN, to not reinvent. If Class::DBI or one of its derivatives was in its infancy, why not use and help develop it, rather than starting your own OORDBMS module? In that CPAN has hundreds of mature modules and thousands of promising starts, CPAN is valuable, and getting more so every week. Communities for other dynamic languages recognize that CPAN is one of the strengths of the Perl and seek to emulate it. Some of them may have problems with Perl's object model, but easy reusablilty of class modules is not one of them.

I agree that for large projects, CPAN modules tend to make up a smaller portion of the code. But I think this misses the point. CPAN modules are not meant to do everything you might need in an enterprise application. But if it is a common task, or involves some sort of agreed upon standard, there is probably a CPAN modules for it these days. CPAN modules make easy tasks easy, which makes time for coding the hard stuff possible.

[Anonymous Monk]

No, he's NOT saying CPAN is useless, per say, but that for large scale applications CPAN is a minor minor piece that doesn't play a big role, and what you normally get from CPAN can be found elsewhere.

"CPAN modules make easy tasks easy, which makes time for coding the hard stuff possible."

As does most of the Ruby language and it already has a huge set of libraries already available. The point is that folks use CPAN as a crutch, it is a very very nice feature, but at some point language cleanliness is not balanced by CPAN. That is, CPAN is not a member of the language cleanliness argument, and CPAN could exist in any language, nothing makes it a Perl-ism other than the way it happened.

The OO argument is very valid. Languages with a strong OO culture that get it right (Ruby, Smalltalk) are ones typically with very good language design. Java goes one way, Perl goes another.

A weak (or just sleep deprived or rushed) programmer is prevented from doing damage by what Java makes hard, but is enabled by what is made clean in Ruby. In Perl, he's likely to introduce some obscure errors. It's about language tools, not language shackles. Perl offers something akin to language TNT. Very powerful if properly directed, but can create maintaince nightmares.

Yes, I *have* unfortunately written code that I didn't grok three weeks later. It's true. Of course there is java code I've never groked at all. Just from experience, Ruby is ultra spiffy clean, and I can't wait for Perl 6.

[Ovid]

No, he's NOT saying CPAN is useless...

Thank you for writing that. I thought maybe I had explained myself properly, but since you get the point I was making, I don't have to remake it :)

[Ovid]

The anonymous monk made most of my points for me, but I wanted to clear up one thing: I do not favor Java. Java has some good points but it is certainly not my first choice of programming language. For a given problem that both are suited for, a skilled programmers will still get more done in Perl than in Java.

[dragonchild]

For a given problem that both are suited for, a skilled programmers will still get more done in Perl than in Java.

A skilled programmer ... huh. Either we're speaking about skilled programmers or we're not. If we are, then Perl is a perfectly good enterprise-level language. If we're not, then Java is the better language all around. Which is it?

[jacques]

maybe I won't be eyeing Ruby with such longing.

Perl is not a woman. But if you think you are cheating, then Ruby isn't a bad mistress. ;-)

[Anonymous Monk]

Ovid,

You really seem to be thinking a lot like I do, but a lot more eloquently. Seeing too much wrong-headed OOP, Ruby goodness, etc. Perl takes an immense amount of skill to wield carefully, and yes -- Java -- while I really hate it's shackles, is designed to keep folks without that constant consideration of every code change, somewhat on the right track.

I guess the thing is that Perl rapidly leads to very small, tight code that is sometimes not easily extensible (i.e. brittle and weakly connected), while Java quickly leads to code that is not easily extensible (i.e. too rigid and often glued together incestously).

Ruby is a good mix, and right now, I am coding my new apps in it, but I do have hopes for Perl 6, based on what I've seen in the community. However the Ruby mailing list has some folks that think very well about OOP and other things, they know what Java does wrong, and they use it to their advantage. It just depends how much Shock and Awe perl 6 brings and when it is first released.

Folks with perl maintaince problems should immediately check out Ruby, it solves a lot, and like Ovid said most of the things I get out of CPAN are things like database modules and such, which are already available in Ruby's core. Gems covers a few loose ends of things that should be in the core. Yes, i don't know where to find an Excel module or stuff, but server-side most of the time this isn't what you are looking for with the type of programming I usually end up doing.

Bottom line -- Perl's strength is in the modules and the flexibility of the language, but it does not always offer the flexibility to make things Rigid. Ruby offers the freedom to make something as Rigid or Flexible as needed, but does need maturing in the module category, but it has enough now.

[dragonchild]

Java -- while I really hate it's shackles, is designed to keep folks without that constant consideration of every code change, somewhat on the right track.

If you're not carefully considering every code change, then do you just blindly charge ahead, slingling code, and hoping you aren't on call when it breaks?

[Anonymous Monk]

"If you're not carefully considering every code change, then do you just blindly charge ahead, slingling code, and hoping you aren't on call when it breaks?"

Straw-man. There are degrees. A simple code change in Java may be impossible to architecturally designed rigidity, while a simple change in Perl may devistate an entire architecture. Such changes are not immediately apparent. What is important is to both have power, convience, and the ability to enforce light discipline and future maintainability all in one.

Perl is not a language that makes this automatic. You are much more likely to see Perl code devolve, as it takes incredible discipline to wield. Yes, I know people want to always have that discipline, I do too, but there are times when even we make mistakes.

[tall_man]

I took a look at Ruby recently, but it had such serious flaws in my view that I dropped it like a hot potato. The main issue I described in The power of strict typo-checking. What was your experience with typo issues in Ruby?

Besides that, the scoping rules for local variables are horrible. (If you happen to use the same name as an outer scope, you clobber that variable? And they call that lexical scoping? I know some sort of fix is on the way, but still...)

[Anonymous Monk]

Typo checking is actually better than Perl's IMHO, especially when checking module calls and such. For variables, i am very fond of attr_writer and attr_reader when I do need them, so there is no clobbering there. I never write foo.@bar = xyz as that's just bad style.

As for local scoping clopping outer scoping, I have not yet run across this problem, but I have never needed to use a variable twice with the same name in the same scope other than with local scope versus instance scope, and in which case, that all works fine.

I guess it depends on how you right your code, but the "Ruby Way" as it were does not run into problems like this, and it is not often a frequent complaint.

I get a lot more runtime type problems with Perl, especially due to the tendancy to abuse hashes and use less object encapsulation. The code is also more fragile.

[chromatic]

Thus if you write Ruby well, you don't have many problems. Me too. If I write Perl well, I don't have many problems, either.

[tall_man]

I never write foo.@bar = xyz as that's just bad style

Most Ruby objects I have seen fail to self-encapsulate their fields. For example, it would be unusual to see something like this:

class MyObj
    attr_accessor :name
    private :name=

    def initialize(myname)
       self.name = myname
    end

    # more stuff using name or self.name instead of @name
end

Usually there would be raw references to "@name" all over the place. In perl, references to $self->{"name"} are typically considered bad style. If code inside and outside the class uses different means for accessing the fields, there is more danger of typos.

But my main point was about the danger of declare-on-assignment, like this:

axxx = 1
if (rare_condition_I_forgot_to_test)
  axx = 2
end
print axxx,"\n"

If "axx" was meant to be "axxx" there is no error message and the program does not always work as intended.

[castaway]

I'm going to have to agree with several other people, that your title does not really fit your content. Some points that I grasp, after having read this several times are:
• CPAN isn't the be-all and end-all of Perl
• You prefer Ruby (for various reasons)
• OO isn't taught properly
• Large systems need lots of customised code
• Good programmers are needed to do a good job
Maybe I've missed a few, but: Isn't all this true no matter what language you use? Fine, Ruby has builtin libraries for lots of stuff that Perl has on CPAN, I don't see how that prevents it needing lots of customised code for a large system, I would have thought all of them do, otherwise we could just hangup our hats and point anyone needing software at the library/CPAN.

CPAN doesn't contain the solution to everything, it can't. Generally when a post gets answered with 'go look on CPAN', its because the gist of the problem lies with the OP attempting to reproduce poorly what some CPAN module already does neatly. Once that part of the code has been replaced, the actual business logic can be fixed.

Similarly, when it comes down to it, you always need a good programmer to get good work done, no matter what the language. Good in the language, that is.

Anyway, CPAN isnt responsible for any of all this, that I can see. True, it contains some wonky wheels, thats why the rating system was started, I believe, a community effort will always attract some not-so-good stuff.

Oops, gotta go to work, more later maybe...

C.

[etcshadow]

No time (now) to fully express it, but basically, I agree with every last thing you said (which is rare... are you looking for a job? :-D). One of those days where I wish I could trade ten votes for the ability to +2 a node.

[Ovid]

I'm not looking for a job unless you happen to be somewhere in Europe, appreciate test-driven development and have effective project management. My last European job only had one out of three :)

Side note: I've thought about aliasing :Wq to :wq due to how frequently I mistype that.

[runrig]

I've thought about aliasing :Wq to :wq due to how frequently I mistype that.

I'd nevermind that and just use :x. I was bitten by :X once, but after I learned what it was, it never happened again.

Update: Why have I never noticed "ZZ" before? Thanx, itub!

[steves]

Now here's my "ace in the hole" argument: Our Perl is not what you think. Sure, it's easy for me to sit here and say Perl's CPAN isn't the end all and be all when we use it so frequently. However, most (not all) things that we use from the CPAN are either readily available in other languages are are easily cobbled together. The heavy lifting -- those things that are the core value in our code -- has all been built in-house for our needs.

I believe this has already been mentioned but this has been true everywhere I've worked. There is no ready-made software for your enterprise. Anything you buy or download has to be tailored or wrapped in some way to fit the reality of your workplace.

Other than that I've found the opposite regarding CPAN. Our use of Perl grew from small to big mostly because the other in-house languages didn't have readily available, free solutions to problems that needed to be quickly solved. CPAN did. We're currently using over 300 CPAN modules. I have no illusions that those would be easy to "cobble together" or would come ready-made as part of another language, particularly for free.

That being said, different languages and systems have their place. There is no one answer. The way we're using Perl now (on a large scale) is a good fit for the problem set. I would not even suggest it for some of the other problems we solve.
I would guess you've been employed as a programmer for somewhere between 5 and 10 years. I only say that because I found myself and other very good programmers going through a phase during that time period where we knew enough to see all the flaws and desperately thought many things should be done and redone differently in "better" ways. Somewhere after year 10 all of us seemed to become practical. The fact is, most of what we write is relatively short-lived anyway. Systems come and go. Ways to program come and go. Methodologies come and go. There will always be something out there that looks like it solves the problem better.

It is a good learning experience to go through a few large scale rewrites to see just how little that promise delivers.

For something new, I agree that you should evaluate and pick the best tool for the job. But there's a practical side to that too: you need to sell it to management and you need to be able to hire people as things grow. I think Ruby would be a hard sell in that regard (at least for me).

[Dylan]

Say, what other language has something comparable to POE (http://poe.perl.org/), Class::DBI (and DBI, too), Template Toolkit or AxKit, or Mason.

Especially POE. I can write a mutli-room multiuser chat server in a hundred lines of code with POE. And yet nothing like it exists for, say, Java.

Not saying am I that you can't write something that offers all that POE offers in Ruby or Java, but that would not be very fun...

Generally, I find all the hard stuff is already done and done well, on the CPAN. Usually to deploy an app I just have to connect the right modules together. Could it be that your problem domain was just fringe?

[Anonymous Monk]

Random gripes: 1) this node is poorly titled, it's yet another "X vs Y" debate masquerading as a critique of CPAN masquerading as a critique and analysis of 'enterprise' software; and 2) it is not

"X is not a Y 'per say'"

... but rather

"X is not a Y per se"

... IT IS LATIN, PEOPLE, GET IT RIGHT.

[Ovid]

First, the node is perfectly titled. In large scale applications the CPAN's utility is limited as the greatest value comes from finely-tuned code that is heavily customized for the needs of the company using the application. I should know. I work in large scale environments.

Second, my node was not a critique of the CPAN. Read it again. It was a critique of those who claim that the CPAN makes up for any limitations (real or perceived) in Perl.

Third, I didn't write per say. Please direct your criticism correctly.

Fourth, if you're going to be pedantic, may I point out that in your charming "IT IS LATIN, PEOPLE, GET IT RIGHT" sentence, there should be a period or other appropriate punctuation after "PEOPLE." The comma is not correct. This is English. Get it right.

[Anonymous Monk]

To dispense with the first three points: the word "PEOPLE" clearly indicates that the 'gripes' are offered in response to participants in this thread, and the overall character thereof, and not to Ovid individually. If the shoe doesn't fit you, then don't try to wear it. No one asked you to put it on.

To dispense with the fourth point: let's just hope the words that may have charmed your socks off, didn't also charm your eyeglasses off. Those charming words are not a sentence, they are a subordinate subclause within a sentence. You may consult item five, subgroup six to see why the comma use is not inconsistent with the time-honored rules of English usage.

Perhaps you could assert that it is a run-on sentence, but such a trifling and dubious complaint would be a mere straw of maladroit verbal discontent, to add to the other such straws in this "pile" of a thread. Fortunately, the pile is meager and withering, and not the least bit likely to break the camel's back.