Si les ressources étaient équitablement réparties, évitant certains de vivre dans l'excès pendant que d'autres vivent dans la pauvreté, mon pifomètre me dit que la terre pourrait subvenir aux besoins de plus de 15 milliards d'être humains.
J'ai abandonné cet éditeur pour retourner sur Sublime Text 3 après le second freeze total.
C'était avant même que VS Code ne pointe son nez (adieu Sublime Text 3, j'ai toujours aimé ta simplicité et ta sobriété, dire que tu m'as fait abandonner vim).
Bah non justement, en Rust les concepts ne sont pas masqués :
allocation dynamique sur la heap ? Box<T>
allocation dynamique avec refcounting pour pouvoir partager une même ressource ? Rc<T>
je veux partager la même data en lecture mais pas en écriture (copy on write) ? Cow<T>
je veux protéger l'accès concurrentiel à une donnée ? Mutex<T> souvent avec Arc<Mutex<T>>
je veux créer une structure qui est thread-safe ? Implémentation de Send et/ou Sync
…
Il n'y a rien de plus explicite, ces informations apparaissent dans le système de type qui va permettre au compilateur de s'assurer que les règles qui gouvernent ces concepts sont bien respectées.
la syntaxe est moche
C'est subjectif. Je trouve aussi que la syntaxe est lourde, mais c'est pas plus moche que des templates C++ qu'on observe en masse dans les librairies "header only" (beurk).
les temps de compilation tendent vers l'infini ;
Exagération obsolète.
Ca compile plus vite que du C++ (de mon expérience personnelle et anecdotique)
sous prétexte d'être plus "safe", on doit se prendre la tête avec 42 concepts qui polluent le code ;
C'est pas sous prétexte d'être plus safe. C'est sous prétexte de prendre aucune décision pour le développeur. On le laisse gérer lui même pour qu'il puisse faire des applications performantes, on le laisse choisir lui même les trade-offs.
Le Go est un langage safe aussi, mais les trade-offs ont été choisi par les développeurs du langage/compilateur. Et toi, pauvre petit développeur, tu dois faire avec.
c'est safe, mais dès l'exemple de base de wgpu, on se retrouve avec un bloc "unsafe".
Ca j'ai mis pas mal de temps à le comprendre. Mais en gros, le choix qui a été fait par les développeurs de Rust est le suivant :
Il vaut mieux rejeter un programme valide qu'accepter un programme potentiellement invalide.
Le unsafe permet au développeur d'indiquer au compilateur que, même si le compilateur ne sait pas le déterminer, le bloc de code est safe. C'est à utiliser avec parcimonie, mais le côté "non safe" (qui est plutôt "n'a pas réussi a déterminer la safety") ne fuit pas vers le reste du programme.
De plus, le hardware sur lequel tourne le code Rust (ton PC) est par nature "unsafe". Il y a donc naturellement des choses que l'on ne peut pas déterminer à l'avance comme étant "safe".
Au final, utiliser "unsafe" c'est déléguer à l'OS la garantie que l'opération est safe. Tout comme en Haskell on délèguerait la gestion d'une IO (impure) au runtime.
Plus j'en apprends sur ce langage, moins j'ai envie d'en faire
Et c'est dommage. Ce langage n'est pas parfait, loin de là. Beaucoup de fonctionnalités ne sont pas encore stabilisées (hello générateurs/code asynchrone/…). La syntaxe est dure à comprendre.
Mais plus j'apprend ce langage, plus mes hypothèses et opinions se cassent la figure, pour laisser place à la réalité.
Grâce à Rust, je me pose des questions sur mon code, mes données, que je ne me posais pas avant, et ce même dans d'autres langages.
Si j'ose dire, apprendre le Rust fait de moi un meilleur développeur C / C++.
pourquoi ne pas écrire le jeu sous forme de core libretro ?
Parce que c'était pas le sujet du "challenge".
Je suis parti de "je voudrais bien ouvrir une fenêtre de manière cross-platforme sans embarquer une DLL" -> winit
Pour continuer vers "j'aimerais bien une primitive sympa pour dessiner dedans" --> pixels
Ensuite, je me suis hurté au compilateur Rust, ce qui m'a motivé à écrire cet article, comme un rappel personnel que ce que j'ai appris depuis 20 ans est faux : la programmation c'est compliqué, les langages nous mentent en cachant cela.
Et même dans des langages bas niveau tel que le C, ou haut niveau tel que le C++ ou le Go, ces choses sont masquées.
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
malloc/calloc/realloc/free (et alloca ne l'oublions pas), ce n'est pas de la gestion de la mémoire.
C'est à toi de calculer la taille suffisante pour stocker ta donnée au préalable. C'est à toi de t'assurer que le pointeur retourné par realloc est toujours le même qu'avant. C'est à toi de t'assurer de ne pas appeler free 2 fois sur le même pointeur.
L'implémentation des malloc qui appelle pour toi les syscall sbrk et brk et organisent la heap pour s'y retrouver reste quelque chose de très bas niveau, et peu différent de ce que tu ferais en Assembleur.
Maintenant, concernant le C++ et le Go, c'est mécanisme de gestion de mémoire sont bien masqués à l'utilisateur. En Go ce n'est pas toi qui appelle le Garbage Collector, ou qui alloue la mémoire pour tes objets. En C++ ce n'est pas toi qui appelle tel ou tel constructeur, ni les destructeurs. Ces choses sont présentes, mais pas exposés à l'utilisateur.
Je persiste et signe donc, C, C++, Go, et bien d'autres langages : ne sont pas explicite sur les concepts sous-jacents.
Pour moi, en C++ tu n'appelle pas manuellement les constructeurs (d'assignation, de copie, …) ou les destructeurs. Donc la durée de vie d'une variable au sein d'une scope est gérée pour toi. En C tu devras appeler ces fonctions à la main.
La STL fournit nombre d'abstractions qu'il est désormais recommandé d'utiliser, sauf si tu as un besoin spécifique bien sûr.
L'héritage, déjà rien que ça. Je recommande la lecture de ooc.pdf pour comprendre comment l'implémenter en C, et ainsi comprendre comment le C++ masque un autre concept bas niveau (organisation de la mémoire, édition des liens, etc…).
Ce qui fait qu'un langage peut être considéré comme haut niveau selon moi, c'est le nombre d'abstraction présente. Et C++ possède beaucoup d'abstraction, la ou le C n'en possède quasiment aucune.
Sauf que là depuis la 3.10, c'est la vocation de toute la team d'améliorer les perfs de Python pour revenir dans la course contre Javascript, Java, Go, etc…
Car ces dernières années, avec les ajouts de fonctionnalités, il a pas mal ralentit.
Alors oui, on a déjà eu quelques optimisations du bytecode en 3.9 et 3.10, mais la 3.11 ils ont décidé de prendre la pelle à merde et de creuser.
Et a chaque nouvelle rc de la 3.11, les benchs sont de plus en plus positifs. C'est surtout ça que tu entends depuis un certains temps, le progrès de la 3.11 sur ce sujet.
Parce que ta page avec son JS, elle va être chargée en 2 requêtes, que la connexion, elle peut couper entre les 2
Pareil que pour le CSS, les images, et autres resources donc. Bienvenue dans l'hypermedia, ça existe depuis les années 1990.
que ton utilisateur peut toujours être derrière un firewall foireux
Si toutes les ressources sont sur le même domaine, comme le décrit la phrase de Zenitram qui tu critiques, le firewall ne bloquera pas les resources si il autorise le site internet.
avoir une extension merdique, etc.
Shit in, shit out.
Je ne vois pas en quoi le fait que ce soit valide aussi pour les images enlève de la pertinence au propos sur le JS…
Si le but de l'article n'est pas de râler pour râler, mais de sensibiliser à l'accessibilité d'un site web. TOUTES les resources chargées de façon asynchrone risque d'impacter cette accessibilité. Se concentrer sur le JS c'est donc du troll histoire de.
Quote du site :
“All your users are non-JS while they're downloading your JS” — Jake Archibald
Je rajouterai donc :
All your users are not users while they're downloading your HTML
All your users are CLI while they're downloading your CSS
All your users are Text Mode while they're downloading your images
Et je conclurai par quelques notions :
l'en-tête Keep-Alive permet de réutiliser la même connexion au lieu d'en recréer une nouvelle à chaque fois, c'est très utilisé par les navigateurs web
la mise en cache des resources annexes d'un document hypermédia est aussi une pratique courante réduisant l'impact des 3/4 des problèmes mentionnés par l'article
HTTP 2 et le futur HTTP 3 vont aussi régler pas mal de ces problèmes
…
Enfin, je ne suis pas sûr qu'il n'y a pas besoin de me "rentrer dedans", on pourrait envisager de
débattre avec moins de violence…
Quoi ? De la communication non-violente sur LinuxFR ? Mais ou vas le monde…
Plus sérieusement, si tu veux de la communication non violente, évite de commencer tes commentaires par un "Non" catégorique qui ne signifie que "Tu as tort, j'ai raison, je n'ai même pas besoin de développer, mais je vais le faire quand même".
Aller je termine avec un trait d'humour. On design comment un site pour les utilisateurs qui ont cassé leur écran ?
ça plaide pour prévoir le cas où le JS n'est pas accessible
vs
ça tape plutôt sur HTTP, les CDN et le JS non accessible
Vous dites la même chose.
parce que ça arrivera et ne consernera pas que les 5 pelos qui désactivent le JS
Oui l'article parle cependant de bien d'autres choses que l'accessibilité du JS, donc :
Perso le JS est sur le même serveur et tout en HTTPS donc (quasi?) rien de ce qui est décrit n'est valide
Cette proposition est toujours valable, surtout lorsqu'elle commence par "Perso" qui démontre une expérience personnelle (certes anecdotique, mais néanmoins existante)
Et tu oublis l'essence même du commentaire à la base :
tout ce qui est écrit marche aussi pour des images
Ce qui est 200% vrai.
Ah c'est facile de commencer un commentaire par "Non" et ensuite de montrer qu'on a rien compris :)
En tant que développeur de librairie, j'utilise poetry, il va s'occuper de générer le setup.py comme un grand et de pousser sur PyPI. Mes utilisateurs font comme ils veulent ensuite.
Tout embarqué dans un seul exécutable (certes un peu plus gros vu qu'il embarque l'interpréteur Python et tout les modules importés). Ensuite je fournis le ".exe" via les releases Github ou, si la motivation est là, le paquet deb/rpm/msi/…
En tant qu'utilisateur, je laisse la distribution gérer son truc elle même, j'ai même pas envie de savoir quelle version de Python elle utilise. De toute façon, mon Python à moi il est dans /opt car je suis les beta/rc/etc… qui sont rarement dans les dépôts.
Au final, cela fait bien 15 ans que je n'ai pas subi ce que décrit ce xkcd.
D'ailleurs :
easy_install n'existe plus (aucun de mes venv ne possède la commande)
conda semble être une niche, car je ne l'ai vu que chez des data engineer/data scientist, les wheels ont aidé à cette situation
il existe désormais pyproject.toml qui (peut être dans 10 ans ?) devrait standardiser le fonctionnement des gestionnaires de paquets de Python
Le graph devrait se simplifier un peu désormais.
Je me fais un peu l'avocat du diable, mais les reproches fait au système de paquet de Python me semblent légèrement obsolètes.
C'est un titre "putaclick" qui prend les lecteurs pour des ignares (qu'ils le soient ou non). Ce titre n'apporte rien au contenu.
Le titre "Ces femmes brillantes qui ont révolutionné l'informatique" se suffit amplement à lui même. Pas la peine de rabaisser les lecteurs potentiels.
En fait, je me fustige de ce genre de titre car c'est une mode sur Youtube :
5 secrets de que tu ne connais pas
5 tips de que tu ne connais pas
top 10 des que tu ne connais pas, le numéro 7 va te surprendre
Et je trouve dommage d'utiliser les mêmes techniques pourries pour parler de personnalités importantes.
Il est tout à fait possible d'ajouter des nombres pairs et des nombres impairs, en les considérant en tant que int. C'est juste qu'il y une annotation explicite de typage pour dire cela au type checker; mais la valeur deux de mon exemple précédent est bien à la fois de type Event.t et de type int.
C'est justement ça que je trouve dommage, devoir explicitement le dire, alors qu'il est possible de le déterminer implicitement.
Cela étant, je tiens à signaler que tout ceci est réalisé statiquement (le code non annoté refuserai de compiler), ce qui n'est pas le cas de LetLang d'après tes specs. La différence étant que les cast doivent être explicites en OCaml.
Yes, pour l'instant je fais au runtime, c'est plus simple. Mais à terme, j'imagine très bien de l'analyse statique de code avant la compilation pour appliquer ce type-check "implicite".
Après, il y a un point non abordé dans ta spec : quid des listes de even ? Sont-elles des listes de number ? Si c'est le cas, il te faudra aborder la notion de variance (invariance, covariance et contravariance) des types paramétriques.
Oui, et une LEP dédiée s'attaquera à ces notions.
Je ne suis pas sûr que tu te sois posé la question, car d'après ta spec sur les fonctions, on peut lire :
NB: The class func[arguments -> return] contains every function with the same signature.'
Pourtant les types des fonctions -> est contravariant sur son entrée (arguments) et covariant sur sa sortie (return). Ainsi la classe func[number -> number] devrait aussi contenir les fonctions avec cette signature funcnumber -> int.
Problème de formulation, j'aurais du dire "with a compatible signature" à la place. Mais je me suis bien posé la question.
tu t'inspires de l'approche de Russel et Whitehead dans leur principia mathematica.
Totalement, j'ai les 3 volumes à la maison. Et quelques autres ouvrages qui traitent de théorie des ensembles, des types et catégories.
Cela étant, il y a un point qui m'intrigue dans ta spec. Tu prétends avoir rejeté l'idée d'un classe object qui contiendrait toutes les valeurs du langage, parce que cela irait à l'encontre de la hiérarchie des set. Mais qu'en est-il de cette classe que je semble pouvoir définir ?
class object (v : !even | even)
De ce que je comprends, sa fonction de compréhension vaut true pour toutes valeurs du langage, et donc l'extension de cette classe contiendrait bien toutes les valeurs.
AAAAAAAAAAAAAAH…. merci. Il va falloir que j'ajoute à ma TODO d'interdire ce genre de définition (il me semble que des outils comme coq pourrait m'aider à implémenter cette fonctionnalité).
Concrètement, ce que j'observe c'est que l'UX (ou DX pour Developer Experience ?) a pris le pas sur la sécurité.
Mettre à disposition un paquet Python : poetry publish
Mettre à disposition un paquet Node : yarn publish
Mettre à disposition une crate Rust : cargo publish
…
Par contre :
Mettre à disposition un paquet Debian : trop long, ça vaudrait le coup d'en faire un journal, ou alors un lien pour télécharger le .deb (cc Windows)
Ubuntu : on passe via les PPA (même soucis que python/node/rust/…)
Archlinux : on passe via les AUR (même soucis que python/node/rust/…)
Il serait possible je pense de "crowdsourcer" la review, comme l'ancien greenlight de Steam :
poetry/yarn/cargo publish : ton paquet est en mode "review"
après un certain nombre de review par les utilisateurs volontaires (n'importe qui dans le monde), le paquet est publié
on pourrait déterminer le nombre de review en fonction du nombre de paquet qui en dépendent ?
Comme ça, pour le développeur, c'est toujours aussi simple de distribuer ce qu'il fait. Et pour l'utilisateur, on a une certaine confiance basée sur le fait qu'il y a plus de personnes bienveillantes que de personnes malveillantes.
Ça éviterait au passage d'avoir des mise à jour de lib toutes les trois minutes (oui c'est toi que je vise eslint !!!).
Le système de review pourrait même se baser sur dependabot pour notifier les gens qui en dépendent qu'il y a une nouvelle version à review.
Le sujet c'est la confusion entre gestionnaire de paquet et dépôt de paquet.
Oui il existe plusieurs manière de résoudre les dépendances, il n'empêche que tout les gestionnaires de paquets le font. Le reste c'est du détail technique.
# Utopie
Posté par David Delassus (site web personnel) . En réponse au journal Jour du Dépassement. Évalué à 10.
Si les ressources étaient équitablement réparties, évitant certains de vivre dans l'excès pendant que d'autres vivent dans la pauvreté, mon pifomètre me dit que la terre pourrait subvenir aux besoins de plus de 15 milliards d'être humains.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Bah et Letlang alors ?
Posté par David Delassus (site web personnel) . En réponse au lien AirScript - comme Lua, mais en Rust, et différent. Évalué à 2.
Je voulais m'amuser un peu, et c'est aussi un terrain d'entraînement pour la gestion des "scopes" qui m'aidera bien pour Letlang dans le futur :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Les vacances c'est fini
Posté par David Delassus (site web personnel) . En réponse au lien [Letlang] Implémentation de TicTacToe. Évalué à 2.
Maintenant, reste plus qu'à implémenter les fonctionnalités manquantes pour compiler ce bout de code :
|>letavec "destructuring"printetreadlineUne fois fait, on est d'accord que c'est turing-complete? :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Atom était encore en vie?
Posté par David Delassus (site web personnel) . En réponse au journal Adieu Atom :(. Évalué à 4.
VS Code est rapide et consomme bien moins de RAM que Atom, et c'est aussi du Electron.
Comme quoi, c'est tout à fait possible de faire les choses bien.
8-16GB ça a l'air d'être le standard quand tu achètes un PC portable.
Ca serait bien que Electron (ou Tauri) soit mutualisé (je pense a urxvtd + urxvtc qui mutualise les terminaux dans un seul process).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Atom était encore en vie?
Posté par David Delassus (site web personnel) . En réponse au journal Adieu Atom :(. Évalué à 5.
J'ai abandonné cet éditeur pour retourner sur Sublime Text 3 après le second freeze total.
C'était avant même que VS Code ne pointe son nez (adieu Sublime Text 3, j'ai toujours aimé ta simplicité et ta sobriété, dire que tu m'as fait abandonner vim).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: libretro core?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 2. Dernière modification le 08 juin 2022 à 14:00.
Ah j'avais mal compris pardon :p
C'est parce qu'en vérité, rien n'est simple :p
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'ai appris plein de trucs et suis tenté par ECS
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3.
Ca fait plaisir de faire des choses utiles :) Merci.
Et surement plein d'autres encore.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: libretro core?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 7.
Bah non justement, en Rust les concepts ne sont pas masqués :
Box<T>Rc<T>Cow<T>Mutex<T>souvent avecArc<Mutex<T>>Sendet/ouSyncIl n'y a rien de plus explicite, ces informations apparaissent dans le système de type qui va permettre au compilateur de s'assurer que les règles qui gouvernent ces concepts sont bien respectées.
C'est subjectif. Je trouve aussi que la syntaxe est lourde, mais c'est pas plus moche que des templates C++ qu'on observe en masse dans les librairies "header only" (beurk).
Exagération obsolète.
C'est pas sous prétexte d'être plus safe. C'est sous prétexte de prendre aucune décision pour le développeur. On le laisse gérer lui même pour qu'il puisse faire des applications performantes, on le laisse choisir lui même les trade-offs.
Le Go est un langage safe aussi, mais les trade-offs ont été choisi par les développeurs du langage/compilateur. Et toi, pauvre petit développeur, tu dois faire avec.
Ca j'ai mis pas mal de temps à le comprendre. Mais en gros, le choix qui a été fait par les développeurs de Rust est le suivant :
Il vaut mieux rejeter un programme valide qu'accepter un programme potentiellement invalide.
Le
unsafepermet au développeur d'indiquer au compilateur que, même si le compilateur ne sait pas le déterminer, le bloc de code est safe. C'est à utiliser avec parcimonie, mais le côté "non safe" (qui est plutôt "n'a pas réussi a déterminer la safety") ne fuit pas vers le reste du programme.De plus, le hardware sur lequel tourne le code Rust (ton PC) est par nature "unsafe". Il y a donc naturellement des choses que l'on ne peut pas déterminer à l'avance comme étant "safe".
Au final, utiliser "unsafe" c'est déléguer à l'OS la garantie que l'opération est safe. Tout comme en Haskell on délèguerait la gestion d'une IO (impure) au runtime.
Et c'est dommage. Ce langage n'est pas parfait, loin de là. Beaucoup de fonctionnalités ne sont pas encore stabilisées (hello générateurs/code asynchrone/…). La syntaxe est dure à comprendre.
Mais plus j'apprend ce langage, plus mes hypothèses et opinions se cassent la figure, pour laisser place à la réalité.
Grâce à Rust, je me pose des questions sur mon code, mes données, que je ne me posais pas avant, et ce même dans d'autres langages.
Si j'ose dire, apprendre le Rust fait de moi un meilleur développeur C / C++.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: C++, haut niveau ?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3. Dernière modification le 07 juin 2022 à 21:35.
D'après les sources de la glibc :
C'est toujours sbrk qui est utilisé.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: libretro core?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3.
Parce que c'était pas le sujet du "challenge".
Je suis parti de "je voudrais bien ouvrir une fenêtre de manière cross-platforme sans embarquer une DLL" -> winit
Pour continuer vers "j'aimerais bien une primitive sympa pour dessiner dedans" --> pixels
Ensuite, je me suis hurté au compilateur Rust, ce qui m'a motivé à écrire cet article, comme un rappel personnel que ce que j'ai appris depuis 20 ans est faux : la programmation c'est compliqué, les langages nous mentent en cachant cela.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: C++, haut niveau ?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3.
malloc/calloc/realloc/free (et alloca ne l'oublions pas), ce n'est pas de la gestion de la mémoire.
C'est à toi de calculer la taille suffisante pour stocker ta donnée au préalable. C'est à toi de t'assurer que le pointeur retourné par realloc est toujours le même qu'avant. C'est à toi de t'assurer de ne pas appeler free 2 fois sur le même pointeur.
L'implémentation des malloc qui appelle pour toi les syscall
sbrketbrket organisent la heap pour s'y retrouver reste quelque chose de très bas niveau, et peu différent de ce que tu ferais en Assembleur.Maintenant, concernant le C++ et le Go, c'est mécanisme de gestion de mémoire sont bien masqués à l'utilisateur. En Go ce n'est pas toi qui appelle le Garbage Collector, ou qui alloue la mémoire pour tes objets. En C++ ce n'est pas toi qui appelle tel ou tel constructeur, ni les destructeurs. Ces choses sont présentes, mais pas exposés à l'utilisateur.
Je persiste et signe donc, C, C++, Go, et bien d'autres langages : ne sont pas explicite sur les concepts sous-jacents.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: C++, haut niveau ?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3.
Ce qui suit n'est que mon avis.
Pour moi, en C++ tu n'appelle pas manuellement les constructeurs (d'assignation, de copie, …) ou les destructeurs. Donc la durée de vie d'une variable au sein d'une scope est gérée pour toi. En C tu devras appeler ces fonctions à la main.
La STL fournit nombre d'abstractions qu'il est désormais recommandé d'utiliser, sauf si tu as un besoin spécifique bien sûr.
L'héritage, déjà rien que ça. Je recommande la lecture de ooc.pdf pour comprendre comment l'implémenter en C, et ainsi comprendre comment le C++ masque un autre concept bas niveau (organisation de la mémoire, édition des liens, etc…).
Ce qui fait qu'un langage peut être considéré comme haut niveau selon moi, c'est le nombre d'abstraction présente. Et C++ possède beaucoup d'abstraction, la ou le C n'en possède quasiment aucune.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: encore ?
Posté par David Delassus (site web personnel) . En réponse au lien Python 3.11, plus rapide pour de vrai de vrai. Évalué à 8.
Sauf que là depuis la 3.10, c'est la vocation de toute la team d'améliorer les perfs de Python pour revenir dans la course contre Javascript, Java, Go, etc…
Car ces dernières années, avec les ajouts de fonctionnalités, il a pas mal ralentit.
Alors oui, on a déjà eu quelques optimisations du bytecode en 3.9 et 3.10, mais la 3.11 ils ont décidé de prendre la pelle à merde et de creuser.
Et a chaque nouvelle rc de la 3.11, les benchs sont de plus en plus positifs. C'est surtout ça que tu entends depuis un certains temps, le progrès de la 3.11 sur ce sujet.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Le rapport?
Posté par David Delassus (site web personnel) . En réponse au lien HTML partout, Javascript nulle part ?. Évalué à 2. Dernière modification le 01 juin 2022 à 04:15.
Pareil que pour le CSS, les images, et autres resources donc. Bienvenue dans l'hypermedia, ça existe depuis les années 1990.
Si toutes les ressources sont sur le même domaine, comme le décrit la phrase de Zenitram qui tu critiques, le firewall ne bloquera pas les resources si il autorise le site internet.
Shit in, shit out.
Si le but de l'article n'est pas de râler pour râler, mais de sensibiliser à l'accessibilité d'un site web. TOUTES les resources chargées de façon asynchrone risque d'impacter cette accessibilité. Se concentrer sur le JS c'est donc du troll histoire de.
Quote du site :
Je rajouterai donc :
Et je conclurai par quelques notions :
Quoi ? De la communication non-violente sur LinuxFR ? Mais ou vas le monde…
Plus sérieusement, si tu veux de la communication non violente, évite de commencer tes commentaires par un "Non" catégorique qui ne signifie que "Tu as tort, j'ai raison, je n'ai même pas besoin de développer, mais je vais le faire quand même".
Aller je termine avec un trait d'humour. On design comment un site pour les utilisateurs qui ont cassé leur écran ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Le rapport?
Posté par David Delassus (site web personnel) . En réponse au lien HTML partout, Javascript nulle part ?. Évalué à 6.
Faut apprendre à lire.
vs
Vous dites la même chose.
Oui l'article parle cependant de bien d'autres choses que l'accessibilité du JS, donc :
Cette proposition est toujours valable, surtout lorsqu'elle commence par "Perso" qui démontre une expérience personnelle (certes anecdotique, mais néanmoins existante)
Et tu oublis l'essence même du commentaire à la base :
Ce qui est 200% vrai.
Ah c'est facile de commencer un commentaire par "Non" et ensuite de montrer qu'on a rien compris :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Environnement très dégradé
Posté par David Delassus (site web personnel) . En réponse à la dépêche Environnement moderne de travail Python. Évalué à 4.
En tant que développeur de librairie, j'utilise poetry, il va s'occuper de générer le setup.py comme un grand et de pousser sur PyPI. Mes utilisateurs font comme ils veulent ensuite.
En tant que développeur d'application --> https://pyinstaller.org/en/stable/
Tout embarqué dans un seul exécutable (certes un peu plus gros vu qu'il embarque l'interpréteur Python et tout les modules importés). Ensuite je fournis le ".exe" via les releases Github ou, si la motivation est là, le paquet deb/rpm/msi/…
En tant qu'utilisateur, je laisse la distribution gérer son truc elle même, j'ai même pas envie de savoir quelle version de Python elle utilise. De toute façon, mon Python à moi il est dans /opt car je suis les beta/rc/etc… qui sont rarement dans les dépôts.
Au final, cela fait bien 15 ans que je n'ai pas subi ce que décrit ce xkcd.
D'ailleurs :
Le graph devrait se simplifier un peu désormais.
Je me fais un peu l'avocat du diable, mais les reproches fait au système de paquet de Python me semblent légèrement obsolètes.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: ...
Posté par David Delassus (site web personnel) . En réponse au lien Ces femmes brillantes qui ont révolutionné l’informatique et que personne ne connaît. Évalué à 4.
Merci pour ces statistiques.
Cependant, cela ne change pas mon propos.
C'est un titre "putaclick" qui prend les lecteurs pour des ignares (qu'ils le soient ou non). Ce titre n'apporte rien au contenu.
Le titre "Ces femmes brillantes qui ont révolutionné l'informatique" se suffit amplement à lui même. Pas la peine de rabaisser les lecteurs potentiels.
En fait, je me fustige de ce genre de titre car c'est une mode sur Youtube :
Et je trouve dommage d'utiliser les mêmes techniques pourries pour parler de personnalités importantes.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# ...
Posté par David Delassus (site web personnel) . En réponse au lien Ces femmes brillantes qui ont révolutionné l’informatique et que personne ne connaît. Évalué à 4.
"Que personne ne connaît" c'est un peu fort. Je suis totalement pour les mettre en avant, mais arrêtons de prendre tout le monde pour des ignares.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Type des paramètres
Posté par David Delassus (site web personnel) . En réponse au journal [Letlang] Hommage à Leonardo Pisano Fibonacci. Évalué à 3.
Idéalement oui, j'aimerais bien arriver à une syntaxe de ce type. Étape par étape :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Complexité algorithmique
Posté par David Delassus (site web personnel) . En réponse au journal [Letlang] Hommage à Leonardo Pisano Fibonacci. Évalué à 2.
Faut vraiment être condescendant pour croire que je ne connais pas la technique de mémoïsation de ce genre d'algorithme.
C'est le genre de truc que tu vois à ton premier cours de programmation dynamique.
Ici l'intérêt, c'est pas la suite de fibonacci en elle même, mais bien le fait que je puisse la compiler et l'exécuter en Letlang.
Une implémentation future avec mémoïsation sera bien évidemment possible. Mais pour l'instant, on fait étape par étape.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Pourquoi parler de sa "net worth"?
Posté par David Delassus (site web personnel) . En réponse au lien rest in peace David Ward. Évalué à 7.
C'est un peu morbide je trouve quand on parle du décès de quelqu'un de parler immédiatement de sa thune.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: théorie des ensembles pas naives
Posté par David Delassus (site web personnel) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 2.
C'est justement ça que je trouve dommage, devoir explicitement le dire, alors qu'il est possible de le déterminer implicitement.
Yes, pour l'instant je fais au runtime, c'est plus simple. Mais à terme, j'imagine très bien de l'analyse statique de code avant la compilation pour appliquer ce type-check "implicite".
Oui, et une LEP dédiée s'attaquera à ces notions.
Problème de formulation, j'aurais du dire "with a compatible signature" à la place. Mais je me suis bien posé la question.
Totalement, j'ai les 3 volumes à la maison. Et quelques autres ouvrages qui traitent de théorie des ensembles, des types et catégories.
AAAAAAAAAAAAAAH…. merci. Il va falloir que j'ajoute à ma TODO d'interdire ce genre de définition (il me semble que des outils comme coq pourrait m'aider à implémenter cette fonctionnalité).
Au passage :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Personne n'est à l'abri
Posté par David Delassus (site web personnel) . En réponse au lien A growing club of broken-by-design package managers. Évalué à 7.
Concrètement, ce que j'observe c'est que l'UX (ou DX pour Developer Experience ?) a pris le pas sur la sécurité.
poetry publishyarn publishcargo publishPar contre :
Il serait possible je pense de "crowdsourcer" la review, comme l'ancien greenlight de Steam :
poetry/yarn/cargo publish: ton paquet est en mode "review"Comme ça, pour le développeur, c'est toujours aussi simple de distribuer ce qu'il fait. Et pour l'utilisateur, on a une certaine confiance basée sur le fait qu'il y a plus de personnes bienveillantes que de personnes malveillantes.
Ça éviterait au passage d'avoir des mise à jour de lib toutes les trois minutes (oui c'est toi que je vise eslint !!!).
Le système de review pourrait même se baser sur dependabot pour notifier les gens qui en dépendent qu'il y a une nouvelle version à review.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Personne n'est à l'abri
Posté par David Delassus (site web personnel) . En réponse au lien A growing club of broken-by-design package managers. Évalué à 2.
C'est pas le sujet.
Le sujet c'est la confusion entre gestionnaire de paquet et dépôt de paquet.
Oui il existe plusieurs manière de résoudre les dépendances, il n'empêche que tout les gestionnaires de paquets le font. Le reste c'est du détail technique.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Personne n'est à l'abri
Posté par David Delassus (site web personnel) . En réponse au lien A growing club of broken-by-design package managers. Évalué à 2. Dernière modification le 13 mai 2022 à 16:59.
Oui mais ici c'est pas l'utilisation aveugle de curl, c'est la confiance aveugle à
http://mon-super-virus.com/fuck-you.shhttps://link-society.com - https://kubirds.com - https://github.com/link-society/flowg