Désolé pour ce titre trollesque, je n'aime pas ce type beaucoup trop imbu de sa personne (j'ai déjà expliqué maintes fois sur linuxfr).
Un mélange de Go et de Rust, pour moi ça n'apporte rien. Certes Rust est compliqué mais il a des avantages. Go est par contre lui inutile.
Se baser sur qbe c'est chouette, c'est simple, basique, propre mais c'est complètement expérimental. J'ai aucun projet qui compile entièrement (en utilisant cproc) pourtant je fais du C99 et C11 strictement POSIX sans aucune extension GCC. Il y a toujours une erreur quelque part (soit c'est pas supporté soit qbe part dans une boucle infinie).
Drew est quelqu'un d'assez antipathique, il n'y a qu'à le suivre sur les projets auxquels je participe (comme Alpine) ou les siens comme sway, wlroots. Quand il pense avoir raison il le fait savoir. Par conséquent pour le développement d'un langage où il est nécessaire de suivre l'avis des gens, j'ai hâte de savoir comment il va prendre en compte les remarques.
Pour moi c'est rien de plus qu'un énième projet NIH de sa part.
git is great because linus did it, mercurial is better because he didn't
C'est dur et c'est faux. La cross compilation est simple, le fait d'être statiquement compilé simplifie les déploiements, la bibliothèques standards n'est pas anémique (je ne sais pas ce qu'il en est de rust), il permet de faire de l'asynchrone plus facilement,…
Je ne suis pas un fan du langage, mais affirmer qu'il est inutile c'est vraiment du troll.
Perso sur rpi, je trouve python un peu lent à démarrer donc pour créer des cli c'est pas très agréable. Générer un binaire sur ma machine, le copier et l'exécuter est bien plus rapide et ne posera jamais de problème de dépendance.
Quand il pense avoir raison il le fait savoir.
C'est pas aussi le cas de Linus Torvalds ? Je ne connais pas Drew, hein. Je ne crois pas avoir utilisé l'un de ses projets.
Posté par arnaudus .
Évalué à 5.
Dernière modification le 26 avril 2022 à 17:44.
Si tu vas par là, est-ce par principe un nouveau langage de programmation n'a pas de très fortes chances d'être inutile?
Bien sûr, dans le détail, tu peux toujours imaginer des langages expérimentaux qui implémentent des concepts nouveaux, ou des langages spécialisés qui répondent à un besoin récent (par exemple, machine learning…).
Par contre, d'une manière générale, lancer en 2022 un langage qui est plus mieux que les autres et qui reprend les concepts de A, B, et C, avec une syntaxe simplifiée, ça me semble très probablement fumeux. Parce que même dans l'hypothèse où le langage est bien fait, il part avec tellement de retard que de manière complètement pragmatique, c'est très risqué de partir sur cette piste : difficile de trouver des contributeurs et des développeurs, support et portabilité du compilateur aléatoire, bibliothèques faméliques, bugguées, non optimisées… Et un risque certain d'un arrêt du support d'ici quelques années.
Après, c'est toujours pareil, qui ne tente rien n'a rien. Mais franchement, si on veut faire quelque chose d'utile pour la communauté, il y a peut-être mieux à faire que de créer un nouveau langage de programmation.
En tout cas, je ne me lasserai jamais des ridiculités cosmétiques qui accompagnent tout projet de nouveau langage. Genre, regardez, il existait #include, using(), library(), module(), package(), \usepackage(), et bah mon nouveau langage c'est use:: pour inclure une bibliothèque. Et puis pour définir une fonction, c'est pas def truc:, ni sub truc { }, ni func truc() { }, ni int truc() { }, c'est fn truc() = { }.
J'ai parcouru vite fait le tutoriel, je trouve ça très peu lisible en fait et presque charabiesque, pas très convaincu. Je trouve en particulier l'initialisation des structures particulièrement "élégante":
let c: struct {x: int,y: int,} = struct {x: int = 10,y: int = 20,};
Il n'y a aucun doute, une telle ergonomie ne peut venir que des progrès récents en psychologie des interfaces humain/ordinateur. Inégalé dans d'autres langages, ça valait le coup d'attendre 2022 pour avoir ça. (j'espère que vous avez noté la position des virgules, la perfection jusque dans les détails. J'ose imaginer qu'elles sont facultatives, mais je n'en sais rien).
est-ce par principe un nouveau langage de programmation n'a pas de très fortes chances d'être inutile?
Dans ce que ça apporte à celui qui l'écrit :
une meilleure compréhension des concepts derrière chaque fonctionnalité du langage
apprentissage
Ensuite, selon le but du langage de programmation, cela te permet de répondre à un besoin que tu as identifié (Domain Specific Language), ou de fournir une implémentation différente à des concepts existant (donc performances différentes, etc…).
C'est jamais inutile de faire un nouveau langage.
Mais franchement, si on veut faire quelque chose d'utile pour la communauté, il y a peut-être mieux à faire que de créer un nouveau langage de programmation.
Pour les arguments que j'ai cité ci-dessus. C'est jamais inutile.
En tout cas, je ne me lasserai jamais des ridiculités cosmétiques qui accompagnent tout projet de nouveau langage. Genre, regardez, il existait #include, using(), library(), module(), package(), \usepackage(), et bah mon nouveau langage c'est use:: pour inclure une bibliothèque. Et puis pour définir une fonction, c'est pas def truc:, ni sub truc { }, ni func truc() { }, ni int truc() { }, c'est fn truc() = { }.
C'est assez ridicule comme remarque. Ce qui est important dans un langage de programmation, c'est la facilité de réutiliser les design patterns que tu connais déjà, et la facilité que tu as pour en apprendre d'autres.
Un langage de programmation c'est avant tout représenter des algorithmes, de la logique métier et de la glue entre tout ça (à l'aide de design pattern).
La syntaxe, c'est accessoire, et au bout d'un moment cela ne devrait pas te poser problème.
Que j'écrive func, function, fun, fn, on a compris. Pareil pour #include, import, use, require, …
Discuter de la syntaxe, c'est comme discuter des goûts et des couleurs. Ça sert à rien.
Apparemment, tu as une conception assez "masturbatoire" du développement d'un langage de programmation. Ça fait plaisir au dev, ça lui apprend des choses, etc. Pourquoi pas, c'est un projet libre, si ça n'intéresse que lui, tant mieux. Mais c'est pas avec ce genre de raisonnements que tu vas avoir des utilisateurs.
Discuter de la syntaxe, c'est comme discuter des goûts et des couleurs. Ça sert à rien.
La syntaxe, c'est l'interface utilisateur d'un langage de programmation. Ce n'est pas une histoire de goût, c'est une histoire d'ergonomie. Un langage est un outil, pas une œuvre d'art. Si tu conçois un marteau dont le manche file des ampoules aux utilisateurs, tu vas dire "ah non critiquez pas c'est une histoire de goûts". Bah c'est un peu plus compliqué que ça, non?
Ma remarque ne visait qu'à remarquer l'ingéniosité à aller inventer une grammaire qui n'existe pas dans un autre langage pour faire quelque chose que tous les langages font. Est-ce que ça ne reflète pas simplement une certaine vanité? Quel intérêt peut avoir fn myfunc() = {} (à part lever une ambigüité syntaxique, ce qui serait plus un problème d'élégance que de vanité).
Mais bon, je reformule ma remarque pour que ça soit moins péremptoire : "Je ne suis évidemment pas la cible de ce langage, et je le trouve inélégant et vaniteux". Je n'essaye pas de dénier au créateur du langage le droit de créer un langage et de lui affubler la syntaxe qu'il souhaite.
Discuter de la syntaxe, c'est comme discuter des goûts et des couleurs. Ça sert à rien.
Je ne suis pas d'accord du tout. Tu montre une toute petite partie de ce qu'est la syntaxe et tu en déduit que ce n'est que de la cosmétique, mais regarde par exemple un sujet qui a était intégré dans pleins de langages ces dernières années les lambdas/closures/fonction anonymes. La syntaxe joue énormément sur l'usage. Pour présenter 2 cas diamétralement opposés :
En groovy la syntaxe des lambdas c'est :
{inti->i+4}// peut s'écrire{it+4}
En python c'est :
lambdai:i+4
Et c'est très strict, on ne peut n'avoir qu'une seule expression dans une lambda.
Je pensais au départ que c'était une volonté de ne pas créer "d'abus", d'en limiter l'usage, mais non, c'est parce qu'ils n'ont pas trouvé de façon pythoniquement acceptable de représenter des lambdas multiligne.
Résultat c'est très peu utilisé en python là où groovy a du succès1 pour les DSL qu'il permet de produire notamment grâce aux lambdas.
Mais tu as d'autres exemples, le Duff's device existe parce que la syntaxe est assez souple et je présume qu'à la création du C ils n'avaient pas en tête ce pattern.
entendons-nous bien je ne dis pas que groovy a du succès et pas python, mais que si groovy n'a pas sombré dans l'oubli c'est pour cette capacité à avoir une syntaxe souple entre autre pour les lambdas ↩
Si tu vas par là, est-ce par principe un nouveau langage de programmation n'a pas de très fortes chances d'être inutile?
Non ce n'est pas du tout ce que j'ai dit. Je l'ai dit pour Go et je le pense aussi pour D, ce sont deux langages qui n'apportent rien de nouveau. Go fait le taf mais n'est pas élégant, il a un garbage collector, la gestion des paquets a été un foutoir monumental et le support des generics a mis une décénnie à arriver. Il y a encore d'autres raisons qui font que c'est un langage qui à mon sens inutile.
Je n'aime pas spécialement Rust personnellement, mais je ne peux pas nier qu'il favorise grandement le développement d'applications bas niveau performantes avec la robustesse en plus. Ça c'est un langage nouveau utile.
Après, c'est toujours pareil, qui ne tente rien n'a rien. Mais franchement, si on veut faire quelque chose d'utile pour la communauté, il y a peut-être mieux à faire que de créer un nouveau langage de programmation.
100% d'accord, on pourrait dire la même chose des frameworks Javascript.
git is great because linus did it, mercurial is better because he didn't
En mettant de côté les prises de position du bonhomme, c'est si nul que ça Sway et Sourcehut ? J'avais l'impression que c'était des projets qui fonctionnaient bien, en tout cas mieux que les tunnels trop étroits et les autopilotes de Musk.
Posté par nlgranger .
Évalué à 2.
Dernière modification le 27 avril 2022 à 20:07.
Sway n'est pas mauvais mais les écrits de Vault sont en contradiction avec la réalité:
il prétendait que du C bien écrit est mieux que les langages plus moderne et plus à la mode. Vu le nombre de segfaults remontés par les utilisateurs, c'est peut-être plus difficile qu'il n'y parait…
Je ne peux pas parler des sourcehut mais sway fonctionne bien.
Cela dit je comparais les personnes vis à vis de leurs interactions sociales, pas ce qu'ils ont produit. On ne peut pas dire que c'est Elon Musk qui développe personnellement les Teslas, spaceX ou les hyperloops de toute manière. Je crois que la seule chose qu'Elon Musk a développé personnellement, ce sont des jeux vidéos en basic et le site web de sa première startup, zip2.
# Aucun intérêt
Posté par David Demelier (site web personnel) . Évalué à 5.
Désolé pour ce titre trollesque, je n'aime pas ce type beaucoup trop imbu de sa personne (j'ai déjà expliqué maintes fois sur linuxfr).
Un mélange de Go et de Rust, pour moi ça n'apporte rien. Certes Rust est compliqué mais il a des avantages. Go est par contre lui inutile.
Se baser sur qbe c'est chouette, c'est simple, basique, propre mais c'est complètement expérimental. J'ai aucun projet qui compile entièrement (en utilisant cproc) pourtant je fais du C99 et C11 strictement POSIX sans aucune extension GCC. Il y a toujours une erreur quelque part (soit c'est pas supporté soit qbe part dans une boucle infinie).
Drew est quelqu'un d'assez antipathique, il n'y a qu'à le suivre sur les projets auxquels je participe (comme Alpine) ou les siens comme sway, wlroots. Quand il pense avoir raison il le fait savoir. Par conséquent pour le développement d'un langage où il est nécessaire de suivre l'avis des gens, j'ai hâte de savoir comment il va prendre en compte les remarques.
Pour moi c'est rien de plus qu'un énième projet NIH de sa part.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Aucun intérêt
Posté par barmic 🦦 . Évalué à 10.
C'est dur et c'est faux. La cross compilation est simple, le fait d'être statiquement compilé simplifie les déploiements, la bibliothèques standards n'est pas anémique (je ne sais pas ce qu'il en est de rust), il permet de faire de l'asynchrone plus facilement,…
Je ne suis pas un fan du langage, mais affirmer qu'il est inutile c'est vraiment du troll.
Perso sur rpi, je trouve python un peu lent à démarrer donc pour créer des cli c'est pas très agréable. Générer un binaire sur ma machine, le copier et l'exécuter est bien plus rapide et ne posera jamais de problème de dépendance.
C'est pas aussi le cas de Linus Torvalds ? Je ne connais pas Drew, hein. Je ne crois pas avoir utilisé l'un de ses projets.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aucun intérêt
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Pourtant les gens l'utilisent (plus que Rust) !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Aucun intérêt
Posté par jseb . Évalué à 10.
« il y a deux sortes de langages informatique : ceux que tout le monde déteste, et ceux que personne n'utilise. »
(à dire sur le même ton que « il y a les gens qui ont un flingue et ceux qui ont une pelle »)
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Aucun intérêt
Posté par lolop (site web personnel) . Évalué à 2.
Bah, les gens ont utilisé aussi beaucoup Java… une force de frappe commerciale certaine.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Aucun intérêt
Posté par arnaudus . Évalué à 5. Dernière modification le 26 avril 2022 à 17:44.
Si tu vas par là, est-ce par principe un nouveau langage de programmation n'a pas de très fortes chances d'être inutile?
Bien sûr, dans le détail, tu peux toujours imaginer des langages expérimentaux qui implémentent des concepts nouveaux, ou des langages spécialisés qui répondent à un besoin récent (par exemple, machine learning…).
Par contre, d'une manière générale, lancer en 2022 un langage qui est plus mieux que les autres et qui reprend les concepts de A, B, et C, avec une syntaxe simplifiée, ça me semble très probablement fumeux. Parce que même dans l'hypothèse où le langage est bien fait, il part avec tellement de retard que de manière complètement pragmatique, c'est très risqué de partir sur cette piste : difficile de trouver des contributeurs et des développeurs, support et portabilité du compilateur aléatoire, bibliothèques faméliques, bugguées, non optimisées… Et un risque certain d'un arrêt du support d'ici quelques années.
Après, c'est toujours pareil, qui ne tente rien n'a rien. Mais franchement, si on veut faire quelque chose d'utile pour la communauté, il y a peut-être mieux à faire que de créer un nouveau langage de programmation.
En tout cas, je ne me lasserai jamais des ridiculités cosmétiques qui accompagnent tout projet de nouveau langage. Genre, regardez, il existait #include, using(), library(), module(), package(), \usepackage(), et bah mon nouveau langage c'est use:: pour inclure une bibliothèque. Et puis pour définir une fonction, c'est pas def truc:, ni sub truc { }, ni func truc() { }, ni int truc() { }, c'est fn truc() = { }.
J'ai parcouru vite fait le tutoriel, je trouve ça très peu lisible en fait et presque charabiesque, pas très convaincu. Je trouve en particulier l'initialisation des structures particulièrement "élégante":
let c: struct {x: int,y: int,} = struct {x: int = 10,y: int = 20,};
Il n'y a aucun doute, une telle ergonomie ne peut venir que des progrès récents en psychologie des interfaces humain/ordinateur. Inégalé dans d'autres langages, ça valait le coup d'attendre 2022 pour avoir ça. (j'espère que vous avez noté la position des virgules, la perfection jusque dans les détails. J'ose imaginer qu'elles sont facultatives, mais je n'en sais rien).
[^] # Re: Aucun intérêt
Posté par Thomas Douillard . Évalué à 2.
C’est aussi « fn » Rust, par contre il n’y a pas d’opérateur = dans la définition : https://doc.rust-lang.org/book/ch03-03-how-functions-work.html
J’imagine que le « = » peut se justifier si les noms de fonctions sont des variables et qu’on peut dynamiquement changer, sinon je vois pas l’intérêt.
[^] # Re: Aucun intérêt
Posté par David Delassus (site web personnel) . Évalué à 1.
Dans ce que ça apporte à celui qui l'écrit :
Ensuite, selon le but du langage de programmation, cela te permet de répondre à un besoin que tu as identifié (Domain Specific Language), ou de fournir une implémentation différente à des concepts existant (donc performances différentes, etc…).
C'est jamais inutile de faire un nouveau langage.
Pour les arguments que j'ai cité ci-dessus. C'est jamais inutile.
C'est assez ridicule comme remarque. Ce qui est important dans un langage de programmation, c'est la facilité de réutiliser les design patterns que tu connais déjà, et la facilité que tu as pour en apprendre d'autres.
Un langage de programmation c'est avant tout représenter des algorithmes, de la logique métier et de la glue entre tout ça (à l'aide de design pattern).
La syntaxe, c'est accessoire, et au bout d'un moment cela ne devrait pas te poser problème.
Que j'écrive
func,function,fun,fn, on a compris. Pareil pour#include,import,use,require, …Discuter de la syntaxe, c'est comme discuter des goûts et des couleurs. Ça sert à rien.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Aucun intérêt
Posté par arnaudus . Évalué à 3.
Apparemment, tu as une conception assez "masturbatoire" du développement d'un langage de programmation. Ça fait plaisir au dev, ça lui apprend des choses, etc. Pourquoi pas, c'est un projet libre, si ça n'intéresse que lui, tant mieux. Mais c'est pas avec ce genre de raisonnements que tu vas avoir des utilisateurs.
La syntaxe, c'est l'interface utilisateur d'un langage de programmation. Ce n'est pas une histoire de goût, c'est une histoire d'ergonomie. Un langage est un outil, pas une œuvre d'art. Si tu conçois un marteau dont le manche file des ampoules aux utilisateurs, tu vas dire "ah non critiquez pas c'est une histoire de goûts". Bah c'est un peu plus compliqué que ça, non?
Ma remarque ne visait qu'à remarquer l'ingéniosité à aller inventer une grammaire qui n'existe pas dans un autre langage pour faire quelque chose que tous les langages font. Est-ce que ça ne reflète pas simplement une certaine vanité? Quel intérêt peut avoir
fn myfunc() = {}(à part lever une ambigüité syntaxique, ce qui serait plus un problème d'élégance que de vanité).Mais bon, je reformule ma remarque pour que ça soit moins péremptoire : "Je ne suis évidemment pas la cible de ce langage, et je le trouve inélégant et vaniteux". Je n'essaye pas de dénier au créateur du langage le droit de créer un langage et de lui affubler la syntaxe qu'il souhaite.
[^] # Re: Aucun intérêt
Posté par barmic 🦦 . Évalué à 3.
Je ne suis pas d'accord du tout. Tu montre une toute petite partie de ce qu'est la syntaxe et tu en déduit que ce n'est que de la cosmétique, mais regarde par exemple un sujet qui a était intégré dans pleins de langages ces dernières années les lambdas/closures/fonction anonymes. La syntaxe joue énormément sur l'usage. Pour présenter 2 cas diamétralement opposés :
En groovy la syntaxe des lambdas c'est :
En python c'est :
Et c'est très strict, on ne peut n'avoir qu'une seule expression dans une lambda.
Je pensais au départ que c'était une volonté de ne pas créer "d'abus", d'en limiter l'usage, mais non, c'est parce qu'ils n'ont pas trouvé de façon pythoniquement acceptable de représenter des lambdas multiligne.
Résultat c'est très peu utilisé en python là où groovy a du succès1 pour les DSL qu'il permet de produire notamment grâce aux lambdas.
Mais tu as d'autres exemples, le Duff's device existe parce que la syntaxe est assez souple et je présume qu'à la création du C ils n'avaient pas en tête ce pattern.
entendons-nous bien je ne dis pas que groovy a du succès et pas python, mais que si groovy n'a pas sombré dans l'oubli c'est pour cette capacité à avoir une syntaxe souple entre autre pour les lambdas ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aucun intérêt
Posté par xcomcmdr . Évalué à 2.
Non. C'est super important la syntaxe. Un code est bien plus souvent lu que écrit.
C'est pas pour rien que la syntaxe !! à la fin du nom d'un paramètre afin de péter une exception en cas de null vient d'être rejetée en C#, par exemple. Ça n'avait aucun sens au regard de l'historique du langage, et ce pour un intérêt très vague.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Aucun intérêt
Posté par David Demelier (site web personnel) . Évalué à 4.
Non ce n'est pas du tout ce que j'ai dit. Je l'ai dit pour Go et je le pense aussi pour D, ce sont deux langages qui n'apportent rien de nouveau. Go fait le taf mais n'est pas élégant, il a un garbage collector, la gestion des paquets a été un foutoir monumental et le support des generics a mis une décénnie à arriver. Il y a encore d'autres raisons qui font que c'est un langage qui à mon sens inutile.
Je n'aime pas spécialement Rust personnellement, mais je ne peux pas nier qu'il favorise grandement le développement d'applications bas niveau performantes avec la robustesse en plus. Ça c'est un langage nouveau utile.
100% d'accord, on pourrait dire la même chose des frameworks Javascript.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Aucun intérêt
Posté par Psychofox (Mastodon) . Évalué à 3.
Je vois Drew DeVault comme le Elon Musk du logiciel libre. Le pognon en moins.
[^] # Re: Aucun intérêt
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4.
En mettant de côté les prises de position du bonhomme, c'est si nul que ça Sway et Sourcehut ? J'avais l'impression que c'était des projets qui fonctionnaient bien, en tout cas mieux que les tunnels trop étroits et les autopilotes de Musk.
[^] # Re: Aucun intérêt
Posté par nlgranger . Évalué à 2. Dernière modification le 27 avril 2022 à 20:07.
Sway n'est pas mauvais mais les écrits de Vault sont en contradiction avec la réalité:
il prétendait que du C bien écrit est mieux que les langages plus moderne et plus à la mode. Vu le nombre de segfaults remontés par les utilisateurs, c'est peut-être plus difficile qu'il n'y parait…
[^] # Re: Aucun intérêt
Posté par Psychofox (Mastodon) . Évalué à 3.
Je ne peux pas parler des sourcehut mais sway fonctionne bien.
Cela dit je comparais les personnes vis à vis de leurs interactions sociales, pas ce qu'ils ont produit. On ne peut pas dire que c'est Elon Musk qui développe personnellement les Teslas, spaceX ou les hyperloops de toute manière. Je crois que la seule chose qu'Elon Musk a développé personnellement, ce sont des jeux vidéos en basic et le site web de sa première startup, zip2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.