101–110 of 127 posts
For someone using Perl 5 as a replacement for bash scripting, is it worth making the jump to Perl 6? P.S. Why not name this language something new? -- Nicklaus Wirth didn't name Modula-2 Pascal 2.
And that was a big marketing mistake. Do you think C++ would have been anywhere near as successful if it had been called Z?
Do the changes to the regular expression syntax seem woefully under-publicized here? Was: $str =~ m/^\d{2,5}\s/i Now: $str ~~ m:P5:i/^\d{2,5}\s/ # :P5 indicates Perl5-compatibile regex syntax Was: $str =~ s/(a)/$1/e; Now: $str ~~ s:P5/(a)/{$0}/; # $1 is now $0 I actually find the change from $1 to $0 particularly disturbing, since that is well standardized and group 0 normally refers to the whole matched pattern (tho…
Earlier quoted context omitted.
1. Can't argue with this. 2. With Inline::Perl5[1] this should be a non-issue. The short code snippet in the README at the github repo referenced should give you the idea. 3. Having not been released yet, Perl 6 has zero history on backwards compatibility, so there's no way to assess whether it's relatively better or worse than Perl 5. That said, I don't necessarily support the original statement that Perl 6 is a sup…
> Having not been released yet, Perl 6 has zero history on backwards compatibility, so there's no way to assess whether it's relatively better or worse than Perl 5. Well, uh, it's not backwards-compatible with Perl 5. Yes, yes, I know, "It's a different language." So why is it called "Perl 6?" The name is very much designed to tell us "this is the one after Perl 5." Insisting that everyone evaluate it as a greenfield…
It is the one after 5, in that sense.
The naming is not perfect but it is, at this point, a little late to do anything about that.
Earlier quoted context omitted.
Perl6 is at least as good as Perl5 for everything Perl5 is good at. No. It is not. Don't believe me? Here is a short list of classic selling points for Perl 5 that Perl 6 clearly loses on. 1. Performance. Back in the 1990s, Perl hit a sweet spot of being quick for development while still being fast enough for a wide variety of tasks. It still performs reasonably well versus other scripting language. Every time I look…
1. Can't argue with this. 2. With Inline::Perl5[1] this should be a non-issue. The short code snippet in the README at the github repo referenced should give you the idea. 3. Having not been released yet, Perl 6 has zero history on backwards compatibility, so there's no way to assess whether it's relatively better or worse than Perl 5. That said, I don't necessarily support the original statement that Perl 6 is a sup…
This is a whole new language, and should probably be called Larry, or something.
Earlier quoted context omitted.
Ah, sorry. Despite having used Perl for years, I'd forgotten how much emphasis it puts on concepts that invoke a high cognitive load.
On the contrary, I think there is a higher cognitive load in having to reason about the behavior that results from using the + operator between two types when their types may differ. e.g., the Wat talk[1]. To be clear, there is a cognitive load to both. One is based on keeping correct type of the variables you are using with the + operator, the other is knowing that numeric addition and string concatenation are not t…
The simple fact that you run out of operators limits how many types can usefully exist. In Python you use + quite reasonably for integers, floats, strings, and arrays. By contrast raw Perl has equivalents only for numbers and strings, and is unable to distinguish between integers and floats. That is why Perl doesn't do exact arithmetic with large integers.
But, you say, Perl allows you to use bigint? Well, yes. And that is internally implemented with the magic of overload. Using that you can have any number of types which overload + to do what they want, and you have all of the same issues as arose in the Wat talk.
It took a long time for me to be convinced, but I am now convinced that typed variables and untyped operators (like Ruby and Python do) is strictly better in practice than untyped variables and typed operators (like Perl does by default). And as for the complexity, it is just something you have to live with.
Want evidence? https://mitpress.mit.edu/sicp/full-text/sicp/book/node48.htm... discussed this exact problem some 30 years ago. I do not believe that the intrinsic problem is being solved any better today than then.
Earlier quoted context omitted.
1. Can't argue with this. 2. With Inline::Perl5[1] this should be a non-issue. The short code snippet in the README at the github repo referenced should give you the idea. 3. Having not been released yet, Perl 6 has zero history on backwards compatibility, so there's no way to assess whether it's relatively better or worse than Perl 5. That said, I don't necessarily support the original statement that Perl 6 is a sup…
But Perl 5 was (and still is) backwards compatible with Perl 4. This is a whole new language, and should probably be called Larry, or something.
A good faith effort was made for compatibility. But it was not perfect. Hence http://www.perl.com/doc/FMTEYEWTK/perl425.html was created to let people know where the problems were.
Everything is a reference! Nice!
Earlier quoted context omitted.
But Perl 5 was (and still is) backwards compatible with Perl 4. This is a whole new language, and should probably be called Larry, or something.
Not quite true! A good faith effort was made for compatibility. But it was not perfect. Hence http://www.perl.com/doc/FMTEYEWTK/perl425.html was created to let people know where the problems were.
Everything is a reference! Nice!
Not really if you car about efficiency.
>any two valid identifiers may be joined with a single ' to form a longer identifier Oh no.
It gets worse. "Hey, let's double down on weak typing!": http://examples.perl6.org/categories/cookbook/01strings/01-0... print +"" ; # a num-ified empty string evaluates as 0 print "1" + 1 ; # 2 The opportunity for insidious bugs (for the benefit of not having to type 'int("1") + 1' those times when you really need to do that) is a terrible tradeoff, in my opinion. In before "but Python...!". Python is strongly typed…
You're thinking of JavaScript in this particular issue.