Como algumas comunidades de idiomas (por exemplo, Ruby e Python) foram capazes de impedir a fragmentação, enquanto outras (por exemplo, Lisp ou ML) não foram?

67

O termo "Lisp" (ou "semelhante a Lisp") é um guarda-chuva para vários idiomas diferentes, como Common Lisp, Scheme e Arc. Há fragmentação semelhante em outras comunidades de idiomas, como no ML.

No entanto, Ruby e Python conseguiram evitar esse destino, onde a inovação ocorreu mais na implementação (como PyPy ou YARV) em vez de fazer alterações na própria linguagem.

As comunidades Ruby e Python fizeram algo especial para impedir a fragmentação da linguagem?

programming-languages language-design

— chrisaycock
fonte

10

Você diz que a fragmentação é uma coisa ruim.

— Sonia

21

@Sonia De uma perspectiva de participação de mercado, a fragmentação é frequentemente um desastre.

— Chrisaycock #

5

Os idiomas estão competindo entre si?

— Barry Brown #

32

@ Sonia Pode ser uma coisa ruim. Por exemplo, uma biblioteca escrita para Python quase certamente não depende da implementação, enquanto uma biblioteca escrita para Lisp pode não funcionar no esquema.

— Kris Harper #

2

@ Barry Brown: Ótimo ponto! Os idiomas não devem estar em concorrência no mercado entre si. Mas os fornecedores de idiomas são e isso geralmente influencia o design da linguagem (não acho que seja o caso de Ruby, Python, Lisp, ML).

— Giorgio

77

Ruby e Python têm ditadores benevolentes no comando. São línguas profundamente enraizadas em preocupações pragmáticas. Esses são provavelmente os fatores mais significativos que inibem a fragmentação. Lisp e ML, por outro lado, são mais como linguagens "design by comitê", concebidas na academia, para fins teóricos.

Lisp foi originalmente projetado por John McCarthy como uma notação matemática prática para programas de computador. Ele nunca o implementou como uma linguagem de programação real; a primeira implementação foi desenvolvida por Steve Russell , mas ele não era um ditador benevolente. Com o tempo, muitas implementações diferentes do Lisp apareceram; O Lisp comum foi uma tentativa de padronizá-los.

Lisp é mais uma "família" de idiomas. O mesmo acontece com o ML, que seguiu um caminho evolutivo semelhante ao Lisp.

— Robert Harvey
fonte

4

Hmm, definitivamente vejo o status de ditador entre comunidades linguísticas homogêneas como Objective-C (para aplicativos iOS) e Ada (para contratos do Departamento de Defesa). Nesses casos, uma potência maior exigia adesão, que os desenvolvedores seguiram apenas para poder vender seu warez. Mas nunca fui obrigado a codificar em Python (projeto hobbyista) no mesmo sentido em que talvez fosse necessário codificar em C # (componente .Net). Ou seja, eu poderia fugir mais facilmente do Python do que, digamos, C. Sem essa ameaça de usá-lo ou você não fará vendas , como um ditador pode se apegar ao rebanho? Essa pode ser uma pergunta separada.

— Chrisaycock #

11

Por "ditador benevolente", quero dizer que todas as mudanças de idioma devem passar por uma pessoa que tenha a visão de manter o idioma puro. As pessoas ficam com o Python por razões pragmáticas; eles gostam da linguagem e são produtivos nela. Mas nem todo mundo e seu irmão têm permissão para bifurcar, e ainda o chamam de Python.

— Robert Harvey

4

@HenrikHansen Haskell é um padrão, como Robert menciona. Portanto, o compilador HUGS deve ser compatível com o GHC, pois ambos se chamam "Haskell". A mesma proteção baseada em padrões se estende a C e C ++, e é por isso que o GCC e o Visual Studio devem ser compatíveis (supondo que não seja necessário usar extensões proprietárias). A curiosidade é o que aconteceu com o Lisp, onde já existe um padrão (Common Lisp) e ainda existem muitos outros Lisps. ML tem o mesmo problema em que há ML padrão e ainda outros MLs.

— Chrisaycock

4

"O Common Lisp foi desenvolvido para padronizar as variantes divergentes do Lisp que o antecederam" - en.wikipedia.org/wiki/Common_Lisp . Em outras palavras, já havia fragmentação antes do desenvolvimento do padrão.

— 31712 Robert

3

Eu diria que ML e Lisp não são linguagens como Python e Ruby. Lisp e ML são mais parecidos com "conceitos", implementados por várias linguagens diferentes.

— benjaminb

29

Um fator provável é simplesmente a idade. Lisp e ML são muito mais antigos que Python e Ruby:

Lisp: 1958
ML: 1973
Python: 1991
Ruby: 1995

Lisp e ML, obviamente, viram mudanças muito maiores nas capacidades de hardware, mais tendências na ciência da computação e muito mais estudantes de Ph.D procurando algo para trabalhar.

— Caleb
fonte

7

Possivelmente, mas não me lembro de Fortran ter esse grau de bifurcação. (Havia coisas como o Fortran D, mas a maioria dos Fortrans passou pela padronização.) Suponho que talvez a era da coalescência possa ser um fator.

— chrisaycock

2

AFAIK, o Fortran possuía muitas incompatibilidades e extensões não padronizadas e diferentes implementações, até que os comitês de normas gradualmente o definiram, provavelmente porque era mais difundido do que Lisp e ML.

— erjiang

@erjian: FORTRAN teve suas incompatibilidades resolvidas porque havia um incentivo sério para: uso comercial. O LISP, usado principalmente em academias, nunca teve esse luxo. Ou seja, não é o quão difundido foi o seu uso, mas o quão abastados foram seus usuários.

— MSalters

2

Ou, alternativamente, as variantes não foram chamadas de FORTRAN. O BASIC, quando lançado, com certeza parecia um FORTRAN simplificado.

— David Thornley

11

O @MSalters Common Lisp foi na verdade um esforço (bastante bem-sucedido da IMO) para combater as incompatibilidades nos vários dialetos do maclisp ditados entre outras coisas pelo uso comercial (e também a DARPA queria que todos os laboratórios de pesquisa que financiava pudessem compartilhar código com mais facilidade) . Hoje, além do esquema, clojure e lisp comum, não existem lisps de uso geral prático, e esses três são diferentes o suficiente, têm comunidades muito separadas com culturas e história separadas para não contá-las como dialetos da mesma língua mais do que java e C ++. .

— Pavel Penev

24

Eles são essencialmente todas as linguagens definidas pela implementação

Quando é fácil criar uma nova implementação de uma linguagem que seja amplamente compatível com o código existente, então os hackers são hackers, eles fazem isso. Todo mundo escreve uma implementação do Lisp em algum momento. Os compiladores de ML são quase obrigatórios para estudantes de graduação em design de idiomas - afinal, o idioma é bem documentado .

Por outro lado, temos as linguagens ad hoc e definidas pela implementação. Ou linguagens tão complexas que é uma barreira significativa para sempre produzir uma implementação alternativa viável:

rubi; perl; python - definido pela implementação demais para produzir alternativas viáveis
ghc haskell e erlang - bem definido, mas tão difícil de fazer qualquer coisa que concorra com o ghc (ou erlang) que as pessoas geralmente não se incomodam

Essa aparente desvantagem - as linguagens que são muito difíceis de produzir alternativas viáveis e têm a enorme vantagem: os escassos recursos do desenvolvedor estão concentrados na única implementação verdadeira.

Como uma nota histórica, vários membros da comunidade Haskell buscaram ativamente fusões e concentração do esforço de desenvolvimento, reconhecendo que qualquer fragmentação da comunidade de desenvolvimento significaria que não teríamos sucesso. O GHC foi escolhido e defendido.

— Don Stewart
fonte

2

Gostaria muito de saber mais sobre as "fusões e concentrações ativamente perseguidas".

— Sam Tobin-Hochstadt

A fragmentação é natural. Idiomas como Python e Ruby são anomolias que, por acaso, não se fragmentam principalmente, se você não contar as variantes não usadas, por exemplo, ChinesePython, e as variantes estagnadas em uma versão anterior, por exemplo, Jython. Também há viés de sobrevivência aqui, porque a maioria dos idiomas com um ditador não se torna muito popular, por exemplo, Nermerle, Groovy, Beanshell, Boo, na verdade existem provavelmente milhares deles.

— Vorg van Geir

11

Mesmo assim, Haskell ainda poderia ser mais prático para alcançar o status de maturidade Python / Ruby. Haskell's cabalnão é uma ferramenta divertida de usar e bastante fácil de quebrar :. Até o Yesod reconhece: yesodweb.com/blog/2012/04/cabal-meta Python e Ruby são muito melhores no que diz respeito ao gerenciamento de pacotes.

— Ehtesh Choudhury

11

@Shurane Python e Ruby não digitar verificar seus pacotes antes da integração ...

— Don Stewart

2

-1: para "ruby; perl; python - todos definidos para implementação demais para produzir alternativas viáveis" Jython, IronPython, JRuby, IronRuby, PyPy, Stackless provam que você está errado quanto às implementações (e estas são apenas as principais). Além disso, CPython é a implementação de referência, mas não a definição da linguagem, isto é

— vartec

12

Eu diria que um fator é uma plataforma definidora . Para Haskell, a plataforma é o padrão Haskell e o GHC (eu imagino). Para Ruby, foi o Ruby on Rails que "definiu" a plataforma de desenvolvimento Ruby. Para C, era o Unix.

Compare isso com o Lisp, onde não havia uma plataforma original que definisse como era o idioma. Se bem me lembro, cada máquina Lisp apresentava pequenas diferenças, dependendo do modelo e do fabricante. Por algum motivo, o Lisp comum não foi definido. Possivelmente por causa de muita concorrência e relutância em mudar para outra plataforma.

É claro que isso é totalmente especulação do meu lado. O pensamento veio das respostas dos comentários à resposta de Harvey. No entanto, parece que a plataforma que define tem várias formas, mas a propriedade comum parece ser a de que é a que ganha popularidade.

— Henrik Hansen
fonte

Eu realmente gosto dessa ideia. Eu posso usar muitas formas de Lisp porque nenhuma delas possui uma "estrutura matadora", mas se eu quiser usar o Rails, devo ficar com o Ruby canônico. Certamente não é a única resposta, mas eu gosto da sua hipótese.

— Chrisaycock #

eu concordaria na parte da plataforma . Se você tiver um único tradutor capaz de executar o idioma - não haverá muita fragmentação.

— C69

O cisco comum não se estabeleceu cedo em uma única definição porque as pessoas tinham opiniões fortes sobre certas coisas, por exemplo, macros higiênicas.

— 21412 Robert

Eu concordo e discordo disso. Concordo porque uma 'estrutura matadora' corrige a linguagem principal com funcionalidade valiosa, incentiva o crescimento e permite inovações rápidas fora das especificações padrão. Discordo porque, se os mantenedores da estrutura não forem muito cuidadosos, esse rápido aumento na inovação poderá levar a muitas inchaços e / ou abstrações com vazamentos que podem torná-la instável.

— quer

11

(cont) Estruturas como o jQuery que estendem a funcionalidade principal de uma linguagem idealmente desaparecerão no futuro, pois as contribuições mais valiosas dadas por essas estruturas serão padronizadas e incorporadas ao núcleo. IMHO, as estruturas tendem a morrer mais rapidamente porque os desenvolvedores geralmente preferem reduzir / eliminar dependências à medida que a base de código se estabiliza. Se os desenvolvedores de idiomas quiserem permanecer relevantes, eles facilitarão esse processo, adaptando e adotando a funcionalidade da estrutura, e incentivando seus usuários a reduzir dependências nas estruturas de terceiros.

— quer

7

Não se esqueça de pesar a cultura que impulsiona o desenvolvimento de um idioma

Eu também ponderaria o fato de que o desenvolvimento em python / php é feito ativamente em público. Você tem um grupo de indivíduos que estabelece uma especificação padrão que está disponível gratuitamente para qualquer um / todos.

Assim como o W3C faz com o padrão HTML / CSS. Você tem um pequeno grupo de indivíduos motivados que controlam os detalhes mais finos do que o idioma foi projetado para realizar. Tudo entra em uma especificação claramente definida antes de ser lançado ao público.

OTOH, idiomas como o LISP são bifurcados a portas fechadas por professores ou outras pessoas que realmente acreditam que sua perspectiva sobre o 'melhor uso' do idioma está correta. Eles podem estar simultaneamente certos e errados ao mesmo tempo, porque algumas implementações são ótimas em certas coisas; enquanto nenhum é o melhor em tudo.

Isso não é necessariamente uma coisa ruim, porque a diversidade gera inovação. Idiomas como o LISP são e continuarão sendo ótimos idiomas para aprendizado e pesquisa, porque ultrapassam os limites da compreensão.

Mas as qualidades que tornam um ambiente bom para a inovação não são necessariamente benéficas para a estabilidade; por outro lado, as qualidades que tornam um ambiente bom para a estabilidade não são necessariamente boas para a criatividade.

Quando o desenvolvimento é baseado na colaboração ativa, às vezes os indivíduos são forçados a conceder em benefício do todo maior. Ruim para pesquisa / bom para consistência.

O fato é que ainda estamos vivendo no oeste do desenvolvimento da linguagem de programação. O problema de projetar a 'linguagem ideal' é tão grande que, apesar dos esforços monumentais, ninguém chegou perto de resolvê-la.

No setor de pesquisa / academia, ainda há muito espaço para aprimoramento e inovação. No setor comercial, onde há um crescimento exponencial de software sendo usado em aplicações práticas e a força motriz é a simplicidade e consistência.

Algumas línguas são especializadas no primeiro, outras são especializadas no último. Aqueles que tentam se especializar em ambos geralmente não se saem muito bem e morrem.

Por ambos, estou me referindo a linguagens monolíticas como VB / C # / Java. É muito cedo para dizer, mas eu gostaria de ver como é o C # e o Python em 10 anos. No ritmo atual, o C # está aumentando a funcionalidade e a inconsistência a um ritmo que o torna bastante sombrio. Mesmo com boa documentação, é muito doloroso lembrar de todos os detalhes e peculiaridades sutis incluídos no idioma. É ótimo para um único desenvolvedor, mas assim que você cria mais desenvolvedores com estilos exclusivos, a inconsistência na base de código aumenta, a qualidade sofre e ninguém vence. Eu acho que há muito a ser aprendido com as dificuldades que Perl apresenta em um ambiente de produção.

— Evan Plaice
fonte

Escada? Você quer dizer o último?

— Giorgio

@ Giorgio Sim, odeio quando escrevo errado.

— Evan Plaice

2

Não acho correto dizer que linguagens como Python e Ruby não sejam fragmentadas. Já estamos começando a ver alguns efeitos de fragmentação. Por exemplo, o Python 3 não é totalmente compatível com o Python 2, portanto, ambas as versões precisam ser mantidas e muito código existente funciona apenas com o Python 2. Existem alguns spinoffs do Python também, incluindo o PyPy.

Outro fator é a idade das línguas. Os mais sujeitos à fragmentação são os idiomas mais antigos e, portanto, sujeitos a pressões de evolução e revisão. O Lisp foi inventado há várias décadas, então houve tempo suficiente para pegar algumas de suas idéias e incorporá-las em novos idiomas. C é outro exemplo de uma linguagem fragmentada. Enquanto C teve apenas uma revisão realmente importante na própria linguagem (K&R para ANSI), houve inúmeros spinoffs, incluindo C ++, Not Quite C e todos os outros que compartilham uma sintaxe semelhante a C.

O próprio Ruby é uma "fragmentação" (se você desejar) dos idiomas anteriores. Como incorpora idéias de C, Smalltalk e Perl (entre outros), atualmente é a linguagem que está fragmentando. Não vejo por que não veremos mais convolução do Ruby com outros idiomas no futuro.

— Barry Brown
fonte

6

-1 porque: (1) Python 3.x não é fragmentação. É apenas o próximo passo na evolução da linguagem; O Python 2.x será descartado inteiramente em alguns anos. (2) Outras implementações de idiomas que são 99% compatíveis (1% são detalhes da implementação e, na maioria das vezes, bastante obscuras) e se recusam ativamente a participar na definição do idioma não são fragmentação. (3) Uma linguagem muito diferente que compartilhe um terreno comum e seja algo compatível (C ++ a C) dificilmente é fragmentação. (4) Aceitar idéias de idiomas existentes não é fragmentação, é a única maneira de projetar um idioma.

2

@ delnan: Python 2.x será descartado inteiramente em alguns anos? Isso é uma coisa boba de se dizer, quando COBOL e Fortran ainda estão por aí!

— Mason Wheeler

3

@MasonWheeler Estou falando de desenvolvimento. O VCS ainda terá um código antigo arquivado, downloads binários não oficiais podem permanecer por décadas e algumas lojas podem evitar a portabilidade. Mas espero que em algum dia não muito distante, a grande maioria da programação do Python ocorra no Python 3. Afinal, o desenvolvimento de recursos do 2.x cessou há um tempo atrás (e não será retomado, a menos que você faça uma lavagem cerebral no python-dev) , as atualizações de correção de bug / segurança não devem continuar para sempre e uma parte significativa das bibliotecas é portada para o Python 3, com a maioria das outras aguardando ansiosamente (por exemplo, Djano) ou mantendo-se sem manutenção.

11

@MasonWheeler Ah, e quanto ao Fortran e COBOL: O Fortran recebeu uma nova revisão padrão em 2008, e o COBOL recebeu uma em 2002 com um punhado de relatórios técnicos desde então.

@MasonWheeler Você sabia que o COBOL moderno permite programação orientada a objetos?

2

O Lisp é fragmentado porque é um modelo tão poderoso, a linguagem mais incrível já concebida. Hoje em dia, a maioria das linguagens empresta coisas que foram implementadas no Lisp; portanto, de certa forma, você pode dizer que toda linguagem faz parte dessa fragmentação específica. Smalltalk foi por exemplo fortemente inspirado em Lisp, e Ruby é fortemente inspirado em Smalltalk. O JavaScript é Lisp disfarçado em Java, e assim por diante. Está tudo conectado, e todo inventor de idiomas seleciona suas peças favoritas de outros idiomas.

Outro fator é que o Lisp é provavelmente o conceito de programação mais fácil de implementar - e é por isso que é feito repetidamente.

— Torbjørn
fonte

1

As linguagens tipo Lisp são muito básicas e teóricas para serem alteradas drasticamente. Mudanças gramaticais (não pretendo mudar apenas os nomes dos comandos) não se encaixariam na teoria da programação funcional por trás deles.

Mas o fato de existirem idiomas como o lisp mostra que "mudanças" já foram feitas no lisp de qualquer maneira. Em outras palavras, existem idiomas criados por pessoas que foram inspiradas pelo lisp ou por sua teoria e criaram um novo idioma de maneira semelhante.

Também existem muitas linguagens inspiradas no Python. Por exemplo, Julia, CoffeeScript, etc., que formariam sua própria família de linguagens orientadas a objetos sensíveis a espaços em branco.

Eu acho que os fundamentos básicos de uma linguagem como Python nunca irão realmente mudar. O Python é orientado a objetos e, portanto, tem semelhanças com C ++ e Java, mas é dinâmico e, portanto, também semelhante a muitas linguagens de script.

Bem, quem realmente se importa com idiomas? O que conta é o objetivo: o francês é semelhante ao latim, mas as meninas que entendem o francês são muito mais gostosas;)

— PSchwede
fonte