3 ms·
It sounds to me like you would like a "batteries included" version of Perl 6. (include JSON/YAML in the runtime) No. We only include things as part of the lang
by b2gills 10y ago
It sounds to me like you would like a "batteries included" version of Perl 6. (include JSON/YAML in the runtime)
No. We only include things as part of the language where the design of it is immediately obvious, and is useful for many applications. It also helps if it has been proven in other languages. So Promises(Futures) are in there, but many other things are not. You can do anything in a module, so write an external module for it instead.
Otherwise we would have the problems where the best module for the job is not in the runtime, but everyone uses the one that is in the runtime.
I have heard that Python has this problem with HTTP. Think of it like this, a module for doing X is included with the first version of a language. That means it is a module that was not written by an expert, because at that point in time there was no expert in the language. Everyone uses it though; as you don't have to install it, because it is already there.
We don't have an official module manager, because we want all of them to be equally as official as every other one. It is a good thing too; as most people in the know use zef currently, rather than panda. If we had one that was official, it would have been panda.
That's also why there is not, nor will ever be an official implementation. Any implementation that passes the test suite is just as official as every other one. (although there is only one currently)
Basically you are asking for things to be included, that are specifically not included for very good reasons. The way that this is dealt with is by using the idea of distributions like "Rakudo Star" for Perl 6, or "Strawberry Perl" for Perl 5 on windows. That is an implementation of Perl 6 along with a set of useful modules.
- woodruffw 10y agoFirst of all, thanks for responding. I understand the hesitation of language maintainers with respect to adding complex modules like JSON and YAML, but I do think that there are some major benefits to doing so: * Users don't have to worry about inconsistent distributions. Following a test suite is one thing, but test suites are (almost) never comprehensive and will not catch programmer errors with respect to particular systems (e.g, LP64 and LLP64). Everything will work until it doesn't, and programmers will have to provide edge-case workarounds until individual distributions fix their implementations. The same goes for module managers. It's good to provide an open spec and encourage multiple frontends, but it's also good to provide a uniform interface for system administrators who just want to automate module installation for an application or framework. Python's easy_install wasn't ideal, but it provided exactly that sort of common denominator. "Batteries included" makes it sound like I want my language to come with a playground, which I think is an unfair way to characterize the expectation that Perl 6 provide feature parity with the languages it competes with (i.e., Ruby 2 and Python 3).
- throwaway7645 10y agoI appreciate the explanation, but it practice it usually means everyone has to pick and choose between a collection of bitrotted old libraries. Yes, some are consistently well maintained, but it is hit or miss. It's nice being able to "import CSV" on any python script without having to wrestle with a failed installation. I think both sides have merit.