# from Gabor Szabo
# on Thursday 29 July 2010 05:11:
On Thu, Jul 29, 2010 at 9:16 AM, Johan Vromans wrote:
Much to my dislike I think we need yet another perl mailing list. I
didn't find anything suitable in the database of over 210 Perl
related mailing lists. Two lists come close: module-authors and
scripts. However, since Perl killer apps require a distinct mindset
than modules and scripts I'd rather not use any of these.
Shall we go for 'killer-apps' or, more modestly, 'applications'?
I am not sure what would you like to achieve on such mailing list.
Would web/desktop/mobile/comman line/etc application all in one place?
I think there are several applications already on CPAN packaged as
modules, for eacmple ack, Padre to be extreme on the sizes.
Personally I'd use the module-authors list.
Is module-authors an appropriate list for discussions about tools and
creating/packaging/deployment of applications? Is there a community of
application builders lurking here? If so, will new app developers find
us here? Are the technologies too specific / different to be lumped
into one list vs e.g. wx, qt, catalyst, par, c existing lists?
Just because we currently package several applications as modules does
not mean that this is the best way to deploy them to a wider audience.
Tools like ack and padre are, after all, developer tools. In my
experience, getting end-users to successfully install from the CPAN can
be very difficult.
It's also possible that a thriving Perl application developer community
does not necessarily publish their code on the CPAN, or that the code
is even published / open. It seems like the module-authors list may
not be a good fit for that.
Then again, maybe (and ironically) the solution to building / deploying
something besides a module is difficult would best be implemented as
some modules. ;-)
What Johan was saying earlier on the pm_groups list:
we have thousands of modules but very, very few non-trivial
applications.
You also see this in the lack of application framework support, only
recently some App:: modules have addressed this.
Installation support is absent. All tools ... are focused on
installing modules. This includes installing all modules in the
global Perl hierarchy ...
No support for application-specific data. TIMTOWTDI is not the right
answer to every question. No standard way to deal with XML -- this is
why may people run towards Python and Java. Also, no support for
local data, no support for user data. Again, until recently.
Relying on CPAN modules is asking for headaches. The modules may be
not present, wrong version, manually clobbered. ...
Application building: The Perl compiler never did take off. Until
recently PAR was non-functional.
GUI integration. ...
The end result is that if you want to build a non-trivial application
and try to use Perl, you have to do a lot of things yourself.
--Eric
--
Speak softly and carry a big carrot.
---
http://scratchcomputing.com
---
