Lazi

Approche esthétique

L'idée est de faire un raisonnement logique qui montre que Lazi est une solution esthétique à de nombreux problèmes en développement. Émotionnelement en se bansant sur le fait que les développeurs trouve que la programmation est esthétique.

Le plan

  • Introduction
  • Les révolutions viennent souvent d'une remise en question d'un élément de base tenu pour acquis.
  • Une question ouverte est : quelles sont les domaines où il existe une solution optimale bien plus puissante ?
    • La science a montrer que le domaine du frai/faux en fait partie.
    • D'autres domaines comme "comment marcher" n'en font pas parti.
    • Le représentation des processus et des mathématiques en font-il parti ?
      • La représentation de ce qui existe en fait parti
      • Les processus et les mathématiques sont des composants de base des représentations de ce qui existe.
      • Est-ce que si les représentations de ce qui existe en font parti, les composants en feraient aussi parti ?
  • Mathématiques et informatique : une construction de base régies par la nécessité / Lazi : une base minimale et une construction régie par l'absence de limite :
    • extensibilité
    • des types non contraignants
    • pas de contrainte du langage
    • pas de contrainte dans la génération du code (notament optimisation)
    • pas de contrainte dans l'évolution du compilateur
  • L'idée tenue pour acquise est que:
    • on doit pouvoir déterminer rapidement, soit :
      • si le code source est valide
      • exécuté ou compiler rapidement
    • les fonctions informatiques et mathématiques sont différentes
    • il est normal que le langage pose des contraintes sur le code produit
    • il est normal qu'un langage pose des limites dans la structure du code source
      • pas possible d'utiliser différents languages dans une même source (ou grosse limitation)
      • pas possible d'inviter de nouvelles structures de contrôle de haut niveau
      • pas possible de manipuler des entités du langages de haut niveau (par exemple utiliser des fonctions pour créer de nouveaux types).
  • Comment enlever ces contraintes :
    • le source est un compilateur
    • les fonctions sont des fonctions mathématiques, les entrées sorties sont des interactions avec la variable U.
    • toute entité est mathématique
    • la fondation mathématique est intégrée

Le plan (abandonné):

  • Introduction sur l'esthétique, la préexistence ou la découverte, les avancées possibles, le raisonnement logique de la suite. Idée de tirer le fil par des déductions.
  • Partir du fait qu'il y a beaucoup de manière de définir des noms.
  • Déduire qu'il faudrait séparer le type de la définition.
  • Déduire que cela implique que des éléments n'ont pas de type et poser la question d'un langage avec typage optionnel et où un type peut être sans type.
  • Réflexion sur le sens des types :
    • vérifier des propriétés
    • ajouter des informations
  • Type attribué/Type déduit
  • Réflexion sur l'inexactitude de l'informatique actuelle : pi est une approximation, le type retourné par une fonction n'est pas forcément celui-là (si la fonction boucle).