O que funcionou em Ciência da Computação: 1999 vs. 2015 (2015)

Linguagens Legadas e Específicas do Domínio

• Muitos sistemas críticos dependem de tecnologia “antiga” ou de nicho: Erlang (telecom), COBOL (bancos), MATLAB/FORTRAN (científico), MUMPS (saúde).
• A discussão pergunta o que pode ser aprendido com o motivo de essas linguagens terem sucesso e permanecerem entrincheiradas.
• Uma visão: a adoção e a evolução de linguagens se assemelham às línguas faladas — impulsionadas por forças sociais e históricas mais do que por mérito técnico.

Sistemas de Tipos Elegantes e TypeScript

• TypeScript é elogiado por ter “realizado” tipagem forte para a maioria dos programadores da web, especialmente aqueles sem formação formal em CS.
• Outros argumentam que sistemas de tipos semelhantes ou mais fortes já existiam décadas antes; a principal conquista do TS foi levá-los à maior base de praticantes.
• Debate sobre o quão “elegante” o TS realmente é em comparação com Java/C#/Checker Framework:
  • Pró: tipos estruturais, uniões, tipos mapeados, inferência rica, bibliotecas poderosas (por exemplo, SQL em nível de tipos).
  • Contra: ele empresta muito de Java/C#, carece de uma especificação formal e pode se comportar de maneiras surpreendentes.

Tipagem Estática em Linguagens Dinâmicas

• Python e JavaScript estão ganhando tipagem opcional; ferramentas e guias de estilo estão tornando isso quase obrigatório em equipes.
• Alguns temem que a tipagem obrigatória trai o propósito do Python, prevendo um fork ou uma nova linguagem sem tipos.
• Outros dizem que “obrigatório” na prática ainda permite saídas de escape (Any, casts), tornando isso menos doloroso do que linguagens totalmente estáticas.
• Os tipos são valorizados por suporte do editor, integração em bases de código grandes e coordenação de equipe, apesar do atrito adicional.

RISC, CISC e Conjuntos de Instruções

• Forte thread revisitando o “RISC = Não” do artigo:
  • Muitos agora veem o domínio móvel da ARM e os M-series da Apple como evidência de que RISC é um “Sim” ou ao menos “Talvez”.
  • Contra-argumento: a divisão real é x86 vs. não‑x86; ARM moderno e x86 são ambos fortemente baseados em micro‑operações e borram as linhas entre RISC/CISC.
• Alguns enfatizam as instruções de largura fixa da ARM, que permitem decodificação muito ampla e eficiente, contribuindo para alto desempenho/W.
• Outros argumentam que RISC importava originalmente quando os orçamentos de transistores eram apertados; hoje podemos arcar com ISAs complexas e pipelines profundos.
• RISC‑V é citado como um sucesso principalmente por causa da abertura, e não da “RISC‑idade” em si, embora os menores núcleos RISC‑V nem usem micro‑operações.
• A discussão mergulha em comparações históricas (R2000 vs 80386), pipeline vs. clock, nós de processo e microcódigo, sem consenso único.

Capacidades e Segurança

• “Capabilities” é esclarecido como segurança baseada em capacidades (tokens não forjáveis que conferem direitos específicos, por exemplo, descritores de arquivo).
• Prompts de permissões em apps móveis estão vagamente relacionados, mas implementam em sua maioria permissões semi-estáticas, baseadas em identidade, e não sistemas de capacidades completos.
• As capacidades são vistas como elegantes, mas raramente usadas como base exclusiva da segurança no mundo real; elas aparecem principalmente dentro de sandboxes e no código de baixo nível do sistema operacional.

Programação Funcional vs. “Estilo Funcional”

• Muitos veem “FP pura” como um “Não” prático, mas as ideias de FP (lambdas, pattern matching, tipos soma, APIs de ordem superior) como cada vez mais mainstream.
• Ponto de vista 1: linguagens híbridas (Java/C#/JS com recursos de FP) dão a maior parte dos benefícios da FP enquanto continuam imperativas/OO.
• Ponto de vista 2: esses híbridos são subótimos; FP de verdade exige mais do que lambdas — por exemplo, orientação a expressões, imutabilidade por padrão, estruturas de dados persistentes e gerenciamento explícito de efeitos.
• Debate contínuo sobre o que define FP:
  • Alguns dizem que funções de primeira classe são suficientes.
  • Outros insistem em condições mais fortes, como transparência referencial e tratamento estruturado de efeitos (mônadas ou sistemas alternativos de efeitos).
• Esclarecimento de que “records” por si só não são inerentemente funcionais; eles precedem a POO e existem em muitos paradigmas.
• Tangente separada sobre o que torna algo “orientado a objetos”, sem acordo; records em Java são vistos por alguns como anti‑OO por minimizarem estado/comportamento ocultos.

Paralelismo, GPUs e Rust

• A questão de se GPUs/TPUs “contam” como paralelismo para a classificação do artigo.
  • Uma postura: elas implementam o modelo “wizard in a box” — kernels paralelos escritos por especialistas, não programação paralela de propósito geral.
  • Outra: quase todos os apps de GUI/web usam implicitamente paralelismo da GPU, além de map-reduce e SIMD serem onde o paralelismo realmente funciona.
• Rust é proposto como algo potencialmente capaz de mudar o quadro do paralelismo, com seu sistema de ownership/borrow dando fortes garantias de segurança de threads sobre uma base de segurança de memória.

Redes Neurais e Avaliações em Mudança

• Alguns sugerem que o status das NNs seria “Sim” em 2024, apontando grandes artigos de deep learning por volta de 2014–2015.
• Outros enfatizam que redes neurais passaram por várias fases quentes desde a década de 1960; 2015 foi uma retomada construída sobre décadas de trabalho anterior.

Meta: Atualizando “What’s Worked” para 2024

• Vários comentaristas querem uma tabela atualizada:
  • RISC mudou de “Não” (2015) para pelo menos “Talvez”.
  • Sistemas de tipos sofisticados estão mais proeminentes (Rust, TypeScript avançado), talvez passando de “Não” para “Talvez/Sim”.
  • Ideias funcionais agora são recursos “esperados” em muitas linguagens mainstream.
• Há cautela geral de que qualquer classificação sim/talvez/não envelhece rapidamente e não deve ser tratada como verdade atemporal.