Antichesse (o ^ω^ o)
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 = 6Passer 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); }
Je poursuis ma migration vers le fonctionnel sur Java 8 avec un petit tuto sur les stream et les map-reduce. Le tout est guidé par une multitude de petits exemples simples.
Je découvre le blog de Jean-Christophe Gay. Très sympa et assez complet sur Java 8.
Attention : si vous ne vous êtes toujours pas mis aux lambdas, aux Clojures et aux Predicats, vous allez avoir du mal à vous revendre dans l'univers Java. Début 2016, cela deviendra indispensable !
P.S : vous savez que je déteste la programmation fonctionnelle car l'inférence de type permet de produire bien trop souvent un code immaintenable, cependant, utilisée avec BEAUCOUP de parcimonie, elle permet de factoriser énormément de code technique et éviter les doublons. Bref, je m'y suis mise, ce n'est pas pour rien.
Vu que je suis obligée de faire de la programmation fonctionnelle (avec inférence de type, ce que je déteste au plus haut point), je vais poster une série de tutos à ce sujet.