Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
C et C++ permettent d'avoir plus de contrôle sur le matériel
C et C++ vous permettent d'écrire du code très efficace
Les langages C et C++ sont portables
C et C++ sont des langages qui évoluent
C et C++ sont largement utilisés
C++ a peut-être de l'avenir, mais je doute que ça soit le cas de C
C a peut-être de l'avenir, mais je doute que ça soit le cas de C++
Je pense qu'ils n'ont plus beaucoup d'années devant eux
Autre (à préciser)
Pas d'avis
Discussion :
Tu sais que c'est pas le développeur qui choisit le langage mais le business qui choisit le langage. Si des entreprise utilisent encore Java, ils vont pas migrer ils vont le vendre c'est tout.Envoyé par RyzenOC
Si tu aimes bien les langages vont mourir, va sur Quora. T'as des postes qui annoncent l'appocalypse des langages comme Ruby, C#, Java, PHP, Javascript, ... Tous les langages y passsent.
Java est gros pour mourir. Juste pour rappeler que le monde est grand et se limite pas à Paris.
Une vieille vidéo : Javapocalypse THE JAVA dooms day
J'avais déjà vu la vidéo. Ils ont pas réussi a tuer compleètement IE6 donc j'ai du mal à croire à Java. Je discute avec un Etudiant au Canada qui avait C# au collège. Et qu'il a dû arreter car tous ces amis faisaient du Java.Une vieille vidéo : Javapocalypse THE JAVA dooms day
A chaque nouveau langage on me dit la même chose mais au final bof.
J'attends toujours le fameux MEAN remplace LAMP, hum hum. J'atttends ... En plus ici, on me bassine avec blockchain, GraphQL, RestQL, chatbot, AI et react alors que trois quarts alors que leur produits ne sont pas extraordinaires.
Sa me rappelle cette video
Python n'a pas gagné la guerre. Le seul avantage qui lui restait était la compilation. Et il l'a en quelque sorte perdu.
C et C++ était sur respirateur artificiel, dans le coeur de beaucoup de programmeurs, depuis un bon bout de temps. Produire du code sans fuite de mémoire demande beaucoup de discipline. Plusieurs tentatives pour les substituer avait été fait sans succès (Langage D, C Objective). Mais ce n'est plus le cas, Ruby a donné naissance à un autre langage de programmation qui met la machine au service du programmeur: Crystal.
Un langage très très prêt de Ruby.(pas identique, parce certains avantage d'un langage interprété ne peuvent être reproduit dans un langage compilé). Les performances sont suffisamment prêt de C++ pour la majorité des programmeurs. À moins de faire du web, Java et .NET va également devenir beaucoup moins intéressant. Et pour cette raison, je crois que ce langage va devenir extrêmement populaire.
http://www.blogduwebdesign.com/langa...ment-ruby/1880
Une raison de plus de préféré Ruby à Python ...
Conseiller à quelqu'un d'apprendre Ruby au lieu de Python aujourd'hui c'est quand même lui conseiller de se tirer une balle dans le pied, Ruby est utilisé principalement (uniquement ?) pour le développement web et est en perte de vitesse. Python est utilisé pour le web également mais est aussi le langage de script tout terrain utilisé un peu partout, notamment pour le scripting serveur et dans les domaines scientifiques. Bref d'un côté tu as un langage en perte de vitesse avec un marché du travail restreint et utilisé dans un domaine uniquement, et de l'autre un langage en plein essor avec un marché du travail correct et qui ouvre sur de multiples domaines.
Le choix est plutôt simple en fait.
+1 j'aurais pas dit mieux...
Ah si j'en rajoute une couche, python est intégré à de nombreux programme comme blender 3D ou C4D et bientôt peut etre carrément dans la suite MS office (pour remplacer VB)
Ruby est belle est bien en train de mourir, c'est un fait.
Et c'est pas utile de se réfugier dans un langage sortie de nul part comme "Crystal". Jamais je prendrais le risque de démarrer un projet d'entreprise avec ce langage dont le développement peut s’arrêter à tous moment.
Et Ruby est utilisé dans Sketchup et dans SASS, SCSS, LESS ..
En Python, tu ne peux que faire des programmes qui fonctionne qu'en anglais. En Ruby, tu peux écrire pour presque toute la planète. Et la plupart des jeux de rôle japonais sont fait en Ruby. Et Ruby est très populaire en Asie pour l'apprentissage de la programmation. Les sondages sur les langages ne couvrent ordinairement que le marché anglophone. Alors ils faut les prendre pour ce qu'ils sont: Des sondage que sur le marché anglophone!
Dire que "Ruby n'est que pour du web"est un erreur très répandue. À titre d'exemple, la gestion de paquet de Gentoo est faite en Ruby. La gestion de packet d'OpenSuse et la version graphique( Yast) est également en Ruby. Tu peux remplacer Bash par Ruby sur les Linux et Unix. Et c'est avantageux de le faire parce qu'avec le temps, un petit script peu finir par devenir un véritable programme. Et à tout les fois que tu utilise du CSS programmable, tu fais du Ruby! CoffeeScript, c'est du Ruby compilé en Javascript. Donc tous les programmeurs qui font du Full Stack ou du Front-end on intérêt à apprendre Ruby pour pouvoir aller plus loin que SASS et SCSS.
Dire que Ruby n'a d'intérêt que pour les gens qui font du web à assez risible comme argument. Le Web doit bien représenté au moins 50% du secteur de la programmation. La ligne entre du web et du PC devient de plus en mince. Un smarphone est un cellulaire qui fonctionne sous une version réduite de Linux. Prétendre que Ruby est que pour du Web, c'est ignorer qu'il est existe des interfaces graphique pour tous les OS. Il existe des interfaces graphiques pour tous les OS (La majorité des desktops sur Linux ont leur interface spécifique).. Apple en a fabriquer un spécifiquement un pour ces machines et peut-être étendue en C objective. Et c'est une interface très populaire pour faire des applis pour IPhone. Mais bon, j'imagine qu'à tes yeux, que c'est juste du web,
Tout ce qui est faisable en Python, peut-être fait en Ruby, avec un code qui ne pique pas les yeux. Mais l'inverse n'est pas vrai. parce qu'il est un langage interprété qui a des propriétés qui sont unique dans le monde des langages interprétés. Les objets en Python sont une addition par dessus le langage original. Ruby utilise Unicode dans son mode natif, ce n'est pas le cas pour Python. Python a un support partiel de l'unicode. Il peut l'écrire mais il n'a de grep qui support l'unicode. Et comme ce n'est qu'une addition, pour trouver de la documentation pour faire du Francais en Python est plus rare qu'en Ruby. En Ruby, ma base de donnée supporte le français sans j’aie à me soucier de la configuration de la base de donnée! Ĉ'est aussi simple qu'en anglais.
Et les capacités de métaprogrammation de Python sont insignifiante comparativement à Ruby. J'ignore si le concept de module existe dans les nouvelles versions. Mais le concept de Mixin n'existe pas: http://rubylearning.com/satishtalim/modules_mixins.html . Les Mixin sont un alternative à l'héritage et le multiple héritage. Et je ne crois pas qu'ils pourront être implanté du façon aussi élégante, car Ruby est un langage pure objet comme Smalltalk. Et je n'aborderai pas le fait que la majorité de prof sont collé à la version 2 de Python et que les deux versions ne sont pas compatible.
Avec ces facilités, Ruby supporte presque tous des modèles de programmation. À l'exception de langage déclaratif comme Prolog, tu peux "penser" ton programme en n'importe quel type de langage pour produire ton programme. Un programmeur de Pascal/C++/Smalltalk peut passer aussi bien en Ruby qu'un programmeur de LISP peut passer à Ruby. Il est possible de faire LISP avec du C++ ou d'autre langages. Au final, n'importe quel langage peut-être utilisé pour imiter un paradigme de programmation d'un autre langage, la différence sera dans la simplicité à le faire et la lisibilité du code produit. La différence est la ! Et généralement le résultat final va devoir très bien documenté pour que le programmeur en charge de la maintenance ne fasse pas un dépression.Pour faire des prototypes ou des Proof of Concept, il n'y a pas de meilleur langage. Et comme depuis la version 2.3, les changements se concentre principalement sur la vitesse, les prototypes sont souvent suffisamment rapide pour ètre le produit final. Et si ce n'est pas le cas, il y a JRuby(la version Java de Ruby) et Crystal qui produit du code presqu'aussi rapide que C++. Et garde à l'esprit que ce n'est mème pas la version 1.0 . Ruby a été penser pas son inventeur comme un outil pour que le programmeur puisse concentré sur son programme plutôt que la façon de l'écrire pour pouvoir le réaliser.
Ruby a également une librairie très solides pour les calculs scientifiques Narray (https://fr.slideshare.net/igrigorik/...l_Ndimensional). Ruby n'a pas besoin de toute ces librairies dès le démarrage, ce qui fais qu'il est relativement facilité de faire de l'auto-programmation et d'inventer des objets pendant l'exécution du programme. En Ruby, tout est indéfinissable, même la classe Class( très commode pour déboguer). Tout les classes sans exception peuvent être étendue. Ou on peut étendre juste un objet spécifiquement. Même Smalltalk ne permet pas ce genre de chose. Ruby poussé les limites de la programmation-objet comme aucun autre langage. Certaines chose peuvent être faite en Ruby qui ne peuvent pas être fait dans d'autre langage.
Je peux faire du code et le protéger en le compilant et avoir une application qui est 400% fois la vitesse de la version compilé de Python. À l'heure actuel, Il ne manque que quelque interface pour certaine bases de donnée. Mais cela devrait arrivé assez vite, puisqu'il ne faut adapté du code existant.
Bref tu faire de la programmation dans tous les secteur et pas seulement pour du web. Mais "juste le web" est plus payant que faire du jeux pour EA ou des applis pour MS. Mais bon, les idiots annoncent la disparition de Ruby depuis dix ans et la demande augmente à chaque année. Et ils sont démentis à chaque année.
Donc au bout du compte, c'est l'apprentissage de Python qui est du temps perdue. Et c'est se tirer des balles dans les deux pieds.
Dire que le code Python pique les yeux il faut quand même être sacrément gonflé tellement c'est simple et facile à lire. De même dire que quand tu fais tu SCSS tu fais du Ruby c'est complètement faux, quand tu fais du SCSS tu fais du SCSS et tu en as rien a foutre du Ruby. Il existe d'ailleurs des implémentations de SCSS qui ne sont pas écrites en Ruby. Idem pour CoffeeScript (qui au passage n'est pas exactement en vogue), tu fais du CoffeeScript pas du Ruby, de la même façon que quand tu fais du Python tu ne fais pas du C.
De toutes façons ton post est typique du fanboyisme aveugle et rempli de bêtises du type python ne supporte pas UTF-8 nativement ou le concept de Mixin n'existe pas. Dans l’hypothèse ou tu déciderais de brancher ton cerveau, je t'invite a utiliser ton moteur de recherche favori et te renseigner sur l'état de Python.
Au final je ne dis pas que Ruby c'est inutile ou nul, je dis que c'est en perte de vitesse et que le domaine ou c'était le plus utilisé (le web avec rails) est rattrapé qualitativement par Python + Django/Flask, PHP + Laravel/Symfony, voir même l’écosystème Node.JS, et est moins demandé (pour ne pas dire presque plus). Vas sur n'importe quel portail de recherche d'emploi si tu ne me crois pas et vérifie par toi même.
En langage C, en général, c'est celui qui alloue la mémoire qui a la charge de la désallouer. Une telle conception réduit fortement les chances d'oublier d'appeler un free.
En C++, écrire du code sans fuite de mémoire est facile si on utilise des types comme std::unique_ptr qui libèrent automatiquement la mémoire quand ils sont détruits au lieu d'utiliser des pointeurs nus sur lesquels il faut penser à appeler delete ou delete[]. Quand des développeurs C++ écrivent plein de fuites de mémoire, cela ne vient pas seulement d'un manque de rigueur, mais aussi d'un problème d'enseignement.
En C et en C++, ce qui demande vraiment de la rigueur par rapport aux langages qui ont un ramasse-miettes, c'est d'éviter d'accéder par mégarde à une donnée qui a été détruite. On peut parfois éviter ce problème en remplaçant la sémantique de référence par une sémantique de valeur, mais cela se fait alors généralement au détriment des performances (même quand on utilise le Copy On Write).
C'est clair, je me demande bien ce qu'ils foutent ces flemmards d'enseignants. C'est quand même pas compliqué d'enseigner le delete, le delete [], le unique_ptr, le RAII, la move semantic, l'héritage multiple de classe (virtuel ou pas, évidemment), le polymorphisme, les templates, les templates variadiques, les constexpr...
Pensez-vous que les étudiants suivent systématiquement tout ce que nous leur recommandons, tout le temps ?
Ton commentaire peut se transposer sur n'importe quel type d'école. Il y a l'enseignement, et ce qu'en font les élèves une fois dehors. Regarde la politique, l'ENA est sans doute l'école la plus pointue et la plus exigeante en terme de respect des procédures et de l'éthique. Et regarde nos politiques ? Est-ce réellement les profs qui ont fait ce qu'ils sont... Je ne pense pas.
En informatique, y a tout de même un problème majeur, ça évolue trop vite. Du coup les besoins se définissent mal. Certaine formation sont larguées et ne savent plus si leurs cours sont encore utiles. Ce qui est vrai aujourd'hui à l'école, risque de ne plus être vrai une fois dehors. Y a pas d'inertie, le changement est radical. Une techno hyper tendance hier, et aujourd'hui plus personne en veut. Flash par exemple, le nombre de Flashers qui se sont retrouvés sur le carreau, avec pourtant une excellente formation en école.
Je programme en C++ également( de moins en moins), Et le terme qui utiliser le plus souvent en C++ est "cast". C est un langage vicieux et même les meilleurs font des erreurs. Et C++ est plus un progrès, mais il n'y a qu'à acheter un jeu vidéo pour voir le résultat final. Les programmes atteignent des niveaux de difficulté incomparable. Les programmeurs ne peuvent plus tout prendre en charge. Ces deux langages sont des dinosaures comme je l'ai mentionner, on doit envisager la conception de compilateur doté d'intelligence artificielle. ne afin qu'ils détecte eux-mème les fuites de mémoire.
Ruby est une preuve de concept pour une nouvelle génération de langage. Ruby a prouvé qu'il est possible de faire de la programmation sans devoir constamment faire des déclarations de type. Mais c'est uniquement possible qu'avec un langage pure-object. C et C++ sont des langages idiots. Si je met un variable a la gauche d'un fonction que retourne une chaîne de caractères, on ne devrait pas à avoir à déclarer le type. Mais comme on ne peut étendre les primitives, on ce retrouve invariable avec des variations de ces types. Alors on cast et on cast à ne plus finir.
En plus, il y a un autre problème avec ces deux langages: Ils sont mal enseignés ! C n'a jamais été imaginé pour être fortement typé. Il était destiné à produire un lien entre des routines en langage machine. Et les programmes qui ont servie à créer Unix.n'avait que trois types: pointer, int, double. Et c'est tout. Et ces comme cela qu'Il devrait-être enseigné.
Maintenant passons à C++. Tu as sûrement entendue parler de cette sonde qui s'est écraser sur Mars, à cause d'un erreur de calcul. Et bien cet erreur à été causé par une fonction privée ! Comme les programmeurs n'avaient pas accès au code, ils n'ont pu déterminer la marge d'erreur de la formule de conversion milles/kilomètre. Une simple observation de la formule aurait suffisante pour qu'un programmeur se demande si la constante utilisée avait suffisamment de chiffre après le point. Les attributs et variables privés sont une vrai plaie, J'ai du refaire des classes complètes en raison de ces saletés. Les professeurs devraient cesser d'encourager les programmeurs de les utiliser. Et si on comprend le concept de SOLID, on réalise que ces truc vont à l'encontre de cette pratique.
Autre archaïsme, l'emploi d’accesseur pour tout et pour rien, alors qu'ils sont inutiles en langage-objet (Pascal s'en passe très bien), En réalité, les accesseurs ne sont utiles qu'à la réception d'une entrée, Si tu as des oranges à l'entrée et que tu t'assure que c'est bien des oranges. Et bien à la suite de ton convoyeurs, tu n'aura que des oranges, Seule vérification nécessaire seront celle qui s'assureront que tu respecte les limites de tes conteneurs (arrays , collections, etc).
En SOLID, tu as trois types d'éléments: Les éléments de base: Cercle, carré, chiffre, structure. Les convoyeurs: ce sont eux ont la charge de remplacer les accesseurs et de vérifier la validité des types et ou de convertir ce qui ont reçue en quelque chose de compatible aux destinataires. Et enfin les contenants: Là rien nouveau, tableau, liste chaînée, fichier.
Une fois, que tu as tout dégraissé à l'essentiel, cela donne des objets très légers. Et conséquemment des programmes plus rapides. Et en bonus, des programmes plus facile à maintenir.
Considérant que Ruby est dans la section Autre sur ce site, c'est drôle !
A partir du C++11, on peut faire de l'inférence de type avec auto, par exemple : auto i = 1;.
Dans d'autres langages, on peut faire de l'inférence de type sans devoir taper un mot-clef spécifique.
Dans tous les cas, pour qu'un langage permette au développeur de ne pas devoir écrire explicitement le type, il n'a pas besoin de supporter le paradigme objet. C'est indépendant.
Les conversions explicites sont verbeuses, mais les conversions implicites sont des sources de bogues.
Par exemple, si on appelle une fonction qui prend en paramètre une chaîne de caractères et un entier mais que l'on écrit les deux arguments dans le mauvais ordre par mégarde, si l'entier n'est pas convertible en chaîne ou si la chaîne n'est pas convertible en entier, alors on aura une erreur de compilation et on verra tout de suite d'où vient l'erreur au lieu de perdre du temps en débogage, à l'exécution.
Au contraire, les professeurs doivent encourager les développeurs à les utiliser et surtout leur expliquer à quoi ça sert.
L'un des intérêts des variables privées est de pouvoir parfois changer l'implémentation de la classe sans avoir besoin de mettre à jour le code source des utilisateurs de la classe. Cela permet, entre autres, de travailler plus efficacement à plusieurs. En effet, quand une classe est utilisée par de nombreuses personnes différentes, s'il faut aller voir tout le monde chaque fois que l'on veut changer la liste des variables membres de la classe, on perd en productivité. C'est encore plus flagrant quand on ne connaît pas la liste exhaustive des utilisateurs, par exemple quand on code une bibliothèque.
Un autre intérêt des variables privées est de pouvoir avoir des invariants de classe. Cela permet de concentrer certains contrôles sur les constructeurs et les mutateurs de la classe au lieu de multiplier ces contrôles dans tout le code qui utilise la classe en question. Par exemple, si, dans un programme donné, un code utilisateur doit être une chaîne alphanumérique non vide sans majuscules, alors il vaut mieux créer une classe CodeUtilisateur avec une variable membre privée de type std::string et un constructeur qui vérifie que la chaîne en question respecte bien les contraintes plutôt que d'utiliser directement des variables de type std::string et écrire 500 fois dans le code assert(EstCodeUtilisateurValide(chaineCodeUtilisateur));.
Il est clair que C et C++ ne sont pas des langages de débutants. Et il y a même un certain nombre de programmeurs qui n'atteindront jamais la rigueur requise pour écrire des logiciels robustes dans ces langages. D'où le grand développement des langages qui gèrent tout cela automatiquement, avec des ramasse-miettes par exemple, qui ont du succès dans les domaines où la productivité de codage est plus importante que tirer les performances maximales de la machine.
Mais si on y tient vraiment, on peut aussi implémenter des ramasse-miettes généralistes en C++, et faire du comptage de références, ça peut être utile dans certains domaines. Mais quand ça ne l'est pas et que c'est même potentiellement pénalisant, on est bien content d'être libre de s'en passer.
En fait, derrière la question posée dans cet article, se pose une autre question :
Le C/C++ permet-il de trouver plus facilement un job de dev que d'autres langages de programmation ? Est-ce une carte de visite qui peut durer dans le temps ?
ce que je remarque sur le marché c'est qu'il y a peu d'emploi pour ces langages comparativement à java.
même en embarqué, il n'est plus rare de voir du java, alors que je vois essentiel du C il y a plus de 12 ans.
Répondre avec citation
Partager