Hi, I'm willing to marshal the next release of PDL.[0]
PDL needs to keep going while its future successor is developed and planned.[1] While PDLA is promising, it's not a simple drop-in replacement, and perhaps shouldn't be. To move PDL into its proper place in the Perl ecosystem[2] requires a lot of work. Splitting it into chunks as Ed has done with PDLA is a start, but in my opinion it needs to go further than that. PDL library organization isn't obvious, we have internal namespace collisions (does everything really need to be a method on a PDL object?), there's no proper C API (e.g. documented, and callable from non PP-generated C code). We need to make it so easy to interface and work with PDL that all of the non-PDL numeric code on CPAN becomes obsolete. While I don't find PP code to be horrible, there's no doubt that it's not user friendly. We need to change that. We also need tighter integration with NumPy, Julia, and R so that we can leverage those ecosystems without horrendous overhead. There's a lot we can do to modernize the existing code base to make a transition easier. Most of it starts with documenting and adding tests, so that we can be sure we don't break things as we move along. The thorniest work will be dealing with Core and PP. There's a lot of undocumented behavior and a bit of cargo-culting in there which needs to be teased out. CPAN is the wild west, and there are PDL modules there which may conflict with a consistently designed PDL library ecosystem. We need to reserve the PDL namespace for the "official" ecosystem and have a separate namespace for contributions outside of it. Namespace pollution is a significant problem that we have to deal with. I'll take some time this weekend to draft my ideas on modernizing the code. [0] My credentials are that I've been using Perl and PDL for a long time, I'm happy to dive into C code, and I've made a few contributions to PDL over the years. My CPAN contributions are here: https://metacpan.org/author/DJERIUS [1] I'm not quite convinced Perl6 is ready for numerics, and Perl5 is still a viable language. Not to mention lots of code using PDL is out there! [2] It's frustrating to see projects on CPAN which should use PDL but don't. PDL doesn't have the same visibility as does NumPy in the Python world, and we need to change that. _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
