Edit comme j'avais des doutes sur le benchmark lancé depuis Intellij, j'ai recodé un comparatif complet qui aura tourné 4 heures sur ma machine

Avec Kotlin, sous Java 21, en utilisant JMH, j'obtiens des résultats en total contradiction avec ceux obtenus via IntelliJ. L'écart passe de 12% à 2,2% dans le pire des cas.

Pour mon benchmark, j'ai calculé la longueur d'une String avec la fonction suivante : 2 * str.length + 1. Le but étant d'illustrer quel type d'appel est le plus rapide pour effectuer ce calcul.

Voici mes tableaux de comparatifs :

Conclusion après benchmark

Créer des instances à la Yegor Bugayenko semble être globalemment l'une si ce n'est la meilleure des solutions lorsque l'on observe son positionnement qui est au pire moyen sinon deux fois premier.

J'ai passé le nouvel an avec @Kysofer & @Chlouloutte. Quand tous les enfants ont le même âge c'est vraiment sympa ; surtout quand ils se couchent tous en même temps :P

Mais passons, ce matin après ce qui sera déjà l'une des plus courtes nuit de cette nouvelle année, je discute avec @Kysofer de ces projets pour 2024, il me sort un truc improbable :

Je pense que je vais abandonner la programmation orientée objet pour la programmation fonctionnelle...

Là, je le regarde limite choquée... Il faut dire que lui et moi partageons - je devrais dire partagions - le même avis sur la programmation fonctionnelle, notamment depuis nos déboires en OCaml (merci le programme de MPSI).

Donc, avec le plus grand respect je lui réponds :

Nani the fuck !?

À ma décharge je n'ai pas bu un seul verre d'alcool depuis la grossesse de ma petite dernière. Et oui. :P

Là il m'explique tout un tas de trucs et je dois dire que je me sens déstabilisée. Je m'explique, j'ai vécu trop de fois le fait de devoir maintenir du Scala pour savoir à quel point, sur le temps long, la programmation fonctionnelle pure devient encore moins maintenable que du Java + Spring Boot.

D'autant que je m'attendais à ce qu'il m'annonce qu'il allait (enfin) se monter un Shaarli.

Bref son idée est dirigée par les contraintes suivantes :

• Avoir un code dirigé par des contrats (au sens interfaces Java) dont le respect du typage est prouvé lors de la compilation et garanti lors de l'exécution.
• Ne pas avoir besoin de créer des instances techniques qui implémentent ces contrats, afin d'encapsuler des données dedans.
• Parvenir quand même à encapsuler les données pour les protéger mais sans jamais créer de nouvelles instances (cf. le point précédent).
• Avoir les mêmes performance d'exécution que du chaînage d'appels de fonctions static ; et donc l'eldorado du zero GC-time.
• Permettre une exécution différée/lazy/paresseuse.

Quand on lit le truc, on se dit que la vie n'est plus à un paradoxe prêt, mais pourtant sa façon de faire fonctionne.

Je vais essayer de vous décrire ce qu'il m'a expliqué afin de mieux l'ingérer moi-même.

Exemple : Déterminer si deux trucs sont égaux

Dans tous les cas de figure, nous allons supposer que les données sont décorées par une implémentation de l'interface suivante qui permet de les représenter sous la forme d'un tableau d'octets.

interface RawData {

    fun asBytes():ByteArray

}

Version OOP Pure

1) On exprime le concept de vérification via une interface :

interface Check {

    fun status():Boolean

}

Ensuite on fournit une implémentation de l'interface Check qui soit spécialisée dans la comparaison de deux RawData :

class IsEqual(
    private val left:RawData,
    private val right:RawData
):Check {

    override fun status():Boolean {
        return this.isSameInstances() || this.haveSameBytes()
    }

    private fun haveSameBytes():Boolean {
        return left.asBytes().contentEquals(right.asBytes())
    }

    private fun isSameInstances():Boolean {
        return left === right
    }

}

Et ça s'utilise comme ceci :

val left:RawData = StrAsData("same data")
val right:RawData = StrAsData("same data")

val comparison:Boolean = IsEqual(left, right).status()

Problème
Pour comparer deux objets on doit forcément créer une instance de IsEqual puis invoquer une méthode dessus. Sur JRE, c'est ~12% de temps de calcul supplémentaire par rapport à un simple appel de méthode statiques !

Version PF pure

Avant toute chose, il faut comprendre ce qu'est un contrat pour @Kysofer. C'est un truc qui va prouver à la compilation que les types d'entrée et de sortie soient bien respectés, ce qui fait que l'implémentation A pourra se substituer à l'implémentation B sans problème lors du runtime.

Mais comment peut-on produire l'équivalent d'une interface en PF ?

=> On passe par des fonctions de premier ordre.

En effet, une méthode qui reçoit une fonction de premier ordre ne sait pas ce qu'elle va exécuter. Elle sait juste que la fonction prendra un certain type en entrée et un certain type en retour. Le reste, c'est le compilateur qui agit.

Si l'on reprend l'interface Check cela nous donne le prototype suivant :

val prototype:() -> Boolean

C'est-à-dire un Predicat sans paramètre.

Maintenant passons à l'implémentation naïve, ceci nous donne :

fun isEqual(left:RawData, right:RawData):() -> Boolean {
    return {
        isSameInstances(left, right) || haveSameBytes(left, right)
    }
}

private inline fun haveSameBytes(left:RawData, right:RawData):Boolean {
    return left.asBytes().contentEquals(right.asBytes())
}

private inline fun isSameInstances(left:RawData, right:RawData):Boolean {
    return left === right
}

On voit bien que la fonction isEqual(..) retourne une fonction de premier ordre qui elle-même retournera un Boolean.

Rappel
En Kotlin, les lambda sont déclarées entre deux accolades { .. }.

Sauf que cet exemple a un problème puisqu'une lambda, sur JRE tout du moins, c'est une instance de l'interface Function ou l'un de ses équivalents. Bref, il n'y a pas de gain en terme de performance par rapport la version OOP.

Pour l'obtenir, il suffit de remplacer la création d'une lambda par un pointeur sur une fonction anonyme, ce qui nous donne :

fun isEqual(left:RawData, right:RawData) = fun():Boolean {
    return isSameInstances(left, right) || haveSameBytes(left, right)
}

Et la ça devient magique car la fonction anonyme étant écrite directement dans le byte-code et épinglée une et une seule fois en mémoire, cela revient à avoir un pointeur sur fonction qui exécutera la-dite fonction.

=> Soit un gain de 12% en termes de performance, ce qui fait qu'on rattrape la vitesse d'exécution d'un chaînage de méthodes statiques.

Mieux que cela, @Kysofer s'appuie sur une variante de la Curryfication . En effet, la méthode isEqual(..) sert à encapsuler les données dans la pile d'appel pour les rendre utilisables que par la fonction anonyme. Donc il devient impossible de savoir ce qui sera utilisé par la lambda qui sera retournée.

=> Les paramètres left et right sont bien encapsulés dans la lambda !

Si on résume

• Le fait que la fonction isEqual(..) retourne une lambda et non un résultat fait que l'on va déclarer un contrat et donc rendre les lambda interchangeables.
• Le fait que l'on retourne une fonction et non un résultat permet un calcul différé/paresseux potentiellement dans un autre thread.
• Le fait que l'on passe par une fonction anonyme qui utilisera les paramètres de la fonction déclarée fait qu'on encapsulera bien les données avant d'exécuter quoi que ce soit dessus.
• Le fait que tout soit fonction garanti l'absence de création d'instances techniques.

Nous avons donc bien là une version fonctionnelle de l'encapsulation et des contrats de l'OOP.

Ça aura pris 15 ans mais je pense être réconciliée totalement avec la PF (O_O) ; sauf le récursif, ça jamais ! En tout cas pas avant une démonstration comme celle-ci :P

En un code d'exemple :

// use macro_rules! <name of macro>{<Body>}
macro_rules! add {
    // macth like arm for macro
    ($a:expr,$b:expr) => {
        // macro expand to this code
        {
            // $a and $b will be templated using the value/variable provided to macro
            $a+$b
        }
    }
}

// Usage in code
fn main(){
    // call to macro, $a=1 and $b=2
    add!(1,2);
}

Attention à ne pas abuser de la méta-programmation car cela peut augmenter significativement les temps de compilation.

Article vraiment très bien proposé ici par @Sebsauvage.

On se rapproche très fortement de ce que propose David West dans Object Thinking (livre qui a 20 ans déjà) et Yegor Bugayenko dans Elegant Objects (livre qui doit fêter ses 8/9 ans). Je me permets de compléter la solution de la pratique n° 3.

L'auteur propose d'encapsuler la hauteur dans une entité, ce qui nous donne :

// Primitive contenue dans un objet (aussi appelé Value Object)
class ArticleHeight {
      private value: number;

      constructor(value: number) {
            if (value < 10) {
                 throw new HeightCanNotBeLessThanTen();
            }
            if (value > 100) {
                 throw new HeightCanNotBeGreaterThan100();
            }
            this.value = value;
       }
}

// passage de notre ArticleHeight dans le constructor
class Article {
     private height: ArticleHeight;

     constructor(height: ArticleHeight) {
          this.height = height;
     }
}

// eh voilou !
class AddArticleUsecase {
     execute({ height }) {
          //...
          const article = new Article(new ArticleHeight(height));
          //...
     }
}

Pas moi. Je propose que la classe Article s'attende à recevoir en paramètre une interface Height dont l'une des implémentations possible soit une ArticleHeight mais qui pourrait très bien être une valeur venant d'une BDD au moyen d'une HeightFromBdd (pas le meilleur nom, mais c'est pour représenter l'idée).

Ceci casse le couplage entre deux classes concrètes et subséquemment facilite les mocks/stubs durant les tests dont l'auteur ne parle pas.

Ce qui nous donne

// Primitive contenue dans un objet (aussi appelé Value Object)
interface Height {
       value(): number
}

class ArticleHeight implements Height {
      private value: number;

      constructor(value: number) {
            if (value < 10) {
                 throw new TooShortLength("Un article doit faire au minium 10 lignes");
            }
            if (value > 100) {
                 throw new TooLongLength("Un article ne peut faire plus de 100 lignes");
            }
            this.value = value;
       }

      value(): number {
            return this.value;
      }
}

class Article {
     private height: Height;

     constructor(height: Height) {
          this.height = height;
     }
}

class AddArticleUsecase {
     execute({ height }) {
          //...
          const article = new Article(new ArticleHeight(height));
          //...
     }
}

Et sur le même modèle, si votre classe expose une méthode publique, c'est qu'elle est imposée par une interface, dans tous les autres cas de figure les méthodes qui ne viennent pas d'interfaces doivent être privées.

Ce serait la 10ème règle que j'ajouterais à l'article.

Les observateurs auront aussi remarqué que j'ai changé les exceptions. Il ne vaut pas confondre nom de l'exception et contexte dans lequel une erreur été levée. D'où l'importance d'un message qui exprime la raison d'une erreur et le nom de l'exception qui exprime le type d'erreur remontée.

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 me souviens que je disais en 2010 à @Roger quelque chose du type :

La programmation fonctionnelle est un cancer.

Heureusement, dix ans plus tard j'ai quand même un peu changé d'avis sur la question, je dirais aujourd'hui :

La programmation fonctionnelle "pure" est un cancer.

La différence étant que je suis en mesure d'argumenter le ressenti inconscient que j'avais à l'époque. Depuis le bouquin sur les design-patterns du Gang of Four, nous avons eu une pléthore d'autres auteurs qui nous ont expliqué pourquoi il faut toujours dépendre des interfaces et jamais des implémentations. Le problème avec ça, c'est qu'une grande partie des développeurs ne comprennent pas bien ce que sont les implémentations et surtout pourquoi il ne faut pas dépendre d'elles.

En réalité, une implémentation embarque avec elle des attributs (et si un objet n'a pas d'attribut c'est que le développeur a codé en procédurale "pure", il n'a rien encapsulé, ça n'est pas objet du tout mais je m'égare). Le problème avec les implémentations ce sont justement les attributs qui deviennent visibles. Dit autrement nous commençons à devenir dépendant de la structure de données qui nous arrive et non plus d'un ensemble de fonctions (ie. méthodes) que nous pouvons exécuter. D'ailleurs nous sommes tellement dépendant des attributs que même s'ils sont privés, nous allons alors ajouter des getters/setters pour y accéder quand même.

Remonter à l'interface c'est casser ce lien explicite avec la structure de données embarquée dans une classe et alors un changement de structure ou de structure de la structure n'impactera pas le code utilisateur.

Mais alors quel est le problème avec la programmation fonctionnelle "pure" ?
C'est justement qu'elle pousse tous les morceaux de code à dépendre des mêmes structures. Changez la structure à un endroit et vous êtes partis pour changer toutes les fonctions qui s'appuient sur cette structure. Cela engendre fondamentalement un maillage global de tous les pans de code d'une application avec un couplage fort autour de cette ou de ces structures.

La seule condition pour y remédier c'est d'avoir "la bonne structure du premier coup"... lol quoi... Comment prévoir quelles données (et de quels types) nous arriveront demain ?

À l'inverse, retourner des implémentations d'interface autoboxé dans le type de cette interface (c-à-d. les fameux "messages" de la POO) garanti non seulement que les changements de structures n'auront pas d'impact, mais que les changements d'algorithmes non plus (ici "pas d'impact" est à prendre au sens où le contrat d'interfaçage n'est pas rompu et donc que le code continu de compiler).

Pourquoi est-ce que je vous parle de tout ça ?
À cause Rust et de mes quatre semaines d'immersion intense.

Soyons clair, je trouve que les concepts derrière le langage sont incroyables et ses performances merveilleuses (en tant que dev Java j'ai toujours détesté la JVM rien que pour ce sujet). Par contre le fait que Rust se soit tourné exclusivement vers le fonctionnel et la programmation en "structure-first" à la place de celle en "contract-first" car la majorité des devs ne parviennent pas à penser en objets avec l'encapsulation, cela fait de Rust un langage aussi immaintenable que C mais un peu plus fiable grâce à son meilleur compilateur.

L'API de Rust est digne de celle du C. Par exemple, prenons la méthodes HashMap::keys()de la stdlib de Rust. Celle-ci aurait pu retourner l'implémentation d'un trait Iterator mais non, elle retourne une structure Key qui contient une structureIter qui contient une autre structure base::Iter.

Changez un morceau de la chaîne et préparez-vous à gérer les impacts partout.

En résumé, et après être passée dans l'ordre par Java, OCaml, PHP, C, ASM, Bash, CSH, Python, JavaScript (ES5 à ES7), Anubis, Haskell, Ruby, Groovy, TypeScript, Scala, Go, Kotlin et enfin Rust (ndr. je bidouillais en Rust depuis quelques années), je peux vous assurer que :

1. Rust est techniquement un super langage avec l'un des meilleurs compilateur du marché.
2. Rust a une API aussi pourrie que celle de C, encourageant le couplage et augmentant l'immaintenabilité. Je crois qu'il doit exister un moyen d'outre-passer cela, mais je ne sais pas encore comment faire et ça me fruste pas mal.

Enfin, je sais que certains dev vont être fâchés de lire ce que j'écris alors permettez-moi de vous proposer un test car j'ai le sentiment que si c'est le cas, c'est que vous n'avez jamais pensé en OOP - et donc que vous ne pouvez pas encore comprendre ce que je dis. Il s'agit d'un exercice que @Kysofer a imaginé pour ses entretiens d'embauche afin de savoir si un candidat "expert Java" savait penser et programmer en orienté objet.

Prenez ces deux classes :

class Person {
    private final String name;
    private final String firstName;
    private final int age;

    public Person(String name, String firstName, int age) {
        this.name = name;
        this.firstName = firstName;
        this.age = age;
    }
}

class Car {
    private final String brand;
    private final String name;

    public Car(String brand, String name) {
        this.brand = brand;
        this.name = name;
    }
}

Objectifs :

• Sans violer l'encapsulation, c'est-à-dire sans jamais accéder aux attributs des deux classes depuis l'extérieur de ces deux classes.
• Sans ajouter des getter ou des setter.
• Sans mettre les attributs en public, package ou protected.
• Sans implémenter les algorithmes de conversion à l'intérieur des deux classes elles-mêmes.

=> Écrivez une architecture qui soit capable de convertir en JSON ou en XML ces deux objets.

Indice : Quand on pense en objet, c'est évident, très facile même. Quand on ne pense qu'en procédurale ou son évolution en fonctionnel, cela paraît impossible.

Et dans tout ça je ne compte pas arrêter Rust pour autant mais je fais appel à mes amis pour qu'ils m'aident à trouver une façon "clean" de coder dans ce langage.

J'avais entendu le nom il y a quelques années mais n'ayant pas plus creusé le concept je l'avais oublié. Le hasard du destin me fait retomber dessus aujourd'hui. Bref il s'agit de 9 règles de programmation à appliquer.

En résumé :

1. N'utiliser qu'un seul niveau d'indentation
2. Ne pas utiliser le mot-clef ELSE
3. Encapsuler toutes les primitives et les String dans des objets
4. Encapsuler les collections dans des objets
5. N'enchaîner qu'un seul point (ou flèche) par ligne
6. Ne pas utiliser d’abréviations
7. Garder des classes petites (moins de 50 lignes)
8. Aucune classe ne doit avoir plus de deux instances en guise de variables
9. Ne jamais utiliser de Getter/Setter

Globalement, je le fais sans m'en rendre compte, mes classes sont minuscules (20 lignes en moyennes). Éventuellement le ELSE m'est encore utile mais c'est vrai que programmant en fail-first je lui préfère un throw direct et donc qu'il n'apparaît vraiment pas souvent.

J'avoue qu'en terme d’obfuscation du code ça se pose là !
Pour @Going

Bon ça fait deux années maintenant et je sais où j'en suis niveau langage de programmation : de toutes les syntaxes, ma préférée est sans aucun doute et de trèèès loin celle de Kotlin (sauf pour les get / set).

Par contre, le meilleur compilateur du marché est celui de Rust, il n'y a pas photo. J'ai vraiment hâte que Kotlin Native décolle 😉 !

Via Riduidel.

Rappel, une façon de créer des modules en C :

/* interface.h */

struct library {
    const int some_value;
    void (*method1)(void);
    void (*method2)(int);
    /* ... */
};

extern const struct library Library;
/* interface.h */

/* interface.c */
#include "interface.h"

void method1(void)
{
   ...
}
void method2(int arg)
{
   ...
}

const struct library Library = {
    .method1 = method1,
    .method2 = method2,
    .some_value = 36
};
/* end interface.c */

/* client code */
#include "interface.h"

int main(void)
{
    Library.method1();
    Library.method2(5);
    printf("%d\n", Library.some_value);
    return 0;
}
/* end */

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 ?