brendn's comments

This is a repost of a backers-only email from Kickstarter. It wasn't meant to be published as a gist.

Tornado relies on its own HTTP server, but its modules for everything from templating to authentication are loosely coupled, so you can take them or leave them.

To your point, I'd be curious to see a non-Tornado server that is Tornado compatible on the backend. It could be an interesting project. I would counter, however, that any server choice has its own inertia--changing web servers is hardly ever a simple process.

The article itself says, "While this HOWTO tries to give an overview of Python in the web, it cannot always be as up to date as desired. Web development in Python is rapidly moving forward, so the wiki page on Web Programming [1] may be more in sync with recent development."

So it may not have been the best resource to present on HN in the first place.

[1] http://wiki.python.org/moin/WebProgramming

Interesting that there's no mention of Tornado [1]. (Disclosure: as a co-author of O'Reilly's Introduction to Tornado, I'm biased in its favor.) I haven't played around with Brubeck [2] yet, but I also hear many great things about it.

Needless to say, there are some great Python web servers and frameworks out there that aren't listed on that page.

[1] http://www.tornadoweb.org/

[2] http://brubeck.io/

Edit: Added links

I find the toilet analogy to be flawed. Sure you don't fix their toilets for free, but you would certainly let someone know if you used one of their facilities and found it to be clogged or otherwise malfunctioning.

As a someone who's filed a few Radar issues over the years, I understand that the lack of feedback is frustrating, but I find it absurd that the way to fix that is to withhold the bug reports that help improve the software we use and develop for daily.

Are you seriously bashing their icons based on the number of people on the team? How can you pass any kind of judgement without knowing what went in to planning, designing, testing, and deploying the change? If you think you could do something similar with fewer resources, either go do it and show us, or stop raining on someone else's parade.

My guess is that radiation's effects on solid-state technology was well-known from nuclear tests.

I think you're misinterpreting my use of "grease monkeys" in general as offensive. (I said not to project value judgements in my original comment. There are certainly developers who see "craftsmen" as aloof purists who look down on practical matters. It cuts both ways.)

I like your city analogy. I won't stoop to comparing programming languages to actual American cities, but I would counter that "PHP is like living in [a particular] big city."

Here's where I disagree: it's not enough to say "hold your nose around these parts, but it's OK because those few blocks on Main St. are worth it."

There will be flaws in any city, and sometimes due to mismanagement, the flaws will be neglected until blight sets in. Here's where the citizens of the city need to step up: they either flee the city and it continues to decay, or they acknowledge the flaws and address them. Don't just accept the downsides! Fix things. Make improvements. The city only thrives on the investments of its citizens.

The arguments in favor of PHP that I continue to hear run along the lines of "everybody's using it" or "it's not that bad if you know what you're doing" or "it's great because it's the Swiss Army knife of languages."

It's hard to argue with those sentiments. And I think the root of the argument stems from the diverging convictions of two distinctly different camps of hackers. There are grease monkeys who love tinkering and see value in a tried-and-true tool that works everywhere. And then there are the craftsmen who strive for elegant code and choose their tools carefully. (There's truth in both of those aspirations. Let's not get carried away in value judgements between the two camps.)

But hearing "PHP sucks but I like it" sounds like Stockholm Syndrome to me. There are some great aspects to PHP that other web stacks and frameworks could learn from. Yet there are some major flaws that actually get in the way of productivity. I hope we can keep the discussion constructive and learn from both camps in building the future of web programming.

This. +1000 if I could.

There are those of us who have been forced to use PHP, and quite honestly, we could use a few good round-up posts of why there are better choices for a project these days than PHP.

Sometimes we can't forget that it exists, so we try to educate people so that with a little luck, they won't pick PHP for their next project.

That may insulate factories from fluctuating inventory supply, but it doesn't solve the problem of fast turnaround when changes are needed. If a part needs to be redesigned, the supplier may still have a weeks-long lead time to get the new part shipped, and has the additional problem of obsolete inventory that is now wasting space near the factory.

Acrobat allows you to embed a subset of the font in the PDF. For a large enough document, most of the glyphs end up embedded anyway, but at least there's no packaged font file that can be installed from the PDF.

That's fine when you make a comparison against a constant, but what if you're comparing two variables?

Part of this has to do with the complexity of storing cookies in WebKit. The SDK wants to redirect to the FB app if it's installed since that is pretty much guaranteed to have the user's credentials. Safari is next most likely, since it will have the user's session cookie stored. Finally, the in-app web view is the fallback of last resort.

This complexity seems to be an attempt to save the user from entering text in a tiny form to sign in. I don't know that it makes an actual user's life easier, but it certainly doesn't help the developer.

Can someone change this to link to the actual IBM blog entry [1] instead of the CNET fluff piece?

[1] http://asmarterplanet.com/blog/2011/12/the-next-5-in-5-our-f...

Why does "more governance" necessarily mean deportation? I fail to see the connection. Can't "more governance" mean better bureaucracy for documenting immigrants?

While you're clearly implying that this is an indicator of a second tech bubble, you're using faulty logic to arrive at that conclusion. Computers were also popular during the dot-com boom. So was the Internet. That doesn't mean that a focus on internet computing caused the bubble, or even indicated it.

If you want to say that this is a managerial dashboard wankfest that may indicate a company more obsessed with metrics than with building a great product, just say it.

A web form to submit a MAC address would make more sense, but if this were a serious problem the solution would be to go to the manufacturers. A standard for broadcasting an "opt-in" bit configurable in the router's admin interface might be reasonable.

(But standards take time to develop and implement. Not to mention that the existence and location of certain MAC addresses is far from the biggest fish to fry, right-to-privacy-wise.)