Front page | perl.perl5.porters |
Postings from February 2014
On Fri, Feb 21, 2014 at 10:09:56AM -0500, Konovalov, Vadim wrote: > > From: Nicholas Clark [mailto:nick@flirble.org] On Behalf Of Nicholas Clark > > And we don't even know if it works, because no-one working on the core > > has access to these systems, and no-one with these systems is providing > > reports. > > As I said before, situation isn't that hopeless: there is emulator (Hercules) > I successfully tried that on my linux, ran z/OS there, have success story. > but I haven't tried to build perl there yet. > > > We don't have infinite developer resources. (It's rather closer to 0 than > > infinity.) So everything is a trade off, and effort being consumed by this > > means that something else isn't being done. So effectively EBCDIC support > > is stealing progress from the rest of the Perl userbase. > > Given that developer resources are indeed finite, these should be not wasted, > so throwing away current UTF-EBCDIC is a serious step back. > > Speaking about resources distractions, there will always be many. > > Please let Perl for z/OS and hence UTF-EBCDIC be there for some more while. From the point of view of developer resources, existing EBCDIC code is a sunk cost. From that perspective it makes no difference whether it stays or goes. For future developer resources, continuing to support EBCDIC is not a sunk cost. It costs more to support it than to remove it. Its presence, as I said, effectively steals from everything else. And it's a sham to say that we are "supporting" EBCDIC when we don't even have any test results to know what works and what does not. So, as Ricardo said, unless regular EBCDIC smoking starts soon, we WILL be removing EBCDIC code soon after 5.20.0 ships. On this matter, actions speak louder than words. Nicholas ClarkThread Previous | Thread Next