CrEv a écrit 4577 commentaires

Je pense surtout que la phrase initiale peut amener à penser que le code 200 n'est pas pris en compte…

Se prendre un procès pour quelle raison ? Parce que les deux ont utilisé un nom commun ?
Le nom est-il déposé ? Il y a des (r) qui trainent quelque part (sachant que (tm) n'a quasiment aucune valeur) ?
Et bon, c'est pas pareil non plus. D'un côté un framework web, de l'autre une GUI.

Au fait, quelqu'un utilise du qnx / photon (pour de vrai et de nos jours) ?

Mais tu n'en es pas non plus propriétaire

Tout comme tu ne deviens pas propriétaire d'un logiciel libre. Le code "appartient" toujours à ces auteurs. C'est d'ailleurs l'essence même des licences à copyright, licences copyleft évidemment incluses.

Le logiciel libre ne te donne pas la propriété d'un programme. Il te permet d'en avoir une copie, d'avoir accès aux sources, d'étudier, de modifier, de redistribuer, d'exécuter. Mais c'est tout, tu ne peux pas prétendre en être propriétaire. Et avec une licence BSD/MIT/… c'est pareil. Tu as le droit de fournir des copies, de les modifier (que les sources soient disponibles ou non) mais ça n'en fait pas de toi l'auteur ou le propriétaire.

développement restreint, fermé, contrôlé

Attention, ce n'est pas lié à la licence ça. Il ne faut pas confondre logiciel libre et logiciel communautaire. Je peux très bien (et certaines boites le font, Google par exemple en est pas loin avec ses codes) développer des choses de manière fermée mais rendre le code source de chaque version disponible sous licence libre.

Quoi ? le mot photon est déjà utilisé ? Naaaan !

;-)

Prenons le cas d'un propriétaire d'une licence office 2003, étant donné que progressivement, il deviendra impossible d'utiliser ce logiciel (est-ce possible d'installer office 2003 sous win 7 ou 8 ? c'est une vraie question, je n'ai pas essayé…) ou d'ouvrir ou de communiquer/lire des documents o2003 dans des versions supérieures de office.

Le premier point j'en sais rien.
Par contre le deuxième, sans problème. Tout comme LibreOffice te propose d'ouvrir du .sxw (après question rendu j'en sais rien) Microsoft Office te permet toujours d'ouvrir des documents format 97-2004 (doc, xls, etc).

Donc sur ce point, ben libre ou non ce n'est en réalité pas la question. Microsoft aurait pu supprimer le support de ces vieux documents, mais le libre aussi (et l'a déjà fait dans certains cas). Ca c'est surtout une histoire de masse critique d'utilisateurs, d'intérêt plus ou moins personnels, de contraintes de développement, de temps, d'investissement, etc.

Après, comme vu plus bas, en effet lorsqu'il y a un CLUF on est dans le cadre d'une location à durée indéterminée, je n'avais pas pensé à ce point. Donc vu comme ça, le terme loué peut convenir. Je trouve que ça porte à confusion quant au côté temporel de la chose et de l'idée de location mais pourquoi pas.

J'ai jamais dit que moi

Peut-être, mais tu semble présumer beaucoup sur les autres personnes de la discussion…

Et si le logiciel à un instant T, qu'on a payé, se paye une mise à jour, à ton insu qui fait que tu ne peux plus faire ce que tu veux avec ?

Et si dans le contrat de licence que tu as accepté c'est écris qu'ils peuvent, ben c'est que tu as fait ton choix. Mais tu ne peux pas céder tes droits sur le logiciel et te plaindre ensuite de les avoir céder.

Je ne parlerai pas non plus des logiciels utilisés au travail où je n'ai pas vraiment le choix si je veux gagner ma croute.

Tu as toujours le choix hein. Personne ne t'oblige en pointant un flingue. Ok c'est pas ce que le gens veulent entendre, mais personne ne t'oblige à avoir un taff où tu utilises des logiciels de merde.

Mais ça ne correspond pas.
Un bien loué, tu t'attends à ce qu'à un moment ce soit terminé. Derrière loué tu as une idée de temps fini. Là ce n'est pas le cas. Et même si cela existe pour certains logiciels ça n'a pas de rapport.

Toi, pas grand chose mais certains ont des compétences informatique supérieur aux tiennes et se mettent hors licence d'utilisation pour faire ce dont ils ont besoin.

1. ça va les chevilles ? beau lancé en tout cas
2. c'est pas ma faute, j'ai été obligé de cracker le soft !

Personne ne t'oblige à utiliser un logiciel qui a des contraintes qui ne te vont pas. Le fait d'avoir un tel logiciel n'a supprimé aucune des libertés.

Tu n'est justement pas propriétaire du logiciel.

D'où l'usage correct du terme de logiciel propriétaire vs libre.

Pas tant que ça. Le code libre reste libre, quoi qu'il arrive. Donc, et c'est ce qui s'est passé, tu peux toujours forker à partir de la dernière version avant le changement de licence.
Mais c'est exactement la même chose si tu fais un code sous GPL avec cession de copyright. Il n'y aura pas de différence, le détenteur du copyright pourra changer unilatéralement la licence s'il en a envie.

Justement, si je livre un code sous BSD, ou une contribution sous BSD je sais que certains vont pouvoir en faire ce qu'ils veulent. Et alors ?
Mon code reste libre, que quelqu'un l'utilise dans un autre soft dont je n'ai pas accès aux sources ne va me priver en rien. C'est simplement que je n'exige rien des autres. Et ça fonctionne plutôt pas mal.

J'ai trouvé ça incroyable qu'un modérateur se permette de remplacer un terme correct dans une dépêche récente par un néologisme qui porte clairement une connotation péjorative.

J'ai du louper un épisode, où est ce problème ?

Sinon, sur le fond, je suis plus du même avis. Je n'ai jamais vraiment compris pourquoi certains s'évertuaient à utiliser le terme privateur plutôt que propriétaire (qui je pense couvre mieux la réalité des choses). Privateur a une connotation "je veux, volontairement, et c'est mon objectif, priver les utilisateurs de quelque chose". C'est une vision très "axe du bien" vs "axe du mal" ça. Et à mon avis ça ne reflète que très peu la réalité des choses (pour pas mal de monde ça reste plus du domaine de la protection - des sources, du droit d'auteur, etc - que de la volonter de priver). Mais faut croire que pour certains c'est plus facile de séparer le monde en deux camps qui s'opposent. Sauf que la plupart des programmes / bibliothèques d'importance qui voient le jour récemment (surtout sur tout ce qui est orienté web) est beaucoup plus sous licence BSD/MIT/… que sous GPL & co. Ce qui montre plus une vision "il faut de tout, et je me fiche de comment c'est utilisé ensuite".

Ce que tu cites ne dit absolument pas qu'il y a un lien d'héritage entre scala et java, ça doit venir d'une mauvaise compréhension de java/jvm.
Java est compilé en bytecode, qui s'exécute sur la jvm.
Scala est compilé en bytecode qui s'exécute sur la jvm.
C'est ce bytecode commun qui fait qu'il existe un pont, que tu peux utiliser des libs java en scala.

P.S.: Sur la photo c'est quoi la fonte? On dirait Monaco mais je ne suis pas sûr à cause de la perspective. :)

Ubuntu Mono (source : https://twitter.com/instacodez/status/327059408947392514)

Je répond en deux fois, une fois rapide sur quelques points et je ferai plus long plus tard (taff, toussa)

Pour reprendre ton exemple :

for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if (*myIntVectorIterator % 2) {
   cout<<*myIntVectorIterator<<" ";
   //Should output 1 3 5
}

Ce code ne passe pas selon mes règles. C'est un exemple, très abstrait, je ne peux donc pas proposer de solution, mais face à un code de ce genre, je réfléchis énormément pour raccourcir la ligne de 144 caractères. Je suppose que je mettrais justement le if/else dans une autre fonction, avec un nom qui indique ce que fait cette condition. myIntVectorIterator est un nom très long, est-ce qu'il n'y en a pas un plus court qui ait un sens dans le contexte actuel ?…

En fait le premier problème de ce code est justement le fait d'aller à la ligne (le if sur la ligne du for)

Ensuite, pour le rendre par certains côtés plus lisible, il faut "juste" comprendre ce qu'est un for :

vector<int>::iterator myIntVectorIterator = myIntVecor.begin();
while(myIntVectorIterator != myIntVector.end()) {
  // bla bla
  myIntVectorIterator++;
}

Et d'ailleurs il devient plus aisé de remplacer le corps du for par une méthode. L'inconvénient (enfin si le corps du for est trop long) est qu'on voit moins vite l'itération, même si on s'en doute fortement.

Pour l'histoire des accolades : arrive-t-on réellement a un code où il n'y a jamais deux instructions dans un if/else/autre ? Si oui, alors il peut être envisageable de se passer d'accolades. Mais ça + une largeur de ligne faible, ça me semble étrange. Mais peut-être est-ce possible, auquel cas c'est intéressant ;)

(la suite un peu plus tard)

Je complète juste un des exemples (tiré d'un vrai code hein…)

using namespace std;

vector<int> myIntVector;
vector<int>::iterator myIntVectorIterator;

// Add some elements to myIntVector
myIntVector.push_back(1);
myIntVector.push_back(2);
myIntVector.push_back(3);
myIntVector.push_back(4);
myIntVector.push_back(5);

for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if (*myIntVectorIterator % 2) {
    cout<<*myIntVectorIterator<<" ";
    //Should output 1 3 5

    // bla bla bla

    // bla bla
} else {
    // bla bla
}

Oui, en général quand tu vois ça il y a subitement pas mal de supplices qui te viennes à l'esprit ;-)

Bon, pas mal de choses à dire :)

Autant les ; en javascript sont discutables (rien que par leur côté simplement optionnel). Pourtant je les conserve pour deux raisons essentiellement, une bonne et une mauvaise.

• la bonne : on ne peux pas, toujours, les supprimer. Et on se retrouve avec des horreurs genre ;!function() {… Et ça franchement, c'est dégueulasse je trouve.
• la mauvaise : ça date du temps où on utilisait des minifieurs un peu trop bêtes : il ne faisaient que supprimer les commentaires et les espaces. Si une accolade manquait, si un point virgule manquait, c'était alors vraiment galère.

Par contre, je suis en général contre l'inline (les block sur la ligne de la condition) et contre l'absence des accolades. Mais ça c'est pour des raisons beaucoup plus terre à terre.

Déjà, c'est tout con, mais placer un point d'arrêt dans le bloc d'une condition c'est quand même parfois vachement pratique lorsqu'on debug. Et quand on a

if (shouldNotWrite(scriptSource, loadedFromBaseJS)) return false

Ben c'est juste pas possible comme ça :)

Le deuxième point c'est que, parfois, on va vouloir ajouter une ligne de log (par exemple). Et si on va un peu trop vite, en plein debug, on va avoir des choses sympa.

Genre

if (shouldNotWrite(scriptSource, loadedFromBaseJS))
  return false

va se transformer en

if (shouldNotWrite(scriptSource, loadedFromBaseJS))
  console.log('shouldNotWrite')
  return false

Et là, c'est le drame.

Ensuite, il y a simplement des cas où on ne peut pas s'en passer (plus d'une instruction) et on arrive parfois à :

if (shouldNotWrite(scriptSource, loadedFromBaseJS)) {
  console.log("shouldNotWrite")
  return false
} else
  console.log("shouldWrite")

Et là, franchement, c'est gerbant.

Et enfin, dernier cas, en obligeant les accolades et interdisant plusieurs instructions sur la même ligne, je vais éviter que quelqu'un me sorte un truc de ce genre :

using namespace std;

vector<int> myIntVector;
vector<int>::iterator myIntVectorIterator;

// Add some elements to myIntVector
myIntVector.push_back(1);
myIntVector.push_back(2);
myIntVector.push_back(3);
myIntVector.push_back(4);
myIntVector.push_back(5);

for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if (*myIntVectorIterator % 2) {
    cout<<*myIntVectorIterator<<" ";
    //Should output 1 3 5
}

(cet exemple est beaucoup plus sympa si vous n'avez pas de retour automatique à la ligne ;-) )

Et là, vraiment, je peux plus le voir ce type de code.

Alors c'est peut-être pas totalement fun mes diverses règles, mais pour le coup c'est réellement l'expérience qui parle. Ce que je veux dire c'est que tous ces cas je les ai rencontré en vrai, certains bien plus qu'une fois.
Et les conventions de code, si elles doivent permettre d'avoir un code élégant, doivent aussi s'assurer que tout fonctionnera au mieux, en prenant si possible en compte les erreurs humaines.

Après, sur le côté closure. Par exemple, le doc = goog.global.document est assez particulier, surtout que je n'en vois pas du tout l'intérêt. En plus, il est utilisé avant sa déclaration (ok, c'est pas forcément un problème, mais quand même).

De manière globale, je trouve qu'il faut plus d'effort pour lire ton code que la version initiale. Ok, chaque méthode est plus petite. Mais finalement c'est tellement morcelé que ça complexifie la lecture et la compréhension, alors que quand même, le code initial est plutôt simple :)

Avoir des limites genre pas plus de 5 lignes, j'en vois pas vraiment l'intérêt. A part mettre chaque instruction ou condition dans une méthode qui lui est propre, mais ça revient à découper pour découper là. D'ailleurs je trouve étrange de limiter la taille des lignes et en même temps vouloir tout mettre sur une ligne…
Par exemple, lorsque tu lis la méthode principale, tu n'as absolument aucune idée du fait que ça peut lever une erreur. Pour le savoir, il faut que tu fouilles dans les fonctions. D'ailleurs ta fonction, shouldNotWrite, n'est pas explicite. On ne s'attend pas à ce que ça lève une erreur non plus.

Idem, le côté not / false, c'est pas génial en général. A la rigueur si on avait du unless ça serait différent par exemple.

Je répond très vite (probablement plus détaillé plus tard).

En fait je trouve que la recherche du "on remplace les commentaires par du code" complexifie le code.
Regarde ce que tu as au final et ce qu'il y avait au début. Je trouve le code initial (même sans commentaires) plus simple à lire. Et ça en terme de maintenance, c'est très important.

Mais surtout, tu essaies de faire dire au code le contenu des commentaires. Certes, on s'en approche. Mais une part de l'intention est toujours absente. Entre autre le fait que si on permet de charger plusieurs fois base.js (et donc deps en effet) c'est parce que des frameworks de tests font les choses un peu étrangement. Cette information demeure totalement absente. Certes certains pourraient dire que c'est une information peu pertinente. Mais finalement si on ne l'a pas, on ne peut pas savoir pourquoi on laisse passer. Enfin si, on sait dans quel cas (le cas où c'est chargé plusieurs fois) mais on ne sait pas comment ce cas arrive (car ce n'est pas normal). Il manque toujours un bout.

Sinon, pour le reste, je referai un commentaire plus long après ;)

Pas mal de choses à dire en fait, mais j'aime beaucoup la tournure que ça prend :)

Déjà, j'aime pas tellement ni le côté "dense" sans accolades, ni l'absence de point virgule. (ni le passage du goog en fait)

Ça, c'est fait :)

Ensuite, honnêtement, je trouve ça plus lourd. Et surtout, il manque réellement des commentaires.
En fait, en lisant ton code, on ne sait toujours pas pourquoi on teste l'état du document, pourquoi un lance une erreur mais pas dans le cas de deps.js.

Donc en fait, ton code factorisé de la sorte n'amène pas de réponses, il serait même à mon avis plus compliqué de décrire les cas (car tu as changé l'ordre des conditions, même si ça ne change pas le résultat).

Et au final je trouve ça moins lisible car cela oblige à faire des allez retour.

Finalement j'aime bien cet exemple car c'est justement un vrai cas où ce qui est intéressant est le pourquoi et non le comment (le comment est très simple, le pourquoi beaucoup plus tordu).

Bonne remarque :)
Pourquoi avoir pointé la page anglaise ? Simplement parce que j'ai tapé "wikipedia literate programming" dans Google et j'ai pris le résultat. Vraiment, il n'y a pas d'autre raison, à part le "en général les pages anglaises sont plus détaillées".

Mais merci de la précision, de pointer la version française :-)

Tiens, un point qui, étrangement, n'est pas arrivé ici.

Qu'en est-t-il des tests en tant que documentation ? Est-ce que les tests (unitaires, fonctionnels) peuvent décrire l'intention ?

Pour ma part j'ai pas un avis tranché sur ce point. Je pense que les tests aident beaucoup, mais de là à couvrir les besoins de commentaires, d'intention, je ne le pense pas. Et vous, vous en pensez quoi ?

Oui c'est bien du CoffeeScript, utilisant Monocle. La "photo" a été faite avec instacod.es.
D'ailleurs je m'étonne que l'extrait n'ai pas encore fait réagir son auteur, qui est sur LinuxFr ;-)

Tiens, je vois qu'on a les mêmes références :)

Très bon bouquin, bien qu'il provienne de chez Microsoft Press diront les mauvaises langues. C'est assez complet, peut-être pas très actuel par certains côtés, mais c'est un bon bouquin. Je le conseil vraiment à tous les programmeurs.

Magento… le projet n'est pas mort… :-(

                       .+ssyss+:.                  ..     /-                    
                      +dhhhhhhhhhh+-`        `:`   mN`   yMN`                   
                     `dhhhhhhhhhhhhdhyo:     /M+   sM-  +MmMs                   
                `:oyhdhhhs++oosyhhhhy-`      `My`-+dM/ `mN.yN.  :-   :-         
              :shhhhhhs/---------/oydo-`      mNNMMNMs +MyohMs -M+  .M+   :+    
            -yhhhhhhh:------------:::/---.    hMh:` md mMNdydN.hN-::hm` -dMM    
           +dhhhhhhhy-------...----+:--:::-   sM+   mN+My`  -MdMMmdNM/ +Nshd    
          +dhhhhhhhhd------...-s```-   `s..   /d+   sd-/.    -mN`  ym.hMs/ms    
         `dhhhhhhhhhh+---:`    ` `.:----.-.                  .y/  /MymdyyhM+    
         -dhhhhhhhyhhs----------/----------:                      -+/+   /M-    
         -dhhhhhhh:/d+----------::--------::-.`                          ./-.   
         `dhhy+ohy-:+---------------------------`                     .------:  
          +hd:::::--:+syyhy-..:------::::::::---`                 ..-:-------`  
           shhso+--hMMMMMMMNdmMmsym/.`.                       ..-:----.-:/-     
           `hhhhd/:MMMMMMMMMMMMMMMN/`                    ..--:------::+:..:     
            /hhhdy-+dNNdyyyy+o+:::--:::::  .-.`     ..--:--------------/::::    
            `dhdhd+-----:::::---------:/:/+/o/++-------.--------::::::/:---:    
            :dhsosoo:---------------/ss+///o/:-----------------.------/--..     
          `.oso+++ooso///:::--:://++/+sos//o.------------------------`          
        -/////+so+o++s+////////////////sos++:.---------:--...`                  
      -/////////so+++os/////////////////s+s+o---::/-..`                         
    `////////////so+++os////////////////+s+s++oo+/+`                            
   `+////////////oo++++s/////////////////soos++//-                              
   `s+::::///+///+s++++os///////++++++++/+soo:                                  
    :---------/o/so+++++s//////////////////ooo                                  
   :----------soso++++++s+//////////////////+s.                                 
  -----------o+++++++++ooo///////////////////+/                                 
 `:.--------oo+++++++++ooo////////////////////+.                                
 --.------.+o+++++++++++oo/////////////////////+

Désolé, c'était plus fort que moi !
Et je compatis, pour avoir bossé un peu avec. Mais le problème de magento c'est qu'il n'y a pas que les commentaires qui soient moisis, loin de là.
Parfois c'est même à ce demander comment ça tombe en marche. (mais par contre pas de problème pour savoir pourquoi c'est lent…)