Filosofia Orientadora
1. Linguagens de Programação para Pessoas
As linguagens de programação são a maneira como as pessoas se comunicam com os computadores. O computador ficará feliz em conversar em qualquer linguagem que não seja ambígua. 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 é evitar sobrecarregar nosso frágil cérebro humano com uma infinidade de detalhes.
Os arquitetos sabem que alguns problemas de design são mais palpáveis do que outros. Um dos problemas de design mais claros e abstratos é o projeto de pontes. Nesse caso, seu trabalho é cobrir a distância necessária com o menor material possível. No outro extremo do espectro está o design de cadeiras. Os projetistas de cadeiras precisam gastar seu tempo pensando sobre traseiros humanos.
O desenvolvimento de software tem uma distinção semelhante. Projetar algoritmos para roteamento de dados através de uma rede é um bom problema abstrato, assim como o design de pontes. Enquanto isso, projetar linguagens de programação é semelhante a projetar cadeiras: você precisa lidar com as fraquezas humanas.
Para a maioria de nós, é difícil perceber isso. Projetar sistemas matemáticos elegantes soa muito mais atraente para muitos de nós do que ceder às fraquezas humanas. O papel da elegância matemática é que um certo grau de elegância torna os programas mais fáceis de entender. Mas a elegância não é o único fator.
E quando digo que as linguagens devem ser projetadas levando em consideração as fraquezas humanas, não quero dizer que as linguagens devem ser projetadas para programadores ruins. Na verdade, você deve projetar o software para os melhores programadores, mas mesmo os melhores programadores têm seus limites. Eu não acho que alguém goste de programar em uma linguagem onde todas as variáveis são nomeadas pela letra 'x' com índices inteiros.
2. Projete para você e para seus amigos
Se você olhar para a história das linguagens de programação, a maioria das melhores linguagens foram projetadas para uso de seus próprios criadores, enquanto a maioria das piores foram feitas para outras pessoas.
Quando as linguagens são projetadas para outras pessoas, geralmente isso se refere a um grupo específico: as pessoas não são tão inteligentes quanto os criadores da linguagem. Assim, você obtém uma linguagem que conversa com você de uma forma condescendente. Cobol é o exemplo mais claro, mas a maioria das linguagens está impregnada desse espírito.
Isso não tem a ver com o quão de alto nível é a linguagem. C é uma linguagem de baixo nível, mas foi criada para ser utilizada por seus autores, e é por isso que os hackers a adoram.
O argumento a favor de projetar linguagens para programadores ruins é que há mais programadores ruins do que bons. Pode ser verdade. Mas esse pequeno número de bons programadores escreve desproporcionalmente mais software.
Estou interessado na questão de como criar uma linguagem que agrade aos melhores hackers. Parece que essa pergunta é idêntica à questão de como criar uma boa linguagem de programação?, mas mesmo que não seja, ainda assim é uma pergunta interessante.
3. Dê ao programador o máximo de controle possível
Muitas linguagens (especialmente aquelas criadas para outras pessoas) agem como babás: tentam avisá-lo sobre coisas que acham que não serão úteis para você. Eu defendo a opinião oposta: dê ao programador o máximo de controle que puder.
Quando eu comecei a estudar Lisp, o que mais gostei foi que conversamos como iguais. Em outras linguagens que eu já tinha estudado até aquele momento, havia a linguagem e meu programa naquela linguagem, e eles existiam de forma bastante separada. Mas em Lisp, as funções e macros que escrevi eram as mesmas nas quais a própria linguagem foi escrita. Eu poderia reescrever a própria linguagem, se quisesse. Tinha a mesma atração que o software de código aberto.
4. Brevidade é irmã do talento
A brevidade é subestimada e até desprezada. Mas se você olhar para os corações dos hackers, verá que eles amam muito a brevidade. Quantas vezes você ouviu hackers falarem com carinho sobre como, digamos, em APL, eles podem fazer coisas incríveis com apenas algumas linhas de código? Acredito que as pessoas realmente inteligentes prestam atenção nisso.
Acredito que quase tudo que torna os programas mais curtos é bom. Deve haver muitas funções de biblioteca; tudo que pode ser implícito deve ser assim; a sintaxe deve ser mais concisa; até os nomes das entidades devem ser curtos.
E não apenas os programas devem ser curtos. Manuais também devem ser curtos. Uma boa parte dos manuais está cheia de explicações, ressalvas, avisos e casos especiais. Se você precisar encurtar um manual, a melhor opção é consertar a linguagem que exige tantas explicações.
5. Reconheça o que é hacking
Muitas pessoas gostariam que hacking fosse matemática ou, pelo menos, algo parecido com as ciências naturais. Eu acho que hacking se assemelha mais à arquitetura. A arquitetura está relacionada à física, no sentido de que o arquiteto precisa projetar um edifício que não caia, mas o verdadeiro objetivo do arquiteto é criar um grande edifício, e não fazer descobertas no campo da estática.
O que os hackers adoram é criar grandes programas. E acho que, pelo menos em nossas próprias mentes, devemos lembrar que escrever programas notáveis é fantástico, mesmo quando esse trabalho não se traduz facilmente em moeda intelectual comum de publicações científicas. Do ponto de vista intelectual, é igualmente importante tanto desenvolver uma linguagem que os programadores amem quanto criar algo horrível, que materialize a ideia sobre a qual você pode publicar um artigo.
Problemas em aberto
1. Como organizar grandes bibliotecas?
As bibliotecas estão se tornando parte importante das linguagens de programação. Elas estão crescendo tanto que isso pode se tornar perigoso. Se leva mais tempo encontrar uma função em uma biblioteca que faz o que você precisa do que escrever essa função por conta própria, então todo o código não faz nada além de engordar seu manual. (Os manuais da Symbolics foram um exemplo disso.) Portanto, teremos que resolver o problema da organização das bibliotecas. Idealmente, projetá-las de forma que o programador possa adivinhar qual função da biblioteca seria adequada.
2. As pessoas realmente têm medo da sintaxe prefixada?
Esse é um problema aberto no sentido de que eu venho pensando sobre isso há vários anos e ainda não sei a resposta. A sintaxe prefixada me parece absolutamente natural, possivelmente exceto pelo uso na matemática. Mas pode ser que a maior parte da impopularidade dos Lisp seja simplesmente devido à sintaxe desconhecida... Deveríamos fazer algo a respeito, se isso for verdade, é outra questão.
3. O que você precisa para software de servidor?
Acredito que a maioria dos aplicativos que serão desenvolvidos nos próximos vinte anos serão aplicativos web, no sentido de que os programas estarão localizados no servidor e se comunicarão com você através do navegador web. E para escrever tais aplicativos, precisamos de novas soluções.
Uma dessas soluções é o suporte a uma nova maneira de lançar aplicativos de servidor. Em vez de um ou dois grandes lançamentos por ano, como o software de desktop, o software de servidor será lançado em uma série de pequenas mudanças. Você pode ter cinco ou dez lançamentos por dia. E todos sempre terão a versão mais recente.
Você sabe como projetar programas para que sejam sustentáveis? O software de servidor deve ser projetado para ser adaptável. Você deve ter a capacidade de alterá-lo facilmente, ou pelo menos entender o que constitui uma pequena alteração e o que é uma alteração significativa.
Outra coisa que pode ser útil no software de servidor é, subitamente, a continuidade da entrega. Em um aplicativo web, você pode usar algo como , para obter o efeito de subprogramas em um mundo sem estado de sessões web. Pode valer a pena ter continuidade na entrega, se essa possibilidade não for muito cara.
4. Quais novas abstrações ainda precisam ser descobertas?
Não estou certo da racionalidade dessa esperança, mas pessoalmente, eu gostaria muito de abrir uma nova abstração — algo que pudesse ter um significado tão grande quanto funções de primeira classe ou recursão, ou pelo menos parâmetros padrão. Pode ser um sonho impossível. Essas coisas muitas vezes não se revelam. Mas eu não perco a esperança.
Segredos pouco conhecidos
1. Você pode usar qualquer linguagem que desejar
Antes, a criação de aplicativos significava desenvolver software de desktop. E no software de desktop, há uma grande tendência de escrever aplicativos na mesma linguagem que o sistema operacional. Assim, há dez anos, escrever software significava, em geral, escrever software em C. Afinal, a tradição evoluiu: os aplicativos não precisam ser escritos em linguagens exóticas. E essa tradição se desenvolveu tanto que até pessoas não técnicas, como gerentes e investidores de risco, aprenderam disso.
O software de servidor destrói completamente esse modelo. Com o software de servidor, você pode escolher qualquer linguagem que desejar. Quase ninguém ainda compreende isso (especialmente gerentes e investidores de risco). Mas alguns hackers entendem, é por isso que ouvimos sobre linguagens indies como Perl e Python. Não ouvimos sobre Perl e Python porque as pessoas as usam para escrever aplicativos para Windows.
O que isso significa para nós, que estamos interessados em projetar linguagens de programação, é que há um público potencial para o nosso trabalho.
2. A velocidade vem de profilers
Desenvolvedores de linguagem ou, pelo menos, seus implementadores amam escrever compiladores que geram código rápido. Mas eu penso que não é isso que torna as linguagens rápidas para os usuários. Knuth observou há muito tempo que a velocidade depende de apenas alguns gargalos. E qualquer um que tentou acelerar um programa sabe que você não consegue adivinhar onde está o gargalo. O profiler é a resposta.
Os desenvolvedores da linguagem não estão resolvendo o problema certo. Os usuários não precisam que os benchmarks sejam rápidos. Eles precisam de uma linguagem que possa mostrar quais partes de seu programa devem ser reescritas. Nesse momento, a velocidade é necessária na prática. Assim, talvez seja melhor se os implementadores da linguagem gastassem metade do tempo que passam otimizando o compilador, investindo esse tempo na criação de um bom profiler.
3. Você precisa de um aplicativo que faça sua linguagem evoluir
Pode não ser a verdade absoluta, mas parece que as melhores linguagens evoluíram junto com os aplicativos nos quais foram usadas. O C foi escrito por pessoas que precisavam de programação de sistemas. O Lisp foi desenvolvido em parte para diferenciação simbólica; McCarthy estava tão ansioso para começar que começou a escrever programas de diferenciação já no primeiro documento sobre Lisp em 1960.
Isso é especialmente bom se seu aplicativo resolver alguns novos problemas. Isso empurra sua linguagem a ter novas funcionalidades que os programadores precisam. Pessoalmente, estou interessado em escrever uma linguagem que seja boa para aplicativos de servidor.
[Durante a discussão, Guy Steele também expressou esse pensamento, acrescentando que um aplicativo não deve consistir em escrever um compilador para sua linguagem, a menos que sua linguagem seja destinada à escrita de compiladores.]
4. A linguagem deve ser adequada para escrever programas descartáveis.
Você sabe o que significa um programa descartável: é quando você precisa resolver rapidamente uma tarefa limitada. Acredito que, se você olhar ao seu redor, encontrará muitos programas sérios que começaram como descartáveis. Não ficarei surpreso se a maioria dos programas tiver começado como descartáveis. Assim, se você deseja criar uma linguagem que seja adequada para escrever software em geral, ela também deve ser adequada para escrever programas descartáveis, pois essa é a fase inicial de muitos programas.
5. A sintaxe está relacionada à semântica
Tradicionalmente, acredita-se que sintaxe e semântica são coisas bastante diferentes. Pode parecer chocante, mas não é. Eu acho que o que você deseja obter em seu programa está relacionado à forma como você expressa isso.
Recentemente conversei com Robert Morris, e ele observou que a sobrecarga de operadores é uma grande vantagem para linguagens com sintaxe infixa. Em linguagens com sintaxe prefixada, qualquer função que você define é, na verdade, um operador. Se você quiser somar um novo tipo de número que inventou, pode simplesmente definir uma nova função para adicioná-lo. Se fizer isso em uma linguagem com sintaxe infixa, perceberá que há uma grande diferença entre usar um operador sobrecarregado e chamar uma função.
Ideias que retornam com o tempo
1. Novas linguagens de programação
Olhando para trás nos anos 1970, era na moda desenvolver novas linguagens de programação. Agora não está mais assim. Mas eu acredito que o software de servidor trará de volta a moda de criar novas linguagens. Com o software de servidor, você pode usar qualquer linguagem que desejar; portanto, se alguém criar uma linguagem que pareça melhor que as demais, haverá pessoas dispostas a usá-la.
2. Compartilhamento de tempo
Richard Kelsey trouxe essa ideia, que está de volta à moda, e eu a apoio totalmente. Minha suposição (e da Microsoft também) é que muitas computações se moverão de desktops para servidores remotos. Em outras palavras, o compartilhamento de tempo voltou. Eu acho que será necessário suporte para isso ao nível da linguagem. Por exemplo, Richard e Jonathan Rees fizeram muito trabalho para implementar o agendamento de processos no Scheme 48.
3. Eficiência
Recentemente parecia que os computadores já eram rápidos o suficiente. Cada vez mais ouvimos sobre bytecode, o que, pelo menos para mim, significa que temos potência em reserva. Mas eu acho que com o software de servidor, não a temos. Alguém terá que pagar por servidores, em que o software opera, e o número de usuários que o servidor pode suportar por máquina será um divisor de seus custos de capital.
Acredito que a eficiência será importante, pelo menos nos gargalos de computação. Isso será especialmente relevante para operações de entrada e saída, pois aplicações de servidor geram muitas dessas operações.
No final, pode acontecer que o bytecode não seja a solução. A Sun e a Microsoft parecem estar em uma batalha cara a cara no campo do bytecode neste momento. Mas eles estão fazendo isso porque o bytecode é um local conveniente para se embutir no processo, não porque o bytecode em si é uma boa ideia. Pode ser que toda essa batalha passe despercebida. Seria engraçado.
Armadilhas e pegadinhas
1. Clientes
É apenas uma suposição, mas é que só os aplicativos que forem totalmente baseados em servidor sairão vitoriosos. Projetar software que funcione sob a suposição de que todos terão seu cliente é como criar uma sociedade baseada na suposição de que todos serão honestos. Isso certamente seria conveniente, mas você terá que admitir que isso nunca acontecerá.
Acredito que haverá um aumento rápido de dispositivos com acesso à web, e pode-se supor que eles suportarão HTML básico e formulários. Você tem um navegador em seu telefone? O telefone estará no seu PalmPilot? Seu Blackberry terá uma tela maior? Você conseguirá acessar a internet pelo seu gameboy? Pelos seus relógios? Não sei. E não precisarei descobrir isso se apostar que tudo estará no servidor. É simplesmente muito mais confiável ter toda a inteligência no servidor.
2. Programação Orientada a Objetos
Entendo que isso é uma afirmação controversa, mas não considero que a POO seja algo importante. Acredito que é uma paradigma adequado para aplicações específicas que precisam de estruturas de dados específicas, como sistemas de janelas, simulações, sistemas CAD. Mas não entendo por que deveria ser adequada para todos os programas.
Acho que as pessoas em grandes empresas gostam da POO, em parte, porque ela oferece muito do que parece ser trabalho. O que naturalmente poderia ser representado como, digamos, uma lista de números inteiros, agora pode ser representado como uma classe com todo tipo de andaime, com barulho e agitação.
Outro aspecto atraente da POO é que os métodos oferecem a você um certo efeito de funções de primeira classe. Mas isso não é novidade para programadores de Lisp. Quando você tem funções de primeira classe reais, pode simplesmente usá-las de qualquer maneira que atenda à tarefa em questão, em vez de empurrar tudo para um modelo de classes e métodos.
Acredito que isso significa para o design linguístico que você não deve integrar OOP de forma muito profunda. Talvez a resposta esteja em oferecer coisas mais gerais, fundamentais, e permitir que as pessoas projetem quaisquer sistemas de objetos como bibliotecas.
3. Projeto pelo comitê
Se a sua linguagem é projetada por um comitê, você está em apuros, e não apenas pelos motivos já conhecidos. É sabido que comitês tendem a criar um design de linguagem confuso e inconsistente. Mas eu acredito que o maior perigo é que eles não assumem riscos. Quando há uma única pessoa à frente, essa pessoa assume riscos que um comitê nunca concordaria em correr.
É preciso arriscar para criar uma boa linguagem? Muitas pessoas podem suspeitar que o design de linguagem é algo onde você deve se manter bem próximo da sabedoria tradicional. Eu apostaria que não é assim. Em tudo o que as pessoas fazem, a recompensa é proporcional ao risco. Então, por que o design de linguagens deveria ser diferente?
Fonte: habr.com
