Version imprimable
Si je comprends bien, tu proposes de tout refaire en Swift, Go ou Rust. Parce que Python ou Ruby sont plus vieux que Java, hein...Citation:
Envoyé par ParseCoder
Personnellement, je me méfie de concepts comme la modernité. Les choses ne sont pas meilleures simplement parce qu'elles sont plus récentes.
Sa dépend du compilateur si il est bien foutue ou pas, mais théoriquement oui.Citation:
Donc tu confirmes que le code assembleur généré est exactement le même?
Je travail sur un gros projet en python (50000 lignes de code), et je ressent cette différence avec les langages compilé, en python si d'écrit un code mal optimisé, il exécutera du code mal optimisé, ce qui n'est pas forcément le cas en c++, ou ton code mal optimisé tournera comme une formule1. Tous dépend de la complexité du code et de la qualité du compilateur.
J'ai pu aussi expérimenter cela en php a l'époque ou il n'était pas compilé, mais juste interprété (5.1) puis sur une version qui compilait le code (5.5) et j'imagine qu'ils ont surtout du optimisé le compilateur dans php7.
Python à su évoluer dans le bon sens (python 2.7->python3), c'est ce que je reproche à java, de na pas évoluer beaucoup au niveau des concepts.Citation:
Si je comprends bien, tu proposes de tout refaire en Swift, Go ou Rust. Parce que Python ou Ruby sont plus vieux que Java, hein...
Et python est réputés pour avoir les meilleurs bibliothèques au monde. J'ai essayé pas mal de langage, et seule python m'a fournit des bibliothèques de qualités, riche et performante (codé en C nativement)
Et enfin python fait tous pour être attractif, notamment au niveau juridique (la python software foundation), avec cette License, vous êtes sur a 100% de na pas avoir d'emmerde avec la justice (cf le procès d'oracle-google).
Ce Henrique est un troll.
C'est bien possible car autant la question posée permet de s’interroger sur l’évolutions des langages, autant ses arguments sont complètement débiles (« La vitesse est telle que si deux octets sont envoyés au même moment depuis deux canaux adjacents, ils vont probablement se désynchroniser après avoir parcouru moins d’un mètre. » quel rapport ? :-)).Citation:
Envoyé par jblecanard
Je suis entièrement d'accord avec l'auteur, nous sommes tous confronté chaque jour à ce problème, franchement c'est le genre de problème qui rend le c++ inutilisable...Citation:
C'est bien possible car autant la question posée permet de s’interroger sur l’évolutions des langages, autant ses arguments sont complètement débiles (« La vitesse est telle que si deux octets sont envoyés au même moment depuis deux canaux adjacents, ils vont probablement se désynchroniser après avoir parcouru moins d’un mètre. » quel rapport ? :-)).
Plus sérieusement, +1, ces arguments sont bidons, ce problème doit toucher que 0.1% des dev c++, et puis si on en arrive à faire de tels programmes avec de tels contraintes, faut utiliser des outils spécialisé.
Bonjour,
l'auteur met en avant (en ce qui le concerne) des insuffisances qui le poussent à trouver d'autres alternatives.
Par exemple quand il parle de désynchronisation, c'est compréhensible dans le trading haute fréquence, vous jouez avec des délais en µS, et que votre programme tourne sur des OS qui gèrent l'ordonnancement, c'est pas étonnant d'avoir des signaux qui n'arrivent pas à la µS près. En passant directement par des opérations codées dans le hardware on a pas cette latence.Citation:
Modern C++ has become a game of academic circlejerk and a big waste of time. The 20/80 rule concludes we should move to learn something more productive.
La difficulté d'un langage comme C++ c'est qu'il ne suffit pas de bien connaitre le langage, il faut aussi bien connaitre le compilateur utilisé pour réussir ses optimisations. Dommage, il ne cite pas son compilo dans son article original, qu'il faut lire pour comprendre qu'il n'est pas en dénigrement pur et simple de C++...Bref, Henrique Bucher veut passer au calcul codé en hard pour aller plus vite en exécution, c'est tout à son avantage, un mix eventuel CPU&FPGA peut s’avérer intéressant, mais pas un tout hard pour le moment...Citation:
C++ is awesome, my main tool, but just not enough anymore.
Ça me fait penser à un article que j'avais lu il y a un moment sur Neurogridcircuit de taille d'un ipad, qui affiche une vitesse d’exécution 9 000 fois plus rapide que la meilleure simulation de cerveau humain sur ordinateur, pour une consommation énergétique 40 000 fois moindre...
Il a finalement archive son article, pour le reecrire. Pour etre plus proche de sa pensee. Et il a ecrit un article sur les reactions a son premier article : https://www.linkedin.com/pulse/rippl...enrique-bucher .
Il y a peut etre effectivement un probleme dans la premiere version. Critiquer un langage generaliste comme le C++ en prenant un exemple domaine-specifique et une solution encore plus domaine specifique, on perd le message qu'il voulait faire passer ("le comite C++ s'eloigne de plus en plus de la pratique quotidienne").
Cela semble plus etre un "coup de gueule" qui suit les nombreux autres reaction du meme type, suite aux choix du comite C++ (cf http://www.developpez.net/forums/d15...grera-concepts).
Et sur ce point... je ne suis pas d'accord non plus. Il est vrai que le comite C++ ajoute pas mal de choses inspirees de la programmation fonctionnelle (<troll>qui est avant tout un langage pour que les chercheurs puissent faire joujou, pas un vrai langage de programmation...</troll>). Mais il y a beaucoup de choses egalement qui visent a ameliorer la lecture du code, la gestion des ressources, la recherche d'erreur, la prog concurrente, enrichir la lib standard, etc. Pleins de choses qui ont un impact concret (en particulier sur la qualite logicielle) sur le dev "industriel" de tous les jours.
Bref, le comite C++ est critiquable (p'tin, pourquoi ils ont pas acceptes les concepts !!!), mais cela ne part pas dans un C++ qui serait trop theorique (a mon sens).
la micro seconde aujour'hui c'est déjà long. le trading hyperfréquence est de toute manière limité par les outils de communication, c'est du processus « tortue » par rapport à ce qu'on peut avoir dans le calcul parallèle de rendu graphique ou plus généralement en traitement du signal... et quand bien même, ces questions ne sont pas réellement "langage dépendent". ca n'a aucun sens.Citation:
Envoyé par athlon64
Je ne savais pas qu'il y avait des petits et des grands octets de code. Ca fait quelle taille un "petit octet" ? 7 bits ?Citation:
(...)de plus petits octets de code peuvent être compilés, débogués et optimisés(...)
Plus sérieusement, cette phrase (et plusieurs autres) ne veut strictement rien dire. Messieurs de developpez.net, merci de soit soigner la traduction (on dirait une traduction Google en fait), soit laisser les phrases en anglais...
Edit : Excusez-moi, j'ai été mauvaise langue. Il ne s'agit pas d'une traduction automatique Google, puisque même Google arrive à traduire correctement "smaller bits of code" par "Petits morceaux de code"...
S'il n'a vraiment que ça comme expérience, il est sacrément culotté de sortir des monstruosités comme celles qu'il avance...Citation:
Envoyé par le
Je déteste le C++, mais il est incontestablement le meilleur langage grâce au fait que d'origine il implémente avec les bons termes (JavaScript tu m'entends :aie: ? Php et ses traits/opérateur fusée et autres tu m'entends :aie: ), tout ce dont a besoin un développeur.
On peut simplement tout faire en C++. Oui, tout. Cela n'empêche pas le fait que je ne l'aime pas, mais au moins j'essaie de rester objectif.
En lisant le post original de Henrique Bucher, je comprend le parallèle avec le Fortran comme ceci.
Le Fortran actuel est très éloigné du Fortran90 d'antan (encore plus du FORTRAN77) et la norme ajoute régulièrement de nouveaux concepts au langage, ce qui rend les compilateurs plus complexes et les programmes plus difficiles à appréhender (quand on fait un usage intensif de ces concepts).
Résultat: le scientifique de base qui écrivait son programme de simulation en Fortran sans problème cède de plus en plus la place à des programmeurs hautement spécialisés capables de maîtriser les subtilités du langage, tandis qu'il utilise à la place des interfaces de plus haut niveau.
Bucher semble penser que le C++ évolue dans la même direction.
Salut,
Je crois que je peux comprendre le coup de gueule de ce point de vue. Mais, bon dieu, quand on doit faire l'entretien de sa voiture, on va chez un mécanicien et quand on veut construire une maison, on s'adresse à un maçon!!!Citation:
Envoyé par pvincent
Alors, je comprend que les chercheurs aient souvent besoin d'outils "particuliers" (j'irais même jusqu'à dire "spécifiques"), à l'évolution parfois (très) rapide pour pouvoir obtenir / traiter rapidement leur données. Mais, à mon sens, le véritable problème est sans doute de la nécessité / de l'envie qu'ont les chercheurs à devoir se "débrouiller par eux mêmes" (et ce ne sont bien sur pas les seuls) sans avoir recours à un véritable développeur informatique qui serait capable de développer (sans doute plus rapidement, si les besoins et les formules sont correctement exprimées) leur application dans finalement ... n'importe quel langage (que ce soit en C++, en java, en python ou en brainuck ;) ).
Je peux comprendre l'envie d'apprendre de nouvelles choses (pourquoi pas un langage de programmation), je trouve dommage que, trop souvent, les chercheurs n'aient souvent pas d'autre choix que de faire par eux-même quelque chose qu'il auraient du pouvoir déléguer à quelqu'un dont c'est le boulot...
Alors, oui, tous les langages de programmation deviennent de plus en plus pointus. Mais la technologie elle-même devient de plus en plus pointue. Et on demande à l'heure actuelle des choses à nos ordinateurs (et, de manière générale, à tous nos équipements informatisés) des choses que l'on n'aurait même pas rêvé leur demander il y a une dizaine d'année.
D'une certaine manière, le temps où l'on pouvait développer son application dans son petit labo entre le bec bunsene et la centrifugeuse est "malheureusement" révolu;et il serait tout doucement temps que les gens finissent par s'en rendre compte ;)
Science sans conscience n'est que ruine de l'âme dit-on . Dans ce débat entre passionnés, experts, membres confirmés etc, il est intéressant de noter que l'article révèle les limites d'un langage de programmation à travers son utilisation dans des conditions limites d'éthique voire d 'illégalité dans de nombreux cas.
Les conditions qui poussent ce langage à envoyer 100.000 commandes à la seconde sur certaines plates-formes dites de haute fréquence, permettez-moi de vous les compléter à travers une description en terme moins informatique et bien plus terre à terre .
Ces 100.000 commandes pour la plupart seront de vrais ordres d'achats ou de ventes envoyés sur une vraie bourse ou doivent se former normalement de vrais prix avec un vrai sens..... Mais pour plus de 99% de ces ordres, ils seront annulés dans les quelques millisecondes qui suivent leur envois grâce à la puissance du C++ .... Autrement dit le gentil gars qui programme en C++ induira en erreur de façon systémique et programmée l'ensemble du marché en tronquant le carnet d'ordres délibérément . Et là je suis sympa car je fais court, simple pour respecter les critères d'efficacités chers aux programmeurs... mais je peux vous assurer qu'il y a pleins de méchants programmeurs en C++ dans le haute fréquence aussi....
Je vous vois arriver , vous allez me dire que tout ceci est hors sujet. Vous parlez du fond mais pas de la forme. Pourtant je puis vous assurer que le pire défaut d'un débat de fonds ce sont les oeillères sur les effets collatéraux comme visiblement pratiqués par l'auteur de cet article.
S'il pouvait avoir la même conscience de son art que de la matière sur laquelle il l'exerce, le monde serait probablement un peu meilleur. Cela tombe bien, j'ai de la conscience à revendre et elle ne vaut pas chère en ce moment , une vraie opportunité...
Salutations
Un trader expérimenté
Pour avoir travailler un peu dans le trading haute fréquence, @vicetvirtu, t'es expérimenté comment, sur quelle place de marché ?
Parce que la seule chose qui compte, c'est le PNL (Profite aNd Lose), point barre.
C'est à la fin de la foire qu'on compte les bouses.
"L'avidité de chacun fera le bonheur de tous", le mantra d'un capitalisme qui ne s'assume pas.
P.S.: ce que le trading haute fréquence a besoin, c'est d'un automate, pas d'un ordinateur en sens de la machine de Turing.(=> VHDL, etc.)
Les pertes éventuelles d'efficacité sont motivées puisqu'en faveur d'une attractivité plus grande.
Lorsque que l'on compare le temps de compilation avec le temps de dèbuggage ou pire le temps de JIT du C#
A ma grande surprise, le C# devient has been et le C++ semble avoir le vent en poupe aussi bien des managers de l'IT que des fournisseurs de solutions.
Même MS commence à se pencher très sérieusement sur la nécessité d'offrir un RAD efficace en C++.
Les pertes éventuelles d'efficacité sont motivées puisqu'en faveur d'une attractivité plus grande.
Lorsque que l'on compare le temps supplémentaire de compilation du C++ 11 avec le temps de débuggage d'un programme en C++ ou pire avec le temps de JIT du C# : ON RIGOLE...
A ma grande surprise (Professionnelle), le C# devient has been et le C++ semble avoir le vent en poupe aussi bien des managers de l'IT que des fournisseurs de solutions.
Même MS commence à se pencher très sérieusement sur la nécessité d'offrir un RAD efficace en C++.
Les raisons de ce renouveau :
--Outsourcing demandant une nouvelle génération de developpeurs,
--Les efforts remarquable pour l'évolution du produit qui fait râler 'puristes', les anciens,
--Volonté d'attirer les jeunes développpeurs et aussi reconquérir les anciens développeurs : ce qui est mon cas , je ne me voyais pas revenir sur du C++ après mon expérience Borland 4,0 ...
Les chiffres sont au rendez-vous le % de C++ dans les dvpts est en largement hausse..
OUI LE C++ A ATTEINT SES LIMITES D'OU LE C++11, 14, 17, etc.
The use of C++ has changed dramatically over the years and so has the language itself.
However, for all applications, you can do better with modern C++; if you stick to older styles, you will be writing lower-quality
and worse-performing code. The emphasis on stability also implies that standards-conforming
code you write today will still work a couple of decades from now.
Bjarne Stroustrup, The C++ Programming Language 4e:
pas d'accord avec l'article,
le c++ est un langage fantastique, si l'on comprend qu'il est fait pour fabriquer des lib afin de faire un langage de 4 génération , maintenant sur que si vous voulez écrire une facturation en c++ avec un code linéaire alors passez votre chemin et même avec n'importe quel autre langage PC
si vous avez besoin d’écrire un driver pour des douchettes alors c'est tellement simple en C++ ....
si vous fabriquez un gestionnaire OPDP "open data space" ou la donnée est unique et ce partage dans un même espace qu comprend le" programme , gestion base de données , screen , impression , .... " par exemple alors OUI le C++ est génial.
de plus le c++ a pris beaucoup de sécurité les fuites bientôt disparu.... c'est enrichi de fonctions structurées .... sur que cela oblige à faire de la veille technologique, mais si vous ne voulez pas alors changer de métier en plus de 40 ans de pratique informatique cela a été mon lot quotidien la veille et le remise en cause de mon savoir pour apprendre et comprendre s'améliorer....:pc:
svp ne découragez pas les débutants . :P:P:P:P:P:P
Beaucoup de mythes dans tout cela... Commençons par le C plus simple et efficace. Non mon expérience en C++ me dit que c'est plutôt le contraire surtout depuis la modernisation de C++11. Par contre, sa complexité empêche le commun des mortels de l'atteindre. Le C plus simple en syntaxe oui, mais si nous considérons l'ensemble des problèmes de fiabilités, fuites de mémoires, gestion des exceptions, etc. Il n'est pas certains que le programme C au final est plus simple.
Le Fortran vieux et dépassé, peut-être mais il est toujours là. Pas certain que nous allons pouvoir en dire autant des langages à la mode aujourd'hui dans 50 ans!
Le C++ est peut-être un "mauvais" langage mais c'est encore le plus versatile qui existe pour une foule de problème...
Sans tomber dans l'élitisme source de toutes les erreurs, ce qui a été dit précédement est un bon résumé ...
BJARNE STROUSTRUP,lui-même, rappelle à CPPCON 2015 :
Many people
--Use C++ in archaic or foreign styles,
--Get lost in details,
--Are obsessed with language-technical details,
Within C++ is a smaller, simpler, safer language struggling to get out
--Code can be simpler,
--as efficient as ever,
--as expressive as ever
M. BUCHER devrait télécharger "C++ TODAY THE BEAST IS BACK " ebook gratuit chez Oreilly.com.
Il serait vraiment temps qu'il apprenne un nouveau Langage ... Le C++11 & Sup
Pour paraphraser Machin, "le C++ est le pire des langages de programmation à l'exception de tous les autres".