(damn)

il y a bien des editeurs qui essayent de se placer au dessus de latex pour utiliser le moteur de rendu, mais c'est souvent assez peu convaincant et on finit tojours par aller ecrire le latex sous jacent.

Regarde du coté de TexMacs. C'est l'alternative la plus sérieuse à Tex+dérivé que je connaisse.

_skip: « je suis […] contre cette idée reçue que moins de lignes de codes c'est mieux. » tu peux développer ? Ton avis sur ce point m'intéresse.

Je crois que celui la n'a pas ete fait :

write(1, "blabla", 6);

(suite de la discussion https://www.jeuxvideo.com/forums/1-47-52353-3-0-1-0-conseil-distrib-linux-pour-programmeur.htm#message_52645 )

bonne suggestion chris, le blabla est plus approprie.

Ce que je voulais dire pour dire que ce n'est pas utile, c'est que pour que je demarre gdb, il faut que mon codene declenche aucune des assertion que j'ai pu mettre dans le code et que valgrind ne reporte pas une erreur et qui ne me permette pas de raffinner mes assertions pour comprendre ce qui se passe. Dans ce cas la, je vais lancer mon debugger.
Mais dans ces cas la, les structures de donnees sont bien trop merdiques pour etre afficher automatiquement par n'importe quel outils code-agnostique. J'ai souvent des structures compliques qui font de l'indirection vers elle meme. Des valeurs dont le signe change completement leur sens. Si je n'ai pas mon bout de code a moi qui affiche les informations, je ne verrais rien. Dans un cas comme ca, gdb, ddd, ou n'importe quoi ca ne sert pas a grand chose.

Donc du coup, mon usage avance d'un debugger arrive quand:
-le bug n'est pas trivialement detecte par valgrind ou un de mes assert
-le bug n'est pas detecte apres avoir affiche le contenu de trois valeurs
-des fonctions d'affichage custom ne sont pas disponible

En bref, ca ne m'arrive pas souvent

1. Ignorer Chris_27 Chris_27 Voir le profil de Chris_27
2. Posté le 19 janvier 2011 à 13:21:45 Avertir un administrateur
3. _skip: « je suis […] contre cette idée reçue que moins de lignes de codes c'est mieux. » tu peux développer ? Ton avis sur ce point m'intéresse.

N'importe quel outil de code-métric te dira formellement que plus ton projet comprend de lignes de code, plus il a de risque de bugs et plus il est difficile à maintenir.
Le truc que tu retrouves sur chaque blog et dans la bouche de chaque évangéliste python: c'est un code en java bien moche style lecture de fichier avec buffer qui fait 20 lignes, et de l'autre côté le super code magique en python qui te permet de tout faire sur 5 lignes.
Et la moitié du temps ces exemples sont encore biaisés parce que le code qu'on te montre ne comprend aucune gestion d'erreur et part du principe que t'es incapable, à partir d'une API assez low level, de te coder une fonction qui fait la même chose qu'une fonction standard d'un langage de plus haut niveau.

Et moi, pour ce que je vois de tous ces langages à la mode, je te dirai que je préfère maintenir 10000 lignes de java plutôt que 2000 lignes de ces codes-scripts magiques que je vois partout. Justement pour certains on dirait que c'est le concours de celui qui met le plus de merde sur une ligne : style "machin égal closure de truc * variable contenant une fonction". Quand je lis une classe, j'aime bien que les membres soient déclarés implicitement et n'apparaissent pas par magie au moment où on les utilise... Bref tout ça quoi.

Mais enfin je ne veux pas cracher sur les langages de scripts parce qu'ils ont leur utilité, mais plutôt sur cette mode de croire que plus on utilise de boîtes noires, moins on a de travail et plus c'est merveilleux. Si je continue avec java parce que c'est le langage que j'utilise le plus professionnellement, les technos qui gravitent autour, principalement dans le monde J2EE ont tendance à devenir extrêmement complexes. La raison de cet état des choses, c'est qu'on veut que le développeur tape le moins de code possible et qu'un "framework" fasse le gros du boulot. Et souvent ces frameworks ont la fâcheuse tendance à abuser du concept DRY et à chercher des simplifications là où le langage n'est pas censé le permettre.
Du coup, le développeur qui bosse avec ça il commence à décrire des structures en XML qui génèrent ensuite automatiquement (au runtime) des objets bricolés à grand coup de réflexion et finalement injectés par annotation dans tous les sens, avec d'obscurs intercepteurs AOP et j'en passe et après on finit avec des applications qui tournent sans que personne sache comment! On sait juste que si on touche quelque chose ça explose...

Et c'est ça l'état de fait que je trouve que désastreux : pour essayer d'écrire moins de code on a recours à des technos qui font des choses qui sont en bien des points comparables à de la magie vaudou. Et généralement il suffit que les soucis de performance ou les erreurs bizarroïdes arrivent pour se rendre compte qu'on maîtrise rien de ces technos. Je pense même que 90% des utilisateurs de frameworks tels que Spring ont jamais regardé son code.

En gros, je commence à trouver qu'on sacrifie beaucoup trop de chose sur l'autel du "write less code". La facilité à maintenir un projet, elle passe par sa documentation, la qualité de son organisation et l'efficacité de ses tests unitaires. C'est pas du tout une histoire de nombre de ligne de code dans une fonction.

Pour information, DRY veut dire "Don't Repeat Yourself". Le concept est decris sur wikipedia : http://en.wikipedia.org/wiki/DRY

https://www.jeuxvideo.com/forums/1-47-52749-2-0-1-0-c-probleme-de-compilation-et-autre.htm#message_52807

_skip, oserai tu dire qu'il vaut mieux faire du procedural avant de faire de l'objet dans le cadre d'un apprentissage coherent? Fais gaffe il y a des inquisiteurs qui vont te bruler!

(Mais promis, je te defendrai)

Je dois faire gaffe parce que je peux me tromper dans les termes parfois. En tout cas, aucun bouquin de c++ que je connais (et je dois en posséder 3 sans compter ceux dont je me suis débarrassé) n'a jamais commencer par des classes.

Ca me paraît logique de commencer par des opérations simples sur des variables, puis passé aux boucles, tableaux, aux fonctions etc... Et quand j'ai fait mes études, on a peut être fait 1 semestre entier avant d'aborder les notions OOP.

Donc oui, à mon avis écrire des classes avant d'avoir de solides connaissances en programmation (procédurale / impérative / non OO je me mélange parfois les termes) c'est brûler les étapes.
Lorsque les petits programmes qu'on bricole deviennent complexes, les bénéfices de l'encapsulation apportés par l'OOP apparaissent plus clairement, et à titre personnel je trouve ça bien de savoir que l'OOP est pas la réponse à tous les problèmes.

skip, je suis d'accord avec toi. Ma reflexe etait ironique vers une fraction des gens (souvent des debuttants) qui crient au scandale des qu'on parle de faire autre chose que de l'objet. Parceque l'objet c'est le bien (TM).

printf("Salut les noobs !");

Do not feed the troll

« Et c'est ça l'état de fait que je trouve que désastreux : pour essayer d'écrire moins de code on a recours à des technos qui font des choses qui sont en bien des points comparables à de la magie vaudou. » je ne peux que penser aux "magnifiques" autotools et plussoier là.

Godrik tes modérateur ici ?
J'en apprend tout les jours

Allez, j'en fais profiter tout le monde :
http://dfan.org/writing/coding.html

Bah, dans ce cas-là, moi non plus.
Pour ceux qui ne connaissent pas : http://thedailywtf.com/

bonjour tout le monde, j'ai une question

la fonction rand(), en C, modulo un nombre environ égal à 400000, c'est normal qu'elle aie tendance à privilégier les nombres du début?

oui. rand() et modulo c'est le mal: lire "the art of computer programming" ou "numerical recipes" (je ne sais plus lequel) au sujet des generateur lineaire a congruence.

Pour faire un nombre uniformement aleatoire entre 0 et N on prefere ((float)rand())/RAND_MAX*N

Et d'ailleurs, j'avais d'experience des generateurs bien meilleur quand j'utilisais drand48().

effectivement, ca marche bien mieux. Merci godrik

je faisais un programme qui dessine des carrés et les fait grandir jusqu'a ce qu'ils touchent un bord, ou un autre carré, bref...

avant, j'avais ça:

http://sournoishack.com/uploads/SF1.PNG

ah okay

après:

http://sournoishack.com/uploads/SF2.png

la différence est sans appel!

quand aux livres... ca s'achète à la fnac? il y a eu une discussion dessus, récemment, je devrais peut-être m'y mettre

T'aimes bien faire des programmes qui dessinent plein de trucs partout toi.

je ne vais pas occuper mon temps libre en programmation pour des logiciels de comptabilité