Você não pode fazer isso porque eu odeio você

Artigo original ↗ Discussão no Hacker News ↗

Programadores debatem quando ferramentas de desenvolvimento devem impor regras estritamente versus se adaptar ao que os usuários claramente pretendem. Os exemplos vão desde o REPL do Python, que exibe uma dica repreensiva em vez de simplesmente sair, até ferramentas do Rust que expõem recursos “instáveis”, porém úteis, ou removem flags que funcionavam antes, forçando os usuários a contornos complicados. Muitos veem esses padrões como falta de empatia e de التفكير de UX no design de ferramentas, enquanto outros argumentam que comportamentos permissivos, atalhos DWIM e opções experimentais podem criar caos de longo prazo e problemas de compatibilidade.

Comportamento de exit no REPL do Python

  • O debate gira em torno de digitar exit versus exit() no REPL do Python.
  • Alguns veem o comportamento atual (imprimir uma string de dica via repr(exit)) como condescendente: o interpretador detecta a intenção, mas se recusa a sair.
  • Outros argumentam que é um compromisso razoável:
    • Mantém a semântica consistente (funções não são executadas sem ()).
    • Evita tratamento especial que quebraria ferramentas que dependem da consistência do REPL ou de repr() ser livre de efeitos colaterais.
  • Alternativas propostas:
    • Tratamento especial de exit apenas no REPL.
    • Imprimir tanto o repr da função quanto uma dica.
    • Avisos ou dicas específicas do REPL, em vez de alterar __repr__.
  • O tratamento mais amigável do ipython (exit simplesmente funciona) é citado como prova de que uma UX melhor é possível.

“Faça o que eu quero dizer” vs. rigidez

  • Um lado: ferramentas devem agir sobre intenções claramente inequívoas (por exemplo, exit, -? para ajuda, -foo quando --foo existe). Ignorar uma intenção clara parece hostil e desperdiça tempo.
  • Outro lado: o comportamento DWIM passa a fazer parte da especificação, introduz ambiguidade e pode causar falhas piores quando as suposições estão erradas (por exemplo, inserção de ponto e vírgula, HTML permissivo dos navegadores).
  • Muitos argumentam que dicas e erros claros são preferíveis a correções automáticas.

Ferramentas Rust e recursos instáveis

  • wrap_comments do rustfmt e a flag removida --no-merge-sources do cargo vendor são pontos de atrito.
  • Críticos: condicionar recursos simples e obviamente úteis ao nightly ou remover flags com mensagens pouco úteis parece que “a ferramenta sabe o que eu quero, mas se recusa”.
  • Defensores: o comportamento de formatação e de vendor tem casos-limite complicados; “instável” evita grandes mudanças em diffs e CI, e a implementação não é trivial. Backlogs e priorização são restrições, especialmente em projetos voluntários.
  • Alguns consideram a divisão entre nightly e stable grosseira demais: pequenas funções utilitárias ou opções de formatação não deveriam exigir nightly.

Ergonomia de CLI e flags de ajuda

  • Irritação recorrente com ferramentas que:
    • Rejeitam -? ou -h enquanto sugerem outra flag de ajuda.
    • Impõem ordem estrita de opções (git log --stat directory).
  • Muitos preferem aceitar múltiplas invocações de ajuda e parsing mais tolerante, especialmente para ações relacionadas a ajuda.

Padrões padrão, botões “não seja ruim” e empatia

  • Botões “não seja ruim”: opções desligadas por padrão que fazem o software se comportar como a maioria dos usuários espera, sem desvantagem óbvia.
  • Tensão entre:
    • Melhorar a UX para usuários novos/típicos com melhores padrões e mensagens.
    • Não quebrar fluxos de trabalho de usuários existentes ou avançados, e não complicar demais a implementação.
  • Vários comentários pedem mais empatia, comunicação mais clara sobre o “porquê” das decisões e mais atenção ao design de interação para CLIs e APIs.