Simplicidade e consistência do Smalltalk vs. outras linguagens (2022) [vídeo]

Simplicidade, Sintaxe e Compromissos

• A sintaxe do Smalltalk é extremamente mínima e uniforme, mas os comentaristas enfatizam que isso não torna automaticamente o código mais fácil de ler/escrever nem os compiladores fáceis de otimizar.
• Blocos e passagem de mensagens unificam estruturas de controle com chamadas normais de método, mas exigem casos especiais no compilador (por exemplo, inlining de ifTrue: / whileTrue:) para evitar desacelerações grandes.
• O modelo de “tudo é uma mensagem para um receptor” empurra o design para distribuir o comportamento por hierarquias de classes/traits, o que alguns veem como elegante e outros como algo que adiciona complexidade em comparação com funções simples em outras भाषagens.
• A familiaridade influencia fortemente o que parece “simples”; uma linguagem minimalista demais pode complicar as soluções.

Desempenho e Otimização da VM

• Há um debate animado sobre por que as VMs de Smalltalk historicamente ficam atrás dos mecanismos JavaScript de alto desempenho.
• Um lado atribui isso em parte ao design da linguagem/VM (por exemplo, blocos, despacho dinâmico) ser mais difícil de otimizar bem com JIT, comparando a trajetória do Smalltalk à do Python.
• Outros argumentam que as diferenças de desempenho são, em grande parte, uma questão de investimento: JS tem equipes grandes e bem financiadas; OpenSmalltalk é movido por voluntários. Usar Squeak/Pharo como referência de desempenho é considerado enganoso.
• São citados exemplos de sistemas semelhantes a Smalltalk de alto desempenho (Self, Strongtalk, variantes de SOM baseadas em Truffle/Graal, TruffleSqueak) que conseguem igualar ou superar JS em alguns benchmarks, desafiando a afirmação de que “Smalltalk é lento”.
• Para Python, as razões subjacentes para a dificuldade de otimização são descritas como pouco claras; menciona-se o forte acoplamento do CPython a extensões em C, mas sem uma resolução.

Ambientes de Programação ao Vivo

• Muitos se encantam com o ambiente baseado em image do Smalltalk, onde código, GUI, depurador e ferramentas estão todos integrados e sempre em execução.
• Isso é contrastado com fluxos de trabalho comuns que exigem reconstruir/reiniciar, vistos como um retrocesso.
• Emacs e sistemas Lisp/Interlisp são mencionados como espiritualmente semelhantes (extensíveis, ao vivo, com histórico baseado em image), mas não idênticos na experiência; Smalltalk é visto como mais coerente, e Emacs como mais “gambiarra”.
• Desvantagens: ambientes Smalltalk modernos podem ser pesados (por exemplo, 1GB+ de RAM) e inconvenientes para distribuir, porque é preciso enviar a VM/image.

Praticidade, Ferramentas e Experiência com Projetos

• Anedotas descrevem produtividade e ferramentas impressionantes em sistemas Smalltalk (bancos de dados OO, motores de fluxo de trabalho, automação embutida no IDE).
• Contra-anedota: um grande projeto secreto em Smalltalk que produziu quase nada demonstrável; a linguagem não foi o único problema, mas sigilo, falta de validação e dificuldades históricas de SCM/configuração em Smalltalk tiveram papel.
• São levantadas preocupações sobre a praticidade do Smalltalk moderno: percepção de falta de bibliotecas “batteries-included”, multithreading fraco ou ausente em implementações FOSS comuns e UIs desajeitadas (editores minúsculos, fluxos de trabalho centrados no mouse).
• Outros observam que os Smalltalks comerciais mais antigos eram “batteries included” para a sua época; o que é prático varia de década para década.

Filosofia de Linguagem e Realidade de Carreira

• Alguns participantes sentem que linguagens mainstream (Python, C++, Java) são muito menos agradáveis ou expressivas do que Smalltalk, Lisp, F#, Elixir etc., mas são obrigados a usá-las por razões de carreira.
• Conselho dado:
  • Prototipe na sua linguagem preferida e demonstre produtividade/valor dramáticos para influenciar escolhas de stack.
  • Esteja preparado para ensinar colegas se introduzir uma linguagem de nicho.
  • Alternativamente, abrace ferramentas populares, mas aplique ideias de linguagens “melhores” no estilo de design e nas abstrações.
• Há tensão entre amar ferramentas e focar na resolução de problemas:
  • Uma corrente diz que a estética das ferramentas é uma distração; o que importa é a eficácia.
  • Outra argumenta que ferramentas de alta qualidade “dissolvem” problemas e que dominar ferramentas é crucial.
  • Alguns sugerem um meio-termo: não se apegar romanticamente às ferramentas, mas também não ignorar seu impacto.

Comparações com Outras Linguagens e Sistemas

• Smalltalk é repetidamente comparado a:
  • Lisp e antigos Lisp machines/sistemas Interlisp (images, GC, desenvolvimento interativo).
  • JS, Python, Ruby e modelos de despacho dinâmico; a busca de métodos baseada em dicionário é vista como poderosa e, ao mesmo tempo, um peso para o desempenho.
  • Tcl e GNU Smalltalk como opções de scripting; GNU Smalltalk é caracterizado mais como “scripting com sabor Smalltalk” do que como um ambiente Smalltalk completo, com estado de manutenção questionável.
• “Homoiconicidade” é debatida:
  • Alguns afirmam que Smalltalk é homoicônico como Lisp; outros argumentam que, em Lisps compilados e ambientes modernos, a noção clássica de “código como dado com a mesma representação” realmente não se aplica.

Aprendizado, Configurações Mínimas e Experimentos

• As pessoas pedem mais vídeos de Smalltalk com “live coding”; são compartilhados links para tutoriais de Pharo, palestras sobre jogos/live-editing e demos introdutórias de Smalltalk.
• Glamorous Toolkit (sobre Pharo) é destacado como um ambiente moderno de “moldable development”, onde a própria documentação é código vivo e editável.
• Alguns querem configurações Squeak ultra-mínimas (sem gráficos/som, apenas REPL em dispositivos pequenos como Raspberry Pi Zero); isso é descrito como não trivial, sem um caminho simples e documentado no tópico.
• São lançadas ideias para:
  • Um sistema parecido com Smalltalk sobre a VM BEAM de Erlang/Elixir para ganhar concorrência e distribuição.
  • Usar VMs JavaScript como destinos de deploy para Smalltalk (por exemplo, squeak.js).
  • Considerar Objective-C (inspirado por Smalltalk) como uma alternativa dinâmica mais prática hoje; isso é mencionado, mas não discutido de forma substancial.