Existem idiomas de nível ultra alto por aí? [fechadas]

Historicamente, uma HLL é algo como C, Fortran ou Pascal e uma VHLL é algo como Ruby ou Python. Eu estou familiarizado com os termos 4GL, 5GL, DSL e LOP, e quem não é deve ler a Wikipedia para obter as definições. Estou procurando por UHLLs.

Minha pergunta é: existem linguagens de computador por aí que são outra ordem de magnitude mais produtiva e alguém está trabalhando nelas?

Mais produtivo significa menos código criado e menos tempo do programador para alcançar um resultado, menos erros e menos depuração, vínculo conceitual mais próximo entre código e requisitos, menos esforço para modificar e manter.

O principal domínio que me interessa são os aplicativos comerciais e de consumo de uso geral, com interface gráfica do usuário ou navegador, persistência de dados e conexões com outros sistemas, como impressão e email. Outras pessoas podem muito bem se concentrar em outro lugar.

Reconheço que algumas dessas linguagens podem ser específicas do domínio e que podem ser pouco mais do que a capacidade de configuração de um aplicativo grande e capaz. As planilhas do Excel se enquadram nessa categoria.

Reconheço que alguns desses idiomas podem parecer gerais, mas ainda podem ter escopo restrito e inadequado para muitos problemas. Por exemplo, o Matlab pode não ser uma boa opção para um programa que lida principalmente com a interação do usuário e dados textuais.

Conheço alguns dos recursos que podem estar em uma UHLL, por analogia com a VHLL. Eu esperaria encontrar um ou mais dos seguintes itens (e fique à vontade para adicionar à lista):

• Um desenho de um formulário da GUI É o programa para um formulário da GUI
• Uma tabela contendo linhas, colunas e cabeçalhos É o programa de uma tabela em um banco de dados
• A lógica declarativa diz o que deve ser feito e quando, sem instruções IF
• Operações em conjuntos de dados, sem loops FOR
• Execução não sequencial, por exemplo, orientada por dados, correspondência de padrões, caminhada na árvore

A motivação para a pergunta é que estou cada vez mais cansado do trabalho duro de traduzir requisitos de negócios relativamente simples em grandes quantidades de código para atender ao que o computador deseja ou precisa. A questão é realmente encontrar outras pessoas que compartilham minha dor e estão trabalhando para aumentar o nível de idiomas e fazer com que o computador faça mais do trabalho duro. Esse foi um dos principais focos nos anos 70-80, mas ainda está acontecendo?

Estas são algumas respostas sugeridas para minha pergunta, fornecidas aqui para resumir ou enumerar os idiomas que eu conheço e que, na minha opinião, ficam aquém.

Existem muitos idiomas HLL ou VHLL e contêm recursos individuais que pertencem a um nível superior. Eu usei a maioria deles (muitas vezes mal). Eles incluem

• Lisp, com suas macros e capacidade de auto-modificar
• Haskell, com dependência de dados e correspondência de padrões
• SQL, que lida com linhas e tabelas
• Rebol, que parece inteligente, mas eu realmente não entendo
• APL (e J), ​​com suas matrizes multidimensionais e operadores ultracompactos
• C # com LINQ
• AWK / Perl / Python / Ruby com maravilhosas coleções e expressões regulares incorporadas

Esses idiomas têm muitos recursos de baixo nível para serem UHLL. O programador ainda precisa escrever muitas construções de baixo nível para qualquer programa útil.

Existem pacotes RAD / 4GL. Eu usei alguns:

• dBase / Foxpro
• Dataflex / Powerflex (meu produto)
• Acesso
• PowerBuilder

E muito mais que eu não usei. Principalmente, na melhor das hipóteses, a linguagem é HLL, mas o pacote contém uma estrutura e conexões privilegiadas entre a linguagem e o pacote, para que os aplicativos possam ser construídos rapidamente. Não sei ao certo por que essa abordagem ficou sem fôlego, mas, de qualquer forma, UHLL não é.

Existem estruturas / bibliotecas brutas. Eu usei alguns:

• Trilhos
• Java awt e swing
• .NET Windows Forms, WPF e ASP.NET.

Atualmente, esse é o estado da arte. Eles deixam o programador preso firmemente na lama da linguagem de implementação, lidando com a complexidade a cada momento. Isso não é UHLL, mas é possível que um UHLL possa ser construído sobre um deles.

Existem ferramentas de design, como o UML e o conjunto de ferramentas do Rational, que eu não conheço bem. Tanto quanto posso ver, eles ajudam a articular os requisitos de negócios, mas nunca podem substituir a etapa de programação. Não quero eliminar programadores, apenas fazer mais por unidade de tempo e esforço.

Então, tendo eliminado todos os candidatos, posso pensar, espero que alguém possa oferecer um candidato melhor.

Tarde Editar: Acho que tenho uma resposta: Wolfram Language. http://www.wolfram.com/wolfram-language/

Quase todos os critérios listados são coisas já experimentadas em ferramentas 4GL / RAD, como MS Access, Sybase Power Builder, Oracle Forms, Ruby-on-Rails (como uma amostra mais moderna para Web Apps) e muito mais (consulte a Wikipedia para obter mais informações). lista muito longa de fornecedores). E, de fato, traduzir requisitos de negócios relativamente simples em algum tipo de programa pode ser alcançado rapidamente com essas ferramentas. É por isso que a maioria dos fornecedores de ferramentas RAD anuncia seus produtos de maneira que todos pensem que já inventaram uma UHLL no seu sentido.

O problema é que, assim que você deixa o campo de requisitos " relativamente simples " e, assim que precisa manter e desenvolver programas escritos com esses ambientes, notará que alcança facilmente os limites e percebe as desvantagens deles. , ou que implementar requisitos com eles não é de forma alguma mais simples do que com qualquer outra "BVS" que você tenha em mente. IMHO, há uma boa chance de que eles acabem com qualquer melhoria de eficiência que você teve na versão 1.0 ao ir para a versão 1.1, 1.2 e 1.3 do seu programa.

Se você deseja criar software para requisitos complexos, precisará de um ambiente de programação complexo. Ainda não existe uma bala de prata , tivemos apenas melhorias graduais ao longo dos anos e não "a ordem de grandeza" na produtividade com qualquer linguagem de programação atual em relação aos seus antecessores (pelo menos nos últimos 30 anos, o que é aproximadamente o tempo em o passado quando o artigo de Brook foi publicado).

A linguagem de programação de mais alto nível que conheço é a APL . Requer um teclado especial para representar todos os símbolos necessários. Confira este vídeo , no qual o autor escreve uma implementação completa do Jogo da Vida de Conway em cerca de sete minutos.

A verdadeira questão, é claro, é "isso é prático?" Posso encontrar programadores de APL suficientes no mundo para sustentar um negócio dessa maneira? O APL será executado em telefones e tablets? Eu realmente preciso comprar todos os teclados novos de todos os meus desenvolvedores de software?

Se você realmente quer um aumento de produtividade, sua melhor aposta provavelmente é uma variante do Lisp. O Clojure é executado na JVM e possui uma porta .NET. Eu digo isso porque as pessoas já fizeram isso; o mecanismo de pesquisa Orbitz é executado no Lisp e Paul Graham administrava um negócio inteiro usando o Lisp, alegando que isso lhe dava uma vantagem significativa sobre seus concorrentes (que estavam todos usando Java).

Observe que, quanto maior o nível da sua linguagem de programação, mais removida ela é do hardware real e mais provável é que você tenha problemas de desempenho. A menos que você tenha compiladores realmente sofisticados, ainda poderá codificar partes críticas do desempenho do seu aplicativo em linguagens de desempenho mais baixo e de tempos em tempos.

E ainda existe a questão de ter uma massa crítica de desenvolvedores versada na linguagem. Apesar de todas as suas verrugas, você nunca terá problemas para encontrar um programador Java.

Observe que os idiomas principais ainda estão evoluindo. O Linq foi criado com o objetivo específico de tornar a programação orientada a dados mais declarativa. Vários novos recursos foram adicionados à linguagem C # para fazer o Linq funcionar; todos eles têm a ver com a melhoria da produtividade do desenvolvedor.

Leitura adicional
superando as médias

Acho que você sugeriu um ponto de cruzamento que limita a existência de linguagens de nível ultra alto - em algum momento, não as identificamos mais como linguagens de programação.

O melhor exemplo desse fenômeno específico que eu conheço e que talvez seja de grande interesse potencial aqui é a Linguagem de Modelagem Unificada . De fato, existem pilhas específicas de aplicativos de software que foram desenvolvidas para fazer especificamente o que você está pedindo. Ele atende a muitos de seus requisitos, mas não necessariamente da maneira que você está pensando. Ainda assim, é extremamente educativo para essa situação, pois me senti da mesma forma e minha experiência (a seguir) mudou a maneira como penso sobre esse problema.

Pessoalmente, falarei aqui do Rational Software Architect da IBM , que é uma tentativa de realmente permitir o desenvolvimento de nível ultra-alto. O objetivo é que você seja capaz de criar o conceito de negócio filosófico como um objeto, como um Ator ou Classe, atribua atributos às entidades, defina conexões, defina como as informações podem fluir através do sistema enquanto elas estão sendo trabalhadas e faça isso tudo com uma GUI.

Você pode, por exemplo, arrastar um objeto DataStore, um Ator, um formulário, algumas Classes relevantes (como Cliente, etc.), desenhar algumas linhas de conexão entre objetos usando gráficos e outros e boom: quando terminar, publique um programa de trabalho. (isso é obviamente extremamente simplificado)

De fato, o que foi feito é a formação de uma GUI complexa, uma implementação / interpretação muito completa da UML e, em seguida, ela compila o código Java / C # / VB com documentos XML completos contendo as informações gráficas da UML e também implementa / habilita Engenharia de ida e volta, para que você possa alternar entre o Modelo e o Código, para poder controlar as coisas em um nível filosófico muito alto e com um código específico de plataforma de nível muito baixo.

É tudo o que você quer e muito mais, e você não desiste de nada na troca! Direita?

Por que todo mundo não usa?!?!

... bem, veja, é isso mesmo. O que você realmente termina é um empreendimento monolítico, tudo envolve muitas partes móveis e magia, tudo é - ou às vezes não é - afetado por uma mudança em qualquer um dos muitos lugares diferentes (na GUI, XML, nível inferior código, modelos UML que são criados / definidos / mantidos em muitos níveis diferentes de modelo).

É tudo muito legal de se brincar, mas é ... como colocar isso ... ele tem uma curva de aprendizado extremamente alta, é projetado com várias disciplinas em mente, e você realmente precisa tratá-lo como uma coisa totalmente nova que permite pouca - muito pouca - generalização para outras habilidades que você já possui.

E o ponto principal é - mesmo assim, com milhões e milhões de dólares investidos no projeto de dezenas de empresas e alguns grandes nomes por trás dele, você ainda acaba com o código de estilo C na camada executável que precisa ser editado diretamente às vezes , porque algumas coisas simplesmente não fazem a tradução entre Descrições de Classes Orientadas a Objetos e UML até o nível de programação / máquina, e a automação simplesmente não pode ser concluída.

Minha experiência foi que era uma maneira incrivelmente complicada de gerar andaimes. Essa é provavelmente a coisa mais cruel que já digo sobre um empreendimento tecnológico tão imenso, mas foi o que obtive disso.

Das pessoas da indústria com quem conversei, eles disseram tristemente a mesma coisa. Eles sentiram que eles trabalharam muito na criação de documentação, incontáveis ​​diagramas, modelos, reuniões, análises, ao longo de meses e meses, e depois jogaram tudo fora e a equipe de desenvolvimento apenas escreveu o código para ele e frequentemente o tratou como ainda. Outro fichário de especificações (que ninguém mais lê mais). Então agora eles usam Java e alguns softwares de diagramação / visualização para fins especiais e o Agile, e esse é o fim dessa história.

Talvez isso seja injusto e funcione quando você faz o que é certo. Talvez, mas de consultores e professores com quem conversei afirmaram ter passado muitas horas em workshops especiais de desenvolvimento de várias semanas trabalhando para aprender o sistema, voltando para mais treinamento e literalmente passando anos para aprender como fazê-lo. trabalhar e o que vai aonde.

Mas talvez seja tudo culpa dos programadores, que eles simplesmente se recusam a aceitar que o sistema funcione tão bem e, no entanto, não é nada parecido com programação de computador. Talvez os programadores de código puro simplesmente resistam à substituição de seus empregos, como os fabricantes de velas e os tecelões de antigamente, e se recusem a realizar sua tarefa limitada de Implementation To Specification, e isso faz com que todos fiquem tão frustrados que jogam fora e dizem coisas ruins, e quase foi perfeito.

Mas ... acho que pode haver alguma verdade nisso, mas acho que na maioria das vezes simplesmente não funciona tão bem. Eu acho que transforma algo que não é realmente tão difícil na maioria das vezes (programação de computador), e torna ainda mais difícil o ponto de que, se funcionar, seria ótimo, mas, caramba, você tem muito tempo sem nada para mostrar para chegar lá!

Talvez funcione apenas em uma empresa com mais de mil equipes, e talvez ainda não estejamos lá.

Não sei.

Entretanto, um estudo do que é certo e errado com essa abordagem para as linguagens de nível ultra-alto - e acho que o tipo de UML precisa ser incluído nessa consideração - deve realmente considerar coisas como o Rational Software Architect, para evitar uma tolos em potencial

Ou talvez apenas tenhamos que dar mais 20 a 50 anos de trabalho duro. Não estou mais otimista de que uma linguagem de programação seja a restrição, mais.

E se as linguagens de programação eram a restrição antes, é por isso que as melhorias nos deram uma potencial melhoria de ordem de magnitude. Se eles não são mais uma restrição, então é mais provável que qualquer inovação seja incapaz de fornecer essa ordem de melhoria. Mas não sei dizer o futuro! Portanto, assumirei que o resto não está "em andamento", mas certamente "muito cedo para contar".

Se você pensar por um tempo, a programação de nível superior é basicamente capaz de compor partes menores que estão prontamente disponíveis e comprovadas. Até o ponto em que seu programa é um código de cola muito simples de várias bibliotecas. Talvez a cola seja uma DSL muito expressiva. Você pode fazer isso em todas as linguagens de programação.

Pessoalmente, estou começando a sentir cada vez mais que a solução para a composibilidade é - ao contrário do que você pode instintivamente sentir - não encontrada na programação orientada a objetos. Esse paradigma, assim como a programação imperativa, oferece muita liberdade aos programadores, o que, por sua vez, torna muito difícil escrever código fácil de reutilizar.

Em vez disso, acho que a programação funcional fornece primitivas muito mais adequadas à composição. Linguagens de programação funcionais puras também não permitem definir funções que tenham efeitos colaterais, o que não apenas reduz bugs ou facilita a detecção, mas também facilita a criação delas (componha-as para um sistema maior).

Se a programação funcional lhe interessar, você pode dar uma olhada em linguagens funcionais modernas como Haskell . Eu acho que o módulo Parsec fornece uma boa DSL de alto nível (é chamada de biblioteca combinadora no jargão funcional) para a análise. Também existem estruturas de programação reativa funcional para Haskell que permitem a criação de GUIs poderosas com algumas linhas de código.

Eu esperaria que Lua, usada pelo jogo para escrever suas missões e interfaces, atendesse a esse critério. Existem também linguagens específicas de domínio semelhantes (e utilitários para criação de mapas) usadas para permitir que os designers de níveis digam rápida e facilmente "quando o jogador fala com Bob, inicie a Epic Quest de Bob".

Conheço mais algumas linguagens esotéricas que se concentram em mover o código para descrever o que está acontecendo, não como deve ser feito. Alguns focam em uma abordagem muito declarativa e baseada em lógica. Alguns se concentram na programação reativa para fazer isso. Alguns se concentram nos atores para fazer isso (especialmente em coisas que precisam ser paralelamente felizes). Alguns focam-se em simplesmente tornar a sintaxe mais natural - com a afirmação de que a sintaxe natural leva a menos erros causados ​​pela tradução entre linguagem natural e código.

Nenhum é realmente promissor na medida em que produz uma ordem de magnitude mais produtiva para o desenvolvedor de classificação e arquivo.

Acho que o REBOL pode atender a todos os seus critérios. Você pode criar aplicativos GUI relativamente sofisticados em várias linhas de código - no entanto, sua "especialidade" é a criação de DSL.