Je me sens tellement proche de ce qu'écrit le monsieur. C'est vrai que chaque langage à ses défauts et en général je ne remets pas en question le dernier langage à la mode autant que je le fais pour les frameworks !!! Car à cause d'eux, nous nous retrouvons avec ces IT qui ont oublié comment coder ne serait-ce qu'un Hello World!.

Par contre on sent que le monsieur a été CEO lorsqu'il écrit ce genre de saletés :

Est-ce que la solution est politique ? Il faut légiférer pour mieux gouverner le monde du logiciel. On le voit avec les dernières réponses législatives aux problèmes concrets : RGPD, notification des cookies… la source du problème n’est pas résolue. Peut-être parce que les politiques ne comprennent que très mal le monde du logiciel.

La dernière chose dont nous avons besoin c'est de personnalités politiques dans le logiciel.

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++).

Exécuter une application en tirant partie du multi-coeur en bash ! Pour toi @Animal !

Via Dooby

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

Je rejoins totalement ce commentaire :

FP engineers: the vegans of the software industry.

La FP c'est cool, mais elle a de nombreuses limitations et un bonne partie des dév FP sont des fanatiques avec un casque complètement pété.

=> Coucou les Scalaistes, dites vous pourriez pas utiliser un vrai langage fonctionnel comme Haskell au moins avant de venir la ramener ? #TrollInside

Je résume l'idée :

• Créer plein de petites instances immutables est plus coûteux que d'en réutiliser une mutable.
• Mais il ne peut pas avoir de graphes d'instanciations entre les anciennes et les nouvelles instances, avec une programmation totalement immutable (puisque les anciennes n'étant jamais modifiées, elles ne pointeront jamais vers les nouvelles).
• De ce fait les temps de garbage collection sont bien plus courts.

Donc nous perdons du temps de calcul pendant l'instanciation pour en récupérer une partie durant la garbage collection.

Pour allier le meilleur des deux mondes, il faut utiliser des objets immutables tout le temps, sauf dans un seul cas de figure qui répond aux contraintes suivantes :

• Je dois modifier beaucoup de fois le même objet immutable avant d'obtenir son état final.
• Je vais donc passer par un objet mutable pour le construire.
• Cet objet mutable doit être instancié et garbage collecté dans la même méthode.

Par exemple, utiliser un StringBuilder pour créer une String immutable en Java (et ne pas partager ce StringBuilder avec un tiers ou encore le mettre en attribut).

Des algorithmes à base d'arbres permettant de mettre en oeuvre des systèmes de prises de décisions via programmation par contraintes.

Merci @Chlouchloutte, tu es topissime !

Un post intéressant sur les annotations JetBrains pour exposer le contrat d'une méthode (cf. programmation par contrat, JML). Si ces annotations peuvent servir à du code Kotlin pour plus facilement recevoir des données provenant d'un code Java, alors je pense que cela peut être une excellente idée de les utiliser afin d'avoir un code Java qui soit Kotlin friendly.

Le lien vers la doc officielle.

Ce qu'illustre Timo ici est ne technique qui rentre dans la programmation dite par contraintes.

Principe

• Vous avez une tétra-chiée de données.
• Pour chacune de ces données, il existe des plusieurs contraintes à vérifier avant de procéder aux calculs.
• Les données à prendre en compte sont uniquement celles qui respectent 100% des contraintes.
• Les temps de calcul sur les données sont super longs.

Méthode :

• Vous exécutez en premier les contraintes qui éliminent le plus de données possibles.
• A chaque fois qu'une donnée est éliminée, vous ne perdez pas votre temps à exécuter la vérification des autres contraintes sur cette dernière, elle est éliminée point.
• Vous ne vous amusez à exécuter les calculs, uniquement sur une donnée qui a passé tous les filtres.

=> Ipso facto : vous n'aurez appliqué 100% des contraintes que sur une partie des données et effectué les calculs que sur les données qui vous intéresse. Votre CPU n'aura pas tourné sur des données inutiles ou vérifier des contraintes sur des données dont on sait déjà qu'elles ne sont pas à prendre en compte.

funKTionale - Functional constructs for Kotlin

Merci à Chlouchloutte pour cette trouvaille ! La vidéo est très claire pour comprendre comment le jouet fonctionne.

Un excellent post sur la théorie des catégories et la distinction entre Monade et Monoïde du point de vue des langages de programmation.

Pour Chlouchloutte

Définition

Le currying de fonction est la décomposition d'une fonction à n paramètres en n fonctions à 1 paramètre.

Prenons un exemple :

// A) Vous écrivez :
val result:Int = add(1, 2, 3)     // result = 6

// B) Vous souhaitez écrire :
val result:Int = add(1)(2)(3)     // result = 6

Passer de A à B, c'est la currification ou currying en anglais. L'opération inverse s'appelle la décurification.

Remarque :
Dans l'exemple (B), add(1) retourne une fonction qui une fois exécutée avec le paramètre 2 retourne une autre fonction qui prendra le paramètre 3.

Outch ! Je peux vous assurer qu'entre la programmation asynchrone, les générateurs, les itérateurs, les call-backs imbriqué et le mot-clef yield (qui à mon sens est un goto déguisé), cela va être de plus en plus compliqué d'appréhender JS pour le chaland.

Il faut vraiment s'y mettre maintenant, dans deux ans il sera trop tard.

Une vidéo trouvaille : demandez à vos enfants de vous écrire les instructions pour faire deux tartines pain / beurre de cacahuètes / confiture et exécutez ces instructions comme le ferait un ordinateur (c'est-à-dire sans pré-requis cognitifs).

Excellente idée pour apprendre à vos enfants le principe de l'algorithmie. Spéciale casse-dédie ma regrettée Noëlle qui m'apprit ce principe avec un robot devant déposer une balle dans un panier.

Comme quoi, certains enseignants vous marqueront pour votre vie.

Woaaa. Anne ce post est pour toi !

Une liste de technos à connaître au 21-ième siècle quand on est dév. Reparties par langages.

Comme pour certains termes financiers, je posterai quelques définitions sur les lambdas.

Prédicat :
=> Fonction qui retourne un booléen.
Les prédicats sont très utilisés dans les filtres, par exemple vous souhaitez parcourir une collection et ne retourner dans une liste que les personnes étant majeures, alors vous créerez une lambda prenant en paramètre une personne et qui retournera true si celle-ci est majeure ou false sinon.

Exemple :

• Prédicat sans paramètres :

  ( ) -> true

• Prédicat sans paramètres mais où l'on spécifie explicitement le return (qui est facultatif en PF) :

  ( ) -> { return true; }

• Prédicat avec un paramètre et le return :

  (person) -> { return person.isMale(); }

• Prédicat avec deux paramètres :

  (persA, persB) -> { Object.equals(persA, persB); }

• Prédicat avec deux paramètres, le return et dont on spécifie le type des paramètres :

  (Person persA, Person persB) -> { return Object.equals(persA, persB); }