• # Comparaison avec Vala

    Posté par  (site web personnel) . Évalué à 3.

    Cela semble bien pareil que Vala ?

    • [^] # Commentaire supprimĂ©

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # L'orientĂ© objet c'est surfait

    Posté par  (site web personnel) . Évalué à -2.

    Aucun intérêt selon moi. L'orienté objet a beaucoup de problèmes de conception et est de plus en plus boudé (c.f rust, go).

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: L'orientĂ© objet c'est surfait

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Je sais que ça paraît stupide comme question. Mais, et c'est sérieux, c'est quoi une programmation orientée objet et en quoi c'est différent d'une programmation euh, normale ? (le pire c'est que je l'ai peut-être su).

      Merci.

      Sinon, il ne faut pas être injuste avec Rust, c'est un petit débutant qui a besoin de s'implanter dans un domaine où il ne manque pas de concurrents (équivalents ou quel que soit le terme qui vous plaira).

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: L'orientĂ© objet c'est surfait

        Posté par  . Évalué à 6.

        Je sais que ça paraît stupide comme question. Mais, et c'est sérieux, c'est quoi une programmation orientée objet et en quoi c'est différent d'une programmation euh, normale ? (le pire c'est que je l'ai peut-être su).

        Il n'y a pas vraiment de programmation "normale" ce qui s'en approcherait le plus c'est la programmation impérative : un programme est une suite d'instructions que la machine exécute l'une après l'autre.

        Il y a beaucoup de programmation différentes : orientée objet, impérative, fonctionnelle, logique,… Et évidement ce n'est pas totalement cloisonné, on trouve des langages qui vont piocher un peu dans différent (ocaml est objet, impérative et fonctionnel par exemple).

        Ce que ça change c'est la manière dont tu organise un logiciel. La programmation consiste entre autre à créer des abstractions et conceptualiser des choses. Représenter des parties de son programme comme des fonctions, des objets ou des modules change la manière que tu as de te représenter les choses. Selon les langages et les styles de programmation ça a aussi un impact sur le programme final (en terme de consommation de ressources) qui peut ne pas être anodin.

        Tout le monde a intimement une préférence (comme ceux qui sont plus visuels) donc tu imagine comment ça peut troller autour du sujet.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: L'orientĂ© objet c'est surfait

        Posté par  . Évalué à 3.

        Une façon de représenter ces différences ça peut être de voir un programme comme une recette de cuisine.

        Généralement c'est impératif, on te dis étape par étape quoi faire.

        Si on écrivait une recette de cuisine en évènementiel. Ce serait quelque chose où toutes les instructions commenceraient par "Quand , faire", la condition ça va être ton évènement (le démarrage de la préparation, le temps passé à laisser reposé, la fin de cuisson, que tel ou tel partie de la préparation est prête,…). Et du coup tu n'es pas obligé d'écrire ta recette dans l'ordre par exemple.

        Si on voulait l'écrire en suivant une programmation logique, on décrirait tout un tas de règle comme :

        • pour avoir une Ă®le flottante, il faut une crème anglaise et des Ĺ“ufs sucrĂ©es montĂ©s en neige
        • pour avoir une crème anglaise, il faut…
        • pour avoir des Ĺ“ufs sucrĂ©es montĂ©s en neige, il faut…

        et ainsi de suite jusqu'à remonter aux ingrédient de base.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: L'orientĂ© objet c'est surfait

        Posté par  . Évalué à 2.

        Je sais que ça paraît stupide comme question.

        Loin d'être stupide, j'ai mis du temps à comprendre l'intérêt de l'orienté objet.

        Ce qui m'a aidé, c'est quand j'ai programmé sur arduino. Car sur arduino l'objet que tu utilises peut être un objet réel (physiquement parlant) : un capteur, un moteur une led.

        L'objet a des caractéristiques (attributs par exemple la couleur de la led, sur quelle broche elle est branché) et des actions (méthodes : allumer la led, l'éteindre par exemple).

        Ainsi en programmation non objet on dirait :

        • Mettre Ă  haut la pin X pour l'allumer
        • Mettre Ă  bas la pin X pour l'Ă©teindre

        En objet on créerait une classe led avec des caractéristiques :

        • broche Ă  utiliser
        • couleur

        Des actions:

        • allumerLed
        • eteindreLed
        • clignoterLed

        On instancie (déclare) notre objet (en l'occurence notre led)

        Et lorsque qu'on a besoin d'allumer la led, on appelle la méthode allumeLed() qui se sert des attributs de notre led (en l'occurence de la broche sur laquelle on l'a branché)

        Evidemment dans l'exemple que je donne, le code semble plus complexe mais :

        • Il est plus modulable (tu peux te servir de ta classe dans un autre projet)
        • C'est plus clair (un allumeLed est plus simple Ă  comprendre qu'un met cette broche Ă  l'Ă©tat haut)

        • [^] # Re: L'orientĂ© objet c'est surfait

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Merci, c'est ce que j'avais compris aussi de la page Wikipédia sur le sujet. Et ce que je comprends avec tes explications, c'est qu'il y a aussi des limites à cette façon de procéder.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

          • [^] # Re: L'orientĂ© objet c'est surfait

            Posté par  . Évalué à 3.

            il y a aussi des limites à cette façon de procéder.

            Il n'existe pas de panacée, clairement, cependant dans le cas de l'objet vs impératif, je dirais que l'objet est une évolution de l'impératif, et que la plupart des bibliothèques de fonctions C essaient de mimer au maximum (des capacités du C, qui sont très, très limitées) l'objet.

            Par exemple, en C il y a typiquement des structures, qui ont chacune un jeu de fonctions dédiées, dont à minima une pour les initialiser, et une autre pour les détruire: il faut juste systématiquement penser à les appeler (aucun mécanisme de création ou destruction automatique), ce qui est une vraie cause de bugs (il est nécessaire d'être plus concentré pour écrire du C correct que pour écrire du C++ correct, et c'est vrai avec bien d'autres langages (que C requiert plus de concentration)). Ça rend l'écriture laborieuse, mais aussi la lecture et, pire, la maintenance.

            D'un autre côté, la bibliothèque standard du C++ (langage multi-paradigme dans le sens ou, contrairement à du java par exemple, il n'y a pas besoin de se battre contre la syntaxe pour utiliser du code non-objet) la tendance est à réduire (et unifier) la richesse des interfaces objet de façon a avoir plus de fonctions, qui en fait exploitent implicitement l'interface des objets, de manière uniforme.

            Pour essayer de faire plus clair, et en reprenant l'exemple de la DEL plus haut, on pourrait avoir:

            class clignotant
{
public:
  virtual void allumer() =0;
  virtual void eteindre() =0;
  virtual bool actif() const =0;
};

class led : public clignotant {
private:
  pin_t m_broche;
  colour_t m_couleur;
  bool m_active;
  void actualiser() { m_broche = m_active ? 0xDEAD : 0xBEEF; }
public:
  void allumer() override { m_active = true; actualiser(); }
  void eteindre() override { m_active = false; actualiser(); }
  bool actif() const override { return m_active; }
};

void clignoter( clignotant& cible )
{
  if( cible.actif() ) { cible.eteindre(); return; }
  cible.allumer();
}

            Et avoir clignoter à l'extérieur, comme une fonction générique. L'avantage de la sortir de l'objet, c'est qu'on peut dès lors lui passer des objets d'un type différents, mais qui peuvent aussi clignoter, a condition d'exposer la même interface (je n'ai pas d'exemple en tête pour compléter celui-ci).

            Ce type de choses est impossible à faire proprement en C ou en java, puisque ces langages étant mono-paradigmes (enfin, pour java, c'est plus nuancé (templates), et ça a peut-être changé, mais je me souviens qu'il était nécessaire de faire une classe avec une méthode statique pour la fonction main(), obligatoire pour lancer un programme, ce qui montre le ridicule du purisme et n'est pas propre…).
            Dans le cas de Java, tout doit être dans un objet, quitte a être déclaré statique.
            Dans le cas du C, il n'existe pas de possibilité d'attacher un type utilisateur à une interface, d'une part, et d'autre part, en C, les arguments d'une fonction ne font pas partie de la signature de la-dite fonction, ce qui mène à ce genre de code:

            double round(double x);
float roundf(float x);
long double roundl(long double x);

            Il faut donc appeler une fonction différente selon le type de variable que l'on passe (c'est particulièrement criant quand on utilise opengl).

            Malgré que l'exemple soit particulièrement trivial, on voit déjà plusieurs problèmes, qui sont certes contournables dans les langages cités, plus ou moins proprement, mais qui restent une charge mentale pour le développeur.

            Mon point n'est pas de dire que C++ est meilleur, loin de la, juste, je considère que l'objet est une amélioration de l'impératif, qui, selon les langages, peu permettre d'avoir un code plus simple à maintenir sur le long terme, à condition de ne pas en abuser. Ce qui a été fait, encore et encore, et typiquement, les outils que je vois qui sont issus du début des années 2000 ou des 1990, sont bourré de l'idéologie "full-object" ce qui en rend souvent le code lourd, complexe, et ironiquement, peu réutilisable.

            D'un autre côté, un langage comme prolog sera radicalement différent, et permets d'écrire certaines parties des programmes bien plus efficacement (en terme de temps passé à écrire le code, en tout cas) puisqu'au lieu de décrire ce que le programme fait, pas par pas, on décrit les règles qu'il doit appliquer à des données.
            Je sais que ça a l'air similaire, mais ça ne l'est vraiment pas, je ne sais pas trop comment l'expliquer mais on laisse en fait le programme décider lui-même dans quel ordre il appliquera les règles.

            Prolog est "un langage de programmation logique" selon wikipedia, et on peut vraiment parler de paradigme différent, du fait que la façon de réfléchir pour obtenir le programme final est vraiment différente, bien plus que dans la guéguerre impératif vs objet (qui gagnent de toute façon a être utilisés ensemble, et non l'un contre l'autre).

            • [^] # Re: L'orientĂ© objet c'est surfait

              Posté par  (site web personnel, Mastodon) . Évalué à 1.

              Les langages objets (c'est le paradigme, comme le fonctionnel et le logique) ne sont pas antinomiques des langages impératifs : quasiment tous les langages objets que j'ai vu passer sont impératifs… Ce dernier terme s'oppose à déclaratif (pensez à Prolog et SQL)
              Il est plus juste, selon moi, de parler de langages traditionnels (ou sens des plus anciens et sans paradigme nouveau/spécifique) pour C par exemple. C++ et Java permettent de travailler de façon traditionnelle (avec une légère gymnastique parfois, comme tu le signales pour Java) ou de façon objet (au passage ces langages ont été écrit en C dans lequel on pouvait déjà faire de l'objet, juste qu'on n'avait pas les aides au niveau du compilateur mais que tout devait se concevoir manuellement) ou un peu de façon fonctionnelle. Tandis que Smalltalk et Eiffel ne permettent de travailler que de façon objet.

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: L'orientĂ© objet c'est surfait

                Posté par  . Évalué à 2.

                Les langages objets … ne sont pas antinomiques des langages impératifs

                C'était mon propos, en fait. À ceci près que je considère l'objet comme un ajout, par-dessus l'impératif, tout en ayant toujours refusé la logique du "tout-objet", ce qui est peut-être la raison pour laquelle j'apprécie le C++: on a plusieurs paradigmes a dispo, mais le langage ne nous force jamais a les utiliser, et en utiliser un n'empêche évidemment pas d'utiliser les autres.
                Je pense que c'est vraiment une des forces principales de ce langage (encore que, ça aurait été pas mal d'avoir des conteneurs standards qui n'obligent pas à utiliser les exceptions, mais d'un autre côté coder un tableau dynamique ou une liste chaînée sans exceptions n'est pas si complexe, et <algorithm> peut fonctionner même avec de simples pointeurs, donc ça me va).

                au passage ces langages ont été écrit en C dans lequel on pouvait déjà faire de l'objet

                Tout comme le compilateur swi-prolog, on peut donc dire qu'on peut faire du déclaratif pur en C… ou peut tout faire en C, après tout, sauf peut-être utiliser des CPU ternaires?

                Le problème, c'est qu'en C il faut une attention de tous les instants pour ne pas écrire de bugs, ce qui est moins vrai (donc toujours vrai) dans les langages implémentant des couches plus hautes (et l'impact sur la performance CPU n'est pas toujours favorable au langage que l'on imagine: penser sort (C) vs std::sort (C++)).
                Il faut aussi bien plus réfléchir pour faire des choses simples dans d'autres langages (au niveau architecture, j'entend. Est-ce un mal, par contre, je ne sais pas.).

                Mais d'un autre côté, exposer une interface publique qui soit écrit dans une sous-partie du C, c'est la seule façon d'avoir une bibliothèque avec une ABI stable, qui soit relativement facile a embarquer dans d'autres langages (presque tous les langages ont au moins un moyen raisonnablement simple d'appeler du code d'une lib C… à condition que ça soit du C très traditionnel, j'imagine qu'utiliser les derniers apports du C peut casser pas mal de choses).

    • [^] # Re: L'orientĂ© objet c'est surfait

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      L'orienté objet a ses avantages et son utilité. Le problème a été de vouloir tout plier avec cette approche, y compris là où ça n'apporte absolument rien ; sans compter que la masse utilise l'objet sans bien comprendre les sous-jacents et les limitations. On aurait eu le même problème s'il y avait le même engouement pour l'événementiel ou toute autre méthodologie.
      De là à cracher dans la soupe c'est un peu abusé. C'est exactement pareil que les gens qui n'ont eu cesse de nous crier que tout langage qui n'est pas objet est sans intérêt (et les mêmes t'expliquaient que c'est de plus en plus boudé et que leurs derniers langages chouchou en est la preuve.)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.