No último Backlog eu abordei um tema que estava me incomodando bastante nos últimos meses: o fato de que devs hoje estão ficando cada vez mais preguiçosos e delegando cada vez mais tarefas para a IA. Desde então tivemos o advento disso aqui, que eu estou nomeando agora como Slopware:

Se você está por fora da bolha de reclamações do mundo tech, esse é o Fly Pieter, um jogo criado pelo mesmo Pieter Levels (que comentei no Backlog anterior) usando apenas a força de vontade e uma subscription do Cursor. Eu tentei jogar, mas aparentemente depois de 20s de jogo eu não consegui conectar em nenhum servidor (imagino que por que meu setup bloqueia trackers).

Como você pode ver, o jogo não é uma obra de arte, mas tudo bem, gráficos não são a parte mais importante de um jogo (eu jogo Tibia e Dwarf Fortress), e sim a jogabilidade, a história, etc. O problema é que esse jogo não tem nenhuma dessas propriedades… É apenas um monte de gente voando e vendo anúncios. E, ainda assim, gera uma renda de 1 milhão de dólares anualmente (segundo o criador). Meu questionamento é um só: por quê? Simples… Audiência.

O efeito da audiência

Eu tenho uma opinião muito forte sobre essa situação toda: não concordo com as pessoas que estão endeusando esse cara porque ele “criou” um jogo e fez milhões com ele. Eu acho que nossos ídolos estão nos lugares errados.

Recentemente o Felipe Deschamps postou esse tweet:

E ele está certo. Levels está construindo isso há não sei quanto tempo, e eu não tenho nenhum problema com isso. Mas é um fato: isso só deu certo porque ele tem uma grande audiência, quase um culto de pessoas que o idolatram porque, de alguma forma, o número na conta bancária dele é maior.

Enquanto a grande massa idolatrar milionários e bilionários, vamos ter o mesmo problema: eles vendem o que querem, quando querem, simplesmente porque são quem são.

O maior exemplo disso é justamente esse jogo, que é basicamente uma exposição de anúncios. Não existe nada que você possa fazer ao jogar, é só voar, atirar nos outros e ver anúncios. E é isso. O que, aliás, é refletido na página de login:

Quando você quer promover sua startup, é levado a uma página de compra do Stripe e, por uma bagatela de 5.000 USD mensais, pode colocar o que quiser nos balões.

Agora me diga: se uma empresa grande de jogos, digamos, a Blizzard, fizesse a mesma coisa, você ficaria feliz ou puto da vida? Então por que esse tratamento diferente? Acho que você entende onde quero chegar.

Nesse vídeo (que vou mostrar mais pra frente), Max discute o mesmo ponto. Isso não é algo que a maioria de nós conseguiria fazer. É algo que só ele consegue, justamente por causa desse culto ao dinheiro.

E, se as empresas têm tanto dinheiro, por que não patrocinar um jogo de um pequeno produtor indie ou uma empresa pequena que está trabalhando duro para ter seu jogo publicado? Simples: essas pessoas não querem estragar o jogo com ads. Quem faz isso são apenas aqueles que não se importam com o produto, só com o dinheiro no final.

E nem tudo tem que ser sobre dinheiro. Enquanto essa for a mentalidade, a única coisa que vamos ter são produtos mal feitos, cheios de promessas.

Vibe coding

Esse jogo foi feito em um modelo que aparentemente existe há mais ou menos um mês: vibe coding. Um termo feito por Andrej Karpathy (um dos fundadores da OpenAI, então sem viés...) e compartilhado em um tweet:

Basicamente, a ideia é aceitar absolutamente qualquer coisa que a IA cuspa para você. Você não está mais codando, está conversando com um agente de IA. Ela sugere o código, você aceita sem ler. Se der erro, simplesmente copia a mensagem e cola novamente na IA, e assim vai indo até conseguir fazer o app funcionar.

Esse modelo me lembra muito um algoritmo chamado Bogosort, onde você embaralha uma lista até ela "se ordenar" sozinha.

Eu não consigo nem começar a descrever o quão contra esse tipo de coisa eu sou. Simplesmente aceitar qualquer coisa que uma IA te sugere é o equivalente de ir no cabeleireiro e ir testando novos cortes de cabelo até um deles dar certo.

E, para completar, temos esse vídeo fantástico da Y Combinator dizendo por que vibe coding é o futuro:

O mais interessante é que esse vídeo é tão estranho, de tantas formas... Os comentários resumem muito melhor do que qualquer coisa que eu possa falar aqui:

O próprio Garry Tan diz que uma das coisas que ficou clara nas pesquisas é que: “Vibe coding é muito difícil de debugar”. Eu imagino por quê… Talvez porque você não entende absolutamente nada do que está escrito ali? Ou talvez porque debugar seja 90% de ser um programador?

Além disso, achei a pesquisa inicial meio estranha. A hipótese proposta é que vibe coding é o futuro, mas a pesquisa feita foi se “como founders usam IA no dia a dia”. Isso é um exemplo clássico da Falácia do Espantalho (Strawman) —quando se tenta provar um ponto completamente diferente do que está sendo debatido, criando uma relação inexistente entre eles. Seria como testar a hipótese de que “pessoas preferem motos a carros” perguntando se costumavam andar de bicicleta quando crianças.

No entanto, no minuto 17, Diana Hu fala algo que faz sentido e com o qual eu realmente concordo: para produzir um produto muito rápido, não há problema em usar algo desse tipo para acelerar o desenvolvimento. O problema é achar que podemos construir empresas inteiras assim.

Sempre lembrando de que, se a IA te faz um 10x engineer, então provavelmente você vai ser substituído por uma IA no futuro próximo.

Enquanto o vídeo da Y Combinator é estranho, mas mostra uma perspectiva do lado que quer ganhar mais dinheiro com menos trabalho, outra perspectiva interessante foi dada pelo Maximilian Schwartzmüller no canal dele:

E essa eu quero cobrir com mais detalhes.

Algo para começar

Vibe coding é uma ideia legal para prototipar rapidamente, testar conceitos e validar hipóteses sem gastar muito tempo. Mas quando falamos de algo realmente sério—um produto do qual muitas pessoas dependem, que precisa ser confiável e sustentável a longo prazo—não dá para tratar o código como um experimento descartável. Você definitivamente não quer que algo “funcione mais ou menos” quando for para produção, porque “mais ou menos” em tecnologia significa bugs imprevisíveis, falhas de segurança e, no pior cenário, um sistema inteiro quebrando no momento mais crítico.

O próprio Andrej menciona isso no tweet original. Então, não—vibe coding não é o futuro da engenharia de software, é só uma forma de testar ideias rapidamente, sem muito pensamento estratégico, para ver se algo dá certo. E mesmo quando dá, chega um momento em que esse código precisa ser reescrito do jeito certo.

Os perigos do vibe coding

Voltando ao caso do simulador de voo, nesse mesmo vídeo, ele mostra o jogo rodando em produção, com milhares de pessoas acessando. Aos cinco minutos, também revela que o código estava vulnerável a XSS (Cross-Site Scripting).

O problema não é deixar de codar ou fingir que está codando. O problema é pedir para uma IA escrever o código, não entender o que está acontecendo, publicar o código sem questionar e, ainda assim, ignorar o mínimo de segurança. Isso coloca não apenas a sua empresa, mas milhares de outras pessoas em risco, tudo porque você se considera um “10x engineer”.

No caso específico, os atacantes começaram a inserir elementos no jogo. Foi “super legal” para o Pieter, mas se fosse um malware, aposto que não seria tão divertido assim…

Sempre existe um viés

Idealmente, tanto as empresas de IA quanto as VCs querem que isso se torne realidade por dois motivos:

1. Empresas de IA querem manter seu valor, e é óbvio que “vibe coding” é bom para elas. Quanto mais as pessoas dependem de IA para gerar código sem entender o que está acontecendo, mais elas consomem e compram os serviços dessas empresas.
2. VCs, como a Y Combinator, estão focadas em uma única coisa: dinheiro. Se você consegue reduzir o custo de contratar desenvolvedores, isso significa mais dinheiro no bolso. E muitas dessas VCs também investem em empresas de IA, o que nos leva ao ponto 1.

Meu ponto é o seguinte: todo mundo que diz que “vibe coding”, ou IA gerando código e resolvendo tudo, é “maravilhoso”, “o próximo passo” ou “o futuro”, geralmente tem algum interesse pessoal em fazer com que isso seja verdade.

Minha teoria não oficial é que, no fundo (ou não), muitas dessas pessoas estão tentando reduzir o valor dos desenvolvedores, porque eles são essenciais em uma economia tecnológica, e bons desenvolvedores são caros. É uma tentativa de dizer: “Opa! A IA também consegue fazer isso, então talvez você não valha tanto assim.” O objetivo, no final das contas, é pagar menos e ainda obter o mesmo resultado. Mais uma vez, tudo se resume a como fazer mais dinheiro de forma mais rápida.

Mas, para não ser injusto, eu mesmo testei o “vibe coding”.

Minha experiência

Eu postei esse tweet falando com a galera de frontend para fazer esse desafio. A ideia é só gerar um input de busca exatamente igual a esse:

O Igor depois me deu a ideia de tentar gerar com IA, e isso não tinha passado pela minha cabeça, quem sabe poderia dar certo. Mas eu estava completamente errado. Eu testei quatro geradores diferentes: Lovable, V0 (que tem uma funcionalidade de copiar de um screenshot), Bolt e Cerebras. Isso foi o que eu consegui:

Não é exatamente o que eu queria quando eu fiz um prompt como: "Copie exatamente esse componente". Mesmo depois de 35 minutos de ping-pong com a IA. Então eu acho que eu não vou estar "vibe coding" num futuro próximo.

O problema do Vibe Coding

Para mim, o problema do “Vibe Coding” não está exatamente no código sendo gerado — a gente já tinha algo similar com assistentes como o Copilot há algum tempo. Quando eu digo que “gosto de escrever código”, o que quero dizer é que esse é o objetivo de um projeto para mim. Eu quero estar envolvido no processo de codificação, mas, claro, não faço tudo sozinho. Não digito todas as linhas ou todas as letras, e é por isso que posso usar assistentes para me ajudar.

O real problema, na minha visão, é não estar no controle. É inaceitável para mim “criar” um produto sobre o qual eu não tenho o menor controle e não faço a menor ideia de como funciona, muito menos colocar isso em produção para outras pessoas usarem. Quando uso assistentes, estou no controle. Eu guio o que quero que seja feito.

Mais do que isso, se você não gosta de escrever código, talvez seja hora de repensar se a programação é a profissão certa para você. Como desenvolvedores, a gente precisa gostar da programação em si. Eu não sou fã de bugs, claro, mas não posso negar que me sinto muito mais calmo e tranquilo quando estou escrevendo o código.

Além de tudo isso, ficar batendo ping pong com a IA tentando fazer com que ela entenda o que eu quero é bem menos produtivo do que simplesmente escrever o código por conta própria.

Eu realmente não entendo por que algumas pessoas querem parar de escrever código.

Para quem não sabe absolutamente nada de programação, o “vibe coding” pode ser um bom caminho, mas é uma via única: ou você usa para tudo ou para nada. Se você quer criar algo muito rápido, simples e direto, e não se importa muito com os detalhes, vá em frente. Mas, por favor, não coloque outras pessoas em risco por não saber o que deveria ter feito você mesmo.

Você é hipócrita!

As pessoas podem me chamar de hipócrita, pois eu também uso IA para outras coisas. Não é mentira, eu realmente utilizo inteligência artificial. Porém, algo que eu não faço é deixar que ela gere algo que vai para produção — seja código, texto ou o que for.

Eu vejo a IA de forma positiva quando aplicada a algo útil. Exemplos disso estão aqui mesmo nesta newsletter! Sempre faço uma revisão para deixar o texto mais conciso, corrigir pontuações, mas todo o conteúdo original é meu, escrito por mim, letra por letra (sem autocompletion). Quando a IA é usada com propósito, ela pode ser muito eficaz. O problema surge quando “usar IA” é visto como um fim em si mesmo, e não como uma solução para um problema específico. “Alguma coisa com IA” não é um propósito. É simplesmente uma solução procurando por um problema.

Slopware

Eu sigo uma newsletter chamada "The Honest Broker". Nela, o autor Ted Gioia publicou um post muito interessante sobre o novo "movimento artístico" chamado de slop. Que é a ideia de que aquelas imagens absurdas geradas por IA podem se tornar um movimento real... Por exemplo:

Quanto pior, melhor; quanto mais absurdo, melhor; quanto mais estranho, mais as pessoas vão comprar. E, se você lembrar do início desta newsletter, isso descreve exatamente o que o nosso game é: algo absurdo, mal feito, mas que as pessoas adoram por um motivo ainda mais absurdo — o desejo de não ficar de fora. É como uma espécie de fenômeno social, onde o status de “estar dentro” se torna mais importante do que a qualidade real do produto. E é isso que nos leva ao conceito que estou apresentando nesta edição: Slopware.

Slopware é o tipo de software que é feito de qualquer maneira

Slopware é o tipo de software que é feito de qualquer maneira, sem uma visão clara ou objetivo definido. Ele provavelmente é gerado, em grande parte, por IA, e se passa como um produto sério. O problema é que, na maioria das vezes, os criadores desses produtos não têm a menor ideia de como esse software foi realmente criado ou como ele funciona. É como se fosse uma simulação de algo “sofisticado”, mas na verdade é apenas um amontoado de soluções que, de alguma forma, se tornam um produto utilizável — ou pelo menos, consumível de alguma forma. Isso se torna ainda mais irônico quando vemos esse tipo de software sendo vendido como inovação, mesmo que o próprio processo de criação seja desorganizado e sem sentido.

Na mesma newsletter, Ted coloca 4 imagens que parecem slop mas não são:

Essas imagens mostram algo mais profundo: elas ilustram como, no mundo real, as pessoas estão se esforçando para alcançar o mesmo resultado medíocre que a IA já entrega, de forma automática. O objetivo por trás disso parece ser normalizar a ideia de que o mal feito é o novo bom. Isso acontece porque, em um cenário onde tudo ao nosso redor é de qualidade questionável, qualquer coisa que se destaque minimamente, mesmo que ruim, se torna relativamente incrível. Quando o padrão é baixo, até o mínimo de esforço se torna uma grande conquista.

E é aí que mora o meu maior medo: que esse conceito de slopware se estenda para o software de forma generalizada. Imagine um futuro onde nossos aplicativos, ferramentas e sistemas são feitos sem muito cuidado, com a IA simplesmente criando algo que funciona de maneira superficial, mas que não passa de uma solução rápida e sem substância. Em vez de aspirarmos a criar software robusto, bem arquitetado e seguro, aceitaremos como normal um produto que apenas “faz o trabalho” de maneira medíocre.

Isso representaria uma grande mudança de paradigma, onde, ao invés de termos softwares que são projetados com qualidade e propósito, todos eles se tornariam exemplos de slopware, e qualquer coisa que se distoasse minimamente dessa mediocridade seria considerada uma verdadeira revolução. O problema é que, no fundo, isso levaria a uma diminuição da qualidade geral, colocando em risco a confiança que colocamos em ferramentas que são essenciais no nosso dia a dia.

É isso. Happy vibe coding.

Nos últimos anos, especialmente após a pandemia e a explosão da IA, testemunhei um declínio silencioso de uma profissão que se orgulhava de seu pragmatismo e atenção aos detalhes: o desenvolvimento de software.

Não estou prevendo o fim dessa carreira - muito pelo contrário. Mas algo mudou na essência do que nos definia. Antes, éramos reconhecidos não apenas por fazer código que funciona, mas por fazer código que conta uma história. Quantas horas já perdemos em debates apaixonados sobre linguagens, tecnologias, arquiteturas? Éramos pessoas que faziam tecnologia porque amávamos o processo de criação, a arte por trás do código.

E essa paixão sempre foi mais evidente em um detalhe fundamental: a documentação.

Documentar o código que você acabou de escrever era como se você estivesse escrevendo um livro sobre a sua obra de arte, as pessoas gostavam de explicar como as coisas funcionavam, gostavam de falar sobre os programas que faziam e os produtos que foram produzidos com tanto carinho.

A EA recentemente liberou o código fonte de Command & Conquer e eu postei esse tweet:

Esse código foi escrito em 1995 e, sem dúvida, é um dos mais bem documentados que já vi em toda a minha carreira. Mas então parei para pensar: já faz anos que não vejo uma documentação assim. Onde foram parar essas boas documentações?

Nos comentários desse tweet, muita gente disse que o código era feio, que hoje as coisas são diferentes, que jamais o consideraria bem documentado, e por aí vai. O que aconteceu? Como passamos de documentações detalhadas como essa para simples anotações apressadas em READMEs mal feitos?

Eu deixei essa pergunta em um outro tweet, se você quiser dar sua opinião por lá vai ser super legal! 😄

O que aconteceu com a gente?

Sempre foi claro que código é uma ferramenta – nunca duvidei disso, e não duvido agora. Mas o que aconteceu com a gente? Paramos de nos preocupar se as pessoas conseguirão usar ou sequer entender nossos sistemas. Hoje, parece muito mais "eficiente" e "produtivo" simplesmente copiar um código qualquer, colá-lo sem ler nada e ver no que dá.

Eu tenho algumas teorias...

O declínio lento do pensamento crítico

Para promover a Formação TypeScript, rodo anúncios em várias plataformas de tempos em tempos. Talvez você já tenha visto (ou não). Não é segredo que faço isso – sempre fiz, assim como qualquer pessoa que tem um produto digital.

Faço isso há anos sem problemas, mas recentemente publiquei um anúncio um pouco mais "polêmico" e, pelo visto, não consegui transmitir a mensagem como queria. Várias pessoas repetiram exatamente o mesmo comentário, mesmo depois de eu já ter respondido a mesma questão diversas vezes.

Isso aconteceu tantas vezes que fui forçado a bloquear os comentários em todos os anúncios.

Não são os haters ou os comentários que me chateiam. Estou na internet há tempo suficiente para lidar com o ódio inevitável que as pessoas destilam do conforto de seus teclados. O que me incomoda é a total falta de esforço para entender o contexto — ou seja, para ler.

E o mesmo acontece no desenvolvimento. Os devs estão cada vez mais preguiçosos e acomodados, perdendo a curiosidade que antes era um pré-requisito para essa área.

De uma profissão que se orgulhava de ser meticulosa e focada, passamos para uma geração que terceiriza seu pensamento para outra máquina, apenas para repetir exatamente o que ela diz. Novamente:

o que aconteceu com a gente?

Desde que o ChatGPT e outras ferramentas surgiram, a quantidade de pessoas que simplesmente copiam e colam um prompt sem nem sequer ler o que ele diz é absurda.

E não sou só eu dizendo isso do alto de um trono de mármore. Existem diversos relatórios sobre o assunto:

Code Quality in the Age of AI ✅

How to create a process for quality throughout the whole SDLC.

RefactoringLuca Rossi

AI is eroding code quality states new in-depth report • DEVCLASS

New research from GitClear, based on analysis of 211 million lines of code, suggest that AI coding assistants […]

DEVCLASSTim Anderson

Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality (incl 2024 projections) - GitClear

GitClear Footer Logo

How AI generated code compounds technical debt

GitClear’s latest report exposes rising code duplication and declining quality as AI coding tools gain in popularity.

LeadDevBill Doerrfeld

AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones - GitClear

GitClear Footer Logo

Quase todos apontam a mesma coisa: A qualidade de código está decaindo ano após ano porque as pessoas estão simplesmente copiando código ao invés de pensar.

Tenho muito mais a dizer sobre isso e vou abordar o assunto em outro Backlog.

O ponto aqui é que poucos agora se preocupam em documentar ou dar um pouco mais de atenção ao código que escreve, porque simplesmente:

• É mais fácil pedir para a IA gerar um código na hora, sem considerar o restante da base.
• Copiar todo o código e pedir para a IA explicá-lo em duas linhas.
• Deixar que a IA escreva a documentação.

E há um problema curioso nisso tudo: o código gerado por IA costuma ser muito bem comentado. O resultado? Criou-se o estereótipo de que qualquer código bem comentado só pode ter sido escrito por IA — e não que seja simplesmente um código bem feito e fácil de ler.

Dev bom sabe ler e entender

Muita gente chega falando:

"Ah! Mas o Clean Code é contra comentários blablabla"

E esse é mais um exemplo de como as pessoas pararam de pensar. Clean Code é um livro antigo, de outra época, mas nem por isso condena comentários no código — ele condena comentários inúteis. Por exemplo:

// Soma a+b
function sum (a, b) { return a+b }

É um comentário inútil — descreve o que está acontecendo, mas não por quê. E é aí que está a nuance.

A documentação (seja em comentários ou não) deve explicar o porquê das coisas, não o que o código faz. Isso deve ser claro apenas lendo o código.

"Se você não consegue entender o que o código faz só lendo, então você é um mau dev"

Essa frase me irrita tanto, e por um motivo simples, Veja esse código:

float Q_rsqrt( float number )
{
	long i;
	float x2, y;
	const float threehalfs = 1.5F;

	x2 = number * 0.5F;
	y  = number;
	i  = * ( long * ) &y;                       
	i  = 0x5f3759df - ( i >> 1 );               
	y  = * ( float * ) &i;
	y  = y * ( threehalfs - ( x2 * y * y ) );   
	return y;
}

Agora tente ler esse código sem nenhum contexto. Conseguiu entender?

Se sim, só existem duas possibilidades: ou você é extremamente inteligente e fora da curva, ou já conhece a história desse bloco.

Entender código é difícil, principalmente porque ele sempre vem com um contexto. É por isso que comentários são tão importantes. Um trecho solto, sem explicação, é como abrir um livro em uma página aleatória e tentar seguir a história a partir dali.

Caso você esteja curioso(a) o código é esse aqui

Mas eu acho que a culpa não é só de devs, mas também de um mindset que eu odeio muito. O de "hustle bro" ou de "indie hacker". Essa é a minha outra teoria.

Ship it! Ship it! Ship it!

Duas palavras definem o mercado de TI de 2019 até hoje (2025): dinheiro e velocidade.

Entre em qualquer site de biblioteca, ferramenta ou framework e você sempre verá alguma variação de "blazing fast", "weeks, not months", e similares. Velocidade e lucro a qualquer custo se tornaram os objetivos principais de praticamente tudo.

A cultura de hustle bro, com seu mantra de "VOCÊ CONSEGUE! ACREDITE EM VOCÊ" e "trabalhe enquanto eles dormem", ganhou força e acabou transformando um mindset que eu admirava, o de indie hacker. Um indie hacker é um empreendedor solo que cria um produto com total controle, sem investidores, sendo independente. Eu sempre amei essa ideia de trabalhar no que você deseja e fazer dar certo. Mas isso mudou quando tudo passou a ser sobre ser mais eficiente e produtivo, como se o dinheiro fosse o único objetivo.

As pessoas estão transitando de um estado de "planejar, aprender e executar" para "executar e ver no que dá".

No mesmo cenário dos criadores de "por que testar? Testar não adiciona valor ao produto", surge a ideia de que "documentação é uma perda de tempo" pelo mesmo motivo. Assim, a documentação é negligenciada, pois, novamente, "bons devs sabem o que acontece no código só de olhar". Documentação, housekeeping e boas práticas são vistos como desperdício, e o foco passa a ser apenas em shipar shipar shipar.

Para exemplificar, vou citar duas figuras emblemáticas do novo "indie hacking", Pieter Levels e Marc Lou, mas longe de serem os únicos, eles são apenas os que fazem mais barulho.

Note que os detalhes são impressionantemente iguais. Bios com sites e rendas mensais, cifrões em todo lugar, a palavra "ship" e "fast" estão bastante presentes.

Para provar meu ponto, um deles está neste momento desenvolvendo um jogo, sem nenhum conhecimento prévio em desenvolvimento de jogos, sem ler documentação, apenas copiando e colando código do Claude Sonnet e esse tweet resume muito do que está acontecendo.

À medida que os bugs ficam mais difíceis, a solução não é aprender a fazer do jeito certo, mas sim resolver os bugs e criar outros "para ver se funciona". As pessoas estão trocando o ciclo de "planejar, aprender e executar" por "executar e ver no que dá", o que é péssimo, pois ninguém quer estudar nada, só testar e ver o que acontece.

O problema não é o que elas "sabem que não sabem", mas o que "não sabem que não sabem", e ainda assim acreditam que está tudo resolvido. O maior exemplo disso foi a treta recente com o Marc, onde um dos seus produtos passou por sérios problemas porque ele não implementou a segurança necessária no seu "MVP". Coisas que poderiam ter sido resolvidas com 15 minutos de leitura de documentação sobre os casos de uso. Isso me lembra novamente o meme:

Documentações que importam

Para finalizar, quero deixar algumas dicas de como eu vejo boas documentações. Empresas como o Stripe, Vercel, Twillio e Resend para mim são as que mais dominaram a "arte de documentar" as coisas que eles tem. As docs são extremamente bem feitas e fáceis de ler, também são mantidas atualizadas.

E o que torna uma documentação boa?

1. Faça a página inicial ser um guia, o Stripe faz isso muito bem, guiando você pelos produtos
2. Ensine os fundamentos da sua tecnologia, não só que ela existe lá, a Vercel tem uma página muito boa para isso
3. Código deve sempre estar presente na forma de um tutorial, um passo a passo ou guia simples, como na Resend
4. Cubra casos de uso comuns entre os usuários com documentações específicas para elas, que nem essa página do SendGrid

Mas como manter a documentação atualizada? O código muda, mas ele não está ligado à documentação... Mas e se estivesse?

Documentação === Código

Tente escrever código que gere a documentação, não o contrário. Em vez de criar e manter a documentação separada, faça com que o código seja a fonte da verdade. Ferramentas como o protobuf ou a spec da OpenAPI são excelentes para manter contratos documentados. Por que não gerar a documentação diretamente a partir delas?

Se você acha que manter a documentação é muito complicado, pare de mantê-la manualmente. Mantenha apenas o código e faça com que ele gere a documentação automaticamente. Não permita atualizar um sem o outro. Existem várias ferramentas que permitem isso tanto com comentários (JS/TSDoc) quanto no próprio código. Eu, por exemplo, já criei uma que transforma rotas diretamente em specs da OpenAPI.

O que quero dizer é que você não precisa manter a documentação separada; você pode delegar essa tarefa ao seu código. Assim, você sempre saberá o que está no código e terá a documentação atualizada sem esforço extra.

Escreva comentários que importam

Comentários devem contar uma história. Se a função é óbvia, não é necessário comentar. A aplicação provavelmente nem notará um comentário a mais ou a falta dele, mas comentários inúteis fazem o oposto do que precisamos.

Quando um comentário ruim é adicionado, você não consegue distinguir um bom de um ruim, e acaba gastando tempo lendo coisas desnecessárias. Ninguém gosta de ler mais do que precisa.

Porém, quando você fornece todo o contexto sobre o motivo de uma função ou até mesmo de uma linha de código, você poupa horas de debugging, tanto suas quanto de outras pessoas no futuro.

Ao contrário do que muitos dizem, documentações, se feitas corretamente, podem trazer muitos benefícios, como uma curva de aprendizado menor e maior facilidade para manter um projeto a longo prazo. Foi graças a documentações como essas que consegui manter este projeto por tanto tempo, por exemplo.

E você? Qual é a sua opinião sobre documentações?

Há mais ou menos 6 meses eu resolvi que era hora de deixar de lado o preciosismo e largar meu editor de longa data (VSCode) e começar a usar esse tão famoso Vim. Quando terminei de configurar e estava satisfeito com meu progresso inicial, escrevi esse artigo. Nele, eu documentei grande parte da minha jornada através da instalação e das primeiras impressões com o Vim, mas eu não quis me estender muito sobre o uso porque eu não tinha usado o editor por tempo o suficiente para ter opiniões (e nem estatísticas) sobre o uso dele.

Agora é diferente. Depois de 6 meses usando somente o Neovim como meu editor principal (na real, como o único editor) eu quero destrinchar tudo que eu aprendi, o que eu ganhei, o que eu perdi, o que eu mais gostei e o que eu achei estranho nessa nova experiência.

Vamos lá!

Pausa para o aviso!

🔥 Quer dominar TypeScript de verdade? 🔥

Se você quer escrever código mais seguro, escalável e sem surpresas, A Formação TS Essencial é o curso que vai te levar do básico ao avançado com prática real! São mais de 16 horas de conteúdo, 3 projetos práticos com cenários reais, exercícios, um minicurso de validação com Zod e acesso à comunidade no Discord, onde você pode trocar ideias e tirar dúvidas direto comigo.

💡 Já somos mais de 300 alunos e, só aqui na newsletter, você ganha 15% de desconto com o cupom exclusivo FTSBKLG8! Mas corre, porque é por tempo limitado.

🎯 Garanta sua vaga agora: https://formacaots.com.br

💌 Me ajude a manter a newsletter no ar! Se você quer patrocinar e alcançar milhares de devs toda edição, entre em contato: hello@lsantos.dev.

Por que comecei a usar o Vim?

Eu uso o VSCode desde muito provavelmente o lançamento, lembro de ter usado a versão beta e pensado "meu Deus isso é horrível" e voltado diretamente para o meu Sublime Text. Mas, alguns anos depois o VSCode se tornou provavelmente o melhor e mais poderoso editor de código de todos, hoje eu vejo poucos motivos para você começar usando outro editor que não seja ele.

Mas então... Por que eu comecei a usar o Vim?

Desde que eu comecei em desenvolvimento eu já conhecia o vi e outros editores como o nano para quando eu precisava fazer um SSH em alguma máquina, ou então configurar algum servidor, mas eu nunca me importei em aprender de verdade como o Vi/Vim funcionava até meados de 2016 em um PHPExperience em São Paulo.

Nesse dia o Augusto Pascutti fez uma palestra chamada "Por que Vim?", mostrando os vários pontos interessantes de usar o editor. Macros, movimentações, configuração aberta e muito mais. Desde esse dia eu mantive o Vim no radar (com uma curiosidade absurda) mas, sempre que eu tentava começar, a curva de aprendizado era muito alta e eu desistia porque demorava muito tempo.

Os anos foram passando, eu fiquei cada vez mais preso no VSCode, eu adorava estar por lá, meu ambiente era inteiro modificado, eu consegui deixar o editor realmente como a minha casa. Mas infelizmente eu ainda precisava ter o editor instalado no computador... E o VSCode não é necessariamente muito leve para rodar em todos os lugares, mesmo com avanços como a separação do servidor da interface e etc...

Mas, o ponto final que me fez mudar para o Vim, foi perceber quanto tempo eu perdia parando de escrever ou tirando a mão do teclado para pegar no mouse e mover as coisas... Se você nunca pensou nisso, pare um pouco, grave você mesmo(a) usando o computador em timelapse e veja a quantidade de vezes que a sua mão faz o movimento lateral de pegar no mouse e depois voltar... Isso estava me incomodando muito - A ponto de eu estar trabalhando em um teclado especial com um mouse embutido.

Eu ODEIO mouses no geral, se eu tenho a opção de fazer tudo em um terminal eu farei... Talvez isso seja o resquício da minha época de sysadmin com AKS. Mas eu adoro TUIs e tudo que não tenha interface gráfica simplesmente porque é muito mais responsivo.

Então, quando eu instalei meu dual boot com o Arch Linux, eu resolvi instalar um Window manager chamado Sway, que dispensa o uso do mouse para a maioria das coisas, então eu pensei: "Por que não começar a abandonar o mouse de vez?" e foi ai que eu resolvi sair completamente do VSCode e usar apenas o Vim.

Infelizmente o uso de GUIs ainda é muito grande e a maioria delas não tem um suporte muito bom para teclado, com atalhos ou movimentações, então infelizmente não vamos ter como abandonar o mouse de uma vez por todas...

Eu também tentei usar a extensão do Vim para o VSCode, mas ele é um editor feito para ser usado com um mouse, então a movimentação não era tão fluida na interface, o que era um problema.

Adaptação inicial

Vou pular a parte da configuração e tudo mais porque já comentei sobre no primeiro artigo

O principal no início foi me forçar a criar o hábito de usar o Vim. Porque eu estava tão acostumado com o VSCode que, por padrão, eu já abria o editor direto.

Para me forçar a usar o Vim, eu removi o VSCode da minha área de trabalho, removi os bindings de arquivos que abririam no VSCode e me forcei a apenas abrir o terminal quando eu iniciasse a máquina. Alguns dias fazendo isso foram suficiente para pegar o hábito. Outra coisa que ajudou bastante foi que eu gostava do look and feel do Nvim, então era legal estar com ele aberto, e ele é muito responsivo então as coisas acontecem muito rápido e você fica se sentindo um hacker.

Quando o primeiro empecilho acabou, o segundo era o pior de todos: lembrar das teclas...

O primeiro problema

Essa é, sem duvida, a parte mais complicada de tudo que eu tive que fazer para usar o Vim. As principais teclas que todo mundo conhece (hjkl) são bem simples, a maioria dos comandos básicos como trocar de modo (com i, v), substituir (c, C, r e R) e as modificações de linhas com O, dd, D, etc também são bem intuitivos.

O problema é quando você tem que interagir com o resto que não é texto, por exemplo, a lista de arquivos, abrir o gerenciador do Git (com o LazyGit) e interagir com popups que aparecem na tela, como as completions do intellisense e os quick peaks que mostram as hints de tipo no TypeScript. Não porque elas são ruins, mas porque em cada novo painel, as teclas mudam.

Por exemplo, o Telescope (equivalente ao ctrl+p do VSCode) tem um campo de busca, então as teclas padrão de movimentação não funcionam (porque elas estão digitando no input de texto), ao invés disso a combinação é ctrl-p para subir e ctrl+n para descer (para previous e next). Além disso ele tem uma pequena preview do lado direito que você pode movimentar não com ctrl+hjkl, mas com ctrl+dfku...

Mas isso é apenas no modo de inserção, quando trocamos para o modo normal, as teclas de movimentação voltam ao padrão, mas as da preview não...

Além disso, o equivalente ao "Find All" do VSCode, é uma mistura de ripgrep com fzf que busca em todos os arquivos via regex e é uma das ferramentas mais poderosas do Nvim, mas não tem uma seleção de modos... Então para mover os resultados sem usar as setas (que estão mais longe no teclado), temos que usar o que? O que seria intuitivo: ctrl+hjkl...

Porém, por incrível que pareça, você usa tanto essas ferramentas (especialmente o telescope) que essas combinações meio que ficam gravadas na sua cabeça. No final do primeiro mês eu já estava 100% confortável com a UI do Vim, inclusive movendo o cursor pelas janelas e tudo mais.

No final, as teclas não são tanto um problema porque o próprio LazyVim tem um comando para buscar todas as teclas, o <leader>sk:

Além disso o pacote whichkey mostra todas as combinações possíveis de uma tecla pressionada:

Isso torna toda a experiência muito boa e aquém de um VSCode, se você quer explorar o editor, basta passar pelas teclas.

O melhor e pior ao mesmo tempo

Outra coisa que vale a pena pontuar é que, durante o primeiro mês (e até hoje, na verdade) eu estou sempre fazendo pequenos tweaks aqui e ali na minha configuração do LazyVim, especialmente quando ele atualiza e muda padrões. Isso é relativamente chato, provavelmente é a coisa que eu mais odeio no Nvim até o momento, mas também é uma das que eu mais gosto: a configuração.

Enquanto a configuração é extremamente permissiva e você pode virtualmente fazer qualquer coisa, ela também é extremamente complexa de entender. A documentação é basicamente inexistente, o LSP de Lua tenta fazer o melhor para extrair as funções e mostrar o que você pode usar, mas a maioria das funções do Vim não são conhecidas, o autocompletion é bem ruim e no geral você se vê procurando coisas na Internet mais do que qualquer coisa.

A configuração do hierárquica é hieráquica, então as configurações iniciais vão ser sobrescritas por uma configuração posterior, portanto a ordem como os plugins e configurações são carregados importa. E isso é uma droga porque não existe um autocompletion bonitinho para o que você pode colocar ali, é sempre um jogo de testes.

Alguma programação em Lua quase sempre é necessário, e muitas vezes obrigatório. Em outros casos a configuração base é suficiente, no geral, a documentação do LazyVim em si é muito boa e ajuda MUITO, ela é bem definida e explicada, mas você eventualmente vai cair em problemas.

LSPs

O maior problema que eu tive foi configurar os LSPs. As configurações padrão para a maioria das linguagens que eu uso é ok, porém eu tive um conflito com Node e Deno. Como ambos usam a mesma linguagem porém tem arquivos-chave diferentes, eu tive que escrever uma função para verificar se o repositório era um repositório Deno ou Node e evitar que eu tenha tanto o LSP de Node quando o de Deno no mesmo arquivo.

LSPs são Language Server Protocols, um protocolo criado pela Microsoft para introduzir a capacidade de um editor se conectar a um serviço que tem a inteligência da linguagem de forma separada, independente do editor, para dar coisas como completions, intellisense e etc de forma distribuída.

Até agora eu só falei coisas ruins, ou coisas que gostei menos do que os demais, será que o Vim é bom assim mesmo?

O ponto de virada

Depois de mais ou menos 2 meses usando o Vim diariamente eu estava pensando que não iria ter nenhuma mudança, eu não estava me sentindo mais "rápido" ou com "super poderes", até o dia que eu precisei modificar um arquivo realmente grande.

Como eu estava com um pouco de pressa e teria que alterar uma série de coisas no arquivo com Regex, eu tentei usar o VSCode logo de cara, mas ele não abriu o arquivo... Então tentei abrir com o Vim e ele nem sofreu, enquanto o VSCode estava usando mais de 2gb de memória só para abrir o arquivo, meu Nvim estava com o arquivo aberto, funcional usando meros 120mb. Aí foi quando eu percebi o ganho além do desenvolvimento.

Eu estava tão focado em usar o editor que eu não cheguei a perceber os verdadeiros super poderes que eu estava ganhando. Primeiro de tudo, eu estava usando cerca de 45% a menos de recursos do meu computador, uma economia absurda para um editor de código. Além disso o editor é muito responsivo, quase tudo que você faz acontece praticamente instantâneamente, tudo isso sem tirar a mão do teclado. Eu considero isso um super poder.

Dentro do código, eu comecei a perceber que eu ganhei uma memória muscular para algumas coisas, por exemplo:

• Apertar :wq ou :w quase sempre em todo lugar
• Apertar esc depois de digitar uma linha (inclusive durante esse artigo)
• Tentar mover qualquer coisa com jhkl
• Tentar navegar com w e b entre linhas e { no código
• Pesquisar qualquer coisa apertando /
• Tentar usar o <leader> (que no meu caso é o espaço) para iniciar comandos
• Copiar coisas com y e colar com p

Isso está tão automático para mim que virou algo natural, quando eu não consigo fazer algum desses comandos eu me sinto estranho. Além disso eu comecei a perceber que eu estava cada vez mais usando outros comandos do Vim que eu não usava antes, eu estava aprendendo!

Melhorias progressivas

Um dos meus checkpoints foi ter começado a fazer o uso extensivo de vim words, que são conjuntos de teclas que permitem que você faça várias ações ao mesmo tempo, por exemplo, se eu quiser deletar um único caractere eu posso apertar x, então se eu quiser deletar uma palavra inteira eu posso só ficar apertando x até o fim. Mas eu também posso falar para o Vim deletar tudo dentro daquela palavra com diw, ou delete in word sem deletar os espaços, ou deletar tudo em volta com daw, onde o "a" é around.

Essas são as conhecidas Vim words, que eu já sabia que existiam mas nunca tinha usado extensivamente. E você pode combinar aw e iw com basicamente qualquer coisa, por exemplo, o LazyVim tem um plugin chamado surround que permite que você envolva qualquer coisa com qualquer outra coisa, por exemplo:

function foo () {
    const codigo = '1'
}

Se eu quiser adicionar um try/catch ao redor desse código, eu posso entrar no modo de seleção de linha com V, digitar gsa? e incluir try { no primeiro prompt e } catch {} no segundo:

E o resultado vai ser o esperado:

function foo () {
    try {const codigo = '1'} catch {}
}

Outros comandos mais avançados como edição em bloco ctrl+V também são super úteis, e muito mais poderosos do que a edição de multi cursor do VSCode, porque você pode editar múltiplas colunas ao mesmo tempo.

Quando isso não é suficiente, você pode usar o famoso replace no estilo sed , que foi uma ferramenta essencial para eu poder ter uma melhoria drástica na minha eficiência, por exemplo, se eu quisesse substituir uma sequencia grande de chamadas:

controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))
controller.run(new URN<'application'>(args.params.applicationId))

Eu quero remover todas as new URN... e deixar apenas a chamada para o args.params.application, eu posso usar a substituição %s/(new URN<'application'>\(([a-zA-Z\.]*)\))/\1 para poder trocar tudo de uma vez:

O comando em si parece bem complexo, mas vamos quebrar pra ficar mais fácil. Aqui eu estou:

1. Pegando tudo que é (new URN<'application'>(
2. Criando um grupo contendo [a-zA-Z\.]*, ou seja, todas as letras e o ponto
3. Pegando os )) finais
4. Substituindo tudo por \1 que denota o primeiro grupo que criamos no 2

Isso é algo que jamais eu iria fazer tão "simples" em outro lugar.

Outras coisas que eu notei

Além dessas pequenas demonstrações, eu também notei algumas coisas sobre Vim que valem a pena serem comentadas:

• Macros são muito bons, mas não são para todas as situações
• Aprender a lidar com buffers e janelas é essencial, saber o que é um buffer, o que é uma janela, o que é um painel e essas coisas
• O Vim possui um conjunto de registradores que você pode acessar com " no Lazy ou com :reg , esses registradores são poderosos porque permitem que você, por exemplo, copie multiplos textos de uma vez com "<numero do reg>y e cole de vários também com "<numero>p, o lazy tem uma lista bem legal de registradores

• Além de registradores o Lazy mantém uma lista de bookmarks (ou só marks) que permitem que você salve um local no código e volte para lá instantâneamente, em qualquer buffer, isso é muito útil para se mover entre duas localizações rápidamente com '', mas você pode criar uma marca com m<letra> e depois ir até ela com '<letra>

• O Vim tem um terminal integrado com :term mas o Lazy tem um terminal em uma aba embaixo assim como o VSCode que permite você usar os comandos do Vim normalmente, mas eu achei um pouco mais fácil usar uma outra aba do mesmo terminal principalmente porque isso pode causar lag no editor.

Veredito, valeu a pena?

Depois de 6 meses usando sem parar, eu posso dizer que essa foi a melhor escolha que eu já fiz. A forma como o Vim é rápido e instantâneo é incrível, usar o teclado ao invés do mouse para movimentação e para ações dentro do editor é ordens de grandeza mais rápido e mais eficiente do que usar um mouse tradicional (mesmo que o neovim suporte mouse).

A integração do editor com o que você está fazendo e o estado de "flow" que você entra estando em uma tela preta sem nenhuma distração é simplesmente incrível. Além de que tudo fica muito mais rápido e muito mais eficiente conforme você vai pegando mais dicas e aprendendo mais coisas sobre o Vim.

Acredito que o principal para mim é que eu posso ver que estou melhorando, é fácil ver uma melhoria, é fácil entender o que está acontecendo, o editor é intuitivo depois que você aprende os conceitos básicos sob o qual ele opera. E você perceber que existe uma melhoria constante e estar constantemente descobrindo novas coisas, novas teclas, novas combinações, novos workflows é simplesmente incrível, até para um editor que tem mais de 40 anos.

Se você já tentou usar o Vim, deixa seu comentário nas minhas redes! Eu quero muito saber como foi a sua experiência com o Vim!

Até mais!

Mais um dia, mais um backlog! Hoje, trago algo diferente: As 10 lições mais importantes que aprendi em 13 anos como dev.

Muita gente já me perguntou sobre dicas e aprendizados essenciais na minha carreira. Confesso que deixei essa ideia de lado por um tempo, até que me deparei com um post no final do ano que me fez lembrar dessas perguntas.

Então hoje eu quero falar sobre as 10 lições mais importantes que eu aprendi em 13 anos de carreira como dev. Lembrando que essas lições estão só no âmbito de desenvolvimento, então tudo que eu falar por aqui é relacionado estritamente à isso.

1 - Seu código não é seu: Nada vai ser como você quer

A primeira (e, talvez, mais importante) lição é que o código nunca será exatamente como você quer. A única maneira de fazer tudo do seu jeito é trabalhando sozinho em um projeto pessoal. Mas, no trabalho em equipe, você sempre vai precisar ceder e se adaptar.

No começo, eu queria que tudo fosse do meu jeito. Quando alguém criticava meu código, eu achava que era um ataque pessoal. Com o tempo, percebi que estava errado.

O código não é só seu. Ele precisa ser fácil de entender para que outras pessoas possam mexer nele no futuro. O mais importante não é escrever do jeito que você gosta, mas sim garantir que toda a equipe consiga trabalhar bem com ele. Aprender a aceitar feedbacks, conversar sobre soluções e deixar o orgulho de lado são habilidades essenciais para um bom programador.

2 - Elegância é para moda, você precisa ser pragmático

Quantas vezes você já encontrou um código impossível de entender? Ou um código tão abstrato que parece tentar prever todos os casos de uso do mundo? Ou então aquele código "elegante" que só o autor compreende?

A realidade é que o código que a gente faz não é para a máquina, a gente já resolveu esse problema há muito tempo com compiladores. Eles otimizam seu código para que a máquina leia da forma mais eficiente possível. O seu trabalho é fazer código que outras pessoas vão ler e dar manutenção. Uma frase que me marcou muito foi:

A maioria dos sistemas não são bons o suficiente para se tornarem legados.

Isso é uma verdade brutal. Apenas sistemas bem projetados e robustos sobrevivem por anos ou décadas. Eu comento bastante sobre isso, mas um bom sistema, para mim, é composto de três pilares:

• Documentação bem escrita e código que seja legível e comentado
• Que segue as práticas atuais do time
• Não possui abstrações complexas e é simples o suficiente dentro do seu escopo

Já me crucificaram muito por falar de comentar código, ou então quando eu falo veementemente que não gosto de programação funcional porque eu acho que, além de difícil de ler e entender, exige um conhecimento prévio bem grande. Mas essas afirmações são fundadas em uma simples frase:

Nunca assuma que todas as pessoas são iguais a você

Nem todos vão entender imediatamente o código que você escreveu. Nem todos conhecem programação funcional. E, honestamente, você mesmo pode não compreender seu próprio código daqui a alguns meses se não deixá-lo claro.

Priorize sempre a facilidade de manutenção e o alinhamento com as práticas da equipe, ao invés de criar soluções "elegantes", mas difíceis de entender.

3 - Não existe planejamento

Quantas vezes já ouvi a frase: "Precisamos entregar isso amanhã, é urgente!" Mas quando tudo é urgente, nada é urgente, certo? Essa foi uma das lições mais importantes que aprendi trabalhando em startups:

O que importa é o que está acontecendo agora

Você pode planejar seu projeto e seu sistema o quanto quiser, mas se algo mais importante surgir no meio do caminho, sem dúvida, todo o planejamento será jogado de lado para perseguir esse novo objetivo. Startups são basicamente fundadas nessa ideia de serem barcos pequenos e rápidos, fáceis de virar e pegar o vento mais forte naquele momento. Por isso, um planejamento sólido raramente sobrevive por muito tempo.

Já em grandes empresas, o problema é o oposto: Planejamento em excesso. Tudo leva meses para acontecer, mas, ao mesmo tempo, tudo é tratado como prioridade máxima. O resultado? Muitas vezes ninguém sabe exatamente por que algo precisa ser feito e, depois de entregue, ninguém sabe quem pediu ou para que serve.

No fim das contas, sempre achei mais eficiente focar nos objetivos em vez de um planejamento rígido. Em vez de tentar prever cada passo, o ideal é definir claramente "o que precisa ser feito" e manter uma visão de longo prazo. Isso gera resultados mais consistentes e evita desperdício de tempo com planos que logo se tornam obsoletos.

4 - As vezes menos é mais

Quantas vezes a gente não ficou empolgado com uma ideia ou com um framework novo ou com um novo conceito que queríamos tanto aplicar que acabamos fazendo um FizzBuzz Enterprise?

A grande lição aqui é que, muitas vezes, nosso projeto não é grande ou crítico o suficiente para justificar todas as tecnologias e padrões que queremos aplicar. Uma boa arquitetura é importante, mas será que você realmente precisa de K-anonymity e de todos os design patterns existentes para um simples sistema de to-do list? Aquele pequeno sistema com 10 clientes realmente precisa se proteger contra todas as CVEs já registradas, mesmo quando aplicar essas correções pode ser mais trabalhoso do que benéfico?

As vezes menos é mais, tirar coisas do projeto para que ele possa ir para frente é o caminho mais rápido para saber se você precisa ou não melhorar a arquitetura do seu sistema.

5 - Tecnologia é um trade-off

A clássica piada do desenvolvedor sênior que responde tudo com "depende" tem um fundo de verdade. Não existe uma bala de prata em tecnologia que resolva todos os problemas. Um professor meu na faculdade costumava dizer:

Toda decisão que melhora algo em uma parte, piora algo em outra parte

Ele comparava a programação a um pacto: Você sempre sacrifica algo para obter uma solução, porque qualquer escolha tem efeitos colaterais.

O importante é lembrar que você nunca vai tomar boas decisões, você sempre vai tomar decisões que são boas para algo e ruins para outro algo, um exemplo clássico disso é segurança: Quanto melhor e mais resistente o algoritmo de criptografia, mais lento ele vai ser. Ou então quando eu comentei no meu artigo sobre RSA, as chaves podem ser arbitrariamente grandes, mas existe um ponto onde ela é suficiente.

Os suecos tem uma palavra chamada lagom, que é uma forma de dizer "apenas o suficiente" ou "nem mais, nem menos". Esse conceito resume bem essa lição: A melhor escolha é aquela que equilibra necessidades sem excessos.

6 - Tecnologia vem e vai, bases ficam

Isso é algo que todo desenvolvedor aprende mais cedo ou mais tarde. É uma daquelas lições fundamentais da carreira.

Chega um momento em que você se cansa de aprender algo novo todos os dias, de estar sempre correndo atrás do framework da moda, da última inovação em IA ou do mais recente padrão de arquitetura. Se você baseia seu conhecimento apenas em ferramentas, é como um pedreiro que acredita que só pode martelar com um martelo, sem perceber que qualquer coisa pesada pode cumprir a mesma função.

A tecnologia funciona da mesma forma. As ferramentas vêm e vão. Eu comecei com Delphi e Visual Basic, que hoje quase não existem. Se meu aprendizado tivesse sido focado apenas neles, minha carreira já teria chegado ao fim. O que realmente importa é entender os fundamentos, porque eles continuam relevantes independentemente da tecnologia usada.

Preste atenção nas aulas de algoritmos, complexidade ciclomática e até no pseudocódigo. Talvez escrever código no papel, como os Maias e Astecas faziam, já te ajude muito a lembrar.

Porque, quando a hype da linguagem atual passar, você saberá como continuar para a próxima. Mas lembre-se:

O mercado sempre vai estar em hype com alguma coisa, isso não significa que você tem que surfar todas as ondas

7 - Feito é melhor do que perfeito?

Existia uma frase que um CTO meu falava que me deixava muito irritado: "Feito é melhor que perfeito". E isso acontecia por dois motivos:

1. Eu achava que tudo deveria ser perfeito (veja o item 1)
2. Eu não suportava a ideia de entregar as coisas sem estarem finalizadas

Depois de muito tempo eu entendo o que essa frase realmente significa. Não é que você precise entregar as coisas mal feitas e de qualquer jeito só para que o sistema vá para frente. Se alguém está te pedindo para fazer isso, então você está com toda a razão em recusar, mas é sobre saber dosar o quanto é "BOM O SUFICIENTE" (LAGOM).

Existe um manifesto muito legal que descreve tudo que eu estou falando aqui. Ele se chama The cult of done (video):

8 - Seja seu próprio oponente

Por muito tempo, eu via outras pessoas falando sobre os prêmios que ganharam e as conquistas que alcançaram. Eu olhava para tudo isso com admiração, querendo estar naquele mesmo lugar. Meu grande sonho sempre foi criar algo útil, algo que as pessoas realmente usassem e gostassem. Eu queria ser o Ken Thompson, o Dennis Ritchie ou, quem sabe, o Bill Joy da modernidade.

Com o tempo, percebi que me comparava demais com os outros, sempre me sentindo menos importante por não ter algo grandioso para mostrar. Isso me fazia mal. Mas quando parei para refletir, notei que as pessoas que fizeram coisas incríveis tinham apenas um verdadeiro adversário: Elas mesmas.

Você só precisa se comparar com quem você era ontem e buscar ser melhor do que essa versão. Ninguém mais importa nessa equação.

Faça algo que faça sentido para você. Todo o resto é consequência.

9 - Faça o que você gosta

Parece clichê até você ser forçado a fazer algo que não gosta. E isso aconteceu comigo durante um emprego que tive. Era uma empresa que eu queria muito trabalhar, mas quando entrei percebi que eu estava fazendo algo que estava cada vez mais distante do que eu gostava de fazer, da minha realidade, do que me deixava feliz. E isso impactou não só meu rendimento, mas também a forma como eu via meu próprio trabalho.

A verdade é que você precisa direcionar sua carreira para algo que realmente gosta. Não adianta insistir em front-end se sua paixão é back-end, ou se aventurar em infraestrutura quando o que realmente te empolga é banco de dados. Perseguir o que você gosta é essencial, mas isso não acontece do dia para a noite. Muitas vezes, será necessário passar por um período fazendo algo que não te satisfaz para dar o próximo passo. É o famoso "um passo para trás para dar dois para frente".

Mas também não se acomode demais nas coisas que você está fazendo e nem foque só em fazer as coisas que você gosta a todo momento, até porque nada de bom acontece dentro da sua zona de conforto.

10 - Talk is cheap

Durante todos esses anos, eu acabei notando que a máxima "Quem muito fala pouco faz" foi se tornando cada vez mais verdade (inclusive temos uma edição só falando disso). No mundo atual, isso se intensifica ainda mais com a explosão de influenciadores e o excesso de informações despejadas sobre nós. Não acredite em influenciadores, seja você a sua própria influência.

O ponto é que você não deve acreditar somente no que as pessoas falam pra você, muita gente fala demais, vende coisas demais mas nunca de fato coloca a mão na massa. A prova disso é que a maioria das pessoas que criaram coisas incríveis sequer tem rede social ou, se tem, mantêm um perfil super discreto.

Busque suas próprias conclusões. É válido se inspirar em outras pessoas, afinal, nada nasce do zero. Mas jamais permita que alguém guie todo o seu pensamento. Essa lição vale para tudo na vida, não apenas para o desenvolvimento.

Quero saber quais lições que você aprendeu ao longo da sua carreira! Comenta lá nas minhas redes!

Mais um dia e mais um backlog no ar! Hoje quero trazer algo diferente: não é sobre história, nem diretamente sobre desenvolvimento, mas sobre devs no geral. Vamos falar sobre o ato de fazer engenharia e a profissão de engenheiro de software como um todo.

Recentemente, recebi um post interessante do Sean Goedecke intitulado: "What makes strong engineers strong", ou, em português, "O que torna os engenheiros fortes, de fato, fortes." (a tradução não ajudou muito). Aqui, força não tem a ver com vigor físico, mas sim com execução, responsabilidade e a habilidade de entregar qualquer tipo de trabalho.

Inicialmente, a ideia era apenas comentar sobre esse artigo, mas descobri um artigo anterior onde o autor também discute o conceito de "engenheiros fortes" e "engenheiros fracos". Isso me deixou um tanto consternado...

Então, vamos começar pelo começo.

Como chegamos aqui?

Antes de definir o que é um engenheiro forte ou fraco, eu tenho que explicar como a gente chegou aqui.

O primeiro artigo menciona um famoso estudo da universidade de Stanford que mediu a produtividade de vários devs em mais de 100 empresas e descobriu que aproximadamente 9.5% de qualquer engenheiro de software em uma empresa está, essencialmente, fazendo nada. O chamado 0.1x engineer, uma alusão ao termo fantástico "10x engineer", criado por um investidor chamado Shekhar Kirani em uma thread do Twitter em 2019. Em teoria, os 10x engineers são seres míticos que entregam todo o tipo de coisa, enquanto 0.1x engineers são o oposto.

Eu cheguei a ler o estudo, mas achei estranho que ele não menciona em nenhum momento uma divisão de trabalhadores remotos ou no escritório, então eu não sei de onde vieram os dados relacionados às porcentagens de eficiência. Da mesma forma, o estudo não menciona nenhum tipo de resultado financeiro, então também não sei de onde vieram os dados para calcular que esses engenheiros geram um prejuízo de $500B:

Pode ser que esse seja outro estudo com base na mesma fonte. Contudo, não consegui confirmar de onde vieram esses números além do que está nas imagens. Se alguém souber, me avise.

De acordo com o estudo, 108 empresas enviaram 1,73 milhão de commits de 50.935 engenheiros. Esses commits foram combinados com repositórios públicos numa proporção de 1 commit público para cada 5 privados. Após normalizações, 70 commits foram selecionados como amostra, e todas as alegações foram baseadas neles.

Uma das métricas usadas foi a quantidade de commits em um mês, algo que até o próprio autor considera pouco confiável. E já foi provado que não é uma boa métrica:

Mas, ao que parece, o objetivo do estudo não era medir a eficiência dos participantes, mas criar um modelo para avaliar a eficiência de programadores — algo que praticamente todo mundo na indústria tenta fazer desde sempre.

Enfim, esse foi o estudo que deu início a tudo isso. Mas como, afinal, definimos o que é um engenheiro "forte" ou "fraco"?

Pausa para um aviso!

Essa newsletter só existe graças à comunidade e aos patrocinadores! E hoje o apoio vem da Remessa Online, que está ajudando demais a manter este projeto vivo 💙.

Muitas pessoas me procuram para perguntar como é trabalhar para fora do Brasil e uma das principais dúvidas é sobre como receber o salário vindo de outro país.

Eu recomendo (inclusive já usava) a Remessa Online, não só porque ela me ajudou a facilitar esse processo, mas também porque as taxas são muito mais baratas (inclusive na conversão) do que se eu recebesse por um banco tradicional.

E tem mais vantagens: o dinheiro entra super rápido na sua conta, a plataforma é super segura, o app intuitivo e todo suporte é em português.

Pra economizar ainda mais, é só usar o cupom LSANTOSDEV para ter 15% nas suas operações.

👉 Clica aqui pra transferir com a menor taxa do mercado!

🥺 Quer ajudar a newsletter a crescer? Se tem uma marca ou produto que se conecta com essa comunidade, manda um e-mail para hello@lsantos.dev. 

A lenda da eficiência em tecnologia

O primeiro artigo define engenheiros fortes e fracos como:

Engenheiros fortes conseguem fazer tarefas que engenheiros fracos simplesmente não conseguem. Nem se lhes fosse dado todo o tempo do mundo.

Porém, o que são essas tarefas? Segundo o artigo:

• Bugs muito complicados como race conditions;
• Entregar melhorias significativas em código legado, seja lá o que signifique "significativas";
• Fazer mudanças que exigem uma grande refatoração arquitetural.

São pontos válidos, mas, na minha opinião, insuficientes. Por exemplo, essas tarefas são algo que tanto engenheiros fortes quanto fracos já tiveram experiência? Ou ambos estão lidando com elas pela primeira vez?

Se alguém é considerado fraco por tentar e falhar ao resolver um problema completamente novo, isso nos tornaria péssimos devs quando o assunto é algo tão complexo quanto encher de combustível um foguete espacial.

O ponto é que isso não é algo preto no branco, e o próprio autor reconhece isso. No entanto, discordo da categorização que ele faz das pessoas. Ele classifica engenheiros como fortes, regulares e fracos. Segundo ele, você pode ser um "engenheiro regular" excelente em resolver bugs complexos ou um "engenheiro fraco" muito bom em manter as coisas funcionando.

Na minha visão, as coisas não são tão simples assim.

As coisas são em tons de cinza (muito mais de 50). Eu já não sou um grande fã da separação entre junior, pleno e sênior, mas entendo o propósito quando temos que contratar. Mas não concordo de forma alguma em dividir ainda mais através de quem "consegue resolver problemas complicados". Todos nós somos ótimos em algo, péssimos em outro algo.

Eu quero acreditar que sou um excelente programador, provavelmente é a melhor coisa que eu faço, mas eu sou um péssimo jogador de futebol.

Você não pode – e nem vai – ser bom em tudo, isso se chama: ser uma pessoa normal.

O que faz um bom dev

No primeiro artigo ele diz enfaticamente:

... A real medida do talento não é a velocidade ou o volume de entrega, mas a habilidade de fazer tarefas que outros não conseguem.

Porém, no segundo artigo, o autor apresenta os 4 pilares dos engenheiros fortes:

• Velocidade;
• Pragmatismo;
• Confiança em si mesmo;
• Habilidade técnica.

Isso me parece um pouco contraditório. Logo de cara, a velocidade aparece como um dos elementos, e, embora o volume de entrega não seja listado diretamente, é uma métrica que está claramente associada à velocidade. Afinal, quanto mais rápido você trabalha, mais coisas são entregues.

Concordo com três dos pilares, mas a velocidade merece uma discussão à parte. Já a habilidade técnica, acho que é algo implícito — você precisa de um certo nível de habilidade para ser um bom dev, então não vou focar nisso agora.

Velocidade

A velocidade jamais deve ser considerada a principal métrica para avaliar bons ou maus engenheiros. Embora seja importante cumprir prazos, entregar algo rápido e sem qualidade é praticamente o mesmo que não entregar nada.

Recentemente, comentei sobre isso nesta thread:

Lucas Santos (@lsantos.dev)

Muita gente acredita que ser #dev é construir software rápido, produtividade, entrega. Construir software AGORA não é difícil, o difícil é manter o software por anos. Se você consegue construir sistemas que duram ANOS com fácil manutenção, isso é engenharia de software.

Bluesky Social

Entregar código rápido e "pra agora" é uma das coisas mais fáceis da engenharia de software. Se você acredita que criar um template no Bolt usando prompts do ChatGPT para automatizar tudo e entregar "valor rápido" é uma prática ideal, então temos opiniões muito diferentes.

O problema é que, nesse cenário, você provavelmente não viu nada do código produzido. Isso significa que, na maioria das vezes, será extremamente difícil mantê-lo a longo prazo — se é que será possível. E essa é a parte mais desafiadora do desenvolvimento de software: entregar algo agora que ainda seja funcional e sustentável daqui a 10 anos.

Uma história engraçada foi meu primeiro projeto grande como freelancer, uns 8 ou 9 anos atrás. Era um sistema bem simples, e eu fiz o código o mais rápido que consegui pra entregar o MVP. O cliente adorou, o produto funcionou por 2 anos e ninguém nunca precisou mexer. Arrasei, né? Não.

Dois anos depois, eles precisaram fazer uma coisa super simples: adicionar mais opções na página. E aí veio o problema... Eu não conseguia dar manutenção no código. Tava tudo tão acoplado que era mais fácil refazer do zero do que tentar mudar o que já estava feito.

Tudo isso porque eu pensei no agora e nem sequer dei valor para o que eu precisaria fazer para manter isso no futuro, eu fui muito rápido, mas a que custo?

Claro que temos que pesar o que precisamos no momento, não podemos ser sempre perfeitos e entregar o melhor possível, muitas vezes o feito é melhor do que perfeito, e está tudo bem.

Qualidade vs Eficiência

Eu sempre gosto de lembrar que ser um "bom engenheiro" é bem diferente de ser um "engenheiro eficiente". Geralmente, bons engenheiros acabam sendo eficientes, mas nem todo engenheiro eficiente é necessariamente bom.

A linha entre eficiência e pura tentativa e erro é bem fina. Engenheiros puramente eficientes tendem a errar muito e rápido, iterando sobre cada falha até chegar a algo mais sólido e confiável. Sabe quem também faz isso? Machine learning.

Isso não quer dizer que bons devs não iterem, muito pelo contrário. Bons devs iteram sim para melhorar as soluções, mas a diferença está no como. A iteração não é feita em cima de um monte de "meias aplicações", mas em uma ideia implementada da melhor forma possível para aquele momento. Cada nova iteração é uma melhoria da anterior, não uma mudança completa.

E o próprio autor manda uma frase bem interessante:

Genialidade, geralmente, vai ao oposto à eficiência

Isso vai exatamente de encontro com o que acabei de falar. Errar rápido e consertar ainda mais rápido, pra mim, não é sinônimo de qualidade. É só um sinal de que você esgotou todas as opções que não funcionam e ficou com a primeira que dá certo, sem se preocupar se é a melhor solução ou não.

Pragmatismo e Confiança

Essas duas qualidades merecem destaque juntas, porque, na minha opinião, são as mais importantes para qualquer dev (ou pessoa técnica, no geral).

Ser pragmático é essencial, principalmente quando você precisa entregar algo. É aquela habilidade de avaliar o momento e focar no que realmente importa. Inclusive, já falei sobre isso em um vídeo:

Pensar de forma pragmática é saber a hora de largar o osso. É reconhecer quando sua solução não é a melhor, quando o que você fez precisa ser refeito ou quando ceder é a melhor escolha.

Eu costumava ficar muito bravo quando alguém dizia que eu estava errado e precisava mudar minha implementação. Mas, depois de muito bater cabeça, percebi que o código que estou escrevendo não é "meu". Eu não faço ele pra mim, faço pra quem vai chegar depois e ter que dar manutenção nisso tudo.

Codar é um trabalho de equipe, você raramente vai conseguir fazer algo sozinho para sempre.

Por outro lado, é importante saber bater o pé e confiar nas suas habilidades quando precisa defender um ponto de vista. Ser pragmático(a) e confiar no que você sabe são, pra mim, duas das principais qualidades de um bom dev.

Claro, tudo em excesso é ruim. Ser pragmático demais e abandonar tudo em favor de dados pode ser tão prejudicial quanto ser confiante demais e achar que sempre está certo.

O paradoxo do aprendizado

Existe um paradoxo interessante que explica muito sobre a dinâmica do mercado à medida que você ganha mais experiência. Sean fala algo nesse ponto com o qual concordo totalmente: por que é mais fácil encontrar "engenheiros fracos" em posições sêniores do que juniores?

A resposta é simples. Ao contratar um sênior, avaliamos mais do que apenas a capacidade técnica. Consideramos também:

• Capacidade técnica;
• Capacidade de liderança;
• Capacidade de comunicação;
• Capacidade de resolver problemas.

Já para juniores, a métrica principal é, quase sempre, a habilidade técnica. Isso facilita para que pessoas não tão boas tecnicamente consigam passar com base na lábia. Já vi isso acontecer várias vezes nos lugares onde trabalhei, e, se você ainda não viu, cedo ou tarde vai presenciar, especialmente em grandes empresas.

Outro motivo é que está tudo bem para um júnior errar — isso é esperado. Mas, socialmente, um erro vindo de um sênior não é tão bem aceito. Espera-se que alguém com 30 anos de carreira e um currículo invejável seja uma espécie de figura mitológica que nunca falha. Isso faz com que muitos sêniores precisem aprender discretamente e sozinhos, o que é bem mais complicado.

Eu, pessoalmente, não tenho nenhum medo ou receio de falar que não sei algo. Inclusive é algo que prego muito para todas as pessoas que conheço e/ou mentoro:

Não saber não é um problema. Não querer aprender é.

Então enquanto uma pessoa errar e quiser aprender, se mostrando aberta, para mim está tudo bem. O problema acontece quando uma pessoa erra e se recusa a continuar aprendendo, talvez como uma forma de esconder uma possível vergonha.

Jamais tenha medo de errar, todo mundo está aqui aprendendo.

O que eu penso disso tudo

No geral, ambos os artigos são bem interessantes e muito bem escritos. São pontos bastante interessantes para se manter na cabeça e discutir.

Pra você, o que é ser um dev bom/forte ou um dev ruim/fraco? Manda pra mim lá nas minhas redes:

• Twitter
• Bluesky
• Linkedin

Ou me manda um email se você quiser que eu comente sobre ele na próxima edição do backlog!

Até mais! E não esquece de me dar seu feedback!

Finalmente, o artigo que estou prometendo há um tempo saiu! E eu tenho muito orgulho de ser parte do time que ajudou a implementar essa funcionalidade! (mesmo apesar de não ter contribuído tanto quanto eu gostaria).

Mas o que é essa coisa toda de Node.js rodando TypeScript?

O Node roda TS?

Em algumas edições anteriores, eu falei que era possível rodar TypeScript nativamente no Node usando o TSX. Historicamente, esse sempre foi o caso, porque não tínhamos como rodar nenhum tipo de arquivo além de JavaScript com o Node. E ainda não temos.

O que acontece é que podemos utilizar loaders. Loaders são hooks especiais que permitem que a gente modifique o comportamento do module loader nativo, utilizado quando carregamos qualquer módulo ESM. Esses loaders são bastante poderosos porque eles permitem, entre outras coisas, que a gente faça ações diretamente com o código que será carregado em memória. Que é exatamente como o TSX se comporta.

Mas agora isso não é mais necessário! A partir da versão 22.6 do Node duas novas flags experimentais foram adicionadas:

• --experimental-strip-types: Que vai receber um arquivo TS e remover completamente qualquer anotação de tipo que exista nele. É a forma mais simples de transpilação, apenas removendo o que não é JavaScript nativo. É importante dizer que funcionalidades que requerem transformação de código como enum e namespace não vão funcionar.
• --experimental-transform-types: implica que a flag anterior vai estar ativa, ou seja, se você passar essa flag, a anterior vai ser automaticamente passada. E permite transformação de tipos, dessa forma podemos utilizar as funcionalidades que antes não seriam habilitadas, fazendo essencialmente o suporte quase completo a TypeScript.

O fato curioso aqui é que o nome dessa flag era para ser enable-transformation e eu sugeri que mudássemos para algo como enable-type-transformation para manter a semântica.

Essencialmente, agora você pode fazer algo assim:

$ node --experimental-transform-types index.ts

E seu arquivo vai rodar como se você estivesse rodando com TSX usando:

$ node --loader=tsx index.ts

Node v23

A versão 23 do Node mandou essa funcionalidade mais adiante ainda e fez com que a flag --experimental-strip-types ficasse ativa a todo o momento, ou seja, o loader nativo do TypeScript (que vamos ver mais embaixo aqui) verifica todos os arquivos, se eles forem um arquivo .ts então ele é transpilado com a remoção de tipos, o processo mais rápido.

Isso significa que, por padrão, você pode rodar arquivos TypeScript simples usando:

node index.ts

Mas, se o arquivo tiver transformações, como enums, ele continua não funcionando e você precisa passar a flag --experimental-transform-types para o comando.

Logo mais, provavelmente na próxima versão LTS (que deve ser a 24) essa flag deixará de ser experimental e se transformará só em --transform-types

Mas como tudo isso funciona?

Conheça o Amaro

Amaro é o nome dado a um dos módulos nativos carregados pelo Node.js, ele também vem em forma de pacote do NPM, então você pode utilizá-lo separadamente do Node também. Mas esse é o coração de tudo que está acontecendo por baixo dos panos.

O Amaro nada mais é do que um wrapper em volta do parser SWC para TypeScript em WASM, o módulo é chamado @swc/wasm-typescript e ele faz uma coisa: transpila TypeScript para JavaScript.

Desde a versão 23, quando qualquer código é importado, basicamente existe uma checagem para garantir que a opção --experimental-strip-types está ativa, se sim, importamos o parser do amaro na memória global. Se não, retornamos apenas o código.

É importante dizer que a transformação do código é feita de forma síncrona, então existe sim um pequeno overhead quando temos que carregar muitos arquivos.

Tendo a melhor experiência com TS no Node

Por mais que o Node tentasse suportar todas as configurações nativas do TypeScript, ele nunca iria suportar o tsconfig nativamente (como foi dito no artigo do Marco Ippolito), e nem faria sentido isso acontecer. Por isso, algumas configurações são necessárias para alinhar o funcionamento do TypeScript com o do Node.js.

Você também pode ver o artigo da documentação do Node sobre essa mudança.

Primeiro de tudo, você precisa setar o seu tsconfig para usar esnext como target e nodenext como module:

{
  "compilerOptions": {
    "target": "esnext",
	"module": "nodenext"
  }
}

Agora vamos ver algumas outras opções que você precisa setar para ter a melhor experiência.

Imports de tipos precisam ser explícitos

Quando importamos módulos que são apenas tipos, ou seja, não existe um código para ser executado ali, podemos dizer para o TypeScript não tentar resolver nenhum deles usando a keyword type:

import type { MeuTipo, MeuOutroTipo } from 'meu-modulo'

Isso fará com que tudo que esteja sendo importado dentro dos {} seja removido na transpilação, evitando processamento desnecessário. Podemos fazer isso com tipos específicos também:

import { MinhaClasse, type MeuTipo } from 'meu-modulo'

Agora só estamos importando MeuTipo como um tipo e não a classe.

Isso parece trivial — até porque o TS vai conseguir resolver isso naturalmente quando você executar o compilador — mas para o Node, não é.

Como o Node não tem como saber quais são os módulos que são ou não tipos, já que ele não tem type checking, você precisa colocar obrigatoriamente a anotação type. Isso pode ser configurado no seu tsconfig.json usando a opção verbatimModuleSyntax e setando para true. Então o compilador vai te avisar quando você precisar de um type.

Seu arquivo tsconfig agora fica assim:

{
  "compilerOptions": {
    "target": "esnext",
	"module": "nodenext",
	"verbatimModuleSyntax": true
  }
}

Imports de arquivos precisam ser explícitos

Além de importar tipos, você também pode importar outros arquivos .ts no seu código. O Node não só suporta isso como deixa muito mais simples e, pelo menos na minha opinião, muito mais fácil de ler.

Quando importando um arquivo local em TS, você obrigatoriamente precisa colocar a extensão .ts:

import { MyClass } from './meu-arquivo.ts'

Se você estiver usando a configuração padrão do Node para ESM, então você vai ter um erro no TypeScript dizendo que você não pode importar um módulo .ts exceto se allowImportingTsExtensions esteja setada como true no seu tsconfig.json. Então é isso que você precisa fazer:

{
  "compilerOptions": {
    "target": "esnext",
	"module": "nodenext",
	"verbatimModuleSyntax": true,
	"allowImportingTsExtensions": true
  }
}

Isso acontece porque, no ESM normal, você precisa explicitamente dizer qual é a extensão do arquivo para reduzir a quantidade de overhead no sistema de resolução de módulos em tentar descobrir que tipo de arquivo você está abrindo. E, se você tenta abrir um arquivo .ts, esse arquivo não existe, então você tem um erro de "Arquivo não existente".

Reescrevendo extensões

Outra opção importante lançada com o TypeScript 5.7 e implementada pelo time do TypeScript diretamente para poder suportar o Node.js é a rewriteRelativeImportExtensions, que vai automaticamente substituir .ts por .js nos seus arquivos, permitindo que você publique o código compilado para o NPM sem precisar de nenhuma outra etapa de transpilação.

Então, o adicionamos aqui também:

{
  "compilerOptions": {
    "target": "esnext",
	"module": "nodenext",
	"verbatimModuleSyntax": true,
	"allowImportingTsExtensions": true,
	"reqriteRelativeImportExtensions": true
  }
}

No futuro

Provavelmente, na versão 5.8, o time do TS vai incluir uma flag chamada --erasableSyntaxOnly que vai te avisar se você estiver usando tipos que não podem ser apagados (se você também estiver usando o Node sem o transform-types).

O que isso significa para o TypeScript?

Muita gente acha que esse é o fim do TypeScript, mas é justamente o contrário, agora o TypeScript estará mais presente do que nunca! Com todos os runtimes suportando TS nativamente, ele está gradualmente caminhando para ser, provavelmente, a linguagem padrão da web.

O que é uma ótima oportunidade para você garantir o meu curso completo de TypeScript, a Formação TS e já se preparar para esse momento!

Claro, ainda existem algumas mudanças que precisam ser feitas, principalmente para a configuração ser mais amigável e menos dolorosa, mas essa mudança é o início de uma pequena revolução que, talvez, substitua o JavaScript como a linguagem mais usada da Web.

Hoje começa o primeiro Backlog de 2025, e vamos começar bem. Esse vai ser o mais sincero que eu já escrevi. Vou falar sobre vários tópicos que sempre me perguntam e, aviso: não vai ter filtro, tudo aqui vai ser autêntico.

A motivação veio ontem à noite. Esse Backlog seria sobre outra coisa (relacionada a história, que fica pra próxima), mas antes de dormir, cometi o maior erro: abri o LinkedIn. O que vi lá me deixou com um misto de sentimentos que preciso expor aqui, já que muita gente me pergunta sobre isso.

Pra não cortar o assunto no meio, vamos pro aviso dos nossos amigos da Remessa ❤️. E lembrem-se: Tudo aqui é minha opinião.

Pausa para um aviso!

Essa newsletter só existe graças à comunidade e aos patrocinadores! E hoje o apoio vem da Remessa Online, que está ajudando demais a manter este projeto vivo 💙.

Muitas pessoas me procuram para perguntar como é trabalhar para fora do Brasil e uma das principais dúvidas é sobre como receber o salário vindo de outro país.

Eu recomendo (inclusive já usava) a Remessa Online, não só porque ela me ajudou a facilitar esse processo, mas também porque as taxas são muito mais baratas (inclusive na conversão) do que se eu recebesse por um banco tradicional.

E tem mais vantagens: o dinheiro entra super rápido na sua conta, a plataforma é super segura, o app intuitivo e todo suporte é em português.

Pra economizar ainda mais, é só usar o cupom LSANTOSDEV para ter 15% nas suas operações.

👉 Clica aqui pra transferir com a menor taxa do mercado!

🥺 Quer ajudar a newsletter a crescer? Se tem uma marca ou produto que se conecta com essa comunidade, manda um e-mail para hello@lsantos.dev. 

Um pouco de contexto

Quem me acompanha sabe que uma das coisas que mais odeio é ver posts de gente se passando por coach, vendendo o que não pratica e criando conteúdo raso só por likes e engajamento (esse principalmente). De 2015 a 2020, o cenário era mais calmo, mas essas figuras sempre existiram. Eu divido essa galera em três categorias:

• O Guru Empreendedor: Acha que tem todas as respostas e promete “revolucionar a humanidade”, mas nunca entrega nada além de variações coloridas de produtos que já existem.
• O Dev de Palco: Fala como criar a aplicação perfeita baseado na sua experiência de dois anos de carreira numa startup de garagem com 10 clientes.
• O Influencer Papagaio: Ensina entre uma dancinha e outra que parseInt é a “melhor solução do JavaScript” (não é) sem checar fontes, provando que o básico mal-feito viraliza mais que conteúdo útil.

Todos fazem a mesma coisa, mas de formas diferentes. O coach te vende que “foguete não tem ré”, criando “seu produto” a qualquer custo. O dev de palco exagera conquistas para se mostrar.

Muito desse "glamour" do mundo dev vem da galera do "minha rotina trabalhando na <FAANG aqui>", vendendo um sonho que não é real.

O ciclo é simples: cria-se um “hype” em torno de uma solução que promete mudar o mundo, mas no final, o produto ou não existe, ou existe e está pela metade ou é uma variação de algo já existente, com uma carinha nova. É o “faça o que eu digo, mas não olhe muito de perto o que eu faço”. Talvez o exemplo mais bem-sucedido dessa prática tenha sido Devin AI, um caso emblemático (que fez um comeback recentemente, aparentemente redimido) de como vender fumaça.

Todo mundo quer criar conteúdo, mas ninguém quer fazer o trabalho de garantir que o conteúdo tenha valor

Tendo isso em mente eu resolvi trazer a tona o que eu penso sobre criação de conteúdo atualmente, sobre coaches tech e responder umas perguntas que a galera faz pra mim.

Um culto ao vazio

Dev de palco não é o problema. Eles podem se vender mais caro do que valem, mas no final só afetam a si mesmos. Muitos acabam sumindo ou, eventualmente, estudam e fazem o que sempre prometeram.

O problema real é uma fatia da galera que se chama de influenciador tech. Apesar de eu não gostar do termo "influenciador", admito que me tornei um sem perceber – só para agora observar de dentro e me perguntar onde isso vai parar. A maioria dos “influencers” hoje tem como ideia de conteúdo algo que é para engajamento apenas, não para ensinar. Em vez de trazer debates profundos ou ideias úteis, o foco está em dancinhas, frases feitas e narcisismo.

Claro, não são todas as pessoas, existem excelentes influenciadores que conseguem ensinar algo bom e engajar a galera, mas são raros.

Isso tudo gera uma bolha de entretenimento, porque é engraçadinho, é engajante, mas quem se destaca não é quem tem algo a ensinar, mas quem sabe entreter ou chamar atenção.

E criar conteúdo é um trabalho difícil, você precisa escolher: ou entretém, ou ensina. Não dá pra fazer os dois realmente bem ao mesmo tempo.

Isso seria inofensivo se não tivesse consequências práticas. O público consome esses conteúdos rasos, toma como verdade absoluta e replica sem pensar. Já entrevistei pessoas que descobriram durante a entrevista que React não era “O JavaScript”. Isso chega ao nível de achar que “Facebook é a internet”.

Já perdi a conta de quantas vezes vi posts que precisam ser corrigidos em várias redes, desde comparações absurdas entre PHP e Node ou notícias incorretas sobre propostas de JavaScript que sequer foram implementadas. O pior não é o erro em si – afinal, a gente está aqui pra aprender –, mas a falta de compromisso em checar se as fontes são reais antes de publicar uma informação. E, do outro lado, a falta de senso crítico para saber que aquilo não fazia sentido...

E se tem algo que me deixa puto, é alguém ensinando algo errado como se fosse verdade.

Mas por que tão raso?

O problema não para nos influenciadores, eles são a consequência de um mercado que prefere entrega a qualquer custo do que parar e pensar no que você está, de fato, fazendo. Isso gera uma indústria que quer tudo rápido, simples e prático.

Todo mundo quer criar conteúdo, mas ninguém quer fazer o trabalho de garantir que o conteúdo tenha valor. E, quanto mais gente fica rica e famosa com conteúdo superficial, mais conteúdo raso é feito, gerando uma bola de neve até chegar em pérolas como essa aqui:

React: 761 issues, VSCode: 5000+ issues [...]
Suas ferramentas não são perfeitas, ainda sim elas dão a milhões de pessoas o que elas precisam.
Pare de se preocupar com bugs pequenos e problemas de interface. Foque na sua funcionalidade principal.

Onde claramente a mensagem é: não importa construir algo bom, importa entregar qualquer coisa. Essa mentalidade reflete no mercado atual.

A galera que está se formando agora, ou está nos primeiros anos de carreira simplesmente não tem vontade de ir a fundo em quase nada.

Como entrevistador, vi isso de perto: projetos simples, conhecimento raso, devs que sabiam codar, mas não entendiam como o código rodava.

“Como funciona?”

Não importa.

O meu futuro nisso tudo

Isso me fez questionar o futuro do que eu crio aqui. Não é segredo que eu não gosto de redes sociais, sou pouco ativo nelas e não sei criar conteúdo “engajante”. Meus poucos posts que geram barulho são exceções, mas também não quero fazer parte do culto ao conteúdo raso. Quero oferecer algo de valor, profundo, que ensine – exatamente o motivo pelo qual criei essa newsletter.

Todo conteúdo que faço e farei seguirá esse princípio: algo pautado, bem fundamentado, do jeito que gosto de aprender e ensinar. Quero que cada artigo/newsletter/video seja algo que você veja e pense: “Isso valeu meu tempo”. Espero que, aos poucos, mais pessoas se juntem a esse caminho e rompam com o show do conteúdo vazio, trazendo discussões e aprendizado real.

Muita gente deixou de me seguir nos últimos meses, inclusive aqui na newsletter. Por quê? Não sei. Talvez meu conteúdo não seja “sexy” ou chamativo o suficiente para o algoritmo, talvez eu seja direto demais (inclusive, você pode me ajudar respondendo aqui). Mas o ponto é que não pretendo mudar só para agradar. O motivo principal de escrever isso tudo sempre foi compartilhar ideias e discutir coisas que realmente importam – e quem fica, entende esse propósito.

Criar conteúdo de verdade dá trabalho. Exige tempo (muito tempo), pesquisa e dedicação – bem diferente dos posts rápidos tipo “cinco segredos para ser um dev ninja”. Quero algo que tenha impacto e ensine de verdade. E, mesmo que não alcance tanta gente, já valeu a pena, porque aprendi no processo.

Então, se você está aqui, lendo até esse ponto, é porque valoriza o mesmo. Obrigado. É para você que eu continuo escrevendo.

Perguntas que me fazem e respostas que ninguém quer ouvir

Agora é o momento que eu respondo um monte de perguntas que muita gente me manda ao longo do tempo mas eu acabei nunca respondendo porque eu acabei esquecendo ou acabei não querendo responder com receio de algum tipo de cancelamento, então ai vai:

Por que você não posta mais em redes sociais?

Eu detesto ter que ficar pensando em algo novo todo dia, não é sempre que você tem inspiração pra criar algo, não é sempre que você tem vontade de criar algo. Mas para a rede social é sempre a frequência que importa, e eu não sou constante, portanto, redes sociais também não gostam de mim. Além de que eu produzo o conteúdo sozinho, e eu também trabalho, então não tem muito tempo pra criar algo de qualidade, e se não tiver qualidade eu prefiro não criar.

Qual é a sua opinião sobre solopreneurs e essa galera coach de sucesso?

Muito dela está aqui na newsletter, mas no geral, sempre que eu vejo um "founder" postando algo fazendo um boost sobre a sua própria empresa ou sempre que eu vejo "disruptivo", "mudança de mindset" ou variações disso, eu paro de seguir, e as vezes até bloqueio a pessoa. Até agora tiveram poucas exceções de pessoas que eu realmente quis seguir que são empreendedores, uma delas é o Zeno Rocha, porque acredito que ele é um dos poucos que realmente entregam valor real nos produtos, desde os primórdios, e o conteúdo dele não é só inspiracional, mas educativo na maioria das vezes.

IA vai roubar meu emprego?

Se você acha que IA vai roubar seu emprego nos próximos 10 anos, então provavelmente ela vai. É o que eu sempre falo, se você se comporta como uma IA, você vai ser tratado como uma IA. Hoje qualquer coisa que contenha "IA" no nome já me dá um certo asco, eu não uso mais copilot e evito ao máximo qualquer tipo de código escrito completamente por IA. São ótimas ferramentas para revisão, rubber ducking, mas não para pensar por você. SEMPRE CHEQUE SUAS FONTES

Você pretende fazer o que com seu conteúdo?

Sinceramente, eu pensei em parar múltiplas vezes. Mas acho que não é justo comigo, porque eu gosto muito de escrever e ensinar (e, mais ainda, aprender), então eu também não quero parar. Provavelmente vou dar uma reduzida agora com projetos como a Formação TS em foco para poder terminar ela de vez e focar em construir coisas, mostrando como eu estou fazendo no processo, quem sabe em lives. Por mais que eu não goste da cultura do solopreneur, eu admiro muito indie hackers, porque eles passam por muita coisa.

Enfim, não sei, me manda uma sugestão no meu email ou nas redes se tiver alguma ideia!

Você vê futuro no conteúdo atual?

Sim, a galera que está por ai hoje tem gente muito boa. Muitos que sabem como lidar com as redes sociais, que nasceram nelas, mas ao mesmo tempo também são muito inteligentes e sabem ensinar, o melhor de todos os mundos. Porém, a quantidade de pessoas que vai para o lado fácil da coisa puxa tudo pra baixo. Se a gente continuar dando palco pra galera que faz conteúdos rasos, a tendência é que mais conteúdo raso apareça.

Você acha que devs de hoje tem conserto?

Eu não acho que a galera esta quebrada. Eu acho que uma pandemia e uma série de problemas ajudou a bolha atual a ser o que ela é. Mas, enquanto conteúdo raso e falta de conhecimento forem norma, eu não tenho que achar nada, porque o mercado vai se encarregar de não deixar a galera que não se importa progredir.

Muito obrigado, não deixa de comentar se gostou nas minhas redes e te vejo no próximo backlog!

Para começar, não haveriam devs sem algo que a gente pudesse escrever para transformar nossos pensamentos em algo útil que um computador possa executar. A gente precisa de uma forma, uma linguagem, para dizer ao computador o que a gente quer fazer, e assim tivemos a ideia de criar as linguagens de programação.

Mas como essas linguagens surgiram? Qual é a história por trás delas? E, mais importante, quem criou a primeira linguagem de programação realmente útil?

Antes de responder, a gente precisa explorar o contexto da evolução das linguagens de programação. Esse processo não aconteceu do dia para a noite – levou mais de 200 anos para chegarmos onde estamos hoje.

Onde tudo começou

Antes de qualquer computador ou máquina de calcular, e mais de 100 anos antes de Alan Turing, um tecelão francês chamado Joseph Marie Jacquard revolucionou a forma como os teares funcionavam. Em 1804, ele criou e patenteou o famoso tear de Jacquard, projetado para criar padrões complexos automaticamente.

Você achou que eu ia falar da Ada Lovelace né? Achou errado.

O tear de Jacquard era completamente programável por meio de cartões perfurados de papel. Cada cartão representava uma linha do desenho, e a máquina podia ser acoplada a qualquer tear existente. Isso simplificou e barateou a produção de tecidos com padrões mais complexos, revolucionando a indústria têxtil da época.

Embora o tear de Jacquard fosse uma aplicação simples de uma DSL (Domain Specific Language, ou uma linguagem projetada para um propósito específico), seu trabalho inspirou o desenvolvimento de linguagens mais complexas, capazes de serem interpretadas por diferentes tipos de máquinas.

Ada Lovelace e a nota G

Finalmente ela aparece!

Trinta e seis anos após Jacquard patentear seu tear, em 1840, o professor Charles Babbage foi convidado a dar um seminário em Torino, na Itália, sobre os avanços de seu projeto mais ambicioso: o motor analítico (um tema para um futuro Backlog). Esse seminário foi a única apresentação pública que Babbage fez sobre a máquina revolucionária que estava desenvolvendo.

Durante a palestra, um engenheiro chamado Luigi Menabrea – que mais tarde se tornaria primeiro-ministro da Itália – tomou notas detalhadas para entender o funcionamento do complexo modelo que, no futuro, seria conhecido como o primeiro computador mecânico do mundo (mesmo que nunca tenha sido construído).

Babbage tinha uma amiga e mentorada importante: Ada Lovelace. Desde 1833, ele e Ada, uma brilhante matemática e filha do poeta Lord Byron, trocavam cartas e notas sobre suas pesquisas e avanços matemáticos. Após uma conversa com Charles Wheatstone, Ada recebeu a sugestão de traduzir as notas de Luigi Menabrea para o inglês como uma forma de contribuir com o trabalho. Ao concluir a tradução, Babbage sugeriu que ela adicionasse seus próprios pensamentos em forma de apêndices, que Ada chamou simplesmente de "notas".

Ada compilou sete notas, nomeadas de A a G, detalhando o funcionamento do motor analítico. Na última delas, a nota G, ela descreveu um algoritmo para calcular os números de Bernoulli, projetado para ser executado exclusivamente na máquina de Babbage. Esse algoritmo – e essa nota – é amplamente reconhecido como o primeiro programa de computador já escrito, tornando Ada Lovelace como a primeira programadora da história.

As notas de Ada eram três vezes mais extensas do que o artigo original de Luigi Menabrea. Além de descrever o algoritmo (apenas na última nota, a G), Ada detalhou todo o funcionamento do motor analítico, explicando como ele diferia da máquina anterior, o motor de diferenças. Na nota C, ela apresentou conceitos revolucionários, como loops, fluxos de controle (if, else) e funções – a primeira vez que essas ideias apareceram na história.

Um fato engraçado é que nem o próprio Babbage tinha pensado nisso para a máquina. As ideias de Ada eram muito maiores que as ambições do seu próprio criador.

E ela fez isso sem nunca ter nem visto a máquina em si (que nunca foi completamente construída) ou ter usado qualquer parte dela. E hoje a gente reclama quando não consegue usar uma API sem documentação...

Pausa para um aviso!

Essa newsletter só existe graças à comunidade e aos patrocinadores! E hoje o apoio vem da Remessa Online, que está ajudando demais a manter este projeto vivo 💙.

Aproveitando o fim do ano, muita gente tá planejando viagens ou começando a vida fora do país, né? Então olha essa promoção exclusiva de férias:

• 1GB de dados grátis com um e-chip pra usar no exterior;
• 35% de desconto no seguro viagem (que a gente sabe que pesa no bolso).

Pra garantir, é só abrir sua conta global na Remessa e carregar com pelo menos 200 Euros ou Dólares até 31/01/2025. Além de conectividade, ainda rola a menor taxa do mercado pra transferências!

Use o cupom LSANTOSDEV5 e aproveite.

👉 Clica aqui pra transferir com a menor taxa do mercado!

🥺 Quer ajudar a newsletter a crescer? Se tem uma marca ou produto que se conecta com essa comunidade, manda um e-mail para hello@lsantos.dev. 

💙 Apoie o meu trabalho: Se você gosta do conteúdo e quer dar uma força, mesmo com apenas R$1, isso já faz toda a diferença! Clique aqui!

Plankalkül, quase lá...

O mundo da computação permaneceu praticamente o mesmo por cerca de 100 anos. Mas, entre 1943 e 1948, um cientista alemão chamado Konrad Zuse (se pronuncia “Zuza”) começou a perceber um grande problema: nenhuma linguagem de computação existente era Turing-completa, o que as tornava inadequadas para seus computadores Z1 a Z3.

Spoiler: Konrad Zuse vai ganhar uma edição inteira do Backlog. Ele é amplamente reconhecido como o inventor do primeiro computador digital programável do mundo, o Z3.

Os computadores de Zuse começaram como máquinas de calcular mecânicas, parecidas com as ideias de Babbage. Mas, ao chegar à terceira versão (o Z3), ele criou algo revolucionário: um computador totalmente digital e programável. Agora, tudo o que faltava era uma linguagem que seu computador pudesse entender...

Por que não criar a sua própria linguagem? Foi exatamente o que Zuse fez. Ele se baseou em conceitos matemáticos, incluindo o cálculo proposicional – um campo complexo da matemática – para desenvolver um modelo de programação.

No entanto, como implementar diretamente o cálculo proposicional em um computador seria extremamente difícil (e não era Turing-completo), Zuse decidiu elaborar sua própria linguagem, chamada Plankalkül.

O Plankalkül é amplamente reconhecido como a primeira linguagem de programação de alto nível, pois abstraía grande parte do funcionamento interno do computador. Com ela, os engenheiros não precisavam lidar diretamente com tarefas repetitivas, como a criação manual de loops.

Embora fosse uma linguagem completamente estabelecida teoricamente, o Plankalkül nunca foi implementado nos computadores de Zuse, como o Z3, mesmo tendo sido desenvolvida depois. O Z3 em si era programado usando fitas perfuradas em um filme cinematográfico, que eram lidas por relés eletromecânicos para uma memória de 1408 bits (64 palavras de 22 bits cada).

Estou deixando um vídeo sobre como o Z3 funcionava, ele está em alemão mas existem legendas auto traduzidas do YouTube.

Em vez disso, sua principal motivação era oferecer uma maneira mais eficiente e estruturada de programar, permitindo o desenvolvimento de programas mais sofisticados e de "fácil compreensão".

Zuse achava que isso era algo de "fácil compreensão", tenho pena de quem precisava usar.

Eu gostaria de explicar como essa linguagem “mais simples” funciona, mas, sinceramente, não consegui entender nada (Zuse era muito mais inteligente do que eu). Então, vou deixar você com o básico:

• A linguagem possui apenas um tipo primitivo, chamado S0, que representa um bit, ou seja, um valor booleano. Um bit pode ser 0 ou… L (sim, isso mesmo, pra que usar o 1 né?). Então, o número 2 (10 em binário) seria escrito como L0.
• Todos os outros tipos são compostos, formados por arrays ou tuplas de bits. Por exemplo, uma sequência de 8 bits seria escrita como 8 x S0.
• As variáveis são sempre locais, sem escopo global.
• Não há suporte para recursão, instruções goto ou referências – apenas valores diretos.
• Suporta estruturas de controle como if, else, for e while.
• Tipos compostos são sempre arrays ou tuplas, sem variações mais complexas.
• Letras maiúsculas, como V, Z, C e R, identificam variáveis, saídas, registradores e constantes.

Eu imagino que isso fazia todo o sentido na cabeça de Zuse (porque na minha não faz), mas, infelizmente, a guerra e a dissolução da Alemanha nazista interromperam seu trabalho.

Com a ocupação dos aliados, ele foi proibido de continuar desenvolvendo computadores, e focou seus esforços na criação de linguagens, mas a linguagem nunca chegou a ser implementada na época. A primeira implementação funcional do Plankalkül só aconteceu em 1975, quando Joachin Hohmann a utilizou em sua dissertação acadêmica.

Apesar de não ter sido implementada originalmente, a publicação de Zuse teve impacto significativo no desenvolvimento de linguagens posteriores, como o ALGOL e o APL, que já discutimos na edição #2.

Agora sim, a mãe de TODAS as linguagens

Até aqui, a maioria das linguagens foi criada de forma um tanto artesanal: seus criadores basicamente estruturavam tudo o que sabiam sobre computação em um sistema funcional. Algumas dessas linguagens, como a APT usada no M70 que vimos na outra edição, eram tão específicas que exigiam até mesmo teclados especiais, cheios de símbolos exclusivos – bem diferente do que usamos hoje.

Mas isso começou a mudar em 1954 com o surgimento do FORTRAN (abreviação de FORmula TRANslation), a primeira linguagem de programação comercial bem-sucedida. Desenvolvido por uma equipe liderada por John Backus na IBM, o FORTRAN trouxe uma abordagem prática e eficiente, que revolucionou o jeito de programar.

Por trás dessas linguagens revolucionárias, havia um desafio técnico gigantesco: fazer os computadores entendê-las.

Compiladores

Entre a invenção de Zuse em 1943 e 1954, qualquer código escrito para um computador precisava ser traduzido diretamente em instruções de máquina específicas para aquele hardware. Era como escrever um programa exclusivo para cada processador, usando uma linguagem que só aquele processador entendia – muitas vezes composta por símbolos matemáticos.

Em 1950, surgiu uma invenção revolucionária: o compilador. Ele permitiu a criação de um grupo de linguagens chamado Autocode, que na época eram descritas como “sistemas de código”. O termo autocoders se referia a uma família de linguagens compiladas, onde um mesmo conjunto de instruções podia ser traduzido para códigos de máquina de diferentes computadores. Em outras palavras, você podia escrever o código uma vez e compilar para várias máquinas, algo inédito até então.

A primeira dessas linguagens, pasmem, também se chamava Autocode. Ela foi criada em 1952 por Alick Glennie, junto com seu próprio compilador. Essa linguagem é considerada a primeira linguagem compilada da história, embora fosse pouco usada fora dos computadores Manchester Mark I.

Essa evolução trouxe uma mudança radical: agora era possível criar códigos usando um sistema único, onde apenas o compilador precisava ser ajustado para cada máquina. Isso simplificou enormemente o desenvolvimento de novas linguagens de programação e abriu caminho para avanços ainda maiores na área.

A história do FORTRAN

No final de 1953, John Backus apresentou uma proposta ousada para seus superiores na IBM: criar uma alternativa mais prática e eficiente ao Assembly para programar o mainframe IBM 704. A ideia era simplificar a vida da galera, permitindo que eles se concentrassem mais no problema e menos nas instruções de máquina.

A principal solução que a nova linguagem deveria oferecer era simplificar a inclusão de equações matemáticas em computadores, aproveitando estudos de 1952 que provaram ser possível converter equações diretamente em código.

O FORTRAN tinha um objetivo claro: traduzir matemática para código. Daí seu nome, uma abreviação de FORmula TRANslator (Tradutor de Fórmulas).

A primeira especificação da linguagem foi concluída em 1954, sob o título “The IBM Mathematical Formula Translating System”. Em 1957, o primeiro compilador de FORTRAN foi criado, e ele produzia um código de máquina rápido o suficiente para convencer a maioria dos programadores de que uma linguagem de alto nível podia ser uma alternativa viável – mesmo com os vários bugs iniciais.

Curiosamente, John Backus criou o FORTRAN porque detestava programar. Enquanto escrevia programas para calcular trajetórias de mísseis no IBM 701, ele pensou: “Deve ter um jeito mais fácil de fazer isso.”

Depois de 1958, o FORTRAN ganhou um compilador confiável e rapidamente se tornou amplamente utilizado na maioria dos mainframes da IBM, estabelecendo-se como a principal linguagem de programação da época. Seu sucesso foi tão grande que, em 1963, já existiam mais de 40 compiladores de FORTRAN.

O FORTRAN era especialmente popular entre cientistas que precisavam realizar cálculos intensivos e precisos com números longos. Por isso, a linguagem foi continuamente aprimorada e, até hoje, é reconhecida como uma das linguagens mais rápidas do mundo para processamento numérico.

A versão inicial do FORTRAN tinha 32 palavras-chave (Golang, por exemplo, tem 25) e suportava:

• Switch
• Go to
• I/O em fita ou bloco
• Aritimética

Quando ele foi criado, não existiam discos ou telas, a maioria dos programas era ainda feita em cartões perfurados, então os desenvolvedores tinham um "formulário" para poder criar, apagar e testar o código antes de transferir para um cartão final.

E, nesses cartões perfurados, existiam algumas colunas específicas que eram destinadas a uso de controle, por exemplo:

• Um C na primeira coluna transformava o cartão todo em um comentário
• As colunas 1 a 5 eram labels, usadas para retornar em funções como GO e IF
• A coluna 6 era pra dizer se o cartão era uma continuação do anterior
• De 7 a 72 era onde escrevíamos os programas
• De 73 até 80 eram ignoradas porque o IBM 704 só lia 72 colunas, então eram muito usadas para anotações ou identificação, como a ordem dos cartões e etc.

Lembrando que cada cartão perfurado representava somente UM statement, ou seja, cada cartão era uma keyword ou uma linha, o cartão acima poderia ter sido um IF.

Evoluções

Após a versão inicial, o FORTRAN continuou evoluindo – e ainda evolui. É a linguagem de programação mais antiga ainda em uso ativo, com sua versão mais recente lançada em 2023. A primeira grande atualização, o FORTRAN II, trouxe um avanço significativo: o suporte à programação procedural, permitindo a criação de sub-rotinas e modularizando o código de forma mais eficiente.

A versão inicial do FORTRAN não tinha funções ou rotinas, todo o código tinha que ser replicado e copiado, mas na versão II era possível usar as keywords SUBROUTINE, FUNCTION e END para criar uma rotina, além de CALL e RETURN. Mas as versões iniciais ainda não suportavam recursão.

Depois veio o FORTRAN III, que introduziu a possibilidade de escrever assembly diretamente junto com o código FORTRAN. No entanto, essa versão nunca foi lançada como um produto comercial. Em vez disso, a IBM lançou o FORTRAN IV em 1961, trazendo mudanças significativas. A principal foi a remoção de dependências específicas das máquinas IBM, como a instrução READ INPUT TAPE, permitindo que o FORTRAN fosse usado em diferentes computadores além dos da IBM.

Mas talvez a evolução mais importante tenha sido o FORTRAN 66. Essa versão foi a primeira a passar por um processo de padronização oficial, muito parecido com o que aconteceu mais tarde com o JavaScript. A especificação foi elaborada pela American National Standards Institute (ANSI) e por um comitê chamado BEMA. Baseada largamente no FORTRAN IV, ela trouxe várias funcionalidades importantes:

• Subrotinas e funções
• Novos tipos primitivos INTEGER, REAL, DOUBLE PRECISION, COMPLEX e LOGICAL
• A keyword DATA para especificar valores iniciais
• GO TO , IF, DO e muitos outros

11 anos depois, o FORTRAN 77 é o que temos como início do que usamos hoje como linguagem de programação, incluindo mudanças como:

• O uso de IF estruturado com END IF ao invés de GO TO e CONTINUE
• O primeiro uso de aspas para textos, já que agora era possível escrever em terminais
• Inclusão de PROGRAM para nomear programas

Uma curiosidade interessante sobre o FORTRAN é como ele lidava com comentários e linhas vazias. Qualquer linha que começasse com a letra C era interpretada como um comentário. No entanto, o compilador do FORTRAN lia todas as linhas do programa em sequência – incluindo as linhas vazias, que frequentemente geravam erros. Para evitar problemas, era comum usar um comentário vazio para separar uma linha da outra.

O FORTRAN continuou evoluindo, mas foi apenas 13 anos depois que surgiu uma grande revisão: o FORTRAN 90. Essa versão é uma das mais comumente utilizadas até hoje, pois trouxe mudanças significativas que provavelmente você nem percebeu de imediato, mas que facilitaram muito a vida dos programadores:

• O texto não precisava ser identado 6 caracteres pra frente antes de qualquer statement (lembra das 6 colunas dos cartões perfurados? Agora olha a identação dos códigos de antes, veja a identação)
• As palavras-chave poderiam ser minúsculas
• Nomes de variáveis com até 31 letras (antes eram só 6)
• Comentários inline ao invés de ocupar a linha toda
• Agora era possível operar em arrays como um todo
• Recursão
• Módulos para agrupar procedures e dados juntos e torná-los disponíveis para importação em outros programas, o primeiro conceito de "pacote"
  • Aqui também temos a inclusão de encapsulamento, tendo funções e partes privadas de um módulo
• Overloads
• SELECT CASE, que é a primeira versão de um switch
• ....

Agora os programas de FORTRAN são muito parecidos ao que escrevemos hoje, veja um hello world:

program helloworld
     print *, "Hello, World!"
end program helloworld

Depois dessas versões, ainda temos o FORTRAN 95 até 2023, que implementou muitas mudanças até hoje, tornando o FORTRAN extremamente útil ainda hoje em dia.

O FORTRAN atualmente

O FORTRAN ainda é amplamente utilizado em sistemas críticos e antigos, como na aviação, em mainframes e em aplicações que demandam computação extremamente rápida. Sua relevância está especialmente em cenários que exigem alta performance no processamento de grandes volumes de dados.

A linguagem é uma escolha comum em áreas como simulações de mecânica de fluidos, modelagem espacial e terrestre, e no cálculo de temperaturas em oceanos. Graças à sua eficiência em cálculos numéricos intensivos, o FORTRAN continua muito usado em campos que dependem de simulações científicas e engenharia de alta precisão.

O código FORTRAN em si sofreu várias modificações até ficar muito parecido com o que a gente entende como um código de programação, por exemplo, abaixo temos um programa para calcular a média dos números lidos:

program average

    ! Read in some numbers and take the average
    ! As written, if there are no data points, an average of zero is returned
    ! While this may not be desired behavior, it keeps this example simple

    implicit none

    real, allocatable :: points(:)
    integer           :: number_of_points
    real              :: average_points, positive_average, negative_average
    average_points   = 0.
    positive_average = 0.
    negative_average = 0.
    write (*,*) "Input number of points to average:"
    read  (*,*) number_of_points

    allocate (points(number_of_points))

    write (*,*) "Enter the points to average:"
    read  (*,*) points

    ! Take the average by summing points and dividing by number_of_points
    if (number_of_points > 0) average_points = sum(points) / number_of_points

    ! Now form average over positive and negative points only
    if (count(points > 0.) > 0) positive_average = sum(points, points > 0.) / count(points > 0.)
    if (count(points < 0.) > 0) negative_average = sum(points, points < 0.) / count(points < 0.)

    ! Print result to terminal stdout unit 6
    write (*,'(a,g12.4)') 'Average = ', average_points
    write (*,'(a,g12.4)') 'Average of positive points = ', positive_average
    write (*,'(a,g12.4)') 'Average of negative points = ', negative_average
    deallocate (points) ! free memory

end program average

Atualmente ainda existem repositórios que contém códigos FORTRAN como em jogos e a linguagem ainda é amplamente utilizada.

Fortran Gaming

Modern and resurrected Fortran games. Includes candidates for conversion to Fortran in other languages. - Fortran Gaming

GitHub

Legado

O FORTRAN foi a primeira linguagem de alto nível a ser largamente distribuída e tudo que usamos atualmente é idêntico ou foi baseado em algum tipo de implementação trazida pelo FORTRAN. Linguagens de base como COBOL, BASIC e ALGOL foram fortemente influenciadas pelo FORTRAN e, em troca, influenciaram outras linguagens como o B, C e todas as que se sucederam.

Recentemente eu estive no Museu Da História da Computação em Bletchley Park (veja no meu instagram) e lá a gente tem um mural muito legal de todas as linguagens de programação que já existiram em um mapa interativo. Você pode acessar esse mapa aqui e, quem sabe, imprimir para decorar sua casa:

Computer Languages History

A Computer Languages diagram

Éric Lévénez

Esse marca o fim dessa edição do Backlog! Espero que você tenha curtido assim como eu saber mais sobre o que foi a primeira linguagem de todas e como ela funcionava!

Um abraço e um feliz natal!

Nos vemos na próxima edição!

O dia 4 de dezembro de 1995 é um dia muito especial. Não só porque é o ano que eu nasci, mas também porque foi o lançamento da linguagem que, hoje, todo mundo ama odiar! O JavaScript.

Como todo mundo que me acompanha sabe, eu sou um grande fã de JavaScript e TypeScript, e gosto ainda mais de mostrar qual é a história dessa linguagem, não só porque a linguagem evoluiu muito e tem um dos arcos de superação mais incríveis da computação, mas também porque a história dessa linguagem é muito interessante. Então pra essa edição do backlog eu quero trazer, em comemoração dos 29 anos de JavaScript:

A história da linguagem que dominou o mundo.

Essa edição é baseada nesse paper de 189 páginas, escrito pelo próprio Brendan Eich sobre os primeiros 20 anos de JavaScript.

De um "hack" a um ecossistema global

A história resumida do JavaScript é o que muita gente vê por ai. Em 1995, por volta de 10 de Maio, Brendan Eich, um jovem programador para a Netscape Corporation passava da metade da sua sprint de 10 dias para criar uma linguagem que servisse como um apoio ao Netscape Navigator, criando mais interação com a página e possibilitando uma Web (ainda muito recente) mais animada

No tweet acima, Brendan Eich diz que nessa época (em 2020, no caso) ele já tinha passado mais da metade do período da sua "sprint de 10 dias" para criar o JavaScript, que na época era chamado de Mocha. Ele iria ter uma demonstração na segunda seguinte para mostrar a integração com o browser versus a tecnologia que dominava que eram os Java Applets.

E hoje, 29 anos depois, o JavaScript é a linguagem que marcou a fundação do desenvolvimento Web moderno, uma linguagem que, hoje em dia, está presente em 98% da Internet. Hoje, a gente não só celebra o JavaScript como linguagem, mas também como um movimento que moldou a Internet como a gente conhece.

Pausa para um aviso!

Essa newsletter só é possível através da ajuda da comunidade e dos patrocinadores!

Essa em particular é patrocinada pela Remessa Online! Se você trabalha com tecnologia, com certeza já precisou trazer algum dinheiro de fora para o Brasil, e as taxas são SUPER ALTAS 😭 Por isso a Remessa é a melhor forma de fazer isso com a menor taxa do mercado!

Se você já teve que passar por isso, então segura aí porque a Remessa Online tem um desconto de 15% pra você com o cupom LSANTOSDEV! Ele é válido pra qualquer recebimento ou envio na conta global e você economiza MUITO! Então aproveita o dólar/euro alto pra fazer a grana render mais!

Muito obrigado à Remessa pelo apoio!

👉 Clica aqui pra transferir com a menor taxa do mercado!

🌟 Quer fazer parte desse sonho comigo? Trazer essa newsletter ao mundo é algo que sempre quis fazer, e ver o projeto crescer com seu apoio seria incrível! Se você tem uma marca ou produto que se conecta com essa comunidade, manda um e-mail para hello@lsantos.dev. Vou adorar conversar!

💙 Apoie o meu trabalho: Se você gosta do conteúdo e quer dar uma força, mesmo com apenas R$1, isso já faz toda a diferença! Clique aqui para contribuir mensalmente ou fazer uma doação única. Cada apoio me ajuda a manter essa newsletter viva e a fazer dela algo especial. Muito obrigado por estar aqui e por acreditar nesse sonho comigo!

Um mosaico de possibilidades

A história do JS começa com a história da Web. Desenvolvida entre 1989-1991 por Tim Berners-Lee no CERN, a World Wide Web foi primeiramente mais aceita na comunidade de físicos e cientistas, já que era feita para compartilhar papers. Mas não era muito vista fora dessa comunidade.

Um dos maiores motivos pelo qual a Web era muito fechada nesta comunidade era porque o seu uso era bastante complicado, baseado em protocolos de texto e não era muito intuitivo. Isso mudou quando Marc Andreessen e Eric Bina criaram o Mosaic em 1992 enquanto trabalhavam na NCSA.

O Mosaic foi o primeiro Web Browser do mundo, essencialmente o que criou a categoria de "Browsers" que a gente tem hoje. Ele quem popularizou o conceito da Web fora da comunidade de cientistas do CERN. Claramente, depois que o Mosaic ganhou fama e notoriedade, muita gente se perguntava se era possível fazer disso algo comercial, na maioria tentando licenciar o próprio Mosaic ou então criando variações dele. Até que um cara chamado Jim Clark, que fundou a Silicon Graphics (uma empresa extremamente importante de hardware) conseguiu um investimento e recrutou os dois estudantes, Marc e Eric, para fundar uma empresa chamada Netscape Communications Corporation (NCC) em 1994.

A ideia da NCC era substituir o Mosaic pelo Netscape, uma versão mais robusta e fácil de utilizar. No final de 1994 e início de 1995, o Netscape Navigator já era o browser mais utilizado de todos. E o que isso tem a ver com JavaScript? Tudo!

Uma Web morta

Originalmente, a Web era centrada em texto plano através de uma linguagem de marcação, o HTML, que era declarativa e estática e representava a estrutura e conteúdo de uma página da Web. O problema era que essas páginas eram estáticas, para criar conteúdo dinâmico você precisava requisitar uma outra página, então qual seria a utilidade para, por exemplo, servir bancos de dados? Pesquisas? Relatórios?

Existia um interesse considerável da indústria em criar uma linguagem de scripting pra poder fazer par com o HTML, dando mais "vida" a ele, e permitindo que as páginas pudessem ser mais dinâmicas. Da mesma forma como o VBA do Excel e o AppleScript fizeram com o Windows e Mac. Essas linguagens não eram focadas em criar sistemas complexos, mas sim "colar" partes de vários sistemas para criar uma integração melhor e novas oportunidades.

Em 1995, Brendan Eich foi recrutado para ser um dos programadores da NCC. Já tendo trabalhado em grandes empresas como a própria Silicon Graphics e MicroUnity, em ambas implementando linguagens específicas para suportar funções definidas, então ele já tinha o conhecimento necessário para criar uma outra linguagem que seria a "cola" entre o HTML e o resto dos sistemas.

Originalmente, ele foi contratado para "implementar o Scheme no browser". (Scheme era uma linguagem funcional, um dialeto do LISP, usada principalmente em áreas acadêmicas) porém, quando ele chegou lá, se deparou com um produto muito mais complicado do que esperava, além de que havia um outro perigo no ar, e ele chamava Microsoft.

A guerra dos browsers

Quando o Netscape foi lançado, a Microsoft, ainda bem jovem, tinha um projeto chamado "Projeto Blackbird", que era um conjunto de programas de gerenciamento de informação e troca de dados para empresas, uma versão da Web da Microsoft, chamada de Microsoft Network (MSN, familiar?).

A ideia era ter uma aplicação que iria servir conteúdo dinâmico, audio e vídeo sem necessidade de outros plugins. Ela seria construída usando tecnologias como Object Linking and Embedding (OLE) e outras que estavam sendo desenvolvidas naquela época.

Mas, com a popularização rápida da Web, a Microsoft viu esse projeto ser esquecido e mudou de foco para as tecnologias voltadas para essa nova "Web" que todo mundo estava falando. Em 1994, ela tentou comprar a NCC, mas foi recusada pelo valor ser baixo demais. Com isso, os fundadores da NCC já esperavam uma retaliação na forma do famoso Embrace Extend Extinguish, onde a Microsoft pretenderia adotar o padrão, estender com suas tecnologias e depois matar o padrão em favor ao seu. Com isso, a Microsoft começou o desenvolvimento do que seria chamado de Internet Explorer.

Com isso, a Netscape precisava correr com a implementação de uma linguagem de scripting, porque a Microsoft chegaria com tudo. As candidatas cotadas eram: Perl, Python, TCL e até mesmo o Visual Basic da Microsoft, além do Scheme. Porém tudo mudou quando o Java chegou.

Java (sem script)

No início de 1995, a Sun Microsystems começou uma campanha pesada de marketing para divulgar a sua, então não lançada, linguagem chamada Java. A Netscape logo viu uma oportunidade de negócio, visto que o Java também queria derrubar o monopólio da Microsoft sobre o Windows, que já era o SO mais usado em todas as máquinas, com a JVM e a sua proposta de rodar em qualquer lugar.

Para você entender a importância da Microsoft naquela época, ela não era só a dona do maior (e quase único) SO usado em mais de 90% dos computadores, mas também dona de quase todas as linguagens que criavam programas para esses computadores.

Logo que a Netscape e a Sun fizeram um acordo onde a linguagem escolhida não seria nenhuma das anteriores, mas sim o Java! E isso se tornou público no dia 23 de Maio de 1995 (eu tinha 1 mês de idade 👶).

Agora com tudo decidido, todas as demais linguagens foram descartadas por interesses comerciais, ou então pela dificuldade que seria integrar uma linguagem completa no navegador. Não haveria tempo suficiente para terminar a implementação e lançar no mercado antes da Microsoft lançar seu navegador. E a linguagem que a Microsoft escolhesse para ser o par do Internet Explorer seria o que iria definir todo o padrão dali para frente.

A Microsoft tinha a faca e o queijo na mão, eles tinham o VBA que já era uma linguagem de scripting usada no Excel, tinham o conhecimento de como criar um browser e como criar uma linguagem, já tinham mercado, só faltava o produto. Então, Bill Joy (olha ele aparecendo de novo), o fundador da Sun sugeriu que a saída seria implementar uma "pequena linguagem" que faria par com o Java e complementaria a funcionalidade.

As principais dúvidas que surgiam na Netscape eram se o Java em si já não era uma linguagem que poderia ser integrada, algo que claramente não era possível já que, para criar um programa em Java, você precisava

1. Colocar o corpo do programa em um método estático chamado main
2. Dentro de uma declaração de classe
3. Dentro de um pacote
4. Declarar tipos para todas as variáveis e retornos

Isso não era a experiência que a Netscape estava buscando para aquela galera que seria um "scripter". A linguagem deveria ser muito mais simples, não podia ser baseada em classes, nem ter tipos. Foi assim que Marc Andreessen propôs o codinome Mocha para a futura linguagem, na esperança que ela fosse chamada "JavaScript" no futuro. Ela teria que "se parecer com Java", ser fácil de user e "baseada em objetos" e não em classes.

Mocha

O Java estava para ser lançado, então o tempo era importante nesse contexto. Por isso que o mocha foi implementado em 10 dias contínuos em Maio de 1995. O fato mais famoso do JavaScript que, na verdade, é distorcido, porque o Mocha era uma linguagem bem diferente do que o JavaScript se tornou. A implementação em 10 dias foi o início do que seria o JS, mas a implementação no final desses dias era uma versão crua, básica e simples do que essa integração poderia ser.

Tecnicamente, o Mocha continha um lexer escrito a mão e um parser recursivo. Esse parser emitia bytecodes, algo que era necessário para que o servidor do Netscape (chamado de LiveWire) pudesse entender as instruções. O resultado final era uma linguagem simples e muito lenta, mas factível.

Foi aqui que a maioria das escolhas que todo mundo adora odiar foram feitas. Como a linguagem tinha que parecer com Java, tudo que era mais parecido com VB foi removido, mas ao mesmo tempo "parecer com Java" fazia com que ela "parece que funcionava como Java", o que não era verdade.

A outra definição explicita era que a linguagem tinha que ser tão fácil de usar, que ela poderia ser escrita diretamente no HTML. E a partir daí, Eich começou a trabalhar nos outros pontos que tornariam o JS o que ele é hoje, por exemplo:

• Herança prototípica veio de uma linguagem chamada Self
• A ideia de High Order Functions e funções como tipos de primeira classe veio do Lisp
• this veio diretamente do Java (que pegou do C++)
• A ideia de criação dinâmica de propriedades
• O Object global de onde todos os demais tipos herdam
• O eval
• O var
• Controles de fluxo emprestados do C

A apresentação do Mocha foi um sucesso e todos estavam otimistas com o lançamento de uma versão mais completa e integrada do Mocha no Netscape 2, agendado para ser lançado em Setembro daquele ano.

O código fonte do Mocha está disponível no GitHub com detalhe especial à nomenclatura "JavaScript" que o Netscape esperava que fosse adotado

Java (com script)

O JavaScript foi lançado no dia 4 de dezembro (após mais ou menos 7 meses de desenvolvimento) em uma conferência de imprensa como sendo uma "linguagem de scripting com objetos" que seria usada para escrever scripts que iriam "modificar dinamicamente as propriedades e objetos Java" e serviria como um complemento ao Java na Web.

Antes de o JavaScript ser chamado de JavaScript, ele foi aberto ao público em um beta aberto do Netscape 2 sob o nome de LiveScript (por conta do LiveWire) em Setembro de 95, e 1 mês depois transformado em JavaScript para criar uma marca forte entre o Java e a Netscape.

O JavaScript não era para ser nenhum tipo de grande linguagem, nem ter muitas features lançadas, tanto que as funcionalidades da linguagem foram severamente cortadas e o JavaScript 1.0 foi lançado com todas as funcionalidades que estavam "praticamente prontas", inclusive com muitos bugs que foram corrigidos durante o desenvolvimento.

Quando ele foi entrevistado em 1996, Brendan Eich disse que ele queria que a a linguagem continuasse pequena e continuasse ubíqua na Web como a melhor forma de "grudar" elementos HTML e ações uns nos outros e também conectar esses componentes com Java Applets, que seria o resto do ecossistema. Tanto que ele falava que um dos exemplos de uso do JS era "criar um link que mudava de acordo com a hora do dia".

O JavaScript teve um rival chamado JScript, a versão do JavaScript da Microsoft, que começou com Robert Welland no time do IE, mas antes trabalhou na Apple com o suporte para o Apple Newton (um tipo de PalmTop) com o NewtonScript, que era uma linguagem também baseada em objetos também influenciada pelo Self. E a Microsoft teve uma sacada interessante que foi criar um debugger para JavaScript embutido no IE, algo que o próprio Netscape não tinha. Além de que eles perceberam que o IE não seria nada se ele não tivesse compatibilidade completa com os sites que o Netscape apresentava. E isso levou o JScript e o IE a fazer uma engenharia reversa do Netscape para tentar fazer com que ambos estejam mais ou menos parecidos.

ECMAScript e atualidade

O JavaScript estava claramente ganhando a corrida dos browsers, e ter duas linguagens diferentes não era uma coisa legal. A falta de uma especificação, de um padrão, era um grande problema. Além disso, quando o projeto do Mocha começou em 1995 já era claro que uma especificação iria precisar ser feita para que fosse possível a interoperabilidade com toda a Web.

Por isso tanto a Sun quanto a Netscape planejaram propor uma especificação para o W3C e a IETF. Mas nem uma nem a outra eram boas para ter uma especificação independente de uma marca, a IETF focava em protocolos, a W3C não queria ter uma linguagem própria porque isso ia contra os propósitos da organização. Mas a necessidade não era só para ter um padrão, mas também porque a Microsoft estava pressionando para ter o VB como linguagem padrão, então ter uma especificação formal iria ajudar o JavaScript a se estabelecer como uma linguagem séria.

Foi ai que Carl Cargill, um especialista em especificações trabalhando para Netscape, colocou a empresa em contato com a ECMA International e propôs que a ECMA tomasse o controle da especificação. Então, no dia 4 de Novembro de 1996 a ECMA montou uma reunião para definir o comitê técnico (Technical Committee, ou TC) de número 39, o TC39. Se houvesse interesse suficiente, esse comitê seria efetivado. O que aconteceu, e a primeira reunião do TC39 aconteceu no dia 21 de Novembro do mesmo ano.

Eu tenho um vídeo explicando como o TC39 funciona se você estiver interessado!

O resto dessa história é bastante conhecida, mas existem muitos detalhes interessantes que, infelizmente, vão ficar de fora desse texto. Mas, a partir daí, o JavaScript teve várias evoluções desde a primeira especificação, mas o que fez do JS a linguagem mais conhecida foi a chegada do Node em 2009 que transformou o ecossistema da Web e fez com que o JavaScript tivesse uma adoção astronômica, incluindo novas especificações e evoluções da linguagem que transformaram o JavaScript no que a gente conhece hoje.

Mas essa é uma história para outro Backlog!

Muito obrigado por chegar até aqui, e te vejo na próxima edição!

E se eu te falasse que sucesso é pura sorte? Que o mês que você nasceu pode ter feito a diferença entre você ser super rico ou não? Nessa edição, vamos discutir sobre por que o sucesso é pura sorte, ou quase...

Há alguns meses eu terminei de ler um dos livros mais interessantes que eu já li, Outliers (ou Fora de Série) por Malcolm Gladwell, que também é autor de outros livros como "Blink" e "O Ponto da Virada". No geral, ele sempre toca em assuntos sobre carreira e ideias que a gente não costuma pensar tanto no dia-a-dia. Nesse em específico ele foca em uma questão:

Por que alguns tem sucesso, e outros não?

O Mito do Talento

Desde pequeno eu ouvi que "quem trabalha duro e se esforça consegue tudo", que "determinação é a chave do sucesso", ou até mesmo que eu tinha "talento" para alguma coisa. Mas a realidade é que isso tudo não passa de uma história para fazer a gente se sentir bem com a gente mesmo. Ou será que não?

A realidade é que talento como um todo é algo muito superestimado. Por exemplo, a gente tende a louvar pessoas que tem um talento incrível, um jogador de futebol, um guitarrista, um artista plástico. Mas, enquanto o talento é sim importante para que essas pessoas chegassem onde chegaram, ele não é tudo. Elas provavelmente não teriam tanto sucesso quanto elas tiveram tendo talento, mas continuariam tendo sucesso da mesma forma sem ele. Eu chamo isso de "o mito do talento".

Talento como um todo é algo muito superestimado.

Outliers é o livro que popularizou o conceito de que você precisa aplicar 10.000 horas de prática para ser um mestre no que seja que você está fazendo. E isso é totalmente verdade, para que você seja realmente bom em algo, você precisa de muita prática deliberada. E isso também é uma das métricas para o sucesso.

Ou você acha que os Beatles começaram e já foram um sucesso logo de cara?

A história dos Beatles, contada no livro, diz que, durante os primeiros anos de banda, eles se encontraram com um empresário que conseguiu diversos shows para eles em Hamburgo. A casa de shows que eles tocavam era um local que precisava de uma atração que ficasse tocando durante a madrugada inteira, como iniciantes eles viram a oportunidade perfeita de não só construir um repertório fazendo covers, mas também testar músicas próprias, além de ganhar experiência de palco e condicionamento para longos shows.

Quando os Beatles estouraram, eles já tinham feito mais de 1200 shows somente naquele bar em Hamburgo, quase 9600 horas tocando sem parar as mais diversas músicas para os mais diversos públicos. Isso os colocou em contato com muitas pessoas que já conheciam a banda, além de outros administradores e empresários que tinham outros contatos para outros shows.

A história dos Beatles mostra que talento sozinho não basta. Mesmo sendo músicos excepcionais, sem os 1200 shows em Hamburgo, eles não teriam a experiência ou os contatos necessários para alcançar o sucesso. Você precisa sim colocar um grande esforço, mas muito depende do quanto você está preparado quando a hora chegar.

Talento importa, mas o contexto é essencial

O talento é uma mistura de vários fatores, muitos deles ligados a fatores externos que você não tem como controlar, como:

• Contexto histórico
• Herança cultural
• Oportunidades

Ou até mesmo coisas que parecem sorte aleatória. Talento e trabalho duro com certeza importam, mas são amplificados quando você atende a outras condições, e essa não é a única história que eu tenho pra te contar. Como uma das pessoas mais ricas do mundo aproveitou suas oportunidades para se tornar quem se tornou.

Pausa para um aviso!

Essa newsletter só é possível através da ajuda da comunidade e dos patrocinadores!

Essa em particular é patrocinada pela Remessa Online! Se você trabalha com tecnologia, com certeza já precisou trazer algum dinheiro de fora para o Brasil, e as taxas são SUPER ALTAS 😭 Por isso a Remessa é a melhor forma de fazer isso com a menor taxa do mercado! E ELES ESTÃO COM PROMOÇÃO DE BLACK FRIDAY!

A campanha Black&Blue da Remessa Online é realmente uma das campanhas mais interessantes que eu já vi! Eles não vão só te dar desconto, eles te dão dinheiro! Dos dias 25 a 29 de Novembro você pode usar o meu cupom BFLUCASSANTOS para ganhar mais R$0,03 no câmbio para recebimentos de transferências internacionais e uma redução do mesmo valor para envios de pagamento, então seu dinheiro vale, literalmente, mais!

👉 Clica aqui pra transferir com a menor taxa do mercado!

🌟 Quer fazer parte desse sonho comigo? Trazer essa newsletter ao mundo é algo que sempre quis fazer, e ver o projeto crescer com o apoio de vocês seria incrível! Se você tem uma marca ou produto que se conecta com essa comunidade, manda um e-mail para hello@lsantos.dev. Vou adorar conversar sobre como você pode apoiar essa jornada!

💙 Apoie o meu trabalho: Se você gosta do conteúdo e quer dar uma força, mesmo com apenas R$1, isso já faz toda a diferença! Clique aqui para contribuir mensalmente ou fazer uma doação única. Cada apoio me ajuda a manter essa newsletter viva e a fazer dela algo especial. Muito obrigado por estar aqui e por acreditar nesse sonho comigo!

A sorte no sucesso

Você está lendo essa newsletter agora, provavelmente gosta de computadores (ou você não iria me conhecer), então você deve conhecer Bill Gates. O Co-Fundador da Microsoft, a maior empresa de softwares do mundo (e meu ex-chefe), já foi o homem mais rico do mundo e continua nessa lista até hoje. E se eu te disser que tudo isso foi sorte? Claro, o talento estava lá, mas a sorte foi o principal fator para o seu sucesso. O livro também conta a sua história.

Fatores externos moldam a sua vida, mesmo que você não tenha nenhum poder sobre eles

O ano em que você nasceu pode determinar muito sobre sua trajetória. Eu, por exemplo, nasci em 1995. Se tivesse nascido 10 anos mais tarde, teria perdido a explosão dos computadores e da internet. Dez anos mais cedo, talvez nunca tivesse entrado na área de tecnologia. Meu momento me deu vantagens específicas, como aprender a trabalhar bem sem internet e lidar com coisas analógicas. E o mesmo aconteceu com o tio Bill.

Bill Gates nasceu em 1955, na época perfeita para aproveitar a revolução dos computadores pessoais dos anos 70. Se tivesse nascido 10 anos antes, seria velho demais. Dez anos depois, novo demais. Gates também teve sorte de estudar na Lakeside School, uma escola particular de elite que, em 1968, adquiriu um terminal de computador. Lá, ele começou a programar jovem e já acumulando suas 10.000 horas de prática

Além disso, outra coincidência improvável é que, se você lembrar da última edição, na época os computadores usavam tempo compartilhado, ou seja, eles eram conectados a um mainframe próximo.

Por morar próximo à Universidade de Washington, que tinha um mainframe e terminais disponíveis para uso noturno. Ele passava madrugadas programando, graças a pais compreensivos que o deixavam ficar fora até tarde. O esforço contou, mas o contexto foi essencial.

Se ele tivesse a oportunidade e não tivesse programado durante madrugadas, nada teria acontecido, foi a visão de entender que essa era uma oportunidade e agarrar essa oportunidade que fez a diferença.

Não é sobre esforço individual, é sobre o contexto desse esforço

Para coroar, aos 16 anos, ele ainda teve a oportunidade de trabalhar na TRW, ao lado de engenheiros experientes, em um projeto de software. Essa experiência o colocou anos à frente da maioria dos estudantes de sua geração. Tudo isso culminou na criação do interpretador BASIC para o Altair 8800, junto com Paul Allen. Se tivesse nascido 5 ou 10 anos depois, nada disso teria acontecido.

O ponto não é diminuir o esforço ou talento dele, mas destacar que ele soube aproveitar um contexto de oportunidades únicas.

Eu não estou dizendo que esforço é inútil, ou que talento não conta, mas dizendo que talento e esforço sem aproveitar a oportunidades não vale nada

Uma outra história parecida é a de Bill Joy, criador do Vi (hoje Vim) e co-fundador da Sun Microsystems, que eu vou contar com mais detalhes em uma edição futura do Backlog. Ele também foi extremamente talentoso, mas muito graças ao local onde ele estava e ao momento que ele viveu. Mas, e se o talento realmente não importasse?

Por que o arroz importa?

Até agora, vimos como o talento foi importante, mas não decisivo, para algumas histórias de sucesso. Porém, existem casos em que o talento realmente não tem nada a ver com o sucesso ou habilidades de alguém.

Por exemplo, há um estereótipo de que pessoas asiáticas são ótimas em matemática. Mas e se eu te dissesse que isso tem mais a ver com arroz do que com genética?

Os agricultores asiáticos trabalhavam 3000 horas por ano versus as 1200 horas de um europeu médio

Durante séculos, o cultivo de arroz foi o principal pilar econômico e cultural em partes da Ásia, especialmente na China. Diferente de outros cultivos, plantar arroz exige atenção constante o ano todo: a quantidade certa de solo sobre a semente, o nivelamento perfeito do terreno e o controle preciso da irrigação. Sistemas complexos de alagamento e drenagem precisavam ser ajustados regularmente, tornando o cultivo um processo incrivelmente meticuloso e trabalhoso. Então o trabalho duro está ali, eles estão fazendo todos os dias

Os agricultores asiáticos trabalhavam, em média, 3.000 horas por ano, enquanto os europeus, 1.200. O cultivo de arroz era meticuloso e exigia esforço constante — desistir não era uma opção, ou ninguém comeria. Essa cultura de esforço intenso, precisão e foco no longo prazo foi passada de geração em geração, criando um legado que persiste até hoje.

E essa persistência e foco em resolver questões difíceis faz com que essa galera não desista fácil, e persista mesmo quando tudo parece dar errado.

E é por isso que eles são melhores em matemática, porque é algo que exige resiliência, esforço, você não pode desistir porque está com um problema difícil. Essas coisas precisam de tempo, esforço. É essa característica que o arroz proporcionou para essa cultura: a persistência.

Enquanto na maioria do mundo ocidental as crianças e adolescentes tendem a abandonar uma tarefa difícil após 5 minutos em média sem conseguir progresso, as crianças orientais tendem a se esforçar por pelo menos 30 minutos, seis vezes mais. E essa persistência e foco em resolver questões difíceis faz com que essa galera não desista fácil, e persista mesmo quando tudo parece dar errado.

Isso não tem nada a ver com talento, mas sim com uma herança cultural que é passada se você nasceu em um determinado local, e apenas ali. Nesse caso é uma característica positiva, mas e se essa herança fosse o maior problema da sua vida?

O preconceito como oportunidade

Uma outra história contada no livro é como o preconceito contra estrangeiros acabou por transformar esses estrangeiros em advogados de sucesso. E como coisas completamente fora do seu controle, como sua herança racial, podem ser decisivas para sua história.

Se você fosse filho de imigrantes do Leste Europeu você sofreria preconceito

Na década de 1940, o mercado jurídico nos EUA era dominado por grandes escritórios tradicionais, que recrutavam apenas advogados de famílias protestantes ricas, formados em universidades de prestígio como Harvard ou Yale. Filhos de imigrantes do Leste Europeu, em sua maioria judeus, enfrentavam preconceito por não serem tão ricos e, mesmo com boas formações, eram excluídos desses escritórios.

Sem acesso às áreas tradicionais, esses advogados se especializaram em campos menos prestigiados na época, como litígios corporativos e fusões e aquisições — áreas vistas como “sujas” e evitadas pelos grandes escritórios. Para eles, essas práticas eram as únicas oportunidades disponíveis, mas também o início de algo muito maior.

Sorte é estar preparado quando a hora chegar

Porém, na década de 1970, o mercado mudou completamente. Fusões e aquisições se tornaram extremamente lucrativas, e, de repente, o mercado jurídico precisava de especialistas. Os melhores? Justamente os advogados judeus, que tinham mais de uma década de experiência nessas áreas negligenciadas.

Essa exclusão inicial, fora do controle deles, os forçou a se especializar em um campo que mais tarde se tornou central no direito corporativo. Sem essa barreira, talvez tivessem seguido caminhos convencionais e nunca se destacado como líderes. Preconceito nunca é algo positivo, mas essa história mostra como situações adversas podem, inesperadamente, abrir portas para novas oportunidades.

E isso não tem NADA A VER com talento

Se a gente fizer a transposição dessa mesma ideia para os dias de hoje, tirando a parte de ser algo "sujo", os antigos engenheiros de Machine Learning e IA que antes eram considerados como áreas "descartáveis" ou "de pouca importância" agora se tornaram indispensáveis para uma geração que depende cada vez mais deles.

Do mesmo jeito que essas histórias mostram como coisas aparentemente sem importância podem virar oportunidades incríveis, minha trajetória também teve um pouco disso.

A Minha História

Para finalizar essa edição, eu quero contar um pouco do que eu acho que minha história tem a ver com isso. E eu acho que é até um pouco parecida com a história de outros como Bill Gates (só um tiquinho menor).

Desde pequeno eu tive contato constante com hardware, software

Nasci em 1995 e tive muita sorte de crescer em um ambiente curioso e cheio de experimentação, graças aos meus pais, especialmente meu pai. Ele tinha uma locadora de VHS e usava um computador para fazer as planilhas, o que me deu contato constante com tecnologia desde pequeno.

Meu pai era super autodidata e consertava tudo sozinho — lâmpadas, cabos, chuveiros — e eu estava sempre por perto, absorvendo tudo. Com o tempo, essa curiosidade virou aprendizado. Aos 6 anos, eu já desmontava e montava computadores (às vezes pra limpar as peças da locadora) e sabia identificar resistores, transistores e capacitores — mesmo sem entender exatamente pra que serviam. Esse contato precoce com hardware e software foi uma vantagem enorme que pouca gente teve.

Com 6 anos eu conseguia montar e desmontar computadores

Nas décadas de 2000, no boom da Internet e dos computadores, eu já estava mexendo com máquinas desde cedo, mas ainda era novo pra conseguir um emprego. Quando entrei na escola técnica, já dominava boa parte do que era ensinado, o que facilitou muito minha vida na hora de buscar trabalho.

Um dia, em um evento que, digamos, não era exatamente popular com a galera descolada, me ofereceram uma bolsa em uma escola de design — algo que eu sempre quis aprender. Decidi começar o curso, e foi aí que rolou a primeira coincidência. Lá, conheci alguém que me conectou ao meu primeiro emprego de verdade, onde fiquei por 5 anos, mesmo sem ter faculdade ou formação formal na área. Eu nunca fiz um estágio.

Nos 3 anos seguintes eu acumulei experiências que poucos na minha faculdade possuíam

Quando entrei na faculdade, já trabalhava como desenvolvedor há mais de 2 anos nessa consultoria, o lugar perfeito pra aprender, já que eu lidava com diferentes clientes quase toda semana. Nos 3 anos seguintes, acumulei mais experiências do que em anos na área, algo que poucos colegas tinham, porque enquanto eles só estudavam, eu fazia os dois – ao custo da minha saúde, infelizmente.

Quando me tornei desenvolvedor sênior, eu tinha 24 anos, e tinha 6 anos de experiência. Eu já palestrava e compartilhava o que sabia — em parte pra não esquecer — isso me conectou com muitas pessoas e abriu ainda mais portas.

Não me considero um programador excepcional, nem extremamente talentoso. Eu só estava no lugar certo, na hora certa, com as habilidades certas para o momento. Uma mistura de trabalho duro, sorte e contexto. Novamente, nunca é só talento.

A pergunta final que eu deixo pra você é o seguinte:

Como pode aproveitar as oportunidades ao seu redor para transformar seu contexto em sucesso?

Olá e seja bem vindo(a) a mais uma edição do Backlog! A newsletter onde eu destilo tudo que eu gostaria de falar sobre tópicos que eu acho muito interessantes!

Hoje a gente vai conversar sobre um dos assuntos que eu mais gosto: história! Você sabe qual foi o PC que provavelmente deu origem a todos os computadores pessoais da história?

Computadores e pessoas

Você agora está lendo essa newsletter no seu computador, no seu celular, no seu video game (quem sabe?), a gente muitas vezes nem pára para pensar como chegamos aqui, para a maioria de nós (eu com certeza) quando nascemos, o computador já existia, as pessoas já conheciam o conceito do computador pessoal, mas isso nem sempre foi assim.

Os primeiros computadores do mundo foram criados na década de 1940 com o único objetivo de quebrar cifras alemãs na segunda guerra, o primeiro computador programável do mundo foi o Colossus, construído em 1944, ele ocupava uma sala inteira e era composto de mais de 2500 válvulas, além de milhares de relês eletromecânicos.

Eu vou falar do Colossus nas próximas edições. Eu recentemente fui até lá em Bletchley Park (olhem meus highlights no instagram) e eu vi esse computador eu mesmo, nessa mesma sala da foto.

Ao longo dos anos eles foram ficando cada vez menores, porém não o suficiente para podermos chamar de um computador portátil. A próxima iteração de um computador útil, o ENIAC, ocupava 3 andares de um prédio e pesava 30 toneladas, isso não é necessariamente algo interessante para o público, mas tudo bem! Porque...

Ninguém precisava de um computador!

Por que alguém iria precisar de um computador? Naquela época, eles eram complexos demais e serviam a tarefas específicas. Tanto é que todos os computadores até então não tinham nenhum tipo de entrada de dados, como um teclado ou mouse, isso aconteceu BEM DEPOIS, eles eram operados por alavancas e patch boards

Personal computers

Nos final dos anos 50 os computadores reduziram um pouco de tamanho. Esses computadores eram os considerados "personal computers", porque precisavam de somente uma pessoa para operar, enquanto os anteriores precisavam de várias e, geralmente, um local refrigerado especial onde pudessem ficar. Perto de 1960, o Librascope LGP-30 foi o primeiro computador "pessoal" que tinha um input humano ou uma HID (Human Interface Device), que era uma máquina de escrever. Ele exigia menos operadores e uma instalação mais simples.

Muitos anos depois em 1965, a IBM lança uma linha de computadores chamado IBM System/360, ainda focado em empresas, ele foi um dos primeiros a ter um software único para todas as máquinas, além de vários periféricos, provando que todo funcionário poderia usar o computador, com menos treinamento do que antes.

O IBM System/360 modelo 40 era um dos menores mainframes da época, ele "só" ocupava uma sala de aula e podia custar mais de $300.000 dólares (de 1965)

Pausa para o aviso!

Essa newsletter só é possível através da ajuda da comunidade e dos patrocinadores!

Essa em particular é patrocinada pela Remessa Online! Se você trabalha com tecnologia, com certeza já precisou trazer algum dinheiro de fora para o Brasil, e as taxas são SUPER ALTAS 😭 Por isso a Remessa é a melhor forma de fazer isso com a menor taxa do mercado e SEM BUROCRACIA!

Você pode automatizar seus recebimentos depois da primeira operação e ainda economiza muito porque a Remessa tem as melhores taxas do mercado! Se você ainda não conhece e não começou a usar a plataforma, aproveita que é só clicar aqui embaixo e usar meu cupom LSANTOSDEV pra ganhar 15% de desconto nas suas transações.

👉 Clica aqui pra transferir com a menor taxa do mercado!

🌟 Quer fazer parte desse sonho comigo? Trazer essa newsletter ao mundo é algo que sempre quis fazer, e ver o projeto crescer com o apoio de vocês seria incrível! Se você tem uma marca ou produto que se conecta com essa comunidade, manda um e-mail para hello@lsantos.dev. Vou adorar conversar sobre como você pode apoiar essa jornada!

💙 Apoie o meu trabalho: Se você gosta do conteúdo e quer dar uma força, mesmo com apenas $1, isso já faz toda a diferença! Clique aqui para contribuir mensalmente ou fazer uma doação única. Cada apoio me ajuda a manter essa newsletter viva e a fazer dela algo especial. Muito obrigado por estar aqui e por acreditar nesse sonho comigo!

SCAMP e miniaturização

Computadores só eram tão grandes usavam relês, válvulas, transistores e outros componentes eletromecânicos, com a invenção de técnicas de miniaturização como o circuito integrado, começou a ser possível reduzir o tamanho dos computadores.

O SCAMP (Special Computer APL Machine Portable) foi um computador desenvolvido na IBM em 1973 como um protótipo de uma máquina portátil que poderia ser carregada com todos os periféricos para qualquer lugar e foi o que deu origem ao que a gente chama hoje de IBM PC, mas ainda sim era caro e focado em usos comerciais, ele ainda era bem caro.

Computadores pequenos eram muito mais caros, os computadores mais "baratos" eram enormes, não existiam computadores que fossem pequenos e baratos. Além disso, nenhum computador era necessariamente fácil de programar, você precisava de um conhecimento quase arcano para conseguir entender o que estava acontecendo e como operar o computador.

Geralmente esses computadores tinham manuais de instruções que eram verdadeiros compêndios de texto. Livros com mais de 800 páginas descrevendo em detalhes não só cada operação, mas o caminho lógico de cada circuito do mainframe. Igualzinho a gente faz com documentação hoje em dia...

Revolução em 1975

Mas isso mudou bastante em 1975 quando uma empresa chamada MITS criou um computador visionário chamado Altair 8800.

O Altair é considerado por muitos como o primeiro computador pessoal da história, porque ele não era focado em empresas ou em aplicações comerciais, ele era essencialmente um processador programável que continha uma linguagem de alto nível (BASIC) e um interpretador para essa linguagem (criado por Bill Gates e Paul Allen).

Esse computador custava $297 USD, ordens de grandeza mais barato que um computador empresarial. Ele tinha 255 bytes de memória (expansível até 64kb), mas não exibia nada em telas, a única saída de um Altair eram luzes vermelhas.

Pra quem tiver curiosidade, o filme "Piratas do Vale do Silício" mostra em detalhes a saga do Bill Gates e do Paul Allen com o Altair 8800, vale bastante a pena assistir

O Altair se tornou o que todos conhecemos como o primeiro computador pessoal bem sucedido de todos, ele era pequeno, barato, era fácil de carregar e não era focado em um público comercial, mas sim hobbystas da computação que queriam brincar com essa tecnologia em suas casas, mas existe uma parte perdida, antes do Altair, a história do MCM/70, o real computador pessoal, ou pelo menos a primeira tentativa de um...

O real computador pessoal

Pouquíssimas pessoas conhecem a história de uma empresa chamada MCM (Micro Computer Machines), criada perto de 1971 pelo canadense Mers Kutt. Mers era um professor de matemática na Queen's University em Ontario que tinha um problema sério com como o método de como os alunos e professores tinham que esperar dias para rodar programas no modelo de computação compartilhada, que consistia nos seguintes passos:

1. Escrever seu programa em cartões perfurados
2. Mandar os cartões perfurados fisicamente para um mainframe (como o IBM360)
3. A galera que operava o mainframe iria rodar seu programa e te dar a resposta

Existiam vários problemas ai, o primeiro era que se você errasse o programa e ele não rodasse no computador, você teria que passar por tudo isso de novo. O outro é que as pessoas que rodavam os programas tinham que priorizar o que era executado e, se você tivesse alguma briga com algum deles, seu programa provavelmente iria pro final da lista.

Todo o processo era muito lento e ele queria transformar o uso de computadores porque ele acreditava que todas as pessoas que usassem um computador poderiam criar coisas incríveis, mas estavam sendo barradas por causa das limitações técnicas. com essa ideia em mente, ele partiu para propor uma ideia de um computador que fosse:

• Pequeno o suficiente para ser levado por aí
• Barato para que as pessoas pudessem ter
• Fácil de usar para que todos pudessem construir algo

Esses eram os três principais problemas da época, e ele queria resolver todos os três de uma vez só. Por sorte, ele conhecia Robert Noyce, o primeiro CEO da Intel (e fundador) que disse que a ideia poderia funcionar em um processador que a Intel estava trabalhando, o Intel 8008.

Vale lembrar que, enquanto a gente sabe e conhece o conceito de computador pessoal, isso não era algo existente na época, ninguém sabia o que era um PC.

É importante ressaltar que a Intel não era uma corporação como é hoje, ela era basicamente uma startup pequena. O Intel 8008 era pequeno, relativamente barato ($120) e tinha um clock de 0.8Mhz, o que era suficiente para uma pessoa rodar um programa.

Pra por em perspectiva, um Hert é 1 ciclo por segundo, 0.8Mhz é o equivalente a 800.000 Hertz, ou seja, o processador rodava 800.000 vezes por segundo. Hoje, um processador ruim roda a 2GHz, isso é 2.000.000.000 vezes por segundo. Seu processador deve rodar a 4.7 ou 5Ghz isso é 5800x mais rápido que o Intel 8008

Isso resolvia uma parte do problema, era possível conseguir computação relativamente barata e pequena, agora e o resto? Para memória física era possível usar fitas cassete, mas elas eram usadas principalmente para audio, para dados digitais a maioria dos leitores eram do tamanho de um micro-ondas, além disso, memória RAM era extremamente cara, um Intel 2102 com 1kb de memória custava $20 dólares por chip, você precisaria de, pelo menos 8kb, para fazer qualquer coisa.

E ainda tinha o problema do uso... Como fazer um computador fácil de usar? Bom, vamos por partes. Kutt nomeou esse projeto de M/C, que acabou virando o MCM/70, o primeiro computador verdadeiramente pessoal do mundo.

Hardware

Com o processador resolvido, a RAM era uma questão simples, porque não tinham muitas opções, então o MCM/70 tinha 8kb de RAM (8 chips 2102, $160 dólares) e uma ROM que iria conter a linguagem do computador.

Para armazenar os dados externamente eles usaram um leitor de fita cassete sequencial, era como se fosse uma fita comum de audio, eram compactas mas lentas... Para deixar tudo mais fácil, o MCM/70 tinha um display SELF-SCAN de 32 caracteres (que era algo inovador na época), igual ao abaixo:

SELF-SCAN é o nome dado a uma família de displays de plasma que podiam exibir caracteres com mais detalhes do que os tradicionais 7-segments, mas usavam muito mais recursos, mas isso era necessário, porque, para deixar o computador mais fácil, eles teriam que usar algo que a galera pudesse entender.

Software

Com os problemas de hardware quase resolvidos, o último problema era como deixar o computador fácil de usar. Para isso Kutt, que já acompanhava o trabalho do Ken Iverson para criar a linguagem APL, uma linguagem matemática que usava símbolos especiais mas era poderosa o suficiente e tinha como ser executada em pouca memória.

O problema era que o custo de criar um teclado diferenciado para APL era mais alto, mas isso, na teoria, pagaria o projeto.

Mas, Kutt não era um programador, então ele contratou Gord Ramer - que já tinha feito um interpretador de APL com baixo uso de recursos antes - para poder criar o interpretador e colocar ele diretamente na ROM do computador. E essa parte é uma das mais interessantes de toda essa história.

Codando para um 8008 sem um 8008

Eles não tinham um Intel 8008 disponível porque eles começaram o desenvolvimento do protótipo antes de o chip ficar pronto, mas a universidade Kingston tinha um IBM360 com um emulador de um Intel 8008. Você colocava um código 8008 ali e ele iria te devolver um código hexadecimal para rodar no hardware, simples assim. O problema era que o IBM360 operava com cartões perfurados, então todo o interpretador de APL era escrito em cartões perfurados do IBM360, levados para a universidade para serem lidos e o código de resposta era também escrito em cartões perfurados e depois digitado manualmente pelos devs dentro do MCM/70 (o protótipo).

E como a viagem entre o escritório e a faculdade era de uns 10 minutos, não era algo que você iria fazer rotineiramente, como dev, você iria usar um debugger que permitia que você editasse o seu código direto no processador, anotasse as mudanças, e depois recompilasse o código correto na universidade.

O que aconteceu?

O MCM/70 foi lançado em 1974, um ano antes do Altair 8800. Ele custava $4950 dólares canadenses na versão com 2Kb de RAM e sem cassetes e $9800 com 8Kb e dois cassetes. Pela primeira vez um computador foi chamado de computador pessoal, tendo clientes além de governos e grandes instituições e começando a entrar em locais menores como hospitais e lojas.

Nos dois anos seguintes o MCM/70 foi renomeado para MCM/700 e, em 1976, o sucessor MCM/800 foi lançado com um processador mais rápido, 16Kb de RAM e poderia usar um monitor externo. Até 1978 a MCM lançou o 900 e o 1000. Mas, mesmo depois de vender muitas unidades, sendo o primeiro computador vendido comercialmente que já continua um monitor, teclado, memória e tendo um preço relativamente barato ele nunca chegou a ser altamente usado fora do meio acadêmico ou comercial. No final dos anos 70 a MCM já tinha vários competidores com computadores mais baratos e mais simples (como a MITS e o Altair) que caíram no gosto do público geral.

Em grande parte, o problema do MCM era a linguagem APL que era extremamente complexa e complicada porque era totalmente composta de símbolos matemáticos, o que não era o caso do Altair e o BASIC que era muito mais simples e direto.

Em 1983, após tentar conseguir um financiamento para um modelo mais avançado e falhar, a empresa fechou as portas e vendeu suas patentes e projetos para outras empresas, inclusive a Alcatel.

Mais detalhes

Se você quiser saber mais sobre essa história, Cam Farnell, um dos empregados da MCM na época, deu uma palestra que fala sobre o MCM/70.

Além disso existe um livro chamado "Inventing the MCM/70" publicado pelo professor Zbigniew Stachniak, mas eu não consegui achar ele em nenhum lugar...

E essa foi a história por trás da história do primeiro computador pessoal do mundo. O MCM/70 pavimentou o caminho para o que conhecemos como computadores pessoais hoje.

Ele solucionou questões cruciais de tamanho, acessibilidade e usabilidade, embora tenha sido ofuscado por concorrentes mais simplificados. Corrigindo esses erros, futuras gerações de PCs seguiram caminhos que moldaram tudo o que a gente conhece como computador.

Olá!

Você não me vê por aqui há um tempo não é mesmo? E foi por um bom motivo. Essa daqui é uma nova newsletter que eu comecei, ela será bi-semanal e vai focar em um conteúdo mais pessoal, de coisas que eu gosto de escrever.

Essa edição vai ter só texto, mas a ideia é intercalar com imagens e coisas interessantes.

Eu quis mandar esse email agora (podemos chamar de pré-newsletter) para contar uma história, a história de como eu cansei de tudo que eu estava fazendo e resolvi começar tudo de novo. Uma história que eu queria contar pra você há muitos e muitos anos... Vai parecer estranho no início, mas fica comigo até o fim que espero que essa mensagem mude a sua vida como mudou a minha.

Criar conteúdo é cansativo

Crio conteúdo desde 2014. São 10 anos publicando na internet: textos, vídeos, podcasts, palestras, participações em outros canais, no total são mais de 2000 conteúdos... A criação de conteúdo é, simultaneamente, minha forma de documentar o que aprendo e minha maneira de retribuir à comunidade que me proporcionou tanto. Posso dizer, sem hesitar, que não teria chegado onde estou hoje se não fosse por criar conteúdo.

Porém, criação de conteúdo é muito mais do que só escrever um texto, criar um artigo, fazer um vídeo. Aquilo que você vê ali é o resultado final de muitas horas de trabalho e, as vezes, anos de pesquisa e experiência. Muitos dos meus artigos lá no meu blog demoraram horas para serem escritos – alguns, como o de criptografia RSA, levaram dias! Entre pesquisar algo, resumir, verificar, escrever, verificar novamente e, no final, tentar arrumar um jeito de deixar o conteúdo chamativo, mas ao mesmo tempo educativo.

O desafio do Criador CLT®

Tudo isso enquanto mantenho um emprego formal - sou o famoso "Criador de Conteúdo CLT", ou seja, eu amo o que eu faço, porém não paga as contas. Adoraria criar conteúdo em tempo integral mas, diferente do que muitos pensam, a não ser que você seja extremamente grande, criar conteúdo não é tão lucrativo assim. A previsibilidade de um emprego ainda é necessária na maioria dos casos.

Como faço grande parte sozinho, preciso usar vários chapéus: empresário, designer (sim, todos os gráficos que você vê aqui foram feitos por mim), social media, marketing e outros. O trabalho não termina na publicação - é preciso divulgar, alcançar mais pessoas... mas para quê?

As métricas da vaidade

Por mais que a gente fale que não se importa com a quantidade de seguidores, o número de likes, ou qualquer coisa do tipo, a realidade é que isso é necessário para te dar uma métrica de como você está impactando as pessoas.

Eu adoraria esconder todas as métricas e focar apenas nos comentários de feedbacks, mas eles são raros. As pessoas não interagem tanto nos conteúdos, então as métricas acabam sendo nossa única forma de avaliar se o conteúdo funciona, se precisamos mudar a abordagem.

E, como criador de conteúdo, o lado comercial também é importante. Marcas e anunciantes olham essas métricas para saber em média a quantidade de pessoas que eles podem atingir ao veicular um produto ou anúncio com você.

Ah, mas anúncios são ruins, por que tem que ter anúncios?

Concordo que anúncios podem ser problemáticos, mas são frequentemente a única forma de equilibrar tempo e retorno financeiro. O desafio é que muitos anunciantes acabam interferindo no conteúdo, algo que felizmente nunca precisei aceitar.

Mas então quer dizer que eu só crio conteúdo porque eu quero algo em troca? Não, na verdade esse é todo o ponto dessa newsletter. É uma rebelião, não contra os anunciantes, mas contra as redes sociais e a forma como nosso conteúdo é feito atualmente.

A minha rebelião silenciosa

Eu estou escrevendo essa edição à 01:10 da manhã, enquanto olho para o contador de palavras e penso: "Eu acho que isso está ficando longo demais", mas a realidade é que esse email vai ser tão longo quanto eu quiser que seja, essa é a minha newsletter, e eu vou falar o que eu quiser falar, por quanto tempo eu quiser falar, eu estou fazendo isso não para ganhar dinheiro ou para ficar famoso, eu estou fazendo isso porque eu adoro isso que eu faço, e eu quero compartilhar com você!

Rápido e superficial

O cenário atual privilegia conteúdo rápido e superficial. As redes sociais nos condicionaram assim porque conteúdos curtos significam mais tempo rolando feed, vendo mais anúncios, gerando mais lucro para elas. Agora temos especialistas de dez segundos em reels compartilhando assuntos (às vezes interessantes) de forma tão reduzida que muito se perde, focando apenas no que gera mais views (as vezes às custas da verdade).

Ao longo do tempo isso me desgastou tanto que eu pensei em parar de produzir conteúdo totalmente múltiplas vezes, porque eu adoro escrever (como você pode ver), e eu escrevo bastante, com detalhes, porque eu esqueço das coisas e meu próprio blog é um recurso que eu consulto tanto quanto os leitores. Não gosto de superficialidade, mas o modelo atual mudou não só para conteúdo raso e curto, mas também para priorizar vídeo sobre texto, o que força a gente a continuar criando (porque vídeos não são simples de editar...)

O que vem por aí?

E essa é a história dessa newsletter. Esse aqui é um espaço onde eu vou escrever muito, o que eu penso, vou ter opiniões (as vezes fortes), vou incitar discussões e te convido a comentar e participar comigo! Mas, acima de tudo: eu vou escrever o que eu gosto.

Aqui você vai encontrar:

• História da computação
• Resumos e opiniões sobre livros
• Experiências pessoais interessantes
• Reflexões sobre tecnologia e além
• Todo aquele conteúdo do meu "backlog mental" que sempre quis compartilhar
• Sugestões são bem vindas, só mandar nas minhas redes

Na próxima edição, vou trazer um tema que tem me fascinado ultimamente: história da computação! Mais precisamente a história do primeiro computador de todos pra manter o nosso ritmo de recomeços 😜

Espero que você goste desse novo espaço. Te vejo semana que vem!

Em 2020 eu participei de um dos episódios do Hipsters.tech onde a gente falou bastante sobre o que era esse tal de Deno, a nova ferramenta que tava surgindo por aí e prometia ser um substituto do Node.

Deno, o novo Node? - Hipsters #203 - Hipsters Ponto Tech

…

Hipsters Ponto TechAdmin

Quatro anos depois, o Deno finalmente chegou na versão 2.0, e dessa vez eu acho que ele realmente tem a capacidade de ser o substituto do Node.js. Mas deixa eu te dizer por que eu acho isso.

O que é Deno?

Antes de a gente começar, o que é o Deno? Há um ano eu e o Roz fizemos uma palestra sobre ele no Iugu Talks4Devs. Vale a pena dar uma olhada:

Em resumo, o Deno é um outro runtime criado pelo Ryan Dahl, o mesmo criador do Node.js, a ideia é que o Deno veio para corrigir os problemas que ele achava que poderiam ser prejudiciais para o Node.js, inclusive a presença de um gerenciador de pacotes que fosse privado como o NPM.

Deno é escrito em Rust e roda TypeScript nativamente, então você não precisa de uma etapa de compilação ou algo do tipo para poder rodar seu código, é como se, automaticamente, ele entendesse tudo que você quisesse fazer com o TypeScript e já interpretasse o código como JavaScript diretamente. Mas eu não vou me estender nisso aqui, temos um artigo aqui no blog que fala só sobre Deno:

Vamos falar sobre o Deno

O Node.js está finalmente morrendo? Seria esse o momento de migrarmos para o Deno? Bora entender tudo sobre ele nesse artigo!

Lucas SantosLucas Santos

Deno 2.0

O Deno 2.0 ainda se mantém fiel às funcionalidades que ele veio inicialmente para prover, e os problemas que ele veio inicialmente para resolver. Embora ele tenha se perdido um pouco no meio do caminho (já vamos falar sobre isso), ele ainda se manteve bem constante no que ele promete e no que ele entrega.

As principais propostas do Deno eram que:

• Ele teria suporte nativo a TypeScript, o que significa que você não teria que instalar nem o TypeScript nem nenhuma outra biblioteca como o TSX para executar TS no runtime
• Construído usando Web Standards, ou seja, ele teria implementações que seguissem estritamente as propostas do TC39 e da IETF. Isso é tão verdade que o Deno foi o primeiro runtime que implementou o Temporal, mas não só isso, Promises, Fetch, ESM e muitos outros já estão implementados nativamente
• Ele teria todas as ferramentas necessárias para poder criar e manter um projeto a longo prazo como: Linter, Formatter, Type Checker, um framework de testes, habilidade de compilar para um executável e mais
• Segurança em primeiro lugar com sistemas de permissões e etc

E isso continua sendo verdade, o que é impressionante, porque, geralmente quando runtimes como esses crescem (como é o caso do Node), concessões acabam sendo feitas de forma que as propostas originais meio que se perdem nos pedidos e nas ideias da comunidade.

As funcionalidades do Deno 2.0 são bastante interessantes, eu diria que são até bem corajosas:

• Suporte completo ao Node e NPM, então você pode rodar qualquer aplicação Node.js no Deno sem nenhuma configuração extra
  • Isso inclui o suporte nativo ao package.json e ao node_modules
• A adição de um package manager que você pode chamar com deno add, deno install e remover pacotes com deno remove
• A biblioteca padrão (stdlib) está oficialmente estabilizada e na versão 1.0
• Suporte para registros privados do NPM
• Suporte para workspaces e monorepo
• Deno agora vai ter calendário de releases e suporte a LTS
• A criação do JSR, que é um registro de pacotes similar ao NPM que suporte múltiplos runtimes

Além disso outras funcionalidades que já existiam agora estão melhores:

• deno fmt agora também formata HTML, CSS e YAML
• deno lint agora tem regras específicas do Node e pode arrumar erros automaticamente com deno lint --fix
• deno test suporta o Node.js Test Runner
• deno task também roda scripts do package.json
• A documentação gerada pelo deno doc agora é mais bonita com um layout melhor
• deno compile suporta assinar pacotes e ícones no Windows
• deno serve agora suporta rodar server usando múltiplos núcleos do processador em paralelo
• deno init tem a capacidade de scaffolding, então você pode ter templates de libs e servers
• deno jupyter para quem usa jupyter notebooks agora tem saída de imagens, gráficos e HTML
• deno bench para rodar benchmarks tem medidas mais precisas
• deno coverage tem saídas de cobertura de testes em HTML

Eu não vou passar parte a parte sobre cada mudança, esse artigo não tem esse foco, a ideia aqui é a gente discutir essas novidades e o que isso significa para o Deno e para o ecossistema de runtimes em geral, mas se você quiser que eu faça mais conteúdo sobre isso, me chama lá nas minhas redes sociais e me avisa!

Vem aprender comigo!

Quer aprender mais sobre Deno e boas práticas com #TypeScript?

Se inscreva na Formação TS!

Opniões

No geral, eu gostei bastante dessa nova versão do Deno, porém tem algumas coisas que eu achei um pouco estranhas. A primeira delas é o suporte a package.json e node_modules que foram coisas que explicitamente foram ditas que o Node tinha de ruim e que não seriam implementadas nesse novo runtime. Porém aqui estamos com suporte completo ao Node.

Enquanto eu entendo que, sem isso, não tem como o Deno competir com o Node de forma nenhuma, porque simplesmente o ambiente Node.js é muito maior do que o ambiente Deno e a comunidade também. Então era meio necessário que a galera do Deno implementasse compatibilidade para que pessoas que já usassem Node pudessem usar Deno de forma direta, sem nenhuma configuração, e isso inclui ter que suportar o ambiente do Node.

Ninguém gosta do node_modules, isso é claro em vários memes.

Então a solução aqui foi realmente suportar tanto o package.json quanto o node_modules, mas não forçar que eles sejam obrigatórios. Isso foi uma boa sacada. Se você quiser usar pacotes do NPM mas não quiser ter o node_modules instalado, você pode simplesmente substituir todas as declarações de imports tipo:

import Express from 'express' // express é uma dep no package.json

Para usar o prefixo npm::

import Express from 'npm:express'

Agora não é mais necessário ter o Express no package.json, e nem instalar nada no node_modules porque o Deno vai tomar o controle desse pacote e instalar ele no cache. Em projetos que são maiores você pode utilizar os import maps (que são um web standard) para poder mapear o nome do pacote para outro nome (o que é essencialmente um outro tipo de package.json, mas ajuda a saber o que está instalado):

// deno.json
{
  "imports": {
    "express": "npm:express"
  }
}

E isso me leva a outro assunto, que é o deno.json em si, que era uma das propostas originais de não ter um arquivo JSON que define todo o projeto. Enquanto ele não é necessário nem obrigatório (a não ser que você queira publicar algo no JSR), meio que se tornou uma boa prática ter esse arquivo ali. E isso é, basicamente, outro package.json.

JSR e Deno PM

O Deno seguiu um pouco nos passos do Bun incluindo um package manager dentro do binário, o que eu acho que vai completamente contra o que eles propuseram inicialmente (inclusive tem até um blog post do próprio Ryan Dahl sobre isso). Eu, pessoalmente, gosto muito do modelo de importação direto por URL que tínhamos antes (e, acredito, que ainda temos no Deno) que é uma forma mais decentralizada de manter os seus pacotes e não entregar o controle dele para organizações privadas, que podem simplesmente remover, alterar, ou até tomar conta de um pacote público.

Isso é tão verdade que existem vários exemplos disso acontecendo, onde empresas tem o controle total de pacotes públicos, como é o caso mais recente do WordPress que tomou conta (quase sequestrando) um dos plugins mais utilizados do ambiente. Substitua WordPress por NPM, Deno, JSR, ou qualquer outra coisa e você tem o mesmo resultado. Claro, tudo depende de como essas empresas se comportam, e o caso do WordPress é sim um caso muito separado por ter uma pessoa chave que tem o controle da maioria das coisas, mas ainda sim é uma possibilidade.

Por outro lado, centralizar pacotes dessa forma torna o ambiente mais seguro, e evita problemas como o que aconteceu com o Faker e o Left-pad (que mostra outro problema completamente diferente e muito mais sério, mas vamos nos ater a essa história). Nesses dois casos, o NPM conseguiu intervir e forçadamente tomar controle dos pacotes, republicando e/ou restaurando versões anteriores. Isso é um exemplo onde ter controle total é uma coisa boa, mas somente se a empresa que tem o controle tem boas intenções. Mas a pergunta que fica é:

Qual empresa tem boas intenções?

Voltando ao Deno, a criação do JSR e o uso do Deno como package manager não é necessariamente algo ruim porque ele basicamente se conecta a muitos gerenciadores e é utilizado como um cliente de cada um para baixar pacotes em múltiplos lugares diferentes. O Deno meio que virou o yarn, inclusive ele se compara a eles:

A ideia é boa, por exemplo, se você rodar deno install:

• Se você tiver um package.json, ele vai se comportar como um npm install, criando um node_modules e instalando todos os pacotes dentro dele
• Se você não tem um package.json ele vai cachear todas as dependências no cache global, a mesma coisa que a gente fazia com deno cache

Isso significa que você pode usar literalmente qualquer tipo de pacote que você quiser de qualquer origem que você quiser, ou seja, você pode usar pacotes presentes no JSR com import x from 'jsr:pacote@versao' junto com import x from 'https://url.com' e import x from 'npm:pacote@versao'. Apesar de interessante, eu imagino a bagunça que isso vai ser em projetos grandes.

Será o fim do Node.js?

Pela primeira vez eu tenho que dizer que realmente não sei. Com a adoção do Deno em maior escala a cada dia que passa, e a inabilidade do Node.js implementar as mesmas funcionalidades na mesma velocidade, eu vejo que muita gente vai acabar migrando para Deno sim, mas não acho que seja o fim do Node.js.

Apesar de ser mais devagar, o Node.js tem feito grandes feitos e está implementando coisas muito interessantes, como o suporte para rodar arquivos TypeScript com --experimental-strip-types e --experimental-transform-types. A adição do Node Test Runner, a melhoria desses pacotes e muitas coisas que estão sendo adicionadas conforme falamos.

Mas eu não acho que todas essas adições sejam suficientes para manter o projeto no ar, o Node é um projeto que tem muitas dependências, tem muitas cabeças envolvidas e muita política também, muitas empresas dependem desse projeto e estão tentando guiar para seu próprio benefício com membros nos comitês. Eventualmente, o Deno (ou o Bun, ou o próximo runtime) vai aparecer com uma funcionalidade que não temos como negar, por exemplo, no caso do Deno, para mim você poder compilar tudo para um binário é algo que é incrível, e muitas pessoas pensam o mesmo, mas isso raramente vai chegar ao Node.

Conclusão

O Deno 2.0 vem com muitas coisas boas e realmente vale a pena testar, talvez até mesmo implementar em um projeto e deixar ele rodando por um tempo, vou fazer alguns testes com projetos Node.js que tenho e quem sabe posto os futuros resultados por aqui, ou na minha newsletter!

Se você quiser ver alguma coisa por aqui não esquece de me chamar!

Não muito tempo atrás eu fiz uma série de previsões para o JS em 2025, e eu não estava tão longe assim da realidade! O TC39 se reuniu essa semana em Tokyo para poder discutir as propostas que seriam passadas para frente nas próximas versões do JS, essa foi a 104a reunião do comitê desde a sua criação.

Como sempre acontece, o Rob Palmer, que é um dos membros do TC39, posta no seu Twitter tudo que será discutido durante as reuniões. Este ano as pautas eram:

• Array.zip
• Atomics.pause
• Error.isError
• Extractors
• Immutable ArrayBuffer
• Iterator helpers
• Math.sumPrecise
• Promise.try
• RegExp modifiers
• Structs

E algumas delas realmente foram passadas para os próximos estágios, nem todas as que eu previ, mas pelo menos 50% delas! Essa foi minha maior taxa de acerto desde sempre! Vamos ver tudo que foi discutido:

Iterator helpers

Uma proposta que, na verdade, são várias. Aqui estamos falando não só dos helpers (que passaram para o estágio 4 e vão ser implementadas), mas também de outra proposta que eu comentei que poderiam ter avanços.

Essa proposta adiciona uma série de métodos de ajuda em iteradores (como Map, Set e generators), como o map, filter, reduce e muitos outros para transformar o uso de iteradores em algo mais próximo de um array.

Algo que hoje não é muito fácil de entender hoje em dia, porque, por exemplo:

const arr = [1,2,3]
arr.map((v) => v) // ok

const set = new Set([1,2,3])
set.map((v) => v) // erro, não temos map em sets

Veja que o Array, que é um iterable, tem map, mas o Set não tem, porque, por mais que a principal forma de usar um Set seja através de iterações, ele não é um Iterable.

Além dessa proposta, outra que eu também comentei (que estava em estágio 2) passou para o 2.7, Iterator Sequencing. Que permite que a gente crie iterators concatenando outros iterators com Iterator.concat assim como fazemos com Array.concat.

Import attributes & JSON Modules

Agora vamos, finalmente, poder usar o que a gente já estava usando há meses. As duas propostas que modificam a forma que importamos JSON e outros módulos passaram para o estágio 4 e serão implementadas!

Agora poderemos fazer isso:

import json from './arquivo.json' with { type: 'json' }

Originalmente as duas propostas eram uma só, mas elas foram separadas. O motivo é que, para os import attributes (o with) isso pode abrir oportunidades para que possamos importar outros tipos de arquivos nativamente que não sejam apenas JSON, por exemplo, XML ou CSV.

E então, cada módulo que será importado terá uma nova proposta como os JSON modules tiveram. Isso garante que os engines não tenham implementações específicas para cada coisa, por exemplo, imagina que droga que seria se cada browser lesse JSON de forma diferente...

Ambas as propostas foram passadas e agora teremos uma forma nativa de ler arquivos JSON diretamente do JS, algo que o Node já implementava, mas não era parte da especificação.

RegExp Modifiers

Mais uma que passou para o estágio 4. Agora vamos poder usar os modificadores como /i, /m e outros diretamente nas RegExps do JS. Essa foi uma que eu não sabia que estava sendo votada, eu admito, achei que essa funcionalidade já estivesse presente no engine atual, mas aparentemente não era algo que foi implementado (diferente de todas as linguagens anteriores que implementaram logo de cara... Vai saber)

Structs

Essa é uma proposta que eu realmente pensei que não fosse avançar tão rápido. Structs adicionam quatro objetos lógicos no JS:

• Structs: Objetos com layout fixo que se comportam como classes, mas com algumas restrições que deixam elas mais rápidas e mais fáceis de serem analizadas estaticamente por um compilador
• Shared Structs: Structs um pouco mais restritas que podem ser acessadas por múltiplas threads em paralelo. Essa estrutura sozinha é responsável por permitir paralelismo de verdade no JS
• Mutex e Condition: Abstrações para sincronizar acessos à structs compartilhadas
• Unsafe Blocks: Objetos que dizem onde uma memória não segura pode ser inicializada e trabalhada

A grande ideia dessa proposta começou com Structs, que seriam objetos fixos, que não podem ter mais ou menos campos, o que é incrível porque a maioria dos objetos que usamos são dessa forma. Assim o compilador não precisa otimizar todos os objetos para serem dinâmicos por padrão.

As SharedStructs vão permitir que possamos utilizar objetos que compartilham memória entre arquivos, sem precisar usar Realms ou outras estruturas. Essa proposta acabou de passar para o estágio 2 e agora será o design que vai ser trabalhado!

Extractors

Extractors avançaram para o estágio 2. Eles nada mais são do que uma função que pode ser aplicada quando estamos fazendo um destructuring de um objeto. Isso permite que a gente faça tanto validação quando normalização dos valores, por exemplo, podemos deixar todas as chaves minúsculas:

const LowercaseExtractor = {
  [Symbol.customMatcher](valor) {
    if (typeof valor === 'string') {
      return valor.toLowerCase()
    }
  }
}

const LowercaseExtractor({ nome, rua }) = { nome: 'LUCAS', rua: 'RUA' }
console.log({ nome, rua }) // { nome: 'lucas', rua: 'rua' }

Promise.try

Depois de 8 anos, o Promise.try finalmente entrou em estágio 4 e será implementado na linguagem! Essa aqui eu tinha previsto no outro artigo também!

A grande ideia aqui é algo bem simples, na verdade, quando temos um valor que não sabemos se é ou não uma promise, geralmente enrolamos ele em uma Promise e seguimos a nossa vida:

// Não sabemos se o retorno de F é uma promise ou não
const p = new Promise(resolve => resolve(F()))
// mas p sempre vai ser uma promise

Com essa proposta vamos poder mudar esse código para algo como:

await Promise.try(F) // retorna F como promise

Isso não é uma forma de rodar funções em paralelo ou de forma assíncrona, ele simplesmente chama função, que antes seria síncrona, de uma forma unificada como uma promise.

Error.isError

Mais uma das que eu tinha previsto que poderiam sair do estágio atual, o Error.isError foi para o estágio 2.7 e está aguardando testes e validações. A ideia aqui é bem simples e eu realmente não sei porque não temos isso desde sempre, mas essa proposta permite que façamos algo parecido com o Array.isArray, só que com erros:

if (Error.isError(err)) {
  // err é um erro
}}

O que vai limitar o uso de instanceof Error, já que o instanceof pode ser modificado externamente.

Conclusão

Existem outras propostas que também avançaram, mas sinceramente, não são algumas que vão fazer muita diferença na vida de todo mundo, duas mais interessantes foram o Array.zip e os Immutable ArrayBuffers que podem ser modificadas nos próximos dias.

Outras propostas podem ser cotadas para discussão também como:

• AsyncContext
• Dataview Clamped Methods
• Decimal
• Discard Bindings
• ESM Phase Imports
• Explicit Compile Hints
• Intl.DurationFormat
• JSSugar
• Math.emplace
• Measure Object
• Observables
• Porffor
• Smart Units
• Temporal

Pelo que eu vi recentemente, o Temporal está em alta e pode realmente ser que ele seja cotado para sair no ano que vem, então vamos observar.

Eu sempre gostei do Vim, mas esse editor é mundialmente conhecido por ser uma das peças de software mais complexas de aprender já criadas, até ganhando a fama de ser o lugar que você entra e nunca mais sai.

Porém existe a promessa da "produtividade super-humana" uma vez que você consegue se sentir confortavel o suficiente com ele.

Recentemente eu resolvi deixar de usar o VSCode 100% e começar a usar apenas o Neovim, e eu vou te mostrar como eu fiz pra deixar ele exatamente desse jeito:

Se você já conhece o editor, pode pular direto para a parte de instalação. Ou, se você quiser saber mais sobre a história do Vim, Vi e Neovim, deixa eu te contar.

Um pouco sobre Vim

Se você não sabe o que é o Vim, em poucas palavras, é um dos editores de texto mais antigos que ainda estão em uso. Ele foi criado por um cara chamado Bram Molenaar em 1991 como uma melhoria ao editor original Vi, criado por Bill Joy em 1976 como um modo visual para um outro editor chamado ed. Por isso que Vim é o acrônimo de "Vi improved".

O Vi, assim como o Vim, introduziu uma mudança drástica na forma de editar textos, a movimentação quase cirúrgica do cursor, e também a movimentação usando as teclas HJKL, como eu expliquei nessa thread:

Desde então muita gente adora usar o Vim porque ele é extremamente leve, fácil de configurar e tem basicamente uma linguagem própria de programação (VimL) que permite que você faça macros e muitas outras coisas de forma absurdamente poderosa.

O único problema é que ele tem uma das maiores curvas de aprendizado da história porque os comandos são definidos como sequências de teclas individuais e combinação de letras, mas quem consegue dominar o Vim tem um aumento estrondoso de produtividade simplesmente pelo fato de que o editor é extremamente responsivo.

Infelizmente o Vim sozinho, do jeito que ele vem "de fábrica", apesar de totalmente usável, não é o que eu chamaria de um bom editor de código, ele poderia ter sido lá em 1991, mas com o avanço das tecnologias, a integração cada vez mais próxima das linguagens com os editores e o movimento saindo dos grandes e complexos IDEs para editores menores com suporte a plugins deixou o Vim um pouco defasado, mesmo que ele tenha ganhado suporte a plugins.

Entra o Neovim

Neovim é um fork do Vim original feito por um Brasileiro chamado Thiago Arruda depois que ele não conseguiu apoio para implementar uma mudança no Vim original que permitiria que o editor tivesse múltiplas threads e pudesse ser controlado por processos externos. O primeiro commit do Neovim aconteceu em 31 de janeiro de 2014.

Dentre as muitas novidades do Neovim, o suporte nativo a Lua é uma das principais, o que significa que você pode escrever plugins e ferramentas de forma muito mais simples do que usando C ou VimL que, apesar de boas, são complicadas. Além de ter processamento assíncrono e ter o suporte nativo a LSPs (Language Server Protocol) que permitem a comunicação em tempo real do que você está escrevendo e um servidor em background que vai analisar o seu código (assim que a gente consegue auto completions, intellisense e análise de erros).

A partir daí o NVim ganhou cada vez mais suporte da comunidade e um aporte de algumas empresas através do OpenCollective e agora é um projeto open source completamente auto sustentável e mantido por alguns devs em tempo integral. E vai ser ele que vamos modificar hoje.

Vem aprender comigo!

Quer aprender tudo sobre #TypeScript e ficar pronto para o mercado?

Se inscreva na Formação TS!

Pré requisitos

Antes de a gente começar eu vou falar alguns pré-requisitos que você precisa ter para poder seguir esse tutorial de um jeito que você consiga aproveitar

1 - Tenha algum tipo de Linux

Embora seja sim possível instalar o Neovim em Windows com o Powershell, eu vou fazer a mesma coisa com um sistema Linux. Você pode estar usando Mac, alguma distribuição Linux, ou até mesmo o WSL no Windows com a distro que você preferir.

Eu estou escrevendo esse artigo em um Arch Linux, mas tudo que eu falar aqui pode ser transposto para o Mac (Darwin) sem problemas, os arquivos ficam no mesmo lugar.

2 - Tenha uma shell pronta

Eu estou usando um ZSH com o Zinit e vários plugins (você pode ver meus dotfiles aqui), a shell em si não importa, você pode usar bash, sh, Fish, ou o que for, o importante é que você tenha ela totalmente configurada para evitar problemas com variáveis de ambiente.

3 - Instale o Neovim

Você pode instalar o Neovim seguindo diretamente as instruções do site oficial, no geral, para Mac você já deve ter ele instalado por padrão, caso contrário é só usar o Homebrew com brew install neovim.

No caso do Arch eu usei o YaY com yay -S neovim, provavelmente sua distribuição tem alguma coisa do mesmo tipo.

Depois de instalado, quando você executar o neovim pela primeira vez digitando nvim, sem nenhuma configuração, ele vai parecer com isso aqui:

É possível sim sair do Neovim apertando esc e depois :q!<enter>

4 - NerdFonts

Uma parte importantíssima desse setup são as NerdFonts. Uma NerdFont é uma fonte comum, porém empacotada com todos os ícones e glifos imaginados. Basicamente é como se sua fonte Arial tivesse um monte de desenhos junto, incluindo ícones do Font Awesome e um monte de outros glifos transformados em fontes que a gente vê por ai.

Você pode instalar a fonte que você preferir, mas uma fonte obrigatória é a MesloLG. Você pode instalar essas fontes de várias formas, a mais simples é ir até a página de downloads achar a fonte e incluir na sua biblioteca de fontes.

Outra forma que eu prefiro é instalar usando o seu gerenciador de pacotes, no caso do brew você pode procurar por fontes usando brew search font-<nome> e baixar a que estiver com o nome nerd-font no final, por exemplo:

$ brew install --cask font-meslo-lg-nerd-font

No caso do Arch é a mesma coisa só que com o yay:

$ yay -S ttf-meslo-nerd

Se você quiser instalar outras fontes, eu também recomendo a CaskaydiaCove Nerd Font (minha atual fonte), Fira Code Nerd Font, e a Hack que são fontes bem interessantes e fáceis de ver.

5 - Lazygit

Instale o LazyGit, que é um cliente de git direto pelo terminal. Você pode instalar ele diretamente pelo brew com o brew install lazygit ou yay lazygit no caso do Arch.

Lazy e LazyVim

Eu não vou entrar em detalhes das bases do Vim, ou do Neovim, mas eu quero ir direto ao ponto e mostrar como você pode começar o mais rápido possível de um jeito bem simples com ele.

Existe um projeto de um plugin manager chamado lazy.nvim.

A ideia de um gerenciador de plugins, assim como um gerenciador de pacotes tipo NPM, RubyGems ou qualquer outra coisa é literalmente tornar fácil o carregamento de funcionalidades externas através de plugins no Neovim, pense nele como se fossem as extensões do VSCode.

Pois bem, o mesmo criador do lazy.nvim deu um passo a mais e criou um "kit iniciante" para quem quer começar com neovim já com vários bons setups iniciais, uma série de plugins e uma série de configurações prontas. E esse é o LazyVim

O LazyVim é extremamente parecido com o VSCode, o que torna todo o processo bem simples e fácil de transitar, além de ter uma série de comandos que já estão prontos e uma busca de keybindings pra você não se perder. Fora que ele também suporta mouse, então caso você queira clicar em alguma coisa é bem simples.

Instalando

A instalação do LazyVim é bem direta, primeiro você faz um backup das suas configurações:

mv ~/.config/nvim{,.bak}
mv ~/.local/share/nvim{,.bak}
mv ~/.local/state/nvim{,.bak}
mv ~/.cache/nvim{,.bak}

Lembrando que nem todas as pastas vão existir, ainda mais se você criou a instalação do Neovim agora.

Por padrão todas as configurações vão ficar salvas em $HOME/.config/nvim mas o LazyVim vai ser instalado em $HOME/.local/share/nvim/lazy, incluindo todas as configurações e plugins que ele já tem. Lembrando que você NÃO deve mexer nesse diretório.

Depois é só clonar o repositório com o Git:

git clone https://github.com/LazyVim/starter ~/.config/nvim

E ai remover a pasta .git de dentro desse repositório pra que você possa modificar sem ter o histórico.

Agora é rodar o comando nvim, você já deve ver algumas mudanças na sua configuração e deve estar vendo a tela padrão do Lazy

Digite :LazyHealth e aperte enter, para garantir que tudo está rodando legal.

A tecla <leader>

O Lazy, assim como muitos outros, tem uma tecla base para as demais combinações, essa tecla é a <leader> que é mapeada para a barra de espaço por padrão, aperte <leader> e você vai ver um guia de keybindings aparecendo na parte de baixo da tela, esse é um plugin chamado WhichKey (que também foi criado pelo Folke, o criador do Lazy):

Basta apertar a próxima tecla da sequência para executar a ação ou para ir para a próxima página (no caso das bindings que tem um + na frente, como +g que abre o git), tente <leader>l, e veja a tela "home" do Lazy se abrir:

Você pode navegar por essa janela usando as letras no cabeçalho, por exemplo I mostra todos os plugins instalados, U vai atualizar todos eles, S vai sincronizar com o repositório e assim vai.

Lembre-se que U e u são diferentes na perspectiva do Vim. Então se você ver uma sequência como <leader>bD, digite exatamente como é: <espaço>b<shift>d

Aperte q para sair do painel. Agora chegou o momento de fazer um tour pelas funcionalidades básicas

Tour básico

Vamos começar com as funcionalidades mais simples e mais úteis.

Explorer (Neotree)

O Lazy vem com um plugin chamado neotree, que é um plugin para mostrar uma barra de navegação de arquivos como o explorer do VSCode. Você pode acessar essa funcionalidade com <leader>e.

Você não precisa esperar até o WhichKey aparecer, é só apertar o mais rápido que conseguir, lembre-se que é a velocidade aqui.

Você pode navegar por ela com HJKL, J e K vão descer e subir, H e L navegam para dentro e fora de pastas. Para abrir um arquivo aperte Enter, aqui estão alguns atalhos úteis:

• a: Cria um novo arquivo
• r: Renomear o arquivo
• d: Deleta o arquivo
• C: Fecha a pasta atual e sobe um nível
• /: Inicia a busca
• ?: Mostra a lista de atalhos

Movimentação

Abra o vim na pasta ~/.config/nvim, vamos começar dali. Selecione o arquivo lua/config/lazy.lua. Esse é o principal arquivo de configuração do lazy, mas a gente quase nunca vai mexer nele.

Aperte <C-l> ou <Ctrl>+l para voltar ao Neotree, agora abra o arquivo options.lua, veja que temos duas abas no topo, esses são os buffers, cada buffer é um arquivo em memória, e é importante dizer que não são abas!

No Vim o conceito de abas e buffers é diferente, abas são como se fossem espaços completamente separados que podem ter uma configuração de janelas completamente a parte, buffers são os arquivos abertos dentro de uma aba e eles podem ser reorganizados em janelas nessa aba. Na maioria das vezes você só vai ter uma aba aberta.

Para se mover entre um arquivo e outro use L e H , ou gn e gp. Você também pode tirar proveito de um outro plugin, o Telescope.

Feche esse buffer com <leader>bd.

Telescope

O Telescope é outro plugin feito para buscar arquivos. Vamos abrir outro arquivo com ele, aperte <leader>ff para abrir a janela do Telescope:

Aqui você pode digitar direto para buscar o arquivo, navegar com as setas ou com <C-n> e <C-p>, você também pode abrir a lista de atalhos com <C-?>. Abra outro arquivo com ele.

Você também pode acessar o telescope para arquivos com <leader><leader>

Existem infinitas opções do Telescope. Por exemplo, você pode buscar dentre todos os arquivos abertos (buffers) com <leader>fb, na verdade, a maioria das coisas que você pode fazer com o Telescope vai estar dentro de <leader>f, ou então de <leader>s, que são os comandos de busca globais.

Configuração

Agora que a gente sabe o básico, vamos começar a configurar o nosso editor. O Lazy vai inicialmente ler todos os arquivos dentro da pasta lua/config como configurações iniciais, começando com o lazy.lua, depois ele vai ler todos os plugins dentro da pasta plugins.

Então para poder adicionar novas funcionalidades a gente só precisa mudar esses arquivos:

• lua/config/options.lua: Opções gerais e configurações do tipo on/off
• lua/config/keymaps.lua: Mapeamento de teclas, aqui que vamos modificar os atalhos
• lua/config/autocmds.lua: Se você tiver algum auto command do vim, aqui é o lugar de colocar
• lua/plugins: Qualquer arquivo lua aqui dentro será lido e adicionado nos plugins, então você pode separar por categoria (ui, search, code, etc) ou pelo nome do plugin, que é o que eu fiz.

Lazy.lua

Vamos começar pelo arquivo que a gente tem que modificar menos, o arquivo lazy.lua, aqui vamos habilitar somente o que são chamados de LazyExtras, configurações de fábrica que o Lazy já traz prontas e permite que você estenda ou modifique depois na pasta plugins.

Vamos focar nessa seção apenas, descomente as três linhas que estão acima de { import = "plugins" }, a primeira vai habilitar o suporte nativo a TypeScript (que vamos configurar depois nos LSPs), a formatação com Prettier e a extensão para JSON.

Além disso, já vamos adicionar um tema, eu estou usando o tema catpuccin modificado, mas não vamos instalar ele agora.

Lembrando que você pode instalar qualquer tema que você quiser e o próprio Lazy já tem alguns pré instalados que você pode testar com <leader>uC

Outro detalhe é que, depois de algumas atualizações do Lazy, a integração do TypeScript acabou começando a usar um outro LSP (vamos falar dele já já) então eu acabei desabilitando essa configuração.

options.lua

O arquivo options é o arquivo que vai ter as opções principais, como tamanho dos espaços, colunas e etc, geralmente é um arquivo bem pequeno e bem pessoal, no meu caso eu coloquei apenas as configurações mais simples:

-- Options are automatically loaded before lazy.nvim startup
-- Default options that are always set: https://github.com/LazyVim/LazyVim/blob/main/lua/lazyvim/config/options.lua
-- Add any additional options here
--
-- -- Enable the option to require a Prettier config file
-- If no prettier config file is found, the formatter will not be used
vim.g.lazyvim_prettier_needs_config = true
-- Auto wrap
vim.opt.wrap = true
-- Attempt to fix indent
vim.opt.tabstop = 4
vim.opt.shiftwidth = 4
vim.opt.expandtab = true
vim.opt.autoindent = true
vim.opt.smarttab = true

-- Highlights for cursor column
vim.cmd.set("cursorcolumn")
vim.cmd("highlight CursorColumn ctermbg=Blue")
vim.cmd("highlight CursorColumn ctermfg=Black")

-- Vim does not recognize the alt key in Mac
-- https://stackoverflow.com/questions/7501092/can-i-map-alt-key-in-vim
-- So we have to use the response from stty -icanon; cat (press alt + key)
-- to get the correct key code, then we can map it to something else
-- NOTE: ^[ is the escape character \e in vim
vim.cmd("set <M-BS>=\\e?") -- in this example alt+backspace is ESC+? which is mapped to <M-BS>

De cima para baixo, as configurações são as seguintes:

• Desabilita o prettier se não houver um arquivo de configuração .prettierrc na pasta, porque eu não gosto de habilitar o prettier globalmente (na verdade eu não gosto de habilitar nada globalmente)
• Ativo o Auto Wrap, para poder quebrar as linhas automaticamente quando chegam no fim da tela
• As próximas opções desde tabstop até smarttab são relacionadas à configuraçòes de tabs e espaços, aqui eu estou definindo que cada tab será 4 espaços e, por padrão, os projetos vão usar 4 espaços de indentação. Isso não é algo que eu gosto muito, mas infelizmente a maioria dos projetos que estou usando ultimamente estão usando essa configuração.
• Seto uma linha mais clara onde meu cursor estiver, tanto na horizontal quanto na vertical, isso ajuda a achar mais facilmente ele na tela
• A última opção é uma alteração para que o Vim reconheça a tecla Alt no Mac, que é mapeada para o command, veja o link no comentário para entender melhor como funciona

autocmds.lua

Outra coisa interessantíssima do vim é que é possível executar comandos automaticamente de acordo com hooks de execução, por exemplo, sempre que entrar em um buffer que tenha um determinado nome, ou sempre que sair de algum buffer, e assim vai.

Eu tenho algumas funções específicas para arquivos markdown - que eu acabo usando bastante - como: setar o tipo do arquivo para markdown, definir uma linha a 80 chars para limitar o texto, etc

-- Autocmds are automatically loaded on the VeryLazy event
-- Default autocmds that are always set: <https://github.com/LazyVim/LazyVim/blob/main/lua/lazyvim/config/autocmds.lua>
-- Add any additional autocmds here
local function augroup(name)
  return vim.api.nvim_create_augroup("custom_" .. name, { clear = true })
end

-- auto set markdown filetype
vim.api.nvim_create_autocmd({ "BufNewFile", "BufFilePre", "BufRead" }, {
  pattern = { "*.md" },
  callback = function()
    vim.cmd("set filetype=markdown")
  end,
})

-- Auto set markdown to break at 80 chars and highlight the 80th column
vim.api.nvim_create_autocmd({ "BufWinEnter" }, {
  pattern = { "*.md" },
  callback = function()
    vim.opt.colorcolumn = "80"
    vim.opt.textwidth = 80
  end,
})

-- On leaving markdown files, reset the colorcolumn and textwidth
vim.api.nvim_create_autocmd({ "BufWinLeave" }, {
  pattern = { "*.md" },
  callback = function()
    vim.opt.colorcolumn = "120"
    -- disabled textwidth
    vim.opt.textwidth = 0
  end,
})

-- auto set i3config filetype
vim.api.nvim_create_autocmd({ "BufNewFile", "BufFilePre", "BufRead" }, {
  pattern = { "*.i3config" },
  callback = function()
    vim.cmd("set filetype=i3config")
  end,
})

Esse arquivo não é obrigatório, e muitas vezes vai estar vazio, a não ser que você tenha algum tipo de comando que queira sempre rodar de acordo com algum tipo de buffer, por exemplo, sempre executar um ESLint quando tiver em um arquivo JS ou algo assim.

keymaps.lua

O último dos arquivos na pasta config é o arquivo keymaps.lua, como você deve imaginar, ele tem os atalhos de teclado que você quer customizar. Nesse ponto eu vou colocar o meu arquivo inteiro aqui, que é bastante grande, mas você não precisa seguir exatamente o que existe aqui, fique a vontade para poder adicionar os que você quiser.

Vou tentar deixar comentários onde for pertinente

-- Keym automatically loaded on the VeryLazy event
-- Default keymaps that are always set: https://github.com/LazyVim/LazyVim/blob/main/lua/lazyvim/config/keymaps.lua
-- Add any additional keymaps here

-- Habilita voltar onde paramos em qualquer busca do telescope
vim.keymap.set(
  "n",
  "<leader>sx",
  require("telescope.builtin").resume,
  { noremap = true, silent = true, desc = "Resume telescope search" }
)

-- Move blocos de texto no Linux
vim.keymap.set("v", "<A-j>", "<cmd>m '>+1<cr>gv=gv", { noremap = true, silent = true, desc = "Move line down" })
vim.keymap.set("v", "<A-k>", "<cmd>m '<-2<cr>gv=gv", { noremap = true, silent = true, desc = "Move line up" })
vim.keymap.set("n", "<A-j>", ":m '.+1<CR>==", { noremap = true, silent = true, desc = "Move line down" })
vim.keymap.set("n", "<A-k>", ":m '.-2<CR>==", { noremap = true, silent = true, desc = "Move line up" })

-- Move blocos de texto (mac)
-- https://stackoverflow.com/questions/7501092/can-i-map-alt-key-in-vim)
vim.keymap.set("v", "˚", ":m '<-2<CR>gv=gv", { noremap = true, silent = true, desc = "Move line up" })
vim.keymap.set("v", "∆", ":m '>+1<CR>gv=gv", { noremap = true, silent = true, desc = "Move line down" })
vim.keymap.set("n", "∆", ":m '.+1<CR>==", { noremap = true, silent = true, desc = "Move line down" })
vim.keymap.set("n", "˚", ":m '.-2<CR>==", { noremap = true, silent = true, desc = "Move line up" })

-- Muda de janelas em modo de edição usando tabs
vim.keymap.set("n", "<F8>", "gt", { noremap = true, silent = true, desc = "Switch to next tab" })
vim.keymap.set("n", "<F7>", "gT", { noremap = true, silent = true, desc = "Switch to previous tab" })

-- duplica a linha atual para baixo
vim.keymap.set("n", "<C-S-d>", "yyp", { noremap = true, silent = true, desc = "Duplicate line down" })

-- Comandos relativos a navegação em buffers

-- Próximo buffer da lista
vim.keymap.set("n", "gn", "<cmd>bn<cr>", { noremap = true, silent = true, desc = "Next buffer" })
vim.keymap.set("n", "<tab><tab>", "<cmd>bn<cr>", { noremap = true, silent = true, desc = "Next buffer" })
vim.keymap.set("n", "<tab>n", "<cmd>bn<cr>", { noremap = true, silent = true, desc = "Next buffer" })

-- Buffer anterior
vim.keymap.set("n", "<S-tab>", "<cmd>bp<cr>", { noremap = true, silent = true, desc = "Previous buffer" })
vim.keymap.set("n", "gp", "<cmd>bN<cr>", { noremap = true, silent = true, desc = "Previous buffer" })
vim.keymap.set("n", "<tab>p", "<cmd>bp<cr>", { noremap = true, silent = true, desc = "Previous buffer" })

-- deletar/fechar buffer
vim.keymap.set("n", "<tab>d", "<cmd>bd<cr>", { noremap = true, silent = true, desc = "Delete buffer" })
vim.keymap.set("n", "<tab>q", "<cmd>bd<cr>", { noremap = true, silent = true, desc = "Delete buffer" })
vim.keymap.set("n", "<tab>w", "<cmd>bd<cr>", { noremap = true, silent = true, desc = "Delete buffer" })

-- busca no telescope para buffers
vim.keymap.set("n", "<tab>f", "<cmd>Telescope buffers<cr>", { noremap = true, silent = true, desc = "Find buffer" })

-- Deleta a palavra atual com Alt+BS
-- mac (see options.lua)
vim.keymap.set("n", "<M-BS>", "hdiw", { noremap = true, silent = true, desc = "Delete word" })
-- linux
vim.keymap.set("n", "<A-BS>", "hdiw", { noremap = true, silent = true, desc = "Delete word" })

-- cmd P para encontrar arquivos
vim.keymap.set("n", "<C-p>", "<cmd>Telescope find_files<cr>", { noremap = true, silent = true, desc = "Find files" })

-- cria um terminal novo
local wk = require("which-key")
wk.add({
  { "<leader>t", group = "Terminals" },
  {
    "<leader>tt",
    function()
      TermNumber = (TermNumber or 0) + 1
      local term = require("toggleterm")
      term.toggle(TermNumber)
    end,
    desc = "New toggle terminal",
  },
  { "<leader>ts", "<cmd>:TermSelect<cr>", desc = "Find open terminals" },
  { "<leader>tf", "<cmd>:TermSelect<cr>", desc = "Find open terminals" },
  { "<leader>tr", "<cmd>exe v:count1 . 'ToggleTermSetName'<cr>", desc = "Rename open terminals" },
  {
    "<leader>th",
    "<cmd>exe v:count1 . 'ToggleTerm'<cr>",
    desc = "Toggle docked terminal (prefix number before command)",
  },
  { "<C-.>", "<cmd>:ToggleTerm<cr>", group = "Terminals", desc = "Toggle docked terminal", mode = { "n", "t" } },
})

-- controle de banco de dados com o plugin DadBod
wk.add({
  { "<leader>D", group = "Database" },
  { "<leader>DD", "<cmd>DBUI<cr>", desc = "Toggle DBUI" },
  { "<leader>Dx", "<cmd>call <SNR>79_method('execute_query')<cr>", desc = "Run Query" },
})

-- deleta uma marca do vim usando delmark
wk.add({
  { "<leader>dm", "<cmd>exe 'delmark ' . nr2char(getchar())<cr>", desc = "Delete a mark <markname>" },
})

-- Move uma linha para baixo sem entrar em modo de edição 
wk.add({
  { "<leader>o", "o<esc>", desc = "New line below in normal mode" },
  { "<leader>O", "O<esc>", desc = "New line above in normal mode" },
})

-- Fecha todos os buffers
wk.add({
  { "<leader>bD", "<cmd>BufferLineCloseOthers<cr><cmd>bd<cr>", desc = "Close all buffers" },
})

A estrutura básica é vim.keymap.set("modo", "atalho", "comando"), seguido das opções para descrição do comando, se deve ou não remapear e etc. Mais abaixo você tem um wk.add que é o WhichKey, isso permite a gente adicionar os atalhos que aparecem na barra de atalhos do WhichKey quando você aperta <leader> (espaço no meu caso), por exemplo, eu tenho um atalho que é <leader>bD para fechar todos os buffers, se eu apertar <leader>b você vai ver que esse atalho aparece na lista também:

Plugins

Agora que acabamos todas as partes de configuração, podemos começar a falar de plugins, o grande poder do Neovim com o Lazy.

Todos os plugins são carregados usando o lazy.nvim que é, como você deve imaginar, do mesmo criador do LazyVim. A ideia do lazy.nvim é que ele tem um diretório chamado plugins na pasta lua, dentro dele você pode criar qualquer arquivo .lua que retorne um dicionário (ou table) nesse modelo:

return {
  "nome/do/plugin",
  event = "evento para carregar se possível",
  keys = {
    {
      "atalho", 
      "comando",
      desc = "descrição do atalho"
    }
  },
  config = function() 
    -- alguma coisa aqui
  end
}

O nome do plugin pode ser um repositório do GitHub, por exemplo, "b0o/incline.nvim", ou então uma URL completa de um repositório Git (é importante que seja um Git porque o lazy vai baixar todos os seus plugins usando Git).

Você pode ou não definir um evento onde esse plugin é carregado, por exemplo, um plugin para markdown não faz sentido ser carregado em um arquivo JS e assim vai, mas não é obrigatório. Se omitido vai ser carregado sempre na inicialização.

Também, opcionalmente, você pode definir os atalhos relacionados àquele plugin direto na configuração dele usando a chave keys, a estrutura é a mesma do keymaps.lua.

No final temos a parte mais importante que são as opções e configurações do plugin, essa parte pode ser uma função que deve retornar uma table. No geral, alguns plugins vão pedir que seja uma função que chame o método setup do plugin, mas se for omitida o lazy vai chamar o método setup sem nenhum parâmetro.

Outra opção que você pode passar também, ao invés de config, uma propriedade opts que será uma table, ou uma função que retorna uma table, e essa table de opções será passada para o método setup do plugin. Vamos a dois exemplos, o primeiro é com a propriedade config:

return {
  "iamcco/markdown-preview.nvim",
  cmd = { "MarkdownPreviewToggle", "MarkdownPreview", "MarkdownPreviewStop" },
  ft = { "markdown" },
  build = "cd ~/.local/share/nvim/lazy/markdown-preview.nvim/app && npm i",
  lazy = true,
  config = function()
    vim.g.mkdp_browser = "vivaldi-stable"
  end,
}

Veja que eu não tenho uma propriedade opts, mas estou usando a config para poder setar automaticamente a opção global de qual browser o markdown preview vai usar. Eu poderia ter setado isso no options.lua, mas como isso é relativo diretamente a esse plugin e sem ele essa configuração não faz sentido, eu preferi setar por aqui mesmo.

Outro exemplo é a configuração do meu Telescope:

return {
  "nvim-telescope/telescope.nvim",
  opts = {
    defaults = {
      path_display = { shorten = {
        len = 5,
        exclude = { 2, -1 },
      } },
    },
  },
}

Estou passando as opções como uma table que está dizendo para o telescope reduzir o tamanho do caminho para 5 letras e excluir tanto a segunda parte do caminho quanto a última parte dele, isso faz com que as buscas fiquem assim:

O que é ótimo para telas pequenas, já que eu não preciso saber o nome completo do local, apenas as primeiras letras.

Meus plugins

Eu não vou listar todos os meus plugins aqui, porque seriam muitos, mas vou deixar os meus dotfiles diretamente na pasta do meu Lazy para que você possa ver o que está acontecendo, eu optei por deixar os plugins divididos por tipo e por função, e não por grupo como parece ser o jeito que a comunidade gosta de fazer. Eu acho muito mais fácil dar manutenção quando eu sei o que o plugin faz ao invés de ter um arquivo com vários plugins dentro agrupado por funcionalidade.

dotfiles/general/nvim/.config/nvim at ba88235f73d88a5a3e0db981e2efbc433c5fee4c · khaosdoctor/dotfiles

My dotFiles. Contribute to khaosdoctor/dotfiles development by creating an account on GitHub.

GitHubkhaosdoctor

Para que a gente possa ter a funcionalidade que eu prometi, deixando o seu nvim igual o meu (pelo menos na aparência), vamos precisar de alguns plugins, o primeiro deles é o meu esquema de cores.

Catpuccin e colorschemes

No geral, instalar temas para o Nvim é bem simples e você pode trocar de temas no LazyVim usando <leader>UC. Para instalar um colorscheme, é como se fossemos instalar um plugin comum, mas no final do arquivo temos que setar uma propriedade que diz ao LazyVim qual é o plugin que vamos escolher como o colorscheme principal. Eu tenho alguns temas instalados:

return {
  { "Mofiqul/dracula.nvim" },
  {
    "catppuccin/nvim",
    opts = {
      flavour = "macchiato",
      highlight_overrides = {
        all = function(colors)
          return {
            CurSearch = { bg = colors.sky },
            IncSearch = { bg = colors.sky },
            CursorLineNr = { fg = colors.blue, style = { "bold" } },
            DashboardFooter = { fg = colors.overlay0 },
            TreesitterContextBottom = { style = {} },
            WinSeparator = { fg = colors.overlay0, style = { "bold" } },
            ["@markup.italic"] = { fg = colors.blue, style = { "italic" } },
            ["@markup.strong"] = { fg = colors.blue, style = { "bold" } },
            Headline = { style = { "bold" } },
            Headline1 = { fg = colors.blue, style = { "bold" } },
            Headline2 = { fg = colors.pink, style = { "bold" } },
            Headline3 = { fg = colors.lavender, style = { "bold" } },
            Headline4 = { fg = colors.green, style = { "bold" } },
            Headline5 = { fg = colors.peach, style = { "bold" } },
            Headline6 = { fg = colors.flamingo, style = { "bold" } },
            rainbow1 = { fg = colors.blue, style = { "bold" } },
            rainbow2 = { fg = colors.pink, style = { "bold" } },
            rainbow3 = { fg = colors.lavender, style = { "bold" } },
            rainbow4 = { fg = colors.green, style = { "bold" } },
            rainbow5 = { fg = colors.peach, style = { "bold" } },
            rainbow6 = { fg = colors.flamingo, style = { "bold" } },
          }
        end,
      },
      color_overrides = {
        macchiato = {
          rosewater = "#F5B8AB",
          flamingo = "#F29D9D",
          pink = "#AD6FF7",
          mauve = "#FF8F40",
          red = "#E66767",
          maroon = "#EB788B",
          peach = "#FAB770",
          yellow = "#FACA64",
          green = "#70CF67",
          teal = "#4CD4BD",
          sky = "#61BDFF",
          sapphire = "#4BA8FA",
          blue = "#00BFFF",
          lavender = "#00BBCC",
          text = "#ffffff",
          subtext1 = "#A3AAC2",
          subtext0 = "#8E94AB",
          overlay2 = "#7D8296",
          overlay1 = "#676B80",
          -- overlay0 = "#464957", -- comments
          overlay0 = "#757a92",
          surface2 = "#3A3D4A",
          -- surface1 = "#2F313D", -- line numbers, hovers, highlights
          surface1 = "#46495b",
          surface0 = "#1D1E29",
          base = "#030303",
          mantle = "#11111a",
          crust = "#191926",
        },
      },
      integrations = {
        telescope = {
          enabled = true,
          style = "nvchad",
        },
      },
    },
    name = "catppuccin",
    priority = 1000,
  },
  { "eldritch-theme/eldritch.nvim", lazy = false, priority = 1000, opts = {} },
  {
    "maxmx03/fluoromachine.nvim",
    lazy = false,
    priority = 1000,
    opts = { glow = false, theme = "fluoromachine", transparent = false },
  },
  {
    "shatur/neovim-ayu",
    lazy = false,
    priority = 1000,
    config = function()
      require("ayu").setup({
        mirage = true,
        terminal = true,
      })
    end,
  },
  {
    "LazyVim/LazyVim",
    opts = {
      colorscheme = "catppuccin",
    },
  },
}

Como você pode ver, eu sou um grande fã de temas escuros, bem escuros. Para mim, o ideal são temas que tem um alto contraste entre o fundo e a fonte. Um exemplo, muita gente usa o tema Dracula (do nosso conterrâneo Zeno Rocha) porque é um ótimo tema, mas para mim, o Dracula original não me agradava por causa da escolha de fundo. Eu sempre usei o Dracula, porém eu sempre modificava a cor do fundo do editor para que ela fosse quase preta (#131313 para ser mais exato).

No Lazy eu descobri um outro tema que chegava mais perto do que eu gostava, o Catppuccin, uma das grandes vantagens desse tema para mim é que ele tem as cores muito parecidas com as do Dracula, que eu acho muito legais, porém ele também é mais escuro, mas ainda sim eu deixei ele AINDA MAIS ESCURO

No caso do Catppuccin, você pode alterar as cores de cada parte do tema usando color_overrides, além disso você também pode setar o "flavour" ou o "sabor" do tema, eu gosto mais do "macchiato" que é o mais escuro, além de que você pode trocar qual cor vai em que e como ela é definida. Eu fortemente recomendo esse tema.

Acima de tudo é sua escolha, então não é algo que você precise pensar demais, recomendo que você instale a vários temas e teste cada um deles para ver qual você gosta mais! O importante é que, no final de tudo você tenha essa chamada:

  {
    "LazyVim/LazyVim",
    opts = {
      colorscheme = "seu tema",
    },
  }

Dashboard

Para ter o dashboard customizado com um logo diferente, e até mesmo opções diferentes, o Lazy usa um projeto chamado Alpha.nvim, que é um gerador de dashboards, essencialmente o que eu fiz foi copiar a configuração original do do LazyVim que está nesse repositório:

LazyVim/lua/lazyvim/plugins/extras/ui/alpha.lua at main · LazyVim/LazyVim

Neovim config for the lazy. Contribute to LazyVim/LazyVim development by creating an account on GitHub.

GitHubLazyVim

E modificar o logo. Todo o resto eu deixei igual porque eu acho que as opções são bem pertinentes e me ajudam bastante, para gerar o logo eu procurei um gerador de ASCII art, este aqui foi exatamente o que eu usei. Ele tem várias opções de fontes e letras e ai é uma questão de você ser criativo. Para substituir o logo basta remover o logo do Lazy e colar o seu próprio logo, lembrando que seu terminal deve suportar os caracteres ANSI se você escolheu essa fonte:

LuaLine

O Lualine é um plugin muito legal que adiciona várias coisas interessantes na parte de baixo do seu editor, como o branch do git, a pasta que você está, número de erros e avisos, caminho, último comando, e outras coisas. Além disso é totalmente customizável e você pode adicionar o que você quiser nela. No meu caso essa é a configuração:

Para não adicionar um arquivo super longo por aqui, vou deixar o link para o repositório na revisão atual:

dotfiles/general/nvim/.config/nvim/lua/plugins/lualine.lua at 4532db19eca517ccc6205fa22826aa8854d88d20 · khaosdoctor/dotfiles

My dotFiles. Contribute to khaosdoctor/dotfiles development by creating an account on GitHub.

GitHubkhaosdoctor

Conclusão

Foi um artigo longo mas agora você consegue instalar e configurar o seu Neovim para começar a usar o poder que ele tem. Estamos longe de estar prontos e de acabar toda essa configuração, mas o importante é que você sinta que esse editor é o seu editor e você se sinta em casa com ele.

Eu ainda quero mostrar muito mais coisas por aqui relacionadas ao Neovim e como eu pessoalmente uso esse editor, além de mostrar tudo que eu aprendi ao longo do tempo (e continuo aprendendo) usando Vim, mas isso vai ficar para uma outra hora!

Se você curtiu esse artigo me dá um oi lá nas minhas redes sociais e me fala o que você quer ver mais aqui no blog!