matéria inicial

prefácio

Embora Kotlin tenha surgido em 2011, é uma das linguagens mais novas do ecos-
sistema Java. Desde então, uma versão do Kotlin rodando na máquina virtual Ja-
vaScript foi lançada, bem como uma versão compilada para código nativo. Isso
torna Kotlin uma linguagem muito mais universal do que Java, embora existam
grandes diferenças entre essas versões porque a versão Java depende da biblio-
teca padrão Java, que não está disponível nas outras duas. JetBrains, o criador ou
Kotlin, está trabalhando duro para levar cada versão a um nível equivalente, mas
isso levará algum tempo.

A versão JVM (Java Virtual Machine) é de longe a versão mais utilizada, e isso teve
um grande impulso quando o Google decidiu adotar o Kotlin como linguagem ofi-
cial para o desenvolvimento de aplicativos Android. Uma das principais razões
para a adoção do Google foi que a versão do Java disponível no Android é o Java
6, enquanto o Kotlin oferece a maioria dos recursos do Java 11 e muito mais. O Ko-
tlin também foi adotado pelo Gradle como a linguagem oficial para escrever
scripts de build para substituir o Groovy, que permite usar a mesma linguagem
para o build e para o que é construído.

Kotlin é voltado principalmente para programadores Java. Pode chegar um mo-

mento em que os programadores aprenderão Kotlin como sua linguagem princi-
pal. Mas, por enquanto, a maioria dos programadores fará apenas a transição de
Java para Kotlin.

Cada língua tem seu próprio jeito, determinado por alguns conceitos fundamen-
tais. Java foi criado com vários conceitos fortes em mente. Ele deve ser executado
em qualquer lugar, ou seja, em qualquer ambiente para o qual uma JVM esteja
disponível. A promessa era: “Escreva uma vez, execute em qualquer lugar”. Em-
bora alguns possam argumentar o contrário, essa promessa foi cumprida. Você
não apenas pode executar programas Java em quase todos os lugares, mas tam-
bém pode executar programas escritos em outras linguagens e compilados para a
JVM. Kotlin é uma dessas linguagens.

Outra das promessas de Java era que nenhuma evolução quebraria o código exis-
tente. Embora isso nem sempre tenha sido verdade, na maioria das vezes tem
sido respeitado. Mas isso pode não ser uma coisa boa. A principal consequência é
que muitas melhorias em outras linguagens não puderam ser trazidas para o Java
porque essas melhorias teriam destruído a compatibilidade. Qualquer programa
compilado com uma versão anterior do Java deve poder ser executado nas ver-
sões mais recentes sem ser recompilado. Se isso é útil ou não é uma questão de
opinião, mas o resultado é que a compatibilidade com versões anteriores sempre
jogou contra a evolução do Java.

Java também deveria tornar os programas mais seguros usando exceções verifica-
das, forçando assim os programadores a levar essas exceções em consideração.
Para muitos programadores, isso provou ser um fardo, levando à prática de agru-
par constantemente exceções verificadas em exceções não verificadas.
Embora Java seja uma linguagem orientada a objetos, ela deve ser tão rápida
quanto a maioria das linguagens para processamento de números. Os projetistas
da linguagem decidiram que, além dos objetos que representam números e valo-
res booleanos, Java se beneficiaria de ter primitivos não-objetos correspondentes,
permitindo cálculos muito mais rápidos. A consequência era que você não podia
(e ainda não pode) colocar primitivos em coleções como listas, conjuntos ou ma-
pas. E quando os fluxos foram adicionados, os projetistas de linguagem decidiram
criar versões específicas para primitivos — mas não todos os primitivos, apenas
os mais comumente usados. Se você estiver usando algumas das primitivas não
suportadas, você está sem sorte.

A mesma coisa aconteceu com as funções. Funções genéricas foram adicionadas

ao Java 8, mas permitiam apenas manipular objetos, não primitivos. Portanto,
funções especializadas foram projetadas para lidar com números inteiros, longos,
duplos e booleanos. (Mais uma vez, infelizmente, nem todos os primitivos. Não há
funções para os tipos primitivos byte, short e float.) Para piorar ainda mais as coi-
sas, eram necessárias funções adicionais para converter de um tipo primitivo
para outro ou de primitivos para objetos e vice-versa.

Java foi projetado há mais de 20 anos. Muitas coisas mudaram desde aquela
época, mas a maioria dessas mudanças não pôde ser trazida para o Java. Isso por-
que teria quebrado a compatibilidade ou eles foram trazidos para o Java de forma
que a compatibilidade fosse preservada em detrimento da usabilidade.

Muitas novas linguagens, como Groovy, Scala e Clojure, foram lançadas desde en-
tão para lidar com essas limitações. Essas linguagens são compatíveis com Java
até certo ponto, o que significa que você pode usar bibliotecas Java existentes em
projetos escritos nessas linguagens, e os programadores Java podem usar bibliote-
cas desenvolvidas nessas linguagens.

Kotlin é diferente. O Kotlin é muito mais integrado ao Java, a ponto de você poder
misturar código-fonte Kotlin e Java no mesmo projeto sem nenhuma dificuldade!
Ao contrário de outras linguagens JVM, Kotlin não parece uma linguagem dife-
rente (embora seja um pouco diferente). Em vez disso, parece o que o Java deve-
ria ter se tornado. Alguns até dizem que Kotlin é o Java feito certo, o que significa
que ele corrige a maioria dos problemas com a linguagem Java. (No entanto, o Ko-
tlin ainda precisa lidar com as limitações da JVM.)

Porém, mais importante, o Kotlin foi projetado para ser muito mais amigável com
muitas técnicas provenientes da programação funcional. Kotlin tem referências
mutáveis ​e imutáveis, mas promove fortemente as imutáveis. Kotlin também pos-
sui grande parte das abstrações funcionais que permitem evitar estruturas de
controle (embora também possua estruturas de controle tradicionais para suavi-
zar a transição das linguagens tradicionais).

Outro grande benefício de usar o Kotlin é que ele reduz a necessidade de código
clichê, permitindo o mínimo necessário. Com Kotlin, você pode criar uma classe
com propriedades opcionais (mais equals , hashCode , toString e copy fun-
ções) em uma única linha de código, onde a mesma classe escrita em Java precisa-
ria de cerca de trinta linhas (incluindo getters, setters e construtores
sobrecarregados).

Embora existam outras linguagens que foram projetadas para superar as limita-
ções do Java no ambiente JVM, o Kotlin é diferente porque se integra aos progra-
mas Java no nível do código-fonte do projeto. Você pode misturar arquivos de ori-
gem Java e Kotlin nos mesmos projetos com uma única cadeia de construção. Isso
é uma virada de jogo, especialmente em relação à programação de equipe, onde
usar Kotlin em um ambiente Java não é mais complicado do que usar qualquer bi-
blioteca de terceiros. Isso torna a transição mais suave possível de Java para uma
nova linguagem e permite que você escreva programas que sejam:

Mais seguro
Mais fácil de escrever, testar e manter
Mais escalável

Suspeito que muitos leitores serão programadores Java em busca de novas solu-
ções para seus problemas do dia a dia. Se este é você, deve estar se perguntando
por que deveria usar Kotlin. Já não existem outras linguagens no ecossistema Java
com as quais você pode aplicar facilmente técnicas de programação seguras?

Claro que existem, e um dos mais conhecidos é o Scala. Scala é uma alternativa
muito boa para Java, mas Kotlin tem algo mais. Scala pode interagir com Java no
nível da biblioteca, o que significa que programas Java podem usar bibliotecas
Scala (objetos e funções) e bibliotecas Scala podem usar bibliotecas Java (objetos e
métodos). Mas os programas Scala e Java devem ser construídos como projetos se-
parados, ou pelo menos módulos separados, enquanto as classes Kotlin e Java po-
dem ser misturadas dentro do mesmo módulo.

Continue lendo para saber mais sobre Kotlin.

agradecimentos

Gostaria de agradecer às muitas pessoas que participaram para tornar este livro
possível. Em primeiro lugar, um grande obrigado à minha editora de desenvolvi-
mento, Marina Michaels. Além do seu maravilhoso trabalho no manuscrito, foi
um grande prazer trabalhar com você. Agradeço também ao meu editor de rese-
nhas, Aleksandar Dragosavljević.

Um grande obrigado também a Joel Kotarski, Joshua White e Riccardo Terrell,

meus editores técnicos, e a Alessandro Campeis e Brent Watson, meus revisores
técnicos, todos os quais me ajudaram a tornar este livro muito melhor do que eu
poderia ter feito sozinho. . A todos os revisores, leitores do MEAP e todos os outros
que forneceram feedback e comentários, obrigado! Este livro não seria o que é
hoje sem a sua ajuda. Especificamente, gostaria de agradecer às seguintes pessoas
que dedicaram seu tempo para revisar e comentar o livro: Aleksei Slaikovskii,
Alessandro Campeis, Andy Kirsch, Benjamin Goldberg, Bridger Howell, Conor
Redmond, Dylan McNamee, Emmanuel Medina López, Fabio Falci Rodrigues, Fe-
derico Kircheis, Gergő Mihály Nagy, Gregor Raýman, Jason Lee, Jean-François Mo-
rin, Kent R. Spillner, Leanne Northrop, Mark Elston, Matthew Halverson, Matthew
Proctor,

Também gostaria de agradecer à equipe da Manning: Deirdre Hiam, Frances Bu-

ran, Keri Hales, David Novak, Melody Dolab e Nichole Beard.
sobre este livro

Quem deveria ler esse livro

O objetivo deste livro não é simplesmente ajudá-lo a aprender a linguagem Kotlin,

mas também ensiná-lo a escrever programas muito mais seguros usando Kotlin.
Isso não significa que você só deve usar Kotlin se quiser escrever programas mais
seguros e, menos ainda, que apenas o Kotlin permite escrever programas mais se-
guros. Este livro usa Kotlin para todos os exemplos porque Kotlin é uma das lin-
guagens mais amigáveis ​para escrever programas seguros no ecossistema JVM
(Java Virtual Machine).

Este livro ensina técnicas que foram desenvolvidas há muito tempo em muitos
ambientes diferentes, embora muitas delas venham da programação funcional.
Mas este livro não é sobre programação funcional fundamentalista. Este livro é
sobre programação segura pragmática.

Todas as técnicas descritas foram colocadas em produção no ecossistema Java por

anos e provaram ser eficazes na produção de programas com muito menos bugs
de implementação do que as técnicas tradicionais de programação imperativa. Es-
sas técnicas seguras podem ser implementadas em qualquer linguagem e têm
sido usadas por alguns por muitos anos em Java. Porém, muitas vezes, o uso des-
sas técnicas foi obtido por meio da luta para superar as limitações do Java.

Este livro não é sobre aprender a programar desde o nível zero. Destina-se a pro-
gramadores em ambientes profissionais que procuram uma maneira mais fácil e
segura de escrever programas sem erros.
O que você aprenderá

Neste livro, você aprenderá técnicas específicas que podem diferir do que você
aprendeu se for um programador Java. A maioria dessas técnicas soará desconhe-
cida ou até mesmo contradirá o que os programadores geralmente reconhecem
como melhores práticas. Mas muitas (embora não todas) práticas recomendadas
são da época em que os computadores tinham 640 K de memória, 5 MB de arma-
zenamento em disco e um processador de núcleo único. As coisas mudaram. Hoje
em dia, um smartphone simples é um computador com 3 GB ou mais de RAM, 256
GB de armazenamento em disco de estado sólido e um processador de 8 núcleos;
da mesma forma, os computadores têm muitos gigabytes de memória, terabytes
de armazenamento e processadores multi-core.

As técnicas que abordo neste livro incluem:

Levando a abstração adiante

Favorecendo a imutabilidade
Entendendo a transparência referencial
Encapsulando compartilhamento de mutação de estado
Abstraindo o fluxo de controle e as estruturas de controle
Usando os tipos certos
Trabalhando com preguiça
E mais

Levando a abstração adiante

Uma das técnicas mais importantes que você aprenderá é levar a abstração muito
além (embora os programadores tradicionais considerem a abstração prematura
 tão ruim quanto a otimização prematura). Mas forçar a abstração ainda mais re-
sulta em uma compreensão muito melhor do problema a ser resolvido, o que, por
sua vez, resulta na resolução mais frequente do problema certo em vez de outro
diferente.

Você pode se perguntar o que realmente significa empurrar a abstração ainda

mais. Simplesmente, significa reconhecer padrões comuns em diferentes compu-
tações e abstrair esses padrões para evitar reescrevê-los repetidamente.

Imutabilidade

A imutabilidade é uma técnica que consiste em usar apenas dados não modificá-
veis. Muitos programadores tradicionais têm dificuldade em imaginar como é
possível escrever programas úteis usando apenas dados imutáveis. A programa-
ção não é baseada principalmente na modificação de dados? Bem, isso é como
acreditar que a contabilidade está basicamente modificando valores em um livro
contábil.

A transição da contabilidade mutável para imutável foi feita no século XV, e o

princípio da imutabilidade foi reconhecido desde então como o principal ele-
mento de segurança para a contabilidade. Esse princípio também se aplica à pro-
gramação, como você verá neste livro.

transparência referencial

A transparência referencial é uma técnica que permite escrever programas deter-

minísticos , ou seja, programas cujos resultados você pode prever e raciocinar. Es-
ses programas sempre produzem os mesmos resultados quando recebem a
 mesma entrada. Isso não significa que eles sempre produzem os mesmos resulta-
dos, mas que variações nos resultados dependem apenas de variações na entrada
e não em condições externas.

Esses programas não são apenas mais seguros (porque você sempre sabe como
eles se comportarão), mas também são muito mais fáceis de compor, manter, atu-
alizar e testar. E os programas que são mais fáceis de testar são geralmente testa-
dos melhor e, portanto, são mais confiáveis.

Compartilhamento de mutação de estado encapsulado

Dados imutáveis ​são automaticamente protegidos contra compartilhamento aci-

dental de mutação de estado, o que causa muitos problemas no processamento si-
multâneo e paralelo, como deadlock, livelock, thread starvation e dados obsoletos.
Mas tornar o compartilhamento de mutação de estado impossível, porque não há
mutação de estado, é um problema quando o estado deve ser compartilhado. Este
é o caso da programação concorrente e paralela.

Ao remover a mutação de estado, você impossibilita o compartilhamento aciden-

tal da mutação de estado, portanto, os programas são mais seguros. Mas a progra-
mação paralela e concorrente implica o compartilhamento da mutação de estado.
Caso contrário, não haveria nenhuma cooperação entre threads paralelos ou si-
multâneos. Esse caso de uso específico de mutação de estado compartilhado pode
ser abstraído e encapsulado para que possa ser reutilizado sem riscos, porque a
implementação única terá sido totalmente testada em vez de reimplementá-la
cada vez que for usada, como é o caso da programação tradicional.
 Neste livro, você aprenderá como abstrair e encapsular o compartilhamento de
mutação de estado para que você só precise escrevê-lo uma vez. Então você pode
reutilizá-lo em qualquer lugar que precisar.

Abstraindo o fluxo de controle e as estruturas de controle

A segunda fonte comum de bugs em programas, depois de compartilhar o estado

mutável, são as estruturas de controle. Os programas tradicionais são compostos
de estruturas de controle, como loops e testes condicionais. É tão fácil mexer com
essas estruturas que os designers de linguagem tentaram abstrair os detalhes o
máximo possível. Um dos melhores exemplos é o for each loop que agora está
presente na maioria das linguagens (embora em Java ainda seja chamado sim-
plesmente de for ).

Outro problema comum é o uso correto de while e do while (ou repeat un-
til ) e, particularmente, determinar onde testar a condição. Um problema adicio-
nal é a modificação simultânea durante o loop em coleções, onde você encontra o
problema de compartilhar o estado mutável embora esteja usando um único th-
read! A abstração das estruturas de controle permite eliminar completamente es-
ses tipos de problemas.

Usando os tipos certos

Na programação tradicional, tipos gerais como int e String são usados ​para re-
presentar quantidades sem levar em consideração as unidades. Como consequên-
cia, é muito fácil mexer com esses tipos, somando milhas a galões ou dólares a mi-
nutos. O uso de tipos de valor pode eliminar completamente esse tipo de pro-
 blema a um custo muito baixo, mesmo que a linguagem que você está usando não
ofereça tipos de valor verdadeiros.

Preguiça

A maioria das linguagens comuns são consideradas restritas , o que significa que
os argumentos passados ​para um método ou função são avaliados primeiro antes
de serem processados. Isso parece fazer sentido, embora muitas vezes não. Pelo
contrário, a preguiça é uma técnica que consiste em avaliar elementos apenas se e
quando eles forem usados. A programação é essencialmente baseada na preguiça.

Por exemplo, em uma if...else estrutura, a condição é avaliada estritamente,

ou seja, é avaliada antes de ser testada, mas os ramos são avaliados preguiçosa-
mente, ou seja, apenas o ramo correspondente à condição é executado. Essa pre-
guiça é totalmente implícita e o programador não a controla. Fazer uso explícito
da preguiça o ajudará a escrever programas muito mais eficientes.

Público

Este livro é para leitores com alguma experiência anterior em programação em

Java. Alguma compreensão dos tipos parametrizados (genéricos) também é assu-
mida. Este livro faz uso intenso de tais técnicas, incluindo chamadas de funções
parametrizadas, ou variância, que não são usadas com frequência em Java (em-
bora seja uma técnica poderosa). Não tenha medo se você ainda não conhece es-
sas técnicas; Explicarei o que significam e por que são necessários.
Como este livro está organizado: um roteiro

Este livro deve ser lido sequencialmente, pois cada capítulo se baseia nos concei-
tos aprendidos nos anteriores. Eu uso a palavra ler , mas este livro não se destina
apenas a ser lido. Muito poucas seções contêm apenas teoria.

Para obter o máximo deste livro, leia-o em seu computador, resolvendo cada exer-
cício à medida que avança. Cada capítulo inclui uma série de exercícios com as
instruções e dicas necessárias para ajudá-lo a chegar à solução. Cada exercício
vem com uma solução proposta e um teste que você pode usar para verificar se
sua solução está correta.

OBSERVAÇÃO Todo o código está disponível como um download gratuito sepa-

rado no GitHub ( http://github.com/pysaumont/fpinkotlin ). O código vem com to-
dos os elementos necessários para que o projeto seja importado para o IntelliJ (re-
comendado) ou compilado e executado no Gradle 4. Se você usa o Gradle, pode
editar o código com qualquer editor de texto. O Kotlin deve ser utilizável com o
Eclipse, mas não posso garantir isso. O IntelliJ é um IDE muito superior e pode ser
baixado gratuitamente no site da Jetbrains (
https://www.jetbrains.com/idea/download ).

Completando os exercícios

Os exercícios são essenciais para o seu aprendizado e para a compreensão do que

este livro ensina. Observe que não se espera que você entenda a maioria dos con-
ceitos apresentados neste livro apenas lendo o texto. Fazer os exercícios é prova-
velmente a parte mais importante do processo de aprendizado, então eu o enco-
rajo a não pular nenhum exercício.
 Alguns exercícios podem parecer bastante difíceis e você pode ficar tentado a
olhar para as soluções propostas. Não há problema em fazer isso, mas você deve
voltar ao exercício e fazê-lo sem olhar para a solução. Se você apenas ler a solu-
ção, provavelmente terá problemas mais tarde ao tentar resolver exercícios mais
avançados.

Essa abordagem não requer muita digitação tediosa porque você não tem quase
nada para copiar. A maioria dos exercícios consiste em escrever implementações
para funções, para as quais você recebe o ambiente e a assinatura da função. Ne-
nhuma solução de exercício tem mais de uma dúzia de linhas de código; a maioria
tem cerca de quatro ou cinco linhas. Depois de terminar um exercício (ou seja,
quando sua implementação for compilada), basta executar o teste correspondente
para verificar se está correto.

Uma coisa importante a observar é que cada exercício é independente em relação

ao restante do capítulo, portanto, o código criado dentro de um capítulo é dupli-
cado de um exercício para o outro. Isso é necessário porque cada exercício geral-
mente é construído sobre o anterior, portanto, embora a mesma classe possa ser
usada, as implementações diferem. Como consequência, você não deve olhar para
um exercício posterior antes de completar os anteriores porque você veria as so-
luções para exercícios ainda não resolvidos.

Aprendendo as técnicas deste livro

As técnicas descritas neste livro não são mais difíceis de dominar do que as tradi-
cionais. Eles são apenas diferentes. Você pode resolver os mesmos problemas com
técnicas tradicionais, mas traduzir de uma técnica para outra pode ser ineficiente.
Aprender novas técnicas é como aprender uma língua estrangeira. Assim como
você não pode pensar eficientemente em um idioma e traduzir para outro, você
não pode pensar na programação tradicional baseada em mutação de estado e
fluxo de controle e traduzir seu código para funções que lidam com dados imutá-
veis. E, assim como você precisa aprender a pensar em um novo idioma, precisa
aprender a pensar de maneira diferente. Isso não vem apenas com a leitura; ele
vem com código de escrita. Então você tem que praticar!

É por isso que não espero que você entenda o que está neste livro apenas lendo-o,
e porque ofereço tantos exercícios; você deve fazer os exercícios para compreen-
der completamente os conceitos. Não porque cada tópico seja tão complexo que
não seja possível compreendê-lo apenas pela leitura. Se você pudesse entendê-lo
apenas lendo sem fazer os exercícios, provavelmente não precisaria deste livro.

Por todos esses motivos, os exercícios são essenciais para aproveitar ao máximo
este livro. Encorajo-o a tentar resolver cada exercício antes de continuar a leitura.
Se você não encontrar uma solução, tente novamente em vez de ir diretamente
para a solução que forneço.

Se você tiver dificuldade em entender alguma coisa, faça perguntas no fórum

(consulte a próxima seção). Fazer perguntas e obter respostas no fórum não ape-
nas ajudará você, mas também ajudará a pessoa que está respondendo à pergunta
(junto com outras pessoas que têm a mesma pergunta). Todos nós aprendemos
respondendo a perguntas (principalmente nossas próprias perguntas, aliás) muito
mais do que fazendo-as.
Sobre o código

Este livro contém muitos exemplos de código-fonte tanto em listagens numeradas

quanto em linha com texto normal. Em ambos os casos, o código-fonte é forma-
tado em a fixed-width font like this para separá-lo do texto comum.

Em muitos casos, o código-fonte original foi reformatado; adicionamos quebras de

linha e retrabalhamos o recuo para acomodar o espaço de página disponível no li-
vro. Anotações de código acompanham muitas das listagens, destacando conceitos
importantes.

Você pode baixar o código como um arquivo ou cloná-lo usando o Git. O código
dos exercícios é organizado em módulos com nomes que refletem os títulos dos
capítulos em vez dos números dos capítulos. Como resultado, o IntelliJ os classifi-
cará em ordem alfabética, e não na ordem em que aparecem no livro.

Para ajudá-lo a descobrir qual módulo corresponde a cada capítulo, forneci uma
lista dos capítulos com os nomes dos módulos correspondentes no arquivo RE-
ADME que acompanha o código ( http://github.com/pysaumont/fpinkotlin ).

O código-fonte de todas as listas neste livro também está disponível para down-
load no site da Manning em https://www.manning.com/books/the-joy-of-kotlin .

discussão ao vivo

A compra de The Joy of Kotlin inclui acesso gratuito a um fórum privado da Web
administrado pela Manning Publications, onde você pode fazer comentários sobre
o livro, fazer perguntas técnicas e receber ajuda do autor e de outros usuários.
 Para acessar o fórum, acesse https://livebook.manning.com/#!/book/the-joy-of-
kotlin/discussion . Você também pode saber mais sobre os fóruns de Manning e as
regras de conduta em https://livebook.manning.com/#!/discussion .

O compromisso de Manning com nossos leitores é fornecer um local onde possa

ocorrer um diálogo significativo entre leitores individuais e entre leitores e o au-
tor. Não é um compromisso com qualquer quantidade específica de participação
por parte do autor, cuja contribuição ao fórum permanece voluntária (e não re-
munerada). Sugerimos que você tente fazer ao autor algumas perguntas desafia-
doras para que ele não perca o interesse! O fórum e os arquivos das discussões
anteriores estarão acessíveis no site da editora enquanto o livro estiver sendo
impresso.

Sobre o autor

Pierre-Yves Saumont é um desenvolvedor Java experiente com três décadas de ex-

periência projetando e construindo software corporativo. Ele é engenheiro de
P&D da ASN (Alcatel Submarine Networks).

sobre a ilustração da capa

A figura na capa de The Joy of Kotlin tem a legenda “Habit of a Lady in Chinese
Tartary, 1700”. A ilustração foi tirada de A Collection of the Dresses of Different Na-
tions, Ancient and Modern (quatro volumes), de Thomas Jefferys, Londres, publi-
cada entre 1757 e 1772. A página de título afirma que são gravuras em placa de
cobre coloridas à mão, realçadas com goma arábica .
Thomas Jefferys (1719–1771) foi chamado de “geógrafo do rei George III”. Ele era
um cartógrafo inglês que era o principal fornecedor de mapas de sua época. Ele
gravou e imprimiu mapas para o governo e outros órgãos oficiais e produziu uma
ampla gama de mapas e atlas comerciais, especialmente da América do Norte. Seu
trabalho como cartógrafo despertou o interesse pelos costumes locais de vestuário
das terras que ele pesquisou e mapeou, que são exibidos de forma brilhante nesta
coleção. O fascínio por terras distantes e as viagens de lazer eram fenômenos rela-
tivamente novos no final do século XVIII, e coleções como esta eram populares,
apresentando tanto o turista quanto o viajante de poltrona aos habitantes de ou-
tros países.

A diversidade dos desenhos nos volumes de Jefferys fala vividamente da singula-

ridade e individualidade das nações do mundo há cerca de 200 anos. Os códigos
de vestimenta mudaram desde então, e a diversidade por região e país, tão rica na
época, desapareceu. Agora é muitas vezes difícil distinguir os habitantes de um
continente de outro. Talvez, tentando ver com otimismo, tenhamos trocado uma
diversidade cultural e visual por uma vida pessoal mais variada — ou uma vida
intelectual e técnica mais variada e interessante.

Numa época em que é difícil distinguir um livro de computador de outro, Man-

ning celebra a inventividade e a iniciativa do setor de computadores com capas
de livros baseadas na rica diversidade da vida regional de dois séculos atrás, tra-
zida de volta à vida pelas fotos de Jeffreys.