GO et un de plus,

[Ludwig1]

Bonjour tous le monde,

Ayant un peu analysé la syntaxe du langage GO de chez Google, je me demande quel est l'intérêt d'avoir
à disposition un langage supplémentaire alors qu'il en existe déjà une quantité non dénombrable.
J'ai cru comprendre que ce langage est essentiellement inspiré des travaux de nom estimé collègue Wirth (Pascal) ainsi que des travaux de Ritchie (C).

Je dois probablement être nul, pour ne pas saisir le bien fondé d'un langage supplémentaire, quelqu'un peut' il m' expliquer?

Cordialement

Ludwig
-----

[CM63]

Bonjour,

J'ai lu le début de la page Wikipedia qui en parle. Au départ je n'ai pas trop aimé le ton condescendant, disant que , en gros, le langage était fait pour les nuls, mais j'ai continué un peu à lire.

L'un des points forts de ce langage c'est qu'on a un héritage "par structure": l'héritage n'est pas déclaré mais automatiquement reconnu en voyant qu'il y a les mêmes données membres.
Il n'y a donc pas vraiment de classes, mais on dispose quand même d'"interfaces" (ces classes "spéciales" qui, en Java et en C#, autorisent l'héritage multiple alors qu'il est interdit dans les classes ordinaires (était⁽¹⁾ autorisés en C++ et aboutissait à des plats de spaghetti)).

C'est un langage compilé. Il fait "automatiquement" du multithreading, et on peut bien sur l'interdire ou se rendre prioritaire (grâce au mot clef "go" : on fait go f(x) au lieu de f(x) )

La démarche a l'air intéressante mais le problème c'est que c'est (encore) un langage propriétaire, il faudrait la même démarche en libre.

(1) : je parle toujours à l'imparfait lorsque je parle du C++: non que le langage n'existe plus, mais qu'on (enfin je) ne l'utilise plus.

[Ludwig1]

Bonjour tous le monde,

Ayant un peu analysé la syntaxe du langage GO de chez Google, je me demande quel est l'intérêt d'avoir
à disposition un langage supplémentaire alors qu'il en existe déjà une quantité non dénombrable.
J'ai cru comprendre que ce langage est essentiellement inspiré des travaux de nom estimé collègue Wirth (Pascal) ainsi que des travaux de Ritchie (C).

Je dois probablement être nul, pour ne pas saisir le bien fondé d'un langage supplémentaire, quelqu'un peut' il m' expliquer?

Cordialement

Ludwig

Bonjour,
Je viens de découvrir un lapsus

essentiellement inspiré des travaux de nom estimé collègue Wirth (Pascal)

Il faut lire

essentiellement inspiré des travaux de MON estimé collègue Wirth (Pascal)

ça va sans dire que j'ai beaucoup d'estime pour Niklaus Wirth et ses travaux de dévelopemment

Cordialement
Ludwig

[Bluedeep]

L'un des points forts de ce langage c'est qu'on a un héritage "par structure": l'héritage n'est pas déclaré mais automatiquement reconnu en voyant qu'il y a les mêmes données membres..

Et en quoi est-ce un point fort ? J'ai beaucoup de mal à voir quel peut être l'avantage de ce genre d'héritage implicite.

[A voir en vidéo sur Futura]

[CM63]

Oui, le vocable de "point fort" ne convient pas, disons plutôt "une caractéristique".

[Ludwig1]

L'un des points forts de ce langage c'est qu'on a un héritage "par structure": l'héritage n'est pas déclaré mais automatiquement reconnu en voyant qu'il y a les mêmes données membres.
Il n'y a donc pas vraiment de classes, mais on dispose quand même d'"interfaces" (ces classes "spéciales" qui, en Java et en C#, autorisent l'héritage multiple alors qu'il est interdit dans les classes ordinaires (était⁽¹⁾ autorisés en C++ et aboutissait à des plats de spaghetti)).

Salut,

Je dois dire que j'ai toujours de la peine à comprendre le bien fondé de ces notions de classes. Ce doit probablement être lié
au fait que:

je ne comprend rien à l'informatique classique
j'ai d'avantage l'habitude d'utiliser un calculateur comme étant une machine à qui je dit ce qu'elle doit faire.
je considère les données comme étant des objets sur lesquels je peux réaliser une opération.
je suis plutôt orienté informatique industrielle, GEMMA, Grafcet, Régulateurs numériques etc...

Par exemple pour piloter les actions d'une machine de production, on donnera les ordres suivants:

Verrin5 sortir
Vanne8 ouvrir
Convoyeur3 Arreter
Etc...

Ouvrir un fichier, lire une ligne dans un fichier, chercher un mot dans cette ligne, fermer un fichier,
Multiplier une matrice, afficher une fenêtre à l'écran, saisir une donnée au clavier etc... sont bien des opérations qui
sont réalisées selon un schéma qui est toujours le même,

Données opérations sur ces données, données opération sur les données etc...

Quand on regarde comment les compilateurs procèdent, on s'aperçoit qu'à partir du texte source d'un langage donné,
ils préparent d'une façon ou d'une autre (en Pascal le tas par exemple), une structure (Pile) de données puis appliquent les
instructions.
En quelque sorte, ils font tous plus ou moins la même pour obtenir plus ou moins la même chose.
Alors pourquoi un de plus pour faire toujours la même chose?


Cordialement
Ludwig

[CM63]

Bonjour,

Imaginons que l'on veille commander le fonctionnement d'un moteur. En programmation classique (pas objet) on va définir un certain nombre de variables:
- etat qui peu prendre la valeur "marche" ou "arrêt",
- vitesse qui prend une valeur numérique entre 0 et 3000t/s
- etc, imaginons que ce soit un système plus compliquée qu'un moteur, et qu'il y ait une centaine de telles variables.

Si maintenant je veux commander le fonctionnement d'un deuxième moteur, je suis obligé de recommencer la définition de mes 100 variables, en modifiant le nom:
- etat_1 , vitesse_1 , etc

Et si je dois le faire pour N moteurs, je suis obligé de recommencer ma liste de 100 variables à chaque fois. Tu me diras on peut faire un copier coller et remplacer le 1 par un 2 dans la liste. Eh bien c'est justement ce que permet la programmation par classes : faire du "copier coller par programme". Certes c'est un peu réducteur, la POO ce n'est pas que ça, mais c'est déjà suffisamment parlant.

Dans le cas présent on va faire :

Je déclare la classe Moteurs avec ses variables :

Class Moteur:
variable etat qui peu prendre la valeur "marche" ou "arrêt",
variable vitesse qui prend une valeur numérique entre 0 et 3000t/s
etc , là j'ai 100 lignes, mais une seule fois

Et ensuite j'instancie mes moteurs:

M1=new Moteur();
M2=new Moteur();
etc , je n'ai plus qu'une seule ligne par moteur.

Ceci n'est qu'un exemple, bien entendu, il y a d'autres avantages à la (improprement nommée) POO (je dirais plutôt programmation par classes).

Tu me diras : on peut faire cela avec des structures de données, en C, pas besoin de classes. Je répondrai: si maintenant je veux créer non plus des données, mais des "méthodes" (des fonctions), par exemple je veux créer la méthode démarre, qui va faire quelque chose d'autre de plus complique que de simplement faire passer la variable etat à "marche", le C ne suffit plus, je suis obligé de passer à un langage de classes, comme le C++.

Dans mon pseudo-langage , cela donnerait:

Class Moteur
   ... définition des variables comme ci-dessus,
  définition de la méthode démarre:
   def demarre():
      code de la fonction

Et ensuite, je fais:
   M1=new Moteur()
   M1.demarre()
   M2=new Moteur()
   M2.demarre()

etc, convaincu ?

[CM63]

Désolé j'ai oublié de mettre des balises codes sur mon pseudo-code, et je ne peux plus modifier mon message. Si un modérateur pouvait le faire, je voulais notamment faire une indentation à la Python, si un modérateur peut faire la modif, je vous dirais si c'est bon.

Class Moteur:
    variable etat qui peut prendre la valeur "marche" ou "arrêt",
    variable vitesse qui prend une valeur numérique entre 0 et 3000t/s
    etc , là j'ai 100 lignes, mais une seule fois

Class Moteur
    définition des variables comme ci-dessus,
    définition de la méthode démarre:
    def demarre():
         code de la fonction

[inviteb9f49292]

Imaginons que l'on veille commander le fonctionnement d'un moteur. En programmation classique (pas objet) on va définir un certain nombre de variables:
- etat qui peu prendre la valeur "marche" ou "arrêt",
- vitesse qui prend une valeur numérique entre 0 et 3000t/s
- etc, imaginons que ce soit un système plus compliquée qu'un moteur, et qu'il y ait une centaine de telles variables.

Si maintenant je veux commander le fonctionnement d'un deuxième moteur, je suis obligé de recommencer la définition de mes 100 variables, en modifiant le nom:
- etat_1 , vitesse_1 , etc

Et si je dois le faire pour N moteurs, je suis obligé de recommencer ma liste de 100 variables à chaque fois. Tu me diras on peut faire un copier coller et remplacer le 1 par un 2 dans la liste. Eh bien c'est justement ce que permet la programmation par classes : faire du "copier coller par programme". Certes c'est un peu réducteur, la POO ce n'est pas que ça, mais c'est déjà suffisamment parlant.

Je ne suis pas d'accord avec cette dichotomie, ici ta factorisation de code passe par la mise en tableau, et si tu veux une structure. La POO c'est essentiellement se trimbaler les algorithmes avec les données qu'ils doivent manipuler et l'héritage.

Tu me diras : on peut faire cela avec des structures de données, en C, pas besoin de classes. Je répondrai: si maintenant je veux créer non plus des données, mais des "méthodes" (des fonctions), par exemple je veux créer la méthode démarre, qui va faire quelque chose d'autre de plus complique que de simplement faire passer la variable etat à "marche", le C ne suffit plus, je suis obligé de passer à un langage de classes, comme le C++.

Si le C suffit, il faut le faire à la "main": une structure avec des pointeurs sur fonction par exemple. Le C n'est peut-être pas "orienté objet", mais ça n'empêche pas d'en faire et il ne faut pas s'en priver... Ce n'est pas un simple amusement d'universitaires mais bien une technique qui est employée dans de vrais projets (dans le noyau linux par exemple)
Ce n'est pas u

[CM63]

Si le C suffit, il faut le faire à la "main": une structure avec des pointeurs sur fonction par exemple.

Oui bien sur, mais c'est juste plus compliqué à écrire. Avec des pointeurs sur fonction, bonjour... mais pourquoi faire simple. C'est justement en constatant cette complexité d'écriture que les créateurs du C++ en sont venu à ce langage.

Le C n'est peut-être pas "orienté objet", mais ça n'empêche pas d'en faire et il ne faut pas s'en priver...

C'est pas parce qu'on fait du C++ qu'on va se priver de faire du C, personne n'a jamais prétendu ça, enfin pas moi.
Quant à l'expression "orienté objet", il y a longtemps qu'on n'en parle plus, c'est un faux débat , on fait de la POO comme Mr Jourdain fait de la prose, sans plus jamais faire référence à cette expression "orienté objet" qui résulte d'une mauvais traduction de l'expression anglaise.

[minushabens]

Imaginons que l'on veille commander le fonctionnement d'un moteur. En programmation classique (pas objet) on va définir un certain nombre de variables:
- etat qui peu prendre la valeur "marche" ou "arrêt",
- vitesse qui prend une valeur numérique entre 0 et 3000t/s
- etc, imaginons que ce soit un système plus compliquée qu'un moteur, et qu'il y ait une centaine de telles variables.

Si maintenant je veux commander le fonctionnement d'un deuxième moteur, je suis obligé de recommencer la définition de mes 100 variables, en modifiant le nom:
- etat_1 , vitesse_1 , etc

Et si je dois le faire pour N moteurs, je suis obligé de recommencer ma liste de 100 variables à chaque fois. Tu me diras on peut faire un copier coller et remplacer le 1 par un 2 dans la liste. Eh bien c'est justement ce que permet la programmation par classes : faire du "copier coller par programme". Certes c'est un peu réducteur, la POO ce n'est pas que ça, mais c'est déjà suffisamment parlant.

pour moi ce n'est pas tellement ça l'intérêt de la programmation par objets. Pour le problème que tu décris il suffit de définir une structure de données "moteur". En programmation orientée objets tu va pouvoir définir plusieurs sortes de moteurs, disons essence, diesel, électrique... qui auront un fonctionnement interne différent mais auront tous en commun le fait d'être des moteurs. Ensuite tu pourras définir par exemple une fonction "demarrer_moteur" que tu pourras appeler pour démarrer n'importe quel moteur: la suite d'opérations que devra exécuter cette fonction sera cachée au programme appelant. Ca simplifie beaucoup la compréhension du code. Enfin ce n'est que mon avis de non-spécialiste.

[inviteb9f49292]

pour moi ce n'est pas tellement ça l'intérêt de la programmation par objets. Pour le problème que tu décris il suffit de définir une structure de données "moteur". En programmation orientée objets tu va pouvoir définir plusieurs sortes de moteurs, disons essence, diesel, électrique... qui auront un fonctionnement interne différent mais auront tous en commun le fait d'être des moteurs. Ensuite tu pourras définir par exemple une fonction "demarrer_moteur" que tu pourras appeler pour démarrer n'importe quel moteur: la suite d'opérations que devra exécuter cette fonction sera cachée au programme appelant. Ca simplifie beaucoup la compréhension du code. Enfin ce n'est que mon avis de non-spécialiste.

Exactement, c'est la notion d'héritage/polymorphisme, et c'est ce que j'essayais de dire dans ma réponse... par opposition à l'agrégation (tableau ou structure).

Oui bien sur, mais c'est juste plus compliqué à écrire. Avec des pointeurs sur fonction, bonjour... mais pourquoi faire simple. C'est justement en constatant cette complexité d'écriture que les créateurs du C++ en sont venu à ce langage.

Franchement, gérer des pointeurs sur fonctions c'est pas compliqué, éventuellement un peu difficile à déclarer (mais le typedef est là pour ça)... Surtout au regard des difficultés qu'amène le C++ (opérateur de copie par défaut et autres joyeusetés de la pieuvre). De plus, un intérêt de la POO devrait être la facilité d'encapsulation, mais va t'en faire une classe opaque en C++ alors qu'en C c'est très simple. Bref, on est pas obligé de faire comme GTK+ et leur GObject...

C'est pas parce qu'on fait du C++ qu'on va se priver de faire du C, personne n'a jamais prétendu ça, enfin pas moi.

Heureusement, je me serais fâché très fort sinon! Blague à part, c'est une ritournelle très classique qu'on nous serine dès l'école qu'on ne peut pas faire d'objet en C, et c'est un peu ce que j'ai cru voir transpirer de ton texte. Or c'est totalement faux, et c'est même une technique à conseiller lorsqu'elle est pertinente.

Quant à l'expression "orienté objet", il y a longtemps qu'on n'en parle plus, c'est un faux débat , on fait de la POO comme Mr Jourdain fait de la prose, sans plus jamais faire référence à cette expression "orienté objet" qui résulte d'une mauvais traduction de l'expression anglaise.

Je ne sais pas où tu vois un problème de vocabulaire dans la traduction, éventuellement objet qui n'a pas le même sens en C (produit de la compilation) mais il me semble qu'en anglais c'est le même vocable.
Ceci dit, je ne suis pas d'accord non plus, la POO (où appelle la comme tu veux) est un paradigme différent du procédural ou du fonctionnel... Et il y a des critères objectifs pour pouvoir catégoriser un programme / une conception dans une (ou plusieurs catégorie). Si tu n'utilises jamais la notion d'héritage, tu ne fais pas de la POO, même si tu utilises du C++. Dans mon boulot (informatique embarquée) l'orienté objet est rarement pertinent je fais donc principalement du procédural.