Discussion :

[gorgonite]

Bonjour à tous,

Je vous propose de vous exprimer ici au sujet des critères à respecter pour concevoir et coder des programmes "rigoureux"... histoire de sortir du train quotidien des hello world, ou des projets où le langage n'est pas important tant qu'il est orienté-objet plein de webservices

Pour cela, il me semble utile d'orienter cette discussion sur des axes tels que :

• la rigueur du codage employée
• le choix d'un sous-ensemble d'un langage
• la rigueur d'un système de type
• les possibilités de vérification formelle
• les contraintes "incompressibles" de certains systèmes embarqués et/ou temps réel

cette liste n'est pas exhaustive bien évidemment...

à tous les participants


Attention

1. à moins que vous ne demandiez de plus amples explications sur un point précis, poster dans cette discussion est strictement réservé aux personnes qui estiment avoir une expertise ou une expérience intéressante à partager
2. tous les propos HS (même techniques) seront supprimées

[Mac LAK]

Ada est un langage qui :

• A été le premier langage objet normé,
• Est une référence en matière de code sécuritaire tout en supportant les contraintes temps réel,
• Permet de faire de la programmation parallèle même si l'OS ne le supporte pas nativement,
• Implémentait la généricité bien avant C++ et les langages managés,
• Possède une syntaxe non ambigüe,
• Peut permettre la preuve formelle,
• Te permet aussi d'avoir des processeurs complexes dignes de ce nom (VHDL),
• Est plus connu (et plus utilisé) que quelques "beaux" langages sortant finalement assez peu des labos ou niches restreintes.

[jabbounet]

Pour trouver un language qui est strict je rejoins certains il faut aller du coté de l'ada (j'ai pratiqué l'ada 83 a un moment). il inclu le multitache dans sa syntaxe, il a un typage strict des données, il n'est pas tres eloigné de l'objet que l'on retrouve probablement dans les versions suivante (ada 95,...) et il a une syntaxe claire et lisible.

[Mac LAK]

Selon moi, un GC, c'est la porte ouverte au je-m'en-foutisme sur la libération mémoire, et la notion de pointeur reste importante quoi que l'on dise : il est fondamental de comprendre ce que c'est, même si c'est pour éviter de l'utiliser derrière (en fonction de ses goûts personnels et de ce que l'on veut faire en programmation bien sûr).

[alex_pi]

Je ne comprends pas... D'un coté, tu es contre le GC parce que ça inciterait à trop se reposer sur la machine, mais de l'autre, tu veux du typage statique. Ca n'insiterait pas à ne pas réfléchir et à juste faire confiance au typeur ?


Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que ça me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention à la gestion des ressources"..

Et en plus, ça interdira un paquet d'algorithme ou de paradigme parce qu'il n'arrivera pas à faire une gestion manuelle de la mémoire là dessus. Est ce que devoir avoir compris les magic pointeur avant de coder est vraiment indispensable...

[jabbounet]

Ce n'est pas tout de faire de l'algorithme, il faut aussi comprendre comment marche la machine et l'os qui est dessus, sinon on risque de faire de choses qui vont heurter son fonctionnement normal et au final avoir des trucs qui rament.

sans compter que c'est un peu l'usine pour faire ton programme tu te retrouve vite a assembler un tas de composants (avec tout un tas d'acronyme ejb, struts, spring, jboss, pojo....) bref il faut s'acheter un dictionnaire français/java pour savoir ce que l'on fait. et ensuite tu te rend parfois compte que tu aurais été plus vite en le codant toi même et que cela aurai mieux répondu a ton besoin et ce surtout si tu débute ou l'on te confie des truc simple au début

Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que ça me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention à la gestion des ressources"..

beaucoup de programmeur codent comme de cochons, mais j'en connais quelque uns (dont moi) qui n'acceptent pas de considérer que le programme est valide s'il subsiste un leak dessus surtout en C/C++.

Ceci dit ce n'est surtout pas parce que tu as un GC que tu ne dois pas t'occuper de ta mémoire, ce serait un erreur. j'ai déjà eu des soucis de memoire avec des programme java de gens oubliant de dereferencér des objets (mem-leak) ou des personnes se retrouvant a dé-référencer trop tôt des objets et avoir un tas de nullpointer exeption (free).....

L'idée que l'on a pas a s'occuper de la mémoire en java est selon moi un peu fausse.

[Mac LAK]

Je ne comprends pas... D'un coté, tu es contre le GC parce que ça inciterait à trop se reposer sur la machine, mais de l'autre, tu veux du typage statique.

Le typage statique demande un minimum de réflexion de la part du développeur... Et plus il est strict, plus il doit réfléchir.

Ca n'insiterait pas à ne pas réfléchir et à juste faire confiance au typeur ?

Justement : c'est un échec à la compilation, et non pas à l'exécution, qui se produit avec un typage statique... Les erreurs de typage dynamique sont en général assez infectes à lever, et dans le pire des cas on a un débutant qui ne comprends même pas la différence entre un nombre (variable entière) et sa représentation textuelle (variable chaîne contenant la représentations ASCII du nombre en question)...

La plupart des langages ont un GC "global" au programme, c'est à dire que l'allocation se fait dans une zone réservée par le runtime... Une fuite mémoire peut exister, certes, mais sans mettre en péril le système d'exploitation. Ce n'est pas "propre", certes, mais c'est un moindre mal.

De l'autre côté, il y a de bonnes habitudes, parmi lesquelles on a :

• Documenter son code,
• Le tester un minimum sérieusement,
• Savoir à l'avance ce que l'on va faire, et non pas "bidouiller" en avançant à tâtons,
• Vérifier la libération de ce que l'on a alloué.

Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que ça me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention à la gestion des ressources"..

C'est un fait.
Moi aussi, je connais hélas trop cette situation...

Et en plus, ça interdira un paquet d'algorithme ou de paradigme parce qu'il n'arrivera pas à faire une gestion manuelle de la mémoire là dessus.

Lesquels ? L'algorithmique, ça s'apprend par le commencement, pas par la fin... Tu arrives à accepter, toi, qu'un stagiaire passe une heure à trouver une librairie pour faire un tri au lieu de l'implémenter lui-même ? Surtout quand ça porte à l'origine sur un tableau d'une vingtaine d'éléments, trié une seule fois ?

Est ce que devoir avoir compris les magic pointeur avant de coder est vraiement indispensable...

Utiliser les "smart pointers" est néfaste en soi pour un débutant, car cela le fait ignorer un mécanisme crucial qui n'existera pas toujours sur les plate-formes qu'il sera amené à utiliser. L'embarqué se porte bien, très bien même... Et là dessus, tu as rarement une usine à gaz type JRE pesant plus lourd que la capacité mémoire disponible pour faire n'importe quoi n'importe comment... Et de toutes façons, les performances exigées mettent hors concours tout ce qui n'est pas langage compilé natif.

Or, à force d'apprendre le développement "façon assisté", tu vois de moins en moins de développeurs réellement compétents dès qu'il s'agit de développement bas niveau, temps réel ou embarqué... Certes, ils savent faire de belles IHM en Java et ouvrir tout plein de communications TCP/IP en même temps, ou se connecter à une BDD. Mais ils sont pas foutus de faire un système d'acquisition temps réel, un driver ou un module exigeant des performances sévères.

[alex_pi]

Personnellement, j'ai commencé par caml, qui dans la catégorie "langage de haut niveau", ça écrase largement java.

Son typage m'a donné un paquet de bonnes habitudes comme éviter d'être tenté toutes les deux minutes de faire des casts ultra sordide, ou encore m'inciter à utiliser les rares possibilités offerte par le système de type des autres langages.
Et le fait que ce soit "haut niveau" m'a habitué à d'abord penser aux algorithmes, à leur complexité, à la qualité des structures de données, etc, avant de me demander si je vais pouvoir échanger le contenu de deux variables en 2 ou 3 instructions comme je vois tellement de débutant en C faire sur ce forum (et de moins débutants), ou comment optimiser le prélude d'une boucle au lieu de m'intéresser à son corps.

[alex_pi]

En outre, "langage de haut niveau" ne veux pas dire performance catastrophique ! Il faut arrêter avec ça...
regardons http://shootout.alioth.debian.org/u6...lang=all&box=1 . Ok ce sont des benchs qui ne veulent pas nécessairement dire grand chose, mais en gros quand même, on se retrouve avec des langages de "haut niveau" voir très haut niveau comme Haskell ou OCaml qui ont des perfs de l'ordre de 1,5 à 2,5 fois plus lent que C. Ca veut dire en gros que sur un proc actuel, on a les perfs d'un proc d'il y a un an, deux peut être (si on ne parle que de performance, ce qui est assez absurde)? Je n'ai pas l'impression que ce soit si "catastrophique" que ça.

Tu nous dis que ça élimine tout une palanqué de domaine où, si je comprends bien, il faudrait tout gérer à la paluche pour avoir la moindre chance d'obtenir un résultat probant. Permet moi d'en douter

Pour le temps réel, il existe des GC "temps réel", c'est à dire ne consommant pas plus que N milisecondes par tour de GC, et M milisecondes en tout par secondes. Et les résultats sont très bons. Ils ont en java un simulateur de Steinway, ce qui est très gourmand en ressource et ne tolère pas le moindre délai (l'oreille humaine s'en rendrait compte tout de suite), et les résultats sont excellents.

Pour le réseau, il me semble quand même qu'Erlang n'est pas tout à fait absurde comme option. De façon anecdotique, acebook l'utilise pour son chat par exemple, mais surtout, il est très utilisé entre autre par Erikson et bien d'autres. Et pourtant, c'est un langage fonctionnel.

Pour l'imagerie et le calcul, je te conseille de jeter un œil à ce que fait le labo de York là dessus, notamment des papiers comme celui ci : http://eprints.whiterose.ac.uk/5000/ . Ils sont capable de gérer des terra de données avec Haskell et de les afficher franchement joliment (j'ai pu voir une démo il y a un an de ça, c'est vraiment chouette.)

Et pour l'embarqué ? Prenons l'exemple des réseau de capteurs. Il est difficile de faire plus demandant en terme de ressource. Et pourtant, de la programmation de "haut niveau" peut apporter beaucoup dans ce domaine. Je te conseille de regarder les langages Flask et Regiment, qui donnent de beaux exemples de ce qu'on peut faire avec un ou deux niveaux d'abstractions en plus : http://fiji.eecs.harvard.edu/Macroprogramming
Mais ça va encore plus loin ! Il y a des gens qui contrôlent des véhicules hybride en... Haskell ! (voir http://cufp.galois.com/2008/schedule.html , deuxième entrée)

Tu parles de mettre du java sur un carte temps réel comme si c'était l'idée la plus con du monde. En même temps, outre java-card, je ne connais pas beaucoup de technologie embarqué qui ont des certifications allant de EAL4 à EAL7 pour certaines parties(http://www.slb.com/modules/news/pres....asp?id=16261& , http://www.gemalto.com/php/pr_view.php?id=239 et www.trusted-logic.com/IMG/pdf/EAL7.pdf). Et oui, il y a des domaines où ça compte !

Pour le calcul ? Prenons l'exemple de la crypto. Même la NSA fait le paris du langage de haut niveau : http://swik.net/nsa+cryptol

Et puis bon, même si on supprime tout ça, il reste quand même quelques ptits truc dans le vaste monde de l'informatique hein... La majorité des softs que j'utilise ne sont pas vraiment contraints en terme de ressources. Mon lecteur de musique, ok, il y a le coeur qui décode le MP3 (admettons que le faire en C reste une bonne idée), mais tout ce qu'il y a autour, la gestion des playlists, intelligentes ou non, des préférences, du marquage des musique, des jaquette de CD, j'en passe et des meilleurs, je ne suis pas sur que ça gagne tant que ça à être codé en C ou C++, même au contraire quand je vois à quel point il est simple de faire crasher Amarok2 en cliquant un peu trop vite.

Mon logiciel de chat, que ce soit x-chat pour IRC ou pidgin pour le reste, je vois assez peu de contraintes lourdes.

Mon gestionnaire de bureau, je préfèrerais qu'il soit éventuellement un poil de cul moins réactif mais en contre partie crash moins souvent (KDE 4.2 n'est vraiment pas au point...).

Le problème de faire du bas niveau pour débuter, c'est qu'après, on reste toute sa vie persuadé qu'il n'y a pas d'autres moyens pour produire du code efficace, alors que les compilos font des *vraies* merveilles (allez, encore un exemple ! http://www.cse.unsw.edu.au/~dons/papers/CLS07.html ) et qu'il existe plein de DSL (domain specific languages) de haut niveau et de grande qualité.

[ZoinX]

Ne pas apprendre à libérer sa mémoire dès le départ, c'est s'exposer à ne JAMAIS le faire... Et ça se vérifie sans arrêt, tout comme ne compter que sur le compilo ou la puissance de la machine pour optimiser un programme ou algo.
C'est comme ça qu'on a de "jeunes diplômés" qui pensent avoir l'idée du siècle en voulant mettre du Java dans une carte embarquée temps réel, en croyant que "rajouter un CPU" ou "2 Go de RAM" n'aura aucune influence ni sur le coût de la carte, ni sur le temps de développement... Et tout ça parce qu'ils trouvent le C (ou le C++) "trop dur" avec tout ces pointeurs tout vilains...

Je suis un jeune diplômé ayant appris à programmer sur des langages de haut niveau (Caml, Java) et je suis aujourd'hui fan de C# et allergique au C. Pourquoi ? Eh oui, parce que je trouve la gestion de la mémoire et les pointeurs en C trop chiants et trop souvent sources de problèmes qu'on n'a pas dans les langages de haut niveau.

J'ai appris à programmer sur des langages de haut niveau, et pourtant j'ai toujours réussi à programmer en C sans avoir trop de problèmes liés à la mémoire. Pourquoi ? Parce que ce n'est pas parce qu'on a appris les langages de haut niveau qu'on ne sait pas comment fonctionne la mémoire et qu'on n'y fait pas attention.

Je fais du C#, ça ne m'empêche pas de faire attention à ce qui est alloué par mes objets, ça ne m'empêche pas d'optimiser mon code, et ça ne me fait pas oublier d'appeler les méthodes Dispose() de mes objets.

Je crois que tu confonds deux choses qui n'ont rien à voir: être conscient et soucieux de la gestion de sa mémoire, et utiliser un langage qui t'oblige à gérer la mémoire à la main, ça n'a rien à voir. Si tu apprends *correctement* un langage haut niveau, c'est à dire en apprenant correctement les différences entre valeurs et références, en sachant ce qu'est un GC et comment il fonctionne dans les grandes lignes, et si tu apprend à programmer en étant soucieux de tes algorithmes et de leur complexité, de tes objets et de leur durée de vie, alors tu n'auras pas souvent de problèmes en C.

Ce que tu confonds c'est d'une part les langages de haut niveau, et d'autre part l'apprentissage de la programmation "n'importe comment", en utilisant toutes les bibliothèques sans jamais se soucier de comment un truc est implémenté et quelle est sa complexité.

Ne jurer que par le Java et le C# ne m'a pas empêché de programmer des trucs complexes et bien codés en C sans jamais avoir vraiment appris le C, ça ne m'a pas empêché non plus d'obtenir de très bons résultats au concours ACM en optimisant bien mes algorithmes et en dépassant en performances des programmes en C mal optimisés, et sans avoir besoin de rajouter 2 Go de ram comme tu dis. Par contre ça m'a permis de passer bien plus de temps à apprendre de bons algorithmes et à utiliser les subtilités des langages de haut niveau au lieu de le passer à débugger des segfaults.

Etre conscient de comment marche un GC et être capable de prendre sa place dans un langage ou il n'y en a pas, c'est important. Se forcer à faire le travail du GC soi-même, c'est une perte de temps. Si des gens se sont emmerdés à créer des langages de haut niveau, c'est pour que nous puissions les utiliser pour implémenter rapidement des algorithmes péchus au lieu d'allouer notre mémoire à la main. Et à mon avis ce qui manque à une majorité de développeurs de nos jours, c'est pas de savoir bien gérer sa mémoire, mais de savoir coder de bons algos.

[Mac LAK]

Quoi ?? "Langage de haut niveau" ne veux pas dire performance catastrophique ! Il faut arrêter avec ça...

Preuves ? Tu as un programme Java, Haskell ou OCaml (un minimum complexe bien sûr) qui tourne aussi vite que son équivalent C/C++, à compétence de développeur égale bien entendu ?

qui ont des perfs de l'ordre de 1,5 à 2,5 fois plus lent que C.

... Ce qui est un gouffre dans le domaine du temps réel ou de l'embarqué, et un surcoût colossal sur le matériel pour l'adapter à certains runtimes.

Tu nous dis que ça élimine tout une palanqué de domaine où, si je comprends bien, il faudrait tout gérer à la paluche pour avoir la moindre chance d'obtenir un résultat probant. Permet moi d'en douter

Tu en seras plus convaincu en devant gérer plusieurs liens Ethernet gigabit à plein débit, par exemple... Ou en devant acquérir deux ou trois mille signaux chaque milliseconde, et les traiter au passage, et ceci sur plusieurs cartes CPU en même temps.
Mon unité de calcul "précise", c'est la MICROseconde... La milli, c'est mon unité "macroscopique", celle "de base".
Et quel que soit le cas, la charge CPU doit être mesurée, et rester sous les 66% de façon à assurer les pics de charge.

Ce n'est absolument pas le même monde. Et dans le mien, les langages "usines à gaz" n'ont pas leur place avant des décennies, et encore !! Car quel que soit le cas, les gens voudront toujours faire cracher le moindre bout de puissance à ces machines...

Pour le temps réel, il existe des GC "temps réel", c'est à dire ne consommant pas plus que N milisecondes par tour de GC, et M milisecondes en tout par secondes.

Des MILLIsecondes ?? Et je perds mes signaux, moi, pendant que ton GC fait mumuse ?

Pour le réseau, il me semble quand même qu'Erlang n'est pas tout à fait absurde comme option. De façon anecdotique, acebook l'utilise pour son chat par exemple, mais surtout, il est très utilisé entre autre par Erikson et bien d'autres. Et pourtant, c'est un langage fonctionnel.

Je te parle de "remplir" des liens Gigabit, moi... Et oui, y'a un pluriel.

Pour l'imagerie et le calcul, je te conseille de jeter un œil à ce que fait le labo de York là dessus, notamment des papiers comme celui ci : http://eprints.whiterose.ac.uk/5000/ . Ils sont capable de gérer des terra de données avec Haskell et de les afficher franchement joliment (j'ai pu voir une démo il y a un an de ça, c'est vraiment chouette.)

Je n'ai pas dit que certaines choses étaient impossibles avec des langages de haut niveau... Juste que ce n'était pas applicable dans certains domaines.

Faire une belle image ? Oui, et alors ? Haskel est-il capable, par exemple, de traiter un flux vidéo en temps réel ? Si oui, à quel pourcentage de charge CPU par rapport à du C/C++ ? Et pour quelle consommation mémoire ? Quel est la taille de l'empreinte sur la mémoire de masse ?
Ces points conditionnent le coût direct (en terme de CPU, RAM, mémoire Flash) d'une carte de décodage... Et donc de son prix ! Et en général, si c'est une production de série, le coût du logiciel devient vite dérisoire par rapport à celui du matériel, ce qui fait que le surcoût de temps de développement du C/C++ devient négligeable.

Et pour l'embarqué ? Prenons l'exemple des réseau de capteurs.

Attention, là : un capteur, ce n'est pas forcément quelque chose contenant du logiciel (c'est même rarement le cas). De plus, il est très courant en automatisme d'avoir des automates de centralisation, qui permettent de s'affranchir du bus de terrain au profit d'un médium plus "courant" et, surtout, plus répandu dans l'informatique classique.
Typiquement, tu vas avoir un automate qui servira de passerelle CAN / Ethernet, programmé en C/C++, et qui permettra de décharger le PC de supervision de la phase d'acquisition. L'automate est cadencé sur le bus de terrain, en acquisition permanente.
Et c'est souvent transparent pour le PC de supervision, tout comme cela permet d'exploser les limites de bande passante des bus de terrain en ne polluant pas la BP d'un sous-réseau avec le trafic "inutile" d'un autre sous-réseau.

Ceci ne change absolument pas le fait que la plupart des PC de supervision sont programmés avec des langages de haut niveau, d'ailleurs... Mais l'acquisition des données des capteurs est en général hors de leur portée vu les contraintes temporelles, ils les récupèrent donc "en bloc" avec un très léger différé, les automates passerelles étant, eux, programmés pour réagir instantanément à certaines conditions ("arc-réflexe" avant d'informer la supervision d'un problème)...

En même temps, outre java-card, je ne connais pas beaucoup de technologie embarqué qui ont des certifications allant de EAL4 à EAL7 pour certaines parties

Moi, j'en connais plein... Certifications SIL4, DO178-B, etc, tous en C ou en Ada.

Pour le calcul ? Prenons l'exemple de la crypto. Même la NSA fait le paris du langage de haut niveau : http://swik.net/nsa+cryptol

Langage de MODÉLISATION... Pour être derrière implémenté notamment en VHDL (plus bas niveau, tu meurs) et C. La partie Haskell reste, à mon sens, anecdotique : si c'est pour crypter un mail, le temps d'exécution n'est pas critique en effet.

même au contraire quand je vois à quel point il est simple de faire crasher Amarok2 en cliquant un peu trop vite.

Pas de problèmes avec WinAmp, pour ma part... Et ce serait étonnant qu'il ne soit pas en C/C++ !
Je n'aime pas Unix, ni Linux : je dois avoir la scoumoune avec, faut croire, mais je fais exploser les Linux à la chaîne. Je trouve toujours crevant de "tuer" un XTerm en faisant un "cat" d'un fichier binaire dedans, pour ma part...

Mon gestionnaire de bureau, je préfèrerais qu'il soit éventuellement un poil de cul moins réactif mais en contre partie crash moins souvent (KDE 4.2 n'est vraiment pas au point...).

Là encore, je n'ai pas de soucis avec le GDI Windows... Et celui d'XP n'est pas en C#, hein...

Le problème de faire du bas niveau pour débuter, c'est qu'après, on reste toute sa vie persuadé qu'il n'y a pas d'autres moyens pour produire du code efficace, alors que les compilos font des *vraies* merveilles (allez, encore un exemple ! http://www.cse.unsw.edu.au/~dons/papers/CLS07.html ) et qu'il existe plein de DSL (domain specific languages) de haut niveau et de grande qualité.

Un programme est écrit pour effectuer une action précise : c'est son but premier, le "non négociable".
Ensuite, tu as deux choses à considérer : le temps de développement, et le temps d'exécution. Le premier est crucial dans certains domaines où un programme n'est exécuté qu'une ou deux fois, mais il faut le résultat après le moins de temps possible, quitte à passer autant de temps en exécution qu'en développement. Les langages de haut niveau ont leur place ici.
Le deuxième, c'est le temps d'exécution, qui dans d'autres domaines sont totalement fondamentaux, car le programme est écrit une seule fois, mais est exécuté des millions de fois... Le temps de développement est négligeable par rapport au temps d'exploitation, et c'est le royaume des langages bas niveau où la performance est le seul critère accepté.

Entre les deux, tu as les petits softs exécutés sur stations de travail personnelle, plus ou moins souvent, et qui peuvent être développés aussi bien en C "hardcore" qu'en langage de très haut niveau. Car l'utilisateur veut alors juste la FONCTION, peu importe que le programme s'exécute en 3 ms ou en une seconde, tant que ça reste "rapide" à l'œil humain.

Mets un jour les pieds dans l'informatique industrielle, tu verras alors que les contraintes n'ont absolument rien à voir avec celles que tu connais...

Et être contraint à le faire dès le départ, c'est s'exposer à ne JAMAIS découvrir un gros paquet d'algorithme et de structure de donnée qui ne tolèrent pas la gestion manuelle de la mémoire (sauf éventuellement les "smart pointers"), comme toutes les structures de données persistantes à partage implicite. Encore une fois, je préfère que le débutant explore un maximum des possibilités offertes, quitte à se limiter le jour où il est obligé d'utiliser un langage bas niveau à gestion manuelle des ressources.

Qui peut le plus peut le moins : je n'ai JAMAIS vu un développeur "bas niveau" ne pas réussir à maîtriser un langage de plus haut niveau... Et, souvent, mieux que quelqu'un qui a démarré avec (le GC, c'est bien, mais libérer soi-même, c'est encore mieux, ça évite les pics de charge et les micro-blocages le temps de libérer le bouzin).

Par contre, la réciproque est souvent fausse...

[Mac LAK]

J'ai appris à programmer sur des langages de haut niveau, et pourtant j'ai toujours réussi à programmer en C sans avoir trop de problèmes liés à la mémoire.

J'aime bien le "sans avoir trop de problèmes"... Normalement, c'est "jamais", tu sais ?

ça ne me fait pas oublier d'appeler les méthodes Dispose() de mes objets.

Sauf qu'avec un GC, si tu oublies, ça n'a pas de conséquences. Sans un GC, c'est critique, et les mauvaises habitudes sont rapides à prendre... Trop rapides, d'ailleurs.

Si tu apprends *correctement* un langage haut niveau

C'est lç que le bât blesse, justement : le "correctement" semble plutôt rarissime.

Par contre ça m'a permis de passer bien plus de temps à apprendre de bons algorithmes et à utiliser les subtilités des langages de haut niveau au lieu de le passer à débugger des segfaults.

Je connais les mêmes algorithmes, pour en avoir implémenté quelques uns d'assez velus. Les langages de haut niveau n'y sont absolument pour rien...

Si des gens se sont emmerdés à créer des langages de haut niveau, c'est pour que nous puissions les utiliser pour implémenter rapidement des algorithmes péchus au lieu d'allouer notre mémoire à la main.

Tu as raison sur ce point : c'est pour faire un programme rapidement que ces langages existent. Mais ce n'est absolument pas pour qu'ils soient performants, ni donner de "bonnes" habitudes de programmation, cf. mon post du dessus.

[jabbounet]

Moi, j'en connais plein... Certifications SIL4, DO178-B, etc, tous en C ou en Ada.

je les connais aussi celles là.
par contre je ne connaissais pas EAL4 et 7.

[jabbounet]

Bref ce que j'en retiens (et que je savais déja) c'est qu'il faut choisr un outil adapté a son besoin.

un tournevis ne sers pas a enfoncer des clous par exemple.

[ZoinX]

toutes les grandes entreprises d'informatique posent des questions d'algorithmique pendant leurs entretiens. Pourquoi ? Parce que c'est ce qui fait le plus défaut aux informaticiens de nos jours.

Etre capable de coder dans un langage bas niveau ? Bien sûr que c'est important. Mais c'est tout à fait possible à apprendre sur le tas quand on connait un langage haut niveau et qu'on a une connaissance sommaire de son fonctionnement sous le capot.

Etre capable de pondre de très bons algos qui n'ont pas une complexité exponentielle ? C'est bien plus important encore. Ton algo exponentiel en C, même sur-optimisé, il aura du mal à battre un algo en n log(n) en java... Et malheureusement, à en croire les entreprises, c'est ce point là qui fait bien plus défaut aux informaticiens d'aujourd'hui. Et il est également beaucoup plus dur à apprendre sur le tas pour qui n'a jamais fait d'algorithmique.

l'algorithmique permet des gains de performances incomparables aux petites optimisations spécifiques à un langage.

Quand tu postules dans une entreprise d'informatique assez généraliste, on veut savoir si tu es capable de sortir de bons algos. Si tu ne connais du tout le langage utilisé c'est pas grave, on sait que si t'es bon en algo le reste tu peux l'apprendre sur le tas assez facilement.

L'algorithmique c'est justement la seule partie de l'informatique qu'il est très difficile d'apprendre en dehors de l'école (et je parle bien d'apprendre à trouver des algorithmes efficaces dans n'importe quelle situation, pas d'apprendre par coeur des algorithmes connus), et c'est aussi la plus complexe et la plus importante.

[alex_pi]

Preuves ? Tu as un programme Java, Haskell ou OCaml (un minimum complexe bien sûr) qui tourne aussi vite que son équivalent C/C++, à compétence de développeur égale bien entendu ?

Et à temps de développement ? Temps de débug ? Niveau de confiance dans le code ? Lisibilité pour les relecteurs et mainteneur ? Modularité et réutilisabilité ? Ah nan, tout ça, RAF, faut que ça aille vite !

Tu en seras plus convaincu en devant gérer plusieurs liens Ethernet gigabit à plein débit, par exemple... Ou en devant acquérir deux ou trois mille signaux chaque milliseconde, et les traiter au passage, et ceci sur plusieurs cartes CPU en même temps.

On me souffle dans l'oreillette que ceci ne serait pas l'activité majoritaire dans le monde de l'informatique.

Attention, là : un capteur, ce n'est pas forcément quelque chose contenant du logiciel (c'est même rarement le cas). De plus, il est très courant en automatisme d'avoir des automates de centralisation, qui permettent de s'affranchir du bus de terrain au profit d'un médium plus "courant" et, surtout, plus répandu dans l'informatique classique.
Typiquement, tu vas avoir un automate qui servira de passerelle CAN / Ethernet, programmé en C/C++, et qui permettra de décharger le PC de supervision de la phase d'acquisition. L'automate est cadencé sur le bus de terrain, en acquisition permanente. [...]

A la rigueur, mais ce n'est qu'une suggestion, lit les abstract des liens qu'on t'envoie, juste histoire de voir si tu parles de la même chose, des mêmes problème. Genre par exemple des cas où on ne peut pas se permettre d'avoir un PC qui récupère les infos de tous les capteurs, parce qu'on a un réseau ad-hoc avec un seul point de sortie, et que si les 4000 capteurs causent en même temps, ça va pas passer. Et que donc il faut faire des requettes sur les capteurs, des filtres locaux, etc, etc.

Langage de MODÉLISATION... Pour être derrière implémenté notamment en VHDL (plus bas niveau, tu meurs) et C. La partie Haskell reste, à mon sens, anecdotique : si c'est pour crypter un mail, le temps d'exécution n'est pas critique en effet.

Là encore, bon, on pourrait suggérer la lecture des deux premières phrases hein, histoire de voir que cryptol est COMPILÉ vers VHDL. C'est un peu comme si tu disais qu'un programme en Caml est "par derrière implémenté notamment en langage machine" parce qu'il y a un compilo natif...

Le temps de développement est négligeable par rapport au temps d'exploitation, et c'est le royaume des langages bas niveau où la performance est le seul critère accepté.

J'ai ouïe dire que les gens qui réfléchissent comme ça se retrouve avec des multiplication des couts par des facteurs 2 ou plus à cause du temps monstrueux de débug. Mais ils ont du oublier d'embaucher des magiciens du malloc/free

Qui peut le plus peut le moins : je n'ai JAMAIS vu un développeur "bas niveau" ne pas réussir à maîtriser un langage de plus haut niveau...

Je crois qu'en fait qu'il faudrait qu'on s'accorde sur ce qu'est un langage haut niveau. Parce que moi, quand je regarde un mec qui a débuté en bel impératif bien main dans le cambouis et qui tente de faire du Caml ou du Haskell, le résultat n'est pas mauvais, il est catastrophique. Parce qu'ils pensent optimisation avant de penser correction et lisibilité de l'algo.

[gorgonite]

Parce que moi, quand je regarde un mec qui a débuté en bel impératif bien main dans le cambouis et qui tente de faire du Caml ou du Haskell, le résultat n'est pas mauvais, il est catastrophique. Parce qu'ils pensent optimisationnnnnnnn avant de penser correction et lisibilité de l'algo.

cet avis est certes tout aussi catégorique, et donc certainement aussi erronné que celui de Mac_Lak, mais je pense qu'il faut quand même essayer de ne pas tout mélanger... a priori toute personne ouverte d'esprit, et faisant preuve d'un minimum de bonnes volontés, comprendra rapidement les concepts d'un nouveau paradigme, et seulement après à force de persévérance réussira à obtenir un résultat potable hors d'un simple cas d'école

[alex_pi]

cet avis est certes tout aussi catégorique, et donc certainement aussi erronné que celui de Mac_Lak

Oui, bon, ok Disons autrement : le changement de paradigme et l'élévation dans les niveau d'abstraction me semble demander plus d'effort que le détail technique de la gestion manuelle de la mémoire.

[Mac LAK]

Je suis tout à fait d'accord avec ça. Sauf que toutes les grandes entreprises d'informatique posent des questions d'algorithmique pendant leurs entretiens. Pourquoi ? Parce que c'est ce qui fait le plus défaut aux informaticiens de nos jours.

Je ne sais pas pour toi, mais pour ma part, j'avais des cours d'algorithmique qui n'étaient sûrement pas faits en même temps que les cours de programmation... Les deux choses n'ont rien à voir, du moins dans un premier temps.

Mais c'est tout à fait possible à apprendre sur le tas quand on connait un langage haut niveau et qu'on a une connaissance sommaire de son fonctionnement sous le capot.

Et t'as alors un mauvais développeur "bas niveau"... Le genre qu'on ne peut laisser seul, et qui fait plus le boulet que le collègue. Que crois-tu ? Que c'est "facile" à apprendre, qu'on peut le faire "sur le tas" comme ça, en un clin d'oeil ?
Non : sur le tas, à partir de théories de langages de haut niveau, tu n'apprends pas à développer, mais soit à bidouiller pour franchir les barrières syntaxiques, soit à faire des usines à gaz. En général, c'est les deux en même temps.

Etre capable de pondre de très bons algos qui n'ont pas une complexité exponentielle ? C'est bien plus important encore. Ton algo exponentiel en C, même sur-optimisé, il aura du mal à battre un algo en n log(n) en java...

Et en quoi le langage de haut niveau permet-il d'avoir un algorithme qui ne serait pas implémentable en C/C++ ?

C'est pour ça qu'il est beaucoup plus important d'apprendre à l'école l'algorithmique plutôt que l'optimisation des performances grâce aux langages bas niveau.

Ce n'est sûrement pas à l'école que j'ai appris l'optimisation... Ce serait plutôt par obligation professionnelle, les clients étant rarement comiques au sujet des performances.

Parce que l'algorithmique permet des gains de performances incomparables aux petites optimisations spécifiques à un langage.

Merci de m'apprendre mon métier, hein... Sûr, j'ai jamais appris ce qu'était une complexité !

Si tu ne connais du tout le langage utilisé c'est pas grave, on sait que si t'es bon en algo le reste tu peux l'apprendre sur le tas assez facilement.

Dans une boîte à viande, peut-être. Dans ma boîte, on exigera les deux, et nous ne sommes pas les seuls à agir ainsi.

Et coup de bol, c'est aussi la plus intéressante et la plus pédagogique, et celle qui donne en général le plus envie aux étudiants de se lancer dans l'informatique.

Tiens, à ce sujet, tu remarqueras que la syntaxe usuelle (=la plus courante) des algos est extrêmement proche du Pascal/Ada... Tiens donc...

Or tu auras du mal à justifier qu'un langage de bas niveau soit plus adapté (ou même aussi adapté) qu'un langage de haut niveau à l'apprentissage de l'algorithmique.

Donc, je vais être direct et brutal : apprends à lire.

La défense du C/C++ que je fais, c'est afin de montrer que si ce ne sont pas des langages "visibles", ils restent néanmoins essentiels à tout point de vue, et forment une très vaste partie de l'informatique... Certes, c'est plus du marché caché qu'autre chose, mais cela reste quelque chose d'énorme.

Le monde du temps réel, de l'embarqué et des optimisations, c'est un monde invisible pour la plupart des gens. Reste quand même le fait que sans eux, ton langage de haut niveau serait sur du papier uniquement.

[SpiceGuid]

Disons autrement : le changement de paradigme et l'élévation dans les niveau d'abstraction me semble demander plus d'effort que le détail technique de la gestion manuelle de la mémoire.

C'est une question de parcours personnel: ce qui coûte le plus d'effort c'est la formation initiale.

Pour toi la POO c'est enfantin (l'héritage c'est du sous-typage sur les enregistrements) mais si tu vas sur les forums Delphi/Java/C# tu verras que la POO c'est vraiment difficile. Tout paraît plus facile quand on est déjà très bon.

C'est la même chose pour le bas niveau, si on commence par là il faut suer pour le maitriser.

Le bas niveau c'est grisant, le haut niveau c'est gratifiant, ce sont deux motivations différentes, il y a autant de compétence à acquérir des deux côtés et la tienne n'est pas plus primordiale que celle d'un autre.

Je comprends d'où vient ton idée: tu pense que C est pauvre en types composites tandis que Caml est pauvre en type primitifs. Mais que ça n'est pas problématique puisque la vraie compétence c'est de savoir bien typer. Selon moi c'est aussi problématique que l'inverse: bien typer c'est la partie lisibilité/qualité/preuve, l'autre moitié, la partie programme/performance/bindings est tout aussi importante à mes yeux.

Parce que moi, quand je regarde un mec qui a débuté en bel impératif bien main dans le cambouis et qui tente de faire du Caml ou du Haskell, le résultat n'est pas mauvais, il est catastrophique. Parce qu'ils pensent optimisationnnnnnnn avant de penser correction et lisibilité de l'algo.

On ne peut pas programmer en fonctionnel sans s'intéresser à la preuve. Ce qui fait le succès des méthodologies POO c'est que les programmeurs veulent plus de garanties mais sans apporter plus de preuves. Le "mec qui a débuté en impératif" veut continuer à écrire des programmes, il n'a pas du tout envie d'un typage élaboré qui l'oblige à écrire des pseudo-preuves.
Quelqu'un qui sait imbriquer des portées lexicales fait un très bon programmeur POO, il n'a plus rien à apprendre et il le sait. La POO c'est mettre les fonctions dans la même portée (extensible) que les variables. Un programmeur POO n'a pas besoin de (et ne veut pas) parler d'inclusion ou de sous-typage. Il aura d'ailleurs du mal à passer d'un sous-typage sur les enregistrements à, par exemple, un sous-typage sur les modules.