Não seria possível eliminar a contagem de referências quando for possível calcular, em tempo de compilação, os momentos de alocação e liberação de memória? Parece que o autor do comentário original no Hacker News não está entendendo o problema da reutilização de memória.
Como foi defendido neste texto, a capacidade de "documentar" é realmente muito importante.
Ela não serve apenas para destacar os próprios pontos fortes e comprovar resultados, mas também ajuda a facilitar o trabalho e a orientar outras pessoas.
Não é necessário criar materiais ou documentos incríveis desde o começo. O importante é adquirir o hábito de organizar as informações e documentá-las, mesmo que de forma simples.
Eu também sei disso na teoria, mas não consigo colocar muito em prática... é realmente um tema difícil.
Não conheço até as bases mais profundas, mas já vi que, quando a pessoa não conhece o básico, ela produz resultados realmente absurdos e difíceis até de imaginar.
Por exemplo, implementar a busca carregando todos os registros do DB na memória e depois pesquisando na memória.
Quando há poucos registros, funciona bem, mas, quando o número de registros aumenta, a memória estoura.
Ela programa assim porque não entende nem um pouco a diferença entre memória e DB.
Esse é só um exemplo, e toda vez implementa de um jeito que ninguém conseguiria imaginar.
Um programador comum(?) realmente não consegue imaginar isso.
Eu também concordo com este texto.
Acredito que definir problemas com valores de estado abstraídos é útil para descobrir problemas, e estou tentando criar ferramentas de gerenciamento de estado visual, explícitas e claras, como visualização de estado com diagramas, Unreal Blueprint ou workflow.
Acho que vou precisar olhar primeiro para a linguagem.
De qualquer forma, o trabalho prático de engenharia de software vai mudar bastante. As máquinas de código vão perder competitividade, mas eu aposto que os engenheiros que realmente conseguem criar produtos end-to-end vão sobreviver.
Enquanto trabalhava com desenvolvimento, houve um período em que atuei com planejamento por alguns anos, e a mensagem do texto sobre a necessidade de "vender (Sell)" realmente me marcou.
Por mais que um produto tenha sido preparado e planejado com muito empenho, se você não conseguir persuadir e vendê-lo de forma eficaz aos colegas ao redor, não conseguirá obter apoio
e, no fim, a iniciativa não conseguirá avançar sem problemas.
Aprendi a lição de que, se você tem uma ideia, também é essencial agir para comunicá-la de forma eficaz às pessoas ao seu redor e conquistar apoio.
Não seria possível eliminar a contagem de referências quando for possível calcular, em tempo de compilação, os momentos de alocação e liberação de memória? Parece que o autor do comentário original no Hacker News não está entendendo o problema da reutilização de memória.
Agora que a IA generativa já consegue escrever código, fico me perguntando se o coletor de lixo ainda é realmente necessário
> Bastante sugestivo...
Ah, puxa, isso eu vou corrigir mais tarde.
Então o
<selectlist>vai deixar de ser necessário?Show GN: jogo web de batalha/ranking de configuração de personagens
Falando de outra coisa, parece que o
<select>do título não é exibido no Slackbot hahaOntem, quando vi, não tinha percebido, mas é da Microsoft mesmo, haha. Vou testar.
Pelo visto, os blogueiros que ficavam monitorando novos commits para prever recursos novos vão ficar desapontados.
Concordo..!
Como foi defendido neste texto, a capacidade de "documentar" é realmente muito importante.
Ela não serve apenas para destacar os próprios pontos fortes e comprovar resultados, mas também ajuda a facilitar o trabalho e a orientar outras pessoas.
Não é necessário criar materiais ou documentos incríveis desde o começo. O importante é adquirir o hábito de organizar as informações e documentá-las, mesmo que de forma simples.
Eu também sei disso na teoria, mas não consigo colocar muito em prática... é realmente um tema difícil.
Não conheço até as bases mais profundas, mas já vi que, quando a pessoa não conhece o básico, ela produz resultados realmente absurdos e difíceis até de imaginar.
Por exemplo, implementar a busca carregando todos os registros do DB na memória e depois pesquisando na memória.
Quando há poucos registros, funciona bem, mas, quando o número de registros aumenta, a memória estoura.
Ela programa assim porque não entende nem um pouco a diferença entre memória e DB.
Esse é só um exemplo, e toda vez implementa de um jeito que ninguém conseguiria imaginar.
Um programador comum(?) realmente não consegue imaginar isso.
https://pt.news.hada.io/topic?id=4138
Também tem um tal de Coolify.
Eu também concordo com este texto.
Acredito que definir problemas com valores de estado abstraídos é útil para descobrir problemas, e estou tentando criar ferramentas de gerenciamento de estado visual, explícitas e claras, como visualização de estado com diagramas, Unreal Blueprint ou workflow.
Acho que vou precisar olhar primeiro para a linguagem.
Este texto me lembra uma aula da graduação em teoria da computação! Recomendo que quem programa estude isso.
Muito bom, né? Até esse tipo de coisa existe como open source haha
Pior é melhor!
De qualquer forma, o trabalho prático de engenharia de software vai mudar bastante. As máquinas de código vão perder competitividade, mas eu aposto que os engenheiros que realmente conseguem criar produtos end-to-end vão sobreviver.
Eu também acho que o function calling do OpenAPI talvez seja melhor. Até refazer isso com o protocolo MCP já dá trabalho.
Enquanto trabalhava com desenvolvimento, houve um período em que atuei com planejamento por alguns anos, e a mensagem do texto sobre a necessidade de "vender (Sell)" realmente me marcou.
Por mais que um produto tenha sido preparado e planejado com muito empenho, se você não conseguir persuadir e vendê-lo de forma eficaz aos colegas ao redor, não conseguirá obter apoio
e, no fim, a iniciativa não conseguirá avançar sem problemas.
Aprendi a lição de que, se você tem uma ideia, também é essencial agir para comunicá-la de forma eficaz às pessoas ao seu redor e conquistar apoio.
É um pouco decepcionante que, numa era em que até o Docker Desktop usa Kubernetes, ele suporte apenas Docker Swarm.