| Devil'sTiger |
___alt a écrit :
Mon commentaire était pas tellement sur l'implémentation d'un DSL.
Mais si jamais ton domaine de développement est suffisamment bien défini et borné pour qu'on puisse écrire un DSL qui permet d'y développer tout ce dont on a besoin, c'est interchangeable avec un outil graphique.
Et je doute que quelqu'un "craque cette merde conceptuelle" :o
|
Je connais bien la musique. La programmation "visuelle" ca a donné ca, en gros (et c'est pareil partout autant que je sache):
- Ca a commencé il y a tres longtemps je crois que c'est presque aussi vieux que les premieres interfaces graphiques. Ca a eu, comme l'IA, un essort dans les 60/70.
- S'en suit une stagnation, et un abandon "car ca ne marche pas/trop restreint/pas assez expressif"
Et globalement ca s'arrete la pour beaucoup. Et comme pour l'IA, t'a un jour un con qui se pointe avec un truc fonctionnel et la tout le monde se rend compte que non, en fait c'était génial.
Pour ce qui est de la musique, pas un mec aurait mis un pesos la dessus dans les années 90, c'était vu comme un domaine trop pointu (a 40k samples/sec avec des PC des années 90 fallait que ce soit un minimum opti + des interfaces graphiques qui sortent plein de graphiques boutons et j'en passe).
Et un jour, un mec se pointe avec un truc a peu pres fonctionnel, capable de faire aussi bien une interface graphique que le flow de la musique en background (il s'appelle Reaktor pour ceux qui veulent voir), et pouf ca attaque super fort le marché. C'est globalement fini la prog C++ dans l'audio, il en reste hein, deja l'outil en lui-meme bien sur, mais les tres gros (genre Native Instruments) il est connu qu'ils ont leur propre pipeline graphique et font que rajouter les quelques points en C++ qui manque, mais la majorité c'est du visuel...
Et donc, justement, le "défini et borné", il faudrait commencer a envisager d'enlever le borné je pense...
theShockWave a écrit :
quand tu dis que ca enterrera "80% de la prog actuelle" est-ce que tu considères qu'on utilise déjà ce genre d'outils actuellement ?
|
Tres peu par rapport a ce qu'ils peuvent faire, et surtout, il y a UN gros point problematique: aucun n'est complet, quasi 100% sont dans la catégorie "flow" (par exemple, traitement d'une image, traitement de données/filtering).
Demande a un de ces outils de faire un webservice, qui a donc un melange "code pur" (démarré le webservice par exemple), un code d'event (un client se pointe), et un code de flow (on process ce qui le client demande), et des endpoints qui peuvent etre aussi bien de recup une donnée en BDD que de sortir un fichier excel: les rares outils qui se présentent comme capable de ca, c'est surtout une bouillie visuelle au mieux, ou impossible de le faire tout simplement.
C'est en ca que je parle de craquer le truc :o Comme pour la musique un jour un mec mettera son doigt sur le bon DSL, celui qui peut aussi bien faire une interface graphique qu'un moteur SQL, la tu seras au point ou ca va commencer a devenir intéressant. Ces exemples sont juste la pour te dire "c'est possible", ils sont suffisamment vaste et complet pour te montrer que il y en a beaucoup sous le coude en possibilitées, mais on a pas encore mis la main sur la version finale de ce genre d'outil je pense (et j'ai hate de voir ca :p )...
theShockWave a écrit :
Pour Blueprint et consorts (on a un système bien plus sympa en interne, d'ailleurs) ca reste des outils qui n'ont que très peu de chance de fonctionner en volume. Je dirais qu'on va probablement continuer à développer une plus grande variété de langages de haut niveau de ce style avec des applications (et utilisateurs) différentes, mais fondamentalement, il te faudra toujours une large part d'effort pour la conception de systèmes qui seront exposés à ces langages de script.
deux points : 1/ Tant que la performance a un impact ce système ne changera pas des masses.
2/ Les questions de parallélisation efficace ne sont en général pas aidées par ces langages (et quand ils sont adaptés pour, débugger le moindre souci dedans requiert de réinventer la roue)
|
1) C'est variable, ce que tu exprimes n'est que la raison pour laquelle on cantonne ca au flow a l'heure actuelle. Tu tombes sur des limites dans ce style. Mais si tu y penses 2sec, tu verras que ces limites ne sont la que parce qu'on ne sait pas faire mieux, ce genre d'outil n'ont aucune raison plus qu'un autre outil de bloquer sur ce genre de problématiques hormis "le mec qui l'a concu n'est pas allé assez loin". Comme dit, l'audio, tout le monde pensait que ce serait impensable, pour autant sans ligne de code aujourd'hui tu peux sortir un truc qui prend 40k samples/sec, fait plein de maths, avec une interface graphique franchement plus complexe que les meilleurs site web, et sans ligne de code (et 2 a 10% du CPU :o ).
2) Les tooling récent sont capable de rejouer les jeu de données, visuellement tu peux le faire progresser en step comme tu ferais progresser ton code avec breakpoint. C'est un peu toujours la meme tronche, ca ressemble au premier screenshot de cet article:
https://bitspark.de/blog/what-is-visual-programming
Pour ma part j'ai refait completement la pipeline de ma boite en tooling visuel custom (du "flow" donc, qui pond un code en Rust via RabbitMQ), on gere quand meme les 3/4 des news de la planete, ca a simplifié le code, réduit les bugs, ca pootre encore plus fort qu'avant (précédente toolchain en Node.JS), et surtout, a n'importe quel moment tu peux rejouer un truc X qui s'est pas bien passé, voir par quelle brique il est rentré, ressorti, et pourquoi ca a donné ca...
Et la on est entrain d'envisager de ne meme plus compiler la pipeline, car pour le moment le tooling visuel pond un gros code en rust capable de faire le flow. Mais la on est entrain de se dire que en fait, ca sert absolument a rien, le tooling visuel peut en meme temps etre le code final, sans compilation, la perte est pas dingue, et surtout, tu peux observer en live ce qui se passe. |