Important to note that postfix dereferencing is experimental, and does not replace the existing method of dereferencing.
Also, I think the deprecation of core CGI.pm is pretty major. For now it just issues a deprecation warning, but will be removed totally from core in future versions, only being available via the CPAN.
You install one of the many modules from CPAN, i.e. Plack, Dancer, Mojolicious, CGI. The only change is that an old module that has way too much badly implemented functionality has been set on the path towards removal from the default Perl installation.
Perl 5.20.0 represents approximately 12 months of development
since Perl 5.18.0 and contains approximately 470,000 lines of
changes across 2,900 files from 124 authors.
Definitely. And as I have lamented in several places online, as well as verbally in discussions about it, I really love Perl, the language, despite its warts. (For example, I view the slurpy subroutine argument style to be an advantage, if used correctly, rather than a wart; that said, having the option of formal parameters would be nice...)
I think we are well past the point now where the language itself is no longer the center of the discussion. Or should not be. What we have is a single back end that's difficult to work on, and which can only target one platform. It's compiled C. Naturally, that's not so bad, as we see Perl is everywhere that Linux is. Which is ... basically everywhere.
But how about a Perl 5 interpreter for the JVM? How about a Perl 5 to Javascript compiler (sort of like Clojurescript)? Or just any other target you can imagine. I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it.
"Kill it," of course, is a relative term. Perl 5 will most likely never truly die. Indeed, I'm writing (what I think is pretty cool) Perl 5 code right at this moment, and putting it on Github and CPAN.
But in terms of attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening. To me, it's a great sadness. I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point).
I like Perl 6 (P6). I would like Perl 5 folk pondering P5's internals or its future to properly investigate and understand P6's role.
> how about a Perl 5 interpreter for the JVM?
In the opening few minutes of Patrick Michaud's 2013 video "Perl on the JVM", he notes that Jesse Vincent suggested "Perl 6 is Perl's best (only?) hope for running on JVM/.NET".
> I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it.
There's been a serious effort to clean up the internals in recent years. But yeah, part of the point of P6 was to develop much better internals.
Rakudo and the NQP compiler toolchain are not only well designed but also almost entirely written in P6 code. (Counting NQP as P6.)
> attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening.
Even in the face of its disastrous reputation, P6 still manages to attract new blood. Aiui the guy who writes the P6 weekly news (http://p6weekly.wordpress.com/) contributed to the Python core before getting in to P6. This year I've seen smart kids visit #perl6 for the first time, chat knowledgeably about a lisp or ML, and start to contribute. Some well known P5 folk such as Nicholas Clark (one of the few folk ever paid by TPF to hack on the P5 internals) and lizmat have fully turned their focus toward P6 in the last year or so.
> I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point).
What about hanging out on #perl6 for a while (prime time is about 8am thru 8pm EST, 7 days a week) to chat with folk and see what there is to see?
I hope I'm being helpful. There's definitely a glass half full / half empty dilemma with talking about P6.
Let me now include a standard caveat list I created last year in an attempt to ensure balance in the force:
"Perl 6 is not remotely as usable and useful as Perl 5; it has dozens of users, not millions; it is 100-1000x slower than Perl 5 for a lot of stuff; the P6 documentation is immature and incomplete; the spec has not reached 6.0.0; the Rakudo compiler has not fully implemented what's already in the spec; most of the concurrency and parallel implementation has only just begun; P6 can not currently use CPAN modules; Perl 6 has syntax and semantics that are not backwards compatible with Perl 5; Perl 6 culture is -Ofun which some think is incompatible with getting things done; some folk think that Perl 6 code looks like line noise... In summary, there are infinitely many things wrong with P6."
I hope that hasn't brought you down to earth with too big a bump.
Try Scala. It's a very expressive language that does not sacrifice on power (JVM/type safety).
As a long time professional Perl programmer, I've given up on it. The heartache it has caused on enterprise teams I've been on is not worth the rise in blood pressure. And I'm starting to think that it is inefficient in its yield per unit of effort ratio. Writing good, scalable, clean, modern Perl requires so much couching and qualifying. My teammates couldn't even write good Perl. And so despite my want of evangelizing it, pitching to younger programmers is probably not useful/efficient.
Aiui folk who love Perl tend to have a natural affinity for Scala. Stevan Little (the Moose and P5 MOP guy) chose Scala for Moe and I'm pretty sure he enjoyed it.
I'm in to P6. ionforce, please indulge/educate me:
> {Scala|P6 is} a very expressive language that does not sacrifice on power (JVM/type safety).
I hope you see where I'm coming from and are willing to play ball. :)
First and foremost, P6 is incomplete, immature, slow, etc. and almost no one is using it to do anything serious. Aiui Scala is used in a wide range of production settings. This is likely the end of any comparison for most folk.
Scala runs on the JVM. Aiui there's no attempt or intent to run it on anything else. Rakudo (P6) runs on the JVM. It also runs on other VMs including MoarVM. See http://moarvm.org
Scala can "seamlessly" call Java code and vice-versa. Rakudo/JVM can call Java code, but it's currently ugly looking. Java code should be able to call P6 code using Rakudo/JVM but the necessary work isn't complete.
Aiui Scala has solid concurrency and parallelism features. P6 has a good story regarding the language's design as it relates to concurrency and parallelism, but implementation only began last year. See http://jnthn.net/papers/2014-nlpw-reactive.pdf for some of the best Rakudo currently has to offer concurrency-wise.
Scala does type inferencing and you can add explicit types. Its type hierarchy is Java's. P6 also does type inferencing with optional explicit types. But it's type hierarchy is not the same as Java's.
Scala has traits, pattern matching, and higher order functions. So does Rakudo.
> But no, I'm not bitter. =)
Of course not. There's more than one way to do it. :)
> The "interpreter-based threads" provided by Perl are not the
> fast, lightweight system for multitasking that one might expect
> or hope for. Threads are implemented in a way that make them
> easy to misuse. Few people know how to use them correctly or
> will be able to provide help.
That's too bad; I know that threads were very unstable and buggy, but I wish they had been improved them instead of considering them "to have been mistakes".
Also on the unfortunate side, CGI.pm has been deprecated and will need to be installed from CPAN.
On a happier note, IO::Socket::IP has been added; which finally gives Perl built-in IPV4/IPv6 parity (i.e. one module that can do the jobs of both IO::Socket::INET and IO::Socket::INET6).
> That's too bad; I know that threads were very unstable and buggy, but I wish they had been improved them instead of considering them "to have been mistakes".
No snark: Patches welcome. There have been people who tried to implement better threads for Perl ( https://metacpan.org/release/threads-tbb , https://metacpan.org/release/threads-lite ). However the task is such a monumentally difficult one, that unless you have considerable ressources available (Java, Go), you're unlikely to get a very good implementation of them (Python, Perl). Perl being entirely volunteer-developed means that there currently simply is nobody with both the knowledge, and the available time, to do this. If you think you can do it, or know someone who can, please by all means give it a try.
The biggest change is the move towards deprecating ascii-related functions:
Use of any of these functions in the POSIX module is now deprecated: isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, and isxdigit
these are going to be littered throughout most perl code - its definitely in a lot of my code.
I read a lot of files of very raw textual data and if the parsed data tastes good, it gets stored in a DB for analysis, if not, kicked out as error.
Its going to be fun watching people who do used the POSIX functions try alternatives. /[A-Za-z]/, I'd like you to meet umlat-u. The POSIX depended on the locale of the installed software which, assuming that's a feature and not a bug (usually its a bug) it'll be interesting to watch people reimplement that "functionality".
This is a fun 13 year old place to start WRT "simple" data verification, not because it exhaustively covers everything, but its watching a noob start from the beginning and hit about ten different roadblocks. There are plenty more of course.
'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"...
This is what makes people run way from Perl nowadays. I recently tried to convince someone that Perl is superior to PHP. When he saw the sub and $_ and shift he was like "I'm not touching this with a ten foot pole".
And there was nothing I could say. Compared to something like PHP 5.4, Perl looks like "mildly evolved stone age shell scripting with some chinese characters in it".
And I say this saddened because I still wish PHP wouldn't have won the "battle for the web" over Perl.
> 'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"...
That is an understandable, yet still naive statement. In the implementation of signatures one has to make MANY decisions concerning the trade-offs of syntax, available features and performance impacts of signatures. The discussions about what was needed and wanted for those experimental signatures were massive and in no way trivial.
Further, asking a PHP person to evaluate another language is often fruitless, as their lifelihood is usually closely tied to that language; and they are largely unaware of the systemic ailments plagueing PHP, thus unable to draw a useful comparison.
Wow, what happened between paragraphs 1 and 2? You went from making a good point to insulting a whole class of people. I’m no fan of PHP, but I could hardly bring myself to insult everyone who uses it...
Simply put, i've been in this business since 2001, have done 3 years of PHP myself, and have never met a PHP programmer who liked PHP and wasn't an exact fit of the description i gave. For a time there even was a PHP developer who i thought was very good, but that judgement turned out to be borne of my ignorance when that person turned out to be unwilling and uncapable to consider the advantages of automated testing. Some people might not like to hear this, but over a decade of experience has convinced me that this is sad and simple fact. The post i was responding to tried to use the reactions of a PHP programmer to make a factual statement about Perl without even attempting to consider the possibility that said programmer might be both not experienced enough, and inherently unwilling to accept Perl as even being good.
I was not aiming to insult, though some might certainly feel offended, but explain why the poster above failed to make a useful point.
which is annoying boilerplate I agree, but actually pretty regular. [You mean language xxx has two different ways to declare subroutine lexical vars?]
The people who want to hate perl will continue to hate it.
After the list of reasons they dislike it are resolved, they'll come up with new ones and/or point to "it's not popular enough" (while simultaneously embracing a brand new language which is significantly less popular).
After the list of reasons people dislike it are resolved, it won't be Perl. It's fine to start calling a modern language Perl, even though the modern language has standard syntax that no current Perl programmer would consider Perl, and standard computer science constructs like OOP and Unicode etc that require coding against a different abstraction than Perl. Nothing wrong with that. But the new Perl would have as little to do with the old Perl as an iPad has with an Apple ][.
It would not be the same language in any meaningful sense, beyond branding.
I'm serious in the sense that some of the extreme syntax-sugar and leniency, more than one way to do it, etc, that Perl is loved for are the reasons that people dislike it in a modern context, and these are to simply be removed with no equivalent replacement.
If you move toward a readable standard "Perl" that supports (only) modern coding styles, you will have something that old Perl users wouldn't really recognize as Perl.
This is "Perl" and recognized as such... but my suggestion of calling some entirely different language Perl in the future would make this essentially a non-script. The same is true for most syntax, as well as a large amount of fundamental structures, regexes, etc.
I'll speak following my analogy: I'll call Perl the Apple ][ and some language that wouldn't be recognized as Perl by today's Perl users, but which should be called Perl in the future I will call the iPad.
For example, it's fairly clear that the iPad language should have every single variable be a full object. The Apple ][ does not force this. Likeweise, classes and OOP would not be optional on an iPad, but a fundamental part of writing any program. But on the Apple ][ it is optional. On the iPad it is clear that $_ would be meaningless and not used, ever. It's a syntax error.
On the iPad all source code is UTF-8 or Unicode, and all built-in standard operators including the iPad version of a regular expression (which uses almost none of the syntax of the Apple ][ language natively operate on UTF-8 or Unicode.
The iPad language is longer and has more explicit, longer keywords. The syntax itself is extremely orthogonal and you could describe the entirety of it to anyone who has programmed in any language in a relatively low number of slides, and they can just start coding. It is fully readable to someone who has never read the iPad language, i.e. if you were to read a numerical algorithm or datamining algorithm that was just talked about in a textbook, you wouldn't be distracted by the textbook having to explain what the iPad is. It speaks for itself.
This explicitness is part of the language; there is no way to write one-liners or extremely concise hacks the way the Apple ][ could.
The iPad language lives on the web. It has primitives for handling a client connection as well as a standard framework for rich client-side connections. A persistent connection over http is as everyday as standard input and standard output was on the Apple ][.
And boy can you Google this. The Apple ][ could have a syntactic structure, special variables [1] that were almost impossible to Google. All sorts of Context.
The iPad language has no such context. There is very little you can set to change the fundamental syntax, no way to change the default index on arrays and related things, or any such high-context things or syntactic context. There is just one context, and everything that is done in a program is spelled-out and eminently Google-able. You never have to ask what something actually does, on a syntactic level, or figure it out by running it. You don't have to spend even six days to get to this level at the language: an afternoon tells you all the context that you will ever need. Anything beyond that, you can Google.
Sure, you may not understand what a piece of code does on a higher level. What happens if you apply a fourier transform to _____. It may not be obvious.
But syntactically, it is extremely easy to read off what you're doing. No more difficult than reading off pseudocode in a textbook.
And the language is succinct. The basic syntax is so small, so orthogonal, that you can be handed a 20-page description, having never seen an iPad language, and be able to more or less implement a version in the language of your choice, in a few weeks, without any further information or context. There is not a lot of magic involved.
Of course, the only thing that the iPad language will have in common with the Apple ][ is just the brand (Perl)..or the fact that at some level they're both turing-complete.
The future of Perl is calling an iPad language that is unrecognizable to any current user of Perl, Perl.
Gone are the days of syntactic sugar or short little idioms.
I think you're constructing a strawman and then having a few swipes at it.
Perl evolved into it's "new form" some time ago. Modern Perl came out 5 years ago and was really just codifying best practice at the time.
It's still the same language if you want it to be. Backwards compatability is taken very seriously. Which - yes - does mean that you can write crappy old perl in it if you want to. (And also that all the crappy old perl you have lying around will continue to work).
But it's also a pretty vibrant, modern language. Any new project or new perl codebase can and should be written in modern perl. And - despite your assertions - it's still very much the same language.
(Not a straw man, I wasn't writing ironically or derisively about anything, but rather made a genuine suggestion to break "apple ][" code - referring to current Perl - with a totally modern and incompatible "iPad" language - referring to a future usage of the brandname without any common technology - that has absolutely nothing in common with the former, whatsoever. Nothing.)
So I am actually making the opposite point, that it shouldn't be the same language. I don't think the new form is new enough, I wouldn't call it the iPad of my analogy. In particular, I am also saying that "the iPad shouldn't run Apple ][ code". (at all.) Nearly all Apple ][ code shoudl be a syntax failure on the iPad. Including even $_. Every syntactical element should behave differently, minimally. Much simpler syntax with very little sugar. Much more verbose.
Basically a totally different language should be whitebranded with the brand currently worn by this language. People who used that language shouldn't recognize this language. People who use this language, shouldn't be able to understand that language. They shouldn't have anything in common.
The two things should have literally as much in common as the Apple ][ does with an iPad, which is nigh-unto nothing.
You say, "it's still the same language if you want it to be", but that is a problem. It is like saying you can still pull a jumbo jet with a horse if you want to. No, you shouldn't be able to pull a jumbo jet with a horse at all, a jet just shouldn't support acting as a cab. It should fail to move forward. The horse should give up. The horse in this case is Ascii. It should never even be hitched to it.
Nothing should remain of Perl but the brand, and that they're both turing-complete, just as the intersection between an iPad and an Apple ][ is the null set (plus the fact that they're both physical objects, and a few similar superficial similarities that would apply to every computing device / programming language.)
I think you really don't know what Perl 6 is, and are incorrectly inferring from some statements here that you "can run perl 5 code in perl 6" what that means, and what it's purpose is (library support, utilizing the massive amount of CPAN modules that already exist).
Perl 6 is not Perl 5, in the same way an iPad isn't still an Apple ][.
Other than that, the main problem I see is you taking a lot of opinion on what you think are good language features and transposing those desires onto "people" who decide what a modern language is. Many of those ideas are based in opinion, or in a language philosophy that is orthogonal to Perl's guiding philosophies, which are very strong and influenced it's design very much.
I think you're talking about other people's comments, not mine. I realize that you might be used to talking with those people, but it doesn't really have much to do with what I write. My statements have more or less nothing to do with Perl. (Please let that sink in.)
As far as my "understanding" of Perl 6. According to
"The Perl 6 standard grammar is written in Perl 6, and specifies how a Perl 6 program is parsed.
The source code can be found on github in the perl6/std project in the file STD.pm6."
token old_rx_mods {
<!after \s>
(\w+)
{
given $0.Str {
$_ ~~ /i/ and $¢.worryobs('/i',':i');
$_ ~~ /g/ and $¢.worryobs('/g',':g');
$_ ~~ /m/ and $¢.worryobs('/m','^^ and $$ anchors');
$_ ~~ /s/ and $¢.worryobs('/s','. or \N');
$_ ~~ /x/ and $¢.worryobs('/x','normal default whitespace');
$_ ~~ /c/ and $¢.worryobs('/c',':c or :p');
$_ ~~ /e/ and $¢.worryobs('/e','interpolated {...} or s{} = ... form');
$_ ~~ /r/ and $¢.worryobs('/c','.subst');
$_ ~~ /a/ and $¢.worryobs('/a','Unicode');
$_ ~~ /d/ and $¢.worryobs('/d','Unicode');
$_ ~~ /l/ and $¢.worryobs('/l','Unicode');
$_ ~~ /u/ and $¢.worryobs('/l','normal regex');
$_ ~~ /p/ and $¢.worryobs('/c','substr or /$<PREMATCH>=[...] <(...)> $<POSTMATCH>=[...]');
$¢.obs('suffix regex modifiers','prefix adverbs');
}
}
}
or
my @t = grep { substr($_.Str,0,2) ne '::' }, @$t;
>Perl 6 is not Perl 5, in the same way an iPad isn't still an Apple ][.
It's true that "an iPad isn't still an Apple ][" but I specifically chose those two examples because they have nothing in common. Whether someone has ever used one wouldn't affect their ability to use the other in any way, they are in no sense in the same 'family'. Nothing in common but the brand.
Perl 5 and Perl 6 are clearly in a same general family.
Your final paragraph is extremely fair. Perhaps I should state that I don't know much about why other people don't/wouldn't choose Perl as the first language to do a dynamic web site in in 2018 if they need to pick some language up. It is fair to state that I'm just expressing my own opinion.
I think the problems with your argument boil down to a few thigs:
1) You seem to be making an argument for some future language. That it would drop many of the things the make Perl Perlish is presupposed as what "people" would want. It would keep the name, as you state, because it would be the same community of people. The community of people that would keep the Perl name are not the same "people" you refer to that after their complaints are fixed would result in a Perl that is not Perlish.
2) If you are just talking about some abstract future language not actually related to Perl, don't use the Perl name. All you are doing is getting people riled up because you are attributing views to them (as the actual Perl community) that they disagree with. Again, I think this can be attributed to you taking a more abstract approach to what you are saying, but choosing to use concrete names, such as Perl, and doing so in the comments of an article about a new Perl release. People here would likely engage you gladly if it was obvious it's just a thought experiment about some futuristic language with nothing to do with Perl, including the name (although there would be challenges as to what you believe are the best features for this new language).
3) You presuppose it's a solved question of what's "best" for specific language features. For example, longer more explicit keywords, very simple to explain, very easy to read by a someone who doesn't know it. These are all good things when you try to maximize learning by novices. One could argue that at the same time, they don't really even allow experts. We have domain languages because they allow us to be more concise and accurate in our definitions. This necessitates learning the domain language, but I think few would argue that the hassle outweighs the future benefit to chemists, physicists, lawyers, engineers and architects to learn the specifics of the domain languages and representations they've developed. As a simple example, look at Ten Hundred Words of Science[1]. I admit it's probably useful to get laymen to understand a topic in general, but is it always sufficient to explain the specifics of that topic in the precise way it requires? Should experts in the field converse with each other this way? Should new bodies of work attempt to use this in the future instead of the domain languages they have developed? It's important to see these for what they are, tools used to shift focus towards or away from specific attributes. It's all a matter of perspective and what the goal is.
This is very good, though this thread is a bit old and deep. Your italicized part ("Again, I think this can be attributed to you taking a more abstract approach to what you are saying, but choosing to use concrete names, such as Perl, and doing so in the comments of an article about a new Perl release.") made me laugh :)
You are possibly right, though I was just making an off-hand remark and only just clarified when prompted explicitly. I think the 90 words / 4 lines I wrote originally were fine, and if someone asks for clarification no reason not to include it. In general I don't think an article on a new version of Perl is a bad place for such thoughts.
I like your comments, especially, on domain specific languages, though as mentioned the thread is a bit old and deep to continue here. I couldn't find an email but if you reply with one I'm happy to discuss. Your tenhundredwordsofscience is a really good example of how it gets awkward not to use specialist vocabulary. I like your analogy with chemists, physicists, lawyers, engineers, and architects. The former two especially use specialist symbols that are impenetrable to total laypersons. anyway if you have an email I'll respond to your good points.
Hi, tried to email you. You'd written "k e n t r a k # google's mail" but kentrak@google.com (the only way I could think of interpreting that) bounced. (I don't mind including it here as Google's server says that mailbox doesn't exist).
Kind of ironic given our conversation :-) Could you bit a bit more explicit ;-)
@google.com is for people who work at google, @gmail.com is what I meant, as "google's email service". I agree, it wasn't very clear, but I don't particularly want harvesters having an easy time.
wow, how bizarre. I could have sworn I sent it to a gmail address, I thought that it was obvious you meant gmail, and even after your reply I thought "well yeah of course I sent it to gmail, that part was obvoius" and thought I must have just mistyped it here, but sent correctly in my sent mail. It's weird that I actually did send it to @google.
The thing is that I must have just carefully been doing character transliteration, changing your #, removing spaces, etc, to deobfuscate and @google didn't end up looking wrong enough! Sorry. Sent to the correct (and obvious) email.
BTW the fact this happened is just too good, given the subject! I forgot to dereference a literal in a string. :)
The point was not your analogy. The point was that you made wild claims about something you obviously have no clue about.
(That is why you write so damn much text about something else. Standard behavior for non serious people that are shown to be wrong.)
And the environment changes for everything in computing. Perl is extensible. The use is very different today compared to e.g. before the millennium before testing took over.
So go troll on some subject you know.
(Perl 6 is a different language in the same family. Quite a few features have been backported.)
"Be civil. Don't say things you wouldn't say in a face to face conversation. When disagreeing, please reply to the argument instead of calling names. E.g. "That is an idiotic thing to say; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them."
As for trolling, at the moment I have four and a half times your karma and am engaging in civil discourse. Try to do the same.
You missed a serious implication with the fact that I'm writing about 'something else'. Which is that what I'm writing about has nothing to do with your language wars. Complaining that I would be wrong if I weren't writing about something else is similar to complaining that an obituary you have read shows extremely shoddy reporting, since a) you're alive, b) they got your birth date, gender, occupation, family history, professional history, and name wrong. They're clearly writing about someone else. Well, yes. I'm actually not part of your language war.
I actually haven't made a single claim about Perl, nor rehashed any arguments.
I explained what features I think a totally new language should have, and that the Perl community should start branding a totally new language as Perl, without starting out from Perl in any way. (As radically new as the iPad is to an Apple ][). It's my opinion.
Without any compatibility or sense of being Perl in any other sense, just like there is zero continuity or compatibility between an Apple ][ and an iPad.
Yes, I agree with you that Perl 6 is a different language in the same family. Perl 6 isn't a candidate for the language that I think should bear Perl branding in the future.
In summary, I like the Perl community and want it to work on some other language and call it Perl. I've given a high-level description of some of the features that I think such a language should have.
My main point is that you could brand anything you want as Perl. It doesn't have to still be Perl to be called Perl. If you disagree, that's fine, but you can't disagree with me for not writing about what you would like me to.
>>I've flagged your post for your last sentence before your parentheses.
Which were that you made wild claims about stuff you obviously know nothing.
>>I actually haven't made a single claim about Perl
:-)
In the same comment you make explicit claims about what is part of "real" Perl and what is not:
>>My main point is that you could brand anything you want as Perl. It doesn't have to still be Perl to be called Perl.
(Quite fun, considering that programmable language extensions have been on CPAN (/in the Perl binary) for lots of years!)
Originally, I reacted to this claim about what is "real" Perl:
>>even though the modern language has [..] standard computer science constructs like OOP and Unicode etc that require coding against a different abstraction than Perl.
That is not [ignorant] claims about Perl?! (There are more examples.)
Again:
The Perl Unicode support is one of the best of the scripting languages -- and todays std OO (Moo[se]) is arguably better than the other scripting languages.
And OO has been in Perl 5 since the start (1990s).
TL;DR: 1. TRIVIALLY bad claims. 2. Long messages without touching the bad claims. 3. "I never made any claims at all".
In case it was an honest mistake, I was referring to "So go troll on some subject you know". Your way of parsing my reference as referring to your second sentence is extremely bizarre, though possible if you were hasty.
If every variable is a reference to an object, that would be a different abstraction from Perl. "The modern language" refers to my hypothetical language which has nothing to do with Perl.
My entire post refers to something hypothetical, which is why you state that it was written about 'something else'.
We are not arguing, and I'm not making any claims about Perl.
I am talking about a hypothetical language in which writing any normal Perl fails with a syntax error.
>>In case it was an honest mistake, I was referring
You wrote "I've flagged your post for your last sentence before your parentheses."
Which was what I discussed. (I did have a 2nd parenthesis, too.)
>>I'm not making any claims about Perl.
I quoted you twice as saying two old language features, which are probably best among the std scripting languages, goes against being Perl. At least one of those features is from the 1990s.
That might mean something different than making claims, but you have carefully not touched it, despite multiple opportunities (while being both called "troll" and down voted over that).
I've flagged this as well, for your argumentative style, specifically that you write:
>despite multiple opportunities while being both called "troll" and down voted over that
This style of discussion is not normal here. Nobody but you has called me a troll, because that goes against our community guidelines. Please read the guidelines.
Until then you will not receive more replies from me. If you pay a bit of attention you will note that this community is much more civil than you may be used to from elsewhere.
("But why??" - I hope if you give it some thought you can appreciate the broader context that there is insight to be gained from discussion, as shown by congresses of minds from Athens to the Royal Society, from the Continental Congress to the National Academy of Sciences, all of which have shown that amazing things can be borne of civil discourse.
Whether you think you have anything to gain from anyone else's opinion is up to you to decide. Engaging in name-calling, cheap argumentative tricks (as repeated here), and willful misinterpreting is not up to you.
Please read the guidelines and contribute or ask honest questions, rather than attack. You are very welcome to express a differing opinion, of course, as long as it is done in civil terms.)
You are called troll because of stupid statements on basic points.
You refuse to talk about WHY you are stamped a troll in multiple comments -- instead you complain in big blocks of text about impoliteness!
This is a common troll strategy, but does it really work?
Do a causal reader miss that you refuse to talk about why you are called troll -- and just see two people complaining about each others?
Edit: So your smoke screen of complaints will change my behavior. :-) The next troll with your strategy will just get a note that he refuses to touch why he is called troll + link.
I did talk about why you (and only you, a user with 239 karma, less than a quarter of mine) called me a troll - it's because you don't understand our guidelines and civil discourse. This style of discourse is frowned upon by this community and YC employs a full-time moderator (dang) just to make sure nobody like you is doing this where anyone is reading. He and others are doing a really good job, and you won't see a single comment like yours in any thread.
If you have any questions about the comments I actually made you can write politely to yc tech mgr @ gmail.com
The fourth time I write this, THEN you claim to have answered!
Strange that you forgot to link, troll...
I am just going to note that in five^H^H^H^H six^H^H^H seven comments you carefully avoid discussing how I motivate that you are a bad troll: https://news.ycombinator.com/item?id=7809359
Sigh, I'll just note that you missed yet another opportunity to explain your strange statements that some of Perl 5's older and stronger features are not Perly.
(You even quoted part of my comment where I discussed that.)
But it is informative with indignation, while repeatedly refusing to discuss criticism.
You were excited in 1996-Feb-29 when 5.002 was released? Also, prototypes are widely used as syntax hints for the perl compiler and were never meant as signatures.
This deprecation affects things like $\cT, where \cT is a literal control
(such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code.
Surprisingly, it appears that originally this was intended as the
canonical way of accessing variables like $^T, with the caret form only being
added as an alternative.
I love perl and use it nigh-unto daily, but—what could possibly have been the thought process behind that? A literal control character?
If you try to use and output ^O while thinking you're outputting a literal control-O then you'll be in for a big surprise.
The language allows (length) 250 or so character variable names with few restrictions, so using single character names is probably a bug or at least bad style, so when the devs are looking for a class of global "internal-ish" variable names, how about those icky single character names that no one should be using? So that's how you end up with $^V being aliased to a string representation of the version of perl interpreter currently executing. You really shouldn't be using single character variable names so they've been repurposed and attempting to re-re-purpose them might be very exciting.
Yes. Its a running joke WRT general global variables, and they all have a single character synonym. And once you use up the preferred letters, well, stranger things are used.
a C programmer who understands command line argument lists would not even remotely be surprised at the contents of the general variable $0. Its probably more "civilized" to call it $PROGRAM_NAME in your code, but whatever. I don't think this is controversial to alias $PROGRAM_NAME to $0 for anyone civilized aka some minimal C experience.
Perl tends to be consistent. In a similar style, if you insist on implementing a global general variable like $PERL_VERSION which contains a string of pretty much what it sounds like it contains, to keep things consistent all general vars also have a single character synonym, so welcome to $"control-V"
In the "real world" you can write something stupid enough to get yourself fired. This kind of activity probably qualifies unless you have an excellent excuse. Perhaps if you have a complicated if-then statement with numerous clauses and using one individual weird, yet short, variable name allows a debugging programmer to keep the whole control flow in their head instead of scrolling the mess off the screen, then, maybe, its a win. But I wouldn't make a habit of it.
Given that you can pretty much transparently "upgrade" or "downgrade" the code with a simple search and replace its not a major crisis.
A lot of people use Perl::Critic as a Perl "lint" and a lot of those users put large amounts of the perlvars file in the Variables::ProhibitEvilVariables test although the Perl::Critic authors don't by default include them, which many people consider a bug in Perl::Critic but whatever.
> Its probably more "civilized" to call it $PROGRAM_NAME in your code, but whatever. I don't think this is controversial to alias $PROGRAM_NAME to $0 for anyone civilized aka some minimal C experience.
$0 (along with $1 etc.) is used in shells, at least bash [and original sh?]. I think Perl just borrowed those, like $ prefixes to variables or not offering explicit subroutine arguments, from the traditional unix shell(s).
Linking yegge is quite pointless, since even in that little screed he demonstrates amply how he doesn't even know the basics of Perl and in fact knows so little that his judgement isn't worth the bytes that store it.
From traditional UNIX shells, by way of awk. perl was originally written as a fancier version of awk (to the point that, until recently, it came with a utility "a2p" that translated awk source code to perl), so that's where it got the variables.
From the perlfunc manpage, about the return values of Perl's operators and functions in scalar versus list context: In general, they do what you want, unless you want consistency.
