111–120 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.
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?
Earlier quoted context omitted.
perl5 is a language name - its current release is version 22. I presume perl6 will be doing similarly.
mst as one of the biggest perl5 proponents are you planning to switch to perl6? 1. yes 2. no 3. maybe 4. will use both
So (4), but what percentage of each that'll end up being in the long run I've no idea.
Earlier quoted context omitted.
It seems "disturbing" is the good word here, as the kind of changes in the semantics or notation between Perl 5 and Perl 6 almost guarantees that most potential users would have to decide if they are going to reject using one or another: The need to "read differently" on the distant look similar code demands too much from the people who'd just like to "get the job done." What's that $1? Well it's the first match if i…
don't use $1, use named captures or list assignment. qr/\$\d+/ is a oneliner thing or a code smell.
Earlier quoted context omitted.
Is there a Perl 5 EOL being discussed? Or, if Perl 5 and Perl 6 really are two completely separate languages separated by a similar syntax, then what comes after Perl 5 in the Perl 5 language? Will it forever be 5.N, 5.N+1, ...? (And, I guess, will there forever be 6.N, 6.N+1, ...?)
Its ridiculous to imagine any EOL for Perl 5, given how large that ecosystem is. Co existence is the way forward. I think a good deal of Perl 6 features will seep into Perl 5 over time, while maintaining backwards compatibility.
while perl6 is truely a new languages not an upgrade to perl5
perl5 devs for a while have been under pressure to make perl5 more popular, using a popular language adds a padding of security, a cushion, perl5 devs are surely hungry for this
and if you like perl5 you will love perl6 as they seem to share the same values both languages that are syntax heavy, and languages that work the way you do, instead of forcing you to think a certain way .. like say functional languages
Perl6 is probably the complete opposite of say .. Haskell, but I believe in a good way ... it will be popular, i think it will be an agile language .. and many devs will love the flexibility
Earlier quoted context omitted.
Perl6 is really a strict supserset of Perl5 in this way. Perl6 is at least as good as Perl5 for everything Perl5 is good at. But Perl6 is way, way more than that.
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…
Yeah, performance sucks for Perl 6. Simple reason - first make it work, then make it fast. It's just been announced like yesterday that there's gonna be beta releases before the first stable release.
My money is performance will get better between now and Perl 6, v1.
Earlier quoted context omitted.
There is nothing "high cognitive load" about having different operators for addition and concatenation. I think it's simpler.
Who "adds two strings"? You're 1) converting the strings to ints 2) adding the ints. The possibility of confusion is the part that is already complex.
$timeText = $systemHours . ':' . $systemMinutes;
vs
$durationTimer = $userInputHours + 1;
There ya go.
Earlier quoted context omitted.
In Perl 5, for and foreach have been aliases for eachover for a very, very long time. # perl -E 'foreach (my $i=0; $i I never use foreach in Perl 5, and that's what I'm paid to write in. This is just a reaffirming that "for" is the preferred syntax (and this isn't a TMTOWTDI thing, this is two reserved words for the exact same code construct thing). Moose, interestingly enough, is based on backporting the then-propos…
Though to be fair, for the last year or so, every time I've needed to hack on a p5 script for $work, my first step has been to convert it to p6. It usually is pretty quick for 50-100 line scripts, and generally it's a lot easier to reason about changing the code once it's in p6.
Do you have/write test suites? In P5? P6?
Have you seriously tried any of the p5-to-p6 translators with your scripts?
Was the usage message typically much-improved, about-the-same, or needs-work after your first successful compile?
Same question for command line argument binding?
Any speed stories? Scripts that started unacceptably slow but eventually got there? Ones that beat their Perl 5 originals? Ones that didn't really make it yet?
Have you converted any of your Perl 6 conversions back in to Perl 5 code (to retain the clarity developed in the conversion to 6 but regain the speed that Perl 5 has)?
Do any of your conversions use Perl 5 modules?
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…
On #1 we agree. We don't agree on #2. Inline::Perl5 is better than I would expect, but there is still an issue. For example, Perl 6 uses garbage collection instead of reference counting so modules like http://search.cpan.org/dist/ReleaseAction/lib/ReleaseAction.... no longer work like they did in Perl 5. (Yes, that module is used in production code. And I happen to know of several independent re-creations of the same…
That said, your complaint in #2 was about Perl 6 losing to every other language in library support, but I think we've established it's nowhere near as bad as that. It's not perfect, but it's definitely not barren. There's a few tens of thousands of modules Perl 6 can try to use, and there's a fairly good way of knowing if they will work or not, since most have good tests.
Your original complaint for #3 was also about companies needing to rewrite all their code. I think Inline::Perl5 goes a long way towards addressing that as well. It's not perfect, but when considering "Their primary motivation for staying on Perl is that they don't want to rewrite their code. Perl 6 requires a rewrite of their code." I think it affects that point of view.
I think you have somewhat valid points, I just don't think they are nearly as solid as initially presented.
To reuse the recent slogan, the only thing that changed is everything. It's a new language with its own internal logic. I used (and still use) Perl 5 because it made some specific things easy to make (various processing of data). I still don't know for which kind of tasks Perl 6 is the best choice. But maybe the language is simply too young for it to be obvious?
Earlier quoted context omitted.
don't use $1, use named captures or list assignment. qr/\$\d+/ is a oneliner thing or a code smell.
It's not a smell if you are doing an asston of text munging. Rather than write one ginormo regex I prefer a sequence of short actions. It's easier to debug and reason with.