3 ms·
The problem there of course (migrating to Perl 6) is also finding matching packages for the _huge_ list we presently use. I can also only imagine the fallout fr
by tech2 10y ago
The problem there of course (migrating to Perl 6) is also finding matching packages for the _huge_ list we presently use. I can also only imagine the fallout from various issues like places we may have accidentally used the outcome of a dualvar accidentally, or other interesting side-effects of Perl 5.
6 Looks just fine as a language, but it really does feel like a completely new language which means it's less a migration and more a re-write. Which then leads to the question: if we're going to re-write, should it still be Perl?
- berntb 10y agoCome on, don't exaggerate -- dualvar has to be explicitly imported and used. (I've never seen it in the wild, I have no clue what Perl::Critic says? Edit: pbp has nothing to say about them?) And I'm not touching the "Perl 6" naming discussion. There is inlining for using Perl 5 libraries in Perl 6, which smoothen the road. But it is a hard start to motivate projects in a new language, which is incrementally better. I would be happy to try.
- tech2 10y agoDualvars come up naturally. Treat a number as a string (try using Data::Dumper on some scalars) and suddenly your json ends up coming out like: {"something": "12"} rather than {"something": 12} Just because both slots are filled with the same "value" in perl, doesn't mean it's _not_ a dualvar. It's just a side-effect of the way scalars in Perl work.
- berntb 10y agoOf course. But I get your our point -- this is a corner that might bite you. It don't happen to me often, but I sprinkle "+ 0" and so on, without thinking about it.