I'm a Perl dev for less than 5 years. Since last week I changed the company I work for. The new company has a project which is 12+ years old.
This project has a code base written in Perl which seemingly violates all programming best practices: files of 50k LoC,functions of several thousands of lines, there are frequently 5-6+ levels of nested ifs. It contains all the technical debt it acquired during these 12+ years.
However, it took me less than an hour from the moment I got access to a working vm to make the first fix - display the correct currency on invoices which were not paid in usd. And this, in the context that it was the first time I logged into the app and I also had to find such a buggy invoice.
Now, tell me again how unreadable and hard to understand Perl is?
I'm increasingly forgiving of that kind of "primitive" code with giant, heavily nested functions, because the worst that can go _wrong_ with it from a maintenance standpoint is heavy duplication and overreliance on mutable state. Those are knowable quantities, and you can attack them systematically. Otherwise, everything is laid out for you in straight-line order. You can just read it and see "this happens before that" without having to run the program or a debugger, and nobody even has to burden themselves with giving "this" and "that" an explicit name(although a comment can be a real boost to finding what you want).
Codebases that are cleverly factored to within an inch of their life are much, much worse. There's no guarantee that the original factoring successfully decoupled anything, and all the additional content allows for new bugs to slip in "between the cracks" - parameters left accidentally unset, a hierarchy of functions getting called in the wrong order, etc. The original programmer has to spend more time coming up with ways to name and enumerate these details, allowing their eyes and thoughts to be taken off of the domain problem. Because more powerful programming tools are used, more powerful debugging techniques become necessary. And when the architecture breaks, the call stacks just get deeper as the heavy metaprogramming guns are brought out to make increasingly clever workarounds to the resulting issues - after all, nobody really wants to try to disentangle the code after it hits the point of architectural meltdown.
Of the two, copy-paste coding is definitely the lesser evil. So I allow some of that first and then clean up the low-hanging fruit.
You can do that in any language. I've done that kind of thing in an hour in languages I've never even used before (uncompiled ones, obviously).
Perversely your first fixes are often easier than your later ones as you're not trying to make things better, you want to show off his good you are to your new boss/client.
The problems with bad code come when you have to make bigger changes and you're constrained by the existing design like a straight jacket.
Adding a £ or a $ or a € is really easy for any experienced programmer.
Beware false laziness. Slamming out a 500 character command line to build something is ok for a little while, but if it ever falls out of history, you're doomed. Write the Makefile and expend less energy overall.
Why not just copy/paste that into a .sh, put #!/bin/bash at the top, check it into source control, and call it good enough for now? I guess they call that a "Dockerfile" these days :)
The true lazy person starts with a cookie-cutter template whenever they start a new project. It helps when the path of least resistance is also the best practice.
I've found the phrase "long-term lazy" is the quickest way to describe the first virtue: someone who's willing to work hard today so they can be lazy (or have more time for other things) later on.
I don't see how 'lazy' is a good word to use though. I would imagine someone who is lazy would be much less likely to write documentation than someone who isn't. Prudent is a much more fitting, if less eye-catching word.
The "long-term" qualifier is important here. The best programmers I know are willing to go to great lengths to be lazy sometime in the future. Why write and maintain comments and documentation? Because you know when it breaks in the future it will be easier to fix, thus allowing you to fix the problem and go back to whatever "lazy" thing you were doing.
Let's be honest, the term lazy is loaded. I use the phrase "long-term lazy" because it elicits conversation. "You're looking for a trait that's considered negative? Why?" It's much easier to pull someone in by saying good programmers are lazy (in the long term) than good programmers are prudent.
This is of course what Larry meant, not the literal meaning.
The whole Perl 6 thing is the ultimate in this form of lazy; 15 years of design work on both the culture and the technology just so he can die in peace in his old age rather than worry about having to be reborn to continue tinkering with Perl 5.
...
Unsupported use of ->(), ->{} or ->[] as postfix dereferencer; in Perl 6 please use .(), .[] or .{} to deref ...
Following the advice leads to:
my $larry;
$larry.{Please}.{Add}.{Feature}++;
which leads to another compile-time error:
...
Undeclared names:
Add used at line 1
Feature used at line 1
Please used at line 1
...
Those "undeclared names" were probably meant to be string hash keys. So try that:
my $larry;
$larry.{'Please'}.{'Add'}.{'Feature'}++;
Bingo.
By the way, that's an unusual way to write such code. The periods are optional, so this is equivalent:
$larry{'Please'}{'Add'}{'Feature'}++;
And the braces, which support any expression, such as strings as used in this example, are typically not used. Instead, typical code uses angle brackets, which assume the words within are strings:
$larry<Please><Add><Feature>++;
Finally, in Perl 6 it's often useful to use an array sigil (@) or hash sigil (%) instead of the general purpose scalar sigil ($):
my %larry;
%larry<Please><Add><Feature>++;
I don't know if I've incanted a commit in Perl 6 by writing this, but ya never know... :)
----
An old sig of mine (slightly reworded) from the 90s:
If I could live my life again I think I'd believe in reincarnation.
Call it lazy; I call it productivity. When the tool introduces more work than the fix, something is wrong. I can do 5 or 10 fixes before lunch. Except I have to go through a ritual of source management that slows me to a standstill, not to mention derailing my train of thought utterly.
I'm curious: are you specifically talking about the GitHub-style fetish for "a fork and feature branch for everything, followed by a merge"? I've been on a tear lately against GitHub after having another go at using it (it's where the collaborators are) and finding that it's still as terrible as it's ever been.
Have you used Git extensively outside of GitHub or done much with Mercurial? Patch-based/commit-only workflows are the right solution to, I dunno, probably 75% of fixes and don't get in the way like the aforementioned approach, which tends to be misapplied (read: used 100% of the time because GitHub demands it).
Commit-only workflows are very light on ritual, since it's got about the same overhead as leaving a two-line comment. Mercurial makes it even lighter, because you don't have to futz around with the index like you do in Git (so long as you're only changing an existing file and haven't introduced a new one).
I do use it, but that still qualifies as having to "futz[...] around with the index":
> -a, --all
> Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
But this wasn't supposed to be a Git vs Mercurial post. It was supposed to be a GitHub vs sanity one, where Git-based solutions exist in the latter, too, which is why I mentioned use of Git outside of GitHub.
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)
Impatience:
The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)
Hubris:
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607) "
Just today I was actually thinking laziness was one of my greatest assets as a developer. Always trying to find a way to make my work do as much of itself as it can, haha.
To be honest, it's not actually 'laziness' as much 'desire for automation'. I've worked with a few actually lazy developers in my time, and it's not fun. For example, it's hard to be a software tester when the design documentation, in it's entirety, is on an A4 sheet in the lead developer's desk, and he's too lazy to make a copy for you. That was medical software, no less...
I think "desire for automation" is in the right direction, but doesn't quite hit the mark. For me, it's more like "not wanting to solve the same problem twice". I don't really care if it's automated or not, but once I've solved a problem I don't want to think about it again (unless there's some new twist).
At my last job I was always getting bugged by support people asking me the same questions over and over. So I wrote documentation/guides telling how to solve the common issues.
TL;DR: it's not so much "robots are awesome" as "ain't nobody got time for that!".
I would categorize it as efficiency. Laziness is when you have the means to do something, but you're just not willing to do it. Efficiency is when you take 2 hours today to save 10 minutes every day for the next 5 years.
I find it disheartening how much people trash talk Perl, while other languages that are extremely similar (JavaScript, Python, Ruby all share much more with Perl than they do with, say, Haskell or Go or ML), get a pass. It's become trendy to do so, to the point where people who clearly have never learned Perl or worked with it feel entitled to speak with authority on it. Taking it to the point of dismissing anything Perl's creator has ever said (as one of the commenters on this wiki page does) is absurd and means not listening to an extremely bright technologist (I mean, c'mon, Larry invented patch, the basis of a tremendous amount of awesome in modern software development!).
There are misfeatures in Perl, certainly, but there are roughly as many misfeatures in JavaScript. It's silly to dismiss it as "awful" when there's so much that is clearly nice about the language for many categories of problem.
I loved Perl when I first learned it. I loved it for the same reason I love Python now. It's very easy to express ideas I have in mind without worrying about the details. It's a great prototyping (as in prototyping ideas, not as in the type system) language. It was my introduction to "higher level" languages. That said, Perl suffers from having too many magical operators that makes it hard to reason about a snippet of code. I feel Python strikes the right balance.
Your comparison to Javascript is apt but I think a lot of us also find Javascript to be a bit of a horror. Recently I learned that Javascript doesn't handle modulus on a negative number correctly among other things.
Perl suffers from having too many magical operators that makes it hard to reason about a snippet of code.
Certainly a matter of personal preference, but a sprinkling of operators isn't so bad once you're acquainted with the language. Yes it's possible to weave a mess in perl, but most of the time you're just dealing with code that might have a few sigils preceeding an identifier, not ASCII soup.
I'd say the real issue is weak typing (implicit conversions between primitives, using strings for many things where some more specialized data type would have been more appropriate) and variable scope problems. These can lead to hard to locate bugs. Worse is the culture in the perl community of manipulating the VM's internals and generating code at runtime and all kinds of other extremely dynamic behaviors. It's amazing what perl lets you accomplish there, but when some package you got off CPAN does something weird and then something goes wrong, it can get really weird.
Recently I learned that Javascript doesn't handle modulus on a negative number correctly among other things.
That's not really true. Javascript doesn't have a modulus operator, it has a remainder operator, and it is completely valid as a remainder operator. The "%" operator is usually called the modulus operator, but it originated in C where prior to C99 its behavior on signed integers was undefined, and on signed integers modulo and remainder are equivalent. So javascript didn't want undefined behavior so they picked one definition and ran with it, it just so happens that C99 chose the other definition and it stuck.
I'm interested in the details of the variable scoping problems are. I'd have thought that perl's explicit declaration of lexicals with 'my' was better than "declare at first use" of javascript/python/ruby.
[There's a class of mistake where you typo a variable name which you can make in those languages which gets caught in a language where you have to declare variables.]
I share your confusion over that assertion. I actually miss Perl's excellent block scope capabilities when working in almost every other similar language. I imagine most other languages have gotten it, by now, but a few years ago when I was using Python for a few years for a client it didn't have block scope and I missed it. A brief googling actually hints that maybe Python still doesn't have block scope, which is pretty weird, so I assume I'm googling wrong.
But, perhaps discussion of scope problems in Perl is just when talking about very old code. Perl had some scope atrocities back in Perl 4 and some weirdness in early Perl 5 days. But, for the past 15 years or so, it's been very predictable and has improved (like the syntactic sugar of "my" declarations in foreach or while expressions).
I seem to recall that Python not only didn't (doesn't?) have block scope, it tended (tends?) to produce a completely, blithely cryptic error message when the programmer assumes that it does have proper block scope and writes a program that fails as a result. Discovering that was memorable.
One weirdness I encountered recently with nested functions:
sub a {
my $v;
sub b {
# captures only the first
# instance of $v
}
}
This is because named subroutines are created once and variable captures are resolved at that time. I expected the more normal capture semantics you get with anonymous subs, like
sub a {
my $v;
my $b = sub {
# a new $b each time
# captures each $v
}
}
The lexical scoping rules are precisely what causes this behaviour. The first example defines a nested function which has access to the variables in scope when defined (as you remark).
It's little different than this block defined outside of any function:
{
my $v;
sub b { ... }
}
Whereas an anonymous function is "defined" each time the enclosing scope is evaluated.
Thanks - useful point. But, I think that's more of an oddity of nested, named subs than anything else. The usual anonymous subs close as you'd expect (as you say).
> most of the time you're just dealing with code that might have a few sigils preceeding an identifier
I personally like sigils but, afaict, one can almost eliminate sigils in Perl 6 if one wants to.
Instead of $ sigil on scalar (single item) variables:
a scalar =$= 42; # uses a fictional feature [1]
say scalar;
# 42
scalar--; # decrement scalar
scalar.say;
# 41
Instead of % sigil on dicts (hashes):
a dict =%= pi, i, e, now;
say dict;
# 2.71828182845905 => Instant:1435371876.325275,
# 3.14159265358979 => 0+1i
dict<pi>--;
say dict.invert;
# Instant:1435371876.325275 => 2.71828182845905
# -1+1i => 3.14159265358979
Instead of @ on lists (arrays):
a list =@= 10,20;
say list >>+>> scalar;
# 51 61
> I'd say the real issue is weak typing
In Perl 6 everything is (implicitly) nominally typed. One can optionally add explicit nominal type info.
It's certainly not HoTT and it has weaknesses that look unlikely to be addressed this year[2] but it's also one of the most advanced gradual typing implementations in any language.[3]
> implicit conversions between primitives
In Perl 6 conversions are generally explicit. If you name a couple implicit conversions in Perl 5 we could compare with Perl 6 (and, say, Python).
> using strings for many things where some more specialized data type would have been more appropriate
Can you provide an example?
> variable scope problems.
Scope features are very much a Perl 6 strength.
Again, perhaps describe a scenario where it's a weakness in Perl 5 and we can compare with Perl 6 and perhaps other langs?
> manipulating the VM's internals
The "reference" Rakudo Perl 6 compiler is a front-end to the NQP compiler toolchain. The NQP toolchain targets several VMs including the JVM. It does not manipulate the JVM's internals!
(NQP also targets MoarVM[4] but it uses the same principled ways to communicate with MoarVM that it does with the JVM.)
> and generating code at runtime and all kinds of other extremely dynamic behaviors.
Ah yes. Perl 6 has upped the ante on that. It is statically compiled in a lot of ways but it also has very powerful dynamic features, carefully designed. [5]
----
[1] I made up the term 'a'. In reality it's 'constant'. But that name is kinda surprising for the purposes to which I've put it -- the terms it declares aren't very constant! But 'constant' is much longer than 'a' and this sort of declaration is supposed to be harder than using other scopes such as 'my' or 'has'. See http://irclog.perlgeek.de/perl6/2015-06-27#i_10812609 and following for a tiny bit more discussion.
> [lang X] doesn't handle [basic math] correctly among other things.
From a recent talk[1], what are x, y, z in the following?
x = 7 ÷ 2;
y = -7 ÷ 2;
z = .1 + .2 - .3
x y z
3.5 -3.5 0 # human
3 ? tiny number # c89; ? depends on compiler
3 -4 tiny number # ruby
3 -4 tiny number # python 2/3
3 -3 0 # bc
3.5 -3.5 tiny number # perl5
3.5 -3.5 0 # perl6
(For Ruby, I've found "the core language does not provide a way to count [human perceived characters]". [3] Is that still correct or out of date?)
----
> Perl suffers from having too many magical operators that makes it hard to reason about a snippet of code. I feel Python strikes the right balance.
To quote Larry Wall, "Perl 6 ... has been rethought and rebalanced on every level".[4]
It might be interesting for you to pick a couple Perl 5 operators that you consider too magical; then we could look at the merits and demerits of those ops in Perl 5 and their equivalents in Python and Perl 6.
> It's very easy to express ideas I have in mind without worrying about the details [of Python, now, and Perl, back in the day]
This, of course, has explicitly been a deliberate focus of all the Perls. Part of the point of Perl 6 was to remove the bits in Perl 5 that were problematic (including some "too cute/weird" stuff) and to introduce much nicer higher level abstractions (eg grammars instead of just regexes[5]).
----
I've long encountered vocal folk who underestimate or misunderstand Larry Wall and Perl to an absurd degree. Perl has been focused for over two decades on making it easy to get the right results when doing basic practical things (like integer division and counting characters) and, imo, that ought to be obvious to anyone who looks at the matter carefully.
> I think my experience with Perl [is] a bit dated
In some ways, contemporary Perl 5 (eg this year's 5.22 release) is quite unlike older Perl 5s. For example Moose -- which first arrived in 2005 -- is a powerful and relatively clean OO and "roles" system which has matured in to a huge ecosystem of its own within CPAN. (It was/is a kind of back port of the Perl 6 OO model which itself built upon the notions found in systems such as CLOS.[1])
But my personal focus is Perl 6.
> I also forgot to give Perl credit for another thing: introduction to regex.
Perl 6 unifies "regexes", PEGs, and lexical closures. [2].
> Perl was a great language for me to learn and I should revisit my sentiments about it.
Anyone who joins the freenode IRC channel #perl6 and says hi will be welcomed.[3] If you visit, feel free to paste a link to my comment. :)
In the 90’s I learned and used C as a general programming language. For lighter tasks, I used shell scripts, sed, and awk, and I came to know them well, and I still use them regularly. I knew then that I needed a better programming language for general programming, and from a distance, I could see that Perl was like shell, sed, and awk all mashed together. I did not want it – it seemed like the entirely wrong direction to go. (Minor or domain-specific languages like PHP was out.) I had heard of Python, but did not try it until I was asked to write a small utility which was just complex enough that a shell script would not suffice; I took the opportunity to learn and use Python (then version 1.5) for it.
I have used Python at every opportunity since, and am happy to use Python 3 everywhere possible.
I never used Perl, but I use Ruby where people might have used Perl before. (Small one-off scripts or simple automation stuff)
People often attack the appearance and readability of Perl code ("write-only" code), but lot's of Ruby code I come across has the exact same problem, except that people seem to love adding 4 or 5 extra layers of abstraction on top of that.
One can write totally incomprehensible code in any language if clean, readable code is not a priority.
And the opposite is true, too, of course. I have seen some fairly messy Python code and some marvelously clean Perl code. And I am fairly certain that over time, some people have written beautiful PHP code and ugly Lisp code.
In my humble experience, it is not so much a property of the programming language as it is of the programmer(s).
> Perl's critical failure is that most CPAN modules expect
> admin rights and a gcc build environment in order to
> install correctly.
> That killed it on shared hosting and for small projects
> that may not have a server admin's support.
I install Perl apps on shared hosts all the time. The great majority I work on are cPanel-powered. They have a CPAN module installer right from within the cPanel.
Compiler support is an option, and is usually enabled by default. If it's not, it's easy enough to enable that in WHM (the cPanel for cPanel accounts basically)
cPanel is available on hosts like Bluehost, Hostmonster, (dog help us) GoDaddy. Most hosts that built their own control panel for hosting accounts have thus moved to cPanel. cPanel, no surprise, is a Perl shop themselves.
So, the 800lb gorilla of shared hosting control panels presently does what you say you can't.
I also ship Perl apps that specifically do not require outside CPAN Perl modules that require compilation, but have support for features, if they're present. Throw up the .gzip distro, throw up, "install.cgi", chmod 755, and visit the thing in your browser. It wasn't impossible ;)
For how to install CPAN modules in alternate locations. Be sure to note the setting of PERL5LIB to the location you choose when running Perl in order to resolve the modules in the custom location.
> Also devs are used to having named arguments for their functions. Not supporting that is just silly.
There are some idioms available to address this. If you are interested, reply and we'll discuss them :-).
> And finally it's difficult to google things like $/, $", $% and $_ when you're confused.
If you have access to a Unix machine with perl installed, then running:
man perlvar
Will produce a man page enumerating the predefined variables which are difficult to use a search engine to find.
It'll be interesting to c how the radically overhauled module management in Perl 6 pans out.
(They're making sure that installation is practical. For example, NativeCall, for calling C libs, does not require a C compiler.)
> Also devs are used to having named arguments for their functions. Not supporting that is just silly.
The latest Perl 5s have this ("signatures").
Signatures are a central element of Perl 6. (They are way more powerful than in Perl 5, even the latest.)
> it's difficult to google things like $/, $", $% and $_ when you're confused.
Yes.
Fwiw Perl 6 only keeps three of these oddly named variables (removing dozens of others) and they are simple in practice:
name concept formally means the current/latest
$_ it topic (Nil or any value/object)
$! oh noes! error (Nil or unthrown exception)
$/ /regex/ match (Nil or parse tree)
I suppose those who only write in relatively similar languages like JS, Python, and Ruby start seeing all the tiny differences and miss the entire subset of Lisp languages that offer so much more.
I'm not sure if laziness is a virtue of a programmer. Often, writing the program takes a lot more work than the actual use (by that particular programmer) of it would warrant.
Take for example the developers of a word processor. Would all that effort spent on that office-automation software really cancel against the probably few letters and/or documents that a developer would write using it?
This seems to be a non-sequitur. Who are you talking about?
Larry isn't libertarian to the best of my knowldge, and certainly not an asshole. He's one of the nicest, most genuinely kind and generous, people I've ever met.
So, a non sequitur, then? Since this article is about something Larry Wall said in Programming Perl (among other places). Perhaps there is some confusion based on their somewhat similar facial hair choices? I can assure you they are separate people with independent thoughts.
Ha! You're completely right! I was reading some other ESR today and just mentally inserted him as a coauthor with Tom Christiansen, Larry Wall and Randall Schwartz.
I can't identify a libertarian among the authors in this article.
This project has a code base written in Perl which seemingly violates all programming best practices: files of 50k LoC,functions of several thousands of lines, there are frequently 5-6+ levels of nested ifs. It contains all the technical debt it acquired during these 12+ years.
However, it took me less than an hour from the moment I got access to a working vm to make the first fix - display the correct currency on invoices which were not paid in usd. And this, in the context that it was the first time I logged into the app and I also had to find such a buggy invoice.
Now, tell me again how unreadable and hard to understand Perl is?