Such brutal honesty would be welcome in other papers.
> Such brutal honesty would be welcome in other papers.
To say nothing of the commitment to employment fairness!
> This feature does enable a neat quine: the Perl program “Illegal division by zero at /tmp/quine.pl line 1.”, when saved in the appropriate location, outputs “Illegal division by zero at /tmp/quine.pl line 1.” The reason for this behavior is left as an exercise for the reader.
> (To be fair to Perl, when perl is run with the -w flag to enable warnings, it does helpfully inform the user that at some point in the future, the Perl developers will most likely pick gggijgziifiiffif as a new reserved word:
>> Unquoted string "gggijgziifiiffif" may clash
with future reserved word at - line 1.)
$ perl -MO=Deparse -e "Illegal division by zero at /tmp/quine.pl line 1."
'division'->Illegal('zero'->by('at' / 'tmp' / 'quine' . line'->pl(1)));
-e syntax OK
the actual parse is
((“at” / “tmp”) / “quine”)
Illegal::division(by::zero(at/tmp/quine . pl::line(1.)))
Or should that be 0.0???
For quines, see the chapter "Air on G's String", a dialogue between Achilles and the Tortoise in Douglas Hofstadter's book GODEL,ESCHER,BACH: AN ETERNAL GOLDEN BRAID.
It's clearly such an incredible labor of love by Larry Wall et al. that I'm sad for them it isn't more popular. Just a mammoth amount of work by nice, passionate people.
In my world (bioinformatics), it was initially the go-to language. Even today I very occasionally run across something using BioPerl, requiring me to stumble through CPAN again. I get pretty nostalgic thinking about it.
There's no reason to guess which factors contributed to Perl's uptake in the young bioinformatics community. Text processing is only one of six reasons Lincoln Stein listed in 1996 in "How Perl Saved the Human Genome Project". See https://web.stanford.edu/class/gene211/handouts/How_Perl_HGP...
Perl was starting to loose ground by then, but was still pretty popular. My guess is around a third of bioinformaticans were using it as the goto language at that point.
Its a pity, I miss Perl and still pull it out for quick scripts that involve manipulating the filesystem as its got so much better syntactic sugar for that sort of thing. And using regexes in Python is such a chore in comparison. I always need to look up the docs, whereas I remember how to use them in Perl despite hardly using the language in 8 years
for line in open("python_yacc.py"):
if line =~ m/def (?P<name>\w+) *(?P<args>\(.*\)) *:/:
print repr($1), repr($args)
It got appreciative hisses when I did a lightning talk about it at a PyCon.
FWIW, I co-founded Biopython back in 1999.
Ruby is specifically designed as a replacement for perl, and keeps a lot of the same warts ($igils, and globals like $?, $1, etc). While I agree it's better than perl for readability, it's not because there's only one way to do any given thing.
While I don't use it often, I feel like GoLang at least vaguely tried to adopt a "single solution" approach to language design. They keep the standard library as compact as possible, and formatting is non-optional with gofmt.
25249 lines (23725 sloc)
That would even more fittingly describe Perl 6.
For some reason, there seems to be a complete lack of toxic behavior in the Perl community (both 5 and 6).
An infinitely long input will never finishing reading, so we'll never find out :)
It's also not a valid Perl program:
bash-4.3$ perl -e "iStock by Getty Images"
Can't locate object method "Getty" via package "Images" (perhaps you forgot to load
"Images"?) at -e line 1.
As bad as some aspects of PHP were, making it so trivial to install and make available on a server was a brilliant move that lots of languages could still learn from today.
If you have a project you want to become popular putting real work in to the initial onboarding is vital.
Of course, I don’t run it like this in production (to refresh the production app I have to go to "/reload" from a certain IP address and be logged into the admin account).
Don’t worry: the “old ways” are still here, even if no longer mainstream.
"Ruby is a language of careful balance. Its creator, Yukihiro “Matz” Matsumoto, blended parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) ..."
Perl also looks like line noise, which makes it hard to read.
PHP also won because you can take a .html file add <?=$x+1?> and it's a valid PHP program. Perl was harder.
I found myself arguing yesterday with another person in the team about the proper use of Perl references, which I cursed and spat on for 2 days when I first had to use them.
I once read that my current position mirrors that of most Perl users.
(my boss has a self-confessed "irrational" hatred of Python because of semantic whitespace. Which is ironic, because they're the one who pushed for using YAML, which also relies on semantic whitespace (at least in the way we use it))
I had to chuckle at that. The whole this is so ridiculous and it's wonderful :D
Full proceedings document for this year: http://sigbovik.org/2019/proceedings.pdf
It seemed like so much of the web ran on it in the late 90s and early 2000s that it would have at least as much traction as PHP does today.
One can speculate what might have happened if focus had been put on evolving Perl5, or getting Rakudo production-ready as-is instead of going through yet another round of 'tinkering' (eg making the compiler backend-independent, the New Object Model refactor, creation of MoarVM, the Great List Refactor, ...) - however my crystal ball seems to be broken and just continues to display 42 no matter the question...
I don’t remember Perl losing mindshare around that time; quite the opposite.
Specifically December 25th 2015.
True, but when your reaction takes 10 years, you lost a lot of ground. When perl6 was started perl was declining but still in serious use.
It's percentage has dropped by a significant amount, but I would bet the amount of new code has not dropped nearly as much.
Also I'm fairly certain that Go is close to a 10 year reaction to Python. (If not it's implementation.) The only difference is that it wasn't done in public. It's so much easier to ignore the years of development when you can hide it.
The free form nature is amazing to spec out an idea and see what happens. Where it falls short for me is static analysis - a simple question like 'if we change this module, how many scripts will be affected?' is very difficult or impossible to answer due to the number of ways you can abuse Perl. Though in most cases, we get by.
$ </dev/urandom tr -dc $chars | head -c 10 | tee random.pl | perl
Regardless, fun to know that
Your statement might make sense, but what I'm saying is that the claim in the title doesn't equate to the claim you made. That's all I'm saying.
I think this says more about your skill level in programming Perl or programming in general at that time than it does about Perl. Or at least the influences that you learned Perl from.
It's possible to write nearly unreadable code in any language. It's easier to do so in Perl, since it's pretty freeform. It's also not that hard to write very clear code. But you're complaining about your own code. I think perhaps blaming the tool at that point is looking in the wrong place.
While I’m sure it’s possible to write maintainable perl I’ve never heard anyone say “we had 10,000 lines of perl and it was a joy to work with.” Ever.
These days, I wouldn't imagine most codebasse of 10k lines in Perl being noticeably worse than in Python or Ruby.
~$ ./perltest | tee output.txt
~$ cat output.txt
~$ cat perltest