# 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
---------------------------------------------------
