Aprendendo programação Swift: está pronto para o horário nobre?

O lançamento da Apple, em junho passado, do Swift, uma nova linguagem de programação para escrever aplicativos iOS, criou muito burburinho e entusiasmo em toda a comunidade de desenvolvedores iOS.

Desde o seu lançamento, muitos desenvolvedores iOS têm lutado com a questão de se, como e quando fazer a transição do Objective-C para o Swift. É claro que a resposta a essa pergunta será diferente para cada equipe e cada projeto.

Existem vários artigos que você pode ler cobrindo muitas das vantagens do Swift. Portanto, em vez de repetir esses mesmos pontos, neste artigo, focaremos em algumas das preocupações que você pode considerar antes de aprender o desenvolvimento de aplicativos com o Swift.

Mas primeiro, vamos voltar um pouco o relógio…

Antes do Swift: Você vai usar Objective-C, e vai gostar…

O ano era 2010. O iPhone ainda não tinha 3 anos, e a capacidade de escrever aplicativos nativos para o iPhone só existia há cerca de 2 anos. Em 8 de abril daquele ano, a Apple anunciou a versão do iPhone OS. O iPhone OS (isso foi antes de mudar seu nome para iOS) incluía novos recursos tentadores como multitarefa, troca rápida de aplicativos e serviços em segundo plano. Compreensivelmente, os desenvolvedores do iPhone estavam ansiosos para colocar as mãos no novo SDK e começar a jogar com todos esses novos recursos interessantes.

Mas o SDK do iPhone OS 4 continha uma bomba inesperada. Essa bomba não estava no software, estava no contrato de uso. Com o SDK do iPhone OS 4, a Seção 3.3.1 do Contrato do Desenvolvedor foi atualizada para incluir a seguinte linguagem problemática:

Os aplicativos devem ser originalmente escritos em Objective-C, C, C++… e somente o código escrito em C, C++ e Objective-C pode compilar e vincular diretamente às APIs documentadas.
– Seção 3.3.1 do Contrato de Desenvolvedor do iPhone OS 4 SDK

Escusado será dizer que esta nova restrição pegou muitos desenvolvedores de surpresa. O motivo oficial da mudança, fornecido pelo próprio Steve Jobs, foi impedir o uso de ferramentas multiplataforma, como o recém-anunciado Flash CS5. Jobs foi citado dizendo que “camadas intermediárias entre a plataforma e o desenvolvedor, em última análise, produzem [sic] aplicativos abaixo do padrão”. Mas o fato de que a abordagem da Apple para combater essas “camadas intermediárias” foi restringir quais linguagens de programação poderiam ser usadas para escrever aplicativos para iPhone revelou algo mais sobre o pensamento da Apple: Objective-C deveria ser bom o suficiente para qualquer um.

Alguém poderia ser perdoado por concordar com essa afirmação, já que o Objective-C ganhou o prêmio de “Linguagem de Programação do Ano” do Tiobe Index por dois anos consecutivos. Mas a realidade era que a popularidade do Objective-C era uma função do crescente ecossistema de aplicativos, e não o contrário. Mesmo em 2010, muitas pessoas já estavam insatisfeitas com Objective-C e, como resultado, formas alternativas de escrever aplicativos para iPhone em outras linguagens de programação já estavam surgindo.

Eventualmente, sob pressão da comunidade de desenvolvedores em geral, a Apple rescindiu essas mudanças na Seção 3.3.1 do SDK Developer Agreement apenas cinco meses depois. Ainda assim, a mensagem era clara: se você quisesse escrever aplicativos para o iPhone, provavelmente deveria estar usando Objective-C.

… ou talvez não. Digite o novo idioma do iOS Swift.

Avance 4 anos desse incidente até junho de 2014, quando a Apple apresentou aos desenvolvedores sua nova linguagem, Swift. Se a mensagem de 4 anos antes era que a Apple estava perfeitamente satisfeita com Objective-C, então a mensagem enviada pela introdução de Swift foi que a Apple estava finalmente pronta para admitir a verdade. Objective-C pode não ser necessariamente a melhor linguagem para escrever aplicativos móveis.

Muito já foi dito sobre como o Swift é uma linguagem mais “moderna” do que Objective-C. Se você estiver interessado em aprender a linguagem de programação Swift, confira o guia para mudar de Objective-C para Swift.

O que você deve notar, porém, é que existem duas diferenças importantes entre as linguagens Objective-C e Swift:

1. Swift não é um superconjunto estrito da linguagem C.
2. Swift é tipado estaticamente, não tipado dinamicamente.

Não ser um superconjunto estrito de C significa que o Swift é livre para fazer uso de construções de sintaxe que de outra forma não seriam permitidas. Isso possibilita, por exemplo, implementar operadores personalizados em Swift.

Ser digitado estaticamente significa que o Swift pode tirar proveito de muitos dos avanços recentes em sistemas de tipos pioneiros em linguagens como Haskell.

Apesar de estar em desenvolvimento há 4 anos antes de ser revelado ao público, o Swift ainda é uma linguagem de programação jovem, por isso vem com uma série de ressalvas.

Compatibilidade com Objective-C

O iOS compartilha uma herança comum com o OS X, que por sua vez leva sua história do sistema operacional NeXTSTEP lançado pela primeira vez em 1989. O NeXTSTEP foi originalmente escrito em grande parte em Objective-C, e muitas das principais bibliotecas do OS X e iOS têm suas raízes todas o caminho de volta para essas implementações originais. (Aliás, é daí que vem o onipresente prefixo “NS” encontrado em classes principais como NSString .) Embora o Swift possa teoricamente existir na ausência dessas bibliotecas principais, a realidade é que qualquer programa Swift que você possa escrever em um futuro próximo terá que fazer interface com Objective-C.

Para seu crédito, os desenvolvedores por trás do Swift fizeram um trabalho fantástico tornando a interação com bibliotecas Objective-C existentes o mais simples possível. Isso não quer dizer que o processo é completamente indolor. A Apple forneceu um guia útil explicando como chamar o código Objective-C do Swift e vice-versa, mas há algumas incompatibilidades de impedância importantes a serem observadas.

Talvez a incompatibilidade mais óbvia esteja relacionada aos arquivos de cabeçalho. Objective-C, devido às suas raízes C, ainda requer que as funções sejam declaradas antes de serem chamadas. Ao chamar uma biblioteca, essas declarações serão encontradas nos arquivos de cabeçalho da biblioteca. Swift, no entanto, não usa arquivos de cabeçalho. Portanto, se você quiser chamar o código Swift do Objective-C, primeiro precisará criar um “cabeçalho de ponte”. Embora conceitualmente isso possa não parecer tão complexo, na prática, na verdade pode ser uma tarefa e tanto.

Outro conjunto de complicações na interface entre Swift e Objective-C decorre das diferenças inerentes em seus sistemas de tipos. Swift, seguindo uma sugestão de outras linguagens modernas, acabou com o conceito de nil . Em seu lugar estão os tipos opcionais do Swift. Por exemplo, um método que abre um arquivo somente se ele já existir teria um tipo de retorno de File? (em vez de apenas File ) em Swift. Ao rastrear todos os locais onde os tipos são opcionais, o compilador Swift pode efetivamente tornar impossível encontrar o temido “Erro de ponteiro nulo”. Isto é, claro, a menos que você esteja chamando Objective-C. Como o Objective-C não oferece garantias sobre não retornar nil , o Swift tem uma categoria especial de tipos chamados Opcionais Implicitamente Desempacotados que são usados ​​ao chamar o código Objective-C. Esses tipos podem ser tratados como opcionais na linguagem Swift, juntamente com toda a sobrecarga necessária para verificação de existência. Alternativamente, eles podem ser usados ​​da mesma forma que qualquer tipo não opcional, mas se o Objective-C retornar um nil , você terminará com um erro de tempo de execução, então você perderá algumas das garantias de segurança em tempo de compilação do Swift.

Finalmente, uma incompatibilidade um pouco mais sutil a ser considerada ao programar entre Swift e Objective-C tem a ver com como objetos e classes são criados secretamente nessas duas linguagens. O Objective-C, devido à sua natureza dinâmica, utiliza despacho dinâmico para chamar métodos em objetos (via objc_msgSend ). Swift certamente pode usar despacho dinâmico, mas como ele é estaticamente tipado, ele também tem a opção de usar uma vtable para armazenar ponteiros de função para cada método. Qual desses dois mecanismos o Swift usa depende de alguns fatores. O Plane Old Swift Objects usará o mecanismo vtable , a menos que a classe ou os métodos dentro da classe sejam anotados usando o atributo @objc Swift. Classes Swift que herdam de classes Objective-C usarão despacho dinâmico para métodos herdados, mas não para quaisquer novos métodos introduzidos pela subclasse (embora, novamente, você possa forçar o uso de despacho dinâmico com o atributo @objc ). Independentemente disso, o código Swift sempre poderá trabalhar com classes Swift, mas o código Objective-C só pode utilizar objetos e métodos Swift que foram anotados corretamente.

Mais rápido que Objective-C?

Quando a Apple apresentou seu lançamento, um dos benefícios do Swift que foi especialmente enfatizado foi sua velocidade. Isso é compreensível quando você considera que uma razão frequentemente dada para a relutância da Apple em mudar do Objective-C para uma linguagem de nível superior foi que o Objective-C, sendo essencialmente uma extensão do C, era capaz de criar programas muito mais rápidos e eficientes. do que algo como Python ou Ruby. Mesmo assim, Objective-C não é um foguete quando se trata de desempenho absoluto, e muito disso pode ser atribuído à tipagem dinâmica. Portanto, com o Swift adotando um sistema de tipo estático, seria de se esperar que o Swift fosse pelo menos tão rápido ou mais rápido que o Objective-C.

É claro que, como diz o ditado, “Existem três tipos de mentiras: mentiras, mentiras malditas e referências”. (Ou algo assim…) Certamente, existem inúmeras razões pelas quais a linguagem Swift pode rodar mais rápido. Infelizmente, parece que a maneira como o Swift utiliza a técnica ARC (Automatic Reference Counting) da Apple para gerenciamento de memória às vezes resulta no compilador do Swift gerando programas significativamente mais lentos, especialmente com configurações de otimização mais baixas (como o que você pode usar durante o desenvolvimento). A boa notícia é que parece que as melhorias no Swift estão continuamente abordando esse problema e, portanto, é provável que em um futuro próximo o Swift gere executáveis ​​pelo menos tão rápido ou mais rápido que o Objective-C.

Há outra ressalva para a velocidade do Swift, no entanto. O ponto principal do Swift é que os desenvolvedores não escreverão o mesmo código que escreveriam em Objective-C. O que isso significa para o desempenho? Bem, certamente isso significa que comparar o desempenho entre Swift e Objective-C é mais complicado do que simples benchmarks podem revelar. Isso também significa que comparar o desempenho absoluto do tempo de execução dos executáveis ​​gerados conta apenas metade da história.

Todo mundo quer programas rápidos, mas muitas vezes a velocidade de desenvolvimento é tão – se não mais – importante. Uma linguagem mais expressiva, capaz de realizar mais trabalho em menos linhas de código, pode ser um grande benefício nesse sentido. Por outro lado, ao trabalhar em uma linguagem compilada onde o ciclo editar-compilar-executar-depurar ocupa grande parte do dia do programador, um compilador lento pode realmente prejudicar a produtividade. Embora a evidência seja principalmente anedótica, parece que o compilador Swift é atualmente lento o suficiente para ser irritante, especialmente ao trabalhar com código que exercita o sistema de tipos avançado do Swift. Um grupo até achou a velocidade de compilação problemática o suficiente para motivar uma mudança de volta para o Objective-C.

O compilador

Falando do compilador Swift, ele é a fonte de ainda mais ressalvas ao considerar a mudança para a nova linguagem Swift. Além da velocidade de compilação, como o Swift emergiu do pequeno grupo de desenvolvedores que trabalham com ele na Apple e foi liberado para as massas, o compilador começou a mostrar rachaduras sob o estresse. Existe até um repositório GitHub inteiro dedicado a coletar exemplos de código que farão com que o compilador Swift falhe.

Há também a questão de como o compilador Swift mudará. Outro projeto no GitHub está coletando especulações e análises da comunidade sobre quais mudanças podem estar reservadas para o Swift. Por exemplo, os operadores personalizados podem sobrecarregar significativamente um analisador. Inicialmente, os operadores personalizados em Swift não podiam usar um caractere de ponto de interrogação (?). Embora isso tenha sido corrigido na versão mais recente do Swift, as solicitações continuam chegando da crescente comunidade de desenvolvedores do Swift para obter ainda mais flexibilidade no que pode ser considerado um operador personalizado válido.

Sempre que você ouvir que o analisador de um idioma está em fluxo, ele deve fazer uma pausa. O analisador de uma linguagem é o coração e a alma de uma linguagem de programação. Antes que qualquer semântica de linguagem possa ser aplicada para dar significado ao código, é o analisador que determina o que é e o que não é código válido para começar. É encorajador, então, que a Apple tenha prometido garantir algum nível de compatibilidade de tempo de execução para o Swift. Isso não garante necessariamente, porém, que o código Swift será executado sem ser recompilado para cada nova versão do Xcode e/ou iOS. Nem garante que você não precisará reescrever partes do seu código Swift para permanecer compatível com versões futuras do Swift. Mas, novamente, o compromisso da Apple de tornar esse processo o menos doloroso possível é pelo menos um pequeno consolo.

Comunidade

Algumas das piores linguagens de programação já criadas (que permanecerão sem nome) foram impulsionadas, muito depois de o senso comum dizer que deveriam ter sido relegadas à lata de lixo da tecnologia fracassada apenas pela força de suas respectivas comunidades. Ao mesmo tempo, a coleção de linguagens de programação realmente boas que não conseguiram se estabelecer por falta de uma comunidade é muito numerosa para contar. Comunidades fortes produzem tutoriais, respondem a perguntas no Stack Overflow, saem online ou pessoalmente em conferências compartilhando histórias, dicas e truques, e escrevem e compartilham bibliotecas úteis entre si. Ao escolher qual idioma usar para um projeto, a comunidade é definitivamente algo a ser considerado.

Infelizmente, a comunidade iOS/Objective-C não tem a melhor reputação de ser amigável e acolhedora. Isso está mudando gradualmente, e o código aberto está desempenhando cada vez mais um papel mais importante no desenvolvimento de Objective-C. Ainda assim, neste estágio inicial, é difícil dizer como será a comunidade Swift daqui para frente. Ele consistirá principalmente de desenvolvedores isolados trabalhando apenas com as APIs oficiais da Apple e suas próprias coleções privadas de código? Ou será uma comunidade vibrante de grupos compartilhando dicas, truques e bibliotecas úteis?

Outra faceta do papel da comunidade é o papel dos próprios desenvolvedores do Swift. A tendência geral na programação tem sido se afastar das linguagens e plataformas de programação proprietárias para soluções de código aberto. O desenvolvimento Open Source, especialmente ao nível de linguagens de programação e runtimes, pode ser uma vantagem real. Embora os desenvolvedores do Swift tenham declarado várias vezes que sua intenção é abrir completamente a linguagem e o tempo de execução do Swift, isso ainda não ocorreu, portanto, é necessário cautela.

Dito isto, os desenvolvedores por trás do Swift são alguns dos mesmos desenvolvedores por trás do projeto LLVM de longa duração. O LLVM não é uma analogia perfeita, pois começou a vida aberta como um projeto da Universidade de Illinois, Urbana-Champaign. Mas, para seu crédito, os principais desenvolvedores permaneceram muito abertos e engajados com a comunidade, mesmo depois que a maioria deles passou a trabalhar para a Apple. É completamente razoável esperar que a linguagem Swift continue a ser desenvolvida (principalmente) em aberto, embora ainda não se saiba se os patches e as sugestões de recursos da comunidade chegarão à linguagem.

Devo aprender Swift?

É claro que não existe uma resposta “tamanho único” aqui. Como sempre, escolher a ferramenta certa para o trabalho exige um conhecimento profundo de todos os detalhes do projeto em questão. Certamente, neste momento, o Objective-C continua sendo a escolha “segura” para o desenvolvimento do iOS, mas o Swift é definitivamente digno de consideração.

A mudança mais significativa que o Swift traz para o desenvolvimento do iOS, porém, é que muitos desenvolvedores, pela primeira vez, estarão se perguntando: “Que linguagem devo usar?” Dada a história da Apple, Objective-C e a plataforma iOS, essa mudança por si só é bastante empolgante, especialmente considerando que a escolha não é binária. Embora a Apple tenha deixado claro sua preferência, a comunidade de desenvolvedores do iOS em geral trabalha duro há anos, fornecendo ainda mais respostas possíveis para essa pergunta.