commit 05635eb27f21eb58590ee0346160b435ad8566fb
Author: Simon Watson <spw01@protonmail.com>
Date: Wed Feb 16 21:12:46 2022 -0500
Updates/edits
diff --git a/in-defense-of-perl.org b/in-defense-of-perl.org
index d455ac1..086bb2c 100644
--- a/in-defense-of-perl.org
+++ b/in-defense-of-perl.org
@@ -107,8 +107,8 @@ gopher://
In this blog post I hope to address these arguments and others, with
concrete and constructive counter points.
- My aim in writing this is not to convince people to program in Perl. It's to convince
- people that Perl is not only a perfectly fine language to use for many different problem
+ My aim in writing this is _not to convince people to program in Perl._ It's to convince
+ people that _Perl is perfectly fine language to use_ for many different problem
areas -- it's to show that it may in fact be the /better/ choice for some problem areas.
I hope the distinction is clear and that I can convince you!
@@ -119,6 +119,7 @@ gopher://
** Perl Syntax
+*** Examples
People often talk about how Perl is completely unreadable and "write only". This can
be true, but I think it can be true for /any/ language, and as such doesn't really feel
like a valid criticism.
@@ -173,68 +174,8 @@ gopher://
may have preferences for one or the other, but I don't think an argument can be made that one or the
other is objectively better.
- OK, so you're probably thinking, this is such a ridiculous and contrived example, and that's true to
- an extent. Let's take a look at something a little bit more involved.
-
- Writing a program to emulate 'tail'.
-
- I saw what I think is an extremely elegant way to do this in Python, see:
- http://www.dabeaz.com/coroutines/follow.py
- http://www.dabeaz.com/coroutines/
-
- For the sake of ease the code above has been copied below. I've changed it slightly
- to work for my version of Python.
-
- #+BEGIN_SRC python
- import time
- def follow(thefile):
- thefile.seek(0,2) # Go to the end of the file
-
- while True:
- line = thefile.readline()
- if not line:
- time.sleep(0.1) # Sleep briefly
- continue
- yield line
-
- # Example use
- if __name__ == '__main__':
- logfile = open("log_file")
- for line in follow(logfile):
- print(line)
- #+END_SRC
-
- The above Python code snippet features some cool async features, but I'm not aiming to talk about that here. I provided
- above simply because I think it show cases some of Python's more elegant syntax and expressive qualities.
-
- Below is a code snippet in Perl that performs roughly the same thing (from a user point of view):
-
- #+BEGIN_SRC perl
- #!/usr/bin/perl
-
- use strict;
- use warnings;
-
- open(my $fh, '<', "log_file");
-
- while () {
- seek($fh, 0, 1);
- print(readline($fh));
- sleep 1;
- }
-
- close($fh);
- #+END_SRC
-
- Again, echoing the sentiments from above. I think both of these implementations are perfectly readable and expressive, and
- don't ask /too/ much of the user unfamiliar with the language:
- - open a file handle
- - seek to end of it
- - read the line
- - print the line
-
- With some contrived examples out of the way, I'm going to provide a code example from some code I wrote in
- the past week:
+ With a simple example out of the way, I'm going to provide a code example from some code I wrote in
+ the past month:
#+BEGIN_SRC perl
if ( $log_file_path =~ m/(\d{4}-\d{2}-\d{2}).log/ ) {
@@ -307,16 +248,35 @@ gopher://
As mentioned above, Perl has this issue as well to an extent, but I think to a lesser extent than dynamically typed
languages that don't denote type with any kind of special syntax.
- I acknowledge however it's difficult to make an _objective_ argument in this regard, so...moving on.
+ I think though that it's difficult to make an _objective_ argument in this regard, so...moving on.
+
+*** Perlvars and Perl Magic
+
+ A friend brought up another interesting point with the last code snippet, the use of the Perl built-in =$1= var.
+
+ To me there seems to be some difficulty in making _objective_ arguments around syntax preferences, but in
+ discussing this article with a friend, there are maybe _objective_ arguments to make against
+ some of the abstractions Perl provides the user.
+
+ In the context of the previous code snippet, I'm using =m//= and regex capture groups to assign a variable:
+ #+BEGIN_SRC perl
+ if ( $log_file_path =~ m/(\d{4}-\d{2}-\d{2}).log/ ) {
+ my $log_date = $1;
+ # ...
+ #+END_SRC
+
+ My friends argument against this kind of magic assignment was that it breaks well understood mental models of
+ how programs operate: You can't use a variable you haven't defined.
+
+ In the greater context of the program this snippet comes from, =$1= is never assigned anywhere,
+ it's provided to me via PCRE.
- I don't want to spend too much time on Perl syntax. I've tried to cover a few small things here, but obviously
- this is pretty shallow and that's kind of intentional. I can spend all day trying to lay out a case on why
- Perl syntax isn't ugly or unreadable, but again I think this is ultimately a subjective point.
+ I was able to be convinced this kind of behavior is more harmful than the way Python handles this problem
+ ( =re.match= /etc) because it forces the reader, who may be familiar with many other languages, but not
+ Perl, to understand Perl specific implementation details.
- It's possible that when looking at programming languages, there is an objective lens with which to view syntax.
- Perhaps that lens is the problem domain and the language features that cater to that problem domain. I think
- at the highest level though, it's ultimately a preference. I'd love to hear your thoughts if you disagree in
- this regard.
+ This is a very valid criticism I think, and as such this leads to the obvious question of what benefit
+ do you get from this complexity? I think, in a word: brevity.
* Perl is /fast/