Tout cela me fait poser la question de compatibilité entre les wikis. Exemple : J'utilise un twiki assez vaste (avec une partie utilisée comme un blog collaboratif grâce à un flux RSS sur les pages d'une catégorie donnée), quelles sont les possibilités de migration vers un autre moteur de wiki ? Comment assurer la pérénité du contenu ?
Mes livres CC By-SA : https://ploum.net/livres.html
Si tu peux relancer l'appli en cliquant sur son icône, où est l'intérêt du tray icon ?
Ton analogie a beaucoup de sens. Le fait de jouer la musique fait donc (d'un point de vue utilisateur) partie intégrante du système lui-même. Le "lecteur" n'est qu'une interface pour dire play/pause/next et choisir la chanson. J'aime beaucoup cette vision (je crois, sans en être sûr, que c'est la façon de fonctionner de MacOSX).
Mais je ne vois toujours pas en quoi un tray icon a avoir avec tout ça.
Justement, le tray icon est une survivance de "je veux cacher la fenêtre mais sans la fermer tout à fait, je veux savoir si le programme tourne ou pas", ce qui, en soi, n'a aucun intérêt pour la plupart des utilisateurs. (la seule utilité pourrait être d'éviter d'utiliser trop de mémoire en ayant un lecteur audio lancé mais c'est une préoccupation compréhensible uniquement que par une minorité de geeks. Le tray icon symbolise donc le fait qu'une partie de la mémoire est actuellement allouée a un programme qui est lancé mais non utilisé, ce qui est un concept encore plus complexe que tout le reste)
Mes livres CC By-SA : https://ploum.net/livres.html
Si tu manques de place, il existe les bureaux virtuels, qui sont une métaphore étonnament facile à comprendre (surtout pour les personnes non-habituées à Windows).
Par contre, le fait que certaines fenêtres se "cachent" au lieu de se fermer, dans une zone toute petite, c'est complètement anti-ergonomique. C'est extrêmement marquant avec les nouveaux utilisateurs.
Mes livres CC By-SA : https://ploum.net/livres.html
hihi, c'est vrai que c'est pas mal. Et autour de moi, le principal argument en faveur de Java est "Tout le monde utilise Java". Qui est un argument tout à fait recevable, il est vrai, mais un peu dommage quand même...
Mes livres CC By-SA : https://ploum.net/livres.html
le débat sur les multicores me fait rigoler vu que la majorité des programmes C, C++ ou Java n'exploitent pas non plus le multicore.
Perso, je vois le multicore comme une opportunité de faire tourner des processus différents, pas de gagner en perf sur mon programme monoprocessus. D'ailleurs, si les perfs sont si importantes pour ton programme, tu ne l'écris pas en Java ou en Python.
Je trouve donc que la discussion n'a pas beaucoup de sens et qu'avant d'optimiser un programme pour qu'il utilise le multi-core, il faut d'abord avoir le programme complètement fonctionnel et optimisé au poil sous tous les autres aspects.
Mes livres CC By-SA : https://ploum.net/livres.html
c'est pas parce que ça s'adresse à des développeurs que tu dois faire tout en dépit du bon sens. Genre le menu en clic droit qui est "presque" le même que le menu dans la barre d'outils. Manque de bol, y'a une ou deux fonctions qui sont pas les mêmes.
Eclipse n'a tout simplement pas d'interface : c'est juste plein de fonctions (très puissantes et utiles, je l'admet) auxquelles on a assigné des bouttons et puis on a lancé ces bouttons au hasard dans une grosse fenêtre. Lotus Notes est comme ça, Open Office est dans le même genre. C'est la philosophie de GUI des années 90 quoi.
Mes livres CC By-SA : https://ploum.net/livres.html
Je trouve qu'Eclipse est un monstre en termes de ressources, qu'il est complètement anti-ergonomique (et encore) mais, fonctionnellement, je reconnais que ce genre de fonctionnalité est très utile quand on développe.
Mes livres CC By-SA : https://ploum.net/livres.html
Ton "c'est très clair" ressemble beaucoup plus à une explication a fortiori qu'à une logique de départ.
D'ailleurs je te suggère d'essayer de l'expliquer à une personne qui n'a jamais touché un ordinateur, tu verras comme c'est non intuitif. (la taskbar ne l'est pas plus d'ailleurs)
Mes livres CC By-SA : https://ploum.net/livres.html
"juste apparaitre temporairement en notification lorsqu'il y a un message"
C'est comme ça que j'utilise pidgin perso. Et pour ceux qui veulent connaître leur status en permanence, il y a le fast-user-switcher applet qui le fait. (par défaut sous Ubuntu 8.10)
Mes livres CC By-SA : https://ploum.net/livres.html
ça se défend mais l'important c'est de garder un comportement constant entre les applis. Or ici il n'y aucun moyen de prédire si une application donnée va quitter ou juste être cachée quand on clique sur la croix, c'est ça que je reproche.
Mes livres CC By-SA : https://ploum.net/livres.html
C'est pas bien d'utiliser le compte linuxfr de ton papa pour troller. Tu sais, troller c'est comme fumer et rouler à fond : faut être un grand pour pouvoir le faire.
Alors tu retournes à Gcompris et qu'on ne t'y prenne plus.
Mes livres CC By-SA : https://ploum.net/livres.html
Euh, la zone de notification de Pidgin est facultative et, justement, la HIG considère que "c'est mal" de mettre une icône de manière permanente dans la zone de notification.
Celui qui met le plus de temps, c'est celui qui a deux commandes à taper. Ce n'est que ce que je dis depuis le début. Bien sûr que Python compile de la même manière qu'une voiture automatique change de vitesse : je m'en fous, il fait juste ce que je veux.
Mes livres CC By-SA : https://ploum.net/livres.html
ça a été fait d'un jet à une heure du mat, complètement crevé et sans relire et de manière non-linéaire (j'ai écrit les mois puis j'ai rajouté des trucs par-ci par-là au feeling). Cela explique (sans excuser) les fautes et les incohérences... désolé.
Mes livres CC By-SA : https://ploum.net/livres.html
oui mais, par définition, tout code que tu écris te parle sur le moment. Mais pas 2 mois plus tard.
Personnellement, je suis en train de tester une nouvelle approche : plutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.
Mes livres CC By-SA : https://ploum.net/livres.html
"Bof. Quand on est habitué, un code java est tout à fait lisible."
Un truc qui me fait peur avec les "experts J2EE", c'est qu'ils m'ont tous toujours tenu le même discours concernant la lisibilité du code :
- Les commentaires sont inutiles, un bon code parle de lui-même.
- Il faut écrire le moins de lignes possibles : pas d'espaces entre les classes, pas de commentaires "inutiles"
- Les commentaires nuisent à la lisibilité du code (sic).
Bon, ce n'est évidemment pas lié au langage mais je trouve significatif que tous les chefs de projets J2EE (et certains C++) m'aie sorti, à peu de choses près, ce genre de choses. Et généralement ces règles sont même écrites sur la page Coding Rules du wiki !
J'ai pour habitude, lorsque j'ai pris du temps à comprendre un bout de code, de mettre un commentaire expliquant ce que j'ai compris (histoire de pas devoir refaire le boulot). Durant ma brêve carrière J2EE, ces commentaires étaient systématiquement effacés par les commit après moi.
Mais je reconnais 100% que ce n'est pas techniquement lié au langage. Je pense que cela fait plus partie d'une culturee très présente dans le milieu J2EE.
Mes livres CC By-SA : https://ploum.net/livres.html
Je sais pas pourquoi vous vous tuez à vous acharner pour m'expliquer le fonctionnement d'un compilo. Je sais bien que ça fait plein de trucs et que ça trouve des erreurs. Mais ces erreurs là, je les trouve aussi en Python en lançant mon code. Et tout ce que fait le compilo "en plus", ça ne justifie pas le fait de compiler (dont la définition est de produire un exécutable, je le rappelle. On ne compile pas pour vérifier son code, c'est une conséquence, pas un but).
Depuis le début, j'explique que je critique la nécessité de "compiler" à chaque fois dans un environnement de dev. Je ne critique pas le fait de checker le code et d'optimiser car c'est très utile mais, en cours de dev, ça devrait juste être facultatif.
Mes livres CC By-SA : https://ploum.net/livres.html
Vu le nombre d'offres d'emploi que je vois pour des dev django dans les sites spécialisés, je me dit que ça commence à devenir sérieux. Je connais même des spécialistes J2EE qui se sont retrouvé à apprendre Django pour des missions de quelques mois. Le marché évolue, c'est comme tout le reste.
Personnellement, j'ai un gros problème avec Java (alors que c'est avec Java que j'ai commencé l'informatique, que j'ai failli abandonné le domaine jusqu'au jour où j'ai découvert le C). Et j'aime troller. Du coup, on comprend mieux mes messages ;-)
Mais plus sérieusement : J2EE est bien (waw, ça me fait mal de le dire). C'est la solution actuelle. Mais J2EE est devenu trop complexe, trop gros. Le futur est à des outils plus légers dont, je pense, font partie Django et Python. Et eux-même seront remplacés par autre chose dans quelques années, c'est l'évolution qui veux ça. Et selon que l'on soit conservateur, que l'on soit confronté à des problèmes présents, urgents et concrets ou que l'on soit idéaliste, rêveur et un peu visionnaire, on soutiendra Cobol, J2EE ou Python. Et dans quelques années, on rechangera...
Mes livres CC By-SA : https://ploum.net/livres.html
Je renonce à argumenter plus car je ne ferais que me répéter. Je comprend ton argument comme "Un compilateur comporte un vérificateur de code dont on doit utiliser un compilateur plutôt qu'un vérificateur de code dédié" et cela ressemble à un sophisme.
Mais juste une note pour Ant : j'aurais du préciser que j'écris ce script qui compile/lance sauf en python où c'est automatique. Le fait que Ant existe est la preuve que c'est une faiblesse du java mais Ant est justement un outil de plus à apprendre.
Ce que j'essaye d'expliquer c'est que, plus tu rajoutes des outils, plus tu complexifies et plus tu vas rajouter des outils pour simplifier. C'est une voie de garage par excellence et c'est complètement anti-productif. ("j'ai passé seulement 2heures et j'ai un super script Ant." Super. C'est 2h que tu n'as pas passé sur ton produit).
Je vais faire plus simple : j'ai deux machines qui font un travail. La première comporte un gros boutton rouge. La seconde comporte 5 bouttons : rouge, vert, mauve, jaune, bleu. Le manuel de la première explique qu'il faut appuyer sur le boutton pour la mettre en marche ou pour l'arrêter si elle est en marche. Le manuel de la seconde explique que le boutton mauve est un préchauffage, le boutton bleu l'initialisation, le boutton vert le lancement, le boutton rouge la confirmation du lancement et le boutton jaune l'arrêt de la machine.
Et toi, tu es en train de défendre que c'est logique d'appuyer sur le boutton bleu parce que, forcément, il faut bien initialiser la machine et que c'est une machine super facile à utiliser vu que quand tu veux la lancer il suffit de faire mauve, bleu, vert, rouge et encore, le mauve n'est pas toujours nécessaire, t'es pas obligé d'appuyer dessus si l'indicateur de température dépasse une certaine valeur.
Mes livres CC By-SA : https://ploum.net/livres.html
Dans ce cas, il faut utiliser un vérificateur de code où quoi que ce soit d'autres. Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.
De plus, quand tu développes, tu peux vouloir tester une fonction tout en sachant que le reste n'est pas encore développé. Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
L'utilisation du compilateur comme un indicateur de la qualité du code est l'un des trucs les plus effrayant qu'on puisse sortir pour justifier la compilation. Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
"La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule "
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps". Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois ("sinon y'a des erreurs du à des trucs pas recompilé mais qui devraient l'être (sic)"). Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Et quand bien même le temps serait vraiment ridicule, ce n'est pas une justification : tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Lors du développement d'un soft, personnellement je finis toujours par écrire un script qui compile, fais tout ce qu'il faut et qui lance le soft. Je modifie le code, lance mon script pour tester, modifie le code, lance le script, ...
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Mes livres CC By-SA : https://ploum.net/livres.html
Ta comparaison est complètement foireuse. Le programmeur, il ne connait que le langage de programmation. Il n'a pas besoin de savoir comment c'est implémenté. Tu peux être un excellent programmeur et ne pas savoir ce qu'est un transistor.
Par contre il doit connaitre, en plus du langage de programmation des tas d'outils pour faire fonctionner son langage de programmation et encore d'autres outils pour faire fonctionner les outils.
Se compliquer la vie pour tenter de la simplifier, c'est voué à l'échec sur le long terme, faut pas chercher très loin pour s'en rendre compte. Lorsqu'un programmeur passe 2 semaines pour réussir à compiler un projet sans toucher une ligne du projet lui-même (juste les makefile et les configure), n'importe qui avec un peu de recul dirait "mais c'est quoi ce délire ?". Mais bon, le nez dans le guidon est le lot de90% des gens. Y'a peu de gens qui se posent la question "mais au fond, c'est quoi le résultat qu'on aimerait avoir ?". Le problème de la vie c'est que poser cette question, c'est remettre en question le travail, les acquis, la souffrance endurée les années précédentes. Alors, on préfère se convaincre que la question ne doit pas être posée.
# Migration
Posté par ploum (site web personnel, Mastodon) . En réponse à la dépêche Sortie de la version initiale de Foswiki - fork de TWiki. Évalué à 4.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 2.
Ton analogie a beaucoup de sens. Le fait de jouer la musique fait donc (d'un point de vue utilisateur) partie intégrante du système lui-même. Le "lecteur" n'est qu'une interface pour dire play/pause/next et choisir la chanson. J'aime beaucoup cette vision (je crois, sans en être sûr, que c'est la façon de fonctionner de MacOSX).
Mais je ne vois toujours pas en quoi un tray icon a avoir avec tout ça.
Justement, le tray icon est une survivance de "je veux cacher la fenêtre mais sans la fermer tout à fait, je veux savoir si le programme tourne ou pas", ce qui, en soi, n'a aucun intérêt pour la plupart des utilisateurs. (la seule utilité pourrait être d'éviter d'utiliser trop de mémoire en ayant un lecteur audio lancé mais c'est une préoccupation compréhensible uniquement que par une minorité de geeks. Le tray icon symbolise donc le fait qu'une partie de la mémoire est actuellement allouée a un programme qui est lancé mais non utilisé, ce qui est un concept encore plus complexe que tout le reste)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 0.
Par contre, le fait que certaines fenêtres se "cachent" au lieu de se fermer, dans une zone toute petite, c'est complètement anti-ergonomique. C'est extrêmement marquant avec les nouveaux utilisateurs.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 2.
Bon, va falloir que je me lance dans la bataille alors.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Perso, je vois le multicore comme une opportunité de faire tourner des processus différents, pas de gagner en perf sur mon programme monoprocessus. D'ailleurs, si les perfs sont si importantes pour ton programme, tu ne l'écris pas en Java ou en Python.
Je trouve donc que la discussion n'a pas beaucoup de sens et qu'avant d'optimiser un programme pour qu'il utilise le multi-core, il faut d'abord avoir le programme complètement fonctionnel et optimisé au poil sous tous les autres aspects.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Eclipse n'a tout simplement pas d'interface : c'est juste plein de fonctions (très puissantes et utiles, je l'admet) auxquelles on a assigné des bouttons et puis on a lancé ces bouttons au hasard dans une grosse fenêtre. Lotus Notes est comme ça, Open Office est dans le même genre. C'est la philosophie de GUI des années 90 quoi.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 4.
D'ailleurs je te suggère d'essayer de l'expliquer à une personne qui n'a jamais touché un ordinateur, tu verras comme c'est non intuitif. (la taskbar ne l'est pas plus d'ailleurs)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 2.
C'est comme ça que j'utilise pidgin perso. Et pour ceux qui veulent connaître leur status en permanence, il y a le fast-user-switcher applet qui le fait. (par défaut sous Ubuntu 8.10)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 6.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: amsn
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 10.
Alors tu retournes à Gcompris et qu'on ne t'y prenne plus.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 3.
http://bugzilla.gnome.org/show_bug.cgi?id=317982
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Modifie les!!!
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 5.
Lire à ce sujet la discussion à propos d'empathy :
http://bugzilla.gnome.org/show_bug.cgi?id=467829
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: C'est trop drôle
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Personnellement, je suis en train de tester une nouvelle approche : plutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Un truc qui me fait peur avec les "experts J2EE", c'est qu'ils m'ont tous toujours tenu le même discours concernant la lisibilité du code :
- Les commentaires sont inutiles, un bon code parle de lui-même.
- Il faut écrire le moins de lignes possibles : pas d'espaces entre les classes, pas de commentaires "inutiles"
- Les commentaires nuisent à la lisibilité du code (sic).
Bon, ce n'est évidemment pas lié au langage mais je trouve significatif que tous les chefs de projets J2EE (et certains C++) m'aie sorti, à peu de choses près, ce genre de choses. Et généralement ces règles sont même écrites sur la page Coding Rules du wiki !
J'ai pour habitude, lorsque j'ai pris du temps à comprendre un bout de code, de mettre un commentaire expliquant ce que j'ai compris (histoire de pas devoir refaire le boulot). Durant ma brêve carrière J2EE, ces commentaires étaient systématiquement effacés par les commit après moi.
Mais je reconnais 100% que ce n'est pas techniquement lié au langage. Je pense que cela fait plus partie d'une culturee très présente dans le milieu J2EE.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Depuis le début, j'explique que je critique la nécessité de "compiler" à chaque fois dans un environnement de dev. Je ne critique pas le fait de checker le code et d'optimiser car c'est très utile mais, en cours de dev, ça devrait juste être facultatif.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
Personnellement, j'ai un gros problème avec Java (alors que c'est avec Java que j'ai commencé l'informatique, que j'ai failli abandonné le domaine jusqu'au jour où j'ai découvert le C). Et j'aime troller. Du coup, on comprend mieux mes messages ;-)
Mais plus sérieusement : J2EE est bien (waw, ça me fait mal de le dire). C'est la solution actuelle. Mais J2EE est devenu trop complexe, trop gros. Le futur est à des outils plus légers dont, je pense, font partie Django et Python. Et eux-même seront remplacés par autre chose dans quelques années, c'est l'évolution qui veux ça. Et selon que l'on soit conservateur, que l'on soit confronté à des problèmes présents, urgents et concrets ou que l'on soit idéaliste, rêveur et un peu visionnaire, on soutiendra Cobol, J2EE ou Python. Et dans quelques années, on rechangera...
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 4.
Mais juste une note pour Ant : j'aurais du préciser que j'écris ce script qui compile/lance sauf en python où c'est automatique. Le fait que Ant existe est la preuve que c'est une faiblesse du java mais Ant est justement un outil de plus à apprendre.
Ce que j'essaye d'expliquer c'est que, plus tu rajoutes des outils, plus tu complexifies et plus tu vas rajouter des outils pour simplifier. C'est une voie de garage par excellence et c'est complètement anti-productif. ("j'ai passé seulement 2heures et j'ai un super script Ant." Super. C'est 2h que tu n'as pas passé sur ton produit).
Je vais faire plus simple : j'ai deux machines qui font un travail. La première comporte un gros boutton rouge. La seconde comporte 5 bouttons : rouge, vert, mauve, jaune, bleu. Le manuel de la première explique qu'il faut appuyer sur le boutton pour la mettre en marche ou pour l'arrêter si elle est en marche. Le manuel de la seconde explique que le boutton mauve est un préchauffage, le boutton bleu l'initialisation, le boutton vert le lancement, le boutton rouge la confirmation du lancement et le boutton jaune l'arrêt de la machine.
Et toi, tu es en train de défendre que c'est logique d'appuyer sur le boutton bleu parce que, forcément, il faut bien initialiser la machine et que c'est une machine super facile à utiliser vu que quand tu veux la lancer il suffit de faire mauve, bleu, vert, rouge et encore, le mauve n'est pas toujours nécessaire, t'es pas obligé d'appuyer dessus si l'indicateur de température dépasse une certaine valeur.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Dans ce cas, il faut utiliser un vérificateur de code où quoi que ce soit d'autres. Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.
De plus, quand tu développes, tu peux vouloir tester une fonction tout en sachant que le reste n'est pas encore développé. Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
L'utilisation du compilateur comme un indicateur de la qualité du code est l'un des trucs les plus effrayant qu'on puisse sortir pour justifier la compilation. Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
"La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule "
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps". Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois ("sinon y'a des erreurs du à des trucs pas recompilé mais qui devraient l'être (sic)"). Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Et quand bien même le temps serait vraiment ridicule, ce n'est pas une justification : tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Lors du développement d'un soft, personnellement je finis toujours par écrire un script qui compile, fais tout ce qu'il faut et qui lance le soft. Je modifie le code, lance mon script pour tester, modifie le code, lance le script, ...
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Grandiose
Posté par ploum (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Par contre il doit connaitre, en plus du langage de programmation des tas d'outils pour faire fonctionner son langage de programmation et encore d'autres outils pour faire fonctionner les outils.
Se compliquer la vie pour tenter de la simplifier, c'est voué à l'échec sur le long terme, faut pas chercher très loin pour s'en rendre compte. Lorsqu'un programmeur passe 2 semaines pour réussir à compiler un projet sans toucher une ligne du projet lui-même (juste les makefile et les configure), n'importe qui avec un peu de recul dirait "mais c'est quoi ce délire ?". Mais bon, le nez dans le guidon est le lot de90% des gens. Y'a peu de gens qui se posent la question "mais au fond, c'est quoi le résultat qu'on aimerait avoir ?". Le problème de la vie c'est que poser cette question, c'est remettre en question le travail, les acquis, la souffrance endurée les années précédentes. Alors, on préfère se convaincre que la question ne doit pas être posée.
Autolink : http://ploum.frimouvy.org/?197-le-conte-du-mousse-et-des-vin(...)
Mes livres CC By-SA : https://ploum.net/livres.html