ti-enxame.com

Como você projetaria uma linguagem de programação?

Se você projetasse uma linguagem de programação, como faria isso? Quais recursos você colocaria? O que você deixaria de fora? Estática ou dinamicamente digitada? Tipo forte ou fraco? Compilado ou interpretado? Justifique suas respostas.

41
Chinmay Kanchi
  • Definitivamente, acho que as linguagens de programação funcional serão ativadas, portanto minha linguagem será funcional. Veja domesticando efeitos com programação funcional

  • Acho que as CPUs em breve terão centenas de núcleos, e os threads serão um inferno para gerenciar. Portanto, o Modelo de Ator é uma obrigação em vez de threads. Veja Erlang - software para um mundo simultâneo

  • Eu também acho que OOP falhou, a comunicação entre objetos foi assumida como sendo assíncrona . Então, acho que precisamos mensagem que passa , com mensagens imutáveis. Envie e esqueça. Como no modelo do ator. Consulte Programação orientada a objetos: o caminho errado? =

  • Eu acho que seria bom ter digitação estática , para que os erros sejam detectados no início do ciclo de desenvolvimento. Mas eu usaria inferência de tipo como em Haskell, para que o desenvolvedor não precise escrever o tipo em todo lugar no código, como em C, C # e Java. Veja Aprenda um Haskell para um Grande Bem

  • Eu também criaria uma ótima biblioteca de interface do usuário , com layout declarativo , como no WPF e Android. Mas eu gostaria de tê-lo como em Programação Reativa Funcional .

Portanto, minha linguagem seria como a concorrência em Erlang, mas com a digitação como em Haskell e uma estrutura de GUI como no WPF.NET.

55
Jonas

Nota: usei a sintaxe do tipo C para descrever os recursos deste post, mas não sou exigente quanto à sintaxe, desde que não seja algo ridículo, como todas as palavras-chave que são CAPS.

1. Sistema de digitação

O recurso número um que eu gostaria em um idioma é a digitação estática com a digitação dinâmica opcional . O motivo é que a digitação estática permite: a) detectar erros mais cedo do que tarde eb) a maioria dos códigos são implicitamente digitados estaticamente, independentemente de o idioma fazer ou não a distinção. No entanto, existem vários casos de uso em que a digitação dinâmica é extremamente útil. Por exemplo, ao ler dados de um arquivo, você costuma ter campos de tipos variados, e a digitação dinâmica facilita recipientes heterogêneos. Então, minha linguagem ideal teria algo assim:

//variable declarations
int anInt = 42 //anInt is now irrevocably an integer and assigning another type to it is an error
vartype aVariable = 42 //aVariable is currently an integer, but any type can be assigned to it in the future

//function definitions
int countElements(Collection c)
{
  return c.count();
} 

//c HAS to be a collection, since countElements doesn't make sense otherwise

void addToCollection(Collection& c, vartype v) 
{
  c.append(v)
}

//c is passed by reference here

2. Compilado vs. Interpretado

Eu gostaria que a linguagem fosse compilada antes do tempo ou compilada pelo JIT, mas não puramente interpretada, sendo a velocidade a razão. Isso está relacionado ao ponto 1, uma vez que um compilador/jitter otimizado terá muito tempo mais fácil para otimizar o código estaticamente digitado e código digitado dinamicamente poderia simplesmente ser deixado como está.

. Fechamentos

A linguagem deve suportar construções de programação funcional e as funções devem ser objetos de primeira classe.

4. Orientado a objetos

A linguagem deve permitir que você escreva código orientado a objetos, mas também deve ser permitido um código imperativo simples. ou seja, deve ser possível escrever um programa hello world assim:

int main(string<> args=null)
{
  printf("hello, world"); 
  return 0;
}

// this code also demonstrates two other features,
// default arguments for functions (not explained further)
// and immutable lists like string<> (see 6. Built-in datatypes)

5. Namespaces

Os espaços para nome são uma coisa boa. Muito pouca coisa deve ser inserida no espaço para nome global. Mas se você deve colocar coisas no espaço de nomes global, pode (ala C++).

6. Tipos de dados incorporados

O idioma deve ter, como tipos de dados internos, as seguintes construções:

  • Um tipo de dados int _ ou tipos. Se houver apenas um tipo int, ele deverá ter um alcance ilimitado. Se houver mais, deve haver upcasting implícito no tipo menor capaz de conter o resultado de uma computação, com o tipo de intervalo ilimitado sendo o maior.
  • Um único tipo binário embutido float, que é equivalente a um IEEE 754 double
  • Um tipo mutável list que é implementado como uma lista duplamente vinculada ou como um bloco de memória contígua contendo ponteiros para cada elemento
  • Um tipo imutável de list que age como uma matriz, mas cujo tamanho não pode ser alterado após a criação
  • Mutável e imutável string tipos, com o padrão sendo imutável.
  • Um tipo map ou dict que é mutável e contém chaves imutáveis ​​e valores mutáveis ​​e/ou imutáveis.
  • Os tipos de coleção internos devem ser digitados de forma homogênea por padrão, mas podem ser vartyped, se necessário
  • Um tipo de boolean
  • Um tipo null ou none que pode ser atribuído a uma variável de qualquer tipo.
  • Mutável e imutável set types
  • Um tipo decimal que implementa variáveis ​​decimais de ponto flutuante
  • Um tipo fixed, que implementa um número de ponto fixo

Os tipos decimal, float e fixed devem compartilhar a exata mesma interface pública (via herança ou digitação de pato), permitindo que sejam passados ​​e retornados de forma transparente a partir de funções. O tipo pai pode ser chamado real.

7. Chamada por valor e por referência

Você deve poder chamar funções por valor e referência, com o valor padrão (ou seja, uma cópia do argumento é feita e operada na função).

8. Ponteiros

O idioma deve ter ponteiros e permitir aritmética do ponteiro. Os ponteiros só podem ser digitados estaticamente (para evitar o pesadelo que é um void*). vartype ponteiros são explicitamente proibidos. Ter ponteiros e aritmética de ponteiros permite que a linguagem seja seriamente usada como linguagem de programação de sistemas.

9. Montagem em linha

Em conexão com 8., o idioma deve permitir o código da linguagem Assembly embutido para as situações em que é necessário.

10. Segurança

O idioma deve ser mais seguro de usar, suportando o tratamento de exceções, etc. O aritmético e o assembly em linha do ponteiro podem ser relegados para partes do código explicitamente marcadas como inseguras. Código inseguro é permitido, mas fortemente desencorajado.

11. Comportamento indefinido

O padrão da linguagem deve especificar como o programa deve se comportar em todas as circunstâncias , exceto no código explicitamente marcado como inseguro, ou seja, não deve haver comportamento indefinido fora do inseguro blocos. Isso permite que o idioma seja usado como um idioma viável de desenvolvimento de aplicativos, enquanto ainda permite que você diga, escreva um SO.

É tudo o que consigo pensar no momento, mas vou editar/atualizar o post à medida que penso em mais coisas.

22
Chinmay Kanchi

É assim que minha linguagem de programação dos sonhos se pareceria:

  • Um poderoso sistema de tipo estático com algum suporte para digitação dependente.
  • Digitação dinâmica opcional.
  • Torre numérica à la LISP, mas digitada estaticamente.
  • Macros à la LISP.
  • Principalmente uma linguagem de programação funcional com suporte básico para programação imperativa (como a família ML).
  • Coleta de lixo.
  • Inferência de tipo.
  • Continuações.
  • Semântica preguiçosa opcional.
  • Todas as construções de controle seriam fornecidas na forma de funções de biblioteca. (Isso pode ser possível usando os dois últimos recursos.)
  • Sintaxe mínima (não tão pequena quanto Lisps, mas algo do tipo Ioke/Seph.)
7
missingfaktor

Eu o teria projetado praticamente como C #, mas a Microsoft me superou. :)

(Exceto, é claro, que o meu teria sido menos bem pensado e mais amador.)

Não me importo muito de ser compilado ou interpretado, por isso não preciso justificar isso.

No que diz respeito à tipagem estática forte, acho difícil entender por que isso exige justificativa. A digitação estática é um recurso que captura bugs durante o tempo de compilação. A digitação dinâmica é a falta desse recurso e adia os bugs até o tempo de execução. Na minha experiência pessoal, eu tinha poucos casos de uso em que o despacho dinâmico fazia sentido e era útil; portanto, as convoluções que tive que passar em C # antes do 4.0 para obtê-lo eram facilmente justificáveis. Com o C # 4.0, nem preciso mais justificar isso, porque agora temos expedição dinâmica.

No entanto, eu provavelmente teria criado uma nova sintaxe em vez de aderir tão religiosamente à sintaxe C antiga quanto o C #. A declaração switch é particularmente horrível e também não gosto da sintaxe do elenco (é o contrário). No entanto, não me importo muito com os detalhes da sintaxe, por isso não preciso justificá-la em detalhes, exceto que eu não gostaria que fosse tão detalhada quanto o Visual Basic.

O que mais você gostaria que eu justificasse?

6
Timwi

Bem, aqui está uma lista de recursos que eu colocaria:


LISP como sintaxe

Estilo LISP

Prós :

  • Sintaxe facilmente extensível. Já tentou implementar um loop foreach em C? Não é exatamente fácil. (Veja bem, eu fiz isso ).
  • Homoiconicidade. Você pode simplesmente (eval "your data files")

Contras :

  • A notação de polimento aninhado geralmente é difícil de ler

Programação Funcional

Estilo Haskell

Prós :

  • Simultaneidade fácil, todo o código é seguro para threads.

Contras :

  • Difícil de implementar efeitos colaterais em código funcional puro, embora as mônadas pareçam fazer um bom trabalho.

Digitação dinâmica forte

Estilo Python

Prós :

  • A digitação dinâmica torna o código legível limpo, a digitação forte pode eliminar erros de digitação

Implementação :

Permitir sobrecarga de função com base em tipos, semelhantes aos CL's defgeneric:

(define (+ (a <int>) (b <int>))
  (ints-add a b))

(define (+ (a <string>) (b <string>))
  (string-concat a b))

(define (+ a b)
  (add-generic a b))

Compilável e Interpretável

Prós :

  • Aumento de desempenho se compilado (geralmente verdadeiro, nem sempre)

Contras :

  • Pode limitar recursos no idioma, mas o llvm seria um bom suporte.

Programação de sistemas

Estilo C

Prós :

  • Apela a uma gama muito pequena de usuários.
  • Mais fácil para aplicativos, kernel e drivers de dispositivo interagirem se todos estiverem escritos no mesmo idioma

Contras :

  • Limita as abstrações no idioma; a digitação dinâmica geralmente não é adequada.

Macros higiênicas (estilo CL e estilo Scheme)

Prós :

  • Fácil de estender o idioma, especialmente com a sintaxe Lispy ™
  • Eu já disse isso antes, não disse?

Contras :

  • Poucos se forem feitos com a sintaxe Lispy ™

Pensando bem, este esquema define mais ou menos, exceto o bit de compilação e programação de sistemas. Isso pode ser contornado usando libguile e escrevendo esses bits em C.

5
Joe D

Dicas do compilador

Estou falando mal de mim porque não sei muito sobre design de linguagem, mas acho que o recurso de que estou falando se chama dicas em outros idiomas. Dicas do compilador, talvez?

Não sei se li isso em um rascunho do Perl6 ou estava alto na época, mas imagino uma linguagem em que tudo, por padrão, seja frouxo e auto-mágico. Mas se você realmente deseja aumentar o desempenho e dizer, ei, esse valor é sempre um número inteiro ou nunca é nulo, ou pode ser paralelo, ou sem estado, coisas assim ... Que o compilador poderia ir automaticamente à cidade nessas áreas especificamente marcadas.

E: Eu gostaria de comentários esclarecendo o que estou pedindo ou citando exemplos onde isso já existe.

3
Mark Canlas

Existem vários idiomas por aí que considero muito bons (C # é o meu favorito atual). Como essa é a minha linguagem de fantasia, eis o que eu realmente quero:

  • Documentação oficial da API da Kick-ass. A API Java é boa assim, e C # /. NET é muito bom. Ruby/Rails é bastante terrível aqui.
  • Documentação geral oficial do Kick-ass (instruções, usos comuns, muitos exemplos de código). C # /. Net é bom para isso.
  • Uma enorme comunidade de documentadores baseados em blogs e solucionadores de problemas do StackOverflow para me ajudar a superar dificuldades
  • Uma ampla variedade de plugins/bibliotecas/extensões bem suportados, bem documentados e poderosos (o Ruby/Rails tem 'poderoso', mas nenhum dos outros dois).
  • É razoavelmente estável - não é possível alterar tudo para quebrar a maioria dos códigos existentes anualmente (olhando para você, Ruby/Rails).
  • Não é muito estável - é capaz de se adaptar aos avanços no design da linguagem (olhando para você, c ++)
3
Fishtoaster

Antes de projetar uma linguagem de programação, eu encontraria uma boa resposta para a pergunta: por que precisamos de outra linguagem de programação? Código Rosetta no momento da redação deste artigo, lista 344 idiomas. Se nenhum deles atendesse às minhas necessidades, os detalhes específicos do motivo pelo qual eles não determinariam o ponto de partida (os idiomas mais próximos) e o que seria adicionado a ele.

Se eu ganhasse na loteria e, por algum motivo, não tivesse nada melhor para fazer, começaria com Liskell e a tornaria uma linguagem completa em oposição a um front-end do GHC, depois tornaria a FFI mais fácil (e automatizada) para que eu pudesse usar qualquer Biblioteca C/C++.

2
Larry Coleman

Uma boa língua é uma linguagem que é:

  • fácil de raciocinar (sem sintaxe obscura)
  • deixe você expressar suas idéias com o mínimo de distorção
  • ocultar os detalhes essenciais de você (otimização/gerenciamento de recursos)
  • facilmente paralelizável (múltiplos núcleos, computação distribuída)

É muito difícil transformar isso em uma lista de recursos, mas acho que a Programação Funcional, apesar de não parecer natural , está mais próxima disso do que a programação imperativa (especialmente para esconder os detalhes detalhados)

  • interface C: C é a língua franca das linguagens de programação e o número de bibliotecas desenvolvidas em C é incrível. Por ter uma interface fácil (como Python) para C, a linguagem se beneficia automaticamente de todas essas bibliotecas e também permite enviar tarefas pesadas que não puderam ser otimizadas o suficiente para uma linguagem próxima à metal.
  • Distribuído: Eu gosto do Go's no multi-threading, com rotinas leves que o tempo de execução despacha em threads, dependendo da atividade deles. Essa linguagem incentiva o programador a raciocinar sobre tarefas e isolá-las umas das outras.
  • Coleta de Lixo: escusado será dizer hoje em dia;)
  • Imutável: muito mais fácil argumentar sobre algo que nunca pode sofrer mutação, muito mais fácil implementar computação multithreading/distribuída também (você só precisa de sincronização para lidar com a vida útil, que é a tarefa do compilador)
  • Lambdas: combina com funções de primeira classe, eu acho
  • Message Passing: imutabilidade não significa mutex, portanto seguimos a sugestão de Tony Hoares
  • Módulos: um pouco semelhante aos namespaces, mas com melhor encapsulamento
  • Reflexão: a computação distribuída requer serialização, que deve ser deixada para o compilador, e a desserialização é mais facilmente alcançada com alguma forma de reflexão.
  • Digitação forte estática: quanto mais cedo um erro for detectado, menor será o custo

No momento, o idioma mais próximo dessa lista é provavelmente Haskell, no entanto:

  • falta Rotinas: ainda não vi uma maneira natural de expressar paralelismo em Haskell (embora possa ser minha ignorância ...)
  • ele tem uma sintaxe obscura: de alguma forma, parece que os programadores Haskell prosperam usando operadores estranhos em vez de palavras. Pode parecer liso, mas não ajuda muito a entender o que está acontecendo.
2
Matthieu M.

Para sua primeira pergunta, "como você faria isso" - resposta curta, eu não faria. Eu não tenho teoria do analisador/compilador suficiente para fazer isso. Mas como programa há 25 anos, tenho algumas idéias e opiniões para compartilhar.

Primeiramente, eu tentaria criar uma abordagem OOP que permita criar modelos verdadeiramente conectados. O que quero dizer com isso é que os modelos são uma das coisas mais importantes em quase todo tipo de projeto de programação - é sempre muito trabalhoso e refatoração contínua para fazer o que é certo, e eu culpo isso pela falta de conectividade real no projeto. OO idiomas.

Permita-me demonstrar. Digamos que uma classe House tenha uma propriedade Door.

var door = house.Door;

Agora você tem uma variável local com uma referência à instância do Door.

Mas considere o que acabou de acontecer: você acabou de arrancar a porta da casa e agora está muito feliz passando a porta, e o restante do seu código ignora o fato de que essa porta está realmente conectada a uma casa.

Para mim, isso é fundamentalmente errado.

E sim, eu sei, isso é "facilmente" corrigido caso a caso - nesse caso, mantendo uma referência inversa de todas as Portas da Casa às quais ela está atualmente conectada. É claro que isso abre seu modelo para erros, já que agora é seu dever manter com precisão duas referências reversas, para que você torne as propriedades House.Doors e Door.House privadas e adicione métodos como House.AddDoor (), House.RemoveDoor ( ), Door.SetHouse () etc., conecte tudo e teste-a para garantir que realmente funcione.

Isso não está começando a parecer muito trabalho para modelar um relacionamento tão direto? Muito código para manter? Muito código para refatorar à medida que o modelo evolui?

O problema é ponteiros. Toda OO linguagem que eu vi, sofre inerentemente do fato de que uma referência a objeto é realmente um ponteiro, porque é isso que os computadores usam.

Ponteiros não são uma boa maneira de modelar o mundo real. Independentemente do mundo que você está tentando modelar, é quase garantido que qualquer relacionamento nesse mundo será de mão dupla. Os ponteiros apontam apenas em uma direção.

Gostaria de ver uma linguagem em que o modelo de dados fundamental seja um gráfico - onde todos os relacionamentos, por padrão, têm duas extremidades. Isso certamente forneceria um ajuste muito mais natural para modelar o mundo real, que é realmente a única coisa para a qual precisamos de computadores. (isso e videogames.)

Não tenho idéia de como seria a sintaxe de uma linguagem como essa, ou se ela pode ser concebida até mesmo como expressão usando texto. (Eu me perguntei se essa linguagem teria que ser gráfica, de alguma forma ...)

Eu também gostaria de ver todas as formas de estado acidental eliminadas.

Por exemplo, no desenvolvimento da Web, gastamos muito tempo moldando dados de bancos de dados, modelos de negócios, modelos de exibição para apresentação ... então alguns desses dados são apresentados em formulários, o que é realmente apenas outra transformação. .. e state volta das postagens de formulário e, em seguida, remodelamos esses dados e os projetamos de volta no modelo de exibição, por exemplo ligadores de modelo de vista e tal ... projetamos do modelo de vista de volta para o modelo de negócios ... usamos mapeadores de objetos relacionais (ou trabalho pesado) para transformar os dados do modelo de visão e projetá-los em um banco de dados relacional ...

Isso está começando a parecer redundante? Em que ponto, durante toda essa loucura, realizamos alguma coisa útil? Por útil, quero dizer, algo tangível - algo que o usuário final possa entender e se importar. No final do dia, as horas que você passou construindo algo que os usuários podem entender são realmente as únicas horas bem gastas. Tudo o resto é efeitos colaterais.

Eu gostaria de uma linguagem altamente dinâmica. O ciclo de gravação/compilação/execução é uma perda de tempo tediosa. Idealmente, o idioma deve apenas descobrir o que mudou e compilar/carregar de forma transparente, em segundo plano, conforme necessário.

Idealmente, você nem precisa pressionar "executar" - as coisas devem acontecer na tela, conforme você faz as alterações, refletindo imediatamente as alterações feitas. O problema com o ciclo de gravação/compilação/execução, ou mesmo o ciclo de gravação/execução mais direto, é que você está muito desconectado do que está fazendo - para se sentir conectado ao nosso trabalho, nós precisa de feedback imediato, resultados instantâneos. Qualquer espera é muito longa!

Novamente, nem sei se isso pode ser conseguido com um IDE tradicional ou se isso exigiria um tipo de interface totalmente novo.

Você deve poder usar uma mistura de tipos fraco e forte, o que for mais adequado para o problema em que está trabalhando.

Estado em geral deve ser algo que o idioma gerencia totalmente para você. Por que você precisa confiar em um banco de dados para persistência? Idealmente, eu gostaria de poder simplesmente especificar o tempo de vida de qualquer variável no modelo: uma solicitação da Web, uma sessão, 24 horas, permanentemente.

Por que precisamos escolher entre toda uma gama de soluções de armazenamento para diferentes mídias e condições de vida? - sem mencionar a transformação e modelagem dos dados para caber em cada mídia; cache do navegador, banco de dados, memória, disco, quem se importa! Dados são dados. Onde você armazena seus dados (e por quanto tempo) deve ser uma escolha simples, não uma batalha contra os deuses!

Bem, boa sorte com isso.

2
mindplay.dk

Tendo em mente que as únicas linguagens que conheço são PHP e javascript, e que eu realmente devo aprender mais algumas antes de criar uma linguagem:

Sintaxe: Pense com cuidado nos nomes das funções e na ordem dos argumentos (ou seja, seja menos confuso que o PHP).

Recursos: Possui um conjunto de funções string, que opera em variáveis ​​como uma série de bytes, mas não entende texto, e um conjunto de funções text, que entendem muitas codificações e podem operar em UTF-8 e outras seqüências de vários bytes. (E possui verificações de integridade de codificação incorporadas ao idioma, com uma função como text.isValidEncoding(text, encoding) que informa se uma sequência de bytes está malformada e insegura para ser tratada como texto.

Acho que gosto da ideia de digitação estática forte, mas nunca a usei, por isso não posso dizer.

2
TRiG

Para experimentar novas idéias:

Eu criaria uma linguagem de programação funcional de tipo dinâmico, que permite executar todos os truques de expressão de instrução e a sintaxe lambda mais simples com a correspondência de padrões. Regra externa ativada.

// a view pattern (or Active Pattern in F#)
default = \def val: !!val.Type val def

// usage of the pattern
greet = \name<(default "world") `and` hasType Str>:
  p "Hello, \{name}!"

(p "Enter your name", .input).greet // (, ) is a sequence expression, returning the last value

Aqui está uma explicação:

default = Define o armazenamento, \def val Inicia uma função ao curry com dois argumentos, val.Type É o mesmo que Type[val], !! Converte em booleano, e booleano podem ser aplicados, então val e def are after it.

f x = f[x] = x.f.f = f[]

e em greet, ele usou name<(default "world") e hasType Str>, significa que o padrão default "world" será usado e vinculado a name. O padrão padrão especifica um valor padrão. and é outro padrão que une dois padrões. o padrão default não pode falhar enquanto hasType pode falhar. Nesse caso, lança uma exceção.

As variáveis ​​são realmente armazenamentos, que podem ser passados ​​funcionalmente, e as tabelas de armazenamento podem ser referências, criadas e destruídas à medida que os escopos mudam.

Hashes e similares serão como em Lua e JavaScript.

Se eu vou fazer uma linguagem compilada, vou criar um F # para Java, com recursos do tipo Haskell. É uma linguagem funcional pura, exceto que existe um recurso que combina Cotações e Comp Exprs para obter uma programação imperativa, escrevendo blocos semelhantes a pseudocódigo.

2
Ming-Tang

Provavelmente seria uma linguagem de paradigmas múltiplos, suportando o seguinte:

  • Programação estruturada/processual
  • Programação orientada a objetos
  • Programação funcional

Por que esses? Orientado a objetos, porque é uma ótima maneira de organizar grandes programas, especialmente para organizar os dados. Estruturado porque você nem sempre quer/precisa disso (OOP), as pessoas devem ter escolha. Funcional porque facilita a depuração de programadores e torna os programas mais claros.

Eu usaria o modelo do Python com blocos recuados para marcar blocos de código. É muito agradável e agradável de ler.

Eu roubaria muitas idéias de Python realmente porque Python é uma linguagem muito agradável. Eu pegaria isso para declaração e copiaria seus mapas, lista e tuplas.

Agora, eu provavelmente não pegaria os conceitos dinâmicos do Python: por um lado, provavelmente seria explicitamente e estaticamente digitado. Eu acho que os programas se tornam mais claros com isso. As variáveis ​​provavelmente seriam objetos com métodos, então você poderia fazer algo como str.length() para obter o comprimento de uma string. Nas definições de função, você teria que especificar o tipo de retorno e os tipos dos argumentos (suportando também alguns tipos de tipos genéricos).

Vamos voltar a copiar de Python ;-). Eu amo que é maneira de ter argumentos de procedimento opcionais, então eu provavelmente teria isso. Python no entanto não suporta sobrecarga de procedimento, eu gostaria disso.

Vamos dar uma olhada nas aulas, eu abandonaria a herança múltipla; fácil de abusar. Eu implementaria escopos privados e similares e provavelmente implementaria isso da maneira que é feita em C++. Eu também teria classes abstratas e interfaces; Eu não acredito que Python tem isso.

Seria compatível com classes internas, na verdade, eu gostaria de uma linguagem orientada a objetos muito poderosa.

Provavelmente seria interpretado. É possível obtê-lo muito rápido usando uma boa compilação JIT (eu gostaria de uma linguagem rápida, embora a produtividade do programador fosse a primeira) e a compilação é ruim para a produtividade muitas vezes. Os idiomas interpretados também promovem a independência da plataforma, algo que importa cada vez mais a cada dia.

Teria incorporado suporte a Unicode; hoje em dia a internacionalização é muito importante.

Definitivamente seria lixo coletado. Porra, eu odeio fazer o gerenciamento de memória; também não é bom para produtividade.

Finalmente, teria uma boa biblioteca padrão.

Uau, acabei de perceber o quanto eu realmente amo Python.

1
Anto

Antes de tudo, eu comprava alguns livros sobre compiladores, alguns padrões e fazia um ou dois cursos em idiomas e compiladores. Eu contribuiria com PEP se visitaria as reuniões do comitê de padrões C++. Eu contribuiria com patches para os compiladores que uso, espero que para recursos e bugs.

Depois, voltaria e olharia horrorizado para a lista apresentada agora, que é quais as direções que eu seguiria com um idioma se começasse agora:

  • Funcional , porque atualmente não sou versado em nenhuma linguagem funcional e criar uma seria uma ótima maneira de aprender uma. Caso não siga diretamente: tudo é constante .
  • Eu o preencheria com o máximo Inferência de Tipo que eu pudesse caber nele, mas com a opção de especificar interfaces explicitamente. Não tenho certeza sobre outros tipos. Isso dobra, pois todas as funções são genéricas por padrão.
  • Como você deve ter adivinhado, com Interfaces ; isto é, com tipos que fornecem apenas promessas nas operações disponíveis.
  • Dizer se o idioma é digitado forte ou fracamente não é muito significativo nesse caso, pelo que sei. Eu chamaria isso de tipo forte, pois as coisas nunca mudam quais interfaces eles implementam .
  • Teria muito suporte Design por contrato . Novamente, tanto quanto eu posso ajustar: pré-condições e pós-condições são uma obrigação; Não sei quanto os invariantes são importantes quando se trata de programação funcional.
  • Enquanto eu estou nisso, daria uma olhada nos idiomas em que você pode formalmente provar a correção e ver se consigo pegar alguma coisa a partir daí.
  • Gostaria de escrever uma biblioteca de testes impressionante . Mesmo que eu não consiga torná-lo incrível, passarei pelo menos uma quantidade considerável de tempo trabalhando nisso, pois acho que é algo que todo idioma deveria ter.
  • Quanto à sintaxe, a linguagem teria espaço em branco significativo e se pareceria muito com Python , ou seria baseado no Lojban e compartilhando grande parte da gramática e vocabulário. No primeiro caso, eu faria o possível para tornar a gramática o mais próxima possível de um CFG.
  • Eu não me importaria se as pessoas que implementaram o idioma o compilariam de antemão, JIT, interpretassem, entoassem em fogueiras ou pagassem alunos da faculdade para executar para eles. Minha própria implementação provavelmente começaria como um intérprete ou um compilador C e, eventualmente, passaria para um JITter.

Como esses pontos razoavelmente amplos provavelmente mudariam rapidamente se eu começasse a implementar a linguagem, acho que entrar em mais detalhes é desnecessário.

1
Anton Golov

Se eu tivesse tempo, projetaria uma linguagem de programação localizável baseada no Scala, para que ele tivesse a maioria de seus recursos, exceto provavelmente para XML. Meu objetivo é criar um idioma que leia quase naturalmente em idiomas com uma estrutura diferente do inglês, como o árabe (minha língua materna). Estou pensando nos seguintes recursos:

  • Uma diretiva de pré-processador #lang, Usada para informar o pré-processador da linguagem humana usada para programação. Por exemplo: #lang ar Permitiria o uso da palavra فئة Em vez de class, عرف Em vez de def e assim por diante. As palavras-chave específicas do idioma humano seriam definidas nos arquivos padrão do pré-processador.
  • O pré-processador removeria algumas palavras-chave opcionais cujo único objetivo é adicionar clareza ao código. Por exemplo, ele removeria "é composto por" em class MyClass is composed of { Para se tornar class MyClass { E remover "como" em def MyMethod(x: Int) as { para se tornar def MyMethod(x: Int) {. Em algumas línguas (humanas), isso tornaria o código muito mais fácil de entender, especialmente para os alunos.
  • O compilador permitiria o uso de notação de prefixo para acesso à propriedade. Isso pode não fazer sentido para a maioria dos falantes de idiomas baseados em latim, mas para alguns outros idiomas faz todo o sentido. Por exemplo, o acesso à propriedade em árabe é normalmente o prefixo, como em اعرض طول اسم محمد, Que é equivalente a print(length(name(Mohammad))) na programação em inglês. (Os parênteses são para maior clareza.)

Acredito que essas mudanças mínimas no pré-processador e compilador tornariam a programação muito mais simples para quem não fala inglês.

0
Hosam Aly