To some extent, the *::Tiny "namespace" addresses this. But I get the feeling that the real issue is that Perl has simply become bloated over time. If nothing else, there are probably quite a few modules in CORE that really don't need to be there to have a working install. Yes, they are handy, and if not part of CORE would have to be brought in from CPAN for many other modules. But some of the most essential modules for many applications are not part of CORE, i.e. DBI. I say leave some of those others out and let them come in when installing something from CPAN that needs them.

(This was almost exactly the stance taken with v5.20 with the removal of CGI from CORE.)

I stopped being able to do a perlbrew install of any relatively recent version of Perl on my hosting service because of execution runtime limits some time ago. My provider (a very popular one) limits command line scripts to only 15min before being shutdown. That means that to install a Perl with perlbrew I have to tell it to NOT run the tests, then come back and run the test suite manually. This is entirely due to the large number of modules in CORE now.

I stopped being able to do a perlbrew install ...on my hosting service because of execution runtime limits...

perlbrew install -n Perl-5.20.0 will skip testing. Your application probably has its own test suite that is much shorter running than Perl's. If that suite passes, it may not be necessary to run the Perl install through its tests. ...maybe not an optimal solution, but it might be good enough until the host sees the light.

On one of my systems the install of Perl 5.16.3 takes about five minutes by skipping tests. Lowly Perl 5.8.9 takes about 2 minutes. Both fall within the 15 minute limit set by your host.




Dave

Aside from the "provider stuff". I agree. But I guess that's the point; exactly what are the MUST-HAVE's?

Is it possible to come up with enough of them to know that anyone tempted to use "Minimal Perl" would know that they will only need to add a few Modules to make it work for their Project/App?

Thanks for the feedback boftx.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

I'd say the must-haves are:

1. strict
2. warnings
3. utf8
4. Carp
5. Exporter
6. List::Util
7. Scalar::Util
8. parent
9. Tie::Hash::NamedScalar and File::Glob because they get auto-required by core under various circumstances.
10. Everything necessary to bootstrap a CPAN client such as cpanminus.
11. Test::Harness
12. Test::More

If you wanted to throw some other stuff in as a bonus:

1. HTTP::Tiny (though this is probably necessary to bootstrap a CPAN client)
2. JSON::PP
3. Class::Tiny
4. Role::Tiny
5. Class::Method::Modifiers

In practice there are quite a few modules which are only available as part of the core Perl distribution, and are not on CPAN in their own right. This means that if you cut them out of your Perl install, users cannot obtain them from CPAN. So you probably need to keep them.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

I wonder what the odds are for discovering the top N, require statements?

First thought was using the statistics at the CPAN to garner the requires of the top Mod's. But given those stats are so long lived. I'm afraid that might skew the results too much, given there are mirrors, and they don't correlate, concatenate the data with one-another. Nothing that I'm aware of is available for such data.

More thought, and investigation required.

--Chris

UPDATE correct myself (note strike out).

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

From my point of view, the question is contextual.

If I were developing for some sort of embedded system, my definition of minimal would be different than it would be if I were developing on a web based application that was going to be run across a cluster of servers. Minimalism seems to me to be a balance between the capabilities and capacity of the:

• hardware one will be running on when in production
• bandwidth (if any) required of external communication channels
• OS on which Perl is to be run
• developers doing the developing and maintenance
• ...others I am overlooking

It seems to me that the nature of the evolution of Perl, of Perl itself, its use, and even more so, the development of modules in various repositories (botfx in Re: Perl::Minimal -- the good, bad, and the ugly...) sort of belies an attempt at a 'single' definition of minimalism. botfx refers to the inclusion of certain modules in Core as 'bloat' and that seems a fair assessment. Perl itself has become such a capable tool because of the rather broad range of contributors and its breadth and depth of application. I suppose the maintainers of Core get the final choice of what goes into it.

The idea of defining those 'minimalist' sets is an interesting one. Would something like that lead to a fragmentation of Perl interest I wonder? Would this then imply that a sub-level of maintainers would keep the various Core categories maintained?

...but maybe I am taking this out of context or mis-understanding the intent? If not, I do like the idea... It would not be all that different than the way Linux distro's package up in their own way Perl(and everything else), other than one would go direct to the source to get that 'tuned' Core that they want. PerlBrew would become even more valuable as a tool I would think...

Thanks for the reply, wjw.

It's this sort of reply that IMHO, helps define "minimal Perl". In my conception, it would simply be the smallest amount possible to bootstrap itself. But with the addition of just enough to bootstrap NETwork. Which doesn't necessarily even include the CPAN. Because, where the CPAN is concerned. If you have a working network, you can get the CPAN related stuff. If you feel that/those are necessary. You might have something else that suits your needs, where this sort of thing is concerned.

I've been interested in the embedded arena for several years now. I see PHP in use quite a bit [more] than Perl. It's used for things as high-level, as providing a web interface to configure your network -- think Gateways, Routers, and IP/Network filters. To lower-level tasks, such as rc/init. To writing out the disk images, and querying user for setup/installation decisions. Personally; I can easily see, where Perl would clearly be the superior choice for this sort of use-case. Not only does it provide for all the applications just mentioned. But it (where WEB based needs are concerned) can actually provide a web server. Which PHP can not.

I have a "boat load" of devices -- Routers, Switches, Gateways, and CPE's (Customer Premise Equipment -- frequently called modems). That I intend to re-write, or modify the OS (Operating System) on. I intend to use FreeBSD, but any Linux, or other, could also be chosen, by anyone interested in such things.

As I stage for all of this. I needed to address the "scripting" of much of this, and the long-term (resident) applications/scripting methods best suited. I decided (for many of the reasons already mentioned above) that Perl would be the perfect/best choice. Save one thing; SIZE.

So for this use-case; I only want what is absolutely necessary for Perl to bootstrap itself, and just enough for Perl to utilize the (inter)NET. From there, I can manage any other needs/additions, that may be required to meet the overall needs of such an application.

This is only one possible use-case. I can easily imagine a myriad of other use-cases, that would benefit from a "Bare Bones" version of Perl. That can be expanded, as needed.

Other thoughts?

Thanks again, wjw, for taking the time to respond.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

One of the items I would be particularly interested in is an OPC module for PLC's. Almost all factory floor automation is run on PLC's, the development environments for which are written by MS Platinum Partners, and generally is buggy, slow, and costly to keep updated(licensing is outrageous from my perspective). Some of the big names are GE and Rockwell, though there are many more.

I attended an conference/trade show in Chicago last year where a company had developed a 'card' which natively talked to both the PLC and an MSSQL DB, acting as a direct link between the manufacturing equipment/cell and the database. This is unique in that under normal circumstances, data is collected by the PLC and sent via some communication channel(there are many) to an OPC server which then stores the data, and may push that data on to a DB or a DB may 'query' the OPC service where the data is stored. This middle-ware adds latency and bandwidth overhead where it is not needed.

Generally, PLC are for, and very good at, machine control. They are really not designed for applying/supplying business logic. Just machine control. Never-the-less, data from machine control is often good for and used for much more than just making sure the given machine operates properly and safely. It is in fact useful for Data Driven Decision making at the business level.

With that short description out of the way: Those 'cards' that plug into a PLC are just embedded systems that bypass the middle-ware, thus reducing the latency issues, and much of the bandwidth as well. There is no reason those embedded system need to be running proprietary software. And Perl would bring an enormous amount of flexibility(not to mention cost reduction) to the table in this regard.

This is just one more example of the potential usefulness of your concept of minimal Core Perl's. OPC is actually and open standard which means Perl modules could be developed for this purpose. Being able to break away from the M$ paradigm on the mfg. floor would be, in my view, very attractive.

There have been some other folks here at PM that have used OPC and Perl...( Like here)

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw

Aside from my previous reply to this. While examining the possible avenues toward actually building "Perl::Minimal". I happened upon [albeit dated] some related ports of Perl. As in small(ish):

• TiVo Series 2
• Perl for WinCE devices
• and
• Sharp Embedix for Sharp Zaurus SL-5500

I intend to examine these more closely, as they may be good reference points. I also thought it worth listing here, for future interests, here on PM. :)

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

I actually have two Zaurus SL-5500's at home. And Perl is on one of them as I recall. Will have to check it out when I get back there to see what it looks like. Been years since I have used them... . If you run into questions you can't find answers to on the web regarding that Perl, let me know. Will see if I can find them for you on the device itself. Not sure what that might be, however t'is a resource if you find the need...

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw

A minimal Perl core is considered by many to have what's needed to run CPAN and the cpan script. One could try to figure out the requirements of that.

A really bare-bones Perl only needs what is necessary for the core pragmas, handling of @INC, DynaLoader for XS, ExtUtils::MakeMaker, and so forth. If you don't mind losing the functionality of CPAN.pm you can do away with a few more modules.

Then there's miniperl which doesn't even handle dynamic loading for XS, but which can convert XS to C to be compiled and linked into perl. I'd call miniperl just a bit less than barebones Perl. It's used in the build process of the perl executable. Looking at the compilation or even cross-compilation process to build perl could be a good way to determine which modules are really needed to get to a certain point you consider complete.

Hello, mr_mischief.

Looking at minimod.PL. It appears to provide much, if not all, that's needed to write out a desired Minimal::Perl/Perl::Minimal/{<chosen-namespace-here>}. Indeed, it might also provide some clues for determining what should/would be considered the optimal/ideal Perl::Minimal.

Thanks for pointing it out, mr_mischief.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

I'd say JavaScript is minimal Perl! But YMMV ... :-)

If JavaScript is minimal Perl, what would you call PHP? :)

It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

If JavaScript is minimal Perl, what would you call PHP? :)

Typhoid Mary.

UPDATE - added context

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Honestly I don't wanna call PHP names.

I've been told that it's a kind of "Monster Perl" and I avoided it since, but w/o personal experience it wouldn't be fair judging.

And I don't wanna adopt this Pythonista attitude of bashing and FUDing out of the blue.

Well maybe they learned it from us and simply did a s/PHP/Perl/g in the process?

Cheers Rolf

( addicted to the Perl Programming Language)

PS: I was serious about JS being a "minimal" Perl (or at least very close) :)

How small is small?

We could go on f-o-r-e-v-e-r, on that question, alone.

So let's just stop it here. :)

--Chris

P.S. You do make a good point, where JavaScript is concerned, and thanks for mentioning it LanX. :)

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

While I'm kind of keen on the two choices I mentioned -- only because they were the first things I thought of, when attempting to "best describe" it's intent. There is definitely something to be said for a name-space that already exists for something like this.

Thanks for pointing out that name-space.

--Chris

Revisiting
Revisiting this name-space, while tooling up to begin the actual creation of this project. Indicates that the Perl::Dist root name-space is devoted to the Win::* family of Operating Systems, to the effective exclusion of [all] others.

That being the case; I believe that the use of that name-space will [ultimately] be misleading. As such, I am looking to keep with something [at least] similar to my original "naming-convention" (should I "poll" for a final name?).

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Would it be worth it to create an additional thread titled
What is the absolute minimum a Minimal::Perl distribution have to be a Minimal::Perl?

--Chris

I would suggest that a “minimal Perl” should include only basic data-structure manipulation ... list utilities, character-set support ... but that, really, “the Perl core is quite small-enough already.”   The inevitable problems of code-size arise, not so much from the Perl core, but the way in which the various CPAN modules were built.   Any contributor was free to use whatever tools and other-packages that s/he wished, and every one of those did the same.

Systems like PHP, which mostly compile-in everything that you're likely to use, produce multi-megabyte executables.   Perl and its ilk, which are modular, use about the same amount of code.   Either way, more code is brought-in than might be called “minimally necessary,” but I frankly think that efforts to reduce that footprint would have negative results, because it would run the serious risk of de-stabilizing code that is already known to work.   Even if a particular well-tested package is quite bloated, indeed, if it makes your expensive programmers more productive and your expensive software more stable and reliable, that’s what really makes a measurable ($$) difference.

Greetings, sundialsvc4, and thanks for the reply.

You almost had me. But then things seemed to take a turn towards the end.

I don't think it matters where "de-stabilizing" is concerned. Given Perl's vast knowledge of "dependencies". I think that point becomes moot. If I have installed this "Minimal Perl", and felt slighted, in some way. I think it's enough to simply Download, Build, and Install whatever I think I need. Perl, and/or the Module takes care of any "deficiencies" during the process. It's not unlike the FreeBSD ports system. You have a tree, CPAN in this case, of applications/utilities/functions. Grab one, build it, then install it. All the needs are AutoMagically delt with during the process. While there may, indeed be cases where those needs must be dealt with Manually. By virtue of that fact, perhaps improvements to the Module, to deal with those cases more efficiently/automatically, should be/could be made. Much of this, is already being addressed with cpanm, and the likes.

In my version of "Minimal Perl"; Perl will have just enough to "gather" what ever it needs, when asked to "Need" more.

Is this wrong?

Thanks again, for taking the time to respond, sundialsvc4.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH