|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
|
|
Currently, the major change in Perl 7 is that pragma warnings and strict will be enabled by default. So all old script probably will need to have version less then 7 to be explicitly stated.
Below there are some extracts from the discussion of enhancement that can be implemented in Perl 7 from Perlmonks (access requires login)
What esteemed monks think about changes necessary-desirable in Perl 7 outside of OO staff
The main danger for the future of Perl are complexity junkies and OO-bigots. Why not to simplify the language, not to make it more complex. Let the complexity be explored by Raku team.
Take some rational ideas from Python and PHP and stick to Perl5 core minus OO. Those who are brainwashing in OO-cult will probably not use Perl anyway. They have plenty of more fancy languages to choose from. But there are many other ways to structure the program and program namespace without OO overhead. For example Python lost a lot of module system efficiency by overloading it with OO. This avenue should be exploited.
The key issue about Perl is that it does not make sense to try to complete with Python in OO and Web frameworks areas. Both wars already lost and it does not make sense to reply them. Perl is often associated with being the predecessor to PHP and was used for the CGI programming in mid nineties. After the Dot Com Crash PHP became the king of the hill. Python took OO mantle (that comes with huge costs, which partially explains the fact that it is very very slow) and chances of taking it back by Perl are close to zero. The language should be adapted strictly for the needs of sysadmins.
But Perl overcomplexity junkies still have a lot of influence in Perl 5 community despite the fact that they now can play with Raku anyway they wish.
The far plans are grandiose( see Perl Community Roadmap ) but resources are shrinking with the separation between Perl 5 and Raku. Do only small changes can be implemented in Perl 7. The question is "what changes?"
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Oct 11, 2020 | perlmonks.org
by likbez
on Oct 11, 2020 at 04:45 UTC ( # 11122681 = note : print w/replies , xml ) Need Help??
- log likbez out
- likbez
- The Monastery Gates
- Seekers of Perl Wisdom
- Meditations
- Cool Uses For Perl
- Obfuscation
- Q&A
- Tutorials
- Poetry
- Reviews
- Perl News
- Donate
- Recent Threads
- Newest Nodes
- Super Search
- PerlMonks Discussion
- What's New
Reputation: 0 The problem is C-style delimiters for conditional statements (round brackets) and overuse of curvy brackets. The former is present in all C-style languages.
in reply to Re^10: 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 staffSo IMHO omitting brackets in built-in functions was a false start; the problem that should be addressed is the elimination of brackets in prefix conditionals.
One possible way is to have a pragma "altblockdelim" or something like that, which would allow to use,say, ?? and ;; or classic "begin/end" pair instead of '{' and '}', which are overused in Perl. That would decrease parenthesis nesting.
After all, we can write && as "and" and some people like it.
It's like within Perl 5 exists a language with more modern syntax that just wants to emerge.
by GrandFatheron Oct 11, 2020 at 07:13 UTC ( # 11122686 = note : print w/replies , xml ) Need Help??
- log likbez out
- likbez
- The Monastery Gates
- Seekers of Perl Wisdom
- Meditations
- Cool Uses For Perl
- Obfuscation
- Q&A
- Tutorials
- Poetry
- Reviews
- Perl News
- Donate
- Recent Threads
- Newest Nodes
- Super Search
- PerlMonks Discussion
- What's New
in reply to Re^11: 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 staffI'm not sure how a discussion about parenthesis ( ) morphed into too many brackets ("curvy brackets" - { } ), but I don't see the problem in any case. The use of brackets for block delimiters is visually quite distinct from any other use I'm familiar with so I don't see the problem.
There is a usage of ;; that I don't quite grok, but seems to be fairly common so the ;; option probably wouldn't fly in any case.
Perl's && and and operators have substantially different precedence. They must not be used as interchangeable. Yes, subtle I know, but very useful.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyondlikbez on Oct 11, 2020 at 15:22 UTC
Re^13: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffI'm not sure how a discussion about parenthesis ( ) morphed into too many brackets ("curvy brackets" - { }), but I don't see the problem in any case.In C you can writeif(i<0) i=0
if Perl you can't and should write
if( $i<0 ){ $i=0 }
because the only statement allowed after conditionals is a compound statement -- a block. Which was a pretty elegant idea that eliminates the problem of "dangling else" https://www.sanfoundry.com/c-question-dangling-else-statements/
But the problem is that at this point round parenthesis become a wart. They are not needed and they detract from readability. So if curvy brackets were not used anywhere else you can simplify this to
if $i<0 {$i=0}
But you can't do this in Perl because curvy brackets are used for hashes.
In Perl ; is an empty(null) statement. So the current meaning of ;; is "the end of the previous statement followed by the null statement".There is a usage of ;; that I don't quite grok, but seems to be fairly common so the ;; option probably wouldn't fly in any case.
main::(-e:1): 1 DB<1> ;;;; DB<2> $a=5;; DB<3> print $a;; 5the new meaning will be "the end of the current statement and the end of the block", which is pretty elegant idea in its own way. Because now Perl allows omitting semicolon before } as special case, but in the new syntax this is just a general case and the special case is not needed.
- Comment on Re^12: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
- Select or Download Code
- Send private /msg to GrandFather
Replies are listed 'Best First'.
|
|
|
Oct 02, 2020 | perlmonks.org
likbez on Oct 02, 2020 at 02:37 UTC ( # 11122463
in reply to Re^14: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff (don't feed)
in thread What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffFor programming languages to evolve and flourish, we all need to accept other people's viewpoints and continue open-minded, civil and respectful dialogue.
In science, scientists always question everything; why shouldn't we question some features and point out deficiencies of Perl 5 which after version 5.10 became really stale feature-wise -- the last important addition was the addition of state variables in 5.10. Partially this happened as most resources were reallocated to Perl 6 (The Perl 6 project was announced in 2000), a robust interpreter for which failed to materialize for too long: the situation which also slowed down Perl 5 interpreter development.
The question arise: Should it be possible on perlmonks to criticize some aspects of Perl 5 current features and implementation as well as its use without being denigrated as a reward?
At least after the split Perl 5 has theoretical chances to stand on its own, and evolve like other languages evolved (for example, FORTRAN after 1977 adopted 11 years cycle for new versions). As Perl 5.10 was released in 2007, now it is 13 years since this date and Perl 7 is really overdue. The question is what to include and what to exclude and what glaring flaws need to be rectified (typically a new version of a programming language tries to rectify the most glaring design flaws in the language and introduce changes that could not be implemented while retaining full backward compatibility.)
Brian D Foy post that announced this new version is really weak. It essentially states "We decided to rename 5.32 and you all should be happy." It does not contain any new ideas, just the desire to have new version of Perl as Perl 5.32 with few new defaults (which BTW will break compatibility with old scripts at least with 5.8 and earlier versions scripts as not all of them use strict pragma, and strict pragma implementation still has its own set of problems ).
The question arises: Whether the game worth candles? Unless the new editions of O'Reilly books is the goal. That's why I provided this contribution, suggesting some minor enhancements which might better justify calling the new version Perl 7. And what I got in return ?
I hoped that this post would be a start of the meaningful discussion. But people like you turned it into a flame-fest.
It looks like it is impossible to have a rational fact-based discussion on this subject with zealots like you.
|
|
|
Sep 27, 2020 | www.quora.com
Eric Christian Hansen , former Senior Systems Analyst (1999-2002) Answered May 15, 2019 · Author has 5.1K answers and 1.6M answer viewsPERL is not dead, only those guardians of PerlMonks dot org, who lie in wait to bounce upon your most recent posts with spiteful replies loaded with falsehoods and hate and jealousy.
Good luck trying to impart your acquired PERL knowledge there. They will do their very best to attempt to discredit you and your ideas.
Alex Jones , works at Own My Own Business Answered January 12, 2020 · Author has 259 answers and 76.1K answer views
My answer refers to Perl 5 rather than Raku (Perl 6),
Perl 5 is a veteran computer language with a track record and pedigree of several decades. Perl has been around long enough that its strengths and weaknesses are known; it is a stable, predictable and reliable language that will deliver results with little effort.
In the new decade 2020 and beyond, Perl in my opinion, remains competitive in performance against any other computer language. Perl remains viable as a language to use in even the most advanced of information technology projects.
Simple market forces have driven Perl out of the top computer languages of choice for projects. Because a business finds it hard to find Perl developers, they are forced to use a computer language where there are more developers such as Python. Because fewer businesses are using Perl in their projects, the education system selects a language such as Python to train their students in.
Perl 5 will probably no longer be the universal language of choice for developers and businesses, but may dominate in a particular niche or market. There is a major campaign underway by supporters of Perl 5 and Raku to promote and encourage people to learn and use these languages again.
My startup is involved in AI, and I use Perl 5 for the projects I am developing. There are a number of strengths in Perl 5 which appeal to me in my projects. Perl 5 has a strong reputation for the abilty to create and execute scripts of only a few lines of code to solve problems. As Perl 5 is designed to be like a natural spoken language, it becomes the practical choice for handling text. When handling complex patterns, the regex capabilities in Perl 5 is probably the best of any computer language. Lastly, Perl 5 was the glue that enabled the systems of the 1990's to work together, and might offer a pragmatic solution to bridging the old with the new in the modern era.
I would describe Perl as existing in a dormant phase, which is waiting for the right conditions to emerge where it will regain its place at the leading edge in a niche or market such as in artificial intelligence. Joe Pepersack , Just Another Perl Hacker Answered May 31, 2015 · Author has 5.7K answers and 7M answer views
No. It's not dead. But it's not very active, either and it's lost a lot of mindshare to Ruby and Python. Hopefully the recently-announced December release of Perl 6 (Finally!) will renew interest in the language.
I found a really useful site the other day: Modulecounts . CPAN is Perl's greatest asset, but unfortunately it seems to have stagnated compared to Pypi or RubyGems. CPAN is getting 3 new modules per day whereas RubyGems is getting 53/day. Rubygems overtook CPAN in 2011 and Pypi overtook it in 2013.
Personally I think Python is Perl on training wheels and represents a step backwards if you're coming from Perl. Ruby is a great language and is pretty Perl-ish overall. Plus someone just recently ported Moose to Ruby so that's a huge win.
I would argue Perl is still worth learning for a couple main reasons:
- It's ubiquitous. Every Unix-ish system made in the last decade has some version of Perl on it.
- It's still unbeaten for text manipulation and for doing shell-scripty type things that are too hard to do in bash.
- Ad-hoc one-liners. Neither ruby nor python can match perl for hacking together something on the command line.
- There's a lot of Perl code still out there doing important things. It's cheaper to maintain it than it is to re-write it in another language.
Tom Le , CSO • CISO • CTO | Security Expert Answered April 3, 2015
Perl is certainly not dead, but it does face an adoption challenge. For example, fewer vendors are releasing Perl API's or code samples (but the Perl community often steps in at least for popular platforms). Finding new developers who know Perl is more difficult, while it is much less difficult to find developers with Python and Java. The emerging technology areas such as big data and data science have a strong Python bent, but a lot of their tasks could be done faster in Perl (from my own experience).
What is great about Perl is despite its quirks, is it is relatively easy to learn if you know other programming languages. What I have found amazing is that when developers are "forced to learn Perl" for a project, they usually pleasantly surprised at how powerful and unique Perl is compared to their language of choice.
From a job value perspective, Perl knowledge has some interesting value quirks (just like the language has some interesting quirks). The market for Perl developers is not as large as other languages, but companies that need Perl developers have a hard time finding good candidates. Thus, you might find it easier to get a job with Perl skills even though there are fewer jobs that require it.
In short, Perl has an amazing ability to convert existing programmers, but fewer programmers are coming into the workforce with Perl experience.
Avi Mehenwal , Ex-perl programmer, but still cannot let it go. I feel the RegEx Attachement Answered April 2, 2016 · Author has 64 answers and 226.8K answer views
Perl has been around since 1987 and became an early darling of web developers. These days, however, you don't hear much about Perl. Everyone seems to be talking about trendier languages like PHP, Python and Ruby, with Perl left in the back as a neglected, not-so-hip cousin.
That might lead you to think that Perl is dying, but as it turns out, it's still used by plenty of websites out there, including some pretty big hitters.
Here are some of the more popular sites that use Perl extensively today:
- Amazon.com: Online Shopping for Electronics, Apparel, Computers, Books, DVDs & more
- IMDb - Movies, TV and Celebrities
- craigslist > sites
- News, sport and opinion from the Guardian's US edition | The Guardian
- The Best Deals on Hotels, Flights and Rental Cars.
Sources:
Dave Cross , I make things with software. Answered October 1, 2014 · Author has 1.6K answers and 1.4M answer views
Depends what you mean by dead.
The language is still thriving. There's a new release every year and each release includes interesting new features (most recently, subroutine signatures). More modules are uploaded to CPAN every year. More authors contribute code to CPAN every year.
But I still think that Perl is dying and I would find it hard to recommend that anyone should choose a career in Perl at this point.
Ask yourself these three questions:
- When did you last read a general programming book that included examples in Perl?
- Why did you last see an API that included usage examples written in Perl?
- When did you last hear of a company using Perl that you didn't already know about?
I should be working 16 hours ago remove link
Hey guys: MAYBE WE SHOULD FOCUS ON GETTING GOOGLE UNDER CONTROL FIRST! play_arrow
mike_1010 17 hours ago (Edited)
Source code information is a closely guarded secret for all IT companies. Because if hackers get access to it, then they can find many ways to compromise its security and to spy on its users.
So, it makes sense that the Chinese government might want to protect the source code of apps that are used by many people in China.
I'm sure the US government would say the same thing, if some Chinese company wanted to buy the source code of Microsoft's Windows 10 operating system or something like that.
From the point of view of cybersecurity, this makes perfect sense.
Every country has legitimate security concerns. And these concerns were heightened, when Edward Snowden revealed the extent of US government hacking and spying of the rest of the world, including China.
The Chinese government has actually more evidence and more reasons to be concerned about possible hacking and spying by the US government, than the other way. USA has only been accusing China of doing the same. But they've never shown any conclusive evidence to back their claims, the way Edward Snowden has revealed such evidence about USA.
The only thing that surprises me in this whole affair is that it took the Chinese government this long to say the obvious. If the situation was reversed and the issue was about the source code of some US company software, then US politicians and security experts would've been yelling about this kind of thing right from the start.
|
|
|
Sep 22, 2020 | perlmonks.org
All of the following satisfy your criteria, are valid and normal Perl code, and would get a semicolon incorrectly inserted based on your criteria:Yes in cases 1 and 2; it depends on depth of look-ahead in case 3. Yes if it is one symbol. No it it is two(no Perl statement can start with && )use softsemicolon; $x = $a + $b; $x = 1 if $condition; $x = 1 unless $condition1 && $condition2;As for "valid and normal" your millage may vary. For people who would want to use this pragma it is definitely not "valid and normal". Both 1 and 2 looks to me like frivolities without any useful meaning or justification. Moreover, case 1 can be rewritten as:
$x =($a + $b); [download]The case 3 actually happens in Perl most often with regular if and here the opening bracket is obligatory:
if ( ( $tokenstr=~/a\[s\]/ || $tokenstr =~/h\[s\]/ )
&& ( $tokenstr... ) )
{ .... }Also Python-inspired fascination with eliminating all brackets does not do here any good
$a=$b=1;
$x=1 if $a==1
&& $b=2;should generally be written
$a=$b=1;
$x=1 if( $a==1
&& $b=2);was surprised that the case without brackets was accepted by the syntax analyzer. Because how would you interpret
$y=1 if $x{$i++};
without brackets is unclear to me. It has dual meaning: should be a syntax error in one case
$y=1
if $y {
$i++
};
[download]and the test for an element of hash $a in another.
dave_the_m on Sep 12, 2020 at 06:52 UTC
Re^13: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffBoth 1 and 2 looks to me like frivolities without any useful meaning or justificationYou and I have vastly differing perceptions of what constitutes normal perl code. For example there are over 700 examples of the 'postfix if on next line' pattern in the .pm files distributed with the perl core.There doesn't really seem any point in discussing this further. You have failed to convince me, and I am very unlikely to work on this myself or accept such a patch into core.
Dave.
likbez on Sep 12, 2020 at 19:53 UTC
Re^14: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by likbez on Sep 12, 2020 at 19:53 UTCYou and I have vastly differing perceptions of what constitutes normal perl code. For example there are over 700 examples of the 'postfix if on next line' pattern in the .pm files distributed with the perl core.Probably yes. I am an adherent of "defensive programming" who is against over-complexity as well as arbitrary formatting (pretty printer is preferable to me to manual formatting of code). Which in this audience unfortunately means that I am a minority.BTW your idea that this pragma (which should be optional) matters for Perl standard library has no connection to reality.
GrandFather on Sep 12, 2020 at 23:53 UTC
Re^15: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffA very large proportion of the replies you have received in this thread are from people who put a high value on writing maintainable code. "maintainable" is short hand for code that is written to be understood and maintained with minimum effort over long periods of time and by different programmers of mixed ability.
There is a strong correlation with your stance of "defensive programming" ... against over-complexity as well as arbitrary formatting . None of us are arguing with that stance. We are arguing with the JavaScript semicolon that you would like introduced based on a personal whim in a context of limited understanding of Perl syntax and idiomatic use.
Personally I use an editor that has an on demand pretty printer which I use frequently. The pretty printer does very little work because I manually format my code as I go and almost always that is how the pretty printer will format it. I do this precisely to ensure my code is not overly complex and is maintainable. I do this in all the languages that I use and the hardest languages to do that in are Python, VBScript and JavaScript because of the way they deal with semi-colons.
Oh, and in case it is of interest, dave_the_m is one of the current maintainers of Perl. He is in a great position to know how the nuts and bolts of an optional semi-colon change might be made and has a great understanding of how Perl is commonly used. Both give him something of a position of authority in determining the utility of such a change.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyondtobyink on Sep 12, 2020 at 22:24 UTC
Re^11: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff"no Perl statement can start with the dot"
Yada-yada operator in Perl 5.12+.
toby döt inkikegami on Sep 14, 2020 at 22:15 UTC
Re^12: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffParser lookaheads are implemented in terms of tokens, not characters. The first token of yada is a triple-dot, not a dot. While you may think it starts with a dot, that's not how the parser sees it, so the existence of yada is not relevant here.
Tux on Sep 12, 2020 at 09:38 UTC
Re^7: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffYou also completely ruin maintainability and extensibility. Consider a filter module ...
my $fixed = $bad =~ y/\x{00d0}/\x{0110}/r # Eth != D-stroke =~ y/\x{0189}/\x{0110}/r # LETTER AFRICAN D != + D-stroke =~ s{\bpra[ck]ti[sc]e\b}{practice}gr # All 4 seen in docume + nt AB12.38C =~ s{\bX13\.GtrA\.14\b}{X13_GA12}gr # Product got renamed =~ s{\b1234\s*zip\b}{1234ZIP}gir # Reciever will crash + on badly formed ZIP code =~ s{\bpays\s*-?\s*bas\b} {The Netherlands}gir # French forms :( =~ ....;The more examples I see posted by my esteemed co-monks, the less I like the idea, and I hated it already when I read it in the OP.
Enjoy, Have FUN! H.Merijnlikbez on Sep 13, 2020 at 19:48 UTC
Re^8: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffWhy you are concentrating on just one proposal. Are all other equally bad ?
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.
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. It might be the easiest one to piss off, but it is far from being the most important or far reaching among those proposals.
There is no free lunch, and for some coding styles (including but not limited to coding styles used in many modules in Perl standard library) it is definitely inappropriate. Nobody claim that it is suitable for all users. It is an optional facility for those who want and need it. In a way, it is a debugging aid that allows to cut the number of debugging runs. 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. And many of them do not use sophisticated editors, often this is just vi or Midnight Commander editor.
Detractors can happily stay with the old formatting styles forever. Why is this so difficult to understand before producing such an example?
Moreover, how can you reconcile the amount of efforts (and resulting bugs) for the elimination of extra round brackets in Perl with this proposal? Is not this the same idea -- to lessen the possible number of user errors?
For me, it looks like a pure hypocrisy - in one case we are spending some efforts following other scripting languages at some cost; but the other, similar in its essence, proposal is rejected blindly as just a bad fashion. If this is a fashion, then eliminating round brackets is also a bad fashion, IMHO.
And why only I see some improvements possible at low cost in the current Perl implementation and nobody else proposed anything similar or better, or attempted to modify/enhance my proposals? After all Perl 5.10 was a definite step forward for Perl. Perl 7 should be the same.
I think the effort spend here in criticizing my proposal would be adequate to introduce the additional parameter into index function ("to" limit). Which is needed and absence of which dictates using substr to limit the search zone in long strings. Which is sub-optimal solution unless the interpreter has advanced optimization capabilities and can recognize such a use as the attempt to impose the limit on the search.
Or both this and an option in tr that allows it to stop after the first character not is set1 and return this position.:-)
Constructive discussion does not mean pissing off each and every my posts ( one has -17 votes now; looks a little bit like schoolyard bulling ) -- you need to try to find rational grain in them, and if such exists, try to revise and enhance the proposal.
The stance "I am happy with Perl 'as is' and go to hell with your suggestions" has its value and attraction, but it is unclear how it will affect the future of the language.
johngg on Sep 13, 2020 at 22:49 UTC
Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffAs 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; [download]should generally be written
2 $a=$b=1; 3 $x=1 if( $a==1 4 && $b=2); [download]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
dsheroh on Sep 14, 2020 at 08:09 UTC
Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffIt 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.
ikegami on Sep 14, 2020 at 22:11 UTC
Re^7: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffYes, and the user will get an error.
Then your suggestion would break a very useful feature. So useful that I take advantage of it in virtually every one of my programs/modules.
|
|
|
www.oreilly.com
Where languages like Basic, TCL, and Logo were artificially limiting, C++ and Perl are, in my opinion, artificially complex. Obviously there are many smart people out there preparing to send me an email claiming that the complexity "buys" them something valuable. I think that the cost is high.
>I am not entirely naive: Computer programming is hard. It is precisely because it is hard that there is no excuse for adding artificial obstacles like modern languages rooted in the idioms of dead languages, and adding syntaxes so complex that humans cannot keep them in their head.
... ... ...
My primary criteria for decency--whether in programming languages, markup languages, or graphical systems--is scalability. By scalability, I mean two things: the ability to scale from easy to difficult problems and the ability for beginners and experts to be comfortable.
Consider an episode from my own life. I was around nine or ten years old and my father taught me how to do things on our Apple II using Basic. My dad was always much more of a hardware rather than software guy. Whenever I would tell him I wanted to do something more complex than we could find in the Basic manual, he would say, "You have to do that in assembly language, and assembly is too hard for a kid." He didn't mean to shut me down but he also didn't know 6502 assembly language himself and was not in much of a position to teach it to me.
The effect, though, was that my travel down the path to programmer enlightenment was delayed for several years. The Basic dialect was (like today's "TCL") designed for beginners and had many arbitrary limitations built in. Assembly was designed for programmers and made no concessions to usability, intuitiveness, or learning. Neither was scalable.
Today we have Perl, TCL, and C++: all non-scalable in their own way. C++ and Perl only make sense if you have a particular programming background. If you did not come from the "Unix tradition", many of their conventions and idioms seem alien.
Consider the modern nine-year-old boy trying to configure and extend his Linux system. He would find that many string-processing programs are inexplicably written in C: one of a very few languages that does not even have a first-class string data type! Most of the GUIs would be written in C++, despite the inflexibility of the language. Many other programs are written in a variety of illegible dialects within the family of languages called "Perl".
C and assembly have historical reasons for being so low-level and thus difficult to use and learn. It makes sense sometimes to trade usability for performance. C++ and Perl have no such excuse. They are cryptic and complex because of an overemphasis on backwards compatibility and plain, old-fashioned poor design.
Where languages like Basic, TCL, and Logo were artificially limiting, C++ and Perl are, in my opinion, artificially complex. Obviously there are many smart people out there preparing to send me an email claiming that the complexity "buys" them something valuable. I think that the cost is high.
When you use some wickedly cool and obscure feature of the language, you reduce the number of potential readers of your code. Ideally the language would encourage you to concentrate your creativity on high-level design. Choosing algorithms and data structures is hard enough. Keeping all of the library functions in your head is also tricky. On top of all of this, programmers should not need to decipher obscure core language features. Why make life harder for those who will follow you?
Personally, I cannot stand this design aesthetic, because it divides the world into "programmers" and "non-programmers". My dream is a world wherein all but the very lowest levels and tightest loops of programs are written in a language that is so simple that it can be taught in primary school as a first language; where every word-processor user who can write a macro can at least try to dive into their word processor's source code to fix a bug, because the macro language is also the implementation language.
We know that such a language exists. Python is easy enough to be a first language and powerful enough to write object databases (like ZODB) and in-memory relational database engines (like Gadfly). And yet, you do not have to come to grips with a complex and difficult type system to use it, and there are few magical variables and functions. I believe it to be as flexible as Smalltalk and as feature-full as Perl; and yet it is as easy as Basic or TCL.
... ... ...
Python may or may not be the language that brings about a Computer-Programming-for-Everybody world. But it is currently the best contender. When there is a better horse, I'll switch my bet. The hard part for a competitive system is building a sophisticated class library; but if the language is good enough, it will find early adherents that will do the work, as Python has.
A hint to would-be language developers: If your language runs on the JVM as JPython does, you get the benefit of the Java library "for free". Being Open Source is also a necessity today.
Power, elegance, simplicity, equality, liberty, fraternity: This is heady stuff, and it explains the evangelical tone of some Python programmers. I promote Python because doing so is the right thing.
|
|
|
Sep 17, 2020 | perlmonks.org
Re^5:johngg on Sep 12, 2020 at 13:46 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by johngg on Sep 12, 2020 at 13:46 UTCif we assume that somebody uses this formatting to suffix conditionalsI do, pretty much all the time! The ability to span a statement over multiple lines without jumping through backslash hoops is one of the things that makes Perl so attractive. I also think it makes code much easier to read rather than having excessively long lines that involve either horizontal scrolling or line wrapping. As to your comment regarding excessive length identifiers, I come from a Fortran IV background where we had a maximum of 8 characters for identifiers (ICL 1900 Fortran compiler) so I'm all for long, descriptive and unambiguous identifiers that aid those who come after in understanding my code.
Cheers,JohnGG
dsheroh on Sep 11, 2020 at 08:11 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 11, 2020 at 08:11 UTCyou !!! on Sep 13, 2020 at 21:25 UTC
Re^6: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 13, 2020 at 21:25 UTCIt might make sense to enable it only with -d options as a help for debugging, which cuts the number of debugging runs for those who do not have editor with built-in syntax checking (like ActiveState Komodo Editor; which really helps is such cases ).
That list includes most Linux/Unix system administrators, who use just command line and vi or similar. And they also use bash of daily basis along with Perl, which increases the probability of making such an error. And this is probably one of the most important category of uses for the future of Perl: Perl started with this group (Larry himself, Randal L. Schwartz, Tom Christiansen, etc) and after a short affair with the Web programming (yahoo, etc) and bioinformatics (bioperl) retreated back to the status of the scripting language of choice for the elite Unix sysadmins.
That does not exclude other users and applications, but I think the core of Perl users are now Unix sysadmins. And their interests should be reflected in Perl 7 with some priority.
BTW, I do not see benefits of omitted semicolons in the final program (as well as, in certain cases, omitted round brackets).
by johngg on Sep 12, 2020 at 13:46 UTCif we assume that somebody uses this formatting to suffix conditionalsI do, pretty much all the time! The ability to span a statement over multiple lines without jumping through backslash hoops is one of the things that makes Perl so attractive. I also think it makes code much easier to read rather than having excessively long lines that involve either horizontal scrolling or line wrapping. As to your comment regarding excessive length identifiers, I come from a Fortran IV background where we had a maximum of 8 characters for identifiers (ICL 1900 Fortran compiler) so I'm all for long, descriptive and unambiguous identifiers that aid those who come after in understanding my code.
Cheers,JohnGG
dsheroh on Sep 11, 2020 at 08:11 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 11, 2020 at 08:11 UTCyou !!! on Sep 13, 2020 at 21:25 UTC
Re^6: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 13, 2020 at 21:25 UTCIt might make sense to enable it only with -d options as a help for debugging, which cuts the number of debugging runs for those who do not have editor with built-in syntax checking (like ActiveState Komodo Editor; which really helps is such cases ).
That list includes most Linux/Unix system administrators, who use just command line and vi or similar. And they also use bash of daily basis along with Perl, which increases the probability of making such an error. And this is probably one of the most important category of uses for the future of Perl: Perl started with this group (Larry himself, Randal L. Schwartz, Tom Christiansen, etc) and after a short affair with the Web programming (yahoo, etc) and bioinformatics (bioperl) retreated back to the status of the scripting language of choice for the elite Unix sysadmins.
That does not exclude other users and applications, but I think the core of Perl users are now Unix sysadmins. And their interests should be reflected in Perl 7 with some priority.
BTW, I do not see benefits of omitted semicolons in the final program (as well as, in certain cases, omitted round brackets).
|
|
|
Sep 16, 2020 | perlmonks.org
- [Edited] [Highly desirable] Make a semicolon optional at the end of the line, if there is a balance of brackets on the line and the statement looks syntactically correct (optional pragma "soft semicolon", similar to the solution used in famous IBM PL/1 debugging compiler). That can help sysadmins who use bash and Perl in parallel and work from command line with vi or similar editors, and are not using such editors as Komodo Edit which flag syntax errors. If might make sense to enable this pragma only via option -d of the interpreter. In this case it will suit as a pure debugging aid, cutting the number of iterations of editing the source before actual run. It does not make much sense to leave statements without semicolons in the final, production version of the program. See, for example, the discussion in Stack Overflow Do you recommend using semicolons after every statement in JavaScript
... ... ...
johngg on Sep 12, 2020 at 13:46 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by johngg on Sep 12, 2020 at 13:46 UTCif we assume that somebody uses this formatting to suffix conditionalsI do, pretty much all the time! The ability to span a statement over multiple lines without jumping through backslash hoops is one of the things that makes Perl so attractive. I also think it makes code much easier to read rather than having excessively long lines that involve either horizontal scrolling or line wrapping. As to your comment regarding excessive length identifiers, I come from a Fortran IV background where we had a maximum of 8 characters for identifiers (ICL 1900 Fortran compiler) so I'm all for long, descriptive and unambiguous identifiers that aid those who come after in understanding my code.
Cheers,JohnGG
dsheroh on Sep 11, 2020 at 08:11 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 11, 2020 at 08:11 UTCyou !!! on Sep 13, 2020 at 21:25 UTC
Re^6: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 13, 2020 at 21:25 UTCIt might make sense to enable it only with -d options as a help for debugging, which cuts the number of debugging runs for those who do not have editor with built-in syntax checking (like ActiveState Komodo Editor; which really helps is such cases ).
That list includes most Linux/Unix system administrators, who use just command line and vi or similar. And they also use bash of daily basis along with Perl, which increases the probability of making such an error. And this is probably one of the most important category of uses for the future of Perl: Perl started with this group (Larry himself, Randal L. Schwartz, Tom Christiansen, etc) and after a short affair with the Web programming (yahoo, etc) and bioinformatics (bioperl) retreated back to the status of the scripting language of choice for the elite Unix sysadmins.
That does not exclude other users and applications, but I think the core of Perl users are now Unix sysadmins. And their interests should be reflected in Perl 7 with some priority.
BTW, I do not see benefits of omitted semicolons in the final program (as well as, in certain cases, omitted round brackets).
dave_the_m on Sep 11, 2020 at 10:37 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dave_the_m on Sep 11, 2020 at 10:37 UTC $a = $b + $c + $d + $e; [download] If not, what are the exact criteria for things on the next line to trigger or not a semicolon?Dave.
you !!! on Sep 11, 2020 at 14:20 UTC
Re^6: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 11, 2020 at 14:20 UTCIn the following, the first line has a balance of brackets and looks syntactically correct. Would you expect the lexer to add a semicolon?Yes, and the user will get an error. This is similar to previous example with trailing on a new line$a = $b + $c + $d + $e;if (1);
The first question is why he/she wants to format the code this way if he/she suffers from "missing semicolons" problem, wants to avoid missing semicolon error and, supposedly deliberately enabled pragma "softsemicolons" for that?
This is the case where the user need to use #\ to inform the scanner about his choice. But you are right in a sense that it creates a new type of errors -- "missing continuation." And that there is no free lunch. This approach requires specific discipline to formatting your code.
dave_the_m on Sep 11, 2020 at 14:52 UTC
Re^7: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dave_the_m on Sep 11, 2020 at 14:52 UTCThe reason I gave that code as an example is that it's a perfectly normal way of spreading complex expressions over multiple lines: e.g. where you need to add several variables together and the variables have non-trivial (i.e. long) names, e.g.
$pressure = $partial_pressure_nitrogen + $partial_pressure_oxygen + $partial_pressure_water_vapour + $partial_pressure_argon + $partial_pressure_carbon_dioxide; [download] In this case, the automatic semicolons are unhelpful and will give rise to confusing error messages. So you've just switched one problem for another, and raised the cognitive load - people now need to know about your pragma and also know when its in scope.Dave.
you !!! on Sep 11, 2020 at 16:51 UTC
Re^8: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 11, 2020 at 16:51 UTCYes it discourages certain formatting style. So what ? If you can't live without such formatting (many can) do not use this pragma. BTW you can always use extra parentheses, which will be eliminated by the parser as in
$pressure = ( $partial_pressure_nitrogen + $partial_pressure_oxygen + $partial_pressure_water_vapour + $partial_pressure_argon + $partial_pressure_carbon_dioxide );dave_the_m on Sep 11, 2020 at 17:05 UTC
Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dave_the_m on Sep 11, 2020 at 17:05 UTC* How exactly does the lexer/parser know when it should insert a soft semicolon?
* How exactly does it give a meaningful error message when it inserts one where the user didn't intend for there to be one?
My problem with your proposal is that it seems to require the parser to apply some complex heuristics to determine when to insert and when to complain meaningfully. It is not obvious to me what these heuristics should be. My suspicion is that such an implementation will just add to perl's already colourful collection of edge cases, and just confuse both beginner and expert alike.
Bear in mind that I am one of just a handful of people who actively work on perl's lexer and parser, so I have a good understanding of how it works, and am painfully aware of its many complexities. (And its quite likely that I would end up being the one implementing this.)
Dave.
you !!! on Sep 11, 2020 at 18:51 UTC
Re^10: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 11, 2020 at 18:51 UTCThe lexical analyser is Perl is quite sophisticated due to lexical complexity of the language. So I think it already counts past lexems and thus can determine the balance of "()", '[]' and "{}"
So you probably can initially experiment with the following scheme
If all the following conditions are true
- You reached the EOL
- Pragma "softsemicolon" is on
- The balance is zero
- [Edited] The last processed token in not ',', '.' '=' *and all derivatives like ++, -++),"=='( and other conditionals like <,>,!=, =<, <=.<=, eq,etc), ':','&','&&','!',"||",'+','-','*' or similar tokens which imply the continuation of the statement.
- [Edited] The next token (not symbol but token) via look-ahead buffer is not one of the set "{", "}", ';', and ".", "!!", "+"(but not "++") '-','*' and several others (see above).
the lexical analyser needs to insert lexem "semicolon" in the stream of lexem passed to syntax analyser.
The warning issued should be something like:
"Attempt to correct missing semicolon was attempted. If this is incorrect please use extra parenthesis or disable pragma "softsemicolon" for this fragment."From what I read, Perl syntax analyser relies on lexical analyser in some unorthodox way, so it might be possible to use "clues" from syntax analyser for improving this scheme. See, for example, the scheme proposed for recursive descent parsers in:Follow set error recovery C Stirling - Software: Practice and Experience, 1985 - Wiley Online Library Some accounts of the recovery scheme mention and make use of non-systematic changes to their recursive descent parsers in order to improve In the former he anticipates the possibility of a missing semicolon whereas in the latter he does not anticipate a missing commadave_the_m on Sep 11, 2020 at 22:02 UTC
Re^11: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dave_the_m on Sep 11, 2020 at 22:02 UTCSo I think it already counts past lexems and thus can determine the balance of "()", '[]' and "{}"It can't currently.If all the following conditions are trueAll of the following satisfy your criteria, are valid and normal perl code, and would get a semicolon incorrectly inserted based on your criteria: use softsemicolon; $x = $a + $b; $x = 1 if $condition; $x = 1 unless $condition1 && $condition2; [download]The warning issued should be something likeI didn't ask what the text of the warning should be, I asked how the parser can determine when the warning should be issued.the scheme proposed for recursive descent parsersBut perl uses an LR(1) parser, not a recursive descent parser.Dave.
you !!! on Sep 12, 2020 at 02:06 UTC
Re^12: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 12, 2020 at 02:06 UTCAll of the following satisfy your criteria, are valid and normal Perl code, and would get a semicolon incorrectly inserted based on your criteria:Yes in cases 1 and 2; it depends on depth of look-ahead in case 3. Yes if it is one symbol. No it it is two(no Perl statement can start with && )use softsemicolon; $x = $a + $b; $x = 1 if $condition; $x = 1 unless $condition1 && $condition2;As for "valid and normal" your millage may vary. For people who would want to use this pragma it is definitely not "valid and normal". Both 1 and 2 looks to me like frivolities without any useful meaning or justification. Moreover, case 1 can be rewritten as:
$x =($a + $b); [download] The case 3 actually happens in Perl most often with regular if and here opening bracket is obligatory: if ( ( $tokenstr=~/a\[s\]/ || $tokenstr =~/h\[s\]/ ) && ( $tokenstr... ) ){ .... } [download] 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; [download] should generally be written 2 $a=$b=1; 3 $x=1 if( $a==1 4 && $b=2); [download] I was surprised that the case without brackets was accepted by the syntax analyser. Because how would you interpret $x=1 if $a{$b}; without brackets is unclear to me. It has dual meaning: should be a syntax error in one case $x=1 if $a{ $b }; [download] and the test for an element of hash $a in another.dave_the_m on Sep 12, 2020 at 06:52 UTC
Re^13: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dave_the_m on Sep 12, 2020 at 06:52 UTCBoth 1 and 2 looks to me like frivolities without any useful meaning or justificationYou and I have vastly differing perceptions of what constitutes normal perl code. For example there are over 700 examples of the 'postfix if on next line' pattern in the .pm files distributed with the perl core.There doesn't really seem any point in discussing this further. You have failed to convince me, and I am very unlikely to work on this myself or accept such a patch into core.
Dave.
you !!! on Sep 12, 2020 at 19:53 UTC
Re^14: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 12, 2020 at 19:53 UTCYou and I have vastly differing perceptions of what constitutes normal perl code. For example there are over 700 examples of the 'postfix if on next line' pattern in the .pm files distributed with the perl core.Probably yes. I am an adherent of "defensive programming" who is against over-complexity as well as arbitrary formatting (pretty printer is preferable to me to manual formatting of code). Which in this audience unfortunately means that I am a minority.BTW your idea that this pragma (which should be optional) matters for Perl standard library has no connection to reality.
GrandFather on Sep 12, 2020 at 23:53 UTC
Re^15: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by GrandFather on Sep 12, 2020 at 23:53 UTCA very large proportion of the replies you have received in this thread are from people who put a high value on writing maintainable code. "maintainable" is short hand for code that is written to be understood and maintained with minimum effort over long periods of time and by different programmers of mixed ability. There is a strong correlation with your stance of "defensive programming" ... against over-complexity as well as arbitrary formatting . None of us are arguing with that stance. We are arguing with the JavaScript semicolon that you would like introduced based on a personal whim in a context of limited understanding of Perl syntax and idiomatic use.
Personally I use an editor that has an on demand pretty printer which I use frequently. The pretty printer does very little work because I manually format my code as I go and almost always that is how the pretty printer will format it. I do this precisely to ensure my code is not overly complex and is maintainable. I do this in all the languages that I use and the hardest languages to do that in are Python, VBScript and JavaScript because of the way they deal with semi-colons.
Oh, and in case it is of interest, dave_the_m is one of the current maintainers of Perl. He is in a great position to know how the nuts and bolts of an optional semi-colon change might be made and has a great understanding of how Perl is commonly used. Both give him something of a position of authority in determining the utility of such a change.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyondtobyink on Sep 12, 2020 at 22:24 UTC
Re^11: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by tobyink on Sep 12, 2020 at 22:24 UTC"no Perl statement can start with the dot"
Yada-yada operator in Perl 5.12+.
toby döt inkikegami on Sep 14, 2020 at 22:15 UTC
Re^12: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami on Sep 14, 2020 at 22:15 UTCParser lookaheads are implemented in terms of tokens, not characters. The first token of yada is a triple-dot, not a dot. While you may think it starts with a dot, that's not how the parser sees it, so the existence of yada is not relevant here.
Tux on Sep 12, 2020 at 09:38 UTC
Re^7: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Tux on Sep 12, 2020 at 09:38 UTCYou also completely ruin maintainability and extensibility. Consider a filter module ...
my $fixed = $bad =~ y/\x{00d0}/\x{0110}/r # Eth != D-stroke =~ y/\x{0189}/\x{0110}/r # LETTER AFRICAN D != + D-stroke =~ s{\bpra[ck]ti[sc]e\b}{practice}gr # All 4 seen in docume + nt AB12.38C =~ s{\bX13\.GtrA\.14\b}{X13_GA12}gr # Product got renamed =~ s{\b1234\s*zip\b}{1234ZIP}gir # Reciever will crash + on badly formed ZIP code =~ s{\bpays\s*-?\s*bas\b} {The Netherlands}gir # French forms :( =~ ....; [download]The more examples I see posted by my esteemed co-monks, the less I like the idea, and I hated it already when I read it in the OP.
Enjoy, Have FUN! H.Merijnyou !!! on Sep 13, 2020 at 19:48 UTC
Re^8: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 13, 2020 at 19:48 UTCAs 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.
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. It might be the easiest one to piss off, but it is far from being the most important or far reaching among those proposals.
There is no free lunch, and for some coding styles (including but not limited to coding styles used in many modules in Perl standard library) it is definitely inappropriate. Nobody claim that it is suitable for all users. It is an optional facility for those who want and need it. In a way, it is a debugging aid that allows to cut the number of debugging runs. 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.
Detractors can happily stay with the old formatting styles forever. Why is this so difficult to understand before producing such an example?
Moreover, how can you reconcile the amount of efforts (and resulting bugs) for the elimination of extra round brackets in Perl with this proposal? Is not this the same idea -- to lessen the possible number of user errors?
For me, it looks like a pure hypocrisy - in one case we are spending some efforts following other scripting languages at some cost; but the other, similar in its essence, proposal is rejected blindly as just a bad fashion. If this is a fashion, then eliminating round brackets is also a bad fashion, IMHO.
And why only I see some improvements possible at low cost in the current Perl implementation and nobody else proposed anything similar or better, or attempted to modify/enhance my proposals? After all Perl 5.10 was a definite step forward for Perl. Perl 7 should be the same.
I think the effort spend here in criticizing my proposal would be adequate to introduce the additional parameter into index function ("to" limit). Which is needed and absence of which dictates using substr to limit the search zone in long strings. Which is sub-optimal solution unless the interpreter has advanced optimization capabilities and can recognize such a use as the attempt to impose the limit on the search.
Constructive discussion does not mean pissing off each and every my posts ( one has -17 votes now; looks a little bit like schoolyard bulling ) -- you need to try to find rational grain in them, and if such exists, try to revise and enhance the proposal.
The stance "I am happy with Perl 'as is' and go to hell with your suggestions" has its value and attraction, but it is unclear how it will affect the future of the language.
johngg on Sep 13, 2020 at 22:49 UTC
Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by johngg on Sep 13, 2020 at 22:49 UTCAs 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; [download]should generally be written
2 $a=$b=1; 3 $x=1 if( $a==1 4 && $b=2); [download]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
dsheroh on Sep 14, 2020 at 08:09 UTC
Re^9: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 14, 2020 at 08:09 UTCIt 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.
ikegami on Sep 14, 2020 at 22:11 UTC
Re^7: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami on Sep 14, 2020 at 22:11 UTCYes, and the user will get an error.
Then your suggestion would break a very useful feature. So useful that I take advantage of it in virtually every one of my programs/modules.
haj on Sep 10, 2020 at 18:35 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by haj on Sep 10, 2020 at 18:35 UTCThat's neither a natural tendency nor an interesting psychological phenomenon. You just made that up.
Semicolons at the end of a statement are as natural as a full stop "." at the end of a sentence, regardless of whether the sentence is the last in a paragraph. The verification process whether a line "looks syntactically correct" takes longer than just hitting the ";" key, and the chances of a wrong assessment of "correct" may lead to wrong behavior of the software.
Language-aware editors inform you about a missing semicolon by indenting the following line as a continuation of the statement in the previous line, so it is hard to miss.
If, on the other hand, you want to omit semicolons, then the discussion should have informed you that you aren't going to find followers.
you !!! on Sep 10, 2020 at 21:20 UTC
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 10, 2020 at 21:20 UTCSemicolons at the end of a statement are as natural as a full stop "." at the end of a sentence, regardless of whether the sentence is the last in a paragraph.I respectfully disagree, but your comment can probably explain fierce rejection of this proposal in this forum. IMHO this is a wrong analogy as the level of precision requred is different. If you analyse books in print you will find paragraphs in which full stop is missing at the end. Most people do not experience difficulties learning to put a full stop at the end of the sentence most of the time. Unfortunately this does work this way in programming languages with semicolon at the end of statement. Because what is needed is not "most of the time" but "all the time"My view, supported by some circumstantial evidence and my own practice, is that this is a persistent error that arise independently of the level of qualification for most or all people, and semicolon at the end of the statement contradicts some psychological mechanism programmers have.
haj on Sep 11, 2020 at 00:41 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by haj on Sep 11, 2020 at 00:41 UTCIf you analyse books in print you will find paragraphs in which full stop is missing at the end.You are still making things up.
..and semicolon at the end of the statement contradicts some psychological mechanism programmers have.There is no evidence for that.
You should have understood that your idea doesn't get support here. Defending it with made-up evidence doesn't help.
Anonymous Monk on Sep 11, 2020 at 15:14 UTC
Re^6: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Anonymous Monk on Sep 11, 2020 at 15:14 UTCdsheroh on Sep 11, 2020 at 08:07 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 11, 2020 at 08:07 UTCBecause people have a natural tendency to omit them at the end of the line.Fascinating. I've never heard of, nor observed, such a tendency. Might you provide references to a few peer-reviewed studies on the topic? I don't necessarily need URLs or DOIs (although those would be most convenient) - bibliographic citations, or even just the titles, should be sufficient, since I have access to a good academic publication search system.Offhand, the only potentially-related publication I can locate is "The Case of the Disappearing Semicolon: Expressive-Assertivism and the Embedding Problem" (Philosophia. Dec2018, Vol. 46 Issue 4), but that's a paper on meta-ethics, not programming.
you !!! on Sep 11, 2020 at 16:38 UTC
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 11, 2020 at 16:38 UTCLiterature is available for free only to academic researchers, so some money might be involved in getting access.
You can start with
A statistical analysis of syntax errors - ScienceDirect For example, approximately one-fourth of all original syntax errors in the Pascal sample were missing semicolons or use of comma in place of semicolon 4) indicates that this type of error is quite infrequent (80o) and hence needn't be of as great a concern to recovery pro PDF Error log analysis in C programming language courses BOOK Programming languages JJ Horning - 1979 - books.google.com to note that over 14% of the faults occurring in topps programs during the second half of the experiment were still semicolon faults (compared to 1% for toppsii), and that missing semicolons were about Every decision takes time, and provides an opportunity for error n assessment of locally least-cost error recovery SO Anderson, RC Backhouse, EH Bugge - The Computer , 1983 - academic.oup.com sym = semicolon in the former, one is anticipating the possibility of a missing semicolon; in contrast, a missing comma is 13, p. 229) if sy = semicolon then insymbol else begin error(14); if sy = comma then insymbol end Both conditional statements accept semicolons but the The role of systematic errors in developmental studies of programming language learners J Segal, K Ahmad, M Rogers - Journal of Educational , 1992 - journals.sagepub.com Errors were classified by their surface characteristics into single token (missing gathered from the students, was that they would experience considerable difficulties with using semicolons, and that the specific rule of ALGOL 68 syntax concerning the role of the semicolon as a Cited by 9 Related articles Follow set error recovery C Stirling - Software: Practice and Experience, 1985 - Wiley Online Library Some accounts of the recovery scheme mention and make use of non-systematic changes to their recursive descent parsers in order to improve In the former he anticipates the possibility of a missing semicolon whereas in the latter he does not anticipate a missing comma A first look at novice compilation behaviour using BlueJ MC Jadud - Computer Science Education, 2005 - Taylor & Francis or mark themselves present from weeks previous they may have missed -- either way change programmer behaviour -- perhaps encouraging them to make fewer "missing semicolon" errors, or be or perhaps highlight places where semicolons should be when they are missing Making programming more conversational A Repenning - 2011 IEEE Symposium on Visual Languages , 2011 - ieeexplore.ieee.org Miss one semicolon in a C program and the program may no longer work at all Similar to code auto-completion approaches, these kinds of visual programming environments prevent syntactic programming mistakes such as missing semicolons or typosdsheroh on Sep 12, 2020 at 13:20 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 12, 2020 at 13:20 UTCLiterature is available for free only to academic researchers, so some money might be involved in getting access.No problem here. Not only do I work at an academic library, I'm the primary responsible for the proxy we use to provide journal access for off-campus researchers. All the benefits of being an academic researcher, with none of the grant proposals!A statistical analysis of syntax errors - ScienceDirectThe first thing to catch my eye was that the abstract states it found that syntax errors as a whole (not just semicolon errors) "occur relatively infrequently", which seems to contradict your presentation of semicolon problems as something which constantly afflicts all programmers.Going over the content of the paper itself, I couldn't help noticing that a substantial fraction of the semicolon errors discussed were in contexts idiosyncratic to Pascal which have no Perl equivalent, such as the use of semicolons to separate groups of formal parameters (vs. commas within each group); using semicolon after END most of the time, but a period at the end of the program; or incorrectly using a semicolon before ELSE. Aside from being idiosyncratic, these situations also have the common feature of being cases where sometimes a semicolon is correct and sometimes a semicolon is incorrect, depending on the context of the surrounding code - which is precisely the major criticism of your "make semicolons sometimes optional, and escaping line breaks sometimes required, depending on the context of the surrounding code". The primary issue in these cases is that the rules change based on context, and you've proposed propagating the larger problem in an attempt to resolve a smaller problem which, it seems, only you perceive.
I also note that the data used in this research consisted of code errors collected from two university programming classes, one of which was an introductory course and the other a relatively advanced one. It is to be expected that semicolon errors (particularly given the Pascal idiosyncrasies I mentioned above) would be common in code written for the introductory course. It would be interesting to see how the frequency compared between the two courses; I expect that it would be much, much lower in the advanced course - and lower still in code written by practicing professionals in the field, which was omitted entirely from the study.
Oh, and a number of other comments in this discussion have mentioned using syntax-aware editors. Did those even exist in 1978, when this paper was published? Sorry, I'm just being silly with that question - the paper mentions card decks and keypunch errors, and says that the students were asked to "access [the compiler] using a 'cataloged procedure' of job control statements". These programs weren't entered using anything like a modern text editor, much less one with syntax awareness. (I wasn't able to find a clear indication of whether the CDC 6000 Series, which is the computer these programs were compiled on, would have used a card reader or a keyboard for them to enter their code, but I did find that CDC didn't make a full-screen editor available to time-sharing users on the 6000 series until 1982, which is well after the paper's publication date.)
A first look at novice compilation behaviour using BlueJYep, this one indeed found that missing semicolons were the most common type of compilation error at 18%, with unknown variable name and missing brackets in a dead heat for second place at 12%. Of course, it also found that the median time to correct and run another compile was only 8 seconds after getting a missing semicolon error, so hardly a major problem to resolve.Also, once again, as even stated in the title of the paper, this was limited to code written by novice programmers, taking a one-hour-a-week introductory course, so it seems misguided to make assertions about the semicolon habits of experienced programmers based on its findings.
Making programming more conversationalThe only mentions of semicolons in this document are " Miss one semicolon in a C program and the program may no longer work at all. " and " Instead of typing in text-based instructions, many visual programming languages use mechanisms such as drag and drop to compose programs. Similar to code auto-completion approaches, these kinds of visual programming environments prevent syntactic programming mistakes such as missing semicolons or typos. " While these statements confirm that semicolons are important and that programmers can sometimes get them wrong (neither of which has been in dispute here), they make no attempt to examine how commonly semicolon-related errors occur. Given that the purpose of this paper was to introduce a new form of computer-assisted programming rather than to examine existing coding practices, I doubt that the authors even considered looking into the frequency of semicolon errors.I was not able to locate the remaining papers you mentioned by doing title or author searches using Ebsco's metasearch tools.
Tux on Sep 10, 2020 at 08:52 UTC
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
- Highly desirable Make a semicolon optional at the end of the line
Highly un desirable. If things to be made optional for increased readability, not this, but making braces optional for singles statement blocks. But that won't happen either.- Highly Questionable Introduce pragma that specify max allowed length of single and double quoted string
Probably already possible with a CPAN module, but who would use it? This is more something for a linter or perltidy.- Highly desirable Compensate for some deficiencies of using curvy brackets as the block delimiters
Unlikely to happen and very un undesirable. The first option is easy } # LABEL (why introduce new syntax when comments will suffice). The second is just plain illogical and uncommon in most other languages. It will confuse the hell out of every programmer.- Make function slightly more flexible
a) no b) Await the new signatures c) Macro's are unlikely to happen. See the problems they faced in Raku. Would be fun though- Long function names
Feel free to introduce a CPAN module that does all you propose. A new function for trimming has recently been introduced and spun off a lot of debate. I think none of your proposed changes in this point is likely to gain momentum.- Allow to specify and use "hyperstrings"
I have no idea what is to be gained. Eager to learn though. Can you give better examples?- Put more attention of managing namespaces
I think a) is part of the proposed OO reworks for perl7 based on Cor , b) is just plain silly, c) could be useful, but not based on letters but on sigils or interpunction, like in Raku</lI.- Analyze structure of text processing functions in competing scripting languages
Sounds like a great idea for a CPAN module, so all that require this functionality can use it- Improve control statements
Oooooh, enter the snake pit! There be dragons here, lots of nasty dragons. We have has given/when and several switch implementations and suggestions, and so far there has been no single solution to this. We all want it, but we all have different expectations for its feature sets and behavior. Wise people are still working on it so expect *something* at some time.
Enjoy, Have FUN! H.Merijnyou !!! on Sep 10, 2020 at 16:57 UTC
Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 10, 2020 at 16:57 UTC Reputation: -4Because }:LABEL actually forcefully closes all blocks in between, but the comment just informs you which opening bracket this closing bracket corresponds to. and, as such, can placed on the wrong closing bracket, especially if the indentation is wrong too. Worsening already bad situation.
Been there, done that.
dsheroh on Sep 11, 2020 at 08:18 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 11, 2020 at 08:18 UTCYour "one brace to close them all" idea is not needed if you have a decent editor - and, incidentally, would most likely break this feature in many/most/all editors which provide it.
you !!! on Sep 11, 2020 at 16:45 UTC
Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 11, 2020 at 16:45 UTC Reputation: -5Highly desirable Make a semicolon optional at the end of the lineHighly undesirable. If things to be made optional for increased readability, not this, but making braces optional for singles statement blocks. But that won't happen either.Making single statement blocks is a programming language design blunder made in PHP. It creates the so called "dangling else" problem.
BTW, if this is "highly undesirable", can you please explain why Perl designers took some efforts to allow omitting semicolon before closing brace?
Tux on Sep 12, 2020 at 09:24 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Tux on Sep 12, 2020 at 09:24 UTCI cannot answer the why in that question, but the only place where *I* use it on a very regular basis is
my @foo = map { $_->[0] } sort { $a->[1] <=> $b->[1] } map { m/^(.*(\d+).*)$/ } @bar; [download]Which works evenly fine when semi-colons are added.
Following the complete discussion, I wonder why you persist. To me it is obvious that Perl is not (or should not be) your language of choice.
If you really think trailing semi-colons should be omitted, do find a language that allows it. You have come up with exactly ZERO arguments that will convince the other users of perl and perl language designers and language maintainers.
To me however, all the counter-arguments were very insightful, so thank you for starting it anyway.
/me wonders how many users would stop using perl completely if your rules would be implemented (wild guess 90%) and how many new users the language would gain (wild guess 1%)
Enjoy, Have FUN! H.Merijnikegami on Sep 14, 2020 at 22:38 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami on Sep 14, 2020 at 22:38 UTCcan you please explain why Perl designers took some efforts to allow omitting semicolon before closing brace? >
Because it's unambiguous, and because it allows one to treat it as a statement separator (like the comma) instead of statement terminator .
Getting rid of the others would cause countless ambiguities.
|
|
|
Sep 15, 2020 | perlmonks.org
alexander_lunev on Sep 10, 2020 at 09:02 UTC
Perl use and abuse of curvy brackets dicussionMaking Perl more like modern Python or JS is not improvement to language, you need another word for that, something like "trends" or "fashion", or something like that. I see this list as a simplification of language (and in a bad way), not improvement. As if some newby programmer would not want to improve himself, to get himself up to match the complexity of language, but blaim language complexity and demand the language complexity to go down to his (low) level. "I don't want to count closing brackets, make something that will close them all", "I don't want to watch for semicolons, let interpreter watch for end of sentence for me", "This complex function is hard to understand and remember how to use it in a right way, give me bunch of simple functions that will do the same as this one function, but they will be easy to remember".
Making tool more simple will not make it more powerful, or more efficient, but instead could make it less efficient, because the tool will have to waste some of its power to compensate user's ineptitude. Interpreter would waste CPU and memory to comprehend sentence ending, this "new" closing brackets and extra function calls, and what's gain here? I see only one - that newby programmer could write code with less mind efforts. So it's not improvement of language to do more with less, but instead a change that will cause tool do same with more. Is it improvement? I don't think so.
you !!! on Sep 10, 2020 at 16:52 UTC
Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 10, 2020 at 16:52 UTC Reputation: -7As if some newby programmer would not want to improve himself, to get himself up to match the complexity of language, but blaim language complexity and demand the language complexity to go down to his (low) level.The programming language should be adapted to actual use by programmers, not to some illusions of actual use under the disguise of "experts do not commit those errors." If the errors committed by programmers in the particular language are chronic like is the case for semicolons and missing closing brace something needs to be done about them, IMHO.
The same is true with the problem of "overexposure" of global variables. Most programmers at some point suffer from this type of bugs. That's why "my" was pushed into the language. But IMHO it does not go far enough as it does not distinguish between reading and modifying a variable. And "sunglasses" approach to visibility of global variable might be beneficial.
BTW the problem of missing parentheses affects all languages which use this "{" and "}" as block delimiters and the only implementation which solved this complex problem satisfactory were closing labels on closing block delimiter in PL/1 ("}" in Perl; "begin/end" pair in PL/1). Like with "missing semicolon" this is the problem from which programmer suffer independently of the level of experience with the language.
So IMHO any measures that compensate for "dangling '}' " problem and provide better coordination between opening and closing delimiters in the nested blocks would be beneficial.
Again the problem of missing closing brace is a chronic one. As somebody mentioned here the editor that has "match brace" can be used to track it but that does not solve the problem itself, rather it provides a rather inefficient (for complex script) way to troubleshoot one. Which arise especially often if you modify a long and not written by you (or written by you long go) script. I experienced even a case when syntactically { } braces structure were correct but semantically wrong and that was detected only after the program was moved to production. Closing label on bracket would prevent it.
choroba on Sep 10, 2020 at 17:10 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by choroba on Sep 10, 2020 at 17:10 UTCIf you write short subroutines, as you should, you don't suffer from misplaced closing curly braces. I had problems with them, especially when doing large edits on code not written by me, but the editor always saved me.
Both puns intended.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]Fletch on Sep 10, 2020 at 19:27 UTC
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Fletch on Sep 10, 2020 at 19:27 UTCMore or less agree WRT mismatched closing curlies. I see it pretty much entirely as an editor issue.
(I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping? At least I recall that ("Your editor will keep it straight") being seriously offered as a valid dismissal of the criticism against S-W-A-G . . .)
The cake is a lie.
The cake is a lie.
The cake is a lie.
you !!! on Sep 10, 2020 at 21:37 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 10, 2020 at 21:37 UTCI mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping?No the argument is different, but using indentation to determine block nesting does allow multiple closure of blocks, as a side effect. Python invented strange mixed solution when there is an opening bracket (usually ":") and there is no closing bracket -- instead indent is used as the closing bracket.The problem is that it breaks too many other things, so here the question "whether it worth it" would be more appropriate, then in the case of soft semicolons.
dsheroh on Sep 11, 2020 at 08:27 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by dsheroh on Sep 11, 2020 at 08:27 UTCAs somebody mentioned here the editor that has "match brace" can be used to track it but that does not solve the problem itself, rather it provides a rather inefficient (for complex script) way to troubleshoot one. Which arise especially often if you modify the script.I would submit that, if you have enough levels of nested blocks that "match brace" becomes a cumbersome and "inefficient" tool, then your problem is that your code is overly-complex and poorly-structured, not any issue with the language or the editor. Good code does not have 47-level-deep nested blocks.atcroft on Sep 12, 2020 at 00:23 UTC
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by atcroft on Sep 12, 2020 at 00:23 UTCGood code does not have 47-level-deep nested blocks.... 43 ... 44 ... 45.<humor> *whew* Made it with 2 to spare. Glad you said "47-level-deep nested blocks".
Wait, there was one more conditi...</humor> :D :)
|
|
|
Sep 15, 2020 | perlmonks.org
ikegami on Sep 14, 2020 at 22:21 UTC
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffExtend last to accept labels
last already accepts labels.
implement "post loop switch"
That's horrible. Noone uses continue since it doesn't give access to the lexical vars of the loop, and this suffers from the same problem.
See Donald Knuth Structured Programming with go to Statements programming with goto statements
Perl already has a goto statement.
That said, while I use goto regularly in C, there's no reason to use it in Perl.
|
|
|
Sep 15, 2020 | perlmonks.org
ikegami on Sep 14, 2020 at 22:30 UTC
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffAs extracting of substring is a very frequent operation
It's actually quite rare to want to extract a substring by position.
Implement tail and head functions as synonyms to substr ($line,0,$len) and substr($line,-$len)
Nothing's stopping you from doing that right now.
likbez on Sep 15, 2020 at 04:12 UTC
Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by likbez on Sep 15, 2020 at 04:12 UTC Reputation: -1Yes, you can do it with certain limitations and the loss of flexibility as a user function. The key question here is not whether "you can do it" -- but how convenient it will be in comparison with the "status quo", are key categories of users benefit directly from this addition (for Perl first of all whether sysadmins will benefit), and what is the cost -- how much trouble is to add it into the already huge interpreter, which inevitably increase already large number of built-in functions. As well as whether "in the long run" new functions can retire same "inferior" functions like chomp and chopImplement head and tail functions as synonyms to substr ($line,0,$len) and substr($line,-$len)Nothing's stopping you from doing that right now.NOTE: it is better to call them ltrim and rtrim.
With chomp, which is far more frequently used out of two, replacing it by rtrim is just a renaming operation, with chop you need some "inline" function capability (macrosubstitution). So rtrim($line) should be equivalent of chomp($line) --assuming that "\n" is the default second argument for rtrim)
Also any user function by definition has more limited flexibility in comparison to the built-in function and is less efficient unless implemented in C.
Without introduction of additional argument for a user-defined function it is impossible to determine if the function ltrim has target or not (if not, it should modify the first parameter.
So on user function level you need to have two functions: ltrim and myltrim ), as it this case the second argument has a more natural meaning.
On use defined function level you have quite limited capabilities to determine the lexical type of the second argument (at run time in Perl you can only distinguish between the numeric type and the string -- not that regex is passed, or translation table is passed. Actually some languages allow to specify different entry points to the function depending on the number and type of arguments (string, integer, float, pointer, etc) passed. In Perl terms this looks something like extended signatures:
sub name { entry ($$){ } entry (\$\$){ } } [download]A couple of examples:
The call ltrim($line,7) should be interpreted as
$line=substr($line,7)
but the call $header=ltrim($line,'<h1>'); obviously should be interpreted as
$header=substr($line,index($line,'<h1>');
Also if you want to pass regex or translation table you need somehow to distinguish type of the last argument passed. So instead of the function call
$body=ltrim($line,/\s*/); you need to use
$body=ltrim($line,'\s*','r'); which should be interpreted as
if ($line=~/^\s*(.+)$/) { return $1; } [download]the same problem arise if you want to pass a set of characters to be eliminated like in tr/set1//d;
$body=ltrim($line," \t",'t'); # equivalent to ($body)=split(' ',$line,1);
One argument in favor of such functions is that in many languages the elimination of free space at the beginning and end of strings is recognized as an important special case and built-in function provided for this purpose. Perl is one of the few in which there is no such special operation.
|
|
|
Sep 15, 2020 | perlmonks.org
ikegami on Sep 14, 2020 at 22:27 UTC
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staffAllow default read access for global variables, but write mode only with own declaration via special pragma, for example use sunglasses.
You can do this already. But it doesn't make sense to do this instead of creating accessors.
Allow to specify set of characters, for which variable acquires my attribute automatically, as well as the default minimum length of non my variables via pragma my
There's a lot of problems with this. But hey, if you want this, there's nothing's stopping from writing a module that provide this "feature".
|
|
|
Sep 15, 2020 | perlmonks.org
Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by likbez on Sep 10, 2020 at 16:52 UTC...BTW the problem of missing parentheses affects all languages which use this "{" and "}" as block delimiters and the only implementation which solved this complex problem satisfactory were closing labels on closing block delimiter in PL/1 ("}" in Perl; "begin/end" pair in PL/1). Like with "missing semicolon" this is the problem from which programmer suffer independently of the level of experience with the language.
So IMHO any measures that compensate for "dangling '}' " problem and provide better coordination between opening and closing delimiters in the nested blocks would be beneficial.
Again the problem of missing closing brace is a chronic one. As somebody mentioned here the editor that has "match brace" can be used to track it but that does not solve the problem itself, rather it provides a rather inefficient (for complex script) way to troubleshoot one. Which arise especially often if you modify a long and not written by you (or written by you long go) script. I experienced even a case when syntactically { } braces structure were correct but semantically wrong and that was detected only after the program was moved to production. Closing label on bracket would prevent it.
choroba on Sep 10, 2020 at 17:10 UTC
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by choroba on Sep 10, 2020 at 17:10 UTCIf you write short subroutines, as you should, you don't suffer from misplaced closing curly braces. I had problems with them, especially when doing large edits on code not written by me, but the editor always saved me.
Both puns intended.
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Fletch on Sep 10, 2020 at 19:27 UTCMore or less agree WRT mismatched closing curlies. I see it pretty much entirely as an editor issue.
(I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping? At least I recall that ("Your editor will keep it straight") being seriously offered as a valid dismissal of the criticism against S-W-A-G . . .)
The cake is a lie.
The cake is a lie.
The cake is a lie.
you !!! on Sep 10, 2020 at 21:37 UTC
Re^5: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by you !!! on Sep 10, 2020 at 21:37 UTCI mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping?No the argument is different, but using indentation to determine block nesting does allow multiple closure of blocks, as a side effect. Python invented mixed solution when there is an opening bracket (usually ":") and there is no closing bracket -- instead the change in indent is used as the proxy for the presence the closing bracket.The problem is that it breaks too many other things, so here the question "whether it worth it" would be more appropriate, then in the case of soft semicolons or "reverse labels on "}" like "}LABEL" .
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: September 27, 2020
