
The strict Pragma is a Cultural Marker - Mithaldu
http://www.modernperlbooks.com/mt/2013/11/the-strict-pragma-is-a-cultural-marker.html
======
darbelo
Worth reading even if you aren't a perl guy. Every language has this type of
'cultural markers' that set your expectations for a codebase by skimming a few
files or just the project structure. On that first dive into someone else's
code[1], this markers are invaluable, they are the first cue into the author's
mindset and background. They are a signal for future maintainers or
collaborators. It's like stepping off the plane and hearing people around you
speak with your own regional accent. Even if you've never been here before,
now you know some of your knowledge still applies.

[1] Rule of thumb, if you haven't touched your own code for a long time, think
of it as being written by someone else. You are not the same person you were
when you wrote it.

~~~
Zancarius
> Rule of thumb, if you haven't touched your own code for a long time, think
> of it as being written by someone else. _You are not the same person you
> were when you wrote it._

This is really insightful, most especially the part I italicized.

I can think of a few particularly embarrassing moments when I've dug through
old code of mine and immediately thought "What kind of idiot wrote this crap?"
followed by a brief moment of horror when the realization sets in that the
idiot was me. :)

I think it would also make a fantastic addendum to this [1] discussion (and
the article to which it is attached), especially since many new programmers
often don't think much of code maintenance. Usually it's comprised of "I (or
someone else) will eventually rewrite this." Then it enters production.

[1]
[https://news.ycombinator.com/item?id=6789504](https://news.ycombinator.com/item?id=6789504)

~~~
Groxx
I've come to (try to) document / code like I assume the next person reading it
will be both insane and stupid.

Usually that's me. Usually it was worth the extra effort :) And at the very
least it's a measure of progress, as I'm no longer _that_ insane and stupid.

~~~
Zancarius
Oh gosh, yes. I've found that approach to be the most helpful. In a year (or
three?), I know that I won't remember _anything_ about what it was supposed to
do. I'm pretty sure I'm stupid or forgetful. Probably both.

I like your assertion of documentation being a measure of progress. As dumb as
it sounds, even if you're the only consumer of an API you wrote internally for
some on-off application, documenting it thoroughly is a tremendous time saver.
Granted, I still slip up occasionally, especially if it's a quick script of
sorts, but I find more often than not that when I do regret not having taken
the time to document something, it's (now) usually something deceptively
simple that I _wish_ I had better curated, because it eventually finds new
life as part of a greater work.

~~~
Groxx
Yeah, especially with one-off scripts I keep upgrading my machine /
reinstalling to clean things up, and wondering wtf -nRT means and why I
thought it was important. Something like half the time I google / manpage
around for a while and find out it _wasn 't_ important, or assumed something
incorrect about what it was trying to do.

I've started wrapping everything I do frequently in small bash scripts, and
documenting what _and why_. Saves a lot of time when migrating to a new
system, since I can glance and say "nope, don't need it" within a couple
seconds, or remember why it was useful (and sitting in a cronjob somewhere)
and reinstall the things I actually use.

~~~
epochwolf
When writing scripts don't use the shortened flags, use the long version.

For example, the deploy script from a simple php app I wrote:

    
    
        rsync --recursive --links --verbose --rsh=ssh --exclude-from ./exclude_from_deploy.txt --delete ./ kazan:/srv/simple-paste/

------
bane
I find that when I use 'struct' in my Perl, I have a psychological mind shift
in how I write the code. Instead of hacking together some code, I start to
take it more seriously, and start to care about everything from what I choose
as my variable names to the overall sructure of the code. I start to care
about maintainability. To be honest, I end up eliminating lots of clover Perl
idioms and make the code much more 'C' and Java like, explicitly declaring
most of my variables at the top of functions and making them verbose and
consistent. I start to document everything and write lots of comments
explaining what I'm doing. It really doesn't add much overhead to the overall
development to be honest.

I think as if I have to give the code to somebody else, even if that other
person is me in the far future.

It's served me well, I've returned to old pieces of code I wrote years before
(even multiple 10s of KLOCS) and after a couple read through was able to get
to work without much fuss.

Fitting in with Larry's idea of programming languages as real languages, it's
as if I've code-switched from a colloquial language to the kind of formal
language I might use when giving a presentation.

~~~
Mithaldu
> explicitly declaring most of my variables at the top of functions

While i largely agree with the rest of your code, that one bit i can't
generally agree with.

If you take care to keep all your functions below 15 or so lines, i.e. such
that they fit on one screen, then that's fine.

As soon as you write bigger functions you end up impacting your code quality
in two ways:

\- readability and refactorability go down, because coders after you have to
read more code to see the context of a variable

\- the chance of bugs goes up because you're more tempted to reuse a
predeclared variable in a loop, instead of redeclaring it at every start of a
loop; or more insidiously, reuse the same variable as the counter in multiple
loops

So please: Declare your variables as late as humanly possible, optimally only
directly before they're used.

~~~
bane
I don't disagree with your points at all. Short life variables I do tend to
declare later in the code.

But most of the major state variables (especially the ones that get returned,
or important data structures I want to keep track of in the code flow) I stick
at the top with comments and explanations of what the variable is and why it
exists.

~~~
Mithaldu
That's better to hear. I'd still invite you to try and make a conscious
efforts to make your functions smaller and more numerous. That might help you
reduce the number of variables you need to make an effort to actually keep
track of. :)

------
marquis
Perl was my first language that I really engaged with, it started my career.
Why did it fall out of favour? (I left web development to write
applications/C, then returned some years later to write APIs but everyone had
stopped using it).

~~~
smacktoward
It was Perl 6.

As soon as it became clear that the move from 5 to 6 was going to be
discontinuous, if you wanted to be a Perl developer you had to decide if that
meant being a Perl 5 developer or a Perl 6 developer. Being a Perl 6 developer
was the clearly marked path to The Future, but Perl 6 was years away from
being ready to use in production environments, and it never seemed to get any
closer. Perl 5 was practical for real-world use, but choosing to be a Perl 5
developer meant worrying that you were investing time and energy learning
skills that were already marked as obsolete and writing code that would end up
having to be re-written.

That kind of uncertainty is fatal to a language. Why put up with it when
there's so many other languages out there with clear upgrade paths? Especially
when the upgrade path for the one you're using now appears pretty similar to
learning a new language anyway?

So developers drifted away from Perl to other languages, and that, as they
say, was that.

~~~
slashdotaccount
Ah, that old chestnut again. The argument falls down when we see what really
happened: Perl 6 had and continues to have a huge positive influence on Perl
5, the future belongs to both as there turned out to be no discontinuous move,
and Perl 5 stays up-to-date.

~~~
Peaker
Even if it is only the way things are perceived, and not the actual truth - it
can still explain the decay of the community.

~~~
draegtun
What decay? The Perl community still continues to grow -
[https://news.ycombinator.com/item?id=6738619](https://news.ycombinator.com/item?id=6738619)

------
kanatohodets
Interesting to think about the sorts of cultural markers that other languages
have. Maybe this is just another way of saying 'code smell', but there must be
similar elements for JS/Ruby/Python (for example) where it the code isn't
strictly 'wrong' (or even debatably wrong), but is still clearly indicative of
a particular cultural approach towards coding in that language.

Like overriding Array.prototype.push in JS - it might be just fine, but I tend
to pause and re-evaluate my attitude towards the code when I see that going
on, because it's a very different approach to coding in JS than I personally
use.

~~~
mattmanser
I tend to see much clearer indicators in JavaScript code. Global variables?
Lots of functions outside any closure? Old skool js coder ahead.

You can also tell javascript only programmers a mile off. Anonymous functions
everywhere? Functions have multiple concerns? Use 'var aFunction =
function()'? Mono linguist and spaghetti code ahead.

~~~
baudehlo
A lot more JS coders could benefit from adding "use strict" to their code too.
It's frankly amazing it isn't used more.

~~~
Mithaldu
Honestly, in practive it falls short and doesn't do nearly enough. :(

~~~
baudehlo
True. It does far too little at compile time. I don't understand why. Maybe we
need a "use compile strict" ;)

------
leokun
I just don't understand why anyone developing a language would think dynamic
scope would be a good idea.

~~~
geocar
Richard Stallman gave an excellent use and rationale for dynamic scope in the
EMACS manual:

[http://www.gnu.org/software/emacs/emacs-
paper.html#SEC17](http://www.gnu.org/software/emacs/emacs-paper.html#SEC17)

One of my favourite things about perl and CL is the ability to have lexical
(my/let) and dynamic (local/special) scope in the same program _depending on
what is clearer_.

In fact, it comes up often enough that programming in a language lacking
dynamic scope (e.g. basic, JavaScript, or python) feels limiting sometimes,
and I end up emulating it (settings+extend, observables, etc).

~~~
jlgreco
That rationale may be a bit revisionist, here is Olin Shivers' take on RMS's
justification for elisp's dynamic scoping:

"Some context: Common Lisp did not exist (the effort was just getting
underway). MIT Scheme did not exist. Scheme was a couple of AI Lab tech
reports and a master's thesis. We're talking the tiniest seed crystal
imaginable, here. There was immense experience in the lisp community on
optimising compiled implementations of dynamically-scoped languages -- this,
to such an extent, that it was a widely held opinion at the time that "lexical
scope is interesting, _theoretically_ , but it's inefficient to implement;
dynamic scope is the fast choice." I'm not kidding. To name two examples, I
heard this, on different occasions, from Richard Stallman (designer &
implementor of emacs lisp) and Richard Fateman (prof. at Berkeley, and the
principal force behind franz lisp, undoubtedly the most important lisp
implementation built in the early Vax era -- important because it was
delivered and it worked). I asked RMS when he was implementing emacs lisp why
it was dynamically scoped and his exact reply was that lexical scope was too
inefficient. So my point here is that even to people who were experts in the
area of lisp implementation, in 1982 (and for years afterward, actually),
Scheme was a radical, not-at-all-accepted notion. And _outside_ the Lisp/AI
community... well, languages with GC were definitely not acceptable. (Contrast
with the perl & Java era in which we live. It is no exaggeration, thanks to
perl, to say in 2001 that _billions_ of dollars of services have been rolled
out to the world on top of GC'd languages.)"

[http://www.paulgraham.com/thist.html](http://www.paulgraham.com/thist.html)

(emphasis _not_ my own)

That whole page is a good read, particularly if you are a fan of Shivers'
writing style.

~~~
keithwinstein
Cool, I hadn't read Olin's take.

However, the cited rationale can't really be revisionist of what RMS told
Olin, because it was published in 1981, about 14 months before Olin came to
MIT in 1982.

It appears verbatim in RMS's paper, "EMACS: The Extensible, Customizable,
Self-Documenting Display Editor," A.I. Memo 519a,
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-519A.pdf (March 26,
1981). He doesn't mention an efficiency justification in there.

The whole document is also fascinating for including RMS's nascent but not-
fully-baked early thinking about free software.

~~~
jlgreco
Hmm, good catch, I didn't notice when that was published.

------
jfb
As the child of anthropologists, I think there's a lot of room for cultural
analysis of technologies. Languages, for instance, have cultures as well as
affordances, and a careful comparative analysis would be really interesting.

