eevee

Yes, I know. nginx is explicitly not designed for being an app launcher; I don't blame Passenger for this.

Grep the US Code for "spouse", write a contract that covers those things?

> How do you handle loans? If I have 30k in debt, and I marry into a polygamous marriage, do the other spouses carry my debt?

I don't even know how this works with two people. I was under the impression that finances are separate unless you deliberately merge them, and that doing so is orthogonal to marriage.

I'm cheerfully assuming that you're using distilled documentation and not the literal spec. If there is, say, conflicting documentation from Mozilla and Google, then we certainly have a bigger problem.

But you can also just use a data: URI with the entire document inlined—gross, but no moreso than srcdoc. Why is srcdoc any better?

The best part is that I'm an engineer, and a Linux user, and I still don't do all that because it's a pain in the ass.

(But then, I don't use Dropbox either.)

Who, precisely, should decide who shouldn't get the same rights as the rest of us?

Maybe we should have some sort of system to decide this on a case-by-case basis.

So do what the spec says by default (and if the feature appears to exist), and only deviate for particular UAs.

Assume good faith.

Maybe sites would render correctly in Firefox if more web developers used it as a primary browser, rather than just for "testing". ;)

I thought the WSGI support for passenger was neat, and I'm glad there's at least one option for Python deployment with little server configuration required, but I don't use it because I don't want to bugger around recompiling nginx :)

> PHP doesn't want to become Python or Java or Ruby.

PHP doesn't know what it wants to become. This is part of the problem: for any given question, PHP has multiple answers. That makes code harder to write (which option should I choose here?) and hard to read (this doesn't look anything like my code!) and harder to reason about (how does this feature interact with this other feature?).

> It never intends to have all features taught in programming languages class.

You say this here (and in other comments) as though it were an insult. Is there something wrong with learning? If programming languages are hard to learn then we should make them more accessible, not just throw all the things that make them valuable out the window.

> It will not force you to...

Python does not force any of these things. Nor do Ruby or Perl. It sounds like you like PHP because it's not Java. Surprise: I don't like Java either. Surprise again: that's part of why I don't like PHP. Interfaces, "abstract", private/protected/public, and much of the rest of the OO layer are all clearly inspired by Java.

> Just imagine a world where you can't choose anything.

Who's arguing for this? I imagine a world where the choices are all equally good and you don't get screwed by picking the overpriced underpowered laptop, the underwater basket-weaving class, or the sleazy travel agent.

That other comment was supposed to be tongue-in-cheek :)

I wrote the "fractal of bad design" article, though, so your biting commentary isn't misdirected. But I stress that I rag on PHP in particular because I feel it does a unique disservice to my field. There are plenty of languages I don't like or otherwise wish to avoid that I haven't felt the need to write a scathing deconstruction of.

Deployment is hard. I deliberately said mod_php seems easy because it still has caveats, and most of the reasons it works have significant downsides in the language. But this is something I think about regularly and am trying to find a solution to.

I mention photography exactly because that snootiness is a double-edged sword: perhaps there are now many more bad photos, but there are also many more photographers, and with that ultimately comes more good photos as well. The road to improvement across the board is always more accessible education + finding a way to marry the convenience of the new easy tools with the power and finesse of the old ones.

In that vein, you may notice that phone camera hardware has been getting increasingly respectable lately, and that people tend to (rightly) gripe when a new phone comes out with a really crappy camera. That's how I feel about PHP: I don't begrudge anyone for using it, but the rest of the field has improved considerably and it's a shame that cruftier equipment is still popular.

I don't know how you can be a good craftsperson without being able to judge the tools at your disposal, for good or for bad. I know why I like Python, and I know what Python lacks that I keep an eye out for in other languages. If you don't like Python, that's fascinating and I would love to know what about your perspective is so radically different, how it could be fixed, how it could be addressed in a similar language, or even what language does it better entirely. The intricate personal attachment to our tools is ridiculous, and discouraging criticism of them will only make us all worse at avoiding the bad ones and designing better ones.

I think you're confused. The huge problem is that other languages don't have anything for deployment that looks as easy as mod_php.

And yes, all manner of professions grumble amongst themselves that newcomers are using inferior tools. Find some professional photographers and ask what they think of phone cameras.

This is a huge problem, and has the added wrinkle that all the people qualified to solve it won't, because it doesn't apply to the stuff they're deploying and they're clever enough to not need it solved anyway.

Right, because we'd spit on it and advertise Rust or Go.

As I understand it, windows are responsible for drawing their own window decorations on Windows and OS X, but on X they're drawn by the window manager. So it's harder to mess with the title bar because you're starting from nothing and don't even know which of a dozen decoration engines is actually being used. Upside is that decorations are remarkably consistent under X.

Wayland matches the Windows/OS X behavior (probably because it's easier to just accelerate one big rectangular canvas the process draws on), so who knows what will happen as that catches on.

Whoops! I could've sworn that said "without", sorry :)

Though I'm not sure `__slots__` actually saves any time, as it's really a space optimization. I've tried it before for hot code and even seen very slight (probably not significant) slowdowns.

The attributes of an object (and its class) are generally stored in a literal dictionary, so it's unlikely that a class will be more performant.

What a class buys you is behavior and a semi-defined interface.

That doesn't explain the gap, though: the same class went from 42% women starting in 2000 to 30% women graduating in 2004. If 71% of both men and women graduated, there should still have been 42% women at the end.

If women are severely underrepresented in our field, then we're doing something that they find exclusionary. Does the work we produce have a similar problem? How would you know?

Or a lot of men transferred/changed majors into CS, whereas very few women did—which wouldn't be too surprising since the outreach was aimed at freshmen.

Definitely an oversight in the article either way.

It's mindboggling that you can simultaneously call women children and assert that men aren't causing any problems for women.

You're really focused on civil rights and the vote (like it should be impressive that those aren't restricted to white male landowners), but by far the biggest grievances I hear from women are cultural. Being assumed to be anything but engineers because girls are bad at math. Being hit on in contexts that are wildly inappropriate or where turning someone down seems like a bad idea. Being blamed for the actions of their male significant others because everyone "knows" women control men. (I don't much appreciate that one, either.) Having committees of men vote down the women's health budget in one of the largest states. Being called children for still having to deal with a barrage of "remember your place" subtext and not really appreciating it. You know, little things.

Of course those women told you they needed more. You were getting death threats for helping them. That pretty clearly screams that something is still deeply wrong.

There are plenty of women working to help women—some of them the best way they know how, by talking about it—but when the main problem is with the culture, the quick solution is to stop perpetuating it.

Hey, it's your analogy. I merely concede that it's an excellent one.

To continue it, I observe that black America also has the freedoms they fought for; is racism over as well?

As in, Google takes a bigger cut?

> Actually, as a matter of fact, it isn't my problem.

> The problem is obviously slave owners, who will rationalize their behavior as they continue to oppress you

I'm glad we're on the same page here.

This comment is written like a helpful suggestion, but the subtext—"stop whining", "women helping women", "blame men"—reads as though you just don't want it to be your problem. You don't disagree that women are marginalized, but you still tell them to just go bootstrap themselves and accuse them of playing the victim.

There are plenty of women running programs designed to help other women in the tech sector, but you propose them as though you're unaware that they even exist, which speaks volumes about how easy it is for them to make an impact.

Can men just stop being dicks to women? That seems way simpler than starting schools and companies for teaching women how to overcome all the men who are being dicks to them. It's so obvious, I'm astonished you haven't thought of it.

I'm confused; where is the difference in revenue coming from if you're selling the same product to the same number of people on each platform?

You need examples?

Are we on the same website?

Oh, I don't doubt that it's sometimes—or even often—deliberate. But if a UI is implemented badly, no one complains (because no one ever does), and the number of purchases/signups/whatever goes up, why would anyone bother trying to "fix" it?

I'm no fan of PayPal, but I interpret this as a reflection of the state of the banking industry rather than scummy behavior on PayPal's part. Cards skim a ton off the top and are generally designed to gouge the merchant (i.e. PayPal) so customers remain blissfully unaware and keep using them; banks aren't making much effort to compete with direct transfers, probably because they get kickbacks from debit card use.

Many of these could just as easily be the result of really bad UI design, especially when there are "technical constraints"—the RyanAir example in particular reeks of an opt-out being jammed haphazardly into an existing form to avoid adding another control.

Hanlon's Razor, yadda yadda. These patterns aren't any better if they're accidents, of course, but there'd at least be a chance that the offending company would fix them.