Salut ! Je vais reprendre ce qu’un ami ma dit et ce que en quoi je crois actuellement après beaucoup de débat avec de multiple dev
Toutes les stratégies de gestion de mémoire dynamique ont des problèmes, par exemple pour du Référence Counting si jamais tu as un gros graph au moment où tu va ne plus avoir de référence dessus tu va prendre un petit temps à decrementer tes références et à desalouer tes noeuds, alors qu’un tracing GC sera bien plus rapide car il établit les dépendances entre tes noeuds et donc sais qu’il peux tous les desalouer d’un coup
En soit les deux méthodes ont leur avantages et inconvénients à toi de savoir ce que tu veux, mais pour être productif tu devrais choisir un langage tel que Python, JS, C#
Enfin du moins tu ne seras pas productif en C/C++ avant un petit moment alors que dans un langage comme ceux-cité plus haut ; Tu seras bien plus rapidement productif
C’est l’inverse, justement : le C t’aidera a ne pas faire un site scalable, déployé dans le cloud avec un système de traitement de messages en temps réel entre différents composants, parce que tu te diras « Oh putain c’est une usine à gaz ce machin, je vais faire plus simple ».
En effet, à la place il t’aidera à te faire virer par ton client parce qu’au lieu de répondre à sa demande, tu lui auras fait un site qui segfaulte.
Sérieusement, quand je lis que "le C n’est pas un langage bas niveau", je ne peux pas m’empêcher de penser qu’on est vraiment en train d’entrer dans des considérations sémantiques fatigantes. Soit on s’accorde sur le fait qu’il y a aujourd’hui une pléthore d’autres couches d’abstraction que la seule abstraction fournie par l’OS, qui permettent entre autres de fournir des garanties qui sont vitales dans les applications de nos jours, ou au moins de grandement limiter les risques inhérents au fait de programmer en C (auquel cas, C est à peu près aussi haut niveau que le second étage de l’Empire State Building est à haute altitude — si si, on peut se tuer si on en chute — ce qui ne manquera pas de faire marrer les gens qui ont pris deux ascenseurs l’un après l’autre pour descendre du 200ème étage), soit on continue de se focaliser sur l’interaction entre le C et le matériel au travers d’un microscope, au risque de ne juste plus du tout parler la même langue, ni vivre dans le même monde que la plupart des développeurs de notre époque.
Y’a quand même une sacrée différence d’échelle qu’on ne peut pas choisir de bêtement ignorer.
@LeCBuilder : si tu veux des performances, oublie le C++. Trop lent, il faut compiler et tout. Non non, code en assembleur. Non, mieux, code en binaire (ou en hexadécimal, je suis pas sectaire).
Et puis pour gagner plus de temps et de puissance, code sans système d’exploitation, ce truc inutile qui prend des ressources comme la RAM ou le CPU, si précieuses. Comme directement sur le PC hop, y’a que ton programme qui s’exécute.
Et si possible, prends un super-calculateur, pour plus de puissance.
Puisqu’on en est à tous proposer son petit favori, je pose Rust sur la table, il va te permettre d’atteindre tes objectifs - Exemples : réseau Servo, Kernel Redox - en utilisant un langage "Secure by design" qui compile au travers la stack LLVM pour de bonnes performances tout en ayant des outils modernes (documentation : rustdoc, gestion du projet : cargo, packages : crates.io …)
Tu ne gères pas la mémoire manuellement, elle est gérée là encore par RAII
Si tu souhaites faire des choses dangereuses, tu vas devoir le spécifier au travers le block unsafe!{...} ce qui limite la zone d’erreur possible
Je ne pense pas qu’il est possible de faire un kernel en JS…
Parce que c’est un langage utilisant des notions plus modernes, qui laissent moins la place à l’erreur humaine (et qui sont subjectivement plus agréable à utiliser)
N’importe quel langage, donc. À moins d’avoir des besoins très particuliers, les ordinateurs modernes sont tellement puissants que c’est rare d’avoir des problèmes de performance à cause du langage.
Par contre c’est très fréquent d’avoir des problèmes de performance parce que tes algorithmes sont pourris, ou que tu fais beaucoup d’opérations lentes (entrées/sortie disque ou réseau par exemple), ou parce que tu fais n’importe quoi avec le langage. À propos de ce dernier point, un langage à garbage collector n’empêche pas qu’il faille gérer un minimum la mémoire.
Si. Tu peux écrire un kernel en JS. Le problème c’est d’avoir la toolchain qui permet de le compiler de façon à ce qu’il puisse faire office d’OS. On écrit bien des OS avec Coq, qui est un assistant de preuve, alors pourquoi pas en JS.
Je recherche juste un moyen d’assouvir ma soif de développement avec un langage permettant d’avoir accès à des performances direct
Alors choisis n’importe quel langage et pars avec. Tu es en train d’atermoyer au lieu de juste apprendre à coder, ce qui retarde d’autant plus le moment où tu commenceras à te poser des questions vraiment utiles.
Et puis quand tu te sera suffisamment frotté, au bout d’un certain temps à faire du C ou du C++, aux problématiques inhérentes au fait de manipuler des pointeurs (ou des références), alors là on reparlera de Rust et de ses garanties "pas utiles".
Alors, je ne connais pas Rust, mais un kernel, un peu plus (et c’est assez horrible à écrire).
Dans tous les cas, modifier salement un pointeur, même en C, en assembleur ou en ce que tu veux, tu mettra des warnings au travers de commentaires. Rust permet de le faire très clairement et d’avoir un code moins sujet à erreur, ce qui, de ce que je vois, ne me semble pas du tout une chose sans intérêt.
Je code en C++ quotidiennement (plein de performance, des licornes et de la joie), et clairement, la gestion de la mémoire est une plaie, ce n’est pas pire qu’en C, mais dans tous les cas ce n’est pas simple et pas très plaisant.
Outre le troll, pourquoi apprendre un langage comme Rust pour faire un code avec uniquement des unsafes ? Je vois mal l’intêret
Si tu n’as que des unsafe, c’est que ton code est vraiment mal fichu. Les zones de manipulations douteuses sont très petites (et doivent être les plus petites possible), elles doivent définir les fonctions de bases du noyau, mais tout le reste n’est pas censé être concerné.
b- Hum… Je suis dubitatif. On va dire que cela dépend des secteurs.
J’aurais tendance à dire pas tant que ça. La plupart des logiciels et librairies les plus répandus sont en C. Du côté des softs : Linux, Git, une énorme partie de tout l’écosystème Gnu, Apache, PHP, Python, etc. Du côté des librairies : quasiment toutes, et une énorme partie des librairies dans les autres langages n’en sont que des surcouches articulées autour d’un portage/binding. Bref une basecode beaucoup trop vaste, qui marche, assez souvent critique, et trop utilisée par les couches au dessus pour être réécrite.
Ou en Cobol, Fortran… Tout ça c’est essentiellement historique. A l’inverse on a aussi plein de trucs en C++: des morceaux non négligeables d’OS, les navigateurs, des compilateurs, des bibliothèques d’imagerie comme GDAL dont le cœur est en C++ et qui expose une interface C, les grosses libs à la mode de deep learning (tensorflow & cie). Bref, ça dépend des secteurs.
J’ai du mal à comprendre pourquoi vous tendez à me diriger vers le C++ ?
Je recherche juste un moyen d’assouvir ma soif de développement avec un langage permettant d’avoir accès à des performances direct
Le C++ n’est pas moins performant que le C, il ne peut être qu’autant performant si ce n’est plus (car il a des outils en plus et rien en moins). Les seuls avantages du C: les plateformes exotique dépourvues de compilateurs C++ (et encore là, on observe parfois des écarts dans le dialecte C à employer), et la stabilité d’ABI (là, en C++, c’est bien plus vite compliqué). Pour le reste, moins j’utilise le C, mieux je me porte, donc incidemment mon discours pousse au C++ à la place du C.
Et comme je le disais, le C++ n’empêche pas de dialoguer avec le hardware. Cf les publications de Dan Saks. Par contre les bonnes pratiques du C++ tendent à remplacer le moment où surviennent les erreurs: au lieu de se viander à l’exécution et de devoir débugger, les erreurs sont préférentiellement détectées à la compilation ce qui retire le besoin de débugger.
Ça l’est sur plusieurs aspects. Tu as accès à plus d’outils (standards qui plus est), de manière plus sûre et parfois moins pénible. Est-il besoin de mettre en avant le paradigme orienté objet qui représente un intérêt non négligeable dans l’utilisation de ce langage ?
Question très (trop ?) ouverte. Tu veux apprendre à programmer et à avoir un premier contact aussi concret que possible avec l’informatique ? Le C est un très bon choix selon moi.
Pour le reste de la discussion, je suis quelque peu désolé de voir qu’on part très vite dans ce qui ressemble à de la masturbation intellectuelle sur le choix des mots.
Le C est un langage de bas niveau. Le C++ aussi. Inutile d’aller chercher plus loin. Il y a des considérations matérielles à prendre en compte là où, dans d’autres langages comme le python ou le javascript, il y a de réelles abstractions tel qu’il est question de résoudre des problèmes d’ordre supérieur sans se préoccuper du contenu véritable de la mémoire (et les exemples peuvent être nombreux).
J’adore le C. C’est de très très loin mon langage préféré (et il est parti pour le rester). Mais je rejoins @nohar sur un avis : « il ne me viendrait absolument pas à l’esprit de réaliser un projet en C en 2018 ». Excepté, peut-être, dans l’optique où je devrais programmer sur une modeste architecture embarquée dans un contexte récurrent. Ce qui, j’ose penser, n’est ni le cas des « pro-C » de ce fil de discussion, ni de beaucoup d’intervenants ici.
Pour le reste, ses vertus pédagogiques et la rigueur qu’il requiert pour être correctement employé font que je trouve le langage C intéressant et incontournable pour tout informaticien qui se respecte.
Pour le reste, ses vertus pédagogiques et la rigueur qu’il requiert pour être correctement employé font que je trouve le langage C intéressant et incontournable pour tout informaticien qui se respecte.
Je ne partage pas cela. Je pense qu’il est plus important de comprendre comment l’ordinateur en général (OS et matériel) que les langages bas niveaux qui les exploitent ou les conçoivent. Ensuite il faut surtout que les développeurs d’un langage X sachent ce qui se passe en dessous d’eux.
Pour un développeur Python, connaître les rudiments du fonctionnement de son interpréteur (CPython ou autre) est plus utile que de connaître le C. De même pour Java avec la JVM ou JS et son interpréteur. Si on veut vraiment de la culture, vaut mieux se pencher sur des choses plus exotiques comme le fonctionnel, le réseau qui ont je pense plus à offrir que le C de ce point de vue.
Je suis un développeur C, et honnêtement en dehors de ses domaines d’applications où il reste pertinent (tronc commun pour les bindings de bibliothèques, embarqué et OS en gros) je ne crois pas que les développeurs plus haut niveau en tireraient quoique ce soit de son apprentissage.
On essaie de t’expliquer que, comme beaucoup de débutants, tu bases tes choix sur des arguments dépassés et que tu restes bloqué là dessus.
Encore une fois, nous, on s’en moque avec quel langage tu codes. Mais j’ai l’impression que tu n’es pas intéressé par les réponses qu’on peut te donner, juste par ton propre point de vue.
Y’a quand même une sacrée différence d’échelle qu’on ne peut pas choisir de bêtement ignorer.
Oui, bien sûr. Mais nous, on le sait. Mais les débutants avancent souvent l’argument du "bas niveau" en pensant justement qu’il n’y a pas de couches entre le langage et le matériel. Et donc que l’apprentissage du C est nécessaire pour comprendre les concepts dont a parlé le PO.
Mais honnétement, si une personne te dit qu’il veut apprendre "Du traitement réseau, algorithmie, apprendre la gestion de la mémoire, accès directe au composant, bref..", tu vas lui dire de lire un cours de C, ou des cours de programmation réseau, d’algorithmie, d’archiecture des systèmes, et d’architecture des ordinateurs ?
je trouve le langage C intéressant et incontournable pour tout informaticien qui se respecte.
Je suis d’accord que c’est intéressant de savoir lire le C. Parce que beaucoup d’exemples utilisent le C. Mais la question est surtout : est-il nécessaire d’apprendre le C ?
Les langages de programmation mainstream sont tellement proche que tu peux apprendre n’importe quel langage et réussir à lire (dans les grandes lignes, ce qui est suffisant pour comprendre les tutos) les autres langages. Les concepts de variables, de fonctions, de tests et boucles, de classes, etc. sont tellement proches, que osef un peu beaucoup du choix du premier langage.
Pour un développeur Python, connaître les rudiments du fonctionnement de son interpréteur (CPython ou autre) est plus utile que de connaître le C.
En vrai, si l’on se cantonne à l’interpréteur standard (ce que je fais, personnellement) je pense qu’il est bon de connaître un peu des deux, ne serait-ce que pour pouvoir aller lire le code des modules qu’on utilise (dont une partie est écrite en C), mais je suis globalement d’accord : quitte à choisir, il vaut mieux avoir des connaissances superficielles sur le fonctionnement de l’interpréteur et se dire que le code des builtins et des modules en C, c’est "du code plus rapide, avec lequel on veut minimiser les allers-retours, et qui n’a souvent pas besoin de tenir le GIL pour tourner". À moins de vouloir écrire soi-même des extensions natives (ce qui est plutôt rare, j’imagine, mais je suis mal placé pour en juger parce que c’est un de mes gros kiffs), cela suffit largement pour avoir un niveau de maîtrise "avancé" de Python.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
du moins tu ne seras pas productif en C/C++ avant un petit moment alors que dans un langage comme ceux-cité plus haut ; Tu seras bien plus rapidement productif
