As linguagens de programação devem ser estritas ou frouxas? [fechadas]

14

Em Python e JavaScript, os pontos e vírgulas são opcionais.

No PHP, aspas em torno de chaves de array são opcionais ( $_GET[key] vs $_GET['key'] ), embora se você omiti-las, ele primeiro procurará uma constante com esse nome. Também permite 2 estilos diferentes para blocos (delimitados por dois pontos ou cinta).

Estou criando uma linguagem de programação agora, e estou tentando decidir o quão estrito devo fazê-lo. Há muitos casos em que caracteres extras não são realmente necessários e podem ser interpretados sem ambigüidade devido a prioridades, mas eu estou pensando se devo ainda aplicá-los ou não para incentivar a consistência.

O que você acha?

Ok, minha linguagem não é tanto uma linguagem de programação quanto uma linguagem de modelos extravagante. Uma espécie de cruzamento entre Haml e templates do Django . Significa ser usado com a estrutura da Web do C # e deve ser muito extensível.

    
por mpen 19.02.2011 / 08:54
fonte

11 respostas

19

Diferentes tipos de linguagens têm usos diferentes, então a resposta para essa pergunta realmente depende de como você a usará.

Por exemplo, o Perl é uma linguagem muito solta, e eu acho muito útil escrever scripts de correção rápida ou processamento de números. Para projetos robustos e sólidos, uso o C #.

Você precisa obter o equilíbrio certo para o uso do destino. Quanto mais estrito for, mais tempo você precisará para escrever o código, mas terá maior robustez, reutilização e manutenção mais fácil.

    
por 19.02.2011 / 09:02
fonte
26

O que eu procuro em uma linguagem de programação (em oposição a uma linguagem de script) é consistência e digitação strong.

Nas linguagens de programação atuais, é possível omitir o ponto-e-vírgula, por exemplo, em determinados locais, sem se tornar ambíguo (a última expressão em um bloco {} é um). Se uma linguagem de programação permite omitir caracteres nesses casos, um programador agora tem um problema extra; no topo da sintaxe geral da linguagem, ela agora tem que saber em quais casos é permitido omitir partes da sintaxe também.

Esse conhecimento extra não é problema para o programador que está escrevendo o código, mas se torna um fardo para qualquer um que tenha que interpretar o código existente em um momento posterior (incluindo o autor original depois de um tempo).

Seu exemplo PHP abre a possibilidade de bugs sutis em um programa quando a constante key seria adicionada no mesmo contexto. O compilador não tem como saber que não é o que foi feito, então o problema só se torna aparente no tempo de execução em vez do tempo de compilação.

    
por 19.02.2011 / 10:02
fonte
11

Em todo lugar onde há alguma ambiguidade, o compilador precisa ter alguma maneira de adivinhar o que o programador realmente quis dizer. Toda vez que isso acontece, há a chance de que o programador realmente tenha significado algo diferente, mas não tenha a regra de resolução de ambiguidade.

Escrever código logicamente correto já é bastante difícil. Adicionar ambigüidades sintáticas pode parecer "amigável" na superfície, mas é um convite aberto para introduzir bugs novos, inesperados e difíceis de depurar na base de código. Bottom line, seja o mais rigoroso possível.

Do seu exemplo, você mencionou que os ponto-e-vírgulas são opcionais em Python e JavaScript. Para o Javascript, pelo menos, isso não é inteiramente verdade. Os pontos-e-vírgulas são tão necessários em JS quanto em qualquer outra linguagem da família C. Mas o analisador JavaScript é requerido pela especificação da linguagem para inserir ponto-e-vírgulas ausentes em determinadas circunstâncias. This is amplamente considerado uma coisa muito ruim porque tende a errar suas intenções e estragar seu código.

    
por 19.02.2011 / 16:04
fonte
6

A resposta para o quão solto você deve fazer a sua língua é igual à resposta da pergunta em um sotaque do Texas. "Quão sortudo você se sente, punk?".

    
por 19.02.2011 / 22:15
fonte
4

Todos não precisariam trabalhar tanto para codificar consistência se os idiomas não tivessem muita variação. Não gostamos quando os usuários fazem solicitações que aumentam desnecessariamente a complexidade, então, por que perguntar as nossas linguagens de desenvolvimento?

    
por 19.02.2011 / 15:27
fonte
2

Minha preferência pessoal é pela capacidade de ter rigor suficiente para pegar meus erros, mas com o mínimo de clichê possível. Eu falo sobre esse problema no link .

Dito isso, você está projetando seu idioma por conta própria. Você deve fazer com que seja o que você quer que seja.

    
por 19.02.2011 / 10:14
fonte
1

Eu gosto de meus idiomas para fazer o que quero dizer. Geralmente isso se inclina bastante para soltar. Eu também gostaria de poder marcar "strict" em um elemento ou bloco para poder depurar / analisar essa área limitada.

    
por 19.02.2011 / 19:21
fonte
1

Eu geralmente tendem a cair para o lado de "O que tornaria mais fácil para mim como programador". Claro que isso pode significar mais de uma coisa. Em Javascript não há quase nenhuma verificação de tipos, o que funciona muito bem até você acertar um bug estranho. Por outro lado, em Haskell há muita verificação de tipos, o que coloca mais trabalho na frente, mas prejudica algumas classes de erros.

Para ser honesto, eu gostaria de verificar um monte de idiomas para ver o que eles fazem e tentar encontrar um nicho que nenhum deles atingiu!

Eu não acho que exista uma maneira correta e óbvia de fazê-lo, ou pelo menos se há algo em que as pessoas ainda não encontraram um consenso. Então, ao criar linguagens com sistemas de tipos diferentes, estamos aprendendo.

Boa sorte.

    
por 19.02.2011 / 18:04
fonte
1

Eu sugeriria que uma boa linguagem de programação deveria ter regras estritas, implementações que deveriam ser implementadas consistentemente, mas as regras deveriam ser escritas de tal forma que fossem úteis. Eu sugeriria ainda que se deve considerar o design de uma linguagem para evitar casos em que a "distância de Hamming" entre dois programas substancialmente diferentes é apenas um. Obviamente, não se pode conseguir tal coisa com literais numéricos ou de string (se um programador que quis dizer 123, em vez disso, digitar 1223 ou 13, o compilador não pode muito bem saber o que o programa significava). Por outro lado, se a linguagem usar := para atribuição e == para comparação de igualdade, e não usar um único = para qualquer finalidade legal, reduziria muito as possibilidades tanto para atribuições acidentais que deveriam comparações e comparações acidentais de nada que deveriam ser atribuições.

Eu sugeriria que, embora existam lugares onde é útil para os compiladores inferirem coisas, tal inferência é freqüentemente mais valiosa nos casos mais simples, e menos valiosa nos casos mais complicados. Por exemplo, permitindo a substituição de:

  Dictionary<complicatedType1,complicatedType2> item =
    new Dictionary<complicatedType1, complicatedType2()>;

com

  var item = new Dictionary<complicatedType1, complicatedType2()>;

não requer nenhuma inferência de tipos complicada, mas torna o código muito mais legível (entre outras coisas, usando a sintaxe mais detalhada apenas em cenários em que é necessário, por exemplo, porque o tipo de local de armazenamento não corresponde exatamente ao tipo da expressão que o cria, ajudará a chamar atenção extra para lugares que possam exigir isso).

Uma grande dificuldade de se tentar uma inferência de tipos mais sofisticada é que situações ambíguas podem surgir; Eu sugeriria que uma boa linguagem deveria permitir que um programador incluísse informações que o compilador pudesse usar para resolver tais ambigüidades (por exemplo, considerando algumas tipologias como preferíveis a outras), determinar que elas não importam (por exemplo, mesmo que duas possíveis sobrecargas podem executar códigos diferentes, o programador indicou que eles devem se comportar de forma idêntica nos casos em que qualquer um poderia ser usado), ou sinalizar aqueles (e somente aqueles) que não podem ser manipulados de nenhuma das formas acima.

    
por 20.07.2012 / 18:29
fonte
1

Para mim, a legibilidade é muito importante.

Para alguém experiente com a linguagem, o significado de um fragmento de código deve ser claro sem ter que analisar profundamente o contexto.

O idioma deve ser capaz de sinalizar os erros sempre que possível. Se cada sequência aleatória de caracteres fizer um programa sintaticamente correto, isso não será útil. E se as variáveis forem criadas automaticamente na primeira vez em que forem usadas, o erro de digitação de client as cleint não resultará em erro de compilação.

Além da sintaxe, a linguagem deve ter uma semântica claramente definida, e talvez seja ainda mais difícil do que decidir sobre uma sintaxe decente ...

Bons exemplos:

  • Em Java, "1" é uma string, 1 é um int, 1.0 é um double e 1L é um longo. Um olhar e você sabe o que é.

  • Em Java, = é a atribuição. Atribui o valor para tipos primitivos e a referência para tipos de referência. Nunca copia dados complexos ou compara.

  • Em Java, chamar um método precisa de parênteses e desta forma é claramente distinguido de variáveis - assim, se não houver parênteses, você não precisa procurar por uma definição de método, é apenas ler dados.

Exemplos ruins:

  • Em Java, um símbolo como client pode ser praticamente qualquer coisa: um elemento de caminho de pacote, um nome de classe ou interface, um nome de classe interna, um nome de campo, um nome de método, uma variável local e até Mais. Cabe ao usuário apresentar ou obedecer às convenções de nomenclatura ou não.

  • Em Java, o ponto . é usado em excesso. Pode ser o separador dentro do nome do pacote, o separador entre o pacote e a classe, o separador entre a classe externa e a interna, o conector entre a expressão da instância e o método a ser invocado na instância e muito mais.

  • Em muitos idiomas, as chaves dos blocos if são opcionais, levando a erros desagradáveis se alguém adicionar mais uma instrução ao bloco (não realmente existente).

  • Operadores Infix: às vezes eu tenho que parar em uma expressão numérica e pensar no que isso significa, passo a passo. Estamos todos acostumados a escrever expressões matemáticas na notação infixada como a * b / c * d + e . Na maior parte do tempo, lembramos a precedência de multiplicação e divisão sobre adição e subtração (mas você percebeu que não estamos dividindo por c*d , mas dividindo apenas por c e depois multiplicando por d ?). Mas há tantos operadores adicionais com suas próprias regras de precedência e em algumas linguagens sobrecarregadas que é difícil acompanhar. Talvez reforçar o uso de parênteses tenha sido uma abordagem melhor ...

por 31.08.2017 / 19:11
fonte
-2

Você pode considerar uma analogia com a linguagem natural. Em e-mail, você é um nazista de gramática? Ou você está bem com alguns erros gramaticais, como infinitivos divididos, conjunções ausentes ou modificadores mal posicionados. A resposta se resume à preferência pessoal.

    
por 31.08.2017 / 16:32
fonte