use Perl

Someone once wrote "I wrote you a long letter because I did not have time to write a short one" and it sounds like a paradox - but communicating clearly usually means communicating shortly and it takes time to work out what really is your core message. This is the same case with programming libraries - it takes time to realize what are the highly cohesive components and what parts can be decoupled into independent modules. It is a bit unfortunate how the big libraries have advantage in gaining popularity over the specialized and decoupled small ones. It is understandable, when you use one library for one thing you are inclined to use it to something other even if some other library could solve the problem better.

Thanks for the reply, what you write here is very close to nothingmuch's two essays: Immutable Data Structures and Immutable Data Structures (cont.). As a comp-sci graduate and ML programmer I like this style of programming and I understand very well these arguments, but just a few months ago, following links from Psychology of Perl talk links, I encountered this article: Usability Implications of Requiring Parameters in Objects' Constructors which states:

A comparative study was performed to assess how professional programmers use APIs with required parameters in objects' constructors as opposed to parameterless "default" constructors. It was hypothesized that required parameters would create more usable and self- documenting APIs by guiding programmers toward the correct use of objects and preventing errors. However, in the study, it was found that, contrary to expectations, programmers strongly preferred and were more effective with APIs that did not require constructor parameters.

I am not sure if that would be helpful - but it is there in the repo: http://svn.perlide.org/padre/trunk/Madre-Sync/lib/Madre/Sync/Schema.pm

because it could end not with a syntax error but instead with a well defined but unexpected behaviour. The important thing is that the possibility that the perl parser treats Two::two { (foo => 'bar', baz => 'quux') } as an indirect call is not something that comes to the mind of the programmer. What that indirect call does, whether it is an error or not, is always something unexpected.

These are the main ideas behind WebNano. You are now doing that web frameworks review. WebNano is still nothing more than a proof of concept and I know that you probably don't have time to have a look at each of the dozens of recent Perl web frameworks - but maybe you'll find it interesting to try one that is less than 200 lines. It implements the simple web request path to library name dispatching in a way that is easy to override and extend on per directory basis. I'll appreciate any comments.

One of the core features of web frameworks is dispatching - i.e. connecting the http address with a subroutine. This can be done in a few main ways:

1. DSL with anonymous subs - this what you described above and it is the most common in recent web frameworks. The problem I can see with that code is - how it plays with the standard OO techniques like inheritance and some more advanced ones like Moose Roles. Even if this can be made to play along I am sure there will be lot's of corner cases making it difficult for complex applications and on the other end of scale it also will not be obvious for newbies.
2. Code attributes a la Catalyst: sub index : Local. This looks nice if the attributes are restricted to the most simple type, but quickly deteriorates when you put more information (and logic) into them. It also requires compile time intervention - which means an array of corner cases even if you use the nicely packaged MooseX::MethodAttributes.
3. External list of methods to be allowed to be called from outside (CGI::Appplication run_modes). This suffers from the problem of maintaining the list of methods far from the actual methods code.
4. Calling just one method for example 'get' or 'post' in Tatsumaki and using the class names for the dispatching. This means just one action per class.
5. Lastly - I am thinking about a 'hybrid approach' - i.e. instead of calling just one method called 'get' - maybe calling all methods with a '_get' postfix? I am sure some people will decry that as 'ugly' - but it should work with all OO techniques is very 'low tech' - so maybe it is worth experimenting with?

Or rather I concur all the points by Dagolden above.

The result of the more extreme demands and additional constraints placed on solutions to aircraft braking was the development of antilock braking system (ABS) for aircraft. Auto firms conducting searches for valuable lead user innovations regarding auto braking were able to learn about this out-of-field innovation and adapt it for use in autos - where it is common today. von Hippel: Democratizing Innovation

One thing that the Perl community starts to excel at is reflexivity - the religious attitude of Perl as the ideal and every critique as a heresy is subsiding and people start to understand the shortcomings - which is the first step towards overcoming them.

Answering your question - I concur robinsmisrod's comment on easy web deployment

I concur Tatsumaki looks really promising.

My experience in this area is the same.

That Phalanx story is very interesting on its own. The outcome is compatible the human nature and especially the nature of authors, but still the it is interesting to see how strong these sentiments can be. But I think we have to find a way to break it if we plan to move forward with CPAN and it's growing complexity. One idea about it is to use the growing competition between CPAN modules doing similar things. Sure programmers would be much more confident to use modules that have been so scrutinized - so their user base should grow and feedback to the module.

"It seems however that this whole thread has been a series of people telling other people that what they can and cannot do in a public forum" - that is a good characterisation of the circumstances - but I think we need to go a bit deeper here and explain why it is now that people started to do that (http://en.wikipedia.org/wiki/5_Whys - anyone?). Yes - CPAN contributors should be free to choose any way they want to code their own modules - but on the other hand those that add these modules as dependencies to their code should be secure that a new version of these dependencies will not render their code unusable. This situation is pretty much the same as with API deprecations and calls for a similar measure - explicite declarations from the module authors.

I mean at the time of converting byte stream into characters.

One thing is clear - there is no one thing that could fix the state of Perl marketing. Instead of trying to unify all interested parties under one flag - we can organize some sub-teams. So that people who want a more unified web face of Perl could talk about the design issues without argumenting why it is more important than making CPAN libs easier to install.

my PM meditation: What can bring the excitement back to Perl?.