Depuis quelques temps, on voit apparaître de nouveaux langages à tout faire : Go, Rust et Swift sont les plus connus, mais il en existe d'autres.
The V Programming Language
Sans pointeur nul, sans comportement non défini et pouvant s'apprendre en un week end, V devrait devenir rapidement populaire chez les reptiliens.
Zig
Proche de Go, mais avec une gestion manuelle de la mémoire et une concurrence via async/await, ce drôle de Zig peut aussi compiler… du C !
Crystal
Vous avez toujours rêvé d'un Ruby avec du typage statique? Non ? Heu et bien les auteurs de Crystal l'ont fait quand même.
Nim
Plus secret, Nim ressemble lui à un Python avec du typage statique. Vous n'en aviez pas rêvé non plus?
Mais quel langage voyez-vous donc en songe la nuit?
# Jeremy
Posté par jmiven . Évalué à 6.
Et surtout, quel langage se prendra les pieds dans le tapis ?
# V is for vapoware ?
Posté par karteum59 . Évalué à 5.
N.B. je lis de manière récurrente que V est un vaporware (exemple arbitraire ici mais ce n'est pas le seul). Compte tenu du niveau de compétence dev bien plus élevé que le mien de la part desdits commentateurs sur HN, en ce qui me concerne je ne prendrai pas le risque d'investir du temps sur ce langage à ce stade (contrairement à Zig/Crystal/Nim qui me semblent tous réellement intéressants. Je rajouterais Julia dans la liste des langages intéressants en ce qui me concerne (pas forcément uniquement pour du calcul scientifique), même si ce dernier a aussi son lot de controverses :)
[^] # Re: V is for vapoware ?
Posté par reno . Évalué à 4.
Pour ce qui est de V, le blog que tu pointes date de 2019 et le langage a continué d'être développé depuis.. Donc vaporware est trop fort, survendu ça probablement.
Pour Julia, il me semble qu'il n'y a pas d'interpréteur? Pour un langage qui est pensé pour une utilisation REPL c'est surprenant.
Et aussi ils ont fait des grosses boulettes, en voila une:
-il disent qu'ils sont un langage générique
-leur tableaux commençant a l'index 1
-mais il y a une librairie qui permet de faire des tableaux avec des index de début arbitraire
-leur système de typage ne permet pas de différencier les 2 types de tableaux
--> il y a des librairies qui hardcode l'index commençant à 1 et ce qui veut dire qu'elles ne fonctionnent pas avec les tableaux avec index arbitraire :-(
Pour un langage dont le point fort supposé est la combinaison des librairies (Dispatch multiple) ça fait désordre..
Ça s'appelle foncer droit dans le mur et être surpris qu'on a des problèmes ensuite..
Ils auraient pas pu utiliser des tableaux avec des index de début arbitraire (à la Ada) dès le début plutôt que de reléguer ça à une librairie???
[^] # Re: V is for vapoware ?
Posté par David Delassus (site web personnel) . Évalué à 8.
Je ne classerai pas ça comme une boulette (ni grosse ni petite).
C'est un choix subversif certes, mais rappelons que du point de vue des maths (point de vue que prend Julia), c'est l'index 0 qui est bizarre.
Aussi, l'argument souvent avancé pour l'index 1 vs l'index 0 c'est le "off by one error" qui est censé ne pas arriver avec l'index 0.
Oui bon la je peux plus les défendre…
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: V is for vapoware ?
Posté par François (site web personnel) . Évalué à 2.
Dire qu'en math c'est mieux quand ça commence à 1 c'est abusif. Si on parle des termes d'une suite oui, peut être, car il est usuelle d'indicer le premier terme avec 1, mais il existe également tout un tas de situation on il est préférable de commencer à 0. Un exemple parmi d'autre, la transformée de Fourier discrète. Pour avoir pratiquer les deux (matlab puis python), je préfère commencer à 0, ça génère moins de bug dans mon code.
[^] # Re: V is for vapoware ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Est-ce uniquement moi ? En tout cas il me semble que l'usage soit bien souvent d'utiliser plutôt l'indice 0 aussi bien en maths qu'en physique : les
, 
, 
et autres 
…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: V is for vapoware ?
Posté par karteum59 . Évalué à 5.
J'allais dire la même chose : c'est un choix (qui ne fait pas l'unanimité, et pour être franc c'est un des choix qui personnellement me déplait), mais pas une "boulette" !
Fortran, Matlab, Lua (pour ne citer qu'eux) font le même choix. ça demande une petite gymnastique intellectuelle pour s'adapter quand on est habitué aux langages qui indexent à partir de 0, mais rien d'insurmontable ;)
[^] # Re: V is for vapoware ?
Posté par Thomas Douillard . Évalué à 3.
Il y a le même genre de problèmes en lua : les tableaux sont supposés commencer à "1" si je me souviens bien (toujours un doute).
Mais, un tableau est un objet comme un autre, comme dans d’autres langages dynamiques, et du coup tu peux avoir des attributs arbitraires et donc indicer avec 0 ou -1 sans problèmes, avec la même syntaxe. D’ou la potentielle surprise quand tu tentes d’utiliser les trucs pour itérer sur les valeurs d’un tableau, qu’on pourrait naivement penser comme les valeurs de clé entières … ça rate le 0 ou les valeurs négatives, et de mémoire il y a des problèmes si il y a des « trous » entre deux valeurs(?)
[^] # Re: V is for vapoware ?
Posté par David Delassus (site web personnel) . Évalué à 4.
En Lua tu as des tables. L'opérateur
#retourne le nombre d'éléments dans la table. Une table ne peut pas contenirnil(et donc assignernila un élément de la table le supprime de la table). Les clés d'une tables peuvent être des nombres, des strings, des fonctions (oui oui), etc…Lorsque l'on créé une table sans préciser les clés, c'est comme si on utiliser des nombres en partant de 1:
Pour parcourir une table on utilise:
Lua n'a donc pas vraiment de "liste" / "tableau". Que des dictionnaires, donc utiliser les indices pour parcourir une table n'est vraiment pas la bonne pratique.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: V is for vapoware ?
Posté par Thomas Douillard . Évalué à 3.
Utiliser des indices est la seule manière qui fonctionne vraiment si il y a des trous dans le tableau et/ou si tu veux une valeur à un indice 0 en gardant l’ordre.
[^] # Re: V is for vapoware ?
Posté par dourouc05 (site web personnel) . Évalué à 5.
Non, pas besoin : tout est compilé à la volée (avec optimisations et tout). Ils ont des projets pour déployer un vrai interpréteur, mais ça ne semble pas si important.
Aucun problème : les tableaux standard sont des
Vector,OffsetArraypermet de changer les indices (pas juste commencer à zéro). Ce dont tu parles, c'est d'incompétents qui utilisent une interface trop générique pour leurs capacités de codage (AbstractVectorn'indique jamais qu'un tableau commence avec l'indice 1, mais les types doivent implémenteraxess'ils ne respectent pas ce point). Ce n'est pas un problème de langage, mais d'utilisateurs… Et Julia est loin d'être le seul langage avec un problème de gens qui ne respectent pas les interfaces qu'ils implémentent ou utilisent.C'est comme ça que le langage a été conçu : pas trop de choses dans la bibliothèque standard ou les types primitifs, mais laisser un maximum de liberté aux utilisateurs. Notamment, pourquoi imposer une seule manière d'implémenter cette fonctionnalité ? De ce que j'ai vu, Ada ne permet pas de surcharger l'opérateur d'indexation sur un tableau : comment implémenter quelque chose comme https://github.com/JuliaArrays/FFTViews.jl ? Je n'ai pas vu de bibliothèque proposant un type DataFrame (comme en R, Python, Julia, etc.) en Ada, alors que ces API utilisent énormément l'opérateur d'indexation.
[^] # Re: V is for vapoware ?
Posté par David Demelier (site web personnel) . Évalué à 3.
Ça serait dommage, V m'intéresse plus que zig qui est un poil plus complexe. Mais c'est vrai que sa documentation est assez hypoglycémique.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: V is for vapoware ?
Posté par karteum59 . Évalué à 3. Dernière modification le 30 septembre 2022 à 00:33.
Moi je trouve qu'elle est complètement glucose :)
[^] # Re: V is for vapoware ?
Posté par Andréas Livet . Évalué à 4.
Je suis d'assez près le développement de V (j'ai même écris toute une dépêche l'an dernier que j'avais prévu de poster pour la v0.3, faut juste que je la mette à jour) et c'est clairement pas un vapoware.
Par contre, ce qui est assez gênant c'est qu'ils annoncent des choses assez fortes sur leur site et cela nuit au projet je trouve. Car après, forcément y a des personnes qui s'attendent à que ce qui soit écrit soit vrai et c'est toujours discutable.
Exemple avec les temps de compile, ils donne un nombre de lignes/s compilées, mais ça dépend du code que tu fais.
Ils disent que les fonctions sont "pures" par défaut excepté les I/O, donc c'est pas pure…
Ils disent que le système de gestion de la mémoire est super novateur, résultat au final ils utilisent Boehm GC et le système
autofreeest pas au point.Bref, y a beaucoup de choses à redire sur leur communication.
Après, franchement sinon j'aime beaucoup la syntaxe et le principe de transpiler en C. Ca permet d'écrire du code avec un langage "moderne" et de bénéficier d'une portabilité énorme. Genre, j'ai commencé à dev des trucs sur Nintendo DS avec et quasiment sans effort (dans le sens où ça a marché du premier coup).
V a pris plein de bonnes choses d'autres langage et le résultat est intéressant je trouve. Par contre, l'équipe est assez réduite et ne bénéficie pas du même engouement que ce qu'il se passe autour de Zig (qui est aussi un super langage ! ) par exemple. Ce qui forcément se fait sentir dans le rythme d'évolution du langage et des outils. La lib standard manque de cohérence parfois aussi.
# tu mélange un peu les choux et les carottes
Posté par reno . Évalué à 4.
Je ne mettrai pas des langages avec GC: Crystal, Nim, dans la même catégorie que les langages avec gestion manuelle de la mémoire: Zig, V.
Enfin pour V je ne sais pas trop ce qu'il compte faire sa doc n'est pas terrible (enfin la fois ou j'avais regardé il y a longtemps).
Odin mériterai d'être ajouté à la liste: un C-like qui se focalise plus sur la programmation des jeux (enfin il n'est forcément restreint à ce sujet).
# Letlang évidemment
Posté par tisaac (Mastodon) . Évalué à 5.
Vu qu'il a la bonne idée de nous en parler régulièrement et qu'il bénéficie ainsi de toute la sagesse de LinuxFR (peut-être du reste aussi mais est-ce toujours souhaitable ?)
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Letlang évidemment
Posté par David Delassus (site web personnel) . Évalué à 7.
Héhé ça fait plaisir de voir ce commentaire :)
En plus en ce moment ça avance pas mal, de grosse news arrivent au moins avant la fin d'année !
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# cible du cristallin ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
En effet, le site de Crystal indique d'entrée, sur la syntaxe, « Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs. » Soit, une syntaxe simple, inspirée par Eiffel et Ada. <3 :-) Pourquoi pas ? Mais pourquoi diantre les rubystes troqueront leur pierre précieuse contre cette autre gemme ou autre chose au diffractogramme discret ? Une première recherche me dit que :
- c'est plus rapide mais avec d'autres pièges —Pavel Timofeev ;
- qu'il y a quelques années il manquait comparativement beaucoup de choses —Xavier Nayrac ;
- mais reste de niche et moins mature —Shadid Haque …
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: cible du cristallin ?
Posté par Psychofox (Mastodon) . Évalué à 5.
Étant plus rubysien que pythonien, j'ai codé une fois un truc en crystal. J'aime bien.
Parmi les raisons, je dirais que de vouloir faire un truc plus rapide donc plus économe en énergie est une bonne raison.
Et l'ecosystème n'est pas si petit que ça:
https://github.com/veelenga/awesome-crystal
[^] # Re: cible du cristallin ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Merci pour ce retour intéressant (je fais un peu de Ruby en hobby, mais clairement pas assez pour apprécier Crystal pour ma part, en plus j'utilise beaucoup le REPL en plus d'avoir peu besoin du typage statique qui est pourtant intéressant dans certains cas.)
Merci également pour le lien ; ça me permet d'en découvrir plus…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Les trucs plus anciens
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
J'avais un prof en école d'ingénieur qui était très énervé par le fait que tout le monde code en C alors que lui, dans sa jeunesse, il avait appris le Simula-67 et c'était vachement plus cool.
C'est un langage objet dérivé de Algol 60, un langage qui ressemble pas mal à Go.
Pourquoi, soixante ans après, on est encore en train d'inventer des nouveaux langages?
[^] # Re: Les trucs plus anciens
Posté par Olivier Abad . Évalué à 7.
Pour implémenter de nouveaux éditeurs de texte ?
[^] # Re: Les trucs plus anciens
Posté par AncalagonTotof . Évalué à 8.
J'attends vendredi ou je balance une crasse sur Java/JS tout de suite ?…
Plus récemment, j'ai tenté le Rust. Mais il faudrait que je recommence le tuto, j'ai pas réussi à m'imprégner des concepts la première fois. Et cette syntaxe me laisse dubitatif (P. Desproges, si tu nous entends …) parfois …
[^] # Re: Les trucs plus anciens
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 26 septembre 2022 à 12:09.
SQL (au moins PostgreSQL) et la JVM (au moins Java et Kotlin). On peut même utiliser des emojis ! (Ne faites pas ça !)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les trucs plus anciens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Puisque le commentaire parent évoquait BASIC, je dirai qu'il y a LSE qui permettait de coder en français, mais je ne me rappelle pas si les variables pouvaient contenir des accents et je doute que ce fut le cas.
Dans la même vaine, puisqu'on mentionne des langages fonctionnels, il y a eu des variantes de LOGO entièrement en français, comme présenté par la page française de Wikipedia. Mais je ne saurai dire pour l'accentuation des variables.
En RPL on peut définir des alias pour toutes les commandes mais personnes (à ma connaissance) n'a jamais traduit les commandes dans une autres langue (y a pourtant de grosses communautés francophone/hispanophone/germanophone). Par contre, j'ai souvenir de pouvoir mettre des lettres accentuées dans mes noms de variables/répertoires/etc.
Plus actuel, en descendant de Pascal, il y a le WLangage qui est bilingue (français/anglais) et dont des ordres/commandes français comportent des accents. Les types et noms de variables aussi (faut aimer.)
Bon, ne pas oublier de mentionner Python qui permet maintenant (3.x.y) d'avoir des identifiants Unicode…
Je laisse d'autres compléter.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Les trucs plus anciens
Posté par Storm . Évalué à 1.
Python 3 aussi (pas les émojis par contre :()
[^] # Re: Les trucs plus anciens
Posté par alberic89 🐧 . Évalué à 2.
En langage français, on retrouve aussi Linotte.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Les trucs plus anciens
Posté par barmic 🦦 . Évalué à 2.
On pourrait dire l'inverse sur l'utilisation d'entiers plus ou moins longs (signés ou non) et de caractères (?) (toujours signé ou non (???)) pour représenter une suite de bit. Tout le monde est naît avec ça du coup on le voit plus mais ça n'est pratique que parce qu'on a des années d’expérience. Utiliser quelque chose qui représente un champ de bit est beaucoup plus pratique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les trucs plus anciens
Posté par karteum59 . Évalué à 2. Dernière modification le 24 octobre 2022 à 14:22.
Linotte ? ;)
(note que les Chinois ont fait un peu pareil avec Chinese Python :) )
[^] # Re: Les trucs plus anciens
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 26 septembre 2022 à 12:08.
Pourquoi continue-t-on d'inventer des roues? On était très bien avec des roues de pierre !
Mais oui pour certains langages, on peut se demander qu'est-ce qu'ils apportent comme progrès…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les trucs plus anciens
Posté par zurvan . Évalué à 7.
Je suis étonné que personne n'ait encore cité Forth, question de tout réécrire, ça se pose là… Mais c'est passionnant !
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Les trucs plus anciens
Posté par AncalagonTotof . Évalué à 4.
Oh oui, j'ai pas pratiqué, mais je voyais les pub pour le Jupiter ACE à l'époque !
[^] # Re: Les trucs plus anciens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
J'ai eu l'occasion de jouer un peu avec Gforth après avoir longtemps pratiqué le RPL qui en reprend les principes (mais pas toutes les commandes et en rajoute d'autres dans l'esprit Lisp)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Les trucs plus anciens
Posté par fearan . Évalué à 7. Dernière modification le 28 septembre 2022 à 12:08.
Parce qu'on a toujours par trouvé le bon pour MultiDeskOS :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Et hare, alors?
Posté par fero14041 . Évalué à 2.
Je m'offusque que le petit dernier, initié par Drew Devault, soit absent de cette liste! Hare a toutes les qualifications requises pour y être mentionné; et il n'est pas inconnu non plus de LinuxFr. De plus, il a un bôlogô (lui!), et est porté par un acteur du Libre reconnu et faisant parler de lui (en bien comme en mal, c'est dire)…
[^] # Re: Et hare, alors?
Posté par reno . Évalué à 4.
Si je me rappelle bien Drew Devault n'a prévu de supporter que des OS libres pour Hare!
Je sais bien qu'on est sur LinuxFr mais bon quand j'ai vu ça, j'ai tout de suite classé ce langage dans la catégorie "a oublier"
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 26 septembre 2022 à 14:04.
Pourquoi? Tu aimes coder pour du proprio?
C'est en GPL3 donc quiconque veut porter ça sur un autre OS est libre de le faire hein.
[^] # Re: Et hare, alors?
Posté par David Delassus (site web personnel) . Évalué à 2.
La vrai question c'est : es-tu prêt a ignorer la majorité des utilisateurs potentiels de ton appli ?
Il me semble que les Linux et *BSD c'est même pas 5% des parts de marché.
C'est bien d'être libriste, mais à un moment il faut être réaliste.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Et hare, alors?
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Tu veux dire comme Red Hat qui ne porte pas Ansible sous Windows?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et hare, alors?
Posté par Lucky Seven . Évalué à 2.
Sauf erreur de ma part, Ansible fonctionne sous Windows à partir du moment ou tu as Python d'installé. Il peut aussi s'authentifier avec un AD sur des Windows et faire des trucs dessus.
Ils ont même fait de la "pub" sur leur blog pour montrer qu'il y a une compatibilité :
- https://www.ansible.com/blog/automating-mixed-red-hat-enterprise-linux-and-windows-environments
- https://www.ansible.com/blog/using-ansible-automation-platform-gitlab-ce-and-webhooks-to-deploy-iis-website
- https://www.ansible.com/blog/using-the-win_dsc-module-in-ansible
Red Hat est probablement moins fermé sur l’interopérabilité que Microsoft, de toute façon j'hésiterais à utiliser un outil qui a été porté par Microsoft (Teams, Edge, …) sur mon système d'exploitation libre !
[^] # Re: Et hare, alors?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Il n'y a pas de version Windows. La doc mentionne WSL toutefois. Il existe aussi un portage sous Cygwin mais il n'est pas très au point.
https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#control-node-requirements
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ces liens ne disent pas le contraires de la remarque initiale : ça ne s'installe pas sur Windows (on ne dit pas que ça ne gère pas les W …et pour info cette gestion s'appuie directement sur Powershell et non Python)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
C'est exactement la raison pour laquelle je fais encore du Puppet :)
Je sais, je fais de l'Ada, je fais du Puppet, je code encore en Java comme il y a 20 ans… Ouais, chui un dino :D
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Même combat pour les poupées : la grande maîtresse n'est pas portée sous W… mais il y a bien un agent pour la plateforme.
Sinon c'est bien les dino …comme Denver.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 4.
L'agent puppet peut interpréter les manifestes directement via
puppet apply, donc même sans puppet server ça reste un puppet à part entière. D'ailleurs il y a des environnements qui ont choisi de fonctionner en mode serverless avec git.[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Ah oui, j'oublie souvent car utilisant rarement. Mais bon, l'agent est un interpréteur du DSL (sous-ensemble Ruby) là où l'autre ferait appel à des scripts powershell avec des paramètres JSON. Un Puppet à part entière, je ne sais pas trop car dans ma vision sans centralisation et possibilité d'utiliser Hiera (ou alternative) + Foreman (ou alternative) c'est pas la solution complète.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 5.
De toute façon il ne viendrait à l'idée de personne de vouloir installer foreman ou puppet sur un server windows quand on peut le faire sur un linux.
[^] # Re: Et hare, alors?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Effectivement, j'avais jamais pensé à cette utilisation-là :)
Autre utilisation que j'ai de l'écosystème, c'est Bolt.
Je continue à garder le DSL Puppet tout en faisant du fonctionnement à la Ansible.
Couplé à Vault pour la gestion des credentials, ça permet de faire pas mal de trucs.
Enfin, mes derniers essais ont été d'interfacer Bolt avec PuppetDB (cf. là), histoire de ne pas me trimballer un fichier Inventory.yml trop volumineux.
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 26 septembre 2022 à 14:23.
La majorité des trucs que j'ai codé dans ma vie, je l'ai fait pour moi ou mon employeur et ça n'avait pas destination à être vendu / utilisé en externe donc ouais je m'en tape complètement. Il me semble que ça représente une grande partie des projets libres. YMMV comme ils disent.
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 10.
Tu parles des distributions GNU/Linux sur le desktop peut-être ?
Parce-que sur les serveurs, je n'ai pas vu de Fenêtre faire la moitié des 95% que tu énonces…
Parce-que dans les poches (et sur les ardoises) comme dans de nombreux NAS propriétaires, je vois pas mal de noyau Linux…
Jdçjdr
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 1. Dernière modification le 29 septembre 2022 à 16:17.
Pas vu le commentaire juste au dessus, à supprimer.
[^] # Re: Et hare, alors?
Posté par David Demelier (site web personnel) . Évalué à 2.
Ça c'est propre à chacun mais refuser de base des plateformes pour des opinions personnelles c'est probablement pas la bonne décision pour un langage. Drew - dont l'égo surdimensionné n'est plus à démontrer - le manifeste une nouvelle fois avec ce langage (dont c'est pas sa seule décision arrêtée).
Swift a beau être développé par Apple il est disponible sur une panoplie de plateformes même si on utilisations sur ces dernières reste sporadique
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 27 septembre 2022 à 09:45.
La licence qu'il a choisi n'interdit aucun portage. J'imagine que n'utilisant pas lui-même des OS proprios, il ne pourrait de toute façon pas offrir un support ni test à la mesure.
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
De plus comparer une armée de pommes (ayant pléthore d'usagers de fenêtres) à un seul individu (qui n'y touche pas) et lui demander de vouloir rivaliser avec Swift (qui au passage n'est pas disponible pour plein d'autres systèmes —à tout hasard, je ne l'ai pas trouvé pour Haiku par exemple.) Bref, faire feu de tout bois…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Il est disponible dans le dépôt de paquets de Haiku suite au travail de return0e pendant le Google Summer of Code 2017.
Par contre nous n'avons pas encore de version de Hare disponible.
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ha merci. Je n'ai pas revérifié depuis… Mais en tout cas ce n'est pas l'implémentation/travail de Apple qu'on pose au niveau que le Drew… Hare viendra quand il y aura les ingrédients (besoin, motivation, disponibilité de temps.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par ElVirolo (site web personnel) . Évalué à 4.
Si, si, il est toujours à démontrer (et quel est le rapport, par ailleurs ?) ;)
Ce sont des opinions politiques, et cela me paraît constituer une opinion tout à fait valable. Libre à chacun d'écrire une implémentation de Hare pour un système privateur, libre à lui de ne pas vouloir s'embêter avec cela.
Je n'ai pas bien compris depuis quand la qualité d'un langage était jugée à la capacité de son fondateur à en écrire une implémentation pour un système privateur (le langage n'est pas son implémentation), surtout quand ladite implémentation est tout à fait possible techniquement et juridiquement.
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Le rapport est personnel : il a des molaires contre lui et ne loupe pas l'occasion de régler ses comptes par commentaires ici.
Je ne poserai pas la question par rapport au fait que le système soit privateur mais juste au fait qu'on l'utilise et qu'on le connait. Il y a plein de systèmes open dont le fondateur ne fait pas l'implémentation et tant mieux : ce n'est pas son boulot de prétendre tout faire sans en avoir la capacité (et on va pourtant lui reprocher d'avoir la grosse tête.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par ElVirolo (site web personnel) . Évalué à 5.
Oui, j'ai remarqué. Je vois pas trop l'intérêt, d'ailleurs, je crois qu'on commence à avoir compris (je trouve par ailleurs qu'il y a des choses critiquables chez Drew, m'enfin de là à en faire une maladie/obsession et à en faire profiter tout le monde à chaque fois, sans que le rapport avec le sujet en question soit particulièrement évident…).
Certes, mais de là à « mettre à la poubelle » un langage entier (sans en faire de commentaires techniques, ce que je trouverais d'ailleurs intéressant en tant que béotien) au motif qu'il n'existe pas d'implémentation officielle sur des OS privateurs alors que nous sommes sur un site traitant de Linux et des logiciels libres, il y a quelque chose qui me dépasse.
[^] # Re: Et hare, alors?
Posté par reno . Évalué à 3.
Pas spécialement, mais quand j'investis du temps pour apprendre un langage (avec ses librairies, son système de build, ses outils etc) je veux pouvoir rentabiliser mon temps en l'utilisant "n'importe où".
Ou sinon je peux utiliser un autre langage..
Comme le notait le journal, ça n'est pas ça qui manque!
[^] # Re: Et hare, alors?
Posté par David Demelier (site web personnel) . Évalué à 3.
Avec une affirmation aussi - propre à son opinion habituelle -, j'ai du mal à y croire.
“Hare does not, and will not, support any proprietary operating systems.”
Je vois mal des gens faire un portage downstream qui soit pas officialisé.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et hare, alors?
Posté par ElVirolo (site web personnel) . Évalué à 2.
Cela ressemble à un procès d'intention. Encore une fois, aucun support des OS privateurs n'est prévu par l'équipe de développement. Et alors ?
Quand j'écris un programme, je n'ai aucune envie de m'assurer qu'il puisse être compilé sur un OS privateur. Étant donné que mes programmes sont libres, chacun peut se charger de ce travail s'il ou elle le souhaite. Qu'il s'agisse ici d'un langage de programmation (en aparté, quand cesserons-nous d'employer cet affreux anglicisme ?) ne change, à mon sens, rien à l'affaire, puisque le compilateur et le langage lui-même sont distincts.
Pourquoi ? Par exemple, il y a des distributions/builds d'Emacs (et donc d'Emacs Lisp) non-officiels pour des OS privateurs. Pourtant, on ne peut pas considérer que l'équipe de développement (et surtout, son chef) accueillent particulièrement chaleureusement lesdits OS privateurs. Je ne vois pas pourquoi on ne pourrait pas faire la même chose pour Hare.
[^] # Re: Et hare, alors?
Posté par David Demelier (site web personnel) . Évalué à 3. Dernière modification le 27 septembre 2022 à 15:54.
C'est ton avis mais affirmer noir sur blanc “ne sera pas supporté” pour moi c'est pas juste une non-envie de s'en occuper mais un doigt levé à quiconque le demande ou souhaite fournir le support pour.
Beaucoup de gens ne fournissent pas le support pour X ou Y système parce qu'ils n'ont ni les compétences, ni le matériel pour mais de là fermer la porte immédiatement c'est à mon sens inconcevable pour un langage.
Avant je n'avais pas de mac et pour autant j'ai jamais dit sur un quelconque de mes projets « il ne sera jamais disponible pour macOS ». Un jour une personne m'a aidé à porter mon programme pour et j'étais ravi qu'il ai pu m'aider à le faire.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 6.
Et avec quel genre de super pouvoir pourraient-ils faire quelque chose contre ça sans changer la licence?
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 27 septembre 2022 à 16:41.
La license n'implique rien à propos du support technique. Plutôt au contraire, il y a une clause écrite en majuscule sur l'absence de garanties, etc.
Donc Drew pourrait, par exemple:
- Refuser de fournir du support aux gens essayant de construire une version Windows,
- Fermer tous les rapports de bugs concernant des systèmes non-libres,
- Refuser d'héberger des binaires pour Windows ou d'intégrer le code dans sa version de Hare,
- Faire exprès de changer l'architecture du code pour rendre la vie plus compliquée aux forks qui tenteraient de le faire sans son aide,
- Interdire l'utilisation du nom "Hare" pour toute implémentation autre que la sienne,
- Encourager les gens à écrire du code non portable,
- Concevoir des APIs difficiles à faire fonctionner sur un système non-UNIX.
Sans pouvoir strictement l'interdire, il y a quand même tout un tas de moyen de mettre des bâtons dans les roues à quelqu'un qui se lancerait là-dedans. Même si on peut supposer que ce ne sera pas le cas, on peut considérer ça comme un problème si on veut écrire du code qui pourrait fonctionner sur un système non-libre (et personnellement, je pense que chacun devrait avoir le droit d'écrire du code qui fonctionne où il veut, et qu'on devrait essayer de rendre ça le plus facile possible).
Ça ne serait pas un problème si Drew disait, personellement, "je ne souhaite pas assurer le support pour les systèmes propriétaires". Mais là c'est présenté comme un choix plus global de toute la communauté Hare. Ce qui est surprenant parce que d'un autre côté, un des messages de blog dit qu'ils n'apprécient pas l'évangélisme de la communauté Rust qui veut réécrire et remplacer tout le code C existant. D'une certaine façon, ce choix de ne pas faire fonctionner Hare sur des systèmes non-libres et de s'engager à ne pas le faire ou à empêcher d'autres gens de le faire, relève pourtant un peu de la même attitude qui consiste à imposer ses propres idées là ou ce n'est peut-être pas nécessaire.
Ça pose aussi la question de savoir si le langage est conçu par une communauté, ou par une seule personne qui a tout pouvoir de décision. Les deux choix se défendent, mais là, la présentation qui est faite se retrouve du coup un peu entre les deux, quelque part entre le "c'est un projet personnel pour mes propres besoins, je fais ce que je veux" et le "on va construire une communauté de développeurs avec des objectifs communs". Ce qui donne une position peut être moins facile: "on va construire une communauté de développeurs qui sont d'accord avec mes objectifs". Cela dit, ça a fonctionné pour d'autres projets (Linux, Python, …) donc, ce n'est pas forcément un mauvais modèle en soi.
Autre bizarrerie, Haiku, FreeBSD, OpenBSD et NetBSD ne sont pas totalement libre d'après la FSF, cependant ils sont dans la liste des systèmes que Hare "prévoit" de supporter (et pour FreeBSD c'est même déjà fait). On peut en déduire que la définition de "propriétaire" n'est pas la même que celle de la FSF, mais du coup, quelle est-elle? Est-ce que le support de ReactOS (et par extension de Windows, son clone propriétaire) est prévu? Qui décide quels systèmes sont supportés ou pas? Est-ce que ça peut changer au cours du temps?
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 1.
Là tu nous fais une Zenitram, faire dire aux gens ce qu'ils n'ont jamais dis.
C'est confirmé, tu ne sais pas lire.
D'une part c'est le projet GNU, pas la FSF. D'autre part les critiques à ces systèmes font référence au fait qu'ils facilitent l'installation de firmware, soit via un medium d'installation, soit via un système de ports. Les ports, c'est un peu comme le système AUR chez Archlinux, ça ne fait pas partie du système de base, c'est maintenu par la communauté.
Ils critiquent de la même manière toutes les distros Linux, et plus ou moins tout ce qui n'est pas GNU/HURD ou Trisquel.
[^] # Re: Et hare, alors?
Posté par barmic 🦦 . Évalué à 3.
Je vais tenter d'exprimer ce que je pense qu'a voulu dire pulkomandy de manière encore plus neutre.
Si le projet choisi des systèmes qu'ils supportent et d'autres qu'ils ne supportent pas pour des raisons politiques : qu'est-ce qui décrit de manière clair et pas sujet à interprétation les systèmes acceptables ou non par le projet ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 28 septembre 2022 à 16:11.
Système propriétaire, ça me semble assez clair, pas fourni sous licence libre.
[^] # Re: Et hare, alors?
Posté par barmic 🦦 . Évalué à 5.
T'es nouveau par ici ? Ça s'étripe à tour de bras pour savoir ce qui est libre ou non. Tout le temps. Tu as au moins 3 ou 4 entités reconnues qui ont leurs définitions de logiciels libres. Elles se recoupent en grande partie évidement, mais qui ne sont pas identiques pour autant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
On peut re-citer la phrase qui est sur le site de Hare:
Je traduis:
ça me semble quand même assez fort comme façon de dire les choses. On peut discuter de ce que ça veut vraiment dire:
Quelle est la définition choisie pour "système propriétaire"? Ce n'est pas celle du projet GNU puisque certains systèmes marqués "pas totalement libres" dans la liste du projet GNU sont tout de même listés dans ceux pour lesquels Hare prévoit de fournir du support. Je ne sais pas quelle autre définition utiliser. Donc je ne sais pas dire quel système pourrait recevoir du support ou pas dans le futur.
Qu'est-ce que "Hare" exactement dans cette phrase? Est-ce que c'est le langage de programmation? Ou est-ce que c'est l'équipe derrière le projet? Parce que effectivement ça donne une interprétation assez différente.
Alors, oui, j'ai pris l'interprétation la plus restrictive. Mais si on me demandait de choisir un langage pour écrire un logiciel, c'est comme ça que je m'y prendrais. Peut-être que je suis trop méfiant et prudent. Mais en tout cas ça ne me donne pas confiance.
D'autre part, chacun sa vision des choses, au moins c'est un choix assumé de militer ouvertement contre les "systèmes propriétaires", et on peut être d'accord ou pas. Mais j'aimerais quand même savoir comment ils décident si un système est propriétaire ou pas.
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 7.
C'est faux. Voir plus bas.
Non tu pars d'une interprétation que tu inventes.
Le projet GNU ne fait pas autorité pour définir ce qui est libre ou pas.
Le projet GNU ne dit pas que ces systèmes ne sont pas totalement libre. Il dit qu'il ne peut pas soutenir ces projets car ils aident à l'installation de firmware non libres sur ton OS. C'est totalement différent.
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Je peux parler pour le cas de Haiku que je connaît bien.
L'installation par défaut de Haiku contient plusieurs logiciels qui ne sont pas libres. À l'époque ou la page de GNU a été écrite, cela comprenait par exemple:
Pour ces deux logiciels, nous avons l'autorisation des auteurs pour les inclure dans notre image d'installation et les préinstaller avec Haiku. Cependant, le code n'était absolument pas libre.
Entretemps, Wonderbrush a été re-licensé et le BePDF a été réécrit pour ne plus avoir besoin de la liblayout. Mais Haiku inclus toujours des firmwares wifi non libres (pas juste de l'aide pour les installer, ils sont inclus directement dans le DVD).
Quelle autre définition peut-on prendre? Est-ce que le moindre bout de logiciel non libre inclus dans un système le rend propriétaire? Est-ce que propriétaire est synonyme de "non libre", ou est-ce qu'il y a des nuances entre les deux?
On peut conclure que pour Hare, l'inclusion de firmware wifi et/ou d'autres morceaux non libres dans un système ne semble pas poser problème et qu'ils considèrent que Haiku et FreeBSD ne sont pas des systèmes propriétaires d'après leur définition.
Mais ça ne répond toujours pas entièrement à la question. Qu'est-ce exactement qu'un système propriétaire?
Mon problème avec cette phrase sur le site web est que chaque mot est sujet à interprétation de la même façon:
Donc, oui, j'essaie de surinterpréter cette phrase parce que, pour moi, elle n'est pas du tout claire et je ne sais pas quoi en penser. Finalement ça peut vouloir dire plein de choses différentes. Si je voulais utiliser Hare, j'aimerais juste savoir à quoi m'attendre.
[^] # Re: Et hare, alors?
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 29 septembre 2022 à 10:52.
Le fait qu'ils soient inclus dans un media d'installation ne signifie pas qu'ils font partie d'Haiku.
De toute façon cette histoire de firmware non libres est de l'hypocrisie de la part de GNU car ils ne disent rien si tu installes Trisquel sur un appareil propriétaire remplis de firmware pas libre. Le fait qu'ils soient flachés de façon permanente sur le chip ou chargé au moment du boot ne change absolument rien.
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pour la première question, s'il s'agit du langage il faudrait alors revoir la licence… La restriction de support fait par contre sens si l'on parle de l'équipe core (en indiquant au passage que les améliorations/amendements visant à supporter les plateformes qui vont à l'encontre de leur vision politique, seront rejetés)
Ceci nous amène à la troisième question où pour moi il y a deux aspects : le premier est juste de faire le portage/implémentation et d'assumer le support (et ça c'est un non indiscutable et on ne peut pas leur en vouloir) ; le second serait de faire des aménagements dans les spécifications pour faciliter le portage et l'utilisation sur d'autres plateformes (ce n'est pas nouveau et plein de langages sont dans le cas.)
La seule chose pas claire, éventuellement, c'est de mentionner "Hare" tout court.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par ElVirolo (site web personnel) . Évalué à 3.
Tout d'abord, on n'en sait rien. Ensuite, même si c'était le cas, et alors ? Encore une fois, personne n'empêche quiconque de le faire - et une implémentation de Hare pour un système privateur aurait peut-être un succès fou, quoi que l'équipe de développement en pense.
Encore une fois, ils ne peuvent pas « fermer la porte », seulement ne pas effectuer ce travail eux-mêmes. Je ne vois pas ce que change le fait que nous ayons affaire à un langage de programmation. Ne pas développer d'implémentation pour un OS privateur est un choix de développement comme un autre. L'équipe de Hare ne doit rien à quiconque (encore moins aux OS privateurs, qui nous pourrissent déjà suffisamment la vie). Ils proposent un travail, dont on fait ce qu'on veut.
C'est tout à ton honneur. D'un autre côté, je comprends que lorsqu'on utilise et promeut le logiciel libre, on ne souhaite pas se donner l'(immense) peine d'assurer le support d'un OS privateur. C'est un logiciel libre : son auteur ne doit rien à personne, ses utilisateurs ne doivent rien à l'auteur, hormis le respect de la licence qu'il a choisie qui, en l'occurrence, n'empêche aucunement une implémentation tournant sur un OS propriétaire.
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
C'est vrai, mais choisir de ne pas utiliser un langage ou une bibliothèque parce qu'elle ne fonctionne pas ou que son équipe ne fournit pas de support technique pour certaines configuration, c'est aussi un choix qu'on peut facilement comprendre. Il est probable que ça réduise l'adoption de ce langage. Ce qui fait que ça va être difficile de trouver des développeurs qui l'utilisent et le maîtrisent. Cela constitue un risque pas négligeable et qui peut pousser les gens à choisir un langage plus connu ou plus ouvert à ce genre de choses, ou à n'en avoir rien à faire et choisir quand même de programmer en Hare. Selon le cas et selon le projet, ça peut être un problème ou pas du tout.
[^] # Re: Et hare, alors?
Posté par ElVirolo (site web personnel) . Évalué à 2.
Tout à fait, mais je pense que c'est un problème secondaire (voire, je l'imagine, pas un problème du tout pour les développeurs de Hare). Si le public de Hare se limite aux utilisateurs d'OS libres, cela ne pose pas nécessairement problème. Qui a dit qu'un logiciel/langage devait avoir la diffusion la plus large possible :) ?
[^] # Re: Et hare, alors?
Posté par Thomas Douillard . Évalué à 5.
Peut-être les gens qui pensent qu’un projet qui s’isole et cherche pas trop à communiquer/collaborer avec les autres et finit par vivre en autarcie est condamné à mourir à petit feu …
[^] # Re: Et hare, alors?
Posté par ElVirolo (site web personnel) . Évalué à 3. Dernière modification le 28 septembre 2022 à 17:51.
Je me trompe peut-être, mais il me semble qu'il y a une différence de taille en le fait de ne pas offrir de support pour les plateformes propriétaires et vivre en autarcie. Les utilisateurs d'OS libres sont suffisamment nombreux, notamment parmi les développeurs, non ?
Et puis, par ailleurs, s'ils veulent effectivement vivre en « autarcie » (ce dont je doute), je ne comprends pas tellement le problème. Pourquoi est-ce que cela déchaîne autant les passions ? On a l'impression que d'aucuns se sentent insultés parce que l'OS propriétaire qu'ils utilisent n'est pas supporté.
Je n'utiliserais probablement jamais Hare dans tous les cas, mais le fait qu'il n'existe pas d'implémentation officielle sous macOS ne m'empêche pas de dormir.
Encore une fois, l'équipe propose quelque chose, on en fait ce qu'on veut, pourquoi couper les cheveux en quatre pour des détails ?
Si le support pour les OS propriétaires est si important (et je n'ironise pas, il l'est peut-être, je ne sais pas), pourquoi ne pas dépenser son énergie à le mettre en place plutôt que de surinterpréter une pauvre petite phrase ?
PS : Je rappelle qu'on a affaire ici à un langage de programmation de bas niveau (autrement dit, utilisé par des spécialistes qui savent très bien installer une distribution Linux), pas de VLC ou d'un autre logiciel grand public. Si Hare n'a aucune diffusion sur les OS propriétaires, je pense que ça n'aura strictement aucune importance.
[^] # Re: Et hare, alors?
Posté par David Demelier (site web personnel) . Évalué à 2.
Aucun rapport. Je n'utilise pas Windows et je n'ai pas de Windows chez moi, pour autant j'ai pas envie de limiter mes projets à des OS libres. Si mon projet fonctionne aussi sur Windows c'est tant mieux car ça fait une audience supplémentaire.
Pour ma part, je critique simplement le point que le projet affirme directement « Les OS non libres ne seront pas supportés » et même si je fais que de l'opensource développé sous de l'opensource, je ne veux pas me limiter à ça.
Si on veut pousser le vice encore plus loin on fait une nouvelle version d'une licence pro-opensource qui dit « attention ce logiciel n'a pas le droit de tourner sur un système non libre » ? Ça n'a aucun sens et c'est simplement un doigt levé des opinions imbue de Drew.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et hare, alors?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Quand je regarde la plupart des projets qui font du code pour W et L, ça ne juste fonctionne pas tout seul… (coucou LibreOffice, Firefox, Gimp, Inkscape, …)
Il y a certes quelques exceptions (cf. Go, Java, …) mais dans ce cas on revient au point de départ : le code est ouvert et il te suffit de porter le compilo sur ton A500 pour que ton appli puisse être disponible sur Amiga, et ce sans que la maison mère ait à supporter officiellement ce système.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et hare, alors?
Posté par Thomas Douillard . Évalué à 2. Dernière modification le 28 septembre 2022 à 20:32.
Forcément vu comme ça ;)
Ben parce que pour motiver à faire ça il faut qu’il y ait un réel intérêt … et juste avoir un langage qui ne semble à la base pas s’intéresser à la plate forme, un langage parmi bien d’autres, ça pousse pas forcément à s’intéresser au langage à la place, faire grandir la communauté, faire des ports, écrire des bibliothèques ce genre de choses. Et on va pas se mentir, avoir du code utilisable sans tout avoir à recoder à zéro c’est important pour les développeurs. Si tu ne donnes pas particulièrement l’impression de t’intéresser à ton langage en dehors de ton cas d’utilisation perso il y a des chances que les gens aillent voir ailleurs.
C’est pas forcément un problème si tu veux faire un langage pour toi dans ton coin, mais c’est pas ce qu’il y a de mieux en 2022 pour faire grandir une communauté et que des gens écrivent des programmes dans le langage. Vaut mieux laisser une porte ouverte au moins …
[^] # Re: Et hare, alors?
Posté par ElVirolo (site web personnel) . Évalué à 3.
Je comprends ton argument, mais je pense qu'il sous-estime l'importance de la population d'utilisateurs d'OS libres. Ne pas proposer d'implémentation pour des OS propriétaires est loin d'équivaloir à « rester dans son coin ».
J'imagine, tout simplement, que, pour l'équipe, le support des OS propriétaires ne vaut pas l'élargissement du public qui est son corollaire. Après tout, avoir un langage « populaire » n'est pas une fin en soi.
Pour poursuivre le parallèle avec Emacs (qui fonctionne sous MacOS et Windows, mais pour qui ces derniers ne sont pas prioritaires - personnellement, je n'ai jamais réussi à avoir un Emacs fonctionnant de manière convenable sous Windows - et ça n'a aucune importance :) : Emacs n'est pas, ou plus, un logiciel « populaire ». Et ça n'a, à mon sens, strictement aucune importance, car ce n'est pas son but. Pour autant, il jouit d'une communauté grande et dynamique, qui, dans son écrasante majorité, utilise GNU/Linux. Son développement est actif, et son « écosystème » de paquets aussi. Si Emacs n'était pas compilable sur des OS propriétaires, je pense que cela ne changerait absolument rien.
On peut très bien avoir des communautés robustes sans support pour des plateformes propriétaires, d'une part, et, d'autre part, la « popularité » est loin d'être nécessairement un objectif à atteindre.
[^] # Re: Et hare, alors?
Posté par Thomas Douillard . Évalué à 2.
Emacs c’est pas un logiciel qui a démarré avant hier, c’est un dinosaure du monde logiciel. Le paysage n’est plus du tout le même que quand il a démarré.
https://trends.google.com/trends/explore?date=all&geo=FR&q=emacs,vscode
Il semble avoir une popularité en baisse, donc probablement une population d’utilisateur vieillissante elle aussi. Sa problématique ne semble pas de démarrer et créer une communauté d’utilisateur, mais que sa communauté reste suffisamment active pour pas faire fuir ses derniers utilisateurs. Et en plus il tourne sous MacOS et Windows.
# Les dinosaures sont toujours là
Posté par dzecniv . Évalué à 7.
Eh bien moi, je préfère les créatures dinosauresques qui sont toujours parmi nous, telles le requin, apparu il y a 420 Ma. Bêtes de l'évolution, ils sont solides, se sont adaptés, sont beaux, même s'ils peuvent avoir un gros cuir (et une dentition dégueulasse).
Mon dinosaure préféré depuis quelques années, c'est Common Lisp. J'ai quelques apps compilées pour mon usage local ou pour des tâches simples sur mes serveurs, une appli web… (domaines explorés avec succès: récupération de données XML via FTP, création et lecture de BDs (sqlite mais peu importe), appli web avec comptes utilisateurs, alertes Sentry, courriels, petite API…)
Même si certains nouveaux joujous donnent envie (Nim peut-être), ils sont loin d'égaler toutes les fonctionnalités présentes, déjà, de base, chez CL. Ces nouveaux langages n'ont souvent pas de REPL, ou un très basique… c'est très, très dur de retourner dans un aquarium, surtout quand tu as déjà chevauché un requin blanc.
# les anciennes choses..
Posté par tkr . Évalué à 0.
sont les meilleures !
personnellement comme je vois à quel point rust et d'autres technos "trendly" (tendances) sont font l'objet d'une communication à l'extreme, sans doute sponsorisée par des boites davantages commerciales que technophiles..
je reste à ma grande préférence du C et aux alternatives libres…
malgré que l'ipv6 et le webm ont permis de virer quelques erreurs de l'internet des années 2000..
que dire de xorg vs wayland?
c'est un peu comme parler d'ipv6 dans un cours d'iut, tout le monde vous fuit..
[^] # Re: les anciennes choses..
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 29 septembre 2022 à 07:51.
C'est que tu n'est toi même pas très techophile mais plus comercial. Evidemment d'un point de vue commercial, un langage en vaut bien un autre.
D'un point de vue ingénieur/développeur il y a moyen d'améliorer certaines choses. De "faire mieux avec moins". Et les langages Rust, Julia et Go apportent de réel plus par rapport aux dinosaures. Citons les principales innovations des langages passés : interprétation en live, les VM, puis la compilation JIT, des paradigmes…
D'ailleurs ceux qui se vantent de leurs vieux langages n'utilisent pas pour autant un des langages proprio de 1950.
Évidemment qu'avant de trouver des langages intéressant, on essaye beaucoup de trucs et qu'ils faut donc des beta-testeurs, des early-adopters…c'est normal que l'on passe par beaucoup de bull-shit langages. Mais ceux qui vantent les dinausores, ne vantent pas les bacctéries plus anciennes encore, pourtant les bactérie, quelques dinausores continuent d'exister avec des animaux beaucoup plus récents dont l'homme. Et l'homme est en train de tuer toutes les autres espèces :D
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: les anciennes choses..
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C++ le faisait déjà avec les smart pointers.
Il n'y a pas de VM en Go :-) C'est juste la compilation native normale comme on le fait depuis 1742 en Fortran, Pascal, C…
Là aussi c'est juste de la bonne vieille liaison statique.
Go et Rust n'apportent pas de nouvelles idées, il les implémentent juste différemment.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: les anciennes choses..
Posté par reno . Évalué à 2.
Pas d'accord, je pense qu'il fait plutôt référence a la gestion des objets en Rust qui est innovante (enfin sauf pour les rares personnes qui ont fait de l'ATS).
Il y a un GC embarqué. Bon ça n'est pas spécialement innovant un langage avec typage statique générant un exécutable (Eiffel, Delphi, D…) les principales différences sont la simplicité du langage et que ça soit poussé par Google.
Je crois que sur Linux Go ne passe pas par la libc pour faire les appels systèmes donc non pas "juste de la bonne vieille liaison statique".
[^] # Re: les anciennes choses..
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 29 septembre 2022 à 11:29.
Un GC n'est pas une machine et n'est pas virtuel. Du coup comme VM c'est moyen :-)
Par défaut si, pour avoir un exe vraiment indépendant, il faut lancer
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build.Ça reste une bonne vieille liaison statique et c'est complètement faisable en C, certes de façon bien compliquai.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: les anciennes choses..
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1.
@reno, je suis d'accord avec toi, j'apporterai tout de même les précisions suivantes :
C'est surtout que les smartpointer de C++, c'est un GC embarqué donc tu perd en performance et en maîtrise du moment de libération. A l'inverse, en Rust, c'est libéré au bon moment de manière décidé à la compilation. Rien à voir.
Je crois aussi mais c'est surtout la combinaison de tout ça qui n'existait pas : GC compilé avec le binaire, pas de dépendance, programmation simplifié (notamment par la GC). Il y a 2 niveaux de langages : les compilés, statiques optimisé mais complexe a programmer et temps de compilation (C et Rust maintenant) les interprétés (Python pour le plus connu) mais dont les performances sont pitoyable. Java est l'exemple type du compromis entre les 2. Go améliore Java sur tout les points ( programabilité, Perfs, portabilité, insensibilité aux changement de version de l'environnement… ).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: les anciennes choses..
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Pas du tout, en C++ personne ne ramasse tes miettes :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: les anciennes choses..
Posté par Thomas Douillard . Évalué à 4.
En Rust aussi le comptage de référence reste nécessaire dans certains cas
[^] # Re: les anciennes choses..
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 29 septembre 2022 à 13:58.
Les smartpointer c'est du code ajouté pour checker. Ce n'est pas un GC complet au sens propre, mais c'est quand même un check en live par du code. Autrement dit des perfs en moins. Cela ne s'appel pas GC mais c'est le même principe. La différence notable c'est que les vrais GC pour être plus efficace le fait par lot par processus // (plus efficace sur du multi-core), les smartpointer sont donc moins efficace mais sont aussi censé être beaucoup moins utilisé que les pointeurs normaux. Les pointeurs normaux étant plus efficace que ceux géré par GC, du C++ ou les smartpointer sont peu utilisé devrait être plus performant qu'un programme 100% GC.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: les anciennes choses..
Posté par David Demelier (site web personnel) . Évalué à 3. Dernière modification le 29 septembre 2022 à 15:19.
Ça n'a absolument aucun sens ce que tu dis. Dans tous les cas la mémoire que tu as allouée doit être désallouée. Les smart pointeurs permettent simplement de s'affranchir de faire des memory leak parce qu'on a oublié de le faire à un fil d'exécution du code. D'ailleurs un std::unique_ptr compilé avec les optimisations au max génère le même code assembleur.
Les smarts pointers permettent surtout d'éviter ce genre de problèmes avant qu'ils existent.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: les anciennes choses..
Posté par Letho . Évalué à 2. Dernière modification le 01 octobre 2022 à 04:50.
Question sans doute naïve, mais je suis curieux :)
J'ai pratiqué un peu de Rust, mais pas de C++. De ce que j'en comprends, le principe de borrowing via
&en Rust permet de libérer la mémoire de façon déterministe au moment de la compilation. Ce n'est pas le cas quand on utilise par exemple le typeArc<T>, qui fonctionne avec un compteur de référence – et donc au runtime.Les smart pointers de C++ semblent plus proches de ce dernier cas ?
[^] # Re: les anciennes choses..
Posté par David Demelier (site web personnel) . Évalué à 4.
Je ne peux pas comparer car je connais pas assez Rust.
Les smart pointers permettent surtout :
git is great because linus did it, mercurial is better because he didn't
[^] # Re: les anciennes choses..
Posté par Letho . Évalué à 1. Dernière modification le 04 octobre 2022 à 01:53.
C'est ce que j'avais cru comprendre en survolant un peu de documentation. En gros, l'opérateur
newrenvoie en C++ un raw pointer référençant le tas, et l'idée est de ne jamais utiliser de variable intermédiaire pour ce dernier mais par convention de le passer directement au « constructeur » de smart pointer qui lui sera sur la pile ?var foobar = std::unique_ptr(new SomeFantasticClass());(syntaxe sans doute très très approximative)
Le smart pointer est le seul à connaître le raw pointer, et je suppose qu'il libère la mémoire quand
foobarsort du scope.J'ai bon ?
Ça ressemblerait effectivement un peu aux types
Box<T>etRc<T>en Rust (ouArc<T>, je ne sais pas sishared_ptrest thread-safe ?)…
…
C'est malin, je vais devoir ajouter C++ à ma liste de langages à tester.
# Gleam
Posté par Letho . Évalué à 5.
Je me suis promis d'essayer Gleam un jour prochain.
Typage statique + VM Erlang + modèle acteur. Miam.
https://gleam.run/
https://github.com/gleam-lang/gleam
# Zig
Posté par vitanix . Évalué à 1.
Zig m'a l'air intéressant. Il a comme philosophie :
Focus on debugging your application rather than debugging your programming language knowledge.
En plus, il n'a pas de GC, et il est sur au niveau du typage. Bun, l'appli pour remplacer nodejs entre autre a été développé avec Zig.
Par contre, une chose intéressante, c'est que ces nouveaux langages ne sont pas objets. C'est le cas aussi de Rust et Go.
[^] # Re: Zig
Posté par reno . Évalué à 2.
Un truc intéressant de Zig, c'est que les dev essayent d'être "plus correcte" même sur des points qui doivent être bien pénible a implémenter: par exemple le type unsigned en Zig ne wrappe pas, il est exactement comme le type entier signé: soit c'est détecté au runtime (checkers en mode débug) ou a la compilation, soit c'est undefined en mode release (ce qui permet de générer du code plus efficace).
Il y a +%, -%.. pour les opérations qui doivent wrapper.
Par contre j'ai quand même l'impression que Zig se focalise sur l'embarqué au détriment de la simplicité d'utilisation (passer les allocateurs de mémoire partout), Odin me parait bien plus "programmer friendly".
# Jai
Posté par bayo . Évalué à 1.
Et Jai, https://inductive.no/jai/ le langage que seul quelques rares élus peuvent utiliser.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.