Je ne me suis pas encore penché sur la question. J'avais gratté un peu la surface des solveurs SAT mais sans plus. Pour le coup, je compte contacter des gens plus compétents à l'INRIA pour m'aider sur cet aspect.
tu risques de te retrouver à devoir gérer des problèmes d’arrondis sur les flottants, d’intervalle et caetera …
J'avais imaginé utiliser libgmp pour représenter les nombres et esquiver les problèmes d'arrondi. A voir comment ça s'intègre avec le solveur d'équation.
J'espère pouvoir utiliser un solveur existant (et pourquoi pas plusieurs backend qu'on peut choisir à la compilation ?) et ne pas devoir en implémenter un de 0.
Le système de contraintes (que je trouve vraiment cool) demander d'implémenter un solveur d'équation, c'est pas très lourd quand on dépasse les exemples simples ?
Exact, le solveur d'équation va être la fonctionnalité la plus difficile à implémenter, et je n'ai aucune idée des performances que cela donnera.
J'ai même songé à faire un bête appel à Wolfram Alpha pour le coup. Je vais sûrement essayer de les contacter à un moment.
je suis tout de même très impressionné par le volume de fonctionnalités.
Avant d'être impressionné, attend que je l'implémente :)
L'avantage que je vois immédiatement sur des langages comme Haskell, c'est l'expressivité de letlang
Cette expressivité tu la retrouves beaucoup en mathématiques, qui à l'avantage de pouvoir utiliser plus de symboles qu'il n'existe sur un clavier et de ne pas être limité à une seule ligne de texte pour écrire une expression.
Je m'étais d'ailleurs acheté "Principia Mathematica" et 2-3 autres livres, pour au final me rendre compte que cette expressivité vient du manque de règles dans l'écriture des mathématiques.
Tu décris ça comme un "side project", je suis plutôt impressionné.
Rien d'impressionnant pour l'instant, au niveau du code j'ai l'AST, et j'ai commencé à écrire le validateur sémantique. Même pas encore de parseur à l'heure actuelle (je compte faire ça avec la librairie pest).
Le plus abouti dans le projet, c'est le design de la syntaxe et des fonctionnalités.
À défaut d'avoir les compétences pour collaborer
J'avoue également manquer de compétences sur l'implémentation de certains aspects du langage, c'est l'occasion d'apprendre :)
succès qui dépendra probablement de la disponibilité d'une collection de modules standard
Pour moi, ce sera un succès le jour ou j'arrive à compiler un programme écrit en Letlang ^
En quoi est-ce différent du système de haskell, dont les classes de type permet de résoudre élégamment se problème ?
C'est également similaire au système de type de TypeScript ou toute forme de pattern matching structurelle que l'on trouve en Erlang/Elixir, et qui commence à apparaître en Python avec match.
Ici c'est pour dire que l'information de type ne se situe pas au niveau de la variable. Il n'y aura pas de mot clé typeof par exemple.
Pour le système de contrainte, tu as vu juste :
let x-3 = 0 // => x = 3, c'est la seule solution
x:=2 // Erreur
x:=3 // Valide mais inutile, on sait déjà que x = 3
Quand on ajoute une contrainte, est-elle testé à la compilation ?
Comme je l'ai dit dans le disclaimer, très peu de code pour l'instant. Le but ultime est d'en faire un langage compilé vers LLVM IR, pour l'instant c'est un interpréteur.
Je compte faire le plus de vérifications possibles à la compilation, mais l'exemple suivant devra être testé à l'exécution :
let x: int
let x > 0
x := readline() |> parse_int() # pipeline operator comme en Elixir
Blitzstream (échecs) : https://www.youtube.com/c/VideosEchecs je vous recommande les analyses des parties du championnat du monde qui est en cours, Magnus contre Nepomniachtchi
tu peux moinser les commentaires et journaux qui ne te satisfont pas pour quelques raisons que ce soit
tu peux étiqueter les journaux inutiles de manière à bien indiquer ta désapprobation
De demander aux utilisateurs de le faire ;
tu peux ne pas afficher les journaux en page d'accueil
De ne pas consulter une grande partie du site ;
le système actuel est bien fait
De suivre la politique de l'autruche, ignorer le problème, et laisser le contenu général du site perdre en qualité.
La tradition des journaux inutiles répondant aux journaux inutiles est ancienne :-)
Ce qui provoque un flot de "spam" sur la page d'accueil du site. Pas très attrayant…
Certaines traditions devraient tout simplement disparaître, ou alors on rajoute une section "toilette" sur le site et on tire la chasse de temps à autres.
Le typage faible, c'est lorsque le compilateur/interpréteur n'est pas strict sur la vérification de type avant exécution du code.
La majorité des langages avec typage dynamique ont donc par définition un typage faible.
Je prend par exemple Python:
3 < "something"
int.__lt__(3, "something")
Et oui, on check pas le type on vérifie juste si la méthode est défini --> typage faible.
En Erlang/Elixir on peut comparer aussi différents types:
1 < :atom
1 == 1.0
C'est donc du typage faible.
Pareil dans les autres langages que j'ai cité.
Bordel, je pourrais rajouter le langage C/C++ dans le typage faible pour la bonne et simple raison que je peux aller chercher un pointeur sur la zone mémoire et convertir ça dans n'importe quel autre type.
Tu ne répond donc pas à la question, en quoi le typage faible est il un problème ?
Je vais même aller plus loin, l'appellation "typage fort" et "typage faible" n'a aucun sens, et est complètement inutile.
Tu ne répond d'ailleurs à aucune des autres critiques. Donc oui on va arrêter là car tu n'es clairement la que pour le troll.
Des micro-package c'est normal mais 1 ligne sérieusement….
Ce genre de chose c'est en aucun cas la faute du langage. Je peux t'écrire des libs de 1 ligne en Python, en Go, en Rust, en C++, etc…
Tu n'as qu'a pas les utiliser, personne t'y obliges.
Par contre si je pouvais avoir une lib pour implémenter String.capitalize avec les edge cases du type emoji, kanji et autres alphabets exotiques, etc… Je l'ajouterai sans regrets car j'ai pas envie de les gérer moi même.
J'espère qu'il y a les packages isEven, isOdd, isTrue et isFalse faudrait quand même pas devoir les implémenter moi même.
Des exemples à la place d'un avis subjectif sorti de nul part ?
typage faible
Python, Erlang/Elixir, Lua, PHP, Perl, Ruby, … En quoi c'est un problème ?
C'est drôle tu défends JavaScript en nous parlant de Typescript.
Donc après avoir cité la norme EcmaScript, toutes les évolutions du language Javascript qui ont eu lieu et qui sont en cours, j'ai le malheur de mentionner Typescript une seule fois et c'est tout ce que tu retiens ?
Que ce soit du copier/coller, ou du require. C'est emmerdant car on doit le maintenir. Ce genre de code devrait faire partie de la stdlib.
Maintenant tu as quelqu'un qui a préféré fournir un ensemble de micro package, au lieu de fournir un immense package. Pourquoi ? Parce qu'il a estimé que les gens n'utiliserai pas un gros package sous prétexte que 95% de ce dernier ne leur sert pas.
j'avais l'habitude de désassembler les binaires de mes tests en C, et plus ça va et moins ça ressemble…
Désactive les optimisations du compilateur, et comme par magie ça redeviendra comme avant. Comme Linus le dit dans la vidéo, fut un temps les compilateurs devaient être simple. Ils sont maintenant très intelligent.
je vois (pour ma part) le même assembleur et mon algo est tout aussi proche de la machine
Bizarre venant de langage avec un runtime, un garbage collector, et tout plein d'autres features qui viennent modifier l'assembleur produit.
Si je dis ironiquement que c'est mieux, c'est parce-que ça me semble l'évolution naturelle du C
Si tu as regardé la vidéo, tu comprendre que le titre racoleur de ce lien n'est qu'une infime partie du message de Linus: I have yet to see a language that comes close to C in that respect.
En aucun cas il est dit que le C est le meilleur langage de tout les temps, tout usages confondus, toutes plateformes confondues, de manière purement objective.
Mais pas grave si tu ne veux pas le comprendre.
Oui, pas grave non plus si tu parles en lisant que le titre.
Je trouve hallucinant les dépendances qui comportent à peine quelques lignes de code (voir une seule comme dans l'exemple !) et que des gens l'utilisent au lieu de l'implémenter eux-mêmes.
La faute à une stdlib trop pauvre. Je vois la même chose avec Rust mais comme ça compile statiquement au lieu d'avoir un node_modules de 10Go, ça choque personne.
Le code derrière qui utilise ça ne doit pas être bien beau….
Bah… pas forcément… En quoi le code qui copie/colle 3 lignes serait plus beau que le code qui fait un require?
Javascript est immonde et devrait arrêter d'être écrit et simplement généré à partir d'autre chose.
Oof, on était pas encore Vendredi pour un troll pareil.
Cracher comme ça sur un langage c'est vraiment ne pas comprendre ce qu'il apporte ni le pourquoi du comment.
Alors rappelons un peu l'histoire, Javascript est une implémentation de la norme EcmaScript (QtScript en est une autre pas exemple). La version supporté à 100% par la totalité des plateforme c'est la version 5 de la norme.
Cette norme a beaucoup évolué. La version 6 date de 2015, depuis on a abandonné ce numérotage et on est passé sur des dates, nous sommes aujourd'hui à ES2020. C'est un langage beaucoup plus mature, qui règle nombre des problèmes qui étaient présent dans la version 5, tout en gardant une rétro-compatibilité phénoménale. Et oui ton code d'il y a 20 ans va toujours pouvoir s'exécuter sans aucun soucis aujourd'hui. Montre moi un autre langage comme ça (j'ai C++, Python et Java dans le viseur).
En plus, aujourd'hui il y a TypeScript, dont le système de type est tellement expressif qu'il est une machine de Turing permettant des implémentations assez drôles:
C'est le même problème avec tout les dépôts communautaires sans review.
Avant d'installer un paquet de AUR on conseille fortement :
Les teams DevSecOps me chuchotent à l'oreille que ces conseils s'appliquent à toutes les dépendances externes peu importe leurs provenance (dépôt officiel ou non).
En fait, ça fonctionne de manière similaire avec NPM, sauf qu'il faut les traiter manuellement.
Good to know :)
c'est quand même à l'empaqueteur de les générer, ou bien ?
T'as de l'outillage pour t'aider à les générer, mais sur le principe oui, si l'empaqueteur ne les fournis pas, personne va les fournir pour toi.
Mais ça c'est pour des logiciels complets, où est-ce que c'est aussi utilisable pour des bibliothèques ?
Tu as par exemple des images Docker pour te fournir une alpine/debian/ubuntu avec un JDK dans une version spécifique. Pareil pour Python, Erlang/Elixir, etc…
Fun fact, j'ai une application Elixir qui embarque dans son image Docker un binaire Go, dans la phase de build j'ai ceci:
COPY --from=golang:1.16-alpine /usr/local/go/ /usr/local/go/
ENV PATH="/usr/local/go/bin:${PATH}"
Alors certes, j'imagine mal une image Docker "python-django" ou "node-expressjs" sur DockerHub. Cependant j'ai pas mal vu en entreprise des images Docker de base du style "java-jdk11-springboot" partagées entre les différentes teams.
Accessoirement, pour Windows si tu veux bosser avec la SDL, tu chope un ZIP qui te donne les headers et les DLLs.
Et ouais, sur Alpine, pas de glibc, musl, pas de wheels donc, du coup tu dois tout build toi même. En 2021, build un paquet Python sur Alpine peut nécessiter :
gcc
g++
rustc (pour le paquet cryptography, donc tout ce qui touche de prêt ou de loin à SSL ou la génération de nombre aléatoire)
myriade de libprout-dev
Malgré ça, même avec les wheels, on est pas au point côté Python (je pense à l'intégration de GTK en Python qui aujourd'hui ne peux pas être faite avec un simple pip install, contrairement à PySide pour Qt).
Après, on a conda qui résoud pas mal de problème, mais on est sur quelque chose de similaire à Flatpak du coup (un système complètement parallèle à celui de la distro).
Pour des écosystèmes comme Rust, ou Go, la question ne se pose pas vraiment, puisque l'artefact final est un binaire statique.
Concernant NPM, à ma connaissance, il n'existe pas d'équivalent des wheels de Python, et c'est un problème car cela complexifie grandement l'installation de paquet. Je prend comme exemple une vielle version de sass-loader dont le build system dépendait de node-gyp (je te hais) qui avait besoin de python2 mais n'utilisait pas l'alias /usr/bin/python, et donc sur les systèmes ou tu as /usr/bin/python pour python2 et /usr/bin/python3 pour python3 (coucou Debian), tu devais faire le link toi même.
Erlang/Elixir te produisent une release sous forme de tar.gz contenant le runtime complet de l'appli, que tu peux extraire ou tu veux. J'aime cette méthode.
Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans C:\Program Files/opt. C'est juste plus simple.
La confiance que j'apporte à NPM/PyPI/etc… c'est sur son intégration avec le reste de l'écosystème du langage.
Je ne compte plus le nombre de fois ou j'ai eu des soucis avec un apt install python-prout qui s'est terminé par un virtualenv dans /opt.
La confiance dont tu parles concerne la sécurité, et oui un dépôt officiel d'une distribution ou chaque contribution est revue par un organisme tier a plus de crédibilité qu'un dépôt communautaire (coucou AUR et archlinux?).
Maintenant, si dans ta société tu as les moyens pour une équipe en charge de la cybersécurité, ces derniers vont te fournir :
un dépôt DEB/RPM/whatever contenant une liste de logiciel autorisé à installer
un dépôt Maven/NPM/PyPI privé contenant les librairies qui ont été auditées et autorisées
Si tu veux être parano et ne pas faire confiance a un quidam, tu l'es jusqu'au bout et tu ne fais pas confiance à un organisme tier sur lequel tu n'as aucun contrôle. En fait tu va vraiment jusqu'au bout et tu fais pas confiance à quelque chose qui a été produit par un humain.
Donnez nous de la déduplication au niveau du système de fichier et ça règlera le problème.
Si tu fais tourner beaucoup de conteneurs Docker, tu as déjà de la dédup non négligeable lors du téléchargement grâce à son système de layers.
En tant qu'entreprise, distribuer un conteneur Docker est infiniment plus simple et pour nous (éditeur) et pour le client (utilisateur). Je sais que ça marchera pareil que sur nos environnements de test, et le client sait qu'il pourra le déployer comme le reste de ses applications.
J'adore Docker, et si j'avais pu avoir ça il y a 10 ans, ça m'aurait évité beaucoup de travail répétitif
et pénible dans ma carrière.
Le soucis des libs de 4 lignes c'est la pauvreté de la stdlib.
En Rust ça pose pas problème, c'est compilé statiquement. En Python la stdlib est colossale.
Ce que je voulais dire c'est que j'ai plus confiance dans :
$ yarn add moment
$ pip install trio Que :
$ apt install moment-js
$ yum install python-trio
Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.
Premièrement, j'ai plus confiance dans NPM/PyPI/Hex.pm/Crates.io pour empaqueter correctement une lib du-dit langage que Debian par exemple.
Deuxièmement, ça a pas l'air de déranger les utilisateurs de Archlinux et AUR d'installer des paquets avec des logiciels potentiellement setuid root venant d'un repository non contrôlé.
IMHO, c'est aux mainteneurs d'une distribution de créer les paquets pour cette dernière.
Qui d'autres qu'eux peuvent assurer la compatibilité de l'intégration avec le reste du système ?
Et surtout, si les développeurs devaient gérer eux mêmes la création des paquets pour toutes les distributions, ils n'auraient pas le temps de développer la-dite application…
Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?
DEB:
Debian ?
Ubuntu ?
Linux Mint ?
..?
RPM:
RedHat ?
CentOS ?
Fedora ?
..?
Je peux t'assurer que les développeurs solo et bénévole vont te caller un Makefile et un README en te disant de te débrouiller avec des instructions "qui marchent sur leurs machines".
Oui Flatpak, Snap, et compagnie ne sont pas des solutions idéales d'un point de vue mainteneur de distribution (doublons de runtime, et toute la ribambelle d'argument que tu peux trouver à droite/à gauche sur le net).
Mais d'un point de vue développeur c'est un moyen de cibler tout le monde sans se poser de question.
Et d'un point de vue utilisateur c'est un moyen d'avoir des applications populaires sans devoir faire une pétition aux mainteneurs de la distribution qui sont occupés à avoir des débats stériles sur le vocabulaire autorisé.
Alors cet article m'a fait beaucoup rire d'ailleurs. A un moment il parle de Windows:
If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.
Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.
Les gens commencent-ils à se rendre compte que "trop de choix tue le choix ?" après avoir perdu une soirée à chercher quelque chose de correct sur Netflix ?
Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).
[^] # Re: Choix du nom
Posté par David Delassus (site web personnel) . En réponse au journal Letlang, encore un nouveau langage de programmation. Évalué à 4.
En mathématiques, tu verras très souvant le genre de phrase :
Ou en anglais :
Dans mes premiers brouillons, tout se définissait en utilisant le mot clé
let(fonctions, classes, etc…). Ce qui a donné le nom Letlang.J'ai fini par écarter cette dernière idée par soucis de lisibilité.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Contraintes
Posté par David Delassus (site web personnel) . En réponse au journal Letlang, encore un nouveau langage de programmation. Évalué à 2.
Je ne me suis pas encore penché sur la question. J'avais gratté un peu la surface des solveurs SAT mais sans plus. Pour le coup, je compte contacter des gens plus compétents à l'INRIA pour m'aider sur cet aspect.
J'avais imaginé utiliser libgmp pour représenter les nombres et esquiver les problèmes d'arrondi. A voir comment ça s'intègre avec le solveur d'équation.
J'espère pouvoir utiliser un solveur existant (et pourquoi pas plusieurs backend qu'on peut choisir à la compilation ?) et ne pas devoir en implémenter un de 0.
Je vais lire ça avec attention, merci! :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Contraintes
Posté par David Delassus (site web personnel) . En réponse au journal Letlang, encore un nouveau langage de programmation. Évalué à 3.
Exact, le solveur d'équation va être la fonctionnalité la plus difficile à implémenter, et je n'ai aucune idée des performances que cela donnera.
J'ai même songé à faire un bête appel à Wolfram Alpha pour le coup. Je vais sûrement essayer de les contacter à un moment.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Wow
Posté par David Delassus (site web personnel) . En réponse au journal Letlang, encore un nouveau langage de programmation. Évalué à 3.
Avant d'être impressionné, attend que je l'implémente :)
Cette expressivité tu la retrouves beaucoup en mathématiques, qui à l'avantage de pouvoir utiliser plus de symboles qu'il n'existe sur un clavier et de ne pas être limité à une seule ligne de texte pour écrire une expression.
Je m'étais d'ailleurs acheté "Principia Mathematica" et 2-3 autres livres, pour au final me rendre compte que cette expressivité vient du manque de règles dans l'écriture des mathématiques.
Merci pour ton retour en tout cas.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Side project
Posté par David Delassus (site web personnel) . En réponse au journal Letlang, encore un nouveau langage de programmation. Évalué à 5.
Bonne année aussi à toi ! :)
Rien d'impressionnant pour l'instant, au niveau du code j'ai l'AST, et j'ai commencé à écrire le validateur sémantique. Même pas encore de parseur à l'heure actuelle (je compte faire ça avec la librairie pest).
Le plus abouti dans le projet, c'est le design de la syntaxe et des fonctionnalités.
J'avoue également manquer de compétences sur l'implémentation de certains aspects du langage, c'est l'occasion d'apprendre :)
Pour moi, ce sera un succès le jour ou j'arrive à compiler un programme écrit en Letlang ^
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Intéressant
Posté par David Delassus (site web personnel) . En réponse au journal Letlang, encore un nouveau langage de programmation. Évalué à 3.
C'est également similaire au système de type de TypeScript ou toute forme de pattern matching structurelle que l'on trouve en Erlang/Elixir, et qui commence à apparaître en Python avec
match.Ici c'est pour dire que l'information de type ne se situe pas au niveau de la variable. Il n'y aura pas de mot clé
typeofpar exemple.Pour le système de contrainte, tu as vu juste :
Comme je l'ai dit dans le disclaimer, très peu de code pour l'instant. Le but ultime est d'en faire un langage compilé vers LLVM IR, pour l'instant c'est un interpréteur.
Je compte faire le plus de vérifications possibles à la compilation, mais l'exemple suivant devra être testé à l'exécution :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: On en veut pas de politique autre que open-source
Posté par David Delassus (site web personnel) . En réponse au journal La rubrique liens doit-elle être un copier/coller de Hacker News (de ycombinator). Évalué à -1.
"Propagande politisée" n'en fait pas non plus parti.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Oups, j'ai publié ma liste d'abonnements quasi-complète
Posté par David Delassus (site web personnel) . En réponse au journal Je préfère LinuxFr.org. Évalué à 5.
Developpez.com est une très bonne source d'information technique : https://developpez.com/
DataTau, un équivalent de HackerNews pour les amoureux des data-sciences : https://datatau.net/
Medium, malgré son paywall, il y a de superbes articles par moment : https://medium.com
Après, je suis beaucoup sur youtube avec des chaînes comme :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Une nouvelle tradition de chiotte
Posté par David Delassus (site web personnel) . En réponse au journal Merci LinuxFr. Évalué à 3.
Oui parce que la solution au spam c'est :
De demander aux utilisateurs de le faire ;
De ne pas consulter une grande partie du site ;
De suivre la politique de l'autruche, ignorer le problème, et laisser le contenu général du site perdre en qualité.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Une nouvelle tradition de chiotte
Posté par David Delassus (site web personnel) . En réponse au journal Merci LinuxFr. Évalué à 6.
Ce qui provoque un flot de "spam" sur la page d'accueil du site. Pas très attrayant…
Certaines traditions devraient tout simplement disparaître, ou alors on rajoute une section "toilette" sur le site et on tire la chasse de temps à autres.
Quand le moment sera venu et que ce sera plus à l'état de PoC :p
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Une nouvelle tradition de chiotte
Posté par David Delassus (site web personnel) . En réponse au journal Merci LinuxFr. Évalué à 10.
Cool, LinuxFR devient vraiment une collection d'article inutile produit par des gens en manque d'attention.
Vous vous êtes cru sur Twitter les gars ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . En réponse au lien I will pay you cash to delete your npm module . Évalué à 1. Dernière modification le 27 novembre 2021 à 15:03.
Haha ok.
Le typage faible, c'est lorsque le compilateur/interpréteur n'est pas strict sur la vérification de type avant exécution du code.
La majorité des langages avec typage dynamique ont donc par définition un typage faible.
Je prend par exemple Python:
3 < "something"
int.__lt__(3, "something")
Et oui, on check pas le type on vérifie juste si la méthode est défini --> typage faible.
En Erlang/Elixir on peut comparer aussi différents types:
1 < :atom
1 == 1.0
C'est donc du typage faible.
Pareil dans les autres langages que j'ai cité.
Bordel, je pourrais rajouter le langage C/C++ dans le typage faible pour la bonne et simple raison que je peux aller chercher un pointeur sur la zone mémoire et convertir ça dans n'importe quel autre type.
Tu ne répond donc pas à la question, en quoi le typage faible est il un problème ?
Je vais même aller plus loin, l'appellation "typage fort" et "typage faible" n'a aucun sens, et est complètement inutile.
Tu ne répond d'ailleurs à aucune des autres critiques. Donc oui on va arrêter là car tu n'es clairement la que pour le troll.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . En réponse au lien I will pay you cash to delete your npm module . Évalué à 0.
Ce genre de chose c'est en aucun cas la faute du langage. Je peux t'écrire des libs de 1 ligne en Python, en Go, en Rust, en C++, etc…
Tu n'as qu'a pas les utiliser, personne t'y obliges.
Par contre si je pouvais avoir une lib pour implémenter String.capitalize avec les edge cases du type emoji, kanji et autres alphabets exotiques, etc… Je l'ajouterai sans regrets car j'ai pas envie de les gérer moi même.
Cette partie, c'est du troll rien de plus…
https://nodejs.org/docs/latest-v16.x/api/index.html
Des exemples à la place d'un avis subjectif sorti de nul part ?
Python, Erlang/Elixir, Lua, PHP, Perl, Ruby, … En quoi c'est un problème ?
Donc après avoir cité la norme EcmaScript, toutes les évolutions du language Javascript qui ont eu lieu et qui sont en cours, j'ai le malheur de mentionner Typescript une seule fois et c'est tout ce que tu retiens ?
C'est de la mauvaise foie pure et dure.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . En réponse au lien I will pay you cash to delete your npm module . Évalué à 2. Dernière modification le 27 novembre 2021 à 09:43.
Que ce soit du copier/coller, ou du require. C'est emmerdant car on doit le maintenir. Ce genre de code devrait faire partie de la stdlib.
Maintenant tu as quelqu'un qui a préféré fournir un ensemble de micro package, au lieu de fournir un immense package. Pourquoi ? Parce qu'il a estimé que les gens n'utiliserai pas un gros package sous prétexte que 95% de ce dernier ne leur sert pas.
C'est marrant parce que Rust mets carrément ça dans leur best practice et ça choque personne : https://rust-unofficial.github.io/patterns/patterns/structural/small-crates.html
C'est ton avis, un avis de chiotte certes, mais uniquement le tiens.
EDIT: J'adore comment tu ignores le reste de ma réponse :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: mine is better
Posté par David Delassus (site web personnel) . En réponse au lien Nothing better than C. Évalué à 3.
Désactive les optimisations du compilateur, et comme par magie ça redeviendra comme avant. Comme Linus le dit dans la vidéo, fut un temps les compilateurs devaient être simple. Ils sont maintenant très intelligent.
Bizarre venant de langage avec un runtime, un garbage collector, et tout plein d'autres features qui viennent modifier l'assembleur produit.
Si tu as regardé la vidéo, tu comprendre que le titre racoleur de ce lien n'est qu'une infime partie du message de Linus: I have yet to see a language that comes close to C in that respect.
En aucun cas il est dit que le C est le meilleur langage de tout les temps, tout usages confondus, toutes plateformes confondues, de manière purement objective.
Oui, pas grave non plus si tu parles en lisant que le titre.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hilarant
Posté par David Delassus (site web personnel) . En réponse au lien I will pay you cash to delete your npm module . Évalué à 3.
La faute à une stdlib trop pauvre. Je vois la même chose avec Rust mais comme ça compile statiquement au lieu d'avoir un node_modules de 10Go, ça choque personne.
Bah… pas forcément… En quoi le code qui copie/colle 3 lignes serait plus beau que le code qui fait un require?
Oof, on était pas encore Vendredi pour un troll pareil.
Cracher comme ça sur un langage c'est vraiment ne pas comprendre ce qu'il apporte ni le pourquoi du comment.
Alors rappelons un peu l'histoire, Javascript est une implémentation de la norme EcmaScript (QtScript en est une autre pas exemple). La version supporté à 100% par la totalité des plateforme c'est la version 5 de la norme.
Cette norme a beaucoup évolué. La version 6 date de 2015, depuis on a abandonné ce numérotage et on est passé sur des dates, nous sommes aujourd'hui à ES2020. C'est un langage beaucoup plus mature, qui règle nombre des problèmes qui étaient présent dans la version 5, tout en gardant une rétro-compatibilité phénoménale. Et oui ton code d'il y a 20 ans va toujours pouvoir s'exécuter sans aucun soucis aujourd'hui. Montre moi un autre langage comme ça (j'ai C++, Python et Java dans le viseur).
En plus, aujourd'hui il y a TypeScript, dont le système de type est tellement expressif qu'il est une machine de Turing permettant des implémentations assez drôles:
On voit de plus en plus de programmation fonctionnelle arriver en Javascript/Typescript, avec notamment:
Merci donc de se documenter un minimum avant d'aller cracher comme ça sur le travail d'autrui.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: mine is better
Posté par David Delassus (site web personnel) . En réponse au lien Nothing better than C. Évalué à 5.
Tiens donc, on a pas regardé la vidéo?
Ni D, ni C++, ni Go, ni Rust ne remplissent ces 3 critères en même temps.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1.
C'est le même problème avec tout les dépôts communautaires sans review.
Les teams DevSecOps me chuchotent à l'oreille que ces conseils s'appliquent à toutes les dépendances externes peu importe leurs provenance (dépôt officiel ou non).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1. Dernière modification le 25 novembre 2021 à 19:44.
Good to know :)
T'as de l'outillage pour t'aider à les générer, mais sur le principe oui, si l'empaqueteur ne les fournis pas, personne va les fournir pour toi.
Tu as par exemple des images Docker pour te fournir une alpine/debian/ubuntu avec un JDK dans une version spécifique. Pareil pour Python, Erlang/Elixir, etc…
Fun fact, j'ai une application Elixir qui embarque dans son image Docker un binaire Go, dans la phase de build j'ai ceci:
COPY --from=golang:1.16-alpine /usr/local/go/ /usr/local/go/
ENV PATH="/usr/local/go/bin:${PATH}"
Alors certes, j'imagine mal une image Docker "python-django" ou "node-expressjs" sur DockerHub. Cependant j'ai pas mal vu en entreprise des images Docker de base du style "java-jdk11-springboot" partagées entre les différentes teams.
Accessoirement, pour Windows si tu veux bosser avec la SDL, tu chope un ZIP qui te donne les headers et les DLLs.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1.
Oof, tu piques la où ça fait mal ! C'est pas très fair play :p
Pour PyPI, tu as les wheels qui sont des paquets précompilés. Tu en as pour la glibc et pour Windows.
Attention par contre : https://pythonspeed.com/articles/alpine-docker-python/
Et ouais, sur Alpine, pas de glibc, musl, pas de wheels donc, du coup tu dois tout build toi même. En 2021, build un paquet Python sur Alpine peut nécessiter :
Malgré ça, même avec les wheels, on est pas au point côté Python (je pense à l'intégration de GTK en Python qui aujourd'hui ne peux pas être faite avec un simple pip install, contrairement à PySide pour Qt).
Après, on a conda qui résoud pas mal de problème, mais on est sur quelque chose de similaire à Flatpak du coup (un système complètement parallèle à celui de la distro).
Pour des écosystèmes comme Rust, ou Go, la question ne se pose pas vraiment, puisque l'artefact final est un binaire statique.
Concernant NPM, à ma connaissance, il n'existe pas d'équivalent des wheels de Python, et c'est un problème car cela complexifie grandement l'installation de paquet. Je prend comme exemple une vielle version de sass-loader dont le build system dépendait de node-gyp (je te hais) qui avait besoin de python2 mais n'utilisait pas l'alias /usr/bin/python, et donc sur les systèmes ou tu as /usr/bin/python pour python2 et /usr/bin/python3 pour python3 (coucou Debian), tu devais faire le link toi même.
Erlang/Elixir te produisent une release sous forme de tar.gz contenant le runtime complet de l'appli, que tu peux extraire ou tu veux. J'aime cette méthode.
Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans
C:\Program Files/opt. C'est juste plus simple.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 2. Dernière modification le 25 novembre 2021 à 15:19.
Je me suis peut être mal exprimé.
La confiance que j'apporte à NPM/PyPI/etc… c'est sur son intégration avec le reste de l'écosystème du langage.
Je ne compte plus le nombre de fois ou j'ai eu des soucis avec un
apt install python-proutqui s'est terminé par un virtualenv dans /opt.La confiance dont tu parles concerne la sécurité, et oui un dépôt officiel d'une distribution ou chaque contribution est revue par un organisme tier a plus de crédibilité qu'un dépôt communautaire (coucou AUR et archlinux?).
Maintenant, si dans ta société tu as les moyens pour une équipe en charge de la cybersécurité, ces derniers vont te fournir :
Si tu veux être parano et ne pas faire confiance a un quidam, tu l'es jusqu'au bout et tu ne fais pas confiance à un organisme tier sur lequel tu n'as aucun contrôle. En fait tu va vraiment jusqu'au bout et tu fais pas confiance à quelque chose qui a été produit par un humain.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1.
Donnez nous de la déduplication au niveau du système de fichier et ça règlera le problème.
Si tu fais tourner beaucoup de conteneurs Docker, tu as déjà de la dédup non négligeable lors du téléchargement grâce à son système de layers.
En tant qu'entreprise, distribuer un conteneur Docker est infiniment plus simple et pour nous (éditeur) et pour le client (utilisateur). Je sais que ça marchera pareil que sur nos environnements de test, et le client sait qu'il pourra le déployer comme le reste de ses applications.
J'adore Docker, et si j'avais pu avoir ça il y a 10 ans, ça m'aurait évité beaucoup de travail répétitif
et pénible dans ma carrière.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1.
Le soucis des libs de 4 lignes c'est la pauvreté de la stdlib.
En Rust ça pose pas problème, c'est compilé statiquement. En Python la stdlib est colossale.
Ce que je voulais dire c'est que j'ai plus confiance dans :
$ yarn add moment
$ pip install trio
$ apt install moment-js
$ yum install python-trio
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 0.
Premièrement, j'ai plus confiance dans NPM/PyPI/Hex.pm/Crates.io pour empaqueter correctement une lib du-dit langage que Debian par exemple.
Deuxièmement, ça a pas l'air de déranger les utilisateurs de Archlinux et AUR d'installer des paquets avec des logiciels potentiellement setuid root venant d'un repository non contrôlé.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Faites des paquets Debian pour vos applications
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 3.
IMHO, c'est aux mainteneurs d'une distribution de créer les paquets pour cette dernière.
Qui d'autres qu'eux peuvent assurer la compatibilité de l'intégration avec le reste du système ?
Et surtout, si les développeurs devaient gérer eux mêmes la création des paquets pour toutes les distributions, ils n'auraient pas le temps de développer la-dite application…
cf Linux Distribution Timeline
Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?
DEB:
RPM:
Je peux t'assurer que les développeurs solo et bénévole vont te caller un Makefile et un README en te disant de te débrouiller avec des instructions "qui marchent sur leurs machines".
Oui Flatpak, Snap, et compagnie ne sont pas des solutions idéales d'un point de vue mainteneur de distribution (doublons de runtime, et toute la ribambelle d'argument que tu peux trouver à droite/à gauche sur le net).
Mais d'un point de vue développeur c'est un moyen de cibler tout le monde sans se poser de question.
Et d'un point de vue utilisateur c'est un moyen d'avoir des applications populaires sans devoir faire une pétition aux mainteneurs de la distribution qui sont occupés à avoir des débats stériles sur le vocabulaire autorisé.
Alors cet article m'a fait beaucoup rire d'ailleurs. A un moment il parle de Windows:
Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.
Les gens commencent-ils à se rendre compte que "trop de choix tue le choix ?" après avoir perdu une soirée à chercher quelque chose de correct sur Netflix ?
Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg