A sintaxe realmente importa em uma linguagem de programação? [fechadas]

41

Um dos meus professores diz que "a sintaxe é a interface do usuário de uma linguagem de programação", linguagens como Ruby têm grande legibilidade e estão crescendo, mas vemos muitos programadores produtivos com C \ C ++, portanto, como programadores, isso realmente importa que a sintaxe deve ser aceitável?

Eu adoraria saber sua opinião sobre isso.

Isenção de responsabilidade: não estou tentando iniciar uma discussão. Eu pensei que este é um bom tópico de discussão.

Atualização: Este acaba sendo um bom tópico. Fico feliz que todos vocês estejam participando.

Saif al Harthi
fonte
16
Hmm, isso parece assumir que a sintaxe C / C ++ é ruim? Certamente alguns elementos dos modelos C ++ são feios, mas no que diz respeito às linguagens (historicamente), o C / C ++ ainda é muito, muito legível.
precisa
2
Bem, eu sei que muitos programadores que irão discordar sobre isso, principalmente a partir da comunidade Ruby, porém, é mais legível do que lisp, tanto quanto eu posso dizer :)
Saif al Harthi
9
Foi um curso teórico? Lembre-se: os professores geralmente são alguns dos piores programadores. Eles não têm idéia de como é lá fora, na natureza.
Job
2
A legibilidade está nos olhos de quem vê :).
MAK
8
Uma boa sintaxe não pode melhorar uma linguagem miserável. Mas a sintaxe miserável pode piorar uma boa linguagem;)
Dario

Respostas:

65

Sim. Se você estiver em dúvida, use APL , J ou Brainfuck , ou mesmo Lisp ou Forth puro e simples, e tente entender qualquer programa não inteiramente trivial. Em seguida, compare com, por exemplo, Python.

Em seguida, compare o mesmo Python (ou Ruby, ou mesmo C #) com coisas como Cobol ou VB6.

Não estou tentando dizer que a sintaxe peluda é ruim e a linguagem natural é boa em todas as circunstâncias. Mas a sintaxe óbvia faz uma enorme diferença. Em suma, tudo o que você pode escrever na linguagem de programação mais bonita, também pode escrever como um programa de máquina de Turing - mas você geralmente não quer, não é?

9000
fonte
26
Lisp é definitivamente compreensível.
Cbrandolino
65
+1 por incluir Lisp na lista de idiomas ilegíveis.
precisa saber é o seguinte
65
-1 para incluir o Lisp na lista de idiomas ilegíveis.
Paul Nathan
27
A programação em geral é ilegível para os não iniciados. Assim como a notação musical e as plantas baixas arquitetônicas. (= XY) é tão legível quanto X == Y, para alguém que sabe ler.
Paul Nathan
6
Eu adorava o APL e, a menos que o código fosse intencionalmente escrito para ofuscar (muito fácil de fazer), era bastante fácil de ler. O poder da sintaxe era que você podia programar algoritmos em 2 ou 3 linhas de código APL que exigiriam dezenas ou centenas de linhas de C, Fortran ou COBOL. A concisão e o poder de uma linguagem como APL é importante para esta discussão, porque tentar ler centenas de linhas de código de outra linguagem pode ser tão frustrante quanto decifrar elementos obscuros da APL.
Oosterwal
11

Na prática, acho que isso importa. A legibilidade já foi discutida acima. Outra questão pode ser quantas teclas são necessárias para expressar uma ideia / algotitmo? Outra questão é como é fácil para os erros de digitação ser difícil para o olho humano captar, e quanto dano eles podem causar.

Também achei útil em alguns contextos analisar e / ou gerar fragmentos de código por meio de outro programa de computador. A dificuldade de analisar o idioma e / ou gerar o código correto afeta diretamente quanto esforço é necessário para criar / manter essas ferramentas.

Omega Centauri
fonte
Ótima observação sobre erros de digitação fáceis de distinguir.
7
Mas, em teoria, não há diferença entre teoria e prática.
Job
10

Acredito que seu professor esteja se referindo ao açúcar sintático .

Açúcar sintático é um termo de ciência da computação que se refere à sintaxe em uma linguagem de programação projetada para facilitar a leitura ou a expressão, enquanto existem formas alternativas de expressá-las .

Então, o que seu professor está sugerindo é que qualquer código / sintaxe escrito em uma linguagem de programação pode ser expresso em outras linguagens da mesma maneira - ou mesmo na mesma linguagem.

Robert Martin, retirando do teorema da Programação Estruturada , abstraiu o que os programadores fazem fundamentalmente com as linguagens de programação em sua palestra no RailsConf 2010: Robert Martin (vídeo do YouTube, veja após 14 minutos, embora eu recomende a coisa toda):

  • Sequência (atribuição)
  • Seleção (se declarações)
  • Iteração (loops)

É o que todos os programadores fazem, de uma linguagem de programação para outra, apenas em uma sintaxe ou interface de usuário (UI) diferente. Acho que isso é o que seu professor estava falando, se ele está falando abstratamente sobre linguagens de programação.

Portanto, em essência , a sintaxe não importa . Mas se você quiser ser específico, obviamente algumas linguagens e sintaxes são mais adequadas para determinadas tarefas do que outras, nas quais você pode argumentar que a sintaxe é importante.

sunpech
fonte
Você chamaria C apenas de açúcar sintático para montador?
Goran Jovic
1
Eu gostaria. Mas eu afirmo que a sintaxe é importante. ;)
Lennart Regebro
2
"... Robert Martin abstraiu o que os programadores fazem fundamentalmente ..." Robert Martin? Robert Martin ?? Você pode realmente considerar este artigo: C. Böhm, G. Jacopini, "Diagramas de fluxo, máquinas de Turing e idiomas com apenas duas regras de formação", Comm. do ACM, 9 (5): 366-371, 1966. que geralmente é creditado como a fonte do 'Teorema do Programa Estruturado'. en.wikipedia.org/wiki/Structured_program_theorem
leed25d
@ lee25d Eu não quis creditar o tio Bob como o criador da abstração, mas como a fonte onde a ouvi recentemente (e vinculei a). Mas obrigado pelo link, atualizarei minha resposta para refletir seu link.
spong
O artigo da Wikipedia vinculado acima não entende bem a história do "teorema da programação estruturada". A ideia era anterior à Bohm & Jacopini. A contribuição de Bohm & Jacopini estava mostrando que era um teorema, não apenas uma conjectura, ou seja, eles forneciam uma prova formal rigorosa.
John R. Strohm
7

Sim e não.

Existem alguns aspectos diferentes da sintaxe.

  • legibilidade
  • expressividade
  • parsability

A legibilidade já foi mencionada.

Expressividade é um caso interessante. Vou usar a passagem de função como exemplo, porque é uma espécie de ponto de inflexão de dor semântica / sintática.

Vamos pegar C ++, por exemplo. Eu posso criar uma função de primeira ordem desta maneira:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

Esse idioma específico é comumente usado nos Elementos de Programação de Stepanov .

Por outro lado, posso imitá-lo no Common Lisp com algo como isto :

(defun myfunc() )

(defun run_func(fun)
  (fun))

Ou, em Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

Ou, em Python -

def myfunc():
    pass

def run_func(f):
    f()

Todos eles têm - essencialmente - o mesmo conteúdo semântico, embora o exemplo C ++ contenha alguns metadados de tipo. Qual idioma expressa a idéia de passar melhor uma função de ordem superior? Lisp comum mal faz uma variação sintática. O C ++ exige que uma classe seja criada apenas para 'transportar' a função. Perl é bastante direto em fazer algum nível de diferenciação. O mesmo acontece com o Python.

Qual abordagem melhor se adequa ao domínio do problema? Qual abordagem melhor pode expressar os pensamentos em sua cabeça com o mínimo de 'incompatibilidade de impedância'?

Parsability é - na minha opinião - um grande negócio. Em particular, refiro-me à capacidade do IDE de analisar e cortar a linguagem sem cometer erros. Reformatar é útil. Idiomas delimitados por token tendem a analisar bem - ruby ​​/ c / pascal, etc.

Considere, no entanto, que todos os tipos de sistemas foram criados com todos os idiomas sérios para resolver problemas do mundo real. Embora a sintaxe seja uma barreira para expressar algumas coisas, é uma barreira que pode ser contornada. Equivalência de Turing e tudo isso.

Paul Nathan
fonte
5

A sintaxe definitivamente importa, apesar de você perceber mais quando não é intuitiva e incentiva bugs. Por exemplo, a piada infame "último bug do mundo":

if (AlertCode = RED)
   {LaunchNukes();}
Mason Wheeler
fonte
2
+1: Interessante, nunca vi (ou reconheci) essa piada infame "último bug do mundo". Mas posso ver como, dependendo da sintaxe de uma linguagem (ou até mesmo da semântica), o resultado desse pseudocódigo pode ser qualquer coisa. Dado também o ângulo semântico, isso pode realmente ser atribuído ao caso clássico de falta de comunicação cultural.
Stephen Swensen
É por isso que você deve usar condicionais Yoda, ou seja, if(RED = AlertCode)nunca deve compilar porque RED é constante (ou deveria ser!)
Malfist
4
@ Malfist: E assim vemos que a sintaxe ruim leva a uma sintaxe ainda pior para compensar. Os condicionais Yoda são feios e difíceis de ler porque não são da maneira que as pessoas pensam do conceito associado. Meu argumento foi mais como "esse é (um dos muitos motivos) pelos quais você deve evitar a família C sempre que possível".
Mason Wheeler
1
Felizmente, esse código tem dois bugs. Claro, ele sempre entra no condicional, mas lá está apenas obtendo uma referência ao LaunchNukesprocedimento e nunca invocando-o. Crise evitada!
munificent
3
Depende do que REDé. Se for 0, LaunchNukes()nunca seria chamado.
dan04
5

A sintaxe importa, e posso dar dois exemplos de suporte: Dylan, que é um Lisp com uma sintaxe mais convencional, e Liskell, que é Haskell com sintaxe semelhante ao Lisp. Em cada caso, foi proposta uma variante da linguagem que tinha exatamente a mesma semântica, mas uma sintaxe radicalmente diferente.

No caso de Dylan, pensava-se que abandonar expressões s em favor de algo mais convencional ajudaria a atrair uma gama maior de programadores. Aconteceu que a sintaxe não era a única coisa que impedia os programadores de usar o Lisp.

No caso de Liskell, pensava-se que o uso de expressões s permitiria um uso mais fácil das macros. Acontece que as macros realmente não são necessárias em Haskell, portanto esse experimento também não funcionou.

Aqui está a coisa: se a sintaxe não importasse para ninguém, nenhum experimento teria sido tentado.

Larry Coleman
fonte
1
Dylan era muito pouco, muito tarde para outras línguas. O que tinha a seu favor não poderia compensar isso. Não podemos mais assumir que é uma falha de sintaxe do que uma falha na nomeação.
Macneil
@ Macneil: Você está certo sobre a coisa muito pouco, muito tarde. Soltar a sintaxe Lisp foi apenas a unha final no caixão. Não acho que tenha sido o principal motivo do fracasso de Dylan, mas não sei como redefinir a resposta para melhor refletir isso.
Larry Coleman
Interessante, eu não sabia que eles tinham a sintaxe Lisp em uma versão anterior ... Foi quando foi chamado Ralph? O Newton Message Pad originalmente tinha Dylan em sua essência. 15 anos depois, temos o iOS com o Objective-C no centro, a linguagem menor dos dois, IMHO.
quer
Não me lembro dos detalhes exatos sobre quando Dylan perdeu expressões s. Estou espreitando no comp.lang.lisp há muito tempo e lembre-se do tópico que aparece em uma de suas guerras periódicas entre parênteses.
Larry Coleman
Dylan é anterior ao Java, e eu não acho que houvesse muitos C ++ na época.
Tom Hawtin - tackline
3

A resposta pode estar na separação do que "importa" em fatores computacionais e humanos . Existem muitos fatores humanos na sintaxe:

  • Legibilidade
  • Sucinteness
  • Manutenção
  • Pedagogia
  • Prevenção de erros
  • Adequação para o objetivo - é uma linguagem REPL, uma linguagem de script ou uma linguagem de grandes sistemas?

No que diz respeito ao computador, o único problema de sintaxe é se há ou não ambiguidades que precisam ser resolvidas e quanto tempo leva para tokenizar / analisar o código na compilação / interpretação - e é apenas no caso dos últimos, onde a sobrecarga da análise é um problema significativo.

Talvez seja por isso que você sempre terá uma resposta "sim e não" a esta pergunta - porque há dois aspectos nela.

Rei Miyasaka
fonte
1

Sem sintaxe, não teríamos um "modelo" comum para comunicar, em nível humano, a intenção de um bloco de código. A sintaxe fornece uma estrutura comum a partir da qual os compiladores podem ser padronizados; métodos podem ser compartilhados; a manutenção pode ser simplificada.

IAbstract
fonte
Por que minha resposta foi rejeitada?
IAbstract
1

Acho que realmente importa é o acesso à API e a disponibilidade de funcionalidades de baixo nível (como controle e bloqueio de memória) quando necessário. A maioria dos outros idiomas vem com esses recursos incluídos. O problema é que, quando você precisa de funcionalidade adicional, geralmente precisa usar uma linguagem como C para implementá-la. E é complicado fazer uma interface C com o idioma que você está usando.

Para tudo, exceto desenvolvimento web (e matemática), descobri que C / C ++ ainda é a linguagem de um sistema operacional e de um aplicativo. É o que é suportado na maioria das vezes para o verdadeiro desenvolvimento de aplicativos multiencadeados, pré-formados e multiplataforma. E a sintaxe de C está bem. Apenas muito simples e relativamente detalhado. Sintaxe incrível realmente não importa muito. Disponibilidade de energia e API Todos precisamos interagir com o código de outras pessoas (que na maioria das vezes é escrito em C ou em seus derivados).

unixman83
fonte
Não tenho escrúpulos com C, mas a multidão de ML / Haskell provavelmente teria algo a dizer sobre a segmentação.
Rei Miyasaka
+1 para "acesso à API": acho que isso pode ser ainda mais importante que os recursos de idioma.
Giorgio
1

Sintaxe definitivamente importa. É extremamente valioso se a sintaxe do idioma for flexível o suficiente para permitir que você crie um idioma específico do domínio conveniente e legível para o seu aplicativo. Se você duvida, imagine imaginar problemas de álgebra em latim prosaico, como foi feito antes do século 18, ou imagine fazer cálculos sem a notação agora conhecida de Leibniz. Certamente, um texto de cálculo é ilegível para um iniciante, mas com a prática podemos usar o cálculo e a notação de Leibniz para resolver rapidamente uma classe de problemas que exigiam páginas de matemática com métodos clássicos. A programação é apenas mais um pouco de matemática. Uma notação conveniente, próxima ao domínio do problema, pode fazer uma enorme diferença na produtividade.

Kevin Cline
fonte
DSLs não são sobre açúcar de sintaxe. A semântica é uma parte muito mais valiosa. Não há problema em projetar eDSLs que não adicionem nada a uma sintaxe existente.
SK-logic
@ SK: claro, mas a semântica está sob o controle completo do programador. A sintaxe é restringida pelo idioma base. Podemos criar DSLs convenientes no Groovy e em outras linguagens, mas não tanto em Java.
kevin Cline
1

Aqui está um programa que calcula a faculdade de 6:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

A sintaxe é mínima:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

Parece haver uma crença comum de que a sintaxe é o que dificulta uma linguagem. Como tantas vezes acredita comumente, exatamente o oposto é verdadeiro.

Observe que a sintaxe LISP é legível apenas (se houver), pois possui muito mais sintaxe que a anterior. Portanto, se os fãs do LISP lhe disserem que "a sintaxe não importa", peça que eles sejam conseqüentes e tente o cálculo do SKI. Eles terão que admitir que uma sintaxe pouco não é tão ruim, afinal.

Ingo
fonte
Eu não consigo entender o voto negativo. Esta é uma resposta realmente perspicaz. +1
scravy
0

Eu não acho que isso importe além da preferência pessoal. Como todas as coisas (desempenho, capacidades, etc.) são iguais, entendo por que alguém colocaria maior peso em uma sintaxe de idioma, mas optando por ignorar o desempenho de idiomas como c / c ++ ou qualquer outro idioma mais adequado para o trabalho, simplesmente por causa de sintaxe pareceria uma má ideia ao redor.

Kurtis
fonte
6
Que tal "tempo de colocação no mercado", "custo para benefício" etc.?
Job
0

Sim, a sintaxe é importante, embora realmente apenas para facilitar a leitura. Comparar:

for i in range(10):
   print(i)

(Sim, isso é Python) com

FOR(i<-RNG-<10){PRN<-i}

(Sim, essa é uma linguagem que acabei de criar). Ambos fariam exatamente a mesma coisa, da mesma maneira, mas a sintaxe é diferente e o Python é mais fácil de ler. Então, sim, a sintaxe definitivamente importa. Até o "açúcar sintático" é importante.

 @property
 def year(self):
     return self._date.year

É mais fácil de ler do que

 def year(self):
     return self._date.year
 year = property(year)
Lennart Regebro
fonte
0

Sim, claro.

Se você deseja iniciar uma grande chama, pergunte ao pessoal, onde eles colocam o bracelete de abertura em idiomas do tipo C. Quero dizer

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

ou mesmo VS

void foo() 
{ // blah
}

E esta é apenas a mesma linguagem! Além disso, pergunte a eles sobre os espaços onde eles os colocam (nome da função e pulseira, operadores etc.).

1000 respostas garantidas!

ern0
fonte
eu não quero iniciar uma chama e até agora eu tenho boas respostas e agradeço a todos por participarem e por aumentarem meu conhecimento e aposto que outras pessoas acharam isso útil.
Saif al Harthi
0

Sintaxe importa. No entanto, hoje em dia, eu diria que isso importa quase inteiramente por causa da legibilidade e não realmente em termos da quantidade de pressionamentos de tecla necessários. Por quê?

  • A menos que você esteja realmente escrevendo algo tão simples, se o número de teclas pressionadas for o fator limitante na criação de um programa, você será realmente uma porcaria na digitação ou pensará muito rapidamente.
  • Atualmente, todos os IDEs decentes têm um grande número de atalhos, o que significa que você não precisa digitar todos os caracteres que está usando na maioria das vezes.

Dito isto, se for muito detalhado, pode chegar ao ponto em que afeta a legibilidade. Eu preferiria ver algo como:

foreach (String em stringList)

Para:

para cada String que está na lista, conforme referenciado pela variável stringlist

...qualquer dia!

berry120
fonte
0

A sintaxe é importante para quem está aprendendo, quanto menor a barreira de entrada, mais popular o idioma pode ser inicialmente. Mas se a linguagem é difícil ou impossível de se expressar rica e sucintamente, ela começará a murchar em popularidade.

Muito conciso e opaco (Perl) é tão ruim quanto excessivamente detalhado e prolixo (AppleScript).

É preciso haver equilíbrio, menor barreira à entrada, alta produtividade e fácil manutenção.

user7519
fonte
-2

Outra coisa a considerar é que as linguagens de programação com sintaxe mais agradável são mais fáceis de analisar, tornando o compilador mais fácil de escrever, mais rápido e menos propenso a erros.

asmeurer
fonte
3
Umm ... 10000 SLOC de parse.yRuby discordam. Há uma razão pela qual cada uma das 7 implementações Ruby prontas para produção, atual ou em breve, usa o mesmo analisador, e todas as implementações Ruby que já tentaram desenvolver seu próprio analisador falharam.
Jörg W Mittag
E havia a infame linguagem da ADA. Juntamente com as especificações de idioma, havia 100 programas que precisavam ser executados corretamente para certificar o compilador. Havia algumas coisas realmente sutis sobre a sintaxe. Para resumir uma longa história, TODOS os primeiros compiladores ADA construíram reprovados em alguns desses programas. E não era uma simples questão de consertar um bug, mas eles precisavam começar do zero. Embora tivesse um apoio maciço do governo (todos os contratos do DOD exigiam ADA), ele sofreu uma morte miserável.
Omega Centauri
-2

Simplificando: a sintaxe, como tal, não importa. A semântica que você pode expressar através dela é importante.

back2dos
fonte
5
Como exercício, escreva um analisador complexo em C e, em seguida, um driver de dispositivo em Haskell. A sintaxe ajudou? Em seguida, faça o contrário, preservando rigorosamente a semântica de ambos os programas. </irony>
9000
1
@ 9000: Vi alguns drivers de dispositivo em Haskell. Não via nada de particularmente errado com eles. Cuidado ao elaborar?
Jörg W Mittag
2
@ 9000, dada a dificuldade de obter os drivers de dispositivo corretos em C, não sei se você escolheu um bom exemplo.
1
@ 9000: Esse foi exatamente o meu ponto. A natureza concreta de um construto sintático não importa, é o que você expressa com ele. Uma linguagem de programação com a sintaxe exata de Haskell , mas que usa uma estratégia de avaliação diferente, fará com que muitos Haskell tenham um desempenho terrível ou até fiquem presos em loops infinitos. Quando se trata de construções sintáticas (ou mais amplas: características da linguagem), não é a sintaxe concreta que importa, mas a semântica, ou seja, o que você pode expressar com elas.
back2dos
@ 9000, não será um problema escrever um analisador em um Haskell com sintaxe do tipo C (ou um driver, usando C com uma sintaxe do tipo Haskell).
SK-logic