I started as a Perl dev, and I must say that some of the principles I learned there that I still feel are underutilized in other languages even though the syntax could support them.
I think the very nature of Perl meant that I had to learn additional tricks to make the code make more sense when I returned 6 months later...tricks that I wish other languages embraced. Having your code not be obscure is the minimum, not the maximum you should be shooting for.
Also - I'd still write short scripts (basically glorified one-liners) in Perl vs Python. JS is getting up there, but still isn't as expressive as Perl.
Edit: And I say this with full respect for other languages, particularly Python that has done a lot for many areas of development
Perl often gets flak for "There's more than one way to do it", and sometimes that's justified: It's confusing to do things a billion different ways. BUT, sometimes you can use those different ways to be meaningful. So:
foo() unless (condition) vs if(!condition){ foo() }
They are FUNCTIONALLY the same, but COMMUNICATE differently. If you don't pay attention to the latter, then TIMTOWTDI will be an enemy. If you do, then it can really help.
Also: "not", "and", "or" - I wish more languages had these. && and || might seem to be the same thing, but there's no reason to cling to foreign symbols where native (for english speakers) symbols do the same. ! is particularly bad, since it's so small, can easily blend in to an adjacent paren, and yet REVERSES the meaning. Don't get me started on the terrible switch/case syntax that is perpetuated for no reason other than C did it.
Moving away from syntax, hashes/dictionaries/associative arrays/Js objects, these guys all have the same basic addressing style. If you're using them in a context where the key will almost always be present, why not use that?
instead of addresses[currentAddress]
use address_of[current] (or addressOf[current]
Instead of building variable names that are 4-5 camelCase words, use the hierarchy of your structures to communicate more clearly.
variables are WORDS. Too few words doesn't communicate clearly, but too many is just as obtuse.
There are a great many "clean" bits of code out there - nicely structured, nothing wrong, but I'll still have to read the whole to understand a part of it. Similar to the semicolon argument: The reason I object to dropping semicolons is not that the statement needs it - but that I need to read the next statement to retroactively know if the statement needs it.
If you can write code so that a reader understands what is happening as they read, rather than understanding the whole and then viewing the parts in that context, your code becomes that much more maintainable.
I think the very nature of Perl meant that I had to learn additional tricks to make the code make more sense when I returned 6 months later...tricks that I wish other languages embraced. Having your code not be obscure is the minimum, not the maximum you should be shooting for.
Also - I'd still write short scripts (basically glorified one-liners) in Perl vs Python. JS is getting up there, but still isn't as expressive as Perl.
Edit: And I say this with full respect for other languages, particularly Python that has done a lot for many areas of development