Perguntas Frequentes

me

Eu • Bebendo uma cerveja.

Quem é você?


Olá, meu nome é Daniel Holden. Sou do Reino Unido, e atualmente estudo para um PhD na Edinburgh University. Minha pesquisa é na área de ferramentas dirigidas por dados para animação de personagens.

Você pode me conhecer por algum de meus projetos como Cello ou Corange. Além de hackear em C, curto escrever novelas, arte digital e desenvolver jogos.

Você pode dar uma olhada no meu site pessoal. Ou você pode me seguir no twitter.

Por que você não ensina arrays neste livro?


Com uma curva de aprendizado já íngreme, arrays pareceram uma omissão conveniente a fazer. Ensinar arrays em C é uma maneira fácil de confundir um iniciante sobre apontadores, que são um conceito muito mais importante a se aprender. Em C, as maneiras em que apontadores e arrays são iguais, mas diferentes, são sutis e numerosas. Excluindo arrays de tamanho fixo, que têm comportamento inteiramente diferente, apontadores representam um super set do comportamento de arrays, e então no contexto deste livro, ensinar arrays teria sido não mais que ensinar açúcar sintático.

Aquelas interessados em arrays são encorajados a descobrir mais. O livro Learn C the Hard Way usa uma abordagem contrária da minha, e ensina arrays primeiro, com apontadores sendo descritos como uma variação. Para aqueles interessados em arrays, isto pode ser útil.

Por que você usa sintaxe para apontador no lado esquerdo


Neste livro escrevo a sintaxe para apontadores no lado esquerdo int* x;, em vez da convenção no lado direito int *x;.

Fundamentalmente, esta distinção é de preferência pessoal, mas a vasta maioria de código em C, assim como os padrões C, são escritos usando o estilo do lado direito. Isto é claramente o padrão, e a maneira mais correta de escrever apontadores, então minha escolha pode parecer estranha.

Escolhi a versão no lado esquerdo porque acredito que é mais fácil de ensinar a iniciantes. Ter o asterisco no lado esquieiro enfatiza o tipo. É mais claro de ler, e torna óbvio que o asterisco não é um operador ou modificação à variável. Com a omissão de arrays e declarações de múltiplas variáveis, esta notação é quase completamente consistente dentro deste livro, e quando não, é feita a distinção. Os próprios K&R admitiram a confusão da sintaxe no lado direito, tornada pior pela bagagem histórica e implementações trapaceiras de compiladores dos primeiros anos. Para um recurso de aprendizado, acredito que escolher a versão do lado esquerdo foi a melhor abordagem.

Uma vez confortável com o método por trás da sintaxe de declaração em C, encorajo programadores a migrar para a versão no lado direito.

Por que o parser da linguagem não é escrito à mão?


Muitas pessoas me dizem que usar uma biblioteca para a análise sintática é um grande desapontamento para elas, porque escrever um parser manualmente é uma parte divertida de construir uma linguagem. E para um Lisp é tão simples. Existem algumas razões por que não usei essa abordagem.

Primeiramente, quando eu estava aprendendo sobre linguagens de programação, achei a teoria das linguagens formais fascinante. Realmente gostei de entrar na mentalidade de pensar sobre linguagens de maneira mais abstrata. Acho que esse é um jeito divertido de ensinar, já que abre muitos novos pensamentos e avenidas de exploração. Na minha mente, os detalhes de implementação são menos importantes.

Esta abordagem também dá a novos programadores a chance de aprender como usar uma biblioteca. Deixa-os confortáveis desde o começo com interfaces estranhas e código de outras pessoas. Acho que bibliotecas combinadores de parsers são uma excelente propaganda para composição funcional efetiva. Então não pude deixar de colocar uma ligação desinibida para um pouco do meu próprio trabalho!

Se você está curioso sobre como bibliotecas Parser Combinator funcionam, confira meu artigo "You could have invented Parser Combinators".

Por que não há macros neste Lisp?


De longe, a maior reclamação que programadores Lisp convencionais têm com o Lisp neste livro é a falta de Macros. No lugar de Macros, um novo conceito de Q-Expressions é usado para avaliação atrasada. Para programadores Lisp convencionais, Q-Expressions são confusas porque sua semântica diferencia sutilmente da macro quote.

Uso Q-Expressions no lugar de Macros por alguns motivos.

Em primeiro lugar, acredito que elas sejam mais fáceis para iniciantes do que macros. Quando a avaliação é atrasada, é sempre explícito, mostrado pela sintaxe, e nunca implicitamente no nome da função. Também significa que S-Expressions nunca podem ser devolvidas pelo prompt ou vistas por aí. Elas são sempre avaliadas.

Segundo, é mais consistente. Não mais requer o conceito de macros, mas em seu lugar transforma expressões citadas no conceito dominante, mais poderoso, que faz tudo que é necessário por qualquer uma. Com Q-Expressions há apenas Funções e Expressões, e a linguagem é ainda mais homoicônica que antes.

Finalmente, Q-Expressions são distintamente mais poderosas que Macros. Usando Q-Expressions é possível passar um argumento a uma função que avalia uma Q-Expression, tornando os argumentos da entrada possíveis de serem dinâmicos. Em Lisps convencionais, passar uma expressão para uma macro sempre pausa a avaliação, e então os argumentos não podem ser dinâmicos, apenas simbólicos.

Onde estão as respostas aos exercícios?


Não há nenhuma. No mundo real, ninguém vai lhe passar um panfleto com as respostas, ou checar o seu trabalho por você. Certificar-se que seu código faz o que você pretendia é uma habilidade essencial a se aprender. Alguns leitores pediram pelas respostas porque estavam preocupadas que poderiam não ter feito a coisa certa. Mas verificar a coisa certa neste caso é apenas testar o entendimento da pergunta; um exercício inútil. Adicionalmente, não há sempre uma maneira certa ou errada de abordar as Metas Bônus. Elas são destinadas como sugestões para ajudar pessoas a verificar seu entendimento, ou explorar outras ideias e pensamentos.

Se você quer fazer uma Meta Bônus e não tem certeza do que significa, fique à vontade para me mandar um e-mail e tentarei clarificá-la! Caso contrário, não se inquiete com a resposta. Tentar é a parte importante, não fazer certo!

• Conteúdo •