Apprendre à coder en c++

Discussions libres
21

Hum j’avoue que j’ai dû relire ton commentaire plusieurs fois avant de répondre, d’abord pour comprendre la logique de ton raisonnement ensuite pour essayer de comprendre le lien avec le fonctionnel. C’est assez loin maintenant pour moi ce cours sur OCaml et malheureusement je n’ai pas pratiqué, je pense avoir perdu une bonne partie de la substantifique moëlle apprise à ce moment là. Mais je vais faire une tentative, j’espère ne pas tomber à côté.

Je vois à travers cette discussion, que pour toi un des critères intéressant d’un langage pour apprendre à programmer est la facilité avec laquelle il permet d’écrire le code et chose importante, sans trop de subtilités qui peuvent être sources d’erreurs pour les non-experts (penser justement au langage C/C++), ce qui n’est pas top pour écrire des programmes fiables.

Les langages fonctionnels permettent d’écrire du code 100% sûr. Il me semble, me corriger si je me trompe, que la raison pour laquelle les programmes fonctionnels sont fiables est le fait qu’ils sont conçus pour rendre impossible les effets de bords. Premier piège classique en programmation pour tous les langages non fonctionnels. Les langages objet (C++, Ruby, Python,…), et plus généralement les langages non fonctionnels, peuvent donner la possibilité d’induire des effets de bords.

Avec les langages objet, on peut limiter les effets de bord. Au niveau des classes et des objets. Avec les langages de type impératifs/procéduraux, les effets de bord peuvent être partout si on n’est pas rigoureux.

Tout penser sous forme d’objet est une très bonne manière d’apprendre la programmation, sauf que ils ne permettent pas d’écrire des programmes sûrs à 100%, à cause des effets de bord qui sont possibles. C’est peut-être ça que tu avais en tête @pvincent ?

1 « J'aime »
22

Plus compliqué concernant OCaml, en effet lorsqu’on lit l’article Wikipédia, c’est un langage multi-paradigme : impératif, objet et fonctionnel ! Ca complique un peu la discussion :slight_smile:. En tout cas avec OCaml on peut s’en tenir à la programmation pure fonctionnelle si on a besoin.

2 « J'aime »
23

Salut @jao,

merci pour ta réponse qui permet d’introduire les différents paradigmes de programmation (impératif, procédural, objet, fonctionnel). Tu as bien résumé les avantages et inconvénients, notamment dans un contexte d’apprentissage.

Pour ma part, j’ai appris la programmation, un peu classiquement, en découvrant au fur-et-à mesure ses différents paradigmes. Parfois, je me suis enflammé, surtout après avoir découvert la programmation fonctionnelle. À cette époque, j’osais même critiquer la programmation orienté objet :woozy_face: . Désormais, un peu plus assagi, je reviens et apprécie davantage un langage comme Ruby.

Exact, l’expressivité et la simplicité me paraissent dorénavant comme des critères importants.

Il me semble qu’il est facile de céder aux sirènes des tendances, y compris sur des aspects comme la robustesse ou la performance. Par exemple, il y a encore peu de temps, le langage Rust paraissait être le choix idéal.

Rust […] topped the chart as “the most desired programming language”

Mais, personnellement, j’ai trouvé que la courbe d’apprentissage est brutale, si ce n’est rédhibitoire. J’admire cependant ceux qui “ont gravi la montagne”. Pour ma part, une petite randonnée me suffit :slight_smile:

2 « J'aime »
24

J’arrive bien tard dans cette discution. Voici mon grain de sel.

Il faut avant tout s’assurer que le langage choisi est en adéquation avec son besoin.

Aujourd’hui la plus part des besoin informatiques sont orienté web et api etc.
Faire du C++ pour faire du web. Ce ne sera pas le “chemin optimal” (euphémisme :slight_smile: ).

Si tu fais des library de calcul, du temps réel, du traitement de signal, de l’embarqué (pas android …) alors le C est un essentiel et le C++ en secondaire.

Voici mon opinion brute:
WEB → RUBY (tous les framework ont copié sur rails etc … @pvincent ;-), c’est élégant et productif)
EMBARQUE → C, incontournable, les fabriquant ne font rien d’autre, … C++
TEMPS REEL → Proscrire tout langage à VM (par définition) → C, C++, Rust
CORRECTION DE CODE et sureté de fonctionnement → Langage Fonctionnel → SCALA, HASKELL (haskell uniquement si tu es dans une boite milliardaire MDR)

C’est mon retour d’expérience après, 10 ans de SCALA pro, 5 ans de RUST et 2 ans de C embarqué, traitement du signal sur DSP NXP.

PS/1 :slight_smile: : RUST c’est presque parfait. Mais parfois difficil à lire tant le langage est puissant. Enormément de concept dans peu de symbole.
PS/2 :slight_smile: : RUST n’est pas objet, pas fonctionnel, mais emprunte les concepts intéressants de chaque.

Rust n’est pas parfait, mais c’est mon préféré.

3 « J'aime »
25

merci, excellente contribution de @Lpe

je ne savais pas que tu avais perduré avec Scala (10ans) :clap:
je suis surpris que tu n’aies pas mentionné Go (un oubli ?).
pour le reste, je valide tout ce que tu as mentionné.

oui, c’est bien vrai.
beaucoup de clone de RubyOnRails, mais aucun qui n’arrive à sa cheville.
avec le recul, je pense que l’avantage n°1 de Ruby sur les autres langages, c’est l’aspect metaprogrammation => dangereux mais tellement puissant :wink:

c du bonheur d’avoir des contributeurs aussi qualifiés que vous.

je sais qu’il y a du haut niveau à la Réunion. je pense à @marcandre, @jnoel, @anna, entre autres, qui de temps en temps, nous font l’honneur d’un petit message.

un jour, ça vaudrait vraiment le coup (comme suggérait par @nathalierun) de se faire un atelier initiation à la programmation et tout le monde viendrait présenter son langage favori.

par exemple, @rjsdesign974, tu fais toujours du Lua ? ça pourrait être intéressant, surtout dans une perspective d’utilisation de Neovim…

26

:heart_eyes: :heart_eyes: :heart_eyes:

27

@pvincent, Concernant Go j’ai survolé au profit de Rust à l’époque (mais c’est un hasard).
J’ai des retours comme quoi Go est très productif et facil à prendre en main.
Go commence à voir une visibilité aux niveau des emplois (… si qq’un à des stats sur les postes recherchés vs langage … je ne serais pas surpris par .Net, Java … MDR :slight_smile: )

Je pense que Go l’emporte grace à la simplicité de prise en main VS la puissance globale.
Exemple : en Go il n’y a pas de notion d’Option native. Il est possible d’implémenté le concept mais ce n’est pas natif.

Un cas classique de difficulté de lecture :

Rust possède les options et rajoute même la notion de Result nativement. Ce qui va plus loin, notament dans la classique gestion de la propagation des erreurs (…). On obtient une code linéaire claire plutot que la fameuse imbrication de IF en accordéon => code metier clair

Néanmoins, Rust peche par la lisibilité :
Ici un exemple de signature d’un code de production supposé simple …

pub fn handle_password_recovery_creation<
    EB: EventBus + Send + Sync + 'static,
    E: Entity + HasEmail + Send + Sync + 'static,
    ER: EntityRepository<E> + EntityExistsByFieldRepository<E> + EntityByFieldRepository<E> + Send + Sync + 'static,
>(mut user_repository: UserRepository<E, ER>, message: MessageAskPasswordRecovery, event_bus: EB, user_password_recovery_mail_topic: String)

Dans cette signature on a les notions de :

  • ici une archi hexagonale qui rajoute une couche d’abstration
  • visibilité de packaging
  • type générique
  • trait et composabilité
  • asycnhronisme/future
  • lifetime
  • typage fort
    …

De fait écrire, une simple boucle FOR dans cette fonction peut se révéler extremement frustrant… en effet … :slight_smile: beaucoup d’erreur "écarlate du compilateur enragé …

Pour écourter le post :

  • si vous etes motivé pour faire du C++ alors vous n’aurez pas peur de Rust et ce sera plus rentable dans le futur (cf apres)
  • NSA et ONCD cite explicitement Rust comme remplacant de C, C++, C#.

    • Problème: 70 % des vulnérabilité sont due aux erreur de dépassement de mémoire.

    • Avec Rust le mécanisme gestion de la mémoire NE PERMET PAS ce type de problème. (cf ownership, borrow checker)

    • Problème: Typage dynamique

    • Rust utilise le typage fort. Tous les types sont vérifié à la compilation. L’exécution est protégée des erreurs de type (Bug de Ariane 5 #1)

    • Problème: Langage à machine virtuelle: Java, Go, Js … (la plus part des lang non compilé). Gestion du garbage collector => INUTILISABLE dans les systèmes temps réels/temps critique

    • Rust est compilé en langage machine comme du C, C++.
      Performance égale/comparable

      Rust est candidat pour etre le Next lang pour les missions spaciales, hardware temps réel

Coté développeur:

  • Ecosystème trés dynamique.
  • Simplicité du build system , versus, Java (SBT, graddle etc …)
  • rapidité
  • interoperable C/C++ nativement
  • documentation très complete.
  • toute plateforme (meme embarqué)
  • Lors de la qualification MISRA, 2/3 de la checklist n’est pas applicable car le langage protège nativement de ces points.
2 « J'aime »
28

je valide aussi.
merci @lpe

pour un débutant, quitte à apprendre un langage, si on choisit le C++ (et ce pour des raisons d’ultra-performance), autant aller directement sur Rust, c’est plus récent, mieux… et encore plus compliqué :wink:

dans le même ordre idée, si le but c’est d’apprendre à programmer, autant zapper le C++ et aller vers des langages plus “abordables”. Ça me parait plus raisonnable

bref le C++, ben euh, il ne reste pas beaucoup d’éléments en sa faveur…
c’est un peu comme apprendre à surfer en allant sur une maxi-vague et avec l’espoir que tout ira bien :pray:

image
image474×721 73.3 KB

est-ce qu’on a répondu à ton interrogation de départ @Fred450 ?

29

Slt → P_20/100…####

Pour ma part , je l’aurais fait en Python ou Bash, les langages de base pour les Raspberry Pi. Après, il y a aussi Go pour les serveurs web. Enfin, comme vous le dites, ça ne sert à rien de réinventer la roue. Il suffit de voir quelle est la communauté la plus active pour ce qu’on veut programmer. L’informatique est vaste…

1 « J'aime »
30

Bonjour @all,
Si je peux partager ma maigre expérience après avoir fait du php il y a … (au moins 15 ans), je me suis lancé dans en projet en Python . j’ai pris beaucoup de plaisir à coder mais j’avoue que je misais sur moins de difficultés pour faire un programme qui tourne sur plusieurs OS. Je serais curieux de découvrir Ruby.

1 « J'aime »
31

ah oui, ça serait une bonne idée de faire le jeu « découvre mon nombre » en Bash.
bravo si tu maitrises ce langage @djtuxxx
perso, je trouve que c’est un langage globalement « difficile ».