copydesk

Author: ramalho

capitulos/cap19.adoc

@@ -1405,7 +1405,7 @@ Aquele workshop foi baseado nos últimos quatro capítulos do
 https://fpy.li/19-100[_Designing for Scalability with Erlang/OTP_]
 de Francesco Cesarini e Steve Vinoski (O'Reilly).
 
-Desenvolver((("KISS principle"))) sistemas distribuídos é desafiador e excitante, mas cuidado com a
+Desenvolver((("KISS principle"))) sistemas distribuídos é desafiador e empolgante, mas cuidado com a
 https://fpy.li/19-40[_inveja da escalabilidade na web_].
 O https://fpy.li/19-102[princípio KISS] (KISS é a sigla de _Keep It Simple, Stupid_: "Mantenha Isso Simples, Idiota") continua sendo uma recomendação firme de engenharia.
 

capitulos/cap20.adoc

@@ -858,7 +858,7 @@ Sou pago para desenvolver aplicações, não sistemas operacionais. Não preciso
 
 Por isso acho o pacote `concurrent.futures` interessante: ele trata threads, processos, e filas como infraestrutura, algo a seu serviço, não algo que você precisa controlar diretamente. Claro, ele foi projetado pensando em tarefas simples, os assim chamado problemas embaraçosamente paralelos—ao contrário de sistemas operacionais ou servidores de banco de dados, como aponta Simionato naquela citação.
 
-Para problemas de concorrência "não embaraçosos", threads e travas também não são a solução. Ao nível do sistema operacional, as threads nunca vão desaparecer. Mas todas as linguagens de programação que achei excitantes nos últimos muitos anos fornecem abstrações de alto nível para concorrência, como demonstra o excelente livro de Paul Butcher, https://fpy.li/20-24[_Seven Concurrency Models in Seven Weeks_] (_Sete Modelos de Concorrência em Sete Semanas_) (EN). Go, Elixir, e Clojure estão entre elas. Erlang—a linguagem de implementação do Elixir—é um exemplo claro de uma linguagem projetada desde o início pensando em concorrência. Erlang não me excita por uma razão simples: acho sua sintaxe feia. O Python me acostumou mal.
+Para problemas de concorrência "não embaraçosos", threads e travas também não são a solução. Ao nível do sistema operacional, as threads nunca vão desaparecer. Mas todas as linguagens de programação que achei empolgantes nos últimos muitos anos fornecem abstrações de alto nível para concorrência, como demonstra o excelente livro de Paul Butcher, https://fpy.li/20-24[_Seven Concurrency Models in Seven Weeks_] (_Sete Modelos de Concorrência em Sete Semanas_) (EN). Go, Elixir, e Clojure estão entre elas. Erlang—a linguagem de implementação do Elixir—é um exemplo claro de uma linguagem projetada desde o início pensando em concorrência. Erlang não me excita por uma razão simples: acho sua sintaxe feia. O Python me acostumou mal.
 
 José Valim, antes um dos contribuidores centrais do Ruby on Rails, projetou o Elixir com uma sintaxe moderna e agradável. Como Lisp e Clojure, o Elixir implementa macros sintáticas. Isso é uma faca de dois gumes. Macros sintáticas permitem criar DSLs poderosas, mas a proliferação de sub-linguagens pode levar a bases de código incompatíveis e à fragmentação da comunidade. O Lisp se afogou em um mar de macros, cada empresa e grupo de desenvolvedores Lisp usando seu próprio dialeto arcano. A padronização em torno do Common Lisp resultou em uma linguagem inchada. Espero que José Valim inspire a comunidade do Elixir a evitar um destino semelhante. Até agora, o cenário parece bom. O invólucro de bancos de dados e gerador de queries https://fpy.li/20-25[Ecto] é muito agradável de usar: um grande exemplo do uso de macros para criar uma DSL—sigla de Domain-Specific Language, _Linguagem de Domínio Específico_—flexível mas amigável, para interagir com bancos de dados relacionais e não-relacionais.
 

capitulos/cap24.adoc

@@ -31,7 +31,7 @@ Este capítulo apresenta as técnicas de metaprogramação de classes em ordem a
 
 [WARNING]
 ====
-Esse é um tópico excitante, e é fácil se deixar levar pelo entusiasmo.
+Esse é um tópico empolgante, e é fácil se deixar levar pelo entusiasmo.
 Então preciso deixar aqui esse conselho.
 
 Em nome da legibilidade e facilidade de manutenção, você provavelmente deveria evitar as técnicas descritas neste capítulo em aplicações.
@@ -950,7 +950,7 @@ O principal caso de uso para `+__prepare__+` antes do Python 3.6 era oferecer um
 Agora que `dict` preserva a ordem de inserção, `+__prepare__+` raramente é necessário.
 Veremos um uso criativo para ele no <<metahack_sec>>.
 
-Importar _metalib.py_ no console do Python não é muito excitante.
+Importar _metalib.py_ no console do Python não é muito empolgante.
 Observe o uso de `%` para prefixar as linhas geradas por esse módulo:
 
 [source, pycon]
@@ -1370,7 +1370,7 @@ A terceira versão de uma fábrica de classes `Checked`, com descritores `Field`
 Por fim, vimos o hack `AutoConst`, inventado por João S. O. Bueno, baseado na brilhante ideia de uma metaclasse com `+__prepare__+` devolvendo um mapeamento que implementa `+__missing__+`.
 Em menos de 20 linhas de código, _autoconst.py_ demonstra o poder da combinação de técnicas de metaprogramação no Python.
 
-Nunca encontrei outra linguagem como o Python, fácil para iniciantes, prática para profissionais e excitante para hackers. 
+Nunca encontrei outra linguagem como o Python, fácil para iniciantes, prática para profissionais e empolgante para hackers. 
 Obrigado, Guido van Rossum e todos que a fazem ser assim.