mcantor

    $ tar -m foo
    tar: You must specify one of the `-Acdtrux' options
    Try `tar --help' or `tar --usage' for more information.

Lego bricks are hard and consistent and unchanging, and you need them to build incredible novelties.

BTW, my personal belief is that they are called "martial arts" because "art" is simply creating novelty within a system of constraints. Also, you are incorrect that all martial arts are concerned with inflicting damage--there are many arts and corresponding practitioners who encourage and value the mystical aura, because martial arts can be used as a vehicle for personal growth, discipline and spiritual nourishment. Please be careful about generalizing your experiences!

Keep your "usage" blurb succinct and clear.

Don't clobber your users' terminals with two pages of output when they're not expecting it. If "yourapp", "yourapp -h" or "yourapp --invalid-flag" results in two screenfuls of information containing your app's license, installation instructions, contribution notes, an exhaustive listing of every single one of the 100 available subcommands, and a verbose representation of a configuration setting that 75% of your users won't care about, you're doing it wrong. (I'm looking at you, rvm).

This is similar to the idea of "You don't really understand something unless you can explain it so your grandmother gets it." Your app doesn't really have a sensible interface unless the top layer of its abstraction, or the most common commands, can be summarized in less than scrillions of lines of text. If you simply can't trim it down far enough, it's because you're breaking from the Unix philosophy and your utility is doing too much.

Context-aware tab completion is very doable in the unix world, actually; it's just a hassle on the part of the utility-writer. Have you ever noticed that if you add a new file "foo/bar/baz.py" to a mercurial repository and type "hg add fo<TAB>", it will autocomplete all the way to "foo/bar/baz.py", without stopping at each directory? This is because hg has overridden the default tab completion provided by bash and defined its own set of possibilities.

I wish it were easier to set up; I think if that were the case, we'd see a lot more utilities with spot-on tab completion.

Use your language's command-line option processing libraries.

OptionParser in ruby and argparse in python. There is no reason to eschew these libraries: they're part of the standard library, they require zero coupling to your app logic, and they handle all of the edge cases for free.

"But I can just shift the arguments", you say! Yeah? Great! What if the user pipes input through STDOUT? What if the user passes a flag, a required argument, and then another flag? Will your script read the last flag correctly, or has the naive logic already entered "required argument processing mode"? Just use the library. It's a solved problem!

Provide explicit flags for default behavior.

For example, if your lines-of-code counting utility excludes preprocessor directives by default, and includes them when you pass "-i", provide an "-x" switch that signals to use the default behavior. This way, when someone wants to write a bash script that uses your utility, they can do this:

    case $include_directives in
    y)
        LOC_FLAGS='-i';;
    n)
        LOC_FLAGS='-x';;
    esac

    myloc $LOC_FLAGS

1.) It's explicit, and thus more obvious and clearer.

2.) It's more consistent, so there's no risk of empty/unset variables, whitespace, or other edge conditions screwing up a delicate munging operation.

3.) It's change-tolerant, so if future versions of your utility change the default behavior, scripts will continue functioning as expected.

I'm actually just now working through "Rules of Play" by Salen & Zimmerman; it's nice to see the field of game design slowly maturing and accruing "serious" texts. It would be nice if we didn't need academia's help to legitimize our pursuits, but ya can't win 'em all.

I liked the separation you drew here: "The idea here is to use techniques of game design in a way which is integrated in the functionality of an application not focused on gaming..." It's an interesting way to frame the goal of a "gamified application": rather than the "game" being played for its own sake, there is an overarching goal, and the path to that goal possesses game-like qualities as an (apparently) organic side-effect. In the same way that "real life" can distract you from a game, you don't want the "game" of the app to distract you from the "real life" or "goal" of the app.

Hackers don't hug their computers, though.

At least, not when anyone else is looking.

Just sayin'!

The "Art of Game Design" book looks fascinating, too--I ordered a copy!

Their female attendees have been harassed and disrespected. You need to understand that there is no such thing as an objective experience; context is the trump card every time. You don't feel threatened when someone trash talks or hazes you at a conference/tournament. Most women do feel threatened. It's up to us as a culture to decide which of those views is "reasonable". I prefer to consider both of them reasonable and search for a viable compromise.

The intention behind men-only events is to avoid having to support women in technology.

This assumes that the OP's only goal was to debate. I opine that his secondary goal was to be a little cheeky and possibly evoke a chuckle, which was successfully achieved with me! You can interpret the "curmudgeon" comment as an ad hominem to the extent that his exclusive concern was the logical presentation of his argument, which I do not think is true for most cases in human discourse, on or off the internet.

Can you elaborate on what you mean by this? It seems like you're saying users will be unhappy because they can't get new features without having to update, which seems odd.

What if Western Digital used Dropbox's pricing plan?

SWEET JESUS GET IT OFF ME

Just because you don't like it doesn't mean it's objectively "lower quality".

http://focusmanifesto.com/

I highly recommend it. It takes maybe a couple of hours to read, and it's very dense with good ideas, suggestions and observations about how we interact with distractions. He doesn't go the extreme route of destroying them like this article's author; instead, he acknowledges that distraction can be fun and even a necessity to inspiration, but that we need the tools to quash it when we need to focus.