Quando é razoável criar minha própria linguagem de programação?

Existem tipos de aplicativos matadores, classes de problemas algorítmicos etc., onde é melhor, a longo prazo, criar minha própria linguagem?

PS: Apenas para ter certeza, quero dizer uma nova linguagem de programação e um compilador, não um novo compilador para uma linguagem existente.

EDIT : Obrigado pelas respostas. Você pode fornecer alguns exemplos em que é absolutamente desnecessário criar uma DSL ou casos em que uma DSL pode ser uma boa idéia?

Certamente é relevante para uma pessoa escrever sua própria língua para fins educacionais. Para aprender sobre o design da linguagem de programação e sobre o design do compilador. Mas os usos no mundo real são poucos e distantes entre si.

Ao escrever seu próprio idioma, você é:

• Adicionando uma quantidade enorme de complexidade ao seu problema
• Adicionando uma quantidade significativa de trabalho por escrito e mantendo o novo idioma e compilador

Portanto, se você planeja escrever seu próprio idioma para o seu projeto, os recursos fornecidos por outros idiomas não precisam compensar os custos acima.

Veja o desenvolvimento de jogos, por exemplo. Eles geralmente precisam de mini-idiomas em seus jogos ou linguagens de script. Eles usam esses idiomas para criar uma enorme quantidade de eventos no jogo que acontecem. No entanto, mesmo nesse caso, eles quase sempre escolhem as linguagens de script existentes e as adaptam às suas necessidades.

Permitam-me apenas citar Paul Vick, ex-desenvolvedor chefe do compilador VB e agora trabalhando no Projeto Oslo e na linguagem M:

É incompreensível e estupendamente difícil criar um novo idioma, mesmo que seja amplamente baseado em um idioma existente. No entanto, muitos programadores pensam: “ei, eu uso linguagens, quão difícil isso pode ser?” E continuamos. ... provavelmente mais de 98% deles nunca conseguem ganhar força, mas Deus abençoe os otimistas, porque sem eles nunca teríamos os 2% de idiomas que obtiveram sucesso. Pessoalmente, estou disposto a sacrificar os milhões de dólares e horas desperdiçados em linguagens que nunca são suficientes para que possamos obter linguagens como C # e Java e Ruby e Python e assim por diante.

Portanto, o fato de apresentar uma nova linguagem ser uma péssima idéia não deve dissuadir as pessoas de desenvolver novas DSLs, deve apenas dar uma pausa e, espero, um pouco de humildade. A chave, acho, é começar pequeno e permanecer pequeno.

DSLs: Definitivamente, é uma má ideia!

Quando é razoável?

Quando você sentir vontade!

Não dê ouvidos a essas pessoas que têm comentários sarcásticos que basicamente dizem:

"Não faça isso porque é muito difícil e a linguagem X é melhor do que qualquer linguagem que você possa criar".

O problema é que a criação de uma DSL acontece o tempo todo. Uma estrutura é uma DSL. Uma macro é uma DSL. Toda vez que você escreve uma função para o seu programa, isso faz parte de uma DSL. Claro, está dentro dos limites da gramática, mas o vocabulário faz parte de um idioma. É por isso que as indústrias costumam criar seu próprio vernáculo: é mais eficiente!

Se "não faça" fosse a resposta certa, todos nós estaríamos escrevendo COBOL e Fortran.

Você pode ler partes do próximo livro DSL de Martin Fowler , se estiver pensando em escrever seu próprio idioma.

Eu realmente não consigo pensar em um caso de negócios para criar um idioma a partir do zero, além de ser uma tremenda experiência de aprendizado.

Edit: para DSLs existem muitos casos de negócios, mas a chave aqui não é se deixar levar e manter simples.

Sugiro que as principais perguntas sejam: "Que problema estou tentando resolver?" e "Quem recebe o ROI?"

Se você está tentando desenvolver suas próprias habilidades e experiência, tenha velocidade máxima à frente, mas não em um sistema de produção que supostamente resolverá o problema de outra pessoa.

Parece que o principal motivo pelo qual você deseja um novo idioma é que você começa a descobrir padrões em seu código que os idiomas existentes não lidam bem. Mas há muitos problemas em criar seu próprio idioma. Você estará perdendo todas as bibliotecas e estruturas criadas para os idiomas existentes. Você gastará muito tempo projetando e implementando a nova linguagem, que é o tempo todo que você não precisa gastar na tarefa de programação real. Você gastará muito esforço convencendo outros desenvolvedores de que eles devem usar seu idioma. Além disso, será difícil recrutar e treinar novos desenvolvedores.

Por que não escrever em um idioma como o Lisp, que permite estender o idioma à medida que você descobre novos padrões? Então, você obtém todo o poder de um novo idioma com todos os benefícios de um idioma estabelecido.

Um motivo pode ser criá-lo como um experimento para aprender sobre design de linguagem e construção de compiladores.

Outro motivo pode ser criar uma linguagem de script em um aplicativo quando você não tiver a opção de adicionar uma API de terceiros.

Não acho que você possa programar sem criar um novo idioma, por isso é bom perceber que é isso que você está fazendo e entender os problemas.

• O que é um idioma?
  Vocabulário, sintaxe e semântica.

Uma linguagem pronta para uso como VB, Java, C # etc. é apenas uma linguagem básica . Assim que você adiciona classes, métodos, etc., adiciona vocabulário e semântica. Existem várias maneiras de implementar idiomas - análise e tradução, análise e interpretação, macros sobre um idioma existente, adição de classes e métodos a um idioma existente.

• O que você quer que um idioma faça?
  Seja bom para expressar problemas de forma concisa.

Como você sabe se você fez isso? A medida que eu uso é a contagem de edições . Se o requisito de uma frase A aparecer, eu continuo implementando o requisito no código. Quando termino e tenho todos os bugs eliminados, verifico o código e o repositório de códigos me fornece uma lista das alterações que fiz, B. Quanto menor o B, melhor a linguagem. Média sobre o espaço de requisitos reais e possíveis, essa medida me diz como é "específica do domínio" a linguagem.

• Por que a concisão é boa?
  Porque minimiza bugs.

Se forem necessárias alterações no código N para implementar o requisito 1 e, às vezes, você cometer erros, o número de erros que você introduzir será aproximadamente proporcional a N. No limite em que N = 1, é quase impossível introduzir um erro sem tentar.

Observe que este é um desafio direto ao "inchaço do código" que vemos hoje em dia.

ADICIONADO: em resposta à sua solicitação de exemplo, consulte execução diferencial . Não vou dizer que ele pode ser entendido rapidamente, mas reduz significativamente o código da interface do usuário.

É sempre "viável" usar a palavra em sua pergunta (original), mas muitas vezes não é útil e raramente é ideal, dada a abundância de linguagens e estruturas maduras e bem suportadas que existem.

É um desafio intelectual interessante, no entanto.

Somente se o negócio principal da sua equipe for linguagens de programação.

Eu trabalhei em uma linguagem de programação que foi criada em uma empresa financeira.

Claramente, para o próprio arquiteto, esse foi um grande desafio e melhorou suas próprias habilidades.

Inevitavelmente, a linguagem não poderia crescer ou melhorar em qualquer lugar próximo da taxa que algo como C # ou Java poderia - eles têm equipes dedicadas a fazer isso.

A linguagem logo estagnou, pois ninguém novo queria assumir a tarefa de melhorar o projeto de estimação de outra pessoa.

O arquiteto original foi embora. A língua murcha e morre após 10 anos.

Esses 10 anos foram um inferno para quem teve a infelicidade de trabalhar em um idioma sem saída.

Então vá em frente, crie seu próprio idioma, mas por favor não peça a ninguém para realmente usá-lo. Por favor, não espere que mais ninguém lhe agradeça.

Projetar idiomas pode ser divertido. Mas você não precisa se restringir às linguagens de programação.

Se eu criar um aplicativo moderadamente complexo, gostaria de adicionar um tipo de linguagem de macro / script para facilitar a execução de tarefas repetitivas complexas. A maioria dos usuários não usa essa funcionalidade, mas os poucos que a utilizam são muito gratos. Além disso, garanto que é valioso para o pessoal de suporte ajudá-lo a solucionar os problemas do cliente.

É completamente razoável se for feito para ampliar suas habilidades e aprender.

Fora isso, se você precisar fazer a pergunta, não é. Se você está tentando descobrir se consegue lidar com uma determinada classe de algoritmo ou com um determinado domínio de problemas melhor do que os idiomas existentes, primeiro precisa ser um especialista na área que está abordando. Você saberá que é apropriado quando suas habilidades e experiência o disserem.

E você pode estar errado sobre isso também, mas você precisaria de outro especialista para convencê-lo disso (ou mostrar que você não é o especialista que pensa que é). Uma discussão animada que seria, não um simples questionário de perguntas e respostas, como você encontrará aqui.

Exceto para fins de auto-educação, gostaria de afirmar que hoje não há necessidade de criar seu próprio idioma. Em qualquer circunstância. Sempre. Independentemente do que você queira fazer, existem muitas cargas de idiomas existentes que você pode levar / adaptar às suas necessidades.

Depende definitivamente da situação. Como nosklo disse - Se você tem uma boa idéia, um novo conceito ou algo assim, eu recomendo que você faça isso.

Em geral, eu sugeriria confiar na tecnologia estabelecida.

Mas se você estiver interessado em criar sua própria "linguagem", verifique: YACC & Lex

Você pode, apenas não se prenda ao antipadrão "Recriando a roda quadrada".

Significando que você está recriando o que já foi feito, apenas mais pobre que o (s) original (ais).

Wouter era conhecido por criar um novo idioma para qualquer nova idéia. Você pode se inspirar em seu trabalho: a página da linguagem de programação de Wouter .

Quando criar seu próprio idioma?

Quando você quiser, como um grande projeto de hobby.

Para um idioma específico do domínio. Estes podem ser bastante elaborados; veja o que acontece na comunidade de Ficção interativa (ou aventura de texto), consultando o arquivo .

Quando seus objetivos são muito ambiciosos e você acha que pode fazer um avanço real, como o projeto Arc de Paul Graham .

Além disso, em qualquer linguagem suficientemente adaptável (talvez C ++, definitivamente Common Lisp) no processo de desenvolvimento de construções de baixo nível.

Quando evitá-lo como você, espero, evitaria um clichê como evitá-lo como uma praga?

Quando é a base do desenvolvimento contínuo de projetos reais. Ele sempre ficará muito atrás do que está disponível comercialmente a baixo custo e prejudicará o desenvolvimento. Eu trabalhei para uma empresa com sua própria versão do COBOL e nunca quero trabalhar em outra empresa que mantenha seu próprio idioma. Vimos outras versões do COBOL obterem melhores recursos e ferramentas, enquanto estávamos presos aos mesmos problemas. (Não quero mais trabalhar com o COBOL, mas isso é outra história.)

As situações em que você pode criar seu próprio idioma não se enquadram nisso. Projetos de hobby não são usados ​​para desenvolvimento real. Algo como o Arc terá sucesso (e terá várias implementações e mais evolução e desenvolvimento) ou falhará (e ninguém mais o usará). Uma pequena linguagem específica de domínio é apenas parte de um projeto e, como é pequena, pode ser aprimorada com o tempo. Uma linguagem de aventura de texto é usada para escrever jogos individuais, e esses jogos, além de serem projetos de hobby, quase nunca são usados ​​para o desenvolvimento contínuo.

Minha perspectiva é que as DSLs geralmente são uma "idéia fraca" e, a longo prazo, é mais produtivo usar uma linguagem padrão e criar suas necessidades específicas de domínio como uma biblioteca "não DSL".

No entanto, pode ser que suas necessidades sejam personalizadas o suficiente para que seja preferível ter uma DSL (não apenas uma implementação gcc ou lisp ligeiramente modificada) para sua empresa. Muitas empresas usam drop-ins dos idiomas atuais que têm como alvo o que estão fazendo, sem escrever / manter seu próprio idioma. Por exemplo, eu ouvi dizer que o PHP tem um bom drop-in; Lua foi projetada para ser um drop-in, o ModelView usa Python e o AutoCAD tem o AutoLISP como seu script.

Não há nada de errado em escrever sua própria linguagem de programação se você puder aproveitar as ferramentas existentes. No mundo de hoje, isso significa que você pode defini-lo em uma sintaxe utilizável para uma linguagem existente (como Java ou C #) ou gravar um pequeno sistema de transformação (expansor de macro) que gera código em uma linguagem existente.

Ir até o código da máquina está reinventando muitas rodas ...

Uma boa razão para uma DSL é representar dados de domínio de maneira sucinta. Isso permite que especialistas em domínio trabalhem com os dados diretamente, em vez de precisar passar por outros. O truque é ter os programas resultantes em um formato fácil de processar.

De um modo geral, a resposta seria um grande NÃO. Das centenas de idiomas por aí, geralmente existe um que se adapte ao seu problema.

No entanto, existem circunstâncias em que é uma opção racional desenvolver um novo idioma: -

• Quando um de seus concorrentes agora possui uma de suas principais plataformas de desenvolvimento. Estou pensando na atual dependência do Googles em Java e no desenvolvimento de "go" (ajuda se você tiver um autor da linguagem mais bem-sucedida de todos os tempos na folha de pagamento!).
• Quando você precisa escrever uma tonelada de código para uma nova plataforma e os idiomas existentes são detalhados e propensos a erros - por exemplo, php para desenvolvimento web.
• Quando você se deparar com problemas de escala e paralelismo que nunca foram encontrados antes, porque ninguém nunca teve tanto hardware para processar tantos dados antes - por exemplo, Scala e (até certo ponto, GO).

A linguagem é boa em composicionalidade ou em reunir os mesmos componentes de maneiras diferentes.

Se o problema do seu domínio apenas precisar que você defina várias opções ortogonais, um idioma provavelmente não adiciona muito sobre formulários, uma interface gráfica do usuário ou uma configuração de texto direta. Arquivo. (Estou assumindo aqui que um arquivo cheio de pares de chave e valor não é o que você quer dizer com "idioma".)

OTOH, se sua configuração é como linguagem real, por exemplo. verbos e substantivos podem ser reunidos em muitas combinações diferentes (e novas) com qualquer grau de complexidade; então, um idioma se tornará quase inevitável, porque a explosão combinatória de tentar especificar o que você deseja por qualquer outro método é esmagadora.

Exercícios de aprendizado à parte, é razoável criar sua própria linguagem de programação somente quando você entender outras línguas, seu domínio de problema específico e a maneira como os idiomas existentes tratam desse domínio de problema, e esse entendimento é completo o suficiente para que você saiba que um novo idioma é razoável solução sem precisar fazer a pergunta.

A última vez que decidi fazer isso em um projeto de hobby, comecei a especificar como eu queria que a sintaxe aparecesse e percebesse no meio do processo, reinventando o prólogo. Outros idiomas que podem ser adequados quando você acha que precisa inventar um idioma são lisp, lua ou algo como Haskell. Basicamente, todas as línguas que você ignorou na faculdade porque pensou que nunca seriam úteis.

Uma razão é para fins educacionais, como já foi dito. Mas tem mais. Por exemplo, existem muitas linguagens de pesquisa, como Sing#no sistema operacional Singularity e BitCno Coyotos, que foram projetadas porque os idiomas existentes não oferecem os recursos necessários (por exemplo, verificação no nível do idioma).

Tom Van Cutsem escreveu recentemente uma resposta de ensaio para esta mesma pergunta:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Resumo do marcador (dessa página):

• A linguagem como mecanismo de abstração sintática: reduzir o código repetitivo que não pode ser abstraído usando os mecanismos de abstração internos de outra linguagem.
• A linguagem como modeladora de pensamentos: induzir uma mudança de paradigma na maneira como se deve estruturar o software (mudando o "caminho de menor resistência").
• A linguagem como um simplificador: resumir um paradigma existente apenas às partes essenciais, freqüentemente para aumentar a compreensão e o insight.
• Linguagem como agente da lei: para impor propriedades importantes ou invariantes, possivelmente para facilitar a dedução de propriedades mais úteis dos programas.

Provavelmente nunca.

Lua é a melhor escolha que você pode ter se quiser incorporar o idioma basicamente em qualquer outro idioma.

Atualmente, os idiomas específicos de domínio pequeno estão inseridos e fazem sentido em alguns aplicativos.

Fora isso, as razões são principalmente acadêmicas.

Criar uma linguagem quando não é necessário, é realmente uma coisa ruim a se fazer devido à complexidade envolvida no desenvolvimento e na manutenção dela. Eu já vi muitos projetos que introduzem algum tipo de linguagem de script específica apenas para esse programa, e foi isso que atrasou o desenvolvimento da coisa base em grande quantidade. Bons exemplos são, por exemplo, linguagens de automação como Phantom, AutoHotKey, AutoIt. Essas ferramentas seriam muito melhores na IMO se usassem algum idioma emissor conhecido como Lua.

Sua 'edição' parece ser uma pergunta substancialmente diferente ("quando devo construir uma DSL?" Em vez da pergunta original que as pessoas entendem como "quando devo construir uma nova linguagem de programação de uso geral"). Parece que as pessoas responderam completamente à pergunta "original", mas há poucas respostas que fornecem critérios específicos para quando usar uma DSL. Então, proponho uma lista de verificação:

1. Sua base de usuários é maior que algumas pessoas, geralmente não técnicas e / ou com acesso restrito ao sistema (portanto, não é razoável esperar que eles aprendam / usem uma linguagem de uso geral existente). Se estiver dentro da sua equipe de desenvolvimento ou organização de software, você poderia dizer "apenas escreva um script".
2. Seus usuários precisam usá-lo com bastante frequência, com comportamentos suficientemente variados e variáveis ​​necessários (ou seja, você não pode apenas fornecer uma biblioteca fixa de funções mantidas por você)
3. O comportamento que os usuários podem especificar é muito complicado para especificar como dados (por exemplo, você não pode obtê-lo usando uma tabela de banco de dados ou uma matriz de entrada do usuário ou uma lista de tarefas ou uma coleção de valores-chave ... pense com cuidado porque você pode obter muita complexidade com esses). Se você conseguir atingir o comportamento usando a entrada ou configuração de dados em vez do DSL, provavelmente deverá fazê-lo, pois será muito menos trabalhoso. Algum tipo de condicionalidade, ou composição / encadeamento, ou modelagem de algumas abstrações diferentes podem ser sinais de que o comportamento de que você precisa é complexo demais para uma configuração / dados simples
4. Mas o comportamento ainda é restrito o suficiente para que você possa especificá-lo em uma DSL concisa. Um grande perigo é o inchaço da plataforma, por exemplo, se os usuários começarem a solicitar "você pode simplesmente adicionar ...?". Se eles precisarem se conectar à Internet ou ler e gravar no sistema de arquivos ou abrir e fechar processos - isso não será mais um DSL. (Vi isso acontecer de verdade ... os usuários podem incorporar pequenas chamadas python, aumentando gradualmente para scripts python e, eventualmente, destruindo quaisquer limites / modularidade / desempenho)

Se tudo isso for verdade, uma DSL pode ser apropriada.

Existem tipos de aplicativos matadores, classes de problemas algorítmicos etc., onde é melhor, a longo prazo, criar minha própria linguagem?

Depende.

Vamos pegar nosso cérebro. Parece ser uma bagunça tão complexa que encontramos fronteiras com QUALQUER linguagem de programação (pelo menos agora). Então, talvez, para realmente virtualizar nosso cérebro, precisamos de outras abordagens e, portanto, de outras semânticas e sintaxes.

De um modo geral, ainda existem tópicos tão complexos que podem levar a outras estratégias que também incluem uma linguagem 'melhor' para um determinado cenário.