IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Affichage des résultats du sondage: Pourquoi C et C++ auraient-ils encore de nombreuses années devant eux ?

Votants
75. Vous ne pouvez pas participer à ce sondage.
  • C et C++ permettent d'avoir plus de contrôle sur le matériel

    41 54,67%
  • C et C++ vous permettent d'écrire du code très efficace

    38 50,67%
  • Les langages C et C++ sont portables

    35 46,67%
  • C et C++ sont des langages qui évoluent

    19 25,33%
  • C et C++ sont largement utilisés

    48 64,00%
  • C++ a peut-être de l'avenir, mais je doute que ça soit le cas de C

    8 10,67%
  • C a peut-être de l'avenir, mais je doute que ça soit le cas de C++

    3 4,00%
  • Je pense qu'ils n'ont plus beaucoup d'années devant eux

    6 8,00%
  • Autre (à préciser)

    3 4,00%
  • Pas d'avis

    3 4,00%
Sondage à choix multiple
Langages de programmation Discussion :

Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ?


Sujet :

Langages de programmation

  1. #181
    Modérateur
    Avatar de jlliagre
    Homme Profil pro
    Ingénieur support avancé & développement
    Inscrit en
    Juin 2007
    Messages
    2 695
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur support avancé & développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 695
    Points : 7 882
    Points
    7 882
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Malheureusement, ton analyse est complétement erronée
    Disons plutôt que c'est une opinion que tu ne partages pas.

    factuellement: l'activité principale des développeurs est la lecture (90%) et l'activité d'écriture représente environ (10%).
    On ne peut pas généraliser sur l'activité principale présumée des développeurs. Il y a tellement de paramètres. L'activité d'un développeur commence souvent par essayer de comprendre ce que le cahier des charges veut bien dire, puis à réfléchir à la meilleure manière d'y arriver, rechercher le code existant ou les bibliothèques qui pourraient être utilisés, prototyper, tester, profiler, analyser, dessiner, discuter, regarder ce qui se fait ailleurs, partager ce qu'on fait, synchroniser, intégrer, valider, documenter, expliquer, comparer, imaginer, inventer, ... C'est un métier passionnant le développement, il ne consiste pas à uniquement rédiger et lire des specs compilables.

    Dans beaucoup de ces tâches, le code source intervient peu, mais je suis d'accord sur le fait que quand on a affaire à du source, c'est plus souvent pour en lire qu'en écrire.

    Ce qui tu appelles mots clefs intrusifs, je l'appelle "anglais structuré". C'est justement ce qui fait la force de ces langages, dès lors qu'il faut communiquer avec la maîtrise d'ouvrage (les clients) : bien utilisés, on écrit des spécifications qui compilent.
    Ça me parait un peu idyllique comme approche. Ton client ne va de toute façon pas de lire 100000 lignes de spécifications.

    Leur "verbosité" est une force qui permet au compilateur de détecter bien plus d'erreurs que dans d'autres langages qui pratiquent la concision et l'élision.
    Ce sont souvent des erreurs faites essentiellement par des débutants. Le pascal est sûrement un bon langage pour enseigner la programmation, mais je trouve que sa verbosité est par la suite un handicap.
    C'est un peu comme les petites roues de stabilisation sur un vélo d'enfant. C'est très bien pour l'apprentissage, mais un jour, il faut les enlever.

    Tu es libre de penser autrement, je te donne juste mon avis. La lisibilité est un facteur important sur l'évaluation que je porte sur les divers langages de programmation que j'ai pu côtoyer et utiliser professionnellement depuis trente-cinq ans, mais ce n'est pas le seul. Par exemple le C++ a beau reprendre beaucoup de la syntaxe du C, je n'ai jamais apprécié lire ou écrire du C++. Au contraire, la syntaxe de SmallTalk n'a rien à voir avec celle du C et j'ai pourtant, en 1986, été enthousiasmé par ce langage et son environnement. J'aime bien aussi la concision de Python mais j'ai horreur de celle de Perl. Les goûts et les couleurs...

    Il reste bien sûr des erreurs sémantiques, mais ces erreurs sont facilement repérables par les clients non informaticiens car ceux-ci sont capable de lire et vérifier les spécification qu'on leur fournit.
    Des clients non informaticiens qui lisent de l'ADA dans le texte, je demande à voir...

    Par ailleurs, tout environnement moderne permet de mettre en gras, d'afficher ou de masquer tout ou partie du source qui fait l'objet de la revue ou (plus rarement) de l'écriture. Le problème des mots-clefs ne se pose pas en pratique d'un point de vue rapidité d'écriture ou capacité à voir des éléments dans le source.
    Si, ça me pose un problème. Je parle surtout ici de la rapidité de lecture, de l'« entropie» du code source, la proportion d'information non redondante, le rapport entre le poids total et la "charge utile" si tu préfères.

    Témoignage:

    ...

    Au final, nous avons spécifié en Pascal, codé en C++, produit le logiciel en 70% du temps imparti, satisfait le client et la comptabilité, et obtenu zéro défaut. Un bon bilan, je crois.
    Alors là, respect !

    En cherchant des projets similaires, je suis tombé sur Lookheed Martin qui a développé l'informatique embarquée de la navette spatiale. Il s'agit de 420000 lignes écrites en ADA, donc du même ordre de grandeur que ton projet de 100000 lignes exécutables, d'autant plus qu'eux, ils ne devaient pas lésiner sur les commentaires.

    Voilà ce qu'on peut lire à propos de ce projet:

    This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.
    Ok, c'était il y a vingt ans et la productivité des développeurs et la qualité des outils ont bien sûr progressé, mais à l'époque, il y avait deux cent soixante personnes pour développer tout ça, dont une bonne partie dont le rôle était uniquement de tester le code.

    Le coût de développement de ces 420000 lignes de code qui ont demandé 21 ans de travail a été d'environ 700 millions de dollars...

    Ok, je me doute bien que ton projet n'avait pas la complexité de celui de Lookheed Martin, et le nombre de lignes de code n'est pas une métrique très pertinente, mais quand même...

    On ne programme pas en Pascal, Ada, Obéron ou Eiffel comme on "code" en C/C++/Java...
    Dans le temps, j'aimais bien crypter en assembleur...

    D'ailleurs, il va falloir créer un nouveau smiley pour ne pas froisser les susceptibilités, celui-ci étant inadapté :

    Comme indiqué plus haut dans un autre post (et avec un peu d'humour), tu roules tranquillement en Twingo, je fonce en Ferrari, et je m'éclate :-). Rejoins-moi, si tu le veux?
    Je roule dans la vraie vie. Une Ferrari, c'est bien pour frimer à Monte-Carlo mais dans les bouchons parisiens, c'est pas forcément la meilleure solution et pour ce qui est de foncer, méfie-toi ! Je viens de me faire flasher et perdre un point, comme quoi une Twingo, ça peut aussi être surdimensionné...

    Citation Envoyé par Pol63 Voir le message
    et qu'il faut rajouter quelque chose à la fin de la boucle, ou une classe je suis obligé de trouver à quoi correspondent ces accolades
    avec
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
             next
          end sub
        end class
      end class
    end namespace
    on comprend tout de suite la structure, qu'il y a une classe dans une classe etc...
    Je ne lis que rarement le code source à partir de la fin donc en général, la structure globale, je la connais quand j'arrive à ces fins de blocs.

    En plus, si je me pose la question de savoir à quoi correspond une accolade fermante, un appui sur "%" me permet sous vi de remonter à l'instruction ouvrante, et un nouvel appui me remet là où j'étais. Avec des BEGIN/END, le vi standard n'offre pas cette fonctionnalité et avec vim, il faut activer un plugin et le reconfigurer à chaque fois, c'est juste trop lourd.

    et tous ces mots c'est l'IDE qui les écrit donc ce n'est pas une perte de temps du tout
    C'est surtout une perte de temps et une nuisance visuelle lors de la lecture et on lit et relit beaucoup plus de code qu'on en écrit.

    en plus le { a été prévu pour les claviers anglais ...
    Pas faux, quand j'ai commencé a faire du développement, je ne travaillais qu'avec des claviers US, et la transition vers l'azerty a été très douloureuse pour l'écriture de source, heureusement compensée par la possibilité d'écrire des mails et de la doc en français avec les accents, les cédilles, etc.

    Mais si on suit ton raisonnement, est-ce que tu écris les nombres en toutes lettres sous prétexte que les chiffres ont eux aussi été prévus pour les claviers anglais ?

    On est à peu près le seul pays au monde a avoir un clavier où les chiffres ne sont pas accessibles directement...
    ɹǝsn *sıɹɐlos*

  2. #182
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 353
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 353
    Points : 1 417
    Points
    1 417
    Par défaut
    j'ai lu avec grand intérêt les échanges des dernières pages, vraiment intéressant.

    Me concernant, ce qui me gène le plus quand je reprends un programme, c'est de comprendre la logique du code, pas vraiment la syntaxe.
    Il y en a qui ont vraiment l'esprit tordu et leur façon de faire marche peut-être mais pas de la façon la plus logique (et là je parle de Java ou de PL/SQL).

    J'ai repris récemment un vieux programme C++ que j'avais fait en 1995, et j'ai réussi à le modifier (j'avais tout oublié). Là encore j'ai plus été gêné par la structure de donnée que par la syntaxe. J'ai déjà analysé du pascal (avec algorithmes), ce n'était pas mieux, l'auteur était avec moi pour m'expliquer la logique, la syntaxe n'est vraiment qu'une petite partie du problème (dans un cas comme pascal vs C++).

    J'aimais bien le ADA mais le problème est de faire une UI ou de s'interfacer aux autres. Çà passe forcément par du C, tout le code qu'on voit sur internet sont en C ou C++. Dès lors qu'on importe les définitions, on est sûr de se planter à un moment et c'est hyper dure de voir l'erreur et on est tout seul dans ce cas.

    Généralement donc, le plus gros problème est un problème d'architecture, savoir évoluer sans s'affaiblir et çà c'est dans tous les langages.

  3. #183
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 150
    Points : 25 066
    Points
    25 066
    Par défaut
    Citation Envoyé par jlliagre Voir le message
    Mais si on suit ton raisonnement, est-ce que tu écris les nombres en toutes lettres sous prétexte que les chiffres ont eux aussi été prévus pour les claviers anglais ?
    On est à peu près le seul pays au monde a avoir un clavier où les chiffres ne sont pas accessibles directement...
    libre à toi de travailler avec un demi clavier, mais le mien y a un numpad à droite ...
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  4. #184
    Modérateur
    Avatar de jlliagre
    Homme Profil pro
    Ingénieur support avancé & développement
    Inscrit en
    Juin 2007
    Messages
    2 695
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur support avancé & développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 695
    Points : 7 882
    Points
    7 882
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    libre à toi de travailler avec un demi clavier, mais le mien y a un numpad à droite ...
    C'était une boutade, mais c'est vrai qu'il n'y a plus de pavé numérique sur la plupart des claviers que j'utilise depuis une vingtaine d'années, vu que ce sont des claviers de laptops.
    ɹǝsn *sıɹɐlos*

  5. #185
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Quand je suis passé du Pascal puis Ada au C, j'ai pas mal râlé après ces accolades. Et puis finalement, les habitudes changeant, c'est avec la verbosité excessive de ces langages que j'ai plus de mal aujourd'hui.
    d'ailleurs "ce qui se conçoit aisément s'énonce clairement "

  6. #186
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par thierryc Voir le message
    (.../...)Ce qui est terrible avec le F-35, alors que nos amis étasuniens ont toujours des ressources financières extraordinaires, c'est qu'ils ont choisi le langage en fonction du "pool" de développeurs au lieu de choisir le langage (et la méthode, etc) en fonction de leur besoins et d'ensuite former les équipes proprement. Des fois, je rêve de ce que j'aurais pu faire avec mon équipe d'alors avec de tels moyens...
    Ce ne sont pas les seuls. JAVA est partout pour le même genre de raisons.

    Ce que les RH ne comprennent pas, c'est que l'important, pour bien programmer, c'est d'avoir une tête bien faite. L'outil compte peu, finalement, pour peu qu'il ne soit pas scandaleux pour l'usage(j'ai fait des merveilles en COBOL, mais c'était de l'info de gestion. Pour, comme un membre de ma famille, calculer l'influence des planètes du système solaire sur les trajectoires de satellites, c'eut été un outil aussi inadapté qu'une scie à bois pour visser un meuble IKEA). D'ailleurs, les délais de formation que tu donnes pour tes programmeurs sont dérisoires, et je les crois réalistes. Pour toi, la difficulté, c'est de choisir la tête bien faite. Une fois que c'est fait, eh bien le plus dur est fait. Il n'y a plus qu'à.

    Je vais même aller encore plus loin, et me faire flamber par les puristes du salon. A mon sens, les écoles d'informatiques ne sont pas un bon moyen de devenir développeur informatique. Nous ne sommes pas dans un domaine figé de connaissances vastes et standard, comme en médecine. Nous sommes dans un domaine hautement fluide, ou l'information manquante se trouve facilement, ou les méthodes changent rapidement, et ou donc le corpus commun de savoir nécessaire est négligeable, comparé à la médecine. J'ai fait un séjour aux urgences, dans la nuit de dimanche à lundi. Hautement désagréable. Une fois qu'il a eu les éléments en main(analyse de sang et d'urine), le constat a été évident pour l'urgentiste : colique néphrétique(si vous ne savez pas ce que c'est, je vous conseille de rester dans l'ignorance). Il y a 100 ans, ça existait déjà, pour les mêmes raisons. Partout dans le monde, quelle que soit la période dans l'histoire, ce savoir est le même. L'informatique ne marche pas comme ça.

    J'ose prétendre que ce dont nous avons besoin, c'est de gens qui ont fait des maths, de la philo, de l'histoire(la vraie, celle ou on réfléchit aux causes, pas celle ou on apprend par cœur), de la littérature, de la physique, de la chimie, bref, toutes les matières nobles et généralistes qui forment l'esprit. J'aurait même envie d'y ajouter le latin, langue de la rigueur par excellence. Un peu de sociologie aussi, parce que l'informatique, c'est toujours fait par des gens pour des gens.

    Et le jour ou il arrive en entreprise, le Jeune Diplômé ne sait certes pas ce que c'est qu'un singleton, ou autres designs patterns. Mais il a appris à structurer sa pensée, et à peine mis au jus, il saura parfaitement quand il faut les utiliser...et quand il ne faut pas. En comparaison, le profil qui s'est tapé 5 ans de JAVA/javascript/angular en école sera peut-être immédiatement opérationnel, mais il sera en grande difficulté dès que la technologie changera, parce-que pour lui, la technologie est un but final, pas un simple outil. Il n'aura pas non plus la largesse d'esprit pour remettre son projet dans son contexte. La pureté technique sera, trop souvent, son seul horizon. Et il fera un programme à la mode, super joli, respectant tous les designs patterns à la mode, mais qui ne sert pas à grand chose. J'en ai trois sur le dos, en ce moment. Un Australien, un Allemand, un Bielorusse, tous formés à l'informatique pure, tous des dieux de la technique. Et qui sont infoutus de corriger des bugs qui m'empêchent de bosser. Et qui m'interdisent de mettre mon nez là-dedans parce-qu'ils ont peur de perdre la maitrise de leur précieux.

    C'est dans ce pool-là, en moins bons, que le DoD a recruté pour le F35. C'est ça qui les a plantés. Pas le choix du C/C++(même si peut-être on aurait pu trouver mieux). Mais leur obsession de prendre des gens qui "maitrisent le langage". Kennena'afout', de la maitrise du langage? Au pire, un ou deux experts pour les trucs exotiques. Tout le reste, ça doit être fait par des gens qui comprennent à qui sert leur code, à l'intérieur du programmer, à l'intérieur du projet, et dans sa globalité. Par exemple, un système d'armes aérien modernes a des contraintes IFF particulièrement tordues, mais nécessaires. être capables de comprendre ce que tactiquement représente le friendly fire ou le dommage collatéral, ça n'a rigoureusement rien d'informatique. C'est un mélange de philosophie et de bases du combats. Pourtant, ça impose des contraintes fortes, que le programmeur au courant sera capable de sublimer. Là ou le programmeur ignorant, même supérieur techniquement, sera incapable de retranscrire en langage informatique de manière satisfaisante. Alors même que lui, il est aux normes.

    Après, certains de ces écoles sortent capables de réflexion approfondie. On en croise pas mal en ces lieux, ici sur DVP, et je les salue. Mais si ils sont devenus capables d'une réflexion supérieure, c'est malgré le système, qui a tenté d'en faire de vulgaire supertechniciens, pas grâce à lui. De même que j'ai croisé des BAC-2 à la tête bien faite, et hautement capables.

    Joel Spolsky n'aime pas enseignement de JAVA dans les écoles d'informatiques parce-que d'après lui c'est trop facile, ce n'est pas assez sélectif. Je dirais que le mal est plus profond encore. Le simple fait d'enseigner toutes les arcanes d'un langage informatique, de bourrer le crâne de l'élève au lieu de l'entrainer à s'en sortir quel que soit l'outil à disposition est une aberration, qui a mené à sa perte bien plus que le projet F35. Le JAVA est super-populaire parce-que c'est un langage ou le médiocre de pensée peut briller en compensant en apprenant par cœur des foultitudes de spécificités sur les API disponibles. Et, jusqu'à un certain point, en JAVA, le travail brut et l'apprentissage par cœur peuvent faire la nique à l'intelligence et à la réflexion. Mais ça a ses limites. il y a toujours un moment ou il faudra être plus futé. Mais, en JAVA, ce moment arrive beaucoup plus tard - et les gens réellement futés qui bossent en JAVA ont beaucoup de mal à sortir du lot à cause de ça. Pourtant, c'est d'eux dont nous avons besoin en masse, pas des superspécialistes qui savent quelle API permet de passer l'aspirateur, et avec quelles performances.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #187
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 353
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 353
    Points : 1 417
    Points
    1 417
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Ce que les RH ne comprennent pas, c'est que l'important, pour bien programmer, c'est d'avoir une tête bien faite. L'outil compte peu, finalement, pour peu qu'il ne soit pas scandaleux pour l'usage(j'ai fait des merveilles en COBOL, mais c'était de l'info de gestion. Pour, comme un membre de ma famille, calculer l'influence des planètes du système solaire sur les trajectoires de satellites, c'eut été un outil aussi inadapté qu'une scie à bois pour visser un meuble IKEA). D'ailleurs, les délais de formation que tu donnes pour tes programmeurs sont dérisoires, et je les crois réalistes. Pour toi, la difficulté, c'est de choisir la tête bien faite. Une fois que c'est fait, eh bien le plus dur est fait. Il n'y a plus qu'à.
    ca s'appelle des gens consciencieux... Mais il faut quand même un minimum de connaissance en programmation pour joindre une boite de programmeurs. C'est pas le but de se trainer quelqu'un qui sait pas aligner une ligne de code mais qui va t'expliquer ce qu'il faut faire.

  8. #188
    Expert éminent Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    Mars 2014
    Messages
    1 760
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Mars 2014
    Messages : 1 760
    Points : 7 185
    Points
    7 185
    Par défaut
    Ca n'est pas mon job de coder. Je laisse cela à plus doué que moi. Mais.

    Lors de ma mission chez un client, il a fallu que je recrute sur le volet ceux qui sortent des sentiers battus, qui savent se sortir les tripes pour trouver comment faire mieux. J'ai donc commencé par faire un simple test où ils passaient en DevOps ne rédigeant chacun qu'une seul ligne. L'objectif étant de sécuriser au mieux une ligne que j'ai écrite en C. Le test a donné 19 brevets logiciels. L'implémentation sur un serveur audité a donné, de loin, le meilleur résultat. Depuis, le partage a fait que chacun a appris à coder sécurisé.

    Au milieu de la mission, Serge Dassault nous a contacté pour un travail que j'ai donné à faire aux élèves du MIT avec des explications sur comment faire. J'ai repris de ma propriété intellectuelle, une trentaine de lignes contenant 2 brevets, que je leur ai fourni à titre de cours. Ils ont mis 2 semaines environ à faire le job. Depuis, je suis agrégé en sécurité.

    Vers la fin de la mission, en lisant un chapitre d'un livre sur la partie réseau, j'ai demandé à ce qu'un job soit fait pour sécuriser. Il a fini par être fait il y a 3 semaines environ. Non seulement nous avons un PoC, mais nous avons le patch soumis et agréé par l'IETF mais pas par les agences des Etats-Unis qui veulent garder la faille ouverte.

    En conclusion, je ne serai jamais un pisseur de lignes de code ( ça ne m'intéresse pas ). Par contre, j'ai un esprit formé à la détection de failles. Pour cette raison je suis ingénieur d'études. Et que d'études; même si à l'occasion, coder me plaît. Donc, je suis de l'avis de el_slapper même si je rejoins ton point de vue epsilon68 jusqu'à un certain degré.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  9. #189
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 353
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 353
    Points : 1 417
    Points
    1 417
    Par défaut
    Citation Envoyé par marsupial Voir le message
    Ca n'est pas mon job de coder. Je laisse cela à plus doué que moi. Mais.
    ...
    Tout cela pour dire que je ne serai jamais un pisseur de lignes de code ( ça ne m'intéresse pas ). Par contre, j'ai un esprit formé à la détection de failles. Pour cette raison je suis ingénieur d'études. Et que d'études; même si à l'occasion, coder me plaît. Donc je suis de l'avis de el slapper même si je rejoins ton point de vue epsilon jusqu'à un certain degré.
    Chapeau ! c'est cool ce que tu fais.

    Cependant ton métier n'est pas programmeur, et (tous) les programmeurs ne sont pas des pisseurs de code, c'est horrible!

    Un programmeur consultant fait le cahier des charges avec le client, il crée des prototypes, il fait l'architecture, il développe, il teste, il trouve des bugs, il discute avec le client, il propose des idées etc.

  10. #190
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par jlliagre Voir le message
    Disons plutôt que c'est une opinion que tu ne partages pas.
    On ne peut pas généraliser sur l'activité principale présumée des développeurs. Il y a tellement de paramètres.
    Cf. http://appthem.com/ : ce n'est pas seulement mon opinion, c'est également l'opinion d'autres développeurs experts.
    C'est un temps "typiquement" constaté. Ou une moyenne...
    Il est vrai que sur certains projets, "legacy" par exemple, on va lire beaucoup plus que l'on va code, tandis que sur un projet neuf avec un sujet neuf où l'on ne peut pas réutiliser de librairies existantes, l'écriture va y être plus importante, de l'ordre de 20%, par exemple. On ne trouvera jamais de situation où le développeur en présence du source ne fait que coder, ou même passe la majorité de son temps à coder.

    A noter que ce ratio de 90%/10% ne s'applique qu'aux activités en présence du source et pas à toutes les autres activités du développeur qui sont nombreuses (et que les managers ont d'ailleurs tendance à oublier).

    Citation Envoyé par jlliagre Voir le message
    L'activité d'un développeur commence souvent par essayer de comprendre ce que le cahier des charges veut bien dire, puis à réfléchir à la meilleure manière d'y arriver, rechercher le code existant ou les bibliothèques qui pourraient être utilisés, prototyper, tester, profiler, analyser, dessiner, discuter, regarder ce qui se fait ailleurs, partager ce qu'on fait, synchroniser, intégrer, valider, documenter, expliquer, comparer, imaginer, inventer, ... C'est un métier passionnant le développement, il ne consiste pas à uniquement rédiger et lire des specs compilables.
    Je suis 100% d'accord avec toi. Des fois, le développeur tient la main du client pour écrire le cahier des charges...

    Les grands logiciels sont les cathédrales du XXIième siècle! C'est pour ces raisons que je me suis engagé dans ce métier.

    Citation Envoyé par jlliagre Voir le message
    Dans beaucoup de ces tâches, le code source intervient peu, mais je suis d'accord sur le fait que quand on a affaire à du source, c'est plus souvent pour en lire qu'en écrire.
    Nous sommes donc d'accord. Les grands esprits se rencontrent

    Citation Envoyé par jlliagre Voir le message
    Ça me parait un peu idyllique comme approche. Ton client ne va de toute façon pas de lire 100000 lignes de spécifications.
    C'est comme une représentation à l'Opera. Tout à l'air facile pendant la représentation, mais quel travail titanesque derrière. Pour arriver à convaincre la hiérarchie, pour élaborer les démonstrateurs, pour écrire les réponses à appel d'offres, pour choisir et former ses équipes, pour sélectionner les composants logiciels qui vont être réutilisés.
    Dans l'exemple, tout pouvait être lu par le client, mais il a lu ce qui l'intéressait et lui posait problème. J'ai du le former peut-être une demi-journée, si je me souviens bien, pour qu'il puisse lire le source, et nous avons également fait une revue formelle ensemble.

    Citation Envoyé par jlliagre Voir le message
    Ce sont souvent des erreurs faites essentiellement par des débutants. Le pascal est sûrement un bon langage pour enseigner la programmation, mais je trouve que sa verbosité est par la suite un handicap.
    C'est un peu comme les petites roues de stabilisation sur un vélo d'enfant. C'est très bien pour l'apprentissage, mais un jour, il faut les enlever.
    Nous sommes en désaccord sur ce point. Capers Jones et d'autres ont montré que la qualité du source et la productivité du développeur ne s'améliorent pas avec l'expérience, sauf exceptions (certains développeurs d'un type particulier). A noter que dans certains pays, 95% des développeurs sont inaptes au développement (cf. http://www.thehindubusinessline.com/...cle9652211.ece)

    Ce que je vois en audit, ce sont les mêmes erreurs répétées sans arrêt. Faute de formation, faute de temps, faute d'ingénieur qualité, faute de réflexion...
    D'ailleurs, nous avons des outils automatiques pour recenser une bonne part de ces erreurs. Cela nous permet d'identifier très rapidement les modules les plus mauvais dans un projet et cela a l'effet aussi de calmer l'équipe que de leur montrer qu'on sait exactement ce qu'elle a tenté de cacher. Et qu'on a trouvé en quelques heures.


    Citation Envoyé par jlliagre Voir le message
    Tu es libre de penser autrement, je te donne juste mon avis. La lisibilité est un facteur important sur l'évaluation que je porte sur les divers langages de programmation que j'ai pu côtoyer et utiliser professionnellement depuis trente-cinq ans, mais ce n'est pas le seul. Par exemple le C++ a beau reprendre beaucoup de la syntaxe du C, je n'ai jamais apprécié lire ou écrire du C++. Au contraire, la syntaxe de SmallTalk n'a rien à voir avec celle du C et j'ai pourtant, en 1986, été enthousiasmé par ce langage et son environnement.
    J'adore SmallTalk également, et tu as bien raison de mettre en exergue son environnement magnifique.
    Je partage évidemment ton avis sur C++, mais j'en tire les conclusions qui s'imposent. Crois ton instinct ...

    Citation Envoyé par jlliagre Voir le message
    Des clients non informaticiens qui lisent de l'ADA dans le texte, je demande à voir...
    Essaye...

    Il faut garder en tête les 3 principes:
    - on écrit en Anglais. Tous les éléments du projet doivent être bien nommés: les classes et les objets ont des noms en forme nominale, les fonctions et les procédures en forme verbale. Si la fonction ou la procédure est une commande (à effet de bord), la forme verbale est à l'indicatif. Si la fonction ou la procédure est une requête ("query", retour d'information sans effet de bord), la forme verbale se présente sous la forme d'une question. Il ne faut pas négliger les articles et autres pre- et post- positions de l'anglais courant. On n'oublie pas les pre- et post-conditions ainsi que les invariants de classe, ni les exceptions.
    - on écrit la spécification d'abord (chaque paquetage Ada possède une spécification et un corps) afin de bâtir une architecture et une conception. On écrit seulement par la suite les corps,
    - le cahier de recette peut être écrit en même temps, en Ada ou en Anglais, peu importe.
    Le tout est fréquemment relu entre membres de l'équipe et avec le client.

    Le résultat est très inhabituel pour un programmeur qui ne pratique pas cela, mais après une période d'adaptation, très efficace.

    Citation Envoyé par jlliagre Voir le message
    Si, ça me pose un problème. Je parle surtout ici de la rapidité de lecture, de l'« entropie» du code source, la proportion d'information non redondante, le rapport entre le poids total et la "charge utile" si tu préfères.
    Je comprends ce que tu veux dire. Mais l'information n'est pas redondante, elle est structurée pour au contraire faciliter ta lecture. Comme dans un livre où tu vois régulièrement "Chapitre 1 ... Chapitre 2 ... Chapitre 3"

    Par ailleurs, j'utilise le mot "entropie" comme un analogue de la "dette technique". Je trouve que le concept de "dette technique" est très bien, mais que l'analogie est trop financière. L'entropie du logiciel est un concept que les équipes comprennent très bien. On le leur montre quand on fait des audits.

    Citation Envoyé par jlliagre Voir le message
    En cherchant des projets similaires, je suis tombé sur Lookheed Martin qui a développé l'informatique embarquée de la navette spatiale. Il s'agit de 420000 lignes écrites en ADA, donc du même ordre de grandeur que ton projet de 100000 lignes exécutables, d'autant plus qu'eux, ils ne devaient pas lésiner sur les commentaires.
    Je te remercie énormément pour la référence, mais dans ce cas précis, je n'ai pas du tout visé le même niveau de démonstrabilité. Nos ambitions étaient beaucoup plus modestes et notre capacité de réutilisation bien plus importante. C'est pourquoi j'avais écrit dans mon précédent post "non-critique". Sur un logiciel critique, chaque ligne ou même morceau de ligne doit être justifié et tracé. Monter le dossier de démonstration est une charge énorme. Nous n'avons heureusement pas eu à le faire. Nous étions trois sur le projet, dont un technicien. Et le client n'a pas du tout payé le même montant.

    Par ailleurs, je n'ai pas l'URL en tête, mais les développements sur la capsule Apollo sont remarquables aussi. Encore une génération d'avant. Et avec des concepts très avancés pour l'époque.

    Citation Envoyé par jlliagre Voir le message
    Je roule dans la vraie vie. Une Ferrari, c'est bien pour frimer à Monte-Carlo mais dans les bouchons parisiens, c'est pas forcément la meilleure solution et pour ce qui est de foncer, méfie-toi ! Je viens de me faire flasher et perdre un point, comme quoi une Twingo, ça peut aussi être surdimensionné...
    Tu as raison, mon analogie est limitée, je pensais à la vélocité du développement. Une autre analogie pourrait être de comparer un petit véhicule utilitaire type Kangoo avec un 38 tonnes bien motorisé...Dans tous les cas, on déplace du volume.

    Citation Envoyé par jlliagre Voir le message
    En plus, si je me pose la question de savoir à quoi correspond une accolade fermante, un appui sur "%" me permet sous vi de remonter à l'instruction ouvrante, et un nouvel appui me remet là où j'étais. Avec des BEGIN/END, le vi standard n'offre pas cette fonctionnalité et avec vim, il faut activer un plugin et le reconfigurer à chaque fois, c'est juste trop lourd.
    J'ai ça dans mon environnement. J'ai aussi un petit "-" ou un petit "+" pour cacher ou afficher une opération ou une classe toute entière. et un raccourci pour créer des "begin/end" automatiquement (et aussi des if...then...else, etc.), comme tout le monde. Ce n'est pas parce qu'on utilise un langage moins connu qu'on n'a pas toutes les facilités d'écriture. et l'environnement colorise les différents éléments en fonction de leur type. Très lisible.

    Bien cordialement,
    Thierryc

  11. #191
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2017
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2017
    Messages : 36
    Points : 95
    Points
    95
    Par défaut
    Citation Envoyé par thierryc Voir le message
    alors que c'est moi qui défends la multiplicité des outils et des techniques.
    Citation Envoyé par thierryc Voir le message
    C/C++/Java ne sont que des outils, et ce sont des mauvais outils.
    Bon là il y a quand même manifestement une contradiction entre les phrases non ?

    Citation Envoyé par thierryc Voir le message
    Stroustrup lui-même l'admet.
    Non. Stroustrup admet que C++ n'est pas parfait, ce n'est pas la même chose.

    Citation Envoyé par thierryc Voir le message
    Très peu de formations modernes enseignent la rédaction de cahier des charges, le travail réel avec le client, l'estimation raisonnable de projets au forfait, et la priorité accordée aux besoins du client, et pas à l'emploi d'un outil défectueux.
    Tout à fait d'accord. Mais je trouve ne pense pas pour autant que cette formation nécessaire doive être prise en charge par les écoles d'ingé et les universités, ce n'est pas (selon moi) leur rôle, et elles en sont de toute façon bien incapables. Pour moi c'est aux entreprises de former ses employés dans ces domaines.

    Citation Envoyé par Madmac Voir le message
    Mais il a pris. Il est connu sous l'acronyme de WWW. Il n'est pas nécessaire d'avoir le OS pour essayer le langage. Vous n'avez qu'à le télécharger pour l'essayer. Ce n'est pas qu'un langage d'ordinateur, mais également un langage de réseau qui permet de faire les tâches qui demandent les "Sockets", mais sous une forme plus abstraite. Toute les idées qui ont développé à partir de ce langage ont été repris sous une forme ou une autre, cela passe de l'hyperlien jusqu'à Appletalk (interéchange par système évènementiel).
    (aussi à propos d'Oberon OS)
    Citation Envoyé par thierryc Voir le message
    J'ai déjà répondu à l'argument de popularité ou d'utilisation dans un post ci-dessus.
    OK, ne parlons pas de popularité. Maintenant concrètement, lorsque vous répondez à cette discussion, tous les deux, vous utilisez quel OS ? Si ce n'est pas Oberon, c'est bien que ce n'est pas un OS qui correspond à vos besoins non ? (Et si c'est oui, promis, je regarde sérieusement ce qu'est Oberon OS )

    Citation Envoyé par thierryc Voir le message
    Ceci dit, sérieusement, Niklaus était très en avance sur son époque.
    Je ne veux pas nier l'importance des contributions de Wirth à la programmation. Mais je ne pense pas qu'il faille dire pour autant que Oberon OS est à utiliser maintenant. Exemple similaire: Dijkstra et THE OS. Il y avait certainement plein de bonnes idées dans cet OS, mais c'était un essai de recherche, pas un programme destiner à durer.

    Citation Envoyé par thierryc Voir le message
    Je n'ai jamais vu de programme C++ rendre de la performance à de l'Ada ou du Pascal, dès lors que la conception est bien faite. Chaque compilateur optimise de lui-même et "inline" les fonctions qui peuvent l'être.
    J'ai du mal à y croire. C'est la première fois que j'entends que Pascal peut concurrencer le C niveau perfo. Je ne suis pas un expert Pascal mais il me semble que pour écrire un code optimisé bas-niveau, il faut faire sauter pas mal de sécurités qui n'existent pas vraiment en C. Donc c'est sans doute possible en théorie, mais ça n'est pas fait pour ça.

    Citation Envoyé par thierryc Voir le message
    Ce que Stepanov a fait il y a longtemps ne paraît pas très pertinent dans ce cas-ci.
    Affaire à suivre. Si j'ai le temps, je programme un tri rapide en C++ et en Ada (ce qui me permettra de m'y mettre) et je vous rapporte ici même les résultats.

    Citation Envoyé par thierryc Voir le message
    Concernant la gestion fine des données, il me semble bien que c'est l'inverse et que c'est Ada qui fournit une gestion très fine des accès jusqu'au bit. Il a été conçu pour cela.
    Sur un PC moderne cela n'a aucune importance niveau performance puisque les accès mémoire se font au minimum à l'octet. Et gérer la mémoire ne se résume pas à cela.

    Citation Envoyé par thierryc Voir le message
    Cf. un autre post plus haut qui répond à cela bien mieux que je ne saurais le faire. Et je n'ai jamais écrit sur Python.
    Votre phrase mentionne les langages de programmation, c'est pour cela que je prenais Python comme exemple. Je voulais juste dire que tous les langages ne sont pas égaux en terme de performance, pour un même algorithme: par exemple, Python/Perl/Ruby/Bash sera plus lent que C/C++/Fortran/Java/Ada.



    Citation Envoyé par thierryc Voir le message
    Par ailleurs, avec cet argument, il vaut mieux développer en assembleur, car avec cet outil-là, on a vraiment le contrôle total sur les pointeurs. LOL.
    Je ne suis pas d'accord. L'assembleur ne connaît pas les pointeurs. Les pointeurs sont une abstraction sur les adresses d'objet typés. Ce ne sont pas des abstractions "sûres", mais ce sont néanmoins des abstractions.

    Citation Envoyé par thierryc Voir le message
    Réponse: une catastrophe pour la lisibilité, et un défaut potentiel un peu plus tard dans le développement.
    Cela veut donc dire que <algorithm> de la STL doit être considéré comme une abomination. Il me semble pourtant qu'il s'agit d'un exemple (rare je le concède) de bonne utilisation des pointeurs et d'arithmétique de pointeur.


    Citation Envoyé par Luc Hermitte Voir le message
    Stepanov semble dire qu'il est parti vers le C++ parce qu'il ne croyait pas en la percée d'Ada et qu'il voulait pouvoir gérer la mémoire finement, allocations comprises (dixit wikipédia). Dans mes souvenirs d'Ada (83?) il n'y avait pas d'arithmétique des pointeurs (chose que je savais émuler en Pascal). Si on regarde comment les algorithmes standards sont écrits, il n'a fait que généraliser (d'un point de vue syntaxe) les algos de la libc et en introduire d'autres. Son livre Elements of Programming est très intéressant.
    C'est également ce que j'avais compris. Il a des vidéos très intéressantes sur Youtube si le livre est trop difficile d'accès.

    Citation Envoyé par Luc Hermitte Voir le message
    Concernant l'arithmétique des pointeurs, sa pertinence dépend des générations de compilateurs. Aujourd'hui, l'accès indexé semble plus recommandable. Parfois utile, mais non indispensable.
    Je suis d'accord. Même si sans mon expérience, les perfo sont similaires dans la plupart des cas (je ne sais pas ce que vous en pensez ?). L'avantage des pointeurs est qu'ils sont des itérateurs (et donc plus facilement utilisables dans un contexte d'algorithmes génériques). Et l'accès indexé est parfois plus naturel. J'utilise les deux en fonction des cas.

  12. #192
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2017
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2017
    Messages : 36
    Points : 95
    Points
    95
    Par défaut
    Citation Envoyé par jlliagre Voir le message
    Ça me parait un peu idyllique comme approche. Ton client ne va de toute façon pas de lire 100000 lignes de spécifications.
    Je me suis fais la même réflexion. Mais justement comme vous nous dites que vous y arrivez. Cela mériterait que vous nous donniez plus de détails. Que lit le client : tout le code, certaines parties... ? Est-ce tous les clients ? Le lisent-ils seuls ou avec votre aide ?

  13. #193
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2017
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2017
    Messages : 36
    Points : 95
    Points
    95
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    A mon sens, les écoles d'informatiques ne sont pas un bon moyen de devenir développeur informatique. Nous ne sommes pas dans un domaine figé de connaissances vastes et standard, comme en médecine. Nous sommes dans un domaine hautement fluide, ou l'information manquante se trouve facilement, ou les méthodes changent rapidement, et ou donc le corpus commun de savoir nécessaire est négligeable, comparé à la médecine.
    Je suis assez d'accord avec vous. Après, je ne pense pas que le corpus soit négligeable. Le problème, ça serait plutôt que l'on se mette d'accord sur ce corpus.
    Tout ne change pas non plus si vite: niveau programmation, on fait toujours des branches, des boucles et des opérations; on a toujours une architecture de Von Neumann depuis 1945 et pour quelques années encore.

    Il ne faut pas croire non plus que la médecine soit complètement figée, et pourtant la question de savoir si on doit enseigner la médecine aux futurs médecins ne se pose même pas.

    Pour continuer le parallèle avec la médecine, le problème de certaines formations aujourd'hui, c'est comme si on disait au futur médecin : si symptôme A, médicament 1, symptôme B, médicament 2. Alors que l'approche correcte serait plus de comprendre quelle est la cause du symptôme pour avoir une idée de comment agir sur la résolution.

  14. #194
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2006
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 376
    Points : 3 583
    Points
    3 583
    Par défaut
    Sinon, je me suis remis au Locomotive BASIC 1.0 sur Amstrad CPC, à l'occasion du BASIC 10 LINER Contest 2018

    http://gkanold.wixsite.com/homeputer...-10liners-2018
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  15. #195
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par _Bérenger_ Voir le message
    Bon là il y a quand même manifestement une contradiction entre les phrases non ?
    Non, L'outil de développement est un outil, mais il est très important dans toute la chaine de fabrication de logiciel. J'ai expliqué pourquoi ailleurs.
    C/C++/Java, dans cette chaîne, est un goulet d'étranglement...

    Citation Envoyé par _Bérenger_ Voir le message
    Non. Stroustrup admet que C++ n'est pas parfait, ce n'est pas la même chose.
    En tant que directeur de projet, je frémis quand je lis cette phrase : quels sont les risques que courent mes projets? Quel impact sur mes délais, mes coûts, le "turnover" de mes équipes.
    En tant que développeur, je préfère utiliser des outils qui me mettent en sécurité plutôt que des outils qui me mettent en danger.

    Citation Envoyé par _Bérenger_ Voir le message
    Tout à fait d'accord. Mais je trouve ne pense pas pour autant que cette formation nécessaire doive être prise en charge par les écoles d'ingé et les universités, ce n'est pas (selon moi) leur rôle, et elles en sont de toute façon bien incapables. Pour moi c'est aux entreprises de former ses employés dans ces domaines.
    C'est une partie intrinsèque du métier (cf. le SWEBOK, https://www.computer.org/web/swebok/index). Je suis d'accord avec toi que les universités sont actuellement incapables d'enseigner ces disciplines indispensables. En revanche, j'ai connu un IUT qui formaient des techniciens en informatique à ces disciplines. J'en ai embauché plusieurs. Et je les ai formés et suivis jusqu'à ce qu'ils deviennent des ingénieurs. Malheureusement, je ne sais pas si cette formation existe toujours.

    Citation Envoyé par _Bérenger_ Voir le message
    Je ne veux pas nier l'importance des contributions de Wirth à la programmation. Mais je ne pense pas qu'il faille dire pour autant que Oberon OS est à utiliser maintenant.
    Il existe des entreprises en Allemagne qui développent des logiciels pour gérer des robots avec Oberon OS. Il faut admettre que c'est très confidentiel. En revanche, développer en Ada ou en Pascal sur à peu près n'importe quelle plateforme est possible.

    Citation Envoyé par _Bérenger_ Voir le message
    J'ai du mal à y croire. C'est la première fois que j'entends que Pascal peut concurrencer le C niveau perfo. Je ne suis pas un expert Pascal mais il me semble que pour écrire un code optimisé bas-niveau, il faut faire sauter pas mal de sécurités qui n'existent pas vraiment en C. Donc c'est sans doute possible en théorie, mais ça n'est pas fait pour ça.
    C'est le contraire qui se produit. Par exemple, la gestion des chaines de caractères est automatiquement optimisé par le compilateur Pascal. Le développeur n'y voit rien, mais son code est optimal. Par rapport à du C de base, il n'y a pas photo.
    Idem pour Ada. Tous les compilateurs modernes Ada et Pascal optimisent sévèrement. Suivants les projets, on est à 10% de perfos en plus ou en moins par rapport à du C/C++ optimisé "à la main". Je ne parle pas de Java, il est hors compétition.

    En revanche, en compilation, et lors des full build, la performance est clairement du côté du Pascal et de l'Ada qui compilent très très vite, en une seule passe. Sur un projet de taille normale, disons 1 à 4 millions de lignes de code, Pascal compile 1000x plus vite que C++ sur un full build ... Le problème en C++ vient 1°) des dépendances cycliques, 2°) des entêtes .h et 3°) de la complexité de la syntaxe et de la grammaire du langage. Il faut se souvenir que Pascal et Ada ont été conçus pour être très facilement compilables.

    Citation Envoyé par _Bérenger_ Voir le message
    Affaire à suivre. Si j'ai le temps, je programme un tri rapide en C++ et en Ada (ce qui me permettra de m'y mettre) et je vous rapporte ici même les résultats.
    Très bonne idée. Étant néophyte en Ada, si tu as des soucis, prends contact avec J.P. Rosen. C'est la meilleure personne pour t'aider.

    Citation Envoyé par _Bérenger_ Voir le message
    Sur un PC moderne cela n'a aucune importance niveau performance puisque les accès mémoire se font au minimum à l'octet. Et gérer la mémoire ne se résume pas à cela.
    Bien entendu, ce n'est qu'une toute petite partie des possibilités d'Ada.

    Citation Envoyé par _Bérenger_ Voir le message
    Votre phrase mentionne les langages de programmation, c'est pour cela que je prenais Python comme exemple. Je voulais juste dire que tous les langages ne sont pas égaux en terme de performance, pour un même algorithme: par exemple, Python/Perl/Ruby/Bash sera plus lent que C/C++/Fortran/Java/Ada.
    100% d'accord. J'ajoute que comme j'utilise un langage qui compile très très vite, je n'ai personnellement aucun intérêt à l'usage d'un langage interprété... sauf bash, mais là, je fais de l'administration système.

    Citation Envoyé par _Bérenger_ Voir le message
    Je ne suis pas d'accord. L'assembleur ne connaît pas les pointeurs. Les pointeurs sont une abstraction sur les adresses d'objet typés. Ce ne sont pas des abstractions "sûres", mais ce sont néanmoins des abstractions.
    Je ne compte plus la quantité de "void *" que j'ai vu dans les projets C/C++. Cela n'est en rien différent d'une adresse assembleur.
    En Pascal et en Ada, sauf nécessité, nous n'utilisons plus l'abstraction de pointeur, mais l'abstraction d'objet.

    Citation Envoyé par _Bérenger_ Voir le message
    Cela veut donc dire que <algorithm> de la STL doit être considéré comme une abomination. Il me semble pourtant qu'il s'agit d'un exemple (rare je le concède) de bonne utilisation des pointeurs et d'arithmétique de pointeur.
    C'est vrai, autant utiliser la STL si on le peux, c'est une bonne librairie.

    Citation Envoyé par _Bérenger_ Voir le message
    Je suis d'accord. Même si sans mon expérience, les perfo sont similaires dans la plupart des cas (je ne sais pas ce que vous en pensez ?). L'avantage des pointeurs est qu'ils sont des itérateurs (et donc plus facilement utilisables dans un contexte d'algorithmes génériques). Et l'accès indexé est parfois plus naturel. J'utilise les deux en fonction des cas.
    Il existe aussi des itérateurs sur des objets en Pascal et en Ada. Le pointeur est inutile pour implémenter des itérateurs.

    Bien cordialement,
    Thierryc

  16. #196
    Membre émérite Avatar de SofEvans
    Homme Profil pro
    Développeur C
    Inscrit en
    Mars 2009
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C

    Informations forums :
    Inscription : Mars 2009
    Messages : 1 076
    Points : 2 327
    Points
    2 327
    Par défaut
    Citation Envoyé par thierryc Voir le message
    C'est le contraire qui se produit. Par exemple, la gestion des chaines de caractères est automatiquement optimisé par le compilateur Pascal. Le développeur n'y voit rien, mais son code est optimal. Par rapport à du C de base, il n'y a pas photo.
    Je commence doucement à en avoir marre de vous voir balancer des affirmations aussi affligeante les unes que les autres ...
    Vous prêchez votre paroisse en vous envoyant des fleurs depuis le début tout en essayant de rabaisser autant que possible tout les autres langages et en vous imposant comme un guide suprême.

    La seule optimisation possible que je vois, c'est que la taille d'une string en Pascal est stocké dans la chaîne (indice 0).
    Et cela limite les possibilité d'utilisation : Que se passe-t-il quand je dois avoir plus de 255 caractère ? Ben on doit utiliser un tableau de char qui se termine par '\0'.
    Oh, ça alors ! Comme en C ! (ou "Comme en Pascal !" ?)
    (Et personnellement, j'ai plus souvent à faire avec des chaînes dont la longueur total est inconnue qu'à des chaînes dont je sais que la taille ne peux être supérieur à 255. Mais ça reste personnel).

    Donc si je comprends bien, le fait que le C soit si lent, c'est parce qu'il n'existe pas de type string "court" ?
    Vous en avez d'autre comme ça ?
    Pour terminer, essayer -03 (ou -02 si vous voulez la sécurité) avec gcc ... Oui, les compilateurs C optimise le code aussi.

  17. #197
    Expert confirmé Avatar de sergio_is_back
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    Juin 2004
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 076
    Points : 5 541
    Points
    5 541
    Par défaut
    Citation Envoyé par SofEvans Voir le message
    Je commence doucement à en avoir marre de vous voir balancer des affirmations aussi affligeante les unes que les autres ...
    Vous prêchez votre paroisse en vous envoyant des fleurs depuis le début tout en essayant de rabaisser autant que possible tout les autres langages et en vous imposant comme un guide suprême.

    La seule optimisation possible que je vois, c'est que la taille d'une string en Pascal est stocké dans la chaîne (indice 0).
    Et cela limite les possibilité d'utilisation : Que se passe-t-il quand je dois avoir plus de 255 caractère ? Ben on doit utiliser un tableau de char qui se termine par '\0'.
    Oh, ça alors ! Comme en C ! (ou "Comme en Pascal !" ?)
    (Et personnellement, j'ai plus souvent à faire avec des chaînes dont la longueur total est inconnue qu'à des chaînes dont je sais que la taille ne peux être supérieur à 255. Mais ça reste personnel).

    Donc si je comprends bien, le fait que le C soit si lent, c'est parce qu'il n'existe pas de type string "court" ?
    Vous en avez d'autre comme ça ?
    Pour terminer, essayer -03 (ou -02 si vous voulez la sécurité) avec gcc ... Oui, les compilateurs C optimise le code aussi.
    Il existe plusieurs types de chaines en Pascal, le langage a bien évolué depuis ces débuts.
    Effectivement historiquement les chaînes (string) étaient limités à 255 octets
    ce n'est plus la cas actuellement. Le type string originel a été remplacé par "shortstring" et
    un nouveau type string a fait son apparition qui est seulement limité par la mémoire disponible... (Et ça date de vieux au point que je m'en souvient pas)

    Pour les chaines à zéro terminal comme en C (ou en C++) on utilisera un type PChar (si c'est de l'unicode) ou un type PAnsichar (1 octet par caractère)
    Ton type PChar ou PAnsiChar sera dimensionné comme en C avec X caractères + 1 pour le \0

    PChar et PAnsichar sont l'équivalent de char * xxx en C

    On peut aussi utiliser un array of char (ou array of ansichar) soit statique soit dynamique (équivalent de char ddd[X])

    Il est possible de transtyper un string en Pchar ou inversement(avec xx=Pchar(str) par exemple)

  18. #198
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 353
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 353
    Points : 1 417
    Points
    1 417
    Par défaut
    @Thierryc, avez-vous déjà audité des logiciels ADA et Pascal?
    quels points auditez-vous?
    Quelle méthodologie utilisez-vous?

    Concernant le C++, est-ce que vous vous concentrez uniquement sur la syntaxe, du type si vous voyez un pointer alors c'est mal?

  19. #199
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    J'ai peur que SofEvans ait une connaissance plus qu'obsolète du pascal, ou de l'Ada, comme le montre son post. C'est très fréquent chez les ayatollah du C/C++. Là où je parle de ce que je sais, ayant développé de très gros logiciels à la fois en Pascal, en Ada, en C++, en Java et encore d'autres langages et me tenant à jour des évolutions de ces langages, les thuriféraires du C++ sont bien ignorants et restent coincés dans l'espace-temps autour de 1970. CQFD.

    Aujourd'hui, les chaînes de caractères ont par défaut un compteur de références et une copie de chaine ne coûte rien. Lorqu'une nouvelle chaine doit être créée en modifiant une chaine existante, c'est fait au dernier moment possible. La taille des chaines Pascal peut dépasser les 2 GB si nécesaire.

    Et un post plus haut indique bien que le compilateur Pascal, ou l'Ada, optimise tout le code. L'exemple des chaines de caractères n'est qu'un exemple. Il faut vraiment lire de travers pour comprendre autrement, et prendre les gens qui lisent ces posts pour des billes pour recommander -o2 ou -o3. (A propos, ces options sont interdites lorsqu'il faut produire du code sûr de fonctionnement. Ça n'aide pas pour la perfo...)

    Je vous invite à regarder le webinar suivant:
    https://community.embarcadero.com/al...-linux-cluster
    vous verrez bien qu'il n'y a aucune difficulté particulière, bien au contraire, à faire du calcul à hautes performances en Pascal.
    Ada possède les mêmes propriétés.

    Bien cordialement,

  20. #200
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 353
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 353
    Points : 1 417
    Points
    1 417
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Aujourd'hui, les chaînes de caractères ont par défaut un compteur de références et une copie de chaine ne coûte rien. Lorqu'une nouvelle chaine doit être créée en modifiant une chaine existante, c'est fait au dernier moment possible. La taille des chaines Pascal peut dépasser les 2 GB si nécesaire
    La spécification de C++11 l'interdit.

Discussions similaires

  1. Pourquoi les langages interprétés sont-ils préférés pour l'analyse de données ?
    Par User23 dans le forum Statistiques, Data Mining et Data Science
    Réponses: 1
    Dernier message: 12/05/2016, 22h18
  2. Les langages statiques sont-ils trop sophistiqués et complexes ?
    Par Katleen Erna dans le forum Actualités
    Réponses: 53
    Dernier message: 20/01/2013, 11h06
  3. Réponses: 2
    Dernier message: 11/05/2010, 20h36
  4. Réponses: 2
    Dernier message: 06/05/2007, 23h37
  5. Pourquoi les mails ne sont ils pas envoyés?
    Par Sunsawe dans le forum Développement
    Réponses: 3
    Dernier message: 13/04/2007, 00h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo