Bastes a écrit 403 commentaires

"Singularity", rien que ça. On a toujours la flatulence haute chez M$...

(pour mémoire :
http://en.wikipedia.org/wiki/Mathematical_singularity
http://en.wikipedia.org/wiki/Gravitational_singularity
http://en.wikipedia.org/wiki/Technological_singularity

Mais il y a aussi ça :
http://en.wikipedia.org/wiki/Mechanical_singularity
In engineering, a mechanical singularity is a position or configuration of a mechanism or a machine where the subsequent behaviour cannot be predicted [...].
En ingénieurie, une singularité mécanique est une position ou configuration d'un mécanisme ou d'une machine dont le comportement ne peut pas être prédit [...].
En gros, ça veut dire que windows "Singularity" va être imprévisible, ou instable, ou peu fiable ?...)

Non, les p'tits gars qui font PHP ont beau avoir manqué un peu de clairvoyance sur certains de leurs choix techniques au cours des ans, ils n'ont cependant pas déprécié les short tags.

Là pour le coup c'est une surprise.

Quoi qu'il en soit, Léonidas est mort vaincu (même si c'était une défaite héroïque)...

Ah, donc si je comprend bien, si c'est un suicide héroïque c'est ok ?

Vivement la version 12 "Kamikaze" alors...

Je me demande s'ils ont vraiment confiance en leur distro, si je me souviens bien Léonidas il meurt à la fin de l'histoire (ou c'est que j'ai pas vu la bonne version de "300" ?)...

Faisons une expérience de pensée, pour nous poser une question philosophique :
Et si Canonical avait libéré tout Launchpad, 100% du code, s'ils avaient aussi offert les codes de leurs serveurs, mis à disposition du publique la cartographie complète de leur architecture réseau, diffusé en temps réel les comptes de l'entreprise au cent près et installé une webcam dans le slip de Mark Shuttleworth.

Essayez bien de visualiser l'image.

Vous y êtes ? Bien ? Vous voyez tout ce que j'ai décrit. Au poil près ?

Bien. Allons-y pour la question :
Considérant le postulat précédent, selon vous, quels arguments devraient déployer les Ubuntu-anti-fanboys pour nous démontrer que Canonical c'est le Mal ? (la majuscule est intentionnelle)

Je vous laisse méditer, moi je vais me contenter de trouver bien qu'une boîte comme Canonical libère un gros bout de logiciel, en plus des efforts déployés pour faire sortir le logiciel libre de son placard. Je dirais d'ailleurs la même chose de n'importe quelle entreprise qui se comporte comme Canonical sur ce plan.

Au contraire le contraire, je n'ai pu former certains de mes collègues à RoR que parce que je partais et que le directeur voulait garder un oeil sur les nouvelles technos du web. Pas besoin d'avoir peur.

erratum :
- intégrer mon module (à la volée dans un instance ou dans la classe, ou dans la déclaration de ma classe si c'est moi qui la crée) pour chaque classe

Et même qui commence à interpeller les SSII, puisque j'ai déjà fait de l'initiation à Ruby on Rails dans la boîte que je viens de quitter parce que le directeur voulait que des gens qui restent gardent un oeil dessus, au cas où...

Ben non, pourquoi ? Quand une exception se produit en Ruby, on a aussi une stack trace, c'est pas une spécificité du Java (je sais que ça peut surprendre, mais déjà en PHP ça existait, si si).

Et non, effectivement, les deux ne sont pas équivalente. On peut utiliser les deux notations pour produire des résultats identiques, mais si elles étaient équivalentent je n'aurais pas pris de temps ici pour pointer leur différence.

Sinon, oui on peut émuler le duck-typing en Java avec un tableau d'objets ou un hash (c'est d'ailleurs ce que tôt ou tard on finit par faire quand on en a assez de devoir faire évoluer X méthodes quand on change juste une petite chose dans l'un des paramètres fondementaux), mais c'est tellement plus simple d'utiliser un langage fait pour ça, d'autant plus que les types natifs de Java rendent souvent l'opération pénible.

Oh, je n'aime pas beaucoup répondre "ligne par ligne" parce que souvent les citations sorties du contexte sont mal interprétées, mais celle-là est trop belle :
Et si je vois un truc comme ca un jour dans du Java, c'est une balle dans la nuque sur la place publique pour le cochon qui l'a ecrit.
Ben oui, c'est bien là le problème. En Java, on dit ne pas aimer la répétition, mais prône la verbosité. Ruby prétends que la verbosité est contre-productive, et qu'elle n'est rien d'autre qu'une autre forme de répétition de structure. Par exemple, si en Java je veux qu'une méthode fonctionnant de la même façon soit donnée à plusieurs classes existantes n'ayant pas d'ancêtre commun modifiable, ça va m'obliger à :

- créer une interface
- créer des sous-classes de chaque objet
- créer un objet qui contienne ma méthode
- créer dans mes sous-classes un conteneur pour mon nouvel objet
- créer une instance du nouvel objet dans le constructeur de chaque sous-classes
- créer dans chaque sous-classes une méthode paravent pour appeller celle qui m'intéresse du nouvel objet

Beurk

En Ruby :
- créer un module contenant ce qu'il faut pour que ma méthode marche
- implémenter ma méthode (à la volée dans un instance ou dans la classe, ou dans la déclaration de ma classe si c'est moi qui la crée) pour chaque classe

Hop

Nommer, répertorier, expliquer les paramètres possibles, je préfère le mettre dans les commentaires, comme de toute façon chaque paramètre doit s'expliquer dans les commentaires ça évite d'écrire deux fois les choses. Et je n'arrive plus à voir l'intérêt de spécifier les types en Ruby, où on préfère la philosophie du "duck typing" (si ça se comporte comme un canard et que j'ai besoin d'un truc qui se comporte comme un canard, pas besoin de lui faire faire un test adn).

Par exemple, en Java, si une méthode à besoin de travailler sur un objet qui implémente une interface IJeSaisFaireQuelqueChose pour utiliser sa méthode abstraite faireQuelqueChose, alors je vais devoir implémenter l'interface pour chaque objet passé en paramètre, voir dans certains cas faire des héritages de classes définies dans des bibliothèques externes pour pouvoir leur coller juste une bête interface.

En Ruby, si une méthode à besoin d'un objets qui réponde à la méthode faire_quelque_chose(), il suffit que mon objet répondre à cette méthode et ça roule. Si vraiment je veux faire mon paranoïaque je peux tester si l'objet répond à la méthode à la réception de l'argument et lancer une exception si ce n'est pas le cas. Ca permet de découpler beaucoup mieux les classes.

Encore mieux, si j'ai une instance d'objet à passer à ma méthode, et qu'il n'a pas la méthode faire_quelque_chose(), je peux faire un module contenant une implémentation de faire_quelque_chose() et le coller à la volée à l'instance (ou à la classe) avant de le donner à manger à la méthode en question, ce qui simplifie énormément le développement orienté comportement.

On y gagne en lisibilité (code plus concis, moins de méthodes vides juste pour implémenter des interfaces, moins de méthodes qui se contentent d'en appeller une autre du même nom pour faire varier le nombre de paramètres, moins de sous-classes définies uniquement pour donner un nouveau comportement à du code existant), en temps (pour écrire des commentaires, des tests), et en réutilisabilité (pas besoin de se taper des diagrammes d'héritages ou des API de 1000+ pages pour réutiliser des libraries bien claires et bien commentées, le code est plus facile à découpler et facotriser).

Je sais que ça fait peur, on a l'impression qu'il n'y a plus de structure, que les autres développeurs (qui sont forcément nuls, fainéants, etc.) ne sont plus obligés de suivre strictement des lignes de conduite rigides et indépassables et vont faire de la merde, forcément, mais franchement, même avec Java un développeur qui fait de la merde peut vraiment faire des trucs bien puants, bien crados. Ce n'est pas la flexibilité du langague qui fait que l'on pond de la merde ou pas, c'est la méconnaissance des bonnes pratiques et la paresse.

Là ça sent le "juste pour le plaisir de troller" quand même.

Sinon, mois j'aime bien les carottes, mais pas dans la soupe aux pois parce que je trouve que c'est trop sucré, et trop orange. Et du coup, je me demande, est-ce que vous aimez la soupe au pois, et est-ce que vous trouvez utile qu'on mette des carottes dedans, ou pourquoi ne pas remplacer par un simple navet ? Que penser des restaurants qui salent trop la soupe ? La soupe est-elle à ce point particulière qu'elle soit le seul plat que l'on serve sous forme liquide ?

Ah, oui, c'est pour les brevets ça en effet. Mais comme le brevet parle de l'implémentation matérielle du procédé ça ne concerne pas le logiciel en effet. Ouf.

Parce que sinon ça serait inquiétant pour l'avenir du logiciel libre si tous les employeurs d'informaticien pouvaient du jour au lendemain décréter que les logiciels libres de leurs "collaborateurs" (on ne dit plus employé de nos jours, ça fait ringard, ça donne l'impression qu'il y a des rapports hiérarchiques) leur appartiennent sous ce prétexte...

Ok, c'est que j'ai confondu la notion légale de "copyright" que je ne connais pas dans les détails avec le droit de copie. Désolé pour la méprise.

Là j'ai de gros doutes, ça voudrait dire que les participants à des développements de logiciels libre en france devraient avoir une dérogation de leur entreprise du moment que ce qu'ils font au travail à un quelconque rapport avec leur domaine d'activité professionnelle, sous peine de "contaminer" la licence. Et ça voudrait aussi dire que ton entreprise possède un droit de regard sur ce que tu fais de tes temps libres ce qui me semble un poil totalitaire comme droit de la part d'un simple employeur.

Comme sujet me touche et m'intéresse, est-ce que tu peux demander au gars de l'INPI de donner des sources sur le sujet ?

Pour le python, je ne connais pas, donc je te crois sur parole. Je ne parlais pas que du python.

En général, les décideurs en SSII ne sont pas des techniciens, ils ne savent pas bien comment ça marche et franchement ils s'en foutent. Ils veulent des mots-clef, des idées qui percutent, des arguments tout fait fournis généralement par les ingénieurs qui bossent pour eux, ou la presse "spécialisée" qui leur digère (je ne parle bien entendu pas de de publication technique mais de publication manageriale).

Au grand maximum, que Python "casse la rétro-compatibilité peut effrayer les ingénieurs, qui sont en contact avec la technique, mais d'une part pas forcément, d'autre part pas forcément plus que la rétro-compatibilité forcenée de Java qui lui fait maintenir des types natifs non-objet contre vents et marée malgré toutes les complications que ça implique pour les développeurs, la maintenance, la propreté du code et la standardisation.

Par contre, c'est vrai qu'un décideur aura tendance à être plus en contact avec des infos sur les technologies commerciales puisqu'elles font de la pub à longueur de page dans la presse "spécialisée" (souvent sous forme d'articles d'ailleurs), donc il est naturel que Java ait des facilités à se maintenir dans les SSII où la direction n'est généralement pas proche du technique...

Effectivement, en France en tout cas, on ne peut pas breveter une idée mais un processus, une implémentation.

Par exemple, je ne peux pas breveter une molécule en France, mais je peux breveter une recette particulière détaillant les instruments employés et le procédé permettant de produire cette molécule.

Ce n'est pas forcément valable partout ceci dit, notamment aux USA (où je suis surpris qu'on n'ait pas encore breveté la respiration ou l'oxygène).

Heu, tu sais que si tu es sous licence libre, il n'y a pas de copyright (GPL : liberté de copie et de diffusion). A moins que tu parles de l'auteur (mais je ne vois pas bien en quoi tu ne pourrais pas être l'auteur de ton propre code, qu'il soit réalisé dans le cadre de ton travail ou pas, à partir du moment où la licence est libre). Ou alors tu parles d'une licence "juste" open-source qui réserve le copyright mais autorise la consultation et la modification sous certaines conditions par exemple ?

Sinon, un développeur employé en France est bien propriétaire de ses idées, même si son contrat le prétend ce n'est pas valide en droit français. Qu'il ne soit pas propriétaire du code qu'il produit dans le cadre de son travail, certes si la licence du dit code le dit, mais l'entreprise ne gagne pas un droit sur le code qu'il produit dans ses temps libres (du moment qu'il ne viole pas les clauses de confidentialité et la licence du code qu'il produit sur son lieu de travail) à ma connaissance.

Ceci dit, la difficulté à maintenir des commentaires nait de la redondance du code, et Java incite à la redondance du code. Exemple :
> en Java :
class Machin {
/**
...
*/
public String truc() {
...
}

/**
...
*/
public String truc(String blah) {
...
}

/**
...
*/
public String truc(String blah, int zorg) {
...
}

/**
...
*/
public String truc(String blah, int zorg, boolean asif) {
...
}
}

> en Ruby :
class Machin
=begin
...
=end
def truc(*args)
...
end
end

Rien que sur ce détail (il y en a d'autres) on est "obligé" si l'on veut bien commenter de se taper plusieurs blocs de commentaires là où un suffirait largement.

Pour inciter un codeur à accompagner son travail de commentaire, il faut qu'il ne se sente pas comme un bon Sisyphe à pousser un rocher qui de toute façon retombe dès que le sommet de la colline est atteint. S'il a l'impression que son travail est inutile, soit parce qu'il pense que son code est déjà limpide, soit parce qu'il voit que de toute façon une fois le code à peine modifié il faut faire trois fois autant de modifications de commentaires, le codeur il n'a pas très envie de commenter.

Oh, je suis sûr qu'il y a des moyens de "gruger" avec Java et de mettre en place du commentaire propre et non redondant, mais je n'ai pas passé beaucoup de temps sur cette plate-forme (ce qui me dérangeait plus que la redondance de commentaires c'est le redondance de code).

C'est avant tout une question de culture je pense, j'ai passé un an dans une SSII à faire du Java et j'ai abdondamment commencé, et l'expert Java de la boîte m'a toujours soutenu et pris en modèle pour ça. Je n'ai d'ailleurs jamais rencontré dans ma carrière (beaucoup de PHP, un peu de Java, pas mal de JavaScript et technos diverses associées au web) de gens qui prônaient le non-commentaire. Tout au plus j'ai rencontré (en grand nombre) des développeurs qui en parlaient beaucoup et n'en faisait pas trop, mais je crois que le consensus est plutôt à commenter son code.

Par contre, c'est toujours mieux de faire un code court et lisible qu'un code long et incompréhensible, à commentaire égal.

Je n'avoue qu'une chose : ce que j'ai voulu dire, c'est que ce n'est pas parce qu'une technologie n'est pas massivement employée par des SSII qu'elle est "au point mort", surtout dans l'open-source. Ca veut surtout dire qu'il faut un moment pour qu'elle fasse ses preuves aux yeux des SSII, et ça ne peut se faire que par deux moyens : convaincre la direction (qui généralement n'y connaît rien à la technique et lit des journaux bourrés de pubs d'éditeurs commerciaux) et convaincre la clientèle (qui est généralement assez peut orientée techniquement ou prône à conserver l'existant).

Par contre, Ruby et Rails commence à séduire les hébergeurs et les structures plus petites, à cause de la productivité, la lisibilité du code, la fiabilité (suite de tests intégrée, pas très difficile à mettre en place), le fait de maîtriser beaucoup mieux le workflow et la facilité de réutilisation des plugins / gems souvent assez peu intrusifs. Il a aussi séduit des startups qui développent des sites commerciaux (ou pas), et qui n'ont pas les moyens ni le besoin de faire appel à d'énormes machineries pour leurs débuts, et veulent un code propre qui évolue rapidement.

A ce propos, et sans vouloir t'offenser, la rétro-compatibilité n'est pas l'apanage de Java. Ce n'est pas parce qu'une plate-forme open-source évolue qu'elle ne répercute pas des corrections critiques sur les version "vivantes" précédentes, et même pour d'importants sauts de versions il est fréquent que l'essentiel du code existant reste viable à quelques légères modifications près.

Sinon, je ne peux pas tellement parler de python, je n'y ai pas (encore) mis les pieds, mais je ne vois pas en quoi un système à base Python ou Ruby ne pourrait pas tenir 10 ans, voir plus, à condition que, comme pour une appli Java de cette ancienneté, il y ait de la maintenance et de la mise à jour effectué. Il se trouve que pour Ruby, Python, ou d'autres logiciels Open-Source, on a envie de faire évoluer la plate-forme au cours de la vie d'une application, personnellement je ne vois pas de mal à ça, je trouve plutôt ça positif. A ma connaissance, c'est d'ailleurs ce qui se passe pour toute plate-forme de développement tant qu'elle n'est pas morte. Evidemment, ça devient de plus en plus difficile de trouver des développeurs COBOL de nos jours, mais les développeurs COBOL sont également de moins en moins demandés, ceci accompagne cela...

Ah mais, mauvaise graine, on ne peut pas être à la fois star de l'internet presque bientôt ministre des nouvelles technologies de communication, parlementaire et maire voyons. Il faut choisir. Déjà, qu'il fasse l'effort de toucher les chèque, ça montre qu'il a du respect pour sa fonction, il se déplace pour ça j'imagine...

Où est-ce que tu as vu que Ruby est au point mort ? Et Rails ? Et Python ?

La seule chose qui freine pour Ruby, Python et leurs frameworks, c'est que les SSII sont frileuses sur les nouvelles techs, ça on le sait ça a fait la même chose il y a 10-15 ans avec Java, et il y a 5-10 ans avec PHP. Et elles sont encore plus frileuses sur l'open-source parce qu'elles n'ont pas la "garantie" de fiabilité qu'offre un système vendu par une société commerciale, sur la base du "si ils le vendent ils vont écouter leurs clients / faire un bon produit / le maintenir / le faire évoluer". Et cet effet est aussi valable pour les clients de la SSII, qui même pour un prix supérieur préfèrent souvent des bases commerciales si elles ont une "garantie".

Je parlais des gens qui y travaillent qui tolèrent ce genre de système du moment qu'ils y touchent une somme qu'ils trouvent (arbitrairement) élevée (25k€ / an ça paraît une fortune pour certaines personnes).