Existe-t-il des langues de très haut niveau? [fermé]

Historiquement, un HLL est quelque chose comme C, Fortran ou Pascal et un VHLL est quelque chose comme Ruby ou Python. Je connais les termes 4GL, 5GL, DSL et LOP, et ceux qui ne le sont pas devraient lire Wikipedia pour les définitions. Je recherche des UHLL.

Ma question est: existe-t-il des langages informatiques qui sont d'un autre ordre de grandeur plus productifs, et quelqu'un y travaille-t-il?

Plus productif signifie moins de code créé et moins de temps de programmation pour obtenir un résultat, moins de bogues et moins de débogage, un lien conceptuel plus étroit entre le code et les exigences, moins d'efforts pour modifier et maintenir.

Le domaine principal qui m'intéresse est les applications commerciales et grand public, avec une interface graphique ou un navigateur, une persistance des données et des connexions à d'autres systèmes tels que l'impression et le courrier électronique. D'autres personnes pourraient bien se concentrer ailleurs.

Je reconnais que certaines de ces langues peuvent être spécifiques à un domaine et qu'elles peuvent être un peu plus que la capacité de configuration d'une application large et capable. Les feuilles de calcul Excel entrent dans cette catégorie.

Je reconnais que certaines de ces langues peuvent sembler générales, mais peuvent néanmoins être de portée étroite et inadaptées à de nombreux problèmes. Par exemple, Matlab peut ne pas être un bon choix pour un programme qui traite principalement de l'interaction avec l'utilisateur et des données textuelles.

Je connais certaines des fonctionnalités qui pourraient être dans un UHLL, par analogie avec VHLL. Je m'attendrais à trouver un ou plusieurs des éléments suivants (et n'hésitez pas à ajouter à la liste):

• Un dessin d'un formulaire GUI EST le programme pour un formulaire GUI
• Une table contenant des lignes, des colonnes et des en-têtes EST le programme d'une table dans une base de données
• La logique déclarative indique ce qui doit être fait et quand, sans instructions IF
• Opérations sur des ensembles de données, sans boucles FOR
• Exécution non séquentielle, par exemple pilotée par les données, correspondance de modèles, marche dans les arbres

La motivation de la question est que je suis de plus en plus fatigué du travail acharné de traduire des exigences commerciales relativement simples en grandes quantités de code pour répondre à ce que l'ordinateur veut ou a besoin. La question est vraiment de trouver d'autres personnes qui partagent ma douleur et travaillent à élever le niveau des langues et à faire en sorte que l'ordinateur fasse plus de travail. C'était un objectif majeur dans les années 1970 et 1980, mais est-ce toujours le cas?

Ce sont des suggestions de réponses à ma question, fournies ici pour résumer ou énumérer les langues que je connais, et qui, à mon avis, sont insuffisantes.

Il existe de nombreuses langues HLL ou VHLL qui contiennent des fonctionnalités individuelles appartenant à un niveau supérieur. J'en ai utilisé la plupart (souvent mal). Ils incluent

• Lisp, avec ses macros et sa capacité à s'auto-modifier
• Haskell, avec dépendance des données et correspondance de modèles
• SQL, qui traite des lignes et des tables
• Rebol, qui semble intelligent mais je ne comprends pas vraiment
• APL (et J), avec ses tableaux multidimensionnels et ses opérateurs ultra-compacts
• C # avec LINQ
• AWK / Perl / Python / Ruby avec de merveilleuses collections et expressions régulières intégrées

Ces langues ont trop de fonctionnalités de bas niveau pour être UHLL. Le programmeur doit encore écrire de nombreuses constructions de bas niveau pour tout programme utile.

Il existe des packages RAD / 4GL. J'en ai utilisé:

• dBase / Foxpro
• Dataflex / Powerflex (mon produit)
• Accès
• PowerBuilder

Et bien plus que je n'ai pas utilisé. La plupart du temps, la langue est au mieux HLL, mais le package contient un cadre et des connexions privilégiées entre la langue et le package afin que les applications puissent être construites rapidement. Je ne sais pas pourquoi cette approche s'est essoufflée, mais en tout cas UHLL ce n'est pas le cas.

Il existe des frameworks / bibliothèques bruts. J'en ai utilisé quelques-uns:

• Rails
• Java awt et swing
• Windows Forms .NET, WPF et ASP.NET.

Il s'agit actuellement de l'état de l'art. Ils laissent le programmeur fermement piégé dans le bourbier du langage d'implémentation, traitant de la complexité à chaque tour. Ce n'est pas UHLL, mais une UHLL pourrait éventuellement être construite au-dessus de l'un d'eux.

Il existe des outils de conception, comme UML et le jeu d'outils de Rational, que je ne connais pas bien. Autant que je puisse voir, ils aident à articuler les exigences métier mais ne peuvent jamais remplacer l'étape de programmation. Je ne veux pas éliminer les programmeurs, faites simplement plus de travail par unité de temps et d'efforts.

Donc, après avoir éliminé tous les prétendants, je pense, j'espère que quelqu'un d'autre pourra fournir un meilleur candidat.

Édition tardive: Je pense avoir une réponse: Wolfram Language. http://www.wolfram.com/wolfram-language/

Presque tous les critères que vous énumérez sont des choses déjà essayées dans les outils 4GL / RAD comme MS Access, Sybase Power Builder, Oracle Forms, Ruby-on-Rails (comme un exemple plus moderne pour les applications Web), et bien d'autres (voir Wikipedia pour un très longue liste de fournisseurs). Et en effet, la traduction d'exigences métier relativement simples en une sorte de programme peut être réalisée très rapidement avec ces outils. C'est pourquoi la plupart des fournisseurs d'outils RAD annoncent leurs produits d'une manière que tout le monde devrait penser qu'ils ont déjà inventé une UHLL dans votre sens.

Le hic, c'est que dès que vous quittez le terrain des exigences étant " relativement simple ", et dès que vous devez maintenir et faire évoluer des programmes écrits avec ces environnements, vous remarquerez que vous atteignez facilement les limites et notez les inconvénients de celles-ci , ou que mettre en œuvre des exigences avec eux n'est en aucune façon plus simple qu'avec n'importe quel autre "VHLL" que vous avez en tête. À mon humble avis, il y a de fortes chances que ceux-ci tuent toute amélioration d'efficacité que vous aviez dans la version 1.0 lorsque vous passez à la version 1.1, 1.2 et 1.3 de votre programme.

Si vous souhaitez créer un logiciel pour des exigences complexes, vous aurez besoin d'un environnement de programmation complexe. Il n'y a toujours pas de solution miracle , nous n'avons eu que des améliorations progressives au fil des ans et non "l'ordre de grandeur" de la productivité avec n'importe quel langage de programmation actuel par rapport à ses prédécesseurs (au moins, pour les 30 dernières années, ce qui est environ le temps en le passé lorsque l'article de Brook a été publié).

Le langage de programmation de plus haut niveau que je connaisse est APL . Il nécessite un clavier spécial pour représenter tous les symboles nécessaires. Découvrez cette vidéo , dans laquelle l'auteur écrit une implémentation complète de Game of Life de Conway en sept minutes environ.

La vraie question, bien sûr, est "est-ce pratique?" Puis-je trouver suffisamment de programmeurs APL dans le monde pour soutenir une entreprise de cette façon? APL fonctionnera-t-il sur les téléphones et les tablettes? Dois-je vraiment acheter de nouveaux claviers à tous mes développeurs de logiciels?

Si vous voulez vraiment augmenter la productivité, votre meilleur pari est probablement une variante de Lisp. Clojure s'exécute sur la JVM et possède un port .NET. Je dis cela parce que les gens l'ont déjà fait; le moteur de recherche Orbitz fonctionne sur Lisp, et Paul Graham dirigeait toute une entreprise en utilisant Lisp, affirmant que cela lui donnait un avantage significatif sur ses concurrents (qui utilisaient tous Java).

Notez que plus votre langage de programmation est avancé, plus il est éloigné du matériel réel et plus il est probable que vous rencontriez des problèmes de performances. À moins que vous n'ayez des compilateurs vraiment sophistiqués, vous pouvez toujours vous retrouver à coder de temps en temps des parties critiques de la performance de votre application dans des langages de niveau inférieur plus performants.

Et il reste encore à avoir une masse critique de développeurs versés dans le langage. Malgré toutes ses verrues, vous n'aurez jamais de problème pour trouver un programmeur Java.

Notez que les langues traditionnelles évoluent toujours. Linq a été créé dans le but spécifique de rendre la programmation basée sur les données plus déclarative. Plusieurs nouvelles fonctionnalités ont été ajoutées au langage C # pour faire fonctionner Linq; tous ont à voir avec l'amélioration de la productivité des développeurs.

Lectures supplémentaires
Battre les moyennes

Je pense que vous avez un peu fait allusion à un point de croisement qui limite l'existence des langages à ultra haut niveau - à un moment donné, nous ne les identifions plus comme des langages de programmation.

Le meilleur exemple de ce phénomène spécifique que je connaisse, et qui est peut-être d'un grand intérêt potentiel ici, est le langage de modélisation unifié . En effet, il existe des piles d'applications logicielles spécifiques qui ont été développées pour faire précisément ce que vous demandez. Il répond à bon nombre de vos exigences, mais pas nécessairement de la façon dont vous pensez. Pourtant, c'est extrêmement instructif pour cette situation, comme je l'ai ressenti de la même manière et mon expérience (qui suit) a changé ma façon de penser ce problème.

Je parlerai ici personnellement de Rational Software Architect d'IBM , qui est une tentative pour vraiment permettre le développement à ultra haut niveau. Le but est que vous puissiez créer le concept d'entreprise philosophique en tant qu'objet, tel qu'un acteur ou une classe, donner aux entités des attributs, définir des connexions, définir comment les informations peuvent circuler dans le système au fur et à mesure qu'elles sont travaillées, et faire ceci le tout avec une interface graphique.

Vous pouvez par exemple faire glisser un objet DataStore, un acteur, un formulaire, quelques classes pertinentes (comme le client, etc.), tracer des lignes de connexion entre des objets à l'aide de graphiques et autres, et boom: lorsque vous avez terminé, vous publiez un programme de travail. (c'est évidemment extrêmement simplifié)

En effet, ce qui a été fait est la formation d'une interface graphique complexe, une implémentation / interprétation très approfondie d'UML, puis il compile en code Java / C # / VB avec des documents XML complets contenant les informations graphiques UML, et ils implémentent / activent également Ingénierie aller-retour afin que vous puissiez aller et venir entre le modèle et le code afin de contrôler les choses à la fois à un niveau philosophique très élevé et à un code spécifique à la plate-forme de très bas niveau.

C'est tout ce que vous voulez, et plus encore, et vous n'abandonnez rien dans l'échange! Droite?

Pourquoi tout le monde ne l'utilise pas?!?!

... eh bien, c'est ça le truc. Ce que vous vous retrouvez en fait est une entreprise monolithique, tout implique beaucoup de pièces mobiles et de magie, tout est - ou parfois n'est pas - effectué par un changement dans de nombreux endroits différents (dans l'interface graphique, XML, niveau inférieur code, modèles UML qui sont eux-mêmes créés / définis / maintenus dans de nombreux niveaux de modèles différents).

C'est vraiment cool de jouer avec, mais c'est ... comment dire ... il a une courbe d'apprentissage extrêmement élevée, est conçu avec plusieurs disciplines à l'esprit, et vous devez vraiment le traiter comme une chose totalement nouvelle qui permet peu - très peu - de généralisation pour d'autres compétences que vous possédez déjà.

Et l'essentiel est - même dans ce cas, avec des millions et des millions investis dans le projet par des dizaines d'entreprises et de très grands noms derrière lui, vous vous retrouvez toujours avec du code de style C sur la couche exécutable qui doit être modifié directement à certains moments , car certaines choses ne font tout simplement pas la traduction entre les descriptions de classe orientées objet et UML au niveau de la programmation / machine, et l'automatisation ne peut tout simplement pas se terminer.

D'après mon expérience, c'était un moyen incroyablement compliqué de générer des échafaudages. C'est probablement la chose la plus cruelle que je dirai jamais à propos d'une entreprise technologique aussi immense, mais c'est ce que j'en ai retiré.

Des gens de l'industrie avec qui j'ai parlé, ils ont malheureusement dit la même chose. Leur sentiment était qu'ils ont fait beaucoup de travail pour créer de la documentation, d'innombrables diagrammes, modèles, réunions, analyses, au fil des mois et des mois, puis ils ont tout jeté et l'équipe de développement a juste écrit le code et souvent traité comme Un autre classeur de spécifications (que personne ne lit plus). Alors maintenant, ils utilisent simplement Java et certains logiciels de visualisation / création de diagrammes à usage spécial, et Agile, et c'est la fin de cette histoire.

C'est peut-être injuste et cela fonctionne lorsque vous le faites correctement. Peut-être, mais les consultants et professeurs avec lesquels j'ai parlé ont déclaré avoir passé de nombreuses heures dans des ateliers de développement spéciaux de plusieurs semaines à travailler pour apprendre le système, à revenir pour plus de formation et à passer des années à apprendre à le faire. travailler et ce qui va où.

Mais peut-être est-ce la faute de tous les programmeurs, qui refusent simplement d'accepter que le système fonctionne si bien et que cela ne ressemble en rien à la programmation informatique. Peut-être que les programmeurs de code pur résistent simplement à ce que leurs emplois soient remplacés, comme les fabricants de bougies et les tisserands d'autrefois, et refusent donc de faire leur tâche limitée de mise en œuvre selon les spécifications, ce qui rend les autres tellement frustrés qu'ils le jettent et disent de mauvaises choses, et c'était presque parfait.

Mais ... Je pense qu'il y a peut-être une part de vérité là-dedans, mais je pense que la plupart du temps, cela ne fonctionne pas vraiment bien. Je pense que cela transforme quelque chose qui n'est pas vraiment si difficile la plupart du temps (programmation informatique), et rend encore plus difficile au point que si cela fonctionne, ce serait génial, mais merde, vous avez longtemps sans rien à faire montrer pour y arriver!

Peut-être que cela ne fonctionnerait que dans une entreprise avec des équipes de plus de mille hommes, et peut-être que nous n'en sommes pas encore là.

Je ne sais pas.

Cependant, une étude de ce qui est bien et du mal avec cette approche des langages de très haut niveau - et je pense que le type UML doit être inclus dans une telle considération - doit vraiment considérer des choses comme Rational Software Architect, afin d'éviter un courses imbéciles potentielles.

Ou peut-être que nous devons simplement lui donner encore 20 à 50 ans de dur labeur. Je ne suis plus optimiste qu'un langage de programmation soit la contrainte, plus.

Et si les langages de programmation étaient la contrainte avant, c'est pourquoi les améliorations nous ont donné un potentiel d'amélioration de l'ordre de grandeur. S'ils ne sont plus une telle contrainte, alors toute innovation est beaucoup plus susceptible d'être incapable de fournir un tel ordre d'amélioration. Mais je ne peux pas dire l'avenir! Je suppose donc que le reste n'est pas "en préparation", mais certainement "trop ​​tôt pour le dire".

Si vous y réfléchissez un moment, la programmation de niveau supérieur consiste essentiellement à composer des parties plus petites qui sont facilement disponibles et éprouvées. Jusqu'au point où votre programme est du code de collage très simple de diverses bibliothèques. Peut-être que la colle est un DSL très expressif. Vous pouvez le faire dans à peu près tous les langages de programmation.

Personnellement, je commence de plus en plus à sentir que la solution à la composabilité n'est pas - contrairement à ce que vous ressentez instinctivement - trouvée dans la programmation orientée objet. Ce paradigme, ainsi que la programmation impérative, offrent trop de liberté aux programmeurs, ce qui rend à son tour trop difficile l'écriture de code facile à réutiliser.

Je pense plutôt que la programmation fonctionnelle fournit des primitives bien mieux adaptées à la composabilité. Les langages de programmation fonctionnels purs ne vous permettent pas non plus de définir des fonctions qui ont des effets secondaires, ce qui non seulement réduit les bogues ou facilite leur repérage, mais facilite également leur construction (composez-les dans un système plus grand).

Si la programmation fonctionnelle vous intéresse, vous pouvez jeter un œil aux langages fonctionnels modernes comme Haskell . Je pense que le module Parsec fournit une belle DSL de haut niveau (on l'appelle une bibliothèque combinatoire en jargon fonctionnel) pour l'analyse. Il existe également des cadres de programmation réactifs fonctionnels pour Haskell qui vous permettent de créer des interfaces graphiques puissantes avec quelques lignes de code.

Je m'attendrais à ce que Lua, tel qu'utilisé par le jeu pour écrire leurs quêtes et leurs interfaces, réponde à ces critères. Il existe également des langages spécifiques au domaine similaires (et des utilitaires de création de carte) utilisés pour permettre aux concepteurs de niveaux de dire rapidement et facilement "lorsque le joueur parle à Bob, lancez Bob's Epic Quest".

Je connais quelques langages plus ésotériques qui se concentrent sur le déplacement du code pour décrire ce qui se passe, pas comment c'est censé être fait. Certains se concentrent sur une approche logique très déclarative. Certains se concentrent sur la programmation réactive pour ce faire. Certains se concentrent sur les acteurs pour ce faire (en particulier pour les choses qui doivent être parallélisables). Certains se concentrent sur le simple fait de rendre la syntaxe plus naturelle - l'affirmation étant que la syntaxe naturelle conduit à moins de bugs causés par la traduction entre le langage naturel et le code.

Aucun n'est vraiment prometteur en ce qui concerne la production d'un ordre de grandeur de productivité supplémentaire pour le développeur de fichiers.

Je pense que REBOL peut répondre à tous vos critères. Vous pouvez créer des applications GUI relativement sophistiquées dans plusieurs lignes de code - mais sa "spécialité" est la création DSL.