Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^8: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

by likbez (Sexton)
on Sep 13, 2020 at 19:48 UTC ( [id://11121692]=note: print w/replies, xml ) Need Help??


in reply to Re^7: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
in thread What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by johngg (Canon) on Sep 13, 2020 at 22:49 UTC
    As for soft-semicolon you completly misunderstood the situation: First, nobody force you to use this pragma. And if you do not use it you are not affected. I am thinking now that it should be enabled only with option -d.

    In the OP you make no mention of a pragma in proposal 1, you just say that it would be "highly desirable" to have soft semicolons. This implies that you would like it to be the default behaviour in Perl 7, which, judging by the responses, would hack a lot of people off, me included. If you are proposing that soft semicolons are only enabled via a pragma perhaps you should add a note to that effect in the OP, being sure to make it clear that it is an update rather than silently changing the text.

    And IMHO there is not a zero subset of Perl users who would be interested in this capability. Especially system administrators who systematically use bash along with Perl.

    I spent the last 26 years of my career as a systems administrator (I had no ambition to leave technical work and become a manager) on Unix/Linux systems and started using Perl in that role in 1994 with perl 4.036, quickly moving to 5. The lack of semicolon statement terminators in the various shell programming languages I had to use was a pain in the arse and moving to Perl was a huge relief as well as a boost to effectiveness. I would not be the slightest bit interested in soft semicolons and they would, to my mind, be either a debugging nightmare or would force me into a coding style alien to my usual practice.

    In this post you say

    Also Python-inspired fascination with eliminating all brackets does not do here any good

    1 2 $a=$b=1; 3 $x=1 if $a==1 4 && $b=2;

    should generally be written

    2 $a=$b=1; 3 $x=1 if( $a==1 4 && $b=2);

    to which I say, nonsense! Why add unnecessary round brackets to perfectly valid code? Use round brackets where they are needed to disambiguate precedence but not where they just add superfluous noise. Nothing to do with fascination, I've never touched Python!

    You should be commended on the amount of thought that you have put into your proposals and such efforts should not be discouraged. It is unfortunate that your first proposal has been the most contentious and the one that most responses have latched onto. Sticking to one's guns is also a praiseworthy trait but doing so in the face of several powerful and cogent arguments to the contrary from experienced Perl users is perhaps taking it too far. Making it clear that soft semicolons would not be the default behaviour might apply some soothing balm to this thread.

    Cheers,

    JohnGG

Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh (Monsignor) on Sep 14, 2020 at 08:09 UTC
    It does not make sense to conduct something like "performance review" in a large corporation for my proposals concentrating on "soft-semicolon" idea and ignoring all others. As if it is the only one worth any discussion.
    Others have already contributed their thoughts on the rest of your proposals, which I generally agree with and (more significantly) you haven't disputed. IMO, the primary reason that all the discussion is focusing on soft semicolons is because it's the only point you're attempting to defend against our criticisms. There was also a brief subthread about your ideas on substring manipulation, and a slightly longer one about alternate braces which close multiple levels of blocks, but those only lasted as long as you continued the debate.
    In a way, it is a debugging aid that allows to cut the number of debugging runs.
    Seems like just the opposite to me. It may allow you to get your code to run sooner, but, when it does, any semicolon errors will still be there and need to be fixed in additional debugging runs. Maybe a marginal decrease in overall debugging time if there's a line where you never have to fix the semicolon error because that line ends up getting deleted before you finish, but it seems unlikely to provide any great savings if (as you assert) such errors are likely to be present on a significant proportion of lines.

    Also, even if it does cut out some debugging runs, they're runs with a very fast turnaround and little-to-no cognitive effort involved. According to your "BlueJ" paper, even rank beginners need only 8 seconds to fix a missing semicolon error and initiate a new compile.

Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Jenda (Abbot) on Oct 17, 2020 at 18:55 UTC
    Are all other equally bad ?

    Yes.

    Jenda
    1984 was supposed to be a warning,
    not a manual!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11121692]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (4)
As of 2024-03-28 15:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found