Filosofia orientadora
1. Linguagens de programação para pessoas
Linguagens de programação são como as pessoas falam com computadores. O computador terá prazer em falar qualquer idioma que não seja ambíguo. A razão pela qual temos linguagens de alto nível é porque as pessoas não conseguem lidar com a linguagem de máquina. A essência das linguagens de programação é impedir que nosso pobre e frágil cérebro humano seja sobrecarregado com uma grande quantidade de detalhes.
Os arquitetos sabem que alguns problemas de design são mais comuns do que outros. Um dos problemas de design mais claros e abstratos é o design de pontes. Nesse caso, seu trabalho é cobrir a distância necessária com o mínimo de material possível. No outro extremo do espectro está o design de cadeiras. Os projetistas de cadeiras devem gastar seu tempo pensando em jumentos humanos.
O desenvolvimento de software tem uma diferença semelhante. Projetar algoritmos para rotear dados através de uma rede é um problema abstrato e bom, como projetar pontes. Considerando que projetar linguagens de programação é como projetar cadeiras: você precisa lidar com as fraquezas humanas.
Muitos de nós têm dificuldade em perceber isso. Projetar sistemas matemáticos elegantes parece muito mais atraente para a maioria de nós do que ceder às fraquezas humanas. O papel da elegância matemática é que algum grau de elegância facilita a compreensão dos programas. Mas nem tudo se limita à elegância.
E quando digo que as linguagens devem ser projetadas para levar em consideração as fraquezas humanas, não quero dizer que as linguagens devam ser projetadas para programadores ruins. De fato, você deve projetar software para os melhores programadores, mas mesmo os melhores programadores têm seus limites. Não acho que pelo menos alguém goste de programar em um idioma em que todas as variáveis sejam indicadas pela letra "x" com índices inteiros.
2. Projete para você e seus amigos
Se você observar o histórico das linguagens de programação, a maioria das melhores linguagens foi projetada para uso por seus próprios autores, e a pior das quais foi projetada para outras pessoas.
Quando os idiomas são projetados para outras pessoas, é sempre um grupo específico de pessoas: as pessoas não são tão inteligentes quanto os criadores da linguagem. Então você obtém um idioma que fala com condescendência com você. Cobol é o exemplo mais claro, mas a maioria das línguas está imbuída desse espírito.
Isso não tem nada a ver com o quão alto é o idioma. C é de nível bastante baixo, mas foi criado para ser usado por seus autores, e é por isso que os hackers adoram.
O argumento para projetar linguagens para programadores ruins é que existem mais programadores ruins do que bons. Talvez seja assim. Mas esse pequeno número de bons programadores escreve desproporcionalmente mais software.
Estou interessado na questão de como criar uma linguagem que os melhores hackers gostem. Parece-me que essa pergunta é idêntica à de como criar uma boa linguagem de programação ?, mas, mesmo que não seja, pelo menos é uma questão interessante.
3. Dê ao programador o máximo controle possível
Muitos idiomas (especialmente aqueles criados para outras pessoas) se comportam como babás: eles tentam alertá-lo sobre coisas que, na opinião deles, não lhe serão úteis. Eu tenho a opinião oposta: dê ao programador o máximo de controle possível.
Quando estudei o Lisp, o que mais gostei foi o fato de termos conversado em termos iguais. Em outros idiomas que eu havia estudado na época, havia um idioma, e havia o meu programa nesse idioma, e eles existiam separadamente. Mas no Lisp, as funções e macros que escrevi eram as mesmas em que a própria linguagem foi escrita. Eu poderia reescrever o próprio idioma, se quisesse. Ele tinha o mesmo apelo que o software de código aberto.
4. Brevidade - a irmã do talento
A brevidade é subestimada e até desprezada. Mas se você olhar para o coração dos hackers, verá que eles amam muito a brevidade. Quantas vezes você já ouviu hackers dizer carinhosamente que, digamos, no APL, eles podem fazer coisas incríveis com apenas algumas linhas de código? Acredito que pessoas realmente inteligentes realmente gostam de prestar atenção nisso.
Acredito que quase tudo o que torna os programas mais curtos é bom. Deveria haver muitas funções de biblioteca, tudo o que pode estar implícito - deveria ser assim; a sintaxe deve ser mais concisa; até nomes de entidades devem ser curtos.
E não apenas os programas devem ser curtos. Os manuais também devem ser breves. Boa parte dos manuais está repleta de explicações, isenções de responsabilidade, avisos e casos especiais. Se você precisar encurtar o manual, a melhor opção é corrigir o idioma, o que exige muitas explicações.
5. Reconheça o que é hacking.
Muitas pessoas gostariam que o hacking fosse matemática, ou pelo menos algo semelhante às ciências naturais. Eu acho que hacking é mais como arquitetura. A arquitetura está conectada à física, no sentido de que o arquiteto precisa projetar um edifício que não caia, mas o objetivo real do arquiteto é criar um ótimo edifício, e não fazer descobertas no campo da estática.
O que os hackers adoram é criar ótimos programas. E acho que, pelo menos em nossos próprios pensamentos, devemos lembrar que escrever programas maravilhosos é maravilhoso, mesmo quando esse trabalho não é facilmente traduzido na moeda intelectual comum dos trabalhos científicos. Do ponto de vista intelectual, é igualmente importante como desenvolver uma linguagem que os programadores adorem e criar uma linguagem terrível que incorpore a idéia sobre a qual você pode publicar um artigo.
Questões em aberto
1. Como organizar grandes bibliotecas?
As bibliotecas estão se tornando uma parte importante das linguagens de programação. Eles se tornam tão grandes que podem ser perigosos. Se demorar mais tempo para encontrar na biblioteca uma função que faça o que você precisa, do que escrever você mesma, todo o código não fará nada além de engrossar o manual. (Os manuais simbólicos foram um exemplo.) Portanto, temos que resolver o problema de organizar bibliotecas. Idealmente, projete-os para que o programador possa adivinhar qual função da biblioteca é adequada.
2. As pessoas estão realmente assustadas com a sintaxe do prefixo?
Esse é um problema em aberto, no sentido em que penso nisso há vários anos e ainda não sei a resposta. A sintaxe do prefixo parece completamente natural para mim, possivelmente além de usá-la em matemática. Mas pode ser que a maior parte da impopularidade de Lisp se deva simplesmente a uma sintaxe desconhecida ... Há algo a ver com isso, se é verdade, essa é outra questão.
3. O que você precisa para o software de servidor?
Eu acho que a maioria dos aplicativos que serão escritos nos próximos vinte anos serão aplicativos da Web, no sentido de que os programas estarão localizados no servidor e se comunicarão com você por meio de um navegador da Web. E para escrever tais aplicativos, precisamos de coisas novas.
Uma dessas coisas é oferecer suporte a uma nova maneira de liberar aplicativos de servidor. Em vez de um ou dois lançamentos importantes por ano, como o software para desktop, o software para servidor será lançado em uma série de pequenas alterações. Você pode ter cinco ou dez lançamentos por dia. E todo mundo sempre terá a versão mais recente.
Você sabe como criar programas a serem suportados? O software do servidor deve ser projetado para ser adaptável. Você deve poder alterá-lo facilmente, ou pelo menos saber o que significa uma mudança menor e o que é importante.
Outra coisa que pode ser útil no software de servidor é, de repente, a continuidade da entrega. Em um aplicativo Web, você pode usar algo como o
CPS para obter o efeito de rotinas no mundo sem estado das sessões da Web. Pode ter continuidade da entrega vale a pena se esta oportunidade não for muito cara.
4. Que novas abstrações são deixadas para abrir?
Não tenho certeza de quão razoável é essa esperança, mas pessoalmente gostaria de descobrir uma nova abstração - algo que pode ser tão importante quanto as funções de primeira classe ou a recursão, ou pelo menos os parâmetros padrão. Talvez este seja um sonho impossível. Tais coisas geralmente não se abrem. Mas eu não perco a esperança.
Segredos pouco conhecidos
1. Você pode usar qualquer idioma que quiser
Anteriormente, a criação de aplicativos significava a criação de software para desktop. E no software de desktop há uma grande tendência para escrever aplicativos no mesmo idioma do sistema operacional. Então, dez anos atrás, escrever software como um todo significava escrever software em C. No final, a tradição evoluiu: os aplicativos não devem ser escritos em linguagens incomuns. E essa tradição vem se desenvolvendo há tanto tempo que pessoas não técnicas, como gerentes e capitalistas de risco, também aprenderam isso.
O software de servidor destrói esse modelo completamente. Com o software de servidor, você pode usar o idioma que desejar. Quase ninguém mais entende isso (especialmente gerentes e capitalistas de risco). Mas alguns hackers entendem isso, e é por isso que ouvimos falar de linguagens indy como Perl e Python. Não ouvimos falar em Perl e Python porque as pessoas os usam para escrever aplicativos do Windows.
O que isso significa para nós, pessoas interessadas em projetar linguagens de programação, que existe um público potencial para o nosso trabalho.
2. Velocidade vem de perfis
Os desenvolvedores de idiomas, ou pelo menos seus implementadores, adoram escrever compiladores que geram código rápido. Mas acho que não é isso que torna os idiomas mais rápidos para os usuários. Knut há muito tempo percebe que a velocidade depende de apenas alguns gargalos. E quem tentou acelerar o programa sabe que você não consegue adivinhar onde está o gargalo. O criador de perfil é a resposta.
Os desenvolvedores de idiomas estão resolvendo o problema errado. Os usuários não precisam de benchmarks para trabalhar rapidamente. Eles precisam de um idioma que mostre quais partes do programa devem ser reescritas. Neste ponto, a velocidade é necessária na prática. Portanto, pode ser melhor se os implementadores de linguagem gastarem metade do tempo gasto otimizando o compilador e gastando escrevendo um bom gerador de perfil.
3. Você precisa de um aplicativo que faça seu idioma se desenvolver
Talvez essa não seja a verdade última, mas parece que as melhores linguagens foram desenvolvidas junto com os aplicativos em que foram usadas. C foi escrito por pessoas que precisavam de programação do sistema. Lisp foi projetado em parte para diferenciação simbólica; McCarthy estava tão ansioso para começar que começou a escrever programas de diferenciação mesmo no primeiro documento Lisp em 1960.
Isso é especialmente bom se o seu aplicativo resolver alguns novos problemas. Isso incentiva seu idioma a ter novos recursos que os programadores precisam. Pessoalmente, estou interessado em escrever um idioma que seja bom para aplicativos de servidor.
[Durante a discussão, Guy Steele também expressou essa idéia, acrescentando que o aplicativo não deve consistir em escrever um compilador para o seu idioma, a menos que seu idioma seja destinado a escrever compiladores.]
4. O idioma deve ser adequado para escrever programas únicos.Você sabe o que significa um programa único: é quando você precisa resolver rapidamente algum problema limitado. Acredito que, se você olhar em volta, encontrará muitos programas sérios que começaram como programas únicos. Eu não ficaria surpreso se a maioria dos programas fosse iniciada de uma só vez. Portanto, se você deseja criar uma linguagem adequada para a criação de software em geral, ela deve ser adequada para a criação de programas únicos, pois esse é o estágio inicial de muitos programas.
5. Sintaxe relacionada à semântica
Tradicionalmente, acredita-se que sintaxe e semântica são coisas muito diferentes. Pode parecer chocante, mas não é. Eu acho que o que você deseja obter no seu programa está relacionado à forma como você o expressa.
Falei recentemente com Robert Morris e ele percebeu que a sobrecarga de operadores é uma grande vantagem nas linguagens vencedoras com sintaxe de infix. Em idiomas com sintaxe de prefixo, qualquer função que você definir é realmente um operador. Se você deseja adicionar o novo tipo de número que você criou, basta definir uma nova função para adicioná-lo. Se você fizer isso em um idioma com sintaxe de infixo, verá que há uma grande diferença entre usar um operador sobrecarregado e chamar uma função.
Ideias que voltam com o tempo
1. Novas linguagens de programação
Olhando para os anos 70, estava na moda o desenvolvimento de novas linguagens de programação. Agora isso não é verdade. Mas acredito que o software de servidor retornará novamente a moda para a criação de novos idiomas. Com o software de servidor, você pode usar qualquer idioma que desejar, portanto, se alguém criar um idioma que pareça melhor que o resto, haverá pessoas que decidirão usá-lo.
2. Partilha de tempo
Richard Kelsey apresentou essa idéia, cuja hora chegou novamente, e eu a apoio totalmente. Meu palpite (e a Microsoft também) é que muitos cálculos passarão da área de trabalho para os servidores remotos. Em outras palavras, a divisão do tempo voltou. Eu acho que você precisará de suporte no nível do idioma. Por exemplo, Richard e Jonathan Reeves fizeram muito trabalho para implementar o planejamento de processos no Esquema 48.
3. Eficiência
Recentemente, parecia que os computadores já eram bastante rápidos. Cada vez mais ouvimos falar do bytecode, o que pelo menos para mim significa que temos o poder em estoque. Mas acho que com o software para servidor, não o temos. Alguém terá que pagar pelos servidores que executam o software, e o número de usuários que o servidor pode suportar por máquina será um divisor de seus custos de capital.
Eu acho que a eficiência será importante, pelo menos nos gargalos da computação. Isso será especialmente importante para operações de E / S, porque os aplicativos de servidor executam muitas dessas operações.
No final, pode acontecer que o bytecode não seja uma opção. Sun e Microsoft atualmente parecem estar lutando cara a cara no campo de bytecode. Mas eles fazem isso porque o bytecode é um local conveniente para se incorporar no processo, e não porque o bytecode sozinho é uma boa idéia. Pode acontecer que toda essa batalha passe despercebida. Seria engraçado.
Armadilhas e armadilhas
1. Clientes
Isso é apenas uma suposição, mas é que apenas os aplicativos que serão totalmente do lado do servidor serão beneficiados. Projetar software que funcione no pressuposto de que todos terão seu cliente é como criar uma sociedade baseada no pressuposto de que todos serão honestos. Definitivamente seria conveniente, mas você deve assumir que isso nunca acontecerá.
Acho que haverá um rápido aumento de dispositivos com acesso à Web, e podemos assumir que eles oferecerão suporte a html e formulários básicos. Você tem um navegador no seu telefone? Haverá um telefone no seu PalmPilot? O seu blackberry terá uma tela maior? Você terá a oportunidade de ficar on-line no seu gameboy? Do seu relógio? Eu não sei E não preciso descobrir se aposto que tudo estará no servidor. É simplesmente muito mais confiável ter todos os cérebros no servidor. .
2. Programação Orientada a Objetos
Entendo que esta é uma afirmação controversa, mas não acho que POO seja algo importante. Eu acho que esse é um paradigma adequado para aplicativos específicos que precisam de estruturas de dados específicas, como sistemas de janelas, simulações, sistemas CAD. Mas não entendo por que deve ser adequado para todos os programas.
Eu acho que as pessoas nas grandes empresas amam o POO, em parte porque isso fornece muito do que parece ser trabalho. O que, é claro, pode ser representado como, digamos, uma lista de números inteiros, agora pode ser representado como uma classe com todos os tipos de andaimes, com barulho e agitação.
Outra característica atraente do OOP é que os métodos fornecem um certo efeito de funções de primeira classe. Mas isso não é novidade para os programadores do Lisp. Quando você tem funções reais da primeira classe, pode simplesmente usá-las da maneira que corresponder à tarefa, em vez de inserir tudo em um modelo, a partir de classes e métodos.
Eu acho que isso significa para o design da linguagem que você não deve incorporar o OOP muito profundamente nele. Talvez a resposta seja oferecer coisas mais gerais e fundamentais e permitir que as pessoas projetem qualquer sistema de objetos na forma de bibliotecas.
3. Design por comissão
Se o seu idioma estiver sendo elaborado por um comitê, você ficará preso, e não apenas por razões que todos conhecem. Todo mundo sabe que os comitês tendem a criar um design de linguagem irregular e inconsistente. Mas acho que o grande perigo é que eles não correm riscos. Quando uma pessoa está à frente, ela corre o risco de o comitê nunca concordar em assumir.
Devo correr riscos para criar uma boa linguagem? Muitas pessoas podem suspeitar que o design de um idioma é onde você deve ficar bem próximo da sabedoria tradicional. Aposto que não é. Em tudo o mais que as pessoas fazem, a recompensa é proporcional ao risco. Então, por que o design de idiomas deveria ser diferente?