nicewook 2025-02-26 | comentário pai | em: Clean Code vs. Filosofia de Design de Software (github.com/johnousterhout)

Concordo um pouco mais com o John.
Acho que o ponto principal é que, em vez de seguir cegamente o que os dois dizem como se fosse um dogma, devemos entender por que eles dizem isso e seguir em frente a partir daí.

 

A reutilização da resolução de conflitos é ótima.

 
ilikeall 2025-02-26 | comentário pai | em: Clean Code vs. Filosofia de Design de Software (github.com/johnousterhout)

No fim das contas, moderação é essencial mesmo.

 

Quando vou ver diff, uso o git-delta para visualizar no formato TUI.

  10   │ [core]  
  11   │     pager = delta  
  12   │ [interactive]  
  13   │     diffFilter = delta --color-only  
  14   │ [delta]  
  15   │     line-numbers = true  
  16   │     side-by-side = true  
  17   │     navigate = true  
  18   │     diff-so-fancy = true  
  19   │     hyperlinks = true  

Se não quiser esquentar muito a cabeça, dá para usar o tig... hahaha
Será que existe algo melhor...?

 
elddytbt 2025-02-26 | comentário pai | em: Clean Code vs. Filosofia de Design de Software (github.com/johnousterhout)

Muito útil 👍🏻

 

Mesmo assim, dá vontade de tentar.

 

Por mais que eu olhe, parece que estão resolvendo um problema simples de um jeito complicado...

 

Li de forma muito divertida.

 

Que pessoas incríveis. :)

 

Eu achava que o Partido Trabalhista do Reino Unido ficava mais à esquerda do que os Conservadores, mas olha só, hein~

 

Acho que os ícones só devem ser usados quando puderem ser entendidos de imediato, e parece indispensável também haver uma função de pressionar e segurar para mostrar um texto de apoio.

 
roryk 2025-02-26 | comentário pai | em: Por que Clojure? (gaiwan.co)

Pessoalmente, uso Clojure e concordo bastante com o conteúdo do texto.
No trabalho, tenho usado principalmente Python e Java(Type)Script, mas bastava relaxar um pouco na manutenção para acabar sendo difícil acompanhar as mudanças da própria linguagem e das bibliotecas, e o código logo virava legado. No caso de Clojure, fiquei muito satisfeito com o fato de que, mesmo ao rever um código escrito há um ano, é muito fácil partir direto para ajustes e desenvolvimento.
Desde então, para uso pessoal, tenho preferido Clojure sempre que não há limitações de alguma biblioteca específica.

 

Você escreve muito bem.

Gostei muito de ler!

 

É muito caro, não tem bom custo-benefício. No uso real, o o3-mini até parece ser melhor, mas para usar em programação, como a etapa de raciocínio é curta e precisa resolver os tokens intermediários, para esse propósito parece ser o melhor. O preço também..

 

A diferença de preço é grande demais para comparar com o flash 2.. fica bem no meio entre o o1pro e o o3-mini

 

Sou o hahnlee, que desenvolveu o hwp.js (https://github.com/hahnlee/hwp.js) :)
Quando desenvolvi esse projeto, e ainda hoje, não gosto muito de HWP. Especialmente no que diz respeito ao nível de abertura.

Ainda assim, concordo até certo ponto com a parte de que o "formato HWP tem elementos favoráveis para treinamento de IA".

Falando com base na experiência de quando construí um RAG, na Coreia usa-se muitas tabelas, em especial. No caso de PDF, como é um formato feito pensando em impressão, não existe "tabela" dentro do PDF. Há apenas linhas e texto.

Por isso, extrair dados de informações tabulares complexas era difícil com base em documentos PDF. Especialmente quando a tabela se estendia para a página seguinte.

Fazendo uma analogia grosseira, se o HWP parece uma espécie de documento de rich text, o PDF dava a sensação de ser um documento txt. Claro, isso se limita ao caso de "tabelas".

Mas isso é uma grande vantagem específica do formato HWP? Acho que não. Para coisas simples, Markdown já basta, e se for algo mais complexo, acho melhor definir em HTML.

E, decisivamente, docx e odt também têm a mesma vantagem.

 

Depois que a Netscape foi completamente atropelada pelo IE, saiu liberando o código-fonte e correndo atrás do prejuízo com atraso, né.

 

Não gosto de hwp e não tenho coisas boas a dizer sobre os produtos da atual empresa Hancom, mas acho que no passado o produto em si era um software muito melhor do que o Word.

 

Para dar uma resposta precisa: mesmo sendo o mesmo livro, se o formato for diferente, é preciso emitir um ISBN separado. Até mesmo e-books em epub e pdf precisam de ISBNs distintos.
Respondendo ao comentário acima, no caso dos e-books na Coreia, como mencionado no texto, o conceito é mais o de comprar um “direito de serviço” do que possuir o conteúdo em si. Além disso, cada livraria aplica DRM diferente. Por isso, muitas vezes não dá para usar com conforto, em qualquer ambiente, um e-book que comprei com o meu próprio dinheiro; precisamos de leis adequadas aos tempos atuais. T_T
Pessoalmente, assim como acontece com o MyData no setor financeiro, eu gostaria que materiais digitais também pudessem ser consumidos no formato que eu quisesse, independentemente de onde eu os comprei.