Antichesse (o ^ω^ o)
Dash est un super environnement d'exécution pour le sous-ensemble POSIX de Bash. Il est portable, hyper rapide, consomme moins de 1 Mo de RAM. Bref un très bon outil.
Par contre, la syntaxe de Bash / Dash est error-prone au possible. D'autant qu'en dehors des outils classiques d'unix (grep, sed, awk, wget/curl) il y a peu de lib qui soient utilisables.
Bref, pour faire de petites choses comme lancer sa JRE ou filtrer des fichiers why not, mais en dehors de ça, ça me fait toujours hésiter.
Et ce matin je découvre que Kotlin peut être utilisé en tant que langage de scripts. Il suffit d'avoir installé dans notre PATH l'utilitaire kscript disponible ici et nous pouvons commencer à écrire ce genre de choses :
#!/usr/bin/env kscript
println("Hello, World!")Ensuite un petits chmod u+x sur notre fichier qui pourra se lancer en tapant :
./mon-script.ktsEt c'est super bien ça !
Titre PutaclickSur20.
Il s'agit en réalité d'une n-ème faille de sécurité de Windows, ici via l'utilitaire cmd.exe qui lance une invite de commande, et qui affecte tous les langages de programmation parce que (contrairement à Linux), je cite :
L'API Windows ne fournit qu'une seule chaîne de caractères contenant tous les arguments, laissant au processus créé la responsabilité de les diviser. La plupart des programmes utilisent la chaîne d'exécution standard argv en C, ce qui permet d'obtenir un comportement cohérent en matière de division des arguments. Cependant, cmd.exe possède sa propre logique de découpage des arguments, qui nécessite un échappement personnalisé par la bibliothèque standard Rust [et des autres langages].
Mais comme les communautés qui développent langages libres et interopérables sont de vrais professionnels eux, les langages compensent à la place de Microchiotte ce que Microchiotte aurait dû codé correctement dans Windows...
Bref, Rust est déjà patché. Si vous ne voulez pas être affectés par cette faille de sécurité, travaillez sur un OS digne de ce nom et quittez les boites qui vous forcent à bosser sur OSX ou Windows.
Je travaille en ce moment sur deux projets, un en Java/Kotlin pour des clients, un second en Rust pour des besoins internes, et j'ai réalisé la chose suivante :
- En Java/Kotlin, le langage est fait pour vous aider mais vous allez vous battre contre les frameworks.
- En Rust, les frameworks sont faits pour vous aider mais vous allez vous battre contre le langage.
C'est incroyable à quel point le borrow checker vous pousse à écrire du code procédurale et mécaniquement intestable. Dès l'instant où l'on souhaite passer par des traits tout devient ultra compliqué. Dernièrement je me suis faite avoir en utilisant des Rc et des RcCell sur un code qui allait devenir multi-thread #Horreur
Pour moi, casser le couplage entre deux composants via une interface/trait est IN-DIS-PEN-SABLE mais Rust pousse à définir des structures comme contrat d'interfaçage principal entre deux pans de code.
Forcément, le langage se transforme en enfer dès l'instant où l'on souhaite dépendre d'un trait et non d'une structure (c'est pourtant le 'I' de SOLID, dépendre des Interfaces mais pas des Implémentations).
En même temps je l'avais déjà dit par le passé, le paradigme fonctionnel pur est un cancer métastasé car l'expressivité de la syntaxe donne le sentiment que des tests ne sont pas nécessaires or c'est toujours faux.
Et j'ai suffisamment souffert de Java dans ma vie pour haïr le fait de devoir mocker/instancier/déclarer quarante-douze-mille trucs avant de pouvoir tester une simple fonction.
Bref, deux ans sur Rust à temps partiel et je me vois retourner dans le RustBook tous les 4 mois pour y chercher un truc #Pénible alors qu'en Kotlin ça ne m'arrive jamais.
Différences entre les enums Option et Result en Rust.
Il n'y a pas à dire, à chaque fois que je code et où le langage m'oblige à utiliser des Optional, je me dis que c'est un langage pourri. Et ceci inclus Rust malgré tout le bien que je pense de lui 😤 !
La meilleure façon de gérer les cas de nullité se trouve dans Kotlin 🥰, TypeScript et Groovy. Le type Optional est une technique archaïque et verbeuse quand on vient du null-check de Kotlin.
Mais bon j'ai déjà expliqué par le passé en quoi le paradigme fonctionnel pure était un cancer métastasé 🤮. Et entre C++ et Rust pour de la programmation système il n'y a plus vraiment de discussion à cette heure, donc faisons-nous violence avec les Optional.
Mon rêve serait un langage natif reprenant la syntaxe de Kotlin (sauf tout ce qui touche aux getter/setter) avec le borrow checker de Rust et qui produise des binaires natifs. Je pense que je peux rêver encore longtemps 🥲
L'évolution de la demande de développeurs Kotlin est en plein boom en France 😁 :
Rust ne suit pas encore mais c'est un résultat attendu puisque l'emploi est pour l'instant situé en Chine, en Corée et aux USA et l'étude se focalise sur la France. Au fil des mois, il devrait phagocyter tout doucement ses parts à C et surtout C++ 🤩 :
La bonne surprise c'est de voir que Kotlin se positionne très bien sur la grille des salaires bruts 🤑 :
Pour l'instant j'ai eu le nez creux avec Kotlin, il faut dire que le compilateur fait des choses époustouflantes, notament la preuve d'absence de de référencement de pointeurs (NullPointer) lors de la compilation, et que son API est merveilleuse comparée à Java (même si elle s'appuie dessus).
Il en va de même pour Rust, qui apporte tellement de choses qui manquent à C et C++, notamment la preuve d'absence de fuites memoire et de race-conditions dès la compilation ou encore un gestionnaire de paquets digne de ce nom.
Bref, attendons encore un peu avant de crier victoire mais pour l'instant, tout se profile comme il le faut pour moi et cela valait bien de s'investir autant 🥳.
Je cite :
« À mesure qu'Android passe de C/C++ à Java/Kotlin/Rust, nous nous attendons à ce que le nombre de vulnérabilités liées à la sécurité de la mémoire continue de diminuer. Vivement un avenir où les bogues de corruption de la mémoire sur Android seront rares », a conclu Google.
Rust et Kotlin sont deux superbes langages (avec une petite préférence pour Kotlin). J'ai pourtant quelques reproches à faire à l'un et à l'autre mais quand je vois que le marché avance vers eux à grands pas, autant vous dire que j'en suis toute chose <3
Que du beau sous le soleil.
Kotiln, Rust et Python progressent et de plus en plus de développeurs les adoptent (et c'est très bien).
J'ai été une grande utilisatrice de Python il y a un peu plus d'une quinzaine d'années lorsque je travaillais en labo sur du Data-Mining (l'ancêtre du Machine Learning). J'avais laissé de côté Python pour trois raisons à l'époque :
- Les problèmes de performance.
- Les problèmes d'outillage autour du build.
- Le fait que les programmes écrits en Python, pour être rapides, doivent utiliser des libs écrites en C, et donc avec un code orienté procédure.
Aujourd'hui, si je devais produire un système temps-réel et très peu énergivore, je partirais sur Rust.
Dans tous les autres cas de figure, je prendrais Kotlin sur OpenJDK ou Kotlin native (via le compilateur Kotlin-native ou GraalVM).
Par contre Python n'est plus du tout dans ma liste car pour moi à présent, si l'exécution d'un langage n'est pas prouvée à la compilation, c'est un stop immédiat. La majorité des développeurs n'écrivant pas de tests et maîtrisant mal le code (en tout cas en industrie) c'est indispensable.
Je cite :
Si l'orthographe française est compliquée, c'est historiquement volontaire. En 1694, dans les cahiers préparatoires du tout premier dictionnaire de l’Académie française, il était écrit : « L’orthographe servira à distinguer les gens de lettres des ignorants et des simples femmes ».
L’orthographe a longtemps été décidée par et pour les lettrés, qui connaissaient le latin et souvent le grec. Ses conventions complexes ont rarement été simplifiées, et le français écrit, avec ses lettres et marqueurs muets, demeure une langue difficile à s’approprier.
Au regard de ce qui est écrit, la remarque de @Sebsauvage me semble hors sujet :
Leçon: Le langage est un outils de domination.
Alors du coup non, je ne pense pas qu'on puisse dire que le langage soit "un outil de domination". Mon point est de dire que le langage est un marqueur socio-culturel et que les populations s'identifiant à l'aide de ces marqueurs s'incluent ou se rejettent.
Qui a envie d'être assimilé à une population qu'il réprouve ? (genre ultra-catho/grenouille de bénitier pour @Sebsauvage)
Je reformule, @Sebsauvage, tu es (en tout cas de mon point de vue) quelqu'un de très éduqué, d'intelligent et de logique. Quels sont tes codes vestimentaires ? Le jeans/polo ? Le Jogging/basket ? Le jean/chemise ? Le costard ?
J'ai le sentiment, en te lisant, que le combo jogging/basket/pantalon retroussé/chaussette au-dessus du pantalon/chaîne en or n'est pas vraiment ton style, me trompé-je ? Aller un petit exemple pour voir si tu te retrouves dans ce style :
Et si non pourquoi ne t'habillerais-tu pas ainsi dans ta vie de tous les jours ? J'ai une petite idée, parce qu'il s'agit d'un marque socio-culturel fort traduisant de manière implicite ton style de vie et surtout ton rapport à la société.
Un langage châtié ou un langage de "d'jeunes" a le même effet qu'une paire de baskets, il en dit long sur vous et votre rapport à la société et donc vous permet d'identifier les personnes qui risquent de vous apporter bon nombre de problèmes rien qu'en les côtoyant.
Mais après, certains préfèrent tout voir au travers du prisme oppresseurs/oppressés alors que je fais partie de ceux qui perçoivent nos rapports comme des bonus/malus au-dessus desquels s'ajoutent des divergences et parfois des convergences d'intérêts (qui peuvent compenser ces bonus-malus d'ailleurs).
My two cents <= Tiens un autre marqueur social lié au langage : l'anglais Signe du bourgeois informaticien éduqué, on en parle de celui-là qui nous touche quasi tous sur les rivers ?
Une IA est par définition conservatrice. Et cet exemple est ... triste.
Très bien dit ! Une IA n'est ni raciste, ni sexiste elle ne fait que reproduire les millions de constats qu'elle a précédemment fait. Ici elle s'appuie visiblement sur de la statistique pour donner la traduction la plus probable.
Par contre cet exemple n'est ni "triste" ni "heureux" (ça c'est de la morale), c'est juste un témoin qui synthétise les données utilisées pour enrichir l'IA.
Une compilation des bases de Rust.
Via Sebsauvage.
J'avoue qu'en terme d’obfuscation du code ça se pose là !
Pour @Going
Spoiler de l'article : Kotlin gagne quasiment partout.
Par contre Kotlin n'est pas que pour Android mais aussi pour tout ce qui cible la JVM ou la compilation du byte-code de JVM en natif. Chez nous il est côté serveur depuis plus de deux ans maintenant et a TOTALEMENT REMPLACÉ JAVA !
Dans la liste, je cite :
Perl, Haskell, Ruby, Objective-C et finalement R
J'ajouterai Java d'ici à 20 ans et Scala d'ici à 15, les deux remplacés par Kotlin en grande partie et Clojure/Elixir dans une autre mesure ; et enfin PHP d'ici à 15 ans remplacé par Python et TypeScript. Voici un graphique tiré de l'article :
Question... À quand JavaScript ?
Le vocabulaire indispensable pour comprendre les StackOverflow récentes. Aujourd'hui j'ai appris ce qu'est le Bicrement => +2 (à la place du +1 issu du i++).
Ceux qui me lisent le savent, je trouve que Rust est un très bon langage mais je lui reproche quand même certaines choses :
- Il n'est pas trivial d'écrire des classes (comme il l'est en Kotlin).
- Le code à écrire est aussi volumineux que celui de Java (Kotlin est 30% à 40% plus concis).
- Il utilise autant d'abréviations stupides que C++.
- Certains éléments de syntaxe sont une immondice à mi chemin entre C++ et O-Caml/Ruby (typiquement le pipe "|" pour les lambas, en dix ans je n'ai jamais pu m'y faire, ou encore l'opérateur "->" pour définir un type de retour d'une fonction).
Mon langage préféré serait à 100% Kotlin si celui-ci disposait :
- D'une cross-compilation native.
- D'un garbage collector injecté au compile-time à l'image de Rust et l'emploi du Ownership.
Oui, c'est ce qu'il faudrait à Kotlin, j'ai vraiment hâte de voir ce que vont donner GraalVM et Kotlin native dans les prochains mois.
Via Riduidel
Une appli écrite en 4 fois en :
- Java
- Groovy
- Kotlin
- Scala
La comparaison du readme est très appréciée.
Un humain de sexe masculin peut fort bien être une recrue, une vedette, une canaille, une fripouille ou une andouille. De sexe féminin, il lui arrive d'être un mannequin, un tyran ou un génie. Le respect de la personne humaine est-il réservé aux femmes, et celui des droits de l'homme aux hommes ? Absurde ! Ces féminins et masculins sont purement grammaticaux, nullement sexuels.
J'abonde : la remarque est pertinente.
L'écriture inclusive et tous ces effets cosmétiques autour du langage font croire que les choses changent ; pourtant la stratégie est simple, modifions la surface d'un problème mais surtout laissons-le intact en profondeur, les faibles auront l'illusion d'avoir remporté bataille tandis que les forts préserverons leurs privilèges.
Le racisme a-t-il disparu depuis que les mots nègres, bougnoules, youpin, niakwé & co ont disparu du langage (j'entends par là, des journaux, de la télévision, des radios, des magazines, des affiches, de la publicité, des jouets, etc) ? Non, certains partis politiques (dois-je préciser français) fondent même leur programme dessus ! Mais sur quoi me direz-vous ? Sur l'idée, ce concept, cette croyance exprimant que la couleur de peau, l'origine, l'orientation sexuelle, la maladie ou encore la religion déterminent la valeur des hommes et leur importance dans la société ; en ce sens qu'ils ont eu la bonne idée d'être bien nés.
Le véritable combat ne serait-il pas l'explication et la diffusion d'autres valeurs "morales" ? Le véritable combat ne serait-il pas d'admettre que nous vivons dans un système de prédation totale et que celui-ci écrase, méprise, domine et achève quiconque s'opposerait à lui ; ceci par tous les moyens possibles, en permanence, pour que d'autres - l'extrême petit nombre - préserve l'ensemble de ses avantages ?
Notre société civile ne facilite pas l'oppression, elle est l'oppression ; le langage n'est pas l'oppresseur, les individus qui oppressent sont les oppresseurs. Un couteau ne tue pas, c'est l'homme qui tue en se servant d'un couteau, le langage n'exclut pas, ce sont les individus qui excluent en se servant du langage. Voyez-vous la différence ?
Prôner l'égalité black/blanc/beurre sur des termes moraux est la chose la plus clivante qui soit ; et ne pas se soucier des injustices en termes de richesse, de partage, de solidarité et de respect, je trouve cela abscons et stupide car elles sont à l'origine du premier problème.
Ne me faites pas dire ce que je n'ai pas dit, je sais que les LGBTx souffrent mais il faut s'atteler à corriger la cause des causes et non le reste. Pour info (et ce sujet étant tellement brûlant) je me dois de préciser que je n'ai pas écrit LGBTx pour me moquer des "x", il faut savoir qu'il existe les LGBTI, LGBTA, LGBTQ ou encore LGBTP. Nous devrions donc écrire quelque chose comme LGBTAIQPT afin "d'inclure" vraiment tout le monde parce que l'idée est là, il faudrait en permanence inclure chacun individu dans sa différence à chaque instant de chaque discours... Seriously...
En fait, l'écriture inclusive me fait penser au langage Scala. L'idée semblait bonne au début : incorporons tous les paradigmes dans le même langage afin que chacun puisse l'utiliser à sa guise. Puis, faisons de chacun des cas particuliers, de chacune des exceptions de chaque paradigmes, une règle générale à appliquer systématiquement, tout le temps et pour tout le monde quelque soit le contexte.
Que se passe-t-il ? Cela revient à penser à protéger son code de problèmes comme la variance, co-variance et contra-variance qui ne posent réellement problème que lorsque le code amoncelle une quantité faramineuse de très mauvaises pratiques. Bref, le cas hyper particulier à gérer exceptionnellement devient chose commune.
Et que se passe-t-il à la fin ? À l'intérieur de Scala il y a les scalaïstes objets, les scalaïstes fonctionnels, les scalaïstes évènementiels, les scalaïstes procéduraux, etc. Et plutôt que de rassembler, la communauté a morcelé Scala pour refléter sa propre nature : les uns ne sont pas les autres.
La solution réside dans l'apprentissage de l'acceptation de l'autre, par dans l'interdiction de s'exprimer avec des mots et au travers de la grammaire.
Pour faire le lien entre une grammaire du type :
S -> aA
A -> bA | ^Il faut comprendre que les terminaux (ici 'a' et 'b') représentent les transitions alors que les non-terminaux ('ici 'S' et 'A') représentent les états de l'automate de parsing.
Je vous renvoie à la page 28 > Preuve du théorème 6 > petit (2) > Exemple.
Je suis en train de me remettre au parser / lexer. Cette article (enfin ce cours en PDF) reprendre à partir de la page 47 les techniques de réductions d'automate à état fini qui peuvent parser des grammaires hors contexte.
Je le bookmark pour mémoire.
Pour Chlouchloutte, toi qui te demandait quelles technos apprendre. Visiblement, c'est TypeScript, Go et Java le triplet gagnant.
- Java pour la sécurité (être sûr d'avoir une mission)
- TypeScript pour la thune
- Go pour le fun