Java vs Kotlin — “all models are wrong”

“all models are wrong”

Em 1976 esta frase mundialmente conhecida em especial para os estatísticos, foi publicada em um artigo do Journal of the American Statistical Association.

“All models are wrong, but some are useful”
Em 1978 a ideia central ganharia espaço na frase.

Esse “aforismo” ou “máxima” seria repetida em vários outros momentos tais como livros, artigos e apresentações até se tornar uma “máxima” ou “aforismo” conhecido mundialmente.

Ao longo do tempo os textos e palestras que envolviam esse aforismo foram trazendo mais clareza para a ideia central, para o propósito dela a medida que George Box escrevia ou falava mais sobre em artigos, palestras ou livros.

Na primeira publicação em 1976 veja:

“Parcimônia
Como todos os modelos estão errados, o cientista não pode obter um modelo “correto” por elaboração excessiva. Ao contrário, seguindo Guilherme de Occam, ele deveria buscar uma descrição econômica dos fenômenos naturais. Assim como a capacidade de conceber modelos simples, mas evocativos, é a assinatura do grande cientista, a superelaboração e a superparametrização são muitas vezes a marca da mediocridade.

Preocupando-se seletivamente
Como todos os modelos estão errados, o cientista deve estar alerta para o que está errado. Não é apropriado se preocupar com ratos quando há tigres no exterior.”

A ideia está aí, mas não está tão clara e explicita. Agora vejamos em 1978 e que pode ser visto na publicação de 1979 a partir da página 201.

“Agora, seria muito notável se qualquer sistema existente no mundo real pudesse ser representado exatamente por qualquer modelo simples. No entanto, modelos parcimoniosos habilmente escolhidos geralmente fornecem aproximações notavelmente úteis. Por exemplo, a lei PV = RT relacionando pressão P, volume V e temperatura T de um gás “ideal” através de uma constante R não é exatamente verdadeira para qualquer gás real, mas frequentemente fornece uma aproximação útil e, além disso, sua estrutura é informativa, pois brota de uma visão física do comportamento das moléculas de gás. Para tal modelo, não há necessidade de fazer a pergunta “O modelo é verdadeiro?”. Se a “verdade” deve ser a “toda a verdade”, a resposta deve ser “Não”. A única questão de interesse é “O modelo é esclarecedor e útil?””

Percebe mais facilmente onde quero chegar ?
Vamos ver o trecho do livro Empirical Model-Building and Response Surfaces de 1986 do mesmo George Box:

“Lembre-se de que todos os modelos estão errados; a questão prática é quão errados eles precisam estar para não serem úteis.”

Ainda pode ficar mais direto e ficou em 1997 no livro do mesmo autor entitulado “Statistical Control: By Monitoring and Feedback Adjustment” na citação:
“Então, como todos os modelos estão errados, é muito importante saber com o que se preocupar; ou, colocando de outra forma, quais modelos provavelmente produzirão procedimentos que funcionam na prática (onde suposições exatas nunca são verdadeiras)”

Mas é aqui onde eu queria chegar, em 2009 é lançada a segunda edição de “Statistical Control by Monitoring and Adjustment” e nela temos esse texto:

“Todos os modelos são aproximações. Suposições, sejam implícitas ou claramente declaradas, nunca são exatamente verdadeiras. Todos os modelos estão errados, mas alguns modelos são úteis. Portanto, a pergunta que você precisa fazer não é “O modelo é verdadeiro?” (nunca é), mas “O modelo é bom o suficiente para esta aplicação específica?”

Pelo título desse artigo e por você estar aqui, não tenho dúvidas que entendeu a ideia de George Box. Mas provavelmente assim como eu, você também é da área de tecnologia e já deve ou ainda vai pensar quais Stacks de tecnologia você vai adotar para sua “aplicação específica”. Entendeu onde eu quero chegar ?

É muito comum se escolher linguagens ou stacks por suas “vantagens”, digo vantagens para não generalizar, porque algumas vezes e quero acreditar que a minoria das vezes se escolhe por um conceito que gosto de brincar chamando de “programação orientada a hype”. Mas assim como George Box disse “All models are wrong, but some are useful” entendo que nossas aplicações são para nós o que os modelos são para George Box.

“Mas Carly, você está dizendo que fazemos software errados então”

Calma, acalme seu ego… Até softwares para aviões que caso falhem pode matar milhares de pessoas falham.

“Falha nos computadores

Sim, eles também se enganam. E quando isso acontece…

Os computadores de bordo são vitais na segurança de voo. Mas também podem falhar. Como no caso do Airbus A330 — o mais com…

Leia mais em: https://super.abril.com.br/tecnologia/como-cai-um-aviao/"

O que isso tem a ver com “definir as stacks/linguagens de uma solução” ?
Tem tudo a ver, porque é preciso pensar no que é “útil” e não no que é “verdade”.
Um exemplo muito comum e recente é a discurssão sobre Java x Kotlin. É muito comum ler/ouvir que Kotlin é melhor ou que Java é melhor. A pergunta não é qual é melhor, mas as perguntas são quais são as necessidades e realidades do contexto. Falo isso em todos os níveis, desde requisitos funcionais, custo/preço, benchmarks e até visão estratégica “quem compete com nossa organização para contratar e manter talentos nessa tecnologia, qual o salario desses profissionais, tenho tempo para forma-los, se forma-los consigo mantê-los, o nosso time já domina essa tecnologia, temos tempo para nos desenvolver nessa tecnologia…” e etc…
Como você pode ver, são muitas as variáveis assim como nos modelos estatísticos que tentam reproduzir o mundo real e é essa a reflexão que quero trazer… Não se trata da “verdade”, mas do que é “útil”.

Entenda seu contexto, sua necessidade e tome decisões alinhadas com os objetivos e a realidade do seu contexto. Se Java é melhor que Kotlin ou vice versa é muito mais papo de bar e zoeira entre amigos, porque no final o que importa é entregar soluções alinhadas aos objetivos e contextos, e para isso meu amigo, você pode usar até PHP…

Calma galera, quem nunca deu uma zoada falando mal do php que atire a primeira pedra… :D

Era isso, espero que possa ter ajudado de alguma maneira a você que leu até aqui e até a próxima.