I love Pyramid and my only thought is will it be maintained indefinitely? Say if the few main committers move on is there some sponsor who will step in? (I have similar thoughts about SQL Alchemy which my Pyramid app uses heavily.) My other thought is whether there is a roadmap for the future of Pyramid. It's good to know the project has a plan of where it wants to take things. I see https://github.com/Pylons/pyramid/blob/master/TODO.txt#L116 but there's only one new feature listed for each release like 1.6, 1.7, etc.
On Wednesday, December 10, 2014 7:19:26 AM UTC+1, lostdorje wrote: > > +1 to all the responses regarding there being Python and Ruby developers > vs there being Django and Rails developers (and even Wordpress > developers...*cough*...vs PHP developers). I got my degree in Computer > Science, so I just consider myself a developer, period. The point of these > narrowly scoped dev types is well taken. I wouldn't want to hire anyone > whose skill set is so tightly tied to a framework. I'd guess in most cases > such developers wouldn't 'scale' well in a growing startup. > > And +1 to Torsten's comment about Python, rather than just Pyramid itself, > having a user base with strong programming roots beyond just web > development within a framework. > > And +1 to Jonathan. Totally agree with you on: Lower-level frameworks > like Flask, Pyramid, etc tend to attract developers more interested-in or > experienced-with the language, the user pool is smaller and self-selecting. > This has both advantages and disadvantages, but in terms of getting the > best talent on board, it seems the best talent would definitely be more > interested in/experienced with the 'lower level' frameworks. > > Thanks for all the insightful responses, it helps me confirm I still > believe Pyramid is the right choice for the startup we are building out. > Regardless of technology stack, we will only being hiring *real* developers > and not devs who can hide behind a framework as a crutch, obfuscating the > depth of their real technical knowledge. > > > On Wed, Dec 10, 2014 at 12:44 AM, Jonathan Vanasco <[email protected] > <javascript:>> wrote: > >> I'll preface this by saying that I'm biased towards Pyramid, and when I >> have to program - I prefer it. I begrudgingly program though - I'm usually >> on the business/product/management side. But in the past 3 years: I've >> been working extensively with Pyramid on a personal project, was CTO of a >> large media company that had a re-deploy onto Rails in-progress (a mistake >> that was scrapped), and was the Product/Tech advisor to medium sided media >> company that was on Django. >> >> If you're doing a "Startup" that is in any way unique or looking to >> scale, I would only consider doing it in Pyramid. If it's going to be >> essentially a lot of basic functionality, something off-the-shelf (blog, >> e-commerce) and nothing really proprietary or large scale, then >> Django/Rails would be perfect. Aside from the language difference, Rails >> and Django are basically the same (there are some differences in approach, >> but both are very high level frameworks). If you are a building a one-off >> project, an advertising campaign, are a dev-shop working for a client's >> time-limited event, etc -- then Django/Rails are what you want, and Pyramid >> would be overkill. >> >> Pyramid / Pylons is a very low-level framework. You'll spend more time >> and energy getting some basic things done at the outset, but you won't ever >> be constrained by the Framework or Data Model, and your velocity will >> improve or stay consistent as you need to pivot or scale. You can make >> large changes with little work, and easily introduce "quick fixes" if >> needed. >> >> Django is very high level. It's so high-level, that most people I know >> consider it more like editing configuration files than writing Python. >> You'll be off to a quick start in basic functionality, but quickly feel >> constrained by a fairly rigid API and the need to do things the Django >> way. Your velocity will plummet as the project moves onwards. It can be >> exceedingly hard to implement a "quick fix", because the framework is so >> tightly integrated. Adding new functionality and addressing bottlenecks >> can be aggravating. >> >> Rails is basically the same as Django, except it's in Ruby. >> >> In terms of hiring... from firsthand experience it is incredibly hard to >> find *good* Django/Ruby developers. This has less to do with the >> concept of a "Developers Market" that others noted (which is true) than it >> has to do with the overall talent pool. While there are a lot of really >> brilliant Python/Ruby developers in the Django/Ruby community, I've found >> that the majority the community are Django/Ruby developers -- NOT >> Python/Ruby developers. These people tend to be pretty unfamiliar with the >> core language and just know the framework -- usually through a HowTo book >> or some sort of bootstrap class. Bad developers flock to the buzzwords: to >> Java, then to PHP, and then to Django/Rails. The result is that the >> signal-to-noise ratio in the Django/Rails applicant pool is ridiculously >> low -- and you can spend months trying to source candidates worth bringing >> in to an interview -- only to end up paying a premium for bad developers >> who simply know the stack. I've had Rails/Django devs with 2 years >> professional experience demand higher compensation than developers with 10 >> years of work experience who were experts in a field. It's a ridiculous >> premium. >> >> Lower-level frameworks like Flask, Pyramid, etc tend to attract >> developers more interested-in or experienced-with the language, the user >> pool is smaller and self-selecting. This is simply a correlated effect to >> the popularity of the frameworks. So you might identify 100 candidates for >> a Rails/Django position, but only want to interview 2 after seeing their >> resumes... meanwhile you might identity 5 candidates for a Pyramid/Flask >> position and probably want to bring all of them in. There are definitely a >> lot more "good" Rails/Django developers than Pyramid/Flask developers -- >> but you'll have to sort through hundreds of applications or profiles to >> find them. >> >> If you do go the Django/Rails route, I would suggest doing all your >> recruiting by targeting people through contributions to open source >> projects. All the best applicants I've met were either active contributors >> to larger projects, or had a few small (and well written) libraries of >> their own -- and I could quickly judge if they actually knew Python/Ruby or >> not. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/pylons-discuss. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
