Tutorial do Pony

Bem-vindo ao tutorial do Pony! Se estiver lendo isto, é provável que queira aprender o Pony. Isso é ótimo! Este tutorial ideal para pessoas que já têm alguma experiência de programação. Não importa realmente se conhece um pouco de Python, quem sabe um pouco de Ruby, se é um expert em JavaScript, Java, Scala, até C/C++, ou Haskell e OCaml. Desde que já tenha escrito algum código antes, tudo vai dar certo!

O que é o Pony, afinal?

Pony é uma linguagem de programação orientada a objeto, modelo de ator, capacidades - segura. É orientado aos objetos porque tem classes e objetos, como Python, Java, C++, e muitas outras linguagens.
É ator-modelo porque tem atores (semelhantes a Erlang, Elixir, ou Akka). Estes comportam-se como objetos, mas também podem executar código de forma assíncrona. Os atores tornam o Pony espantoso.

Quando dizemos que o Pony é seguro em termos de capacidades, referimos a algumas coisas:

  • É do tipo seguro. Escreve-se realmente seguro. Há uma prova matemática e tudo.
  • É seguro para a memória. Ok, isto vem com um cofre de tipo, mas ainda assim é interessante.
  • Não há ponteiros pendulares, não há buffer overruns, raios, a linguagem nem sequer tem o conceito de nulo!
  • É seguro à excepção. Não há excepções de tempo de execução. Todas as excepções têm uma semântica definida, e são sempre tratadas.
  • É livre de corridas de dados. O Pony não tem fechaduras ou operações atómicas ou algo do género. Em vez disso, o sistema de tipo assegura em tempo de compilação que o seu programa concorrente nunca poderá ter corridas de dados. Por isso, pode escrever código altamente concorrente e nunca o interpretar mal.
  • Está livre de bloqueios. Este é fácil, porque o Pony não tem qualquer tipo de bloqueio! Por isso, definitivamente não tem bloqueios, porque eles não existem.

Falaremos mais sobre capacidades - segurança, incluindo tanto as capacidades dos objectos como as capacidades de referência mais tarde.

A Filosofia do Pony: Fazer

No espírito de Richard Gabriel, a filosofia Pony não é nem "fazer do jeito certo", nem "pior é melhor". É "fazer".

  • Correção: A incorreção não é simplesmente permitida. É inútil tentar fazer as coisas se não se pode garantir que o resultado seja correto.
  • Desempenho: A velocidade do tempo de execução é mais importante do que tudo excepto a correção. Se o desempenho tiver de ser sacrificado pela correção, tente arranjar uma nova forma de fazer as coisas. Quanto mais rápido o programa conseguir fazer as coisas, melhor. Isto é mais importante do que tudo, exceto um resultado correto
  • Simplicidade: A simplicidade pode ser sacrificada pelo desempenho. É mais importante para a interface ser simples do que a implementação. Quanto mais rápido o programador conseguir fazer as coisas, melhor. Não há problema em tornar as coisas um pouco mais difíceis para o programador para melhorar o desempenho, mas é mais importante tornar as coisas mais fáceis para o programador do que tornar as coisas mais fáceis na linguagem/tempo de execução.
  • Consistência: A coerência pode ser sacrificada pela simplicidade ou desempenho. Não deixar que a consistência excessiva se interponha no modo de fazer as coisas.
  • Completude: É bom cobrir tantas coisas quanto possível, mas a integralidade pode ser sacrificada por qualquer outra coisa. É melhor fazer algumas coisas agora do que esperar até que tudo possa ser feito mais tarde.

Princípios orientadores

Ao longo da concepção e desenvolvimento da linguagem devem ser seguidos os seguintes princípios.

  • Utilizar a abordagem "get-stuff-done".
  • • Gramática simples. A linguagem deve ser trivial para ser analisada tanto para humanos como para computadores.
  • Sem código carregável. Tudo é conhecido do compilador.
  • Digitar totalmente seguro. Não há coerção "confie em mim, eu sei o que estou a fazer".
  • Totalmente seguro de memória. Não há "este número aleatório é realmente um ponteiro, honesto".
  • Não há falhas. Um programa que compila nunca deve falhar (embora possa ser pendurado ou fazer algo não intencional).

A abordagem "fazer as coisas" tem a mesma atitude em relação à correção e simplicidade que "a-coisa-certa", mas a mesma atitude em relação à consistência e completude que "pior-é-melhor". Também acrescenta o desempenho como um novo princípio, tratando-o como a segunda coisa mais importante (depois da correção).

  • Mensagens de erro sensatas. Sempre que possível, utilizar mensagens de erro simples para casos de erro específicos. É bom assumir que o programador conhece as definições das palavras no nosso léxico, mas evite o jargão de compilador ou outro jargão informático.
  • Sistema de construção inerente. Não são necessárias aplicações separadas para configurar ou construir. Procure reduzir bugs de programação comuns através da utilização de sintaxe restritiva. Fornecer uma forma única, limpa e clara de fazer as coisas em vez de satisfazer os preconceitos preferidos de todos os programadores.
  • Tornar as atualizações limpas. Não tente fundir novas funcionalidades com as que estão a substituir, se algo estiver partido, remova-o e substitua-o de uma só vez. Sempre que possível, providencie utilitários de reescrita para atualizar a fonte entre versões linguísticas.
  • Tempo de compilação razoável. Manter baixo o tempo de compilação é importante, mas menos importante do que o desempenho e correção do tempo de execução.
  • Permitir ao programador omitir algumas coisas do código (argumentos por defeito, tipo de inferência, etc.) é bom, mas deve ser sempre permitido especificar completamente.
  • Sem ambiguidade. O programador nunca deve ter de adivinhar o que o compilador vai fazer, ou vice-versa.

A complexidade do documento é necessária. Nem todas as características linguísticas têm de ser triviais para serem compreendidas, mas as características complexas devem ter explicações completas nos documentos para serem permitidas na linguagem.

As características linguísticas devem ser minimamente intrusivas quando não são utilizadas.

  • Semântica totalmente definida. A semântica de todas as características da linguagem tem de estar disponível nos documentos linguísticos padrão. Não é aceitável deixar o comportamento indefinido ou "dependente da implementação".
  • O acesso eficiente ao hardware deve estar disponível, mas isto não tem de permear toda a linguagem.

A biblioteca padrão deve ser implementada em Pony.

  • Interoperabilidade. Deve ser interoperável com outras linguagens, mas isto pode exigir uma camada de calço se forem utilizados tipos não primitivos.
  • Evitar a dor da biblioteca. A utilização de bibliotecas Pony de terceiros deve ser tão fácil quanto possível, sem surpresas. Isto inclui a escrita e distribuição de bibliotecas e a utilização de múltiplas versões de uma biblioteca num único programa.

O que precisa

Para começar, é necessário um editor de texto e o compilador de pónei. Ou se estiver numa plataforma não suportada ou não quiser instalar o compilador, pode utilizar o Pony's Playground.

  • Um editor de texto

    • Embora se possa escrever código usando qualquer editor, é bom usar um com algum suporte para a linguagem. Mantemos uma lista de editores que apoiam o Pony.

  • O compilador

    • O Pony é uma linguagem compilada, e não interpretada. Na realidade, vai ainda mais longe: Pony é uma linguagem compilada antecipadamente (AOT), em vez de uma linguagem compilada just-in-time (JIT).

    O que isto significa é que, uma vez construído o seu programa, pode executá-lo repetidamente sem precisar de um compilador ou de uma máquina virtual, ou de qualquer outra coisa. É um programa completo, tudo por si só.

    Mas também significa que precisa de construir o seu programa antes de poder executá-lo. Numa linguagem interpretada ou numa linguagem compilada JIT, tende-se a fazer coisas como esta para executar o seu programa:

    $ python helloworld.py

    Ou talvez coloque um shebang no seu programa (como #!/usr/bin/env python), depois chmod para definir a parte executável, e depois faça:
    $ ./helloworld.py.


    Quando se usa o Pony, não se faz nada disso!

Compilando o seu programa

Se estiver no mesmo diretório que o seu programa, pode simplesmente colocar: $ ponyc Isso diz ao compilador Pony que o seu diretório de trabalho atual contém o seu código fonte, e para o compilar. Se o seu código-fonte estiver noutra directoria, pode dizer ao ponyc onde está: $ ponyc path/to/my/code