These are reasonable points to make. But Pyramid is explicitly not
trying to be the same thing that either Django or Rails is trying to be.
Those are what we call "opinionated" frameworks, which make things
easier on less experienced developers by making many choices for them.
This usually comes at a cost; you lose flexibility, and you have to
wrestle w/ the framework when you realize that the choice you want to
make isn't in fact the one your tool has made.
Pyramid has some opinions, sure, but far fewer of them. It's intended to
strike the right balance between flexibility, performance, and ease of
use for more experienced developers. Some people complain about certain
features b/c "I'm never gonna need this, and it confuses me, can't we
just rip it out?" But in every case that feature is there b/c SOMEone
had to solve a hard problem and that was the best way to do it. Ripping
it out would make those hard problems harder to solve. But Pyramid
targets those hard problems, and thus the features stay.
This case w/ globals is similar, although slightly inverted. In many
cases module-level global settings are fine; they make the developers
life a little bit easier, and they don't cause any problems. But in some
cases they *do* cause problems. Real, honest to god developer pain.
Django and Pylons have both hit this in the real world. For Django it's
fine, it's a trade-off that makes sense given their philosophy and their
target audience. For Pyramid it doesn't, b/c Pyramid is just as
interested in reducing developer friction in the hard cases as it is the
easy cases, and so they make a different set of trade-offs.
Does this mean that Pyramid will never be as widely used as Django?
Probably. Does that matter? Nope.
-r
On 1/31/12 8:16 PM, Jonathan Vanasco wrote:
my .02ยข is this:
App Developers like features like 'Globals'. It's something that is
familiar-from, and present-in many other frameworks.
Granted, pyramid is a low-level framework - and one that a more
'webmonkey' friendly framework might be built upon itself. But those
frameworks are likely to end up implementing those features
themselves... both in bad ways, and in many numerous different ways. If
pyramid can find a way to pull it off correctly, it would be great.
Rails didn't succeed because it was a "great framework", its success is
largely do to it being usable-by and appealing-to really bad developers
( i mean really awful ones ). PHP got to be ubiquitous and installed on
every platform, by just doing a shoddy job implementing everything, so
even the worst developers flocked to it. People I've been introduced to
by recruiters as "Top Django Pros!" commanding 160k salaries, have been
robots that barely know python.
I loved pylons, I love pyramid. I only get to code about 20% of my time,
and love being able to work in them, because they're implemented in a
way that really resonates with how I like to work. The problem though,
is that I'm usually running operations, tech or product at a company --
not implementing it. Having to source people to execute on goals is a pain.
I understand why "technically" some things might not be right or ideal,
and why they shouldn't be done -- but sometimes the best route for
adoption and continued health isn't to do the "right" thing.
sorry for ranting on this.
/j
--
You received this message because you are subscribed to the Google
Groups "pylons-discuss" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/pylons-discuss/-/ddSQnMKjZZ4J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
