Je suis tombé amoureux pour la première fois à l'âge de 16 ans. C'était il y a 16 ans déjà, dans un petit bâtiment au détour d'une rue ou on m'avait dit qu'on donnait des cours d'informatique pour pas cher. Au début, je croyais que j'aurais affaire à des souris glissant de fenêtre en fenêtre histoire d'ajouter "dompteur de rongeurs" à mon CV, à cette époque chez moi c'était aussi impressionnant que "dompteur de lions", et puis quelques mois après elle est entrée dans ma vie : la programmation, j'ai d'abord découvert Pascal puis C et j'ai aussi découvert que l'on pouvait faire bien plus que glisser des curseurs d'un bout à l'autre de l'écran. À l'issue de ma formation j'ai décidé de m'investir dans l'informatique, "un métier d'avenir" qu'on disait à l'époque.
Après le bac donc, la fac, direction l'institut d'informatique. Seulement voilà, quelques obstacles me barraient le passage pour devenir, moi aussi, un gourou et entrer au panthéon geek.
Le premier est que j'avais une aversion pour tout ce qui touchait aux mathématiques, aversion acquise suite au martyre que j'avais subi de la main de certains de mes enseignants, un en particulier, grossier personnage qu'on croirait tout droit sorti d'un roman écrit de la main droite du marquis de Sade et de la main gauche d'Henri Poincaré. Les mathématiques, comme vous le savez, c'est l'âme de l'informatique et sans âme point de vie.
Mais être étudiant en informatique m'a permis de rencontrer d'autres geeks, de me sentir un peu revivre après deux décennies passées en authentique nerd anabiote (id est : un no-life endurci), de découvrir Linux, vous savez le "Oh un système UNIX Linux dans mon PC et tout cela sans débourser un sou et sans culpabilité parce qu'avant je tipiakais des logiciels propriétaires car chez moi ça coûte un bras et une jambe d'acheter ne serait-ce qu'un Windows authentique" ...
Mais par rapport à mes amis geeks j'avais un petit handicap : bien que j'eus pu, comme eux, tant bien que mal, réussir mes examens, j'étais affligé par le plus grand des maux dont un geek peut souffrir; je pouvais écrire écrire des codes les plus beaux et les solutions les plus élégantes qui soient mais je bloquais très souvent, trop souvent, sur des bugs mineurs, bugs dus à des petites erreurs d'inattention, deuxième obstacle donc. Les Américains appelleraient ce mal le TDAH , moi j'appelle cela une malédiction, oui, j'étais un geek maudit et cette malédiction m'a toujours poursuivi, si bien qu'à la fin de mes études, même avec un diplôme en poche, convaincu que j'étais le plus médiocre des informaticiens, j'ai été contraint de quitter mon amour de toujours, un divorce valait mieux qu'une vie commune empoisonnée par la frustration, et prononcé le divorce fut. Je dus alors me chercher un autre métier.
Entre temps, les vents du destin m'avaient emporté vers d'autres cieux et finalement déposé sur la terre des Gaulois et du haut_débit_qui_déchire_la_race_à_sa_tante. Je pouvais profiter de beaucoup de libertés, dont la liberté des logiciels et continuer à utiliser allègrement les logiciels libres, j'ai même pu attirer de nouveaux disciple à l'école du GNU.
Mais les dieux geek sont mesquins et pleins de condescendance pour les mortels, iEros revint à me harceler et à remuer la flèche que j'avais brisée en tentant de l'extirper de mon cœur il y a près d'une décennie. D'un autre côté, plus j'utilisais les logiciels libres - gratuitement le plus souvent, ma bourse étant vide et une bourse, comme disait Hermann Melville, "n'etant rien d'autre qu'un morceau de tissu s'il n'y a pas un sou dedans." - plus j'utilisais les logiciels libres donc, plus je culpabilisais. J'avais l'impression d'être un fardeau pour la communauté libre, un profiteur, un parasite, qui utilise du bon code sans jamais y contribuer. "Tu es un informaticien médiocre, mais tu n'en es pas moins informaticien" c'est avec ces mots que ma conscience me torturait.
Pourquoi le code ? me direz-vous, pourquoi pas la documentation, la soumission de rapport de bogues, le support technique, la promotion du libre ? oui vous avez raison, le libre ce n'est pas que le code et je fais déjà deux choses sur les quatre que je viens de citer. Mais le code, c'est une écriture sacrée. Le code, c'est le nerf de la guerre et du software. Le code cristallise la pouvoir technique du geek. Le code, c'est les blocs de pierre qui constituent le mur de Geekgamesh. Le code, c'est le passeport pour l'éternité. Le code c'est la création du monde libre. Le code, c'est le destin du développeur. En ne codant pas, ou plutôt en étant incapable de produire du bon code, j'ai commis un sacrilège, j'ai brisé mon destin, j'ai contrarié les desseins de iTyché.
Depuis quelque temps, je n'arrête pas de penser au code, j'en vois partout, parfois j'ai des illusions d'optique et je jurerais avoir vu des accolades ouvrantes et fermantes dans mes spaghetti.
J'aimerais recommencer à écrire du code, je le fais déjà mais c'est du Bash donc ça ne compte pas. J'ai entamé récemment une auto-formation en Java, oui je sais ça pu c'est pas (vraiment) libre, mais il faut bien manger ... j'ai bien voulu refaire du C/C++ mais ça me rappelle trop de mauvais souvenirs. Et puis ma vieille hantise ne me quitte pas, je crains d'être toujours maudit et que mon sort, en tant qu'aspirant-développeur, soit scellé. J'ai peur d'être condamné à une geekitude vaine et infertile ad vitam aeternam.
Voilà, je sais que les journaux ne doivent pas être des déversoirs d'état d'âmes de geeks en mal de talent, mais il ne reste plus beaucoup d'endroits où je peux crier son désarroi.
Amies geekettes, amis geek, que le fork soit avec vous.
Journal Lamentations ou les remords d'un geek
18
juin
2010
# même situation
Posté par Gabin . Évalué à 10.
Là je m'empresse de rattrapper le temps perdu, mais ça me frustre encore plus!
Je remarque que c'est plus par peur que par réel constation d'echecs que je n'ai pas progressé plus dans la programmation pure.
Quant aux Math, c'est une partie du problème, tu n'es pas obligé d'acquérir tout le bagage universitaire pour pondre du bon code, de ce que quelques amis m'ont dit, hein? :)
La question - que je me pose du moins - est : Est-il encore possible de rattrapper le train qu'on a manqué?
Je pense que oui, car cela se vérifie dans n'importe quel domaine et on a d'autant plus de ressources à notre dispo que ça devrait en être facile, mais l'ennemie principale est la volonte ou confiance en soit... ou les deux. :)
C'est chiant, hein? la solution est à bout de doigts, on peut presque la toucher mais...
Merci pour ton journal néanmoins, je me sent rassurré de voir une autre personne affronter les même problèmes que moi. :)
Question:
- Est-ce rassurant de savoir que le destin ne s'acharne pas personnellement sur moi.
ou
- Est-ce rassurant de savoir que je ne suis pas le seul à en chier? Donc un brin égoïste :p
[^] # Re: même situation
Posté par cortex62 . Évalué à 3.
C'est une question de motivation...Il faut trouver un projet, une situation, qui permette de maintenir cette motivation.....
[^] # Re: même situation
Posté par KamelPanic . Évalué à 4.
[^] # Re: même situation
Posté par Gabin . Évalué à 2.
Ne pas savoir apprécier la difficulté d'une telle tâche par sur-assurance, peut aussi être une cause de frustration.
On peut se dire que la sur-assurance et la frustration ne sont pas nécessairement compatibles.
# Vive la revue de code!
Posté par thargos . Évalué à 6.
Toute personne qui code ajoute des bugs. Lance toi, tu verras bien. La communauté t'aidera.
[^] # Re: Vive la revue de code!
Posté par zerkman (site web personnel) . Évalué à 5.
# Anabiote ?
Posté par zebra3 . Évalué à 10.
Hem.
Et je ne sais toujours pas ce que signifie anabiote.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Anabiote ?
Posté par fero14041 . Évalué à 2.
[^] # Re: Anabiote ?
Posté par Obsidian . Évalué à 4.
« Anabiote », ce serait plutôt : « qui a la vie d'un canard ». :-)
Source : http://www.cledut.net/xylo.htm
[^] # Re: Anabiote ?
Posté par vladislav askiparek . Évalué à 2.
Sacrés fantasmes!
[^] # anal
Posté par zebra3 . Évalué à 7.
Maintenant je sais. Le tout va être d'arriver à le caser dans une conversation :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Et pis .....thon
Posté par Fabien PRORIOL . Évalué à 8.
C'est beaucoup beaucoup plus simple que C++ ou même Java, et on peut presque tout faire sans {trop} souffrir de performance... (sauf si tu code un codec video mais bon la...)
Coder en Python c'est un regale, tu ne fera pas de faute d'inatention car tout est naturel...
Tu code ce que tu pense...
Bon, tu n'aura pas d'accolade... tu sera obliger de bien indenter... c'est très simple a débuguer, tu peux tester tes essai dans une console pour voir en direct comment sa marche..
Avec ces 4 lignes tu active l'autocompletion dynamique dans ta console:
import readline
import rlcompleter
readline.parse_and_bind("set show-all-if-ambiguous on")
readline.parse_and_bind("tab: complete")
Et avec Python, tu peux aller loin, SDL pour les Jeux, PyQT pour faire des GUI très bien fairte (ne commence quand même pas par les GUI, car c'est assez complexe, et même avec QT ou autre, faire des fenetres, ben, c'est déjà connaitre la programmation...);
Tu trouvera plein d'exemple bien documenter, tu apprendra vite....
Après libre a toi de redécouvrir le C ou le C++, ou même si tu metrise PyQT, le passage au C++/QT est pas si compliqué...
Le Python comme langage scolaire serait un grand pas...
Bonne chance
[^] # Re: Et pis .....thon
Posté par fero14041 . Évalué à 1.
http://www.alterway.fr/publications/python-d-veloppement-aut(...)
[^] # Re: Et pis .....thon
Posté par pipo_molo . Évalué à -3.
Python peut aussi être une bonne solution : étant un langage qui demande moins de lignes de code à écrire que C ou Java pour un résultat identique, il offre moins d'opportunités de faire des erreurs.
Maintenant, python en tant que langage scolaire, à mon avis, ça serait seulement après une bonne dose de C et d'assembleur, histoire de comprendre ce qui se passe sous le capot de l'interpréteur.
Et même là, certaines choses ne sont pas super propres, et peuvent porter à confusion : len() qui sort de nulle part, les types simples passés par valeur alors que tout le reste est passé par référence...
Par contre, je ne dis pas : pour quelqu'un qui a déjà de bonnes bases génériques et qui veut juste aller au but (traduction approximative de "get the job done" ?), python c'est le pied.
[^] # Re: Et pis .....thon
Posté par Jean B . Évalué à 1.
BIIIIIIIIP !!
Tu doit confondre avec Java, en Python les int par exemples sont passés par référence, ils sont juste immuables.
[^] # Re: Et pis .....thon
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Je suis dans une prépa intégrée, donc même si on voit de l'informatique c'est pas censé voler haut. Voici ce qu'on a vu en deux ans :
_1ère année : Java, et en parallèle Linux et la totale du Bash, puis en vrac xhtml/css, le xml, le xslt, le LaTeX (très mal car les deux derniers, aucun souvenir)
_2ème année : on continue le Java pendant toute l'année, en parallèle on continue un peu le bash, on attaque le python, et toujours en parallèle du java on fait du php/javascript.
On a une dent contre l'enseignement de Java car c'est en fait une version d'évaluation du livre d'un de nos professeurs [http://elec.polytech.unice.fr/~vg/fr/livres/algojava/] et ceux qui ne comprennent pas et/ou n'ont pas déjà vu tout ça un autre jour sont souvent condamnés à acheter le livre sans forcément comprendre mais au moins il y a des corrections… en passant en python c'était le jour et la nuit :
_Code qui marche pas car faute d'inattention : en Python c'était seulement l'indentation, en Java c'était les accolades, les types, les points-virgules...
_Demander à l'utilisateur une valeur : en Python on nous donne input() directement, en Java on nous offre une classe qui prémâche le System.out.println() + la fonction pour récupérer un résultat de l'utilisateur + le traitement de l'erreur, c'est cool mais au bout de la deuxième année on utilise toujours cette classe prémâchée...
_Ouvrir un fichier : en python on nous donne les deux-trois fonctions nécessaires, en Java on doit s'amuser avec les classes et les flux et trouver le combo parfait pour ce qu'on souhaite faire. Sur le SdZ c'est même franchement avoué que les combos de classes c'est la bonne façon de faire [http://www.siteduzero.com/tutoriel-3-65524-les-flux-d-entree(...)], et j'ai dû faire un combo complètement nouveau pour profiter d'un readline().
Et d'autres choses qui sont d'un côté simples à faire en python, d'un autre pas amusantes du tout en Java.
Bon, c'est dans le cadre d'une prépa intégrée, il y a quand même une belle part de l'enseignement aux maths/physiques et ensuite électronique et enfin informatique, donc les gens s'en contrebalancent que le len() sorte de nulle part (pas tant que ça, count() en php fait pareil il me semble) ou que les types simples machin référence passer à saute-mouton. Je ne connais l'assembleur que de nom et le C un peu car olol c'est sur le sdz olol je vais apprendre le C olol je serai un programmeur, je pense que c'est une hérésie d'apprendre le C en début de formation et le Java c'est à peine mieux (les classes sont plus simples qu'en C++, mais comparé au python je chasse le Java du choix).
En bref le python c'est bien pour débuter, mangez-en les bleus.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Et pis .....thon
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Et pis .....thon
Posté par campagnard . Évalué à 5.
En général on commence l'enseignement de la programmation par le pascal (vu que c'est de l'algoritmique de base traduite en anglais), puis on passe au C.
Le C a au moins les avantages suivants :
- ca permet d'apprendre la notion de pointeurs (oui c'est casse-gueule, mais je pense que c'est necessaire de savoir que ca existe, et ca permet de comprendre un peu plus ce que fait l'ordinateur)
- c'est un peu plus proche du materiel. (langage de bas-niveau)
- lorsqu'on passe à la programmation orientée objet, on commence par le C++ et on n'est pas dépaysé (on connait la syntaxe, il ne reste plus qu'a apprendre les concepts de l'orienté objet).
- ca permet d'aborder la programmation systeme assez facilement
Java pour commencer l'etude de la programmation c'est du suicide :
- on commence directement par de l'orienté objet
- L'existence du garbage collector est certes pratique, mais induit de mauvaises habitudes.
- on ne voit plus de "kernel panic", et ca ca manque gravement !
Enfin, c'est juste mon point de vue. M'enfin remarquez j'ai appris comme ca (pascal => C => C++ => Java) mais aujourd'hui je reste une buse en programmation (surtout en Java, je hais ce langage). Remarquez ca vient peut être du fait que je ne pratique plus la programmation depuis la fin de mes etudes (je fais bcp de shell mais a part ca plus rien)
[^] # Re: Et pis .....thon
Posté par windu.2b . Évalué à 2.
Selon moi, on peut commencer à apprendre la programmation avec Java, tout en apprenant les concepts sous-jacents (gestion de la mémoire, références, pile/tas, débordements, ...).
C'est juste qu'il se pourrait bien que beaucoup de profs de Java (et de langages haut-niveau, en général) ne font pas cet effort, mais cela n'est, AMHA, pas la faute de Java !
[^] # Re: Et pis .....thon
Posté par lasher . Évalué à 3.
Dans la catégorie "moi je" :
IUT 1è année:
- 6 mois de C / algorithmique;
- 3 mois de C++;
- 3 mois de Visual Basic.
- Un ou deux TP d'assembleur pour compléter la formation en architecture.
IUT 2è année :
- 6 mois de Java;
- 6 mois de HTML+XML+ASP
(c'est ce que j'ai fait en prenant l'option réseaux/info répartie)
ou
- 6 mois de C++ avancé
- 6 mois de COBOL
(pour ceux qui avaient pris l'option génie logiciel)
En école d'ingé j'ai vu en plus :
- Common LISP
- PROLOG
Ce que je préconise pour former les nouveaux étudiants:
En IUT génie informatique :
- 1 langage compilé et un langage interprété;
- 1 langage procédural et un langage orienté objet;
- 1 langage pour apprendre à faire de la prog système.
En tout, il faut au moins 3 langages différents (car finalement, les études en informatique devraient former à s'adapter à de nouveaux environnement rapidement).
En école d'ingé, je proposerais en plus :
- 1 langage fonctionnel;
- 1 langage déclaratif.
Du coup, avec ce cahier des charges, on pourrait avoir (par exemple) :
- le langage C : procédural, compilé, et permet la prog système;
- Python ou Ruby : orienté objet et interprété;
- HTML+CSS+Javascript : événementiel, interprété, et euh... bizarre ;-) OU Java OU C++.
En école d'ingé, je rajouterais :
- Common LISP, Haskell, OCaml, etc. (certes ce sont des langages multi-paradigmes, mais ils sont clairement plus connus pour leur côté fonctionnel);
- PROLOG ou Erlang (pour se faire des nœuds au cerveau au moins une fois dans sa vie).
Je suis volontairement vague, parce que mon expérience me dit que le plus important, c'est le prof. Malgré tout, avec la façon dont j'ai tourné les choses, j'impose un peu le C, mais je trouve que c'est important : ne pas faire d'assembleur, passe encore, mais même si on peut parfaitement comprendre les problèmes liés à l'allocation/désallocation de la mémoire, aux plantages divers, etc., simplement en écoutant le cours, à mon avis rien ne remplace l'expérience.
Les autres langages, on s'en fout, du moment qu'ils sont utilisés dans des projets de taille conséquente, pour forcer l'étudiant à s'investir et comprendre.
[^] # Re: Et pis .....thon
Posté par Johands . Évalué à 2.
Mais Python, Perl, Ruby, Haskell et autres sont bien la preuve qu'on peut développer des programmes plus ou moins simple sans forcément passer par la case "gestion de pointeurs et allocation de la mémoire".
J'ai rencontré beaucoup de personnes qui ne sont pas vouées à devenir contributeurs au noyau Linux et qui néanmoins doivent développer des programmes pour leur travail (genre des biologistes effectuant des traitements statistiques ou des mécaniciens sur des calculs de structure -- même raisonnement pour les sysadmins et développeurs web). Et pour ceux ayant subi l'infâme "introduction à l'informatique via C", le terme informatique avait une forte tendance à être synonyme de :
- perte de temps : passer des heures à rédiger du code qui ne compilera même pas
- complexité : pourquoi tant de fonctions pour entrer des données ? getc, getchar, fgetc, fgets, ...
- incompréhension : le fameux "segfault", qui nous laisse dans l'embarras sans aucune autre explication
- inutilité : 1 mois de travail sur un projet pour afficher seulement trois lignes de texte et deux triangles à l'écran
... et après on s'étonne qu'en fin de formation, tout le monde préférait Excel/Access à gcc :o
[^] # Re: Et pis .....thon
Posté par lasher . Évalué à 3.
Bien sûr. Mais je dis que quelqu'un qui veut pouvoir se dire « informaticien » devrait avoir touché aux pointeurs & co, et vraiment essayé de piger comment ça marche. Tout simplement parce qu'ensuite, entre les machines virtuelles, les ramasse-miettes, etc., beaucoup de ces mécanismes sont cachés mais pas forcément invisibles (cf. les références circulaires non gérées dans pas mal de ramasse-miettes ou de machins façon les autoptr de boost).
Tu parles de biologistes, mécaniciens, etc. Ceux-là ne sont pas des informaticiens, mais des biologiste, etc., qui ont besoin de l'outil informatique pour faire leurs simulations. C'est différent. Là bien sûr, s'il est possible d'éviter de les faire passer par le C ou le C++, il faut ! Maintenant, mon expérience me dit que Fortran et C++ sont un peu les deux mamelles de la simulation numérique en physique ... avec d'excellentes raisons pour Fortran (même si je déteste ce langage).
Il fallait donc bien lire mon post « littérallement » : je proposais un programme pour IUT génie informatique, et certainement pas pour gens qui ont besoin d'apprendre à programmer.
Par contre, dans les facs de science, je suis tout à fait pour une sorte de « piscine light », un peu comme celle d'EPITA/EPITECH, avec un langage adapté. Après tout, les étudiants font des maths depuis le CP, de la physique/chimie depuis la 4è, de la bio depuis la 6è... En « vraie » informatique, la plupart ne font pas grand chose (apparemment ça a changé et en seconde ils commencent à faire de l'algo, ce qui est déjà mieux). La programmation va devenir, selon moi, un passage obligé de la plupart des sciences appliquées. Autant apprendre aux étudiants à correctement utiliser les outils à leur disposition.
[^] # Re: Et pis .....thon
Posté par nicolas . Évalué à 3.
Notons au passage qu’à part des gens qui ont besoins de très bonnes performances sur des algos. très particuliers il existe des langages adaptés comme matlab et idl pour les plus connus. Python a l’avantage d’être libre tout en remplaçant avantageusement ces deux là, même si numpy/scipy sont encore un peu jeune, par contre pour python il vaut mieux avoir quelques petites notions pour savoir quand c’est le pointeur de l’objet qui est copié ou sa valeur, genre :
> a = array([1, 2])
> b = a
> b[0] = 3
> print a
[3 2]
Cool…
PS : Je hais le C++ pour la simulation numérique, on n’a pas 36000 objets avec des propriétés similaires et compagnie pour profiter de la POO. C’est le pire qui puisse arriver, un non-informaticien qui a appris la programmation à travers le C++.
PPS : quand on parle de Fortran vaut mieux préciser quelle version du langage… 77 et 90 n’ont pas grand chose à voir. Mais je crois pas que beaucoup de nouveaux codes soient écrits en Fortran (et c’est bien dommage).
[^] # Re: Et pis .....thon
Posté par Johands . Évalué à 1.
La programmation va devenir, selon moi, un passage obligé de la plupart des sciences appliquées. Autant apprendre aux étudiants à correctement utiliser les outils à leur disposition.
Je l'espère aussi. Reste plus qu'à trouver des outils libres et des méthodes de formation pour convaincre les gens que la programmation n'est pas une prise de tête mais quelque chose leur permettant d'aller boire un café pendant que leur ordinateur travaille à leur place.
... histoire d'éviter de se retrouver avec une formation en info apparaissant toujours comme la 3ème roue du carrosse où, après une semaine de formation accélérée à C++, les étudiants sont lâchés sur des programmes style fem++ et doivent comprendre eux-même la signification de messages d'erreurs complètement cryptiques. Cela dit, peut-être qu'en remplaçant C++ par FORTRAN, on arriverait à diminuer le nombre de migraines, ou pas ...
[^] # Re: Et pis .....thon
Posté par totof2000 . Évalué à 2.
[^] # Re: Et pis .....thon
Posté par Perthmâd (site web personnel) . Évalué à 5.
L'étape d'après, si tu veux être sûr de ne pas laisser passer un bug, c'est de prouver ton programme.
[^] # Re: Et pis .....thon
Posté par 태 (site web personnel) . Évalué à 4.
C'est forcément rétrograde et sexiste, mais j'ai beaucoup de mal à trouver les langages fonctionnels masculins et encore moins virils. Les qualités étant l'élégance, la légèreté du code et la propreté.
La loourdeur (oui, avec deux o) des langages objets, la rudesse de C ou le laisser-aller de Perl, ça ce sont des qualités d'hommes.
[^] # Re: Et pis .....thon
Posté par monsieurmoche . Évalué à 1.
Si tu n'as pas trop de mal avec l'anglais, je te conseille de lire au moins l'introduction de l'ouvrage « Real World Haskell » (RWH), que tu peux lire gratuitement en intégralité : http://book.realworldhaskell.org/read/
Je n'ai pas encore eu le temps d'en venir à bout, mais l'introduction donne l'eau à la bouche. Non seulement c'est très expressif en peu de lignes, mais en plus c'est extrêmement safe (sur le plan du typage, notamment). La plupart des adeptes du langage prétendent qu'un code Haskell qui compile est un code Haskell qui fonctionne (et sans bug), tout du moins presque dans tous les cas.
Bref, c'est le langage parfait pour les étourdis !
L'inconvénient, c'est que malgré sa popularité montante, il s'agit encore d'un langage assez exotique (à cause du paradigme fonctionnel pur).
Le mieux est que tu lises l'introduction de RWH pour te faire ton propre avis.
[^] # Re: Et pis .....thon
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pis .....thon
Posté par Perthmâd (site web personnel) . Évalué à 1.
Le Lisp me colle des boutons, car je déteste le typage dynamique. Sans parler de la syntaxe abstruse (Lots of Stupid and Insipid Parenthesis).
De l'autre côté de la barrière, Haskell et OCaml étant des ML, ils profitent tous deux de l'inférence de types, et ça c'est vraiment bien. J'ai une nette préférence pour OCaml, cependant, car il est multiparadigme et call-by-value. Il est vrai que l'utilisation de monades rajoute une couche de sûreté sur le code, mais je trouve ça lourd ; de même, on peut avoir besoin de call-by-need par moment, mais on peut l'émuler en call-by-value, donc ça en limite l'intérêt.
Notons quand même à la décharge d'Haskell que GHC a plein d'extension qui tuent, genre les typeclasses et l'ordre supérieur, mais j'imagine que ça ne sert pas trop à un débutant.
[^] # Re: Et pis .....thon
Posté par outs . Évalué à 3.
Perso j'ai toujours regretté que dans OCaml il soit impossible de définir des classes de types. Par exemple il y a une addition + pour les entiers et une addition +. pour les flottants, mais ce n'est pas limité à ca le code Caml est rempli de fonction qui font le même type d'opération avec des nom légèrement différent à cause de cette limitation.
Sinon Haskell est un standard avec plusieurs compilo dispo, ce qui assure une certaine stabilité. Alors que Ocaml est géré par une équipe de l'INRIA dans un but de recherche.
Les deux langages possèdes des compilo très efficaces, avec de bonnes optimisations et génération de code natif. Ce qui est important pour contrebalancer la lenteur potentielle de la prog fonc.
[^] # Re: Et pis .....thon
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si on me confiait la réalisation d'un "gros" soft compliqué, je pousserais Ocaml même si personne ne le connait à la base.
"La première sécurité est la liberté"
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Johands . Évalué à 5.
Python est trop dangereux pour les étourdis chroniques : trop de libertés, trop de possibilités d'erreur, trop de canards enrubannés (et parfois même, comme avec GTK+2, des bogues entre les bindings C et la machine virtuelle un peu trop subtiles à mon goût).
Des langages fortement typés comme Haskell ou C/C++ et leurs descendants (Java, Vala?) ne conviendraient-ils pas mieux ? (je ne connais pas Ruby, je ne sais pas ce qu'il en est pour lui). Tant pis pour les fioritures et autres "boilerplate". On a des éditeurs de textes suffisamment puissants aujourd'hui pour ne plus s'en soucier. Tant pis également pour ce méchant compilateur qui n'arrête pas de nous taper sur les doigts. Il faut persévérer, on est tous passé par là et on finit par s'y faire.
S'il le faut, on peut même rajouter une p'tite bibliothèque de tests unitaires. Avec tout ça, on devrait bien réussir à vaincre cette «malédiction» !
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par totof2000 . Évalué à 2.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Johands . Évalué à 2.
Aie, j'ai beau avoir relu ces derniers mois des pages de C++, il m'aura fallu ce bon vieux wikipedia pour me remémorer ce qu'est l'Encapsulation_des_données. Alors effectivement, Python ne protège aucune donnée. Mais objectivement ça ne m'a jamais gêné : une règle tacite du python est que toute donnée précédée d'un '_' est interne à la classe. Si le programmeur y touche, il ne doit pas venir pleurer si un futur changement de version cassera son code.
Par contre, j'aimerais plus d'explication concernant :
cette fausse impression de sécurité que le langage te donne en te forçant à tout spécifier
Spécifier quoi ? Alors que justement mon principal reproche envers Python est qu' on n'y déclare rien et que tout y est implicite.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Batchyx . Évalué à 5.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Johands . Évalué à 1.
Je ne connaissais pas l'histoire des deux tirets de soulignement '__'. Après tests, il apparaît que seuls les attributs commençant par '__' et ne se terminant pas par '__' sont verrouillés. … histoire de rester consistant lorsqu'on décide de bidouiller __dict__ ou autre __class__.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Fabien PRORIOL . Évalué à 2.
a._Degage__pastouche
'lal'
C'est pratique en phase de debug, je l'utilise très souvent.... mais il suffit de se l'interdire dans le code 'normal'.
En python, on peut tout faire, tout parcourir... et c'est pratique, j'ai comme habitude de lancer par mon programme une 'pseudo-console-interpreteur-python' avec comme namespace, plusieurs variables de mon choix, de la, et par la console interactive, je parcours tout mes objets dynamiquement ce qui me permet de tester/modifier les valeurs en fonctionnement.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par El Titi . Évalué à 3.
Si tu te réfères à la page anglaise:
http://en.wikipedia.org/wiki/Encapsulation_%28object-oriente(...)
Tu verras que ces 2 notions sont distinctes même si elle sont souvent confondues.
Si on parle du principe d'embarquer les données avec les traitements dans une même entité autonome: l'objet, par opposition au langages procéduraux, l'encapsulation est parfaitement prise en charge par Python.
Le masquage de donnée est un autre principe qui est destiné à renforcer l'encapsulation en n'autorisant l'accès aux objets qu'au travers de leur contrat/interface.
Ce principe est sensé protéger l'intégrité de l'objet contre des manipulations hasardeuses de plusieurs attributs dont les valeurs seraient interdépendantes et de contrôler l'accès à la structure de l'objet. Il confère donc une certaine sécurité sur ces données. Il assure aussi en principe une séparation stricte entre contrat et implémentation qui permet de faire évoluer cette implémentation sans impacter le contrat (le fameux exemple des nombres complexes cartésiennes qui deveinnent polaires)
Dans la pratique que remarque t'on ?
L'inviolabilité de la structure n'est jamais assurée à partir du moment ou le langage propose l'introspection.
Une convention telle que celle de Python qui se charge simplement de prévenir qu'on la transgresse est amplement suffisant.
Dans 90% des cas, chaque attribut dispose de ses accesseurs et des trésors d'ingéniosité sont déployés pour simplifier cet accès (fonctions ds les IDE, annotations, syntaxiques : a.x=2 qui renvoie en fait à un appel de méthode qu'on peut modifier en cas de changement de nom d'attribut, ....)
Pourtant:
Si un attribut x public devient y.
Quelle est la différence entre casser le contrat dans le code appelant (attention au tests unitaires un must-have pour python) et celle d'en faire un privé et obliger à créer 2 nouveaux accesseur getY/setY et déclarer les accesseur getX/setX en obsolete.
Cette fameuse stabilisation des contrats n'est bien souvent qu'un miroir aux alouettes.
Je vous laisse débattre.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par barmic . Évalué à 2.
Je me permettrait juste de remarquer que quand tu parle de :
a.x=2 qui renvoie en fait à un appel de méthode
Ça reviens a avoir des accesseurs quand ils sont implicites c'est bien si tu veut que ton attribut soit publique. Si tu préfère avoir un contrôle fin de ce qui est "exporté" par ton objet et donc que par défaut tout soit privé tu est obligé de préfixé tout tes identifiants par __ si au bout d'un moment tu te rend compte que tel attribut peut/doit finalement être publique hop faut modifier l'identifiant partout où il est utilisé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par totof2000 . Évalué à 2.
En Ruby tu en as à la pelle des canards ..... Par contre ça ne me gène pas tant que ça, c'est un style de programmation qu'il faut connaitre et utiliser pour pouvoir l'apprécier.
Des langages fortement typés comme Haskell ou C/C++ et leurs descendants (Java, Vala?) ne conviendraient-ils pas mieux ? (je ne connais pas Ruby, je ne sais pas ce qu'il en est pour lui). Tant pis pour les fioritures et autres "boilerplate". On a des éditeurs de textes suffisamment puissants aujourd'hui pour ne plus s'en soucier. Tant pis également pour ce méchant compilateur qui n'arrête pas de nous taper sur les doigts. Il faut persévérer, on est tous passé par là et on finit par s'y faire.
C/C++ fortement typé ? Non je ne pense pas. A mon avis, si tu veux un langage fortement typé, c'est Ada qu'il faut utiliser. Mais dans beaucoup de cas c'est sortir l'artillerie lourde pour pas grand chose.
Je ne connais pas Haskell (il faudra que je m'y mette un jour pour voir). Par contre je me suis mis il y a quelques temps à Erlang. C'est un peu particulier, mais j'aime assez.
Sinon d'une manière générale, je pense que coder avec un langage "strict" ou déclaratif à l'extrême dans tous les cas de figure est contre-productif, et ce genre de langage devrait être utilisé que ans des cas particuliers.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par Johands . Évalué à 2.
Sinon d'une manière générale, je pense que coder avec un langage "strict" ou déclaratif à l'extrême dans tous les cas de figure est contre-productif, et ce genre de langage devrait être utilisé que ans des cas particuliers.
Hum, le problème des langages typés forts ou faibles est un troll sans fin. De même concernant les autres "aides" à la programmation plus ou moins directive. :)
Chacun ses préférences, la mienne consiste à écrire un programme ainsi : le problème initial, une feuille et un crayon de bois, cribouillages, cribouillages, puis rédaction sur ordinateur et enfin le compilateur ou la suite de tests qui sert de filet de protection en m'aidant à vérifier et à gommer mes étourderies. Je ne cherche pas un truc extrêmement typé comme l'Ada (c'est comme du VHDL ça ?), juste le minimum syndical disponible avec le C++ qui m'empêchera de confondre un string avec un tableau d'entiers.
Certainement un défaut dû à ma formation universitaire et à ses méchants modules concernant l'UML, hihi. Ou alors cela vient de mon inexpérience (professionnelle) en programmation : j'ai bien plus d'aisance à m'exprimer à travers une feuille de papier qu'à travers une ligne de code.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par barmic . Évalué à 3.
Sinon pour ce qui est C et C++, ce sont deux langages différents typés différemment : le C++ est typé bien plus fortement que le C (mais moins que l'ADA ou l'Eiffel).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par El Titi . Évalué à 3.
Le typage faible correspond au fait qu'un même objet peut être typé différemment en fonction du contexte dans lequel il est invoqué.
Ainsi Python est fortement et dynamiquement typé.
Un objet ne peut être que d'un type à la fois et un contrôle s'applique.
Perl est faiblement typé car une même variable peut-être vue comme une chaîne, un entier , ... en fonction de comment on l'invoque.
Le typage statique correspond au fait de déclarer les types de variables avant de les utiliser. L'intérêt est donc d'appliquer des contrôles de types losrqu'on compile ou qu'on assemble 2 bibliothèques à l'édition de lien alors que pour les langages dynamiques fortement typé ce contrôle n'a lieu qu' l'exécution (en prod ;-) d'où l'importance des test unitaires et de la couverture de code pour ces derniers.
Petit rappel
http://articles.sitepoint.com/article/typing-versus-dynamic-(...)
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par brendel . Évalué à 2.
Non, ça veut dire que le type des variable est connu à la compilation (c'est ce que tu dit après), mais pas que les type sont déclaré avant d'utiliser la variable. Le Caml est par exemple à typage statique mais les types ne sont pas déclarés avant d'utiliser les variables.
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par El Titi . Évalué à 2.
(Si ca existe ?)
Je reprécise: un langage statiquement typé déclare explicitement le type de ses variables et reste immuable au cours de l'exécution du programme.
C'est mieux comme ça ?
Le fait que ce soit connu à la compil , n'est qu'une conséquence.
Ainsi:
int i=5;
char i='a';
refusera de compiler en C
alors que
i=5
i='a'
passe très bien en python car son type est dynamique (en réalité le nom i est assigné à une nlle valeur)
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par brendel . Évalué à 2.
C'est mieux comme ça ?
Non, je te renvois a mon exemple du OCaml, le type des variable n'est pas déclaré explicitement dans le code. Pourtant, il dispose d'un typage statique, et il peut être interprété et compilé. C'est grâce à l'inférence de type.
http://fr.wikipedia.org/wiki/Inf%C3%A9rence_de_types
[^] # Re: Et pis .....thon n'est pas très TDAH-compliant, si ?
Posté par El Titi . Évalué à 2.
D'autre pensent que la créativité ne doit pas être bridée par la lourdeur syntaxique.
Le compilateur agit à priori et freine ta pensée en t'encombrant de règles syntaxique et au final te détournes de l'objectif initial, implémenter ton idée le plus vite possible.
Pourtant ces contrôles incontournables, pourraient être entrepris après.
Tu disposes de PyChecker avec Python qui appliquent ces contrôles à postériori.
Certains langages permettent même de démarrer avec un typage dynamique et autorisent à typer en statique progressivement.
[^] # Re: Et pis .....thon
Posté par dave . Évalué à 1.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
# Lance toi
Posté par gnumdk (site web personnel) . Évalué à 10.
J'avais entre temps découvert que GNU/Linux c'était encore mieux quand on avait accès à internet, et j'ai donc commencé à faire un peu de packaging pour Mandrake...
Au bout de 4 ans donc, un bug chiant dans ksysguard, je me motive, il faut que je regarde le code, j'ai peur, je vais rien comprendre, j'ai fait du C++ mais sur des serveurs HPUX en console, jamais de développement graphique...
Au bout d'une heure, je trouve un truc bizarre, je rajoute un ligne, wahou ca marche! J'envoie un patch et :
http://cia.vc/stats/project/kde/kdebase/ksysguard/.message/1(...)
Du coup par la suite, j'ai continué, y'a eu des patchs pour rien, 1 pour nautilus qui n'a pas été accepté car je corrigeais le problème mais pas au bon endroit, ca ma permit de regarder le boulot de F.Crozat et de comprendre pourquoi il faut bien assimiler tout le code avant de se lancer...
Des patchs pour amarok, pam, rekonq... Je me souviens plus de tout, mais au final, avec le temps, je peux être fier d'avoir apporter ma modeste contribution au logiciel libre...
J'ai aussi codé un ptit soft python y'a deux ans que j'essaye de maintenir même si je n'utilise plus mpd (mpdBrowser), j'ai voulu reprendre le code de gtk-qt-engine mais j'ai bloqué sur Firefox qui ne fait rien comme les autres donc j'ai laissé tombé, j'ai aussi un plasmoid en cours de dev mais pour l'instant je reste bloqué sur des bugs de jeunesse de plasma (enfin avec python en tout cas) donc j'ai mis en attente...
Ma plus grosse contribution restera quand même autour de compiz ou j'ai écris plusieurs patchs conséquents, qui n'étaient pas parfaits mais qui en les faisant évoluer font maintenant parti du soft qui est installé sur beaucoup de distrib par défaut... Et pourtant, quand je me suis lancé dans le code de placement des fenêtres, j'ai vraiment souffert, j'étais désespéré, "je n'y arriverai jamais" et pourtant...
Donc voila, il faut se lancer, le plus simple, c'est que lorsque tu trouves un bug dans un soft, tu fais un bug report, tu chope le svn/git, et tu cherches le bug, ca te permettra de voir le code d'autres personnes, de le comprendre, et d'avancer ;)
[^] # Re: Lance toi
Posté par GuiBrother . Évalué à 7.
tu peux aussi contribuer à l'amélioration des scripts et outils d'installation (via CMake, SCons, setuptools, qmake et beaucoup d'autre)
Il existe de nombreux logiciels libres (en particulier scientifiques) qui auraient vraiment besoin d'amélioration à ce niveau.
Je trouve qu'il n'y a pas plus frustrant que de tomber sur un programme qui "répondrai" exactement à ce que l'on cherche, qui utilise les algorithmes à la pointe, bref, le logiciel idéal mais ... impossible de l'installer.
Exemple sorti de mon imagination mais pas loin de la réalité pour certains programmes
->comprendre que ce programme utilise l'installeur exotique µInstaller.
->réussir à changer le préfixe d'installation (45min de lecture de doc)
-> enfin compris $delta tools/install/bin/myconfig --init --install-in=$HOME/local/
libmachin n'est pas installé ...
-> ah bah oui, il ne cherche que dans /usr/lib/Xyz alors que sur ma distrib c'est dans /usr/lib/abc
-> modification du script d'installation
erreur link libmachin ...
-> Cette fois il cherche à lier la version 32bit alors que tout le reste est en 64
-> modification du script d'installation
les 19 variables d'environnement ne sont pas initialisées
-> ./auto_init_env.sh
installation :
copie libprog dans /home/guibrother/local/lib
copie python2.2 dans /home/guibrother/local/lib (Mais pourquoi il me copie sa version locale de python ???)
copie icons dans /usr/share/icons/prog (Nooon, il a oublié de changer ce chemin)
ERROR pas les droits d'écriture
grrrrrrr, 2h de perdu pour ça, raz-le-bol, j'abandonne et je retourne sur mon vieux logiciel moins bien mais qui fonctionne
-> lance vieux-logiciel
erreur
-> quoi ???
(lui aussi utilisait 14 variables d'environnement dont deux en commun avec le programme précédent ...)
Bref, vous avez compris l'idée ;-)
Je pense que ce genre de contribution ne peut-être que bénéfique au logiciel libre...
Avis aux amateurs
# Infos
Posté par hugo (site web personnel) . Évalué à 5.
pourrais-tu en dire plus sur les gènes occasionnés par le TDAH ?
je pouvais écrire écrire des codes les plus beaux et les solutions les plus élégantes qui soient mais je bloquais très souvent, trop souvent, sur des bugs mineurs, bugs dus à des petites erreurs d'inattention
ça m'arrive aussi et une consultation sur la page sur wikipédia, notamment la liste des symptomes m'a mis un gros doute, j'ai plusieurs de ces symptomes, j'en tire aucune conclusion, c'est un peu comme l'horoscope, surtout que la liste est assez longue, on a vite fait de se retrouver dedans.
Est-ce avec plus de rigueur et de méthode et une belle phase de test, comme dans tout développemenent, tu ne peux pas t'en sortir haut la main, après tout, tu le dis aussi, c'est un maux qui toucherait pas mal de geek, comment il font eux ?
# "[Oh, mon frère,] je sens la douleur à ton côté, jumelle de la mienn
Posté par fero14041 . Évalué à 2.
Pourquoi nier ce désir, pourquoi renier cet appel? Ecrire du code est ta voie, et sa voix passe par toi.
Tu es bien mal en point, mon frère, mais tu possède tous les fermants nécessaires en toi, dans ton histoire et dans ton environnement pour atténuer cette douleur, calmer cette pulsion, assouvir cette soif... Et la communauté vers laquelle tu tends l'expression de tes sentiments est la réponse. Ton geste même la résume.
Oui, ton cas n'est pas isolé. Oui, d'autres individus ont des parcours chaotiques, faits de hauts et de bas. Aussi de peur, et d'échecs cumulés. (Coucou!) On parle trop de parcours réussis, d'individus brillants: n'y a-t-il de place que pour ceux-là? Il y a de la diversité dans les situations et les comportements, les idées et les projets.
Mes conseils (en dehors de se faire aider psycho-physiologiquement -- médicaments, psychothérapie -- et non, ce ne sont pas des termes grossiers!): lance-toi! Trouve un langage de prog. qui te convient, pas qui t'es imposé (par les autres, le marché, etc.). Créée, innove, essaye, note à propos de tes essais (sentiments, plus et moins, etc.).
Fais fructifier tous les temps que tu peux trouver, entre deux journées, pendant une pause, les transports, tous les points en rapport: lecture d'articles, de magazines, de livres, de blogs, de forums, de manuels, ... griffonne des bouts d'algos, des bouts d'archi., des idées, des possibilités de réalisation...
Regarde également du côté d'associations de passionnés, où rencontrer des semblables (et pourtant différents), comment participer. Balbutie dans ton coin, bâcle des protos projets, mais fais-le pour toi (et pour le Code, bien entendu). Regarde ce que tu peux faire pour/avec les autres. Marche (ne cours pas -- pas tout de suite ;-) !
Une possibilité: monte une vieille bécane comme serveur, installe-toi une forge, et avance à ton rythme. Un prof disait: "l'important est de toujours avancer, à son rythme, mais ne jamais s'arrêter!" Brouillone!
Et quand même pas d'accord sur un point: le code est peut-être le constituant de base du logiciel libre, ce n'est pas lui qui dira où/comment/quoi construire... Tu peut être un mauvais maçon et un très contre-maître. Ou un mauvais et un conseilleur de pierres hors-pair. Ou un mauvais et un bon architecte. Ou aussi un mauvais et un quand même un très bon tribun (etc.). Plus important que le code, les idées sous-jacentes à celui-ci, qui n'en devrait être que l'expression. Pour quoi veux-tu te battre, et donc te former/changer -- tout en ne te reniant pas?
[ma vie]
Perso: parcours universitaire en biologie, puis info, puis d'autres.
Langages: au début C/C++ (pas le choix pour le premier projet), puis Java (cours d'infos), et enfin Python (essai, puis adoption).
Projets: une nouvelle idée intéressante par mois (au moins), donc trop pour en mener un seul bien, au bout. Pas grave, on en lance d'autres...
[/ma vie]
[^] # Re: "[Oh, mon frère,] je sens la douleur à ton côté, jumelle de la m
Posté par Perthmâd (site web personnel) . Évalué à 8.
Pour quelqu'un qui veut faire du code ouvert, c'est plutôt un handicap !
[^] # Re: "[Oh, mon frère,] je sens la douleur à ton côté, jumelle de la m
Posté par Kopec . Évalué à 2.
[^] # Re: "[Oh, mon frère,] je sens la douleur à ton côté, jumelle de la m
Posté par lendemain . Évalué à 2.
# C'est en forgeant. qu'on devient....
Posté par ze_lionix (site web personnel) . Évalué à 6.
Garde à l'esprit que :
- Les programmes ont des bugs car ils sont fait par des hommes, et les hommes sont imparfait ! Tu as beau mettre toute l'attention du monde il y aura toujours un cas aux limites que tu n'auras pas pensé, un check de cas qui manque, ou un flux pourris ici....
- Tu te rendras compte que des fois en fixant un bug tu en induis un autre qui était masqué par le précédent... Et oui, mais ça va dans le bon sens : l'amélioration globale du code....
- C'est en forgeant qu'on devient forgeron : plus tu codes, plus tu fixes, le mieux tu vas coder.... A corriger des bug tu vas y penser "automatiquement" dès la conception....Quand je repense à ce que je pondais au début j'ai honte ( je ne testais pas systématiquement les paramètres, ne pensais pas aux attaques par injection....etc... )
Concernant ton "blocage" je te dirais ceci :
"Il n'y a que ceux qui ne font rien qui ne font pas d'erreur !"
Et pour l'avoir constaté j'ai enrichi l'adage de cela :
" Et ne rien faire peux aussi être une erreur ! "
Ami Geek prend ton clavier.... Et libère toi !
Car ces chaînes à tes mains c'est toi qui les a mis !
Fuse : j'en Use et Abuse !
[^] # Re: C'est en forgeant. qu'on devient....
Posté par Le Pnume . Évalué à 1.
[^] # Re: C'est en forgeant. qu'on devient....
Posté par ze_lionix (site web personnel) . Évalué à 4.
"Knuth has kept a very detailed log of all the bugs he has corrected and changes he has made in the program since 1982; as of 2008[update], the list contains 427 entries"
http://en.wikipedia.org/wiki/TeX
Fuse : j'en Use et Abuse !
[^] # Re: C'est en forgeant. qu'on devient....
Posté par Piour (site web personnel) . Évalué à 4.
[^] # Re: C'est en forgeant. qu'on devient....
Posté par Le Pnume . Évalué à 3.
# reconversion
Posté par B16F4RV4RD1N . Évalué à 10.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: reconversion
Posté par pipo_molo . Évalué à 1.
[^] # Re: reconversion
Posté par Davy Defaud . Évalué à 4.
Et rassure-toi, tu n'es pas le seul à avoir ce genre d'états d'âme ;-)
# Non je ne suis pas TDAH
Posté par marahi . Évalué à 2.
Je suis un peu étourdi, certes, mais je ne souffre en aucun cas de TDAH qui est une maladie "à la mode" aux States (et un peu en Europe depuis quelques années) et pour laquelle on donne (surtout aux petits enfants un peu turbulents) des substances que je ne sauraient prendre.
C'est juste une façon de dire que j'étais trop étourdi en programmation et qu'un petit bug que le noob de base pourrait débusquer le doigts dans le nez me prendrait des semaine voire un temps infini pour le corriger.
Pour anabiote, c'est en fait un néologisme que j'avais proposé, pour dire NO-LIFE en bon français, à un collègue. Il s'y connait un peu en grec et il a dit que c'était pas faux étymologiquement parlant, enfin c'est pas de l'étymologie mais si on combine les racines ana et bio, comme dans symbiote ... enfin, je me comprends.
[^] # Re: Non je ne suis pas TDAH
Posté par totof2000 . Évalué à 2.
Bah, ça ça vient avec l'habitude; Plus tu codes et moins tu fais ce genre d'erreurs.
J'ai fait du C, de l'assembleur sur microcontrolleurs variés, du c++, un peu de java, du Perl, du Python, du shell, awk, j'ai joué un peu avec Erlang, j'ai essayé smalltalk, et à chaque fois, au fur et à mesure que je développais je faisais de moins en moins d'erreur de ce genre. Le plus difficile c'est de switcher entre deux langages proches (je fais du Ruby et me suis remis un peu au python dernierement. Pas eu de mal à m'y remettre, mais curieusement, reswitcher vers Ruby a été un peu compliqué).
[^] # Re: Non je ne suis pas TDAH
Posté par campagnard . Évalué à 2.
Les auteurs de South Park ont fait un très bon épisode à ce sujet !
# Pas de maths obligatoire
Posté par Nicolas (site web personnel) . Évalué à 2.
J'ai commencé l'informatique/l'algorithmique au collège dans un club informatique avec un prof de latin.
J'ai eu la chance d'en faire au lycée (c'était il y a 20 ans; ça me fait mal d'écrire ça !) en discipline "normale" avec 3/4 heures par semaine avec un prof de latin/grec/français.
En y repensant, la logique algorithmique n'est pas si éloigné que ça de l'analyse d'une phrase en latin.
[^] # Re: Pas de maths obligatoire
Posté par Diagonale de Cantor (site web personnel) . Évalué à 4.
Après il est vrai que c'est une branche encore relativement indépendante du reste des mathématique, et le fait d'être nul en topologie algébrique ou en analyse complexe n'est pas du tout un handicape.
[^] # Re: Pas de maths obligatoire
Posté par Obsidian . Évalué à 2.
Cependant, l'informatique actuelle, c'est aussi énormément de technique, une histoire, une vaste communauté et des gens qui la font. Ramener toute l'informatique à la seule science du traitement de l'information − par laquelle il faudrait pourtant commencer car on tend à l'oublier −, c'est un peu comme affirmer que l'aviation se résume à une application de la mécanique des fluides.
[^] # Re: Pas de maths obligatoire
Posté par Diagonale de Cantor (site web personnel) . Évalué à 2.
Faux. Les sciences (physique, chime, ...) ne sont pas des maths. On appelle mathématique tous travaux sur des relations abstraites en objets, travaux ne reposant que sur la logique. De ce fait l'algorithmie est une branche des maths.
En ce qui concerne la linguistique, je n'ai pas lu les travaux de Kleene, mais àmha il a définit un modèle mathématique pour étudier la linguistique (tout comme le physicien utilise des équa diff), ce n'est pas pour autant que son travail n'est que des maths (utiliser des math et être des math, ce n'est pas la même chose).
Cependant, l'informatique actuelle, c'est aussi énormément de technique
Oui et ? Dans mon message, je ne parle pas de l'informatique (au sens général), mais de l'algorithmique (ce qui n'est qu'une branche de l'informatique).
Alors après, d'autre domaine de l'informatique (comme le matériel, la définition de nouveau langage, la création de norme, facebook, le porno...) ne sont pas des maths.
[^] # Re: Pas de maths obligatoire
Posté par Obsidian . Évalué à -1.
Le porno n'est pas un domaine de l'informatique. C'est une utilisation que l'on en fait et qui peut se faire sur d'autres médias. Ça n'a aucun rapport avec ce que l'on dit au dessus.
[^] # Re: Pas de maths obligatoire
Posté par Diagonale de Cantor (site web personnel) . Évalué à 4.
[^] # Re: Pas de maths obligatoire
Posté par Obsidian . Évalué à 1.
# Le code..
Posté par Grunt . Évalué à 2.
< ma vie >En fait j'ai commencé avec un 386 sous DOS 5, et surtout QBasic. J'arrivais à faire des trucs sympas avec, principalement dessiner des fractales (Mandelbrot, Julia), avec le soucis de l'optimisation (un simple commentaire dans une boucle, et le programme met 40H au lieu de 36 pour terminer la fractale. L'interprété ça pardonne pas).
Et puis j'ai découvert GNU/Linux et Internet, et là, grosse déception: les langages et les IDE modernes qui construisent les OS libres me semblent plus que rébarbatifs.< /ma vie >
Ceci dit, si quelqu'un connaît un IDE qui s'arrête pile poil sur la ligne fautive quand il y a une erreur dans le code, en renvoyant un message d'erreur avec une aide contextuelle, qui permet d'avoir de l'aide et des exemples pour chaque mot-clef du langage, qui permet d'interrompre l'exécution et de tester à la volée les variables en cas de comportement inattendu, avec un langage qui ne demande pas à se poser des questions existentielles du genre "faut que j'importe la lib biduletruc" avant d'écrire la moindre ligne, je prends.
Quelque chose du niveau de l'éditeur QBasic fournit avec MS-DOS 5, si c'est un peu plus gourmand en ressources c'est pas grave (j'ai changé de machine depuis).
Ça me manque de coder :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Le code..
Posté par Obsidian . Évalué à 3.
Un gros avantage, à mon goût, est que les instructions qui étaient disponibles − parce que le jeu d'instructions était statique − étaient bien choisies. On avait un PRINT qui savait faire des choses évoluées, on avait des fonctions de gestion de fichier, de disque, on avait PEEK et POKE pour écrire dans la mémoire, EXEC pour lancer un bout de langage machine, PLAY pour faire de la musique et LINE et BOX (ou assimilé), voire CIRCLE pour faire du graphisme. Avec une petite centaine d'instructions, on pouvait presque tout faire. Du coup, on pouvait se permettre de les assimiler et de connaître le langage par cœur.
Par contre, il arrive un moment où il est temps de devenir grand. Le BASIC, aujourd'hui, tu devrais être capable de le coder tout seul. :-) Tu ne dois pas devenir dépendant d'un IDE pour coder dans un langage. Par contre, en ce qui concerne [un truc] qui permet d'interrompre l'exécution et de tester à la volée les variables en cas de comportement inattendu, là c'est tout-à-fait le rôle d'un debugger. Bien souvent, celui-ci est intégré à l'IDE, ce qui fait qu'on ne fait pas la différence.
D'ores et déjà, si tu programmes en C, tu peux compiler ton programme avec l'option -g et le lancer sous gdb. Tu auras 90% de ce que tu cherches.
[^] # Re: Le code..
Posté par benoar . Évalué à 2.
# Tu n'es pas seul
Posté par J.V. FERNANDEZ . Évalué à 3.
Tu n'es pas seul dans ce cas...
Lycéen j'ai commencé à apprendre à programmer en ... LSE (ne cherchez pas, ça n'existe plus), c'était une sorte de langage BASIC francisé.
C'était un temps que les moins de 40 ans ne peuvent pas connaître.
Puis, nul en math, j'ai totalement changé d'orientation.
Note bien que je rejette la faute de ma nullité sur un professeur crasseux, fumeur et antipathique que j'avais eu au collège. Ils ont bon dos les profs, mais cela n'explique pas pourquoi d'autres réussissent avec les même.
Finalement, presque 2 ans après mon service militaire, je suis revenu à l'informatique.
Le projet GNU existait déjà, mais linux n'était même pas encore un songe de son créateur.
Au début, c'était alimentaire, sans plus de conviction, puis peu à peu, j'y ai repris goût.
J'ai maintenant plus de vingt ans d'expérience et il y a quelques années, je me suis dis que je devais me remettre à apprendre au moins les rudiments de C.
Ce fut une expérience intéressante, même si ma progression fut assez lente car j'ai tout fait en auto-formation.
Cela dit, même si je ne participe pas à des projets libres car mes compétences de programmeur ne sont pas assez développées, j'ai du plaisir à comprendre et à faire comprendre aux autres ce qu'est un logiciel libre.
Je peux leur donner des exemples, je peux les aider dans leur utilisation de ces produits.
J'ai donné des conférences jusqu'à une époque assez récente, quand j'avais le temps.
Le but du jeu n'est pas de programmer pour programmer, mais je pense qu'il faut participer chacun en fonction de nos compétences respectives.
Je pense que si on est pas un bon programmeur et qu'il est un peu trop tard pour le devenir, il y a bien d'autres moyens de participer.
Culpabiliser est une perte de temps.
Bien cordialement.
Jonas.
# Non
Posté par Zenitram (site web personnel) . Évalué à 7.
Non, ce n'est pas bloquant, je vis bien de programmation en ayant la même tare :)
C'est tout l'intérêt de faire le travail à plusieurs : un qui développe, un qui teste, etc... Du coup, on corrige au fur et à mesure (il y a toujours des bugs, partout. La question est de savoir les gérer)
Mais le code, c'est une écriture sacrée. Le code, c'est le nerf de la guerre et du software.
Non.
Le code n'est qu'une partie d'un logiciel. Le reste (la documentation, la soumission de rapport de bogues, le support technique...) est aussi importante.
C'est le problème de beaucoup de programmeurs : il font un joli logiciel, mais il reste dans l'oubli car il n'y a pas le reste.
[^] # Re: Non
Posté par dave . Évalué à 2.
Si le but c'est de faire des solutions élégantes, autant écrire du pseudocode et le publier sur wikipédia...
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
# Sortir par le haut
Posté par Ontologia (site web personnel) . Évalué à 5.
Ca fait du bien de lire ça, on se sent moins seul :-)
Moi je suis TDAH tendance procrastination. Alors j'ai maintenant choisi la même voie que toi pour pallier à ce même problème : ne plus faire de code dans son métier (je reprend dès septembre une formation en organisation/management).
Par contre, comme je suis rêveur et éternel insatisfait, je travail depuis quelques années à réinventer les langage de programmations.
En effet, je suis convaincu que le paradigme même qui sous tend ces derniers est intrinsèquement trop error prone.
Les langages de programmations, même de haut niveau sont trop orientés "machines" avec une sémantique beaucoup trop pauvre, qui ne prend en compte que la dichotomie, le test d'existance, l'affectation. Elle est la survivance directe des premiers ordinateurs manuellement cablés.
Pour des gens comme nous, qui n'avons pas la puissance et la rigeur logique des knuths et consorts, ils nous faut un outil de programmation adapté à notre cerveau, notre façon de pensée d'humain : ainsi on fera moins d'erreur et on pourra reprendre plaisir à programmer.
En ce qui me concerne, à part 2 ou 3 langages que je trouve "suportable" (prolog, ocaml, lisaac, ruby à la limite), ça devient trop pénible.
J'ai encore passé un mois sur un ensemble de bouclettes qui analyse un tableau html en gérant les spans : un vrai cauchemar.
En ce moment, pour mon futur langage, je travaille sur l'analyse du langage naturel, l'anglais en l'occurence pour faire des requêtes sur les données.
Cela a été initié entre autres par "chat 80", écrit en 1978-1981 en prolog par Warren (le type qui a inventé la Warren Abstract Machine) et Pereira
http://www.cis.upenn.edu/~pereira/oldies.html
Chat80 permet de répondre à des question assez couillues.
Exemple de dialog, que je copie de mon terminal :
% chattop.pl compiled 0.01 sec, 0 bytes
XPCE 6.6.66, July 2009 for i386-darwin9.8.0 and X11R6
Copyright (C) 1993-2009 University of Amsterdam.
XPCE comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
The host-language is SWI-Prolog version 5.8.3
For HELP on prolog, please type help. or apropos(topic).
on xpce, please type manpce.
?- hi.
Question: Which country bordering the Mediterranean borders a country that is bordered by a country whose population exceeds the population of India?
turkey.
On peut tracer son exécution, c'est assez marrant
Question: trace.
Tracing from now on!
Question: Which country bordering the Mediterranean borders a country that is bordered by a country whose population exceeds the population of India?
Parse: 0msec.
whq
$VAR(1)
s
np
3+sin
np_head
int_det($VAR(1))
[]
country
reduced_rel
$VAR(2)
s
np
3+sin
wh($VAR(2))
[]
verb(border, active, inf, [prog], pos)
arg
dir
np
3+sin
name(mediterranean)
[]
[]
verb(border, active, pres+fin, [], pos)
arg
dir
np
3+sin
np_head
det(a)
[]
country
rel
$VAR(3)
s
np
3+sin
wh($VAR(3))
[]
verb(border, passive, pres+fin, [], pos)
[]
pp
prep(by)
np
3+sin
np_head
det(a)
[]
country
rel
$VAR(4)
s
np
3+sin
np_head
det(the(sin))
[]
population
pp
poss
np
3+sin
wh($VAR(4))
[]
verb(exceed, active, pres+fin, [], pos)
arg
dir
np
3+sin
np_head
det(the(sin))
[]
population
pp
prep(of)
np
3+sin
name(india)
[]
[]
[]
Semantics: 0msec.
answer([$VAR(0)]) :-
country($VAR(0))
& borders($VAR(0), mediterranean)
& exists $VAR(1)
country($VAR(1))
& exists $VAR(2)
country($VAR(2))
& exists $VAR(3)
population($VAR(2), $VAR(3))
& exists $VAR(4)
population(india, $VAR(4))
& exceeds($VAR(3), $VAR(4))
& borders($VAR(2), $VAR(1))
& borders($VAR(0), $VAR(1))
Planning: 0msec.
answer([$VAR(0)]) :-
exists $VAR(1) $VAR(2) $VAR(3) $VAR(4)
population(india, $VAR(4))
& borders($VAR(0), mediterranean)
& {country($VAR(0))}
& { borders($VAR(0), $VAR(1))
& {country($VAR(1))}
& { borders($VAR(2), $VAR(1))
& {country($VAR(2))}
& { population($VAR(2), $VAR(3))
& {exceeds($VAR(3), $VAR(4))} } } }
turkey.
Reply: 0msec.
Ya trois étapes : le parsing avec analyse grammaticale, la transformation en requete logique, et le planning où la requete est améliorée.
Bref, c'est possible.
Ce langage sera aussi basés sur des paradigmes vraiment nouveaux, mais je vous en reparlerai en temps voulu.
Bref, tout ça pour dire, que d'une part l'humain, c'est mieux qu'une machine au quotidien. Et d'autre part, nos outils de programmations sont peut être pas adaptés.
Et je n'accepte pas (pour moi, les gens font ce qu'ils veulent) les messages de résignations que je lis tout le long du style "c'est en forgeant qu'on devient forgeron", "code plus, tu feras moins de bugs".
Je code beaucoup depuis l'age de 11 ans, et je fait encore bcp trop de fautes d'innatention, c'est donc un problème de cerveau ET de langage.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Essais le Test-driven development !
Posté par case42 (site web personnel) . Évalué à 1.
Écris tes tests avant d'écrire ton code! Écrire les tests équivaut a écrire une spec de ton code, mais une spec qui vérifie ton code!
Tu veux une nouvelle fonctionnalité dans ton programme? Tu écris un ou des tests. Puis tu code jusqu'a ce que tous les tests passent. Tu ne peux pas oublier un bout par inattention, car tu as les tests pour te le rappeler. Si tu as oublier d'écrire des tests pour certaines parties, tu les écris, puis tu ecris le code pour que les tests passent. Si tu trouve un bug, tu ecris un test qui le verifie, puis tu ecris le code qui corrige le bug. Le bug ne peut jamais revenir, ou tu le sauras grace au test. C'est une super méthode anti-étourderie, et ca produit un code super robuste.
http://en.wikipedia.org/wiki/Test-driven_development
my 2 cents.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.