1 points par GN⁺ 2024-11-10 | 1 commentaires | Partager sur WhatsApp
  • λ-2D est une expérimentation de langage où le dessin lui-même fait office de code, visant à la fois des expressions visuelles difficiles à traiter avec les langages textuels et la forme esthétique des programmes
  • L’ossature du langage repose sur le lambda-calcul : il part de l’idée qu’une structure plus proche de l’évaluation que d’un ordre d’exécution prédéfini ressemble à la manière dont on regarde un dessin
  • Il utilise des symboles sur grille et des fils pour représenter le flux de données, afin d’être facile à dessiner à la main tout en restant interprétable par une machine
  • Le lambda-calcul pur étant peu pratique à utiliser, des sucres syntaxiques et des éléments interactifs ont été ajoutés, comme les nombres, les opérateurs mathématiques, les frames et les sliders
  • L’implémentation actuelle transforme un programme λ-2D en une unique expression JavaScript pour l’exécuter ; elle reste limitée par un rendu qui évoque encore un schéma de circuit, ainsi que par des défis d’apprentissage et de scan

Une expérimentation de langage pour coder par le dessin

  • λ-2D est une expérimentation de langage de programmation non verbal née de la question : « peut-on coder à travers des dessins ? »
  • Il existe déjà plusieurs familles de langages non textuels
  • Les objectifs de conception se résument en trois points
    • Tirer parti du fait que le programme est dessiné pour intégrer des fonctionnalités difficiles à réaliser avec un langage textuel
    • Éviter aussi bien un nombre de commandes trop réduit, qui rendrait même les programmes simples difficiles, qu’un nombre trop élevé, qui nuirait au minimalisme et compliquerait le traitement par vision par ordinateur
    • Faire en sorte que le programme lui-même soit visuellement attirant, au point de devenir un dessin que l’on aurait envie d’encadrer et d’accrocher

Lambda-calcul et représentation sur grille

  • λ-2D prend pour base le lambda-calcul, plutôt qu’une approche impérative ou bas niveau
  • Le lambda-calcul relève davantage de l’« évaluation » que de l’« exécution », ce qui rejoint la manière dont le regard parcourt un dessin sans ordre précis, en suivant points, lignes, formes et composition
  • La structure initiale est un système basé sur une grille
    • L’utilisateur peut tracer des lignes continues traversant plusieurs cases de la grille
    • Chaque case est finalement interprétée comme l’un des symboles d’un ensemble fini
    • C’est un compromis : facile à dessiner pour l’humain, facile à parser pour l’ordinateur

Symboles de fonctions et flux de données par fils

  • Les commandes de base du lambda-calcul ne sont qu’au nombre de deux
    • Application de fonction
    • Définition de fonction
  • λ-2D représente l’application de fonction par un symbole en forme de coupe, et la définition de fonction par la lettre grecque λ
  • Comme dans le lambda-calcul de base, une fonction prend toujours un seul argument et produit une seule sortie
  • Pour gérer plusieurs arguments, on utilise le currying, qui consiste à chaîner plusieurs fonctions
  • Les fils entre les symboles servent de canaux par lesquels circulent les données
  • À ce stade, le langage est techniquement Turing-complet, mais son usage réel est très fastidieux ; des symboles supplémentaires comme les nombres et les opérateurs mathématiques ont donc été ajoutés
    • Ces symboles supplémentaires sont du sucre syntaxique
    • On peut aussi, si on le souhaite, n’utiliser que des constructions de lambda-calcul pur, comme les entiers de Church

Frames, données de dessin et sliders

  • λ-2D cherche à prolonger plus naturellement l’expérience de Scratch, où l’on dessine des sprites dans le même éditeur avant de les utiliser directement
  • Une frame consiste à entourer de fils une zone précise du canevas et à placer un symbole d’affichage en haut à gauche
    • Les gribouillis à l’intérieur de la zone peuvent être utilisés comme données
    • Il est possible d’esquisser directement la forme d’une fonction mathématique et de l’utiliser, par exemple, dans une animation
    • La forme est traitée comme une donnée, sans étape séparée de recherche d’équation
  • Des sliders déplaçables à l’exécution ont aussi été introduits
    • Ils servent à contrôler le programme de manière paramétrique
    • D’autres éléments d’interface graphique sont aussi envisagés à l’avenir

Éditeur et symboles 5×5

  • L’idée initiale vient d’un exemple de programme dessiné à la main sur un carnet à points
  • La partie vision par ordinateur nécessaire pour scanner des programmes sur papier n’étant pas prête, un éditeur simple permettant de dessiner des programmes numériquement a d’abord été créé
  • Chaque symbole est construit en 5×5 pixels, ce qui le rend facile à placer sur un canevas en grille
  • L’utilisateur peut aussi faire des dessins à main levée, comme avec un outil crayon
  • Commencé comme une solution provisoire, l’éditeur se rapproche progressivement d’un éditeur doté de nombreuses fonctionnalités

Le problème de la sortie dans un langage purement fonctionnel

  • λ-2D étant purement fonctionnel et sans état, il est difficile d’y implémenter une instruction print classique
  • Produire une sortie revient à modifier un état ; et pour s’attendre à ce que les sorties apparaissent dans un certain ordre, il faut aussi supposer un ordre d’évaluation des expressions
  • La solution consiste à redéfinir la « sortie » de manière fonctionnelle
    • On passe un canevas vide à une fonction
    • On récupère un nouveau canevas dont les pixels ont été modifiés pour ressembler à du texte ou aux gribouillis souhaités
  • Le langage est conçu autour des canevas et des pixels, plutôt que des chaînes et des caractères

Transformation en JavaScript et visualisation de l’exécution

  • Le parseur de base transforme l’ensemble d’un programme λ-2D en une expression JavaScript équivalente
  • Le JavaScript obtenu est une unique énorme expression avec beaucoup de parenthèses ; c’est inefficace, mais cela fonctionne
  • Comme le parseur actuel produit du JavaScript et laisse au moteur JavaScript du navigateur le soin de l’exécuter, il est difficile de visualiser le processus d’exécution réel
  • En revanche, le parsing peut être facilement visualisé, et son animation peut ressembler au chemin que parcourrait un interpréteur par parcours d’arbre lors de l’exécution du programme
  • En associant un son à chaque symbole dans l’animation de parsing, on peut « entendre » l’exécution du programme comme une chanson
    • Le résultat se rapproche du son d’un étrange jeu vidéo de l’ère 8 bits
    • On peut l’essayer dans la démo en ligne via Menu > Program > Animated Run

Limites restantes et prochaines étapes

  • λ-2D a d’abord commencé comme une partie d’un projet de recherche plus large visant à dessiner des programmes au stylo sur papier et à recevoir des retours interactifs en réalité augmentée
  • Le projet devenant de plus en plus intéressant, il est devenu indépendant
  • Les objectifs initiaux ne sont pas encore entièrement atteints
    • Les programmes ont tendance à ressembler davantage à des schémas de circuits qu’à des dessins
    • Il est difficile d’être certain qu’ils seront faciles à apprendre pour le grand public
    • Il se peut qu’un système de vision par ordinateur ait aussi du mal à les scanner sans erreur
  • Après avoir davantage peaufiné λ-2D, l’équipe prévoit également de concevoir d’autres langages de programmation pouvant s’intégrer à des systèmes traitant le dessin comme du calcul
  • La version bêta de λ-2D est disponible en ligne, et le code source du parseur et de l’éditeur devrait être publié prochainement sur GitHub

1 commentaires

 
GN⁺ 2024-11-10
Avis sur Hacker News
  • Si ce genre de choses vous plaît, le métier d’ingénieur en projets d’automatisation pourrait vous sembler amusant, ou au moins familier.
    Les diagrammes de blocs fonctionnels (FBD) sont assez similaires : des blocs fonctionnels sont reliés par des lignes, et l’ordre d’exécution est défini par l’ordre des blocs. Les blocs eux-mêmes peuvent être comme des fonctions intégrées du moteur, ou des blocs composites. Le diagramme est exécuté une fois par cycle de contrôle et, en général, en l’absence de bloc de saut, chaque bloc s’exécute exactement une fois à chaque cycle de contrôle, que les entrées aient changé ou non.
    La logique de contrôle, des brasseries aux usines pétrochimiques, est implémentée de cette façon. Je travaille côté UI de systèmes de contrôle basés sur FBD, donc je vois ce genre de choses tous les jours.

    • Vous parlez de quelque chose comme un PLC, ou d’un équivalent ?
  • C’est proche de BitGrid[1], mais pas identique. Imaginez une sorte de FPGA extrêmement simplifié, avec des bits qui avancent en parallèle sur une grille.
    Cette idée pourrait avoir une utilité énorme — des pétaflops pour le grand public — ou pas ; au final, tout dépend de l’énergie que consomme une DFF dans un ASIC. Les chiffres que je cherche depuis longtemps sont la puissance statique et l’énergie nécessaire pour charger un bit.
    Le modèle de programmation est aussi un problème. Personne n’a envie de placer directement de la logique sur une grille, tout le monde veut abstraire le plus vite possible. Je n’ai pas assez de concentration pour mener cette partie à bien.
    En explorant cela, j’ai découvert l’automate cellulaire de Von Neumann[2] et les automates cellulaires de Nobili[3], que je voyais pour la première fois malgré des décennies d’intérêt pour des idées similaires. Ce domaine de l’informatique est frustrant tant il est peu découvrable.
    Les deux partagent le même fondement absurde : un ensemble de FSA définit un espace de cellules de taille infinie, et tous les FSA ont la même fonction de transition d’état ou le même ensemble de règles. Rien que cette « simplification » donne l’impression de reléguer le sujet au domaine du code golf.
    [1] https://github.com/mikewarot/Bitgrid
    [2] https://en.wikipedia.org/wiki/Von_Neumann_cellular_automaton
    [3] https://en.wikipedia.org/wiki/Nobili_cellular_automata
    Si quelqu’un veut reprendre l’idée de BitGrid, je lui en serais reconnaissant.

  • Au passage « Techniquement, à ce stade, le langage est Turing-complet, mais il est extrêmement pénible à utiliser et viole donc ma règle de conception n° 2 », mes Lambda Diagrams[1] se sont arrêtés à l’étape 1.
    En bas de cette page, il y a des liens vers toutes les autres notations graphiques du lambda-calcul que je connais, et je viens d’y ajouter celle-ci.
    [1] https://tromp.github.io/cl/diagrams.html

    • Un élément qui pourrait intéresser ce site : le combinateur Y dessiné en Lambda Diagram : https://tromp.github.io/img/cl/Y.logo.gif
    • Et pourtant, la traduction intégrée de Firefox me demande si je veux traduire cette page depuis le grec.
      C’est plutôt une belle réussite : vous pouvez maintenant prétendre avoir créé un langage qui fait dire au navigateur « pour moi, c’est du grec ! »
    • C’est aussi extrêmement difficile à lire. Les polices pixelisées et le dessin au trait ont un côté rétro, mais si l’on doit plisser les yeux pour lire les lettres ou distinguer les formes des lignes, ce n’est pas ergonomique.
      Avec l’arrivée des écrans haute résolution dans les années 90, on avait déjà laissé ce genre de choses derrière nous.
    • À mes yeux, ça ressemble à de l’écriture cunéiforme sumérienne, et je trouve ça cool.
    • Il me semble qu’il manque Alligator Eggs.
      https://worrydream.com/AlligatorEggs/
  • Ce genre de choses a aussi été tenté avec LabVIEW, et on voit bien qu’il est difficile d’aller très loin. Cela existe aussi dans les programmes de création sonore/musicale, Max [max] en étant en quelque sorte l’ancêtre.
    On peut construire quelque chose, mais cela devient vite brouillon. Est-ce agréable à regarder ? Je ne pense pas.
    [max] https://en.wikipedia.org/wiki/Max_(software)

    • Je trouve que le paradigme visuel lignes/nœuds de Max/MSP et Pure Data se défend assez bien. Il repose sur l’interface « brancher une boîte dans une autre » du matériel de musique électronique, et peut aussi refléter l’agencement de circuits électroniques.
      Un flux de signal complexe est beaucoup plus facile à suivre dans une disposition visuelle, surtout avec un diagramme où les valeurs numériques en temps réel sont animées, que dans un bloc de texte statique.
      Les versions récentes de Max/MSP proposent aussi mc, qui fournit des connexions multicanaux évitant de créer des lignes/nœuds séparés pour plusieurs signaux identiques, et ~gen ainsi que JavaScript permettent aussi des nœuds de programmation textuelle.
    • Simulink ne devrait-il pas aussi figurer dans cette liste ?
      Ces « langages de programmation par blocs » semblent prometteurs : ils abstraient en boîtes noires et permettent de créer des boîtes dans des boîtes. Je me demande si le problème vient de mauvaises implémentations, d’un mauvais usage, ou du paradigme lui-même qui ne fonctionne pas.
      Un point à prendre en compte est que ces outils sont généralement utilisés par des personnes qui ne connaissent pas la programmation ni l’abstraction. Quelqu’un qui programme bien pourrait ne pas en faire quelque chose de brouillon, mais dans ce cas il pourrait tout aussi bien écrire du code, ce qui rend la situation ambiguë.
      Je suis d’accord pour dire que LabVIEW est atroce. Pas seulement à cause de ce problème : les mises à jour cassent tout, les licences aussi, bref, c’est une source d’ennuis.
    • C’est juste une autre manière de penser ; on peut aussi écrire du code LabVIEW propre et lisible.
      Il existait une petite communauté de développeurs LabVIEW professionnels, qui écrivaient dans l’ensemble du très bon code, très lisible. C’était différent de ce à quoi la plupart des gens sont habitués, mais c’était bien.
      Cela dit, j’ai quitté cet univers il y a quelques années, car les signes indiquant que LabVIEW finirait par mourir étaient clairs, quoi qu’on puisse en faire.
  • Depuis que j’ai entendu parler pour la première fois des réseaux de Petri il y a une dizaine d’années, je m’intéresse aux spécifications formelles graphiques
    J’ai toujours eu le sentiment que, s’il existait des représentations graphiques plutôt que des notations mathématiques et des langages intimidants, les ingénieurs utiliseraient davantage les méthodes formelles. Malheureusement, chaque fois que je montrais les réseaux de Petri à d’autres ingénieurs, ils perdaient presque aussitôt tout intérêt
    Avant d’abandonner mon doctorat à l’University of York, j’ai travaillé sur quelque chose appelé RoboChart et RoboSim[1], qui pourrait en fait être plus accessible. Cela dit, c’est assez lié à la sémantique de la robotique. Comme projet personnel, j’essaie depuis quelque temps d’adapter et d’étendre RoboSim pour le rendre plus utile dans le monde des réseaux et des serveurs
    [1] https://robostar.cs.york.ac.uk/robotool/

  • J’aime vraiment beaucoup ça. Surtout le fait que ce soit implémenté en JavaScript
    Les puristes se retourneront dans leur lit ou dans leur tombe, mais au moins les étapes suivantes de visualisation et d’audio ont sûrement été facilitées. Les visuels sont superbes, et l’étape suivante semble être de traduire d’une manière ou d’une autre la structure de haut niveau de programmes existants dans ce format. Il doit bien y avoir pas mal de geeks prêts à payer pour accrocher au mur l’algorithme de Dijkstra ou l’algorithme de rétropropagation d’un réseau de neurones artificiel
    Ce que j’ai trouvé amusant, c’est que le langage est tellement purement fonctionnel et totalement sans état qu’il est impossible d’implémenter une instruction print. Produire une sortie revient à modifier un état, et s’attendre à ce que la sortie apparaisse dans un ordre précis suppose que les expressions sont évaluées dans un certain ordre
    Est-ce que ça ne veut pas simplement dire « ce n’est pas impératif » ? Cela dit, je serais curieux de voir comment l’état pourrait être encodé. On pourrait peut-être introduire des variables, par exemple icône + couleur, et aligner les phrases individuelles selon un axe ou selon les deux axes

  • « Le domaine des langages de programmation non linguistiques n’est pas inexploré »
    Dès la deuxième phrase, ça commence par une triple négation agressive

    • Et il y a aussi Scratch, non ?
  • Ça me rappelle Wireworld, de 1987. Il y a évidemment aussi un article Wikipedia [1]
    J’ai déjà vu un compteur 8 bits implémenté avec Wireworld, et c’était assez impressionnant. Cela dit, celui-ci a l’air plus concis
    [1]: https://en.wikipedia.org/wiki/Wireworld

    • Je préfère assez nettement la manière dont Zachtronics a traité le sujet dans KOHCTPYKTOP
      Mais il est difficile d’y jouer aujourd’hui. La page web[1] et la version Steam dépendaient de Flash, et il faut bricoler avec des réimplémentations tierces de Flash
      Je trouve tout de même que son implémentation du fonctionnement des semi-conducteurs est bien meilleure que Wireworld
      [1] https://www.zachtronics.com/kohctpyktop-engineer-of-the-peop...
  • Lien direct vers la démo en ligne : https://l-2d.glitch.me/

    • Ils ont vraiment enterré l’essentiel trop profondément
  • Voici d’autres environnements/langages de programmation très visuels que j’ai trouvés. Ils sont différents des autres formes de programmation visuelle qui relient des nœuds par des lignes
    On pourrait les classer autrement, mais je ne sais pas comment les appeler
    Piet https://www.dangermouse.net/esoteric/piet.html
    Turnstyle https://jaspervdj.be/turnstyle/ https://github.com/jaspervdj/turnstyle
    Markovjunior https://github.com/mxgmn/MarkovJunior
    Cellpond https://cellpond.cool/ https://github.com/TodePond/CellPond https://www.youtube.com/watch?v=xvlsJ3FqNYU
    Imagegram https://zaratustra.itch.io/imagegram
    Color Code http://colorcode.bananabanana.me/ https://www.youtube.com/watch?v=5M5hy9xsqKc Color Code 2 http://colorcode2.bananabanana.me/ https://www.youtube.com/watch?v=tTvvX4sjZWw Splaty Code http://splatycode.bananabanana.me/ https://www.youtube.com/watch?v=gd_e85lAKOs (créé par Muril Polese https://github.com/murilopolese/ http://gallery.bananabanana.me/)
    Alchemy Online https://maxbittker.github.io/alchemy-online/ https://github.com/MaxBittker/alchemy-online