Ian Bicking: the old part of his blog

Re: Full Stack vs. Glue

Hmm, no capitalists in the debate? I guess "let the market decide" isn't the favored approach? Or are we trying to save the folks wandering in from making a terrible wrong decision?

Concept-wise I tend to fall towards the ["Thou that shall not be named"] WSGI-ish style of Pylons, but in a practical sense (there's some place for that, right?), the WSGI-ish approach really needs a project as approachable and documented and "polished" (at least for basic stuff and beginners) as Django to be able to argue on a level playing field. At least if the point of all these debates (that look like developer pissing contests) is to educate people new to python webdev. It's a bit detached from reality to argue you're 10x better technically but then not have the average newcomer able to figure out how to use your kit. Though again, this is rampant in technology.

Also rather than the Windows/Mac, fullstack/glue analogies mentioned, it looks a lot to me like Windows webdev vs Java webdev (wherein the java flavor is say Spring + Hibernate + 23 other libs from diff vendors or groups compared to the all-MS tools on the other side). "Single-source" vs. "multi-vendor"? I guess thousands of people still fight over those two also, but it doesn't seem like an ideal use of energies.

Comment on Full Stack vs. Glue
by ToddG

Comments:

Hmm, no capitalists in the debate? I guess "let the market decide" isn't the favored approach?

The market is made up of individuals making informed and conscious decisions with many factors that are ultimately weighed intuitively. Discussions like this inform those decisions, and inform the market. As a result I think deferring to the market is a little silly: we are the market, this is the market working, there's nothing external to be deferred to. And programmers are uniquely positioned to be both consumers and producers, and to frequently make decisions about what role they want to play in a certain circumstance.

For instance, it would be an entirely valid choice for someone to use a piece of Django that they take from the framework; to choose decoupling whether or not the framework encourages it. It would be valid to wrap Django against its will, though you have to remember that it will also be fragile (and that package is almost certain to be broken right now as a result). The choices we have are infinite, and not just in theory but in practice. With so many choices, how is someone supposed to make a good choice without substantial amounts of discussion?

It's a bit detached from reality to argue you're 10x better technically but then not have the average newcomer able to figure out how to use your kit.

I didn't actually say the decoupled approach is "better", though of course it's generally accepted that decoupled is better than coupled. But that's only true when everything else is equal, and I am not claiming everything else is equal, or even that coupling is a free variable when considering other important attributes. But decoupled and coupled are fairly objective terms, so I feel justified using them clearly in this context; better and worse are highly subjective and contextual.

# Ian Bicking

Discussions like this inform those decisions, and inform the market.

...

we are the market, this is the market working, there's nothing external to be deferred to. And programmers are uniquely positioned to be both consumers and producers, and to frequently make decisions about what role they want to play in a certain circumstance.

Well sorta -- I think the number of people involved at low levels with the projects in question (variable) is a tiny part of the overall "market" in this case -- the handful of people doing (at least publicly) WSGI stuff and/or core Django devs is (I hope) a very small part of the overall userbase. But certainly it's still an example of the market working, even if it seems weighted towards the producer end of things. I was casually dropping the market comment in relation to "the masses" (we can hope!).

It seems to me the fact that programmers are often "consumers and producers" is often a reason many projects become opaque and unapproachable to people who aren't as deeply involved -- that is the "occasional" consumers or new consumers who are at a totally different level of "consumer" than the producers. This of course doesn't negate any sound reasoning in design or whatever, but many projects fail to successfully address these consumers. Often on this point a more "packaged" or "designed to all seamlessly work together" solution has an inherent headstart, as it's a much simpler story to tell.

In other words, until the solution you (and myself to my more limited abilities) support can demonstrate the ability to retain (build on) its technical strengths but still appeal to non-"producers" and more casual users and make _those_ things equal, the endless technical ping-pong might be unecessary(?)

# ToddG

"Hmm, no capitalists in the debate? I guess "let the market decide" isn't the favored approach?"

I don't necessarily regard myself as a capitalist, but I decided to ignore the "debate" and do my own thing, although this isn't news in any sense.

Most of what I've been reading is just advocacy dressed up as methodology: framework A is doing "the right thing" because of the perceived attitudes of their developers, the architectural choices, the ease of use (delete as appropriate), whereas framework B is doing "the wrong thing" because it does something different for all those things, all according to someone's sense of taste (or lack thereof).

Really, the TurboGears and Pylons tendencies to seemingly mix and match with varying levels of readiness obviously provides benefits, although you're still buying into someone's vision of Web programming, and although there's a book out for the former (has the code even reached 1.0 yet?) the documentation may not convey that vision effectively. Meanwhile, Django evolved in relative isolation, although one of its creators seemingly attempted early on to further the Python Web standards effort (with few results), but you've got to buy into the vision a little bit more, although there's a possibility of slightly better documentation about that vision.

Frequently, people who don't know how to start writing their Web application want to buy into a vision. Once sold, they'll produce any amount of hot air to justify their choices. That there's a technological disconnect between various communities says enough about people's willingness to produce hot air instead of working on the things they should all have in common.

# Paul Boddie

Most of what I've been reading is just advocacy dressed up as methodology: framework A is doing "the right thing" because of the perceived attitudes of their developers, the architectural choices, the ease of use (delete as appropriate), whereas framework B is doing "the wrong thing" because it does something different for all those things, all according to someone's sense of taste (or lack thereof).

As someone who writes software and discusses software, obviously advocacy and methodology mix. I program with the methodology I think is right. I advocate the methodology I think is right. I advocate the framework that implements the methodology I think is right. It's not dressing one thing up as the other thing -- it's the two faces of thoughtfully pursuing the craft.

# Ian Bicking