I still believe that while it's not a new-ground 80/20, it's still some type of 80/20, or even 90/10.
You still make the assumption that "after working with the technology for a while, we have a fair grasp of what core functionalities of it is really required and others can be supplemented much later or not at all" to make the
So in the end - whether on new grounds or after extensively exploring an already existing ground - you make a distinction of certain features you care about, whether they were already implemented elsewhere or await your implementation.
Don't get me wrong - I think it's a good approach and has landed some great successes in various places (YAML::Tiny, Time::Tiny, Template::Tiny, etc.). I was just poking fun at the obvious "you should always provide 100% of the features" cult - which would condemn both 80/20 behavior on new projects and on
Joel "The Joel" Spolsky advises against such 80/20 behavior.
You and your experience with successful
I don't want to put anything into a config file that I wouldn't expect a non-Perl programmer sysadmin to potentially change.
You've got a point there. Fair enough.
Mojo is winning on the cumulative result over all weeks so far, but did not pull ahead.
Positive and negative comparisons are a matter of semantic. Every "win" is a "loss for the opponent". Suckless can say "we write good programs", instead they decided to say "We write programs that don't suck as much as the others."
However, even though you disliked a certain feature of Mojo, and disliked it more than you liked the way it is in Dancer - you still awarded no points to Dancer. Kinda sucked, but oh well, maybe we can change the name of Dancer to "Not Mojo".
This also isn't really the kind of thing you'd want in a config file, it's an inherent part of the application. You aren't going to change it on one particular machine compared to another machine.
Configuration files aren't just things that change across machines. They are also a nice way of getting some code out of your application and into a bit of a cleaner text. Especially when you can write them more succinctly than in code. The TT tags are a good example of that, IMHO.
So we didn't lose, Mojo lost - but we didn't win, so Mojo won. I'm confused.
Should be noted that it seemed like you were more inclined to use "set" in your code when you could have just changed the configuration file (as is shown in the docs):
(taken directly from the POD)
We're actually working on creating a CPAN distribution-like directories. I reckon it would impede even greater on your dislike of multiple files for a small-sized application, but I reckon it'd be better for a user that wants to document, write tests and integrate it as a full-fledged CPAN-structured application. This might be optional though.
I reckon this post was instigated mainly by me. When Adam turned up on the IRC channel after he read from our posts that strict and warnings are on by default, I tried to explain it's on purpose and asked what the problem with it was.
This started a whole discussion when Adam said there's no need for it in production and I countered it saying I do want it in production.
Then the discussion flowed between the rest of the programmers on letting the user be able to change the default warnings on.
This is also something that's a bit mentioned in my recent post on blogs.perl that mentions we learned that users might want to be able to turn off the warnings.
I reckon the whole discussion (which involved a lot of experience of Adam and me on being sysadmins) pushed Adam to finally write a "No warning on production, damn it!" post.
Straight off the bat.
People would often reply to that with "If you don't want to step in shit or god-knows-what, don't step on my porch" which is sort of equivalent to the ol' "this is free software, leave me the fuck alone".