David Demelier a écrit 670 commentaires

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

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

On le dit depuis le début, il faut tout externaliser sur des plateformes fermées ! Le cloud saylebien© !

Je vous laisse je dois push sur mon dépôt Mercurial self-hosted avec la même configuration depuis 2009.

git is great because linus did it, mercurial is better because he didn't

J'espère que les performances seront enfin là, mais si c'est toujours codé en python probablement pas 🤷🏻‍♂️

git is great because linus did it, mercurial is better because he didn't

Oui ? Je fais de la MAO sous Linux depuis 2005, jamais eu le moindre problème…

J'aimerais bien connaitre ton utilisation de la MAO. Parce que la dernière fois que j'ai voulu simplement faire tourner tuxguitar (pulseaudio) et ardour (jack) en même temps j'ai bien cru que j'allais m'arracher les cheveux. Sans compter la quantité massive de crash et erreur ardour.

Pour ce qui est des VSTs, tu es bien vite limité.

git is great because linus did it, mercurial is better because he didn't

À côté sous linux tout est bien plus facile et cohérent, de l'installation du système à la prise en main du bureau, de l'installation des logiciels à l'ajout de nouveau périphériques, c'est finger in ze nose comparé à win10.

Oh purée tu m'as fait bien rire.

Je vais pas détailler parce que linkdd l'a déjà bien fait mais je rajoute des éléments.

• Essaye seulement de faire de la MAO sous Linux avec la pile audio cadavérique que nous avons.
• Je suis sous Linux depuis 2003 (mandrake 10), bien que ce soit stable je ne peux qu'admettre qu'il y a rien de cohérent sous Linux. Du bureau aux entrailles. Des services qui ont tous une syntaxe différente (essaye voir de faire du polkit à la main). On a maintenant du XML, du .ini, du maison et d'autres encore. Pour l'utilisation en CLI c'est pareil : bluetoothctl, nmcli, iwd, systemctl. Ça en revanche c'est bien quelque chose qu'OpenBSD a fait de cohérent.
• L'installateur anaconda mériterait sa place en enfer.
• GNOME et prise en main dans la même phrase ? J'adorerais voir un utilisateur Windows lambda passer à GNOME sans aucune aide. N'hésitez pas à faire l'expérience si vous le pouvez. Pour KDE, c'est peut-être plus facile mais c'est très riche.

Concernant Windows 11, j'avoue que plus en avance dans ses versions plus c'est incohérent (surtout graphiquement) mais ça juste marche©. À ce jour j'aurais tendance à dire “all OSes suck”. Rien est parfait mais dire que Linux est cohérent et facile c'est de la pure mauvaise foi ou un total manque de connaissance.

git is great because linus did it, mercurial is better because he didn't

On parle de remplacer printf par puts quand il s'agit d'une chaine littérale, rien à voir avec gettext puisque c'est complètement déterminé à l'exécution.

git is great because linus did it, mercurial is better because he didn't

Oui c'est même pour ça que lors d'un hackaton FreeBSD (si je me trompe pas) les développeurs en ont fait une petite blague.

Tout ça pour rajouter des standard --help et copyright.

git is great because linus did it, mercurial is better because he didn't

Sauf que personne utilise c99 de POSIX. Une bonne partie des développeurs sensés activent tôt ou tard les warnings (options -W de gcc/clang) qui n'est évidemment pas couvert par POSIX et donc ton utilisation non portable. De plus, POSIX demande un compilateur C99, aujourd'hui on est bientôt à C23, ce serait dommage de rester sur des anciennes versions juste pour être 100% POSIX compliant.

Évidemment, loin de moi l'idée de dénigrer POSIX je suis moi même développeur C et embarqué privilégiant des APIs POSIX pour rester portable, mais je considère pas POSIX comme la bible non plus (POSIX make par exemple, c'est bien pour un projet à 2-3 fichiers, mais ça devient vite casse gueule sur des projets plus riches).

Pour résumer, je pense que ton argument n'est pas valable. POSIX stipule l'option -o de disponible donc quiconque voulait un nom de fichier prédictif devrait l'utiliser de toute manière.

git is great because linus did it, mercurial is better because he didn't

J'oublie toujours à quel point on est réfractaire au changement. Surtout quand c'est aussi trivial que ça.

git is great because linus did it, mercurial is better because he didn't

cl.exe utilise le nom du fichier, main.c devient main.exe. Donc dans notre cas main.

git is great because linus did it, mercurial is better because he didn't

Moi j'ai aussi hâte que les compilateurs C arrêtent de créer un exécutable a.out par défaut. Surtout quand celui ci est un ELF.

git is great because linus did it, mercurial is better because he didn't

C'est pas juste une position ou le respect des HIG de Apple, c'est clairement un autre style.

Exemple avec Terminal.app

Et avec Qt Creator (Qt 6)

La position des polices, la taille des polices, la couleurs du tab widget, la forme du selecteur de combobox. Rien ne va donc c'est pour ça que je ne comprends pas pourquoi si Qt 6 utilise les APIs native comme ça a été indiqué au dessus il y a autant de choses qui ne vont pas.

git is great because linus did it, mercurial is better because he didn't

Baaaah alors je comprends pas pourquoi les applications Qt 5 n'ont pas du tout un look natif sur macOS.

git is great because linus did it, mercurial is better because he didn't

Mais Qt utilise le toolkit sous-jacent dessiner les widgets. Et là c'est bien le but oui.

Cela a changé avec Qt 6 alors, parce qu'avec Qt 5 on peut toujours « simuler » l'interface de n'importe quel système sur n'importe qu'elle plateforme (aka Windows sur Linux, macOS sur Windows).

Tiled, une application en Qt 5 par exemple sur macOS Big Sur est pas native et a un look-and-feel des anciennes versions de macOS (<= Catalina).

git is great because linus did it, mercurial is better because he didn't

Au style:

• Onglets avec mauvaises couleurs.
• Boutons avec des icônes.
• Encore d'autres détails que l'on voit directement quand on connait macOS.

git is great because linus did it, mercurial is better because he didn't

Il y a écrit que c'est du natif en bureau mais en voyant la capture d'écran de la version macOS je constate immédiatement que ce n'est pas le cas. Aurais-je mal compris le terme natif ?

git is great because linus did it, mercurial is better because he didn't

Le C++ évolue beaucoup alors les ressources deviennent rapidement obsolètes (ou presque). Le cours du site du zero est évidemment à bannir.

Celui du zeste de savoir est pas mal mais contient pas tout des dernières normes. En tout cas tu peux commencer par ça. Pour le reste, le plus simple est de faire de la recherche et de poser des questions. Il y a des tonnes d'articles sur le C++11, C++17 et C++23 qui vont expliquer les nouveautés, à quoi elles servent, quels problèmes elles résolvent, etc.

git is great because linus did it, mercurial is better because he didn't

Comme en shell, tu peux simplement mettre un tiret avant EOF et alors tu peux indenter ce dernier.

my $help = <<-EOF;
...
...
EOF

Perl suit visiblement la même syntaxe que le shell (sauf le ; obligatoire)

git is great because linus did it, mercurial is better because he didn't

Sous Linux, dépendre de gtk/qt/whatever ça devient plus compliqué. C’est une jungle de différentes versions, de différentes options de compilation, compilateur, en veut tu en voila.

Faut vraiment s'abstenir de dire des inepties quand on sait pas de quoi on parle. Le seul moment où ça devient compliqué c'est quand tu veux utiliser une fonctionnalité qui est récente et que tu vises des distributions qui ont des vieux paquets. Pour ma part ça m'arrive jamais et pourtant j'utilise des outils moderne (je demande du CMake 3.20 par exemple, du C11, du C++17, du Qt 6, etc.). Alors à un moment donné tu peux aussi dire « désolé mon application ne supporte pas Debian 7 ». Tout comme tu peux voir des applications stipulant « Windows 10 ou supérieur, macOS Catalina ou supérieur, etc » Mais à ce moment là on jette la pierre au développeur plutôt qu'à la distribution qui fournit une panoplie de paquets sentant le formol.

C’est une jungle de différentes versions, de différentes options de compilation, compilateur, en veut tu en voila.

Pas sûr de comprendre en quoi tu peux en avoir quelque chose à faire que Gtk soit compilé en -O0 ou -O3. Pour Qt et Gtk, les choses sont bien faites, il y a des modules indépendants. Comme QtWayland, QtMultimedia, etc. Ça permet justement de pas faire un Qt monolithique « Oops, mon programme peut pas se compiler car la distribution crux ne compile pas le support de l'audio dans Qt »/.

Si t’es pas upstream, bon courage. Ça va être la foire à « Debian machin a gtk 42.31, mais on a linké a la version 43.21 et des choses bizarres se passent

Là c'est la preuve totale que tu ne sais pas de quoi tu parles. Rien ne bizarre se passe du moment que l'ABI est respectée. Hint : il s'agit du petit numéro stocké dans le SONAME d'un ELF.

readelf -d /usr/lib/libgtk-4.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libgtk-4.so.1]

git is great because linus did it, mercurial is better because he didn't

Dis ça lorsque le poste en question est un développement d'une application Windows utilisant la WinAPI, les MFC, RPC et COM :)

git is great because linus did it, mercurial is better because he didn't

Note : GNU/Linux n'est plus. Beaucoup de distributions ne sont plus basées sur GNU comme celle que j'utilise et je contribue : Alpine.

Pour ma part :

• Je développe quasiment que sous Linux (vim, make, cmake, clang comme outils).
• J'utilise un mac en “daily driver” parce que je n'apprécie plus Linux en bureautique comme je l'appréciais il y a 17 ans.

Concernant le sondage, pas de Visual Studio et encore moins de Azure, AWS ou Google Cloud Platform. La centralisation de masse, pas mon truc :).

git is great because linus did it, mercurial is better because he didn't

sizeof (char) renverra toujours 1, peu importe la machine et l'architecture. La différence c'est qu'il existe des machines ou un char vaut 64 bits donc pour faire simple : un octet ne fait plus 8 bits mais 64.

git is great because linus did it, mercurial is better because he didn't

Hmm ouais. Sauf qu'une fois j'ai voulu utiliser un seul module "header-only" et j'ai du me trimballer MPL, System et d'autres modules transitifs. Et System lui n'est pas header-only, donc ceux qui disent que cette bibliothèque est header-only et modulaires vendent du vent.

git is great because linus did it, mercurial is better because he didn't

Faudra m'expliquer cet entêtement à vouloir copier cette barre de menu globale. GNOME a viré les menus des applications mais Plasma le gère toujours. Ça n'a strictement plus aucun sens, c'était utile quand on avait des écrans en 800x600 où il fallait économiser le moindre pixel. Maintenant qu'on a des écrans géants et des résolutions 5k je perds plus de temps à naviguer entre la barre de menu et la fenêtre quand je connais pas le raccourci clavier par cœur.

git is great because linus did it, mercurial is better because he didn't