TImaniac a écrit 6420 commentaires

http://www.mono-project.com/FAQ:_General#Is_Microsoft_helping_Novel(...)
Et pour reprendre ton poste précédent : .NET (la techno) EST portable. MS la prouvé avec Rotor. Après certains API sont plus difficilement portable (ou tout du moins pas adaptés), mais dans le contexte qui nous intéresse ici, un shell qui utilise les base fondamentales du framework c'est tout à fait portable.

Non c'est pas mieux du tout.
Y'a mieux : des sous-equipes sur de petites parties, des unit-tests obligatoire, de la revue de code... et du typage statique.

Oui, mais des projets de 150 ans/homme on en trouve pas non plus tous les jours.
Non mais des projets de plusieurs centaines de milliers de ligne de code avec plusieurs développeurs sur plusieurs années il y en a une floppée, je dirais même que c'est la majorité. Et bizzarement dans tous ces projets tu retrouve rarement du Python ou du Ruby ;)
En espérant juste que ton logiciel ne devienne pas plus ambitieux.

alors tu imposes à tes équipes de passer par l'analyseur qui contrôle les types.
Tu te prends pas la tête et tu imposes un langage typé statiquement et fortement, auquel toute ton équipe est de préférence habitué.

. Je ne dis pas que le contrôle est mal, ce que je dis c'est qu'il faut que ce soit un choix, pas une contrainte.
Bah voilà c'est bon, on a déjà ca : pour les vrais gros projets où tu recherches un minimum de qualité tu prends un langage typé, compilé (parcque bon tu veux aussi des perfs tant qu'à faire), etc. Pour les petits projets où y'a 2 codeurs, tu peux te permettre de choisir un langage comme python, VB.NET ou Ruby. On se rapproche bien de l'objectif initiale de ces langages : ce sont des langages de script dynamique.

C'est pour ca que le parlais d'ingénieur informaticien : l'ingénieur est censé s'adapter au domaine dans lequel il travail, quitte à y acéquérir des connaissances pointues. C'est pas à l'académicien de se mettre à l'info.

Je ne vois pas trop l'interêt de brancher la sortie vidéo sur la freebox
Y'a pas d'entrée vidéo sur la freebox ca risque pas :)
C'est plutôt une solution de streaming qui passe par ethernet entre le PC et la freebox. Comme dit plus haut, un serveur de type VideoLan semble correspondre.

Mais l'académie fait son boulot : elle définie les règles.
C'est à l'informaticien de les traduire en algorithme, pas à l'académicien. Dès qu'on demande à un informaticien de réfléchir c'est tout de suite trop on a l'impression : enfin c'est ce qui fait la différence entre un ingénieur informaticien et un codeur.

- tu profites de l'interpréteur "ca s'exécute à la moindre modif" voire du "debuggueur en cours de frappe"
Le prochain Visual Studio permet cela avec des langages comme C#. Je me demandes comment ils font mais visiblement pas besoin de garder le fardeau de l'interpréteur (qui mine de rien en est un question perf).

tu rajoutes les contraintes de type si tu le souhaites là où le code est plus délicat ou si tu souhaites renforcer les contrôles pour valider ton code
J'aime pas le "si" tu le souhaites. Je préfères que le langage le contraigne au développeur, pour le "forcer" à produire un code de meilleur qualité. C'est aussi ca le rôle d'un langage : ne pas être trop laxiste et forcer l'utilisateur. L'excuse du gain de temps en ne typant pas n'est pas du tout valable pour moi.

Que je sache les dev de M$ n'ont pas aidé dans le projet Mono/DotGNU.
Eh oui il y a des choses que tu ne sais pas : Les dev de M$ ont gentiment aidé les dev de Mono quand ceux-ci avaient des difficultés.

Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
Sauf qu'en général le prototype c'est pas une "référence". C'est pas forcement "bien" de partir de son code, il faut mieux parfois reprendre tout à 0 de façon plus propre, lorsque les différentes idées dans le prototype commence à se mettre en place.

Toi tu proposes d'améliorer au fure et à mesure la qualité du code de ton prototype. Pourquoi pas. Je ne suis pas partisan de cette manière de faire, je préfères faire le plus propre possible dès le début, en me basant sur un modèle plus abstrait validé "théoriquement".

Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
A l'arrivé on est parfois plus productif puisque l'IDE propose automatiquement les méthodes qui s'applique à un objet. Dans un langage où le type n'est connu qu'à l'exécution ca va être "balèze". Souligner les fautes est également productif à mon goût.

Bref tout est affaire de compromis entre performance et productivité.
Je ne parlais pas de performances, là j'aurai trop epru de troller ;)
Je préfères me contenter de parler de compromis entre productivité et "qualité".

Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
Très bonne conclusion avec laquelle je suis d'accord. Cela va assez dans mon sens : les grands comptes qui font de "grosses" applis ont besoin du maximum d'outils pour vérifier et valider des bouzins énormes. D'où l'idée qu'un typage statique fort va dans le sens de la qualité (et avec un bon IDE sans rien sacrifier à la productivité à mon goût).

J2EE va vraiment dans le sens des grosses applis, Python/Ruby pour le RAD. Mono je le situerais bien entre les 2. Peut être pas parfait dans un cas ni dans l'autre, mais à "l'aise" dans les 2.

Pour la prog par contrat je n'avais regarder que du côté de Eiffel.
Sinon une variante de Python avec typage fort et statique : Boo pour Mono.

Tout bon IDE te complète automatiquement le nom du type après avoit saisi "new". Conclusion tu tapes une seule fois le type, ce n'est donc pas plus long.
De plus tu peux très bien vouloir parfois ne pas mettre le même le même type à gauche et à droite. Typiquement tu peux instancier un type dérivé et ne conserver qu'une référence à une interface, pour t'obliger à l'utiliser en tant que tel.

Comme je l'ai dit plus haut je crois qu'on a pas les mêmes "sensations" à la compilation tout simplement parcqu'on utilise pas les mêmes langages. En C++ les temps de compile sont effectivement "relou", notamment avec les templates. Mais bon c'est tellement plus facile de compiler en C# sans ces problèmes de compile ;) Du coup moi j'ai pas les désavantages que tu as, mais je comprends que cela puisse t'énerver.
Cela dit le problème ne vient pas du typage fort et statique en soit, ni du compilo, la preuve en Java ou C# tu peux obtenir un très bon confort sans ces "temps" de latence, tout en conservant le compilo.

La question c'est : est-ce qu'il est indispensable que ton langage à typage fort et statique soit un langage compilé pour pouvoir faire ce genre de vérification ? la réponse est "non".
Arf evidemment vu comme ca. Mais bon d'une manière générale les langages dynamiques interprétés ne sont justement pas typés fortement, et encore moins statiquement.

Pour le reste je suis assez d'accord. En fait je crois que votre préocupation concernant la vitesse de compilation cible avant tout C++. J'avoue que C++ voilà quoi, ca me gave et effectivement, pour peux qu'on utilise beaucoup les templates... Je préfères largement coder en C# ou Java, là je n'ai pas ces problèmes de compilation "lente", et donc pour moi le compilo n'est qu'une étape sans aucun désavantage.

NON! Je bosse sur Visual Studio en ce moment et le fait qu'il souligne en rouge les erreurs de syntaxe n'est pas une compilation puisqu'elle ne génère pas les fichiers exécutables.
Et qu'est t'en sait ? Il peut très bien générer le code intermédiaire (la première phase de compilation qui correspond au "front-end") sans te pondre explicitement le code dans un répertoire pour que tu le vois.

Quand tu fais des tests d'intégration!
C'est complémentaire, pas exclusif.

Ben c'est plus long que de ne pas l'indiquer
Pour le prototypage je reconnais qu'un langage sans typage peut être "pratique". Mais ca reste du prototypage. Ca rejoint l'idée première de ces langages qui restent des langages de "script", pas pou faire des grosses applis.

Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Les templates en C++ c'est un peu affreux, j'en convient.
En Java le compilo remplace partout la référence au type par object avec un cast. Il n'y a donc pas de génération spécifique.
En C#, le typage est conservé dans le bytecode, le code spécifique est généré à la volée, tout en conservant toutes les informations sur la "généricité".
En C# non seulement c'est un gain non négligeable en terme de fiabilité (puiqu'il permet d'éviter de nombreux casts tout en permettant au compilo d'effectuer des vérifications), mais c'est aussi un gain de temps à l'exécution (une pile d'entier est allouée sur la pile, alors qu'une pile d'objet ne l'est pas).

Enfin pour te montrer que le typage est si "important", il a constitué pour Java et C# une des principales améliorations et atouts de leur évolution, parcque réclamé par les dev.

(cf le lien sur la page de Bruce Eckel que j'ai donné)
J'ai du mal à comprendre son point de vue. Je vois pas pouquoi il posse 2 notions qui sont complémentaires. Tout est bon pour améliorer la qualité du code, que ce soit le typage statique et fort, les tests unitaires, les contrats, etc.
Le but étant d'automatiser le maximum de tâche (une machine se trompe rarement), c'est pourquoi sont apparus les Garbage collector entre autre.

Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Arf effectivement si tu poses bien tes contrats tu vas résoudre pas mal de problème.
Mais on en revient toujours au même point : c'est l'humain qui rédige les contrats, et à moins d'avoir des outils comme le langage B pour formaliser tout ca et s'assurer de la validifé des contrats, il restera toujours une marge d'erreur.

Si tu rédiges des contrats en Python, ils te péteront à la tronche à l'exécution. J'espère que ca ne sera pas chez le client le jour où un contrat aura été mal rédigé.

Enfin tu me fais sourir quand même : tu veux pas écrire le type de tes variables par "gain de temps", et tu consommes une bonne partie de celui-ci à la rédaction des contrats. Cette reflexion sur les contrats doit en plus t'amner bien souvent à "réfléchir" sur le type à l'exécution de tes variables.
De plus préciser le type d'un paramètre par exemple fait parti de la signature d'une méthode, si tu mets plusieurs méthodes dans un même "conteneur", t'as une interface, qui constitue déjà une sorte de contrat, qui lui a l'avantage d'être checkable à la compilation, et donc qui sera vérifier par un outil avant d'aller péter le cas échéant chez le client.

C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Ben dans le cas d'un langage typé fort et statiquement, si c'est une des finalités. Si pour toi contribuer à améliorer la qualité du code produit n'est pas dans les objectifs d'un compilo...

C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Je te ferais remarquer que gcj tourne sur un peu plus d'architecture, et il est tout à fait capable de compiler "à la volée" (JIT) le code intermédiaire : tu ne perds pas la portabilié. Et ayant généré un exécutable pour la machine cible, c'est celui-ci qui sera de nouveau exécuté. Non là tu ne perds pas la portabilité.

En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
Genre le refactoring tu trouves pas ca pratique ? En python t'as jamais envie d'extraire une interface d'une classe ? Ah ben non désolé y'a même pas la notion d'interface :) T'as jamais besoin de renommer une variable ? Et là tu vois un parfait exemple d'utilité du refactoring : tu modifies le type d'une variable, le refactoring applique les modifs partout, et bien le compilo te gueuleras dessus si jamais une erreur de typage a été introduite quelque part.
EN Python t'as intérêt de te rappeler quelles sont les conséquences de tes changements.

Si pour toi la complétion automatique de méthode n'est pas un gain de productivité je ne cherche plus à comprendre... Le typage fort instaurant de plus de nombreux tests automatique, il permet d'obtenir un peu plus de fiabilité, au final de bugs en moins et donc de la productivité en plus.

Enfin franchement j'ai du mal à te suivre : tu semble "fan" des contrats (j'abonde dans ton sens), mais tu refuses le typage statique, alors que les 2 notions cherchent le même but et sont complémentaire : assurer une certaine qualité du code. Enfin tu sembles préférer faire confiance exclusivement à ta rédaction des contrats plutôt que de confier des vérifications de base à un outil dont c'est en parti le boulot.

Ah mais j'insiste seulement pour dire qu'il n'y a MALHEURESEMENT pas d'équivalent à ces 2 plateformes. Je trouve ca dommage qu'il n'y est pas eu d'initiative libre et indépendante pour en créer une. Je constate, mais en même temps je comprends : rassembler une bande de hacker pour coder un soft OK, mais rassembler toute une troupe d'architecte dans une même pièce (le braiinstroming à distance c'est pas encore ca) pour concevoir l'architecture d'une telle plateforme, ben, c'est pas tellement à la portée de n'importe quel communauté du libre :-(.

Ce qui est contre productif c'est d'être obligé de mettre des déclarations de type partout alors qu'on veut simplement tester une idée.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.

Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
On a inventé les génériques :
Pile maPile;

De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?

Tu developpes ta classe et ton test unitaire associé en même temps..
Genre toi humain t'es beaucoup plus fiable pour générer des tests unitaires exhaustifs en pouvant te permettre de te passer des vérifs qu'apporte un typage fort et statique.
Si encore tu me disais : moi je tests jamais les progs je comprendrais, t'assumerais effectivement jusqu'au bout, mais là non.
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), alors bon question productivité je préfères faire confiance au compilo et garder mes tests unitaires pour ce qu'il ne sait pas faire.

Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme pour les tests unitaires : il est fortement conseillé de les écrire D'ABORD. Tout va toujours dans le même sens : on met le maximum de contraintes (tests unitaires, typage, etc.) et on code APRES.

Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.

'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...)
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.

Par contre les inconvénients du typage fort subsistent.
C'est quoi déjà les inconvénients ?
Ah oui tu peux pas mettre n'importe quoi dans ta pile, et c'est super long à taper le type.

PS : déclarer le type d'un objet c'est aussi une forme de documentation pour celui qui relis le code.
Taper le mot "int" ou "MaClasse" c'est une part négligeable de la rédaction du code et cela permet de gagner un peu plus loin : l'IDE ayant le type il peut te proposer les méthodes applications à ton objet , et ca question productivité c'est un gain beaucoup plus important.

Oué bientôt il y en a un qui vas nous inventer les frames. Ah quand Ruby on Frames ?

En même temps tu prends exemple sur PHP qui est un langage interprété avec un typage dynamique.
Moi je te parle de C++, Java ou C#, avec un vrai compilo qui vérifies le typage statiquement (quand c'est possible) et vrai IDE.

Et franchement non, la phase de test et la phase de compilation sont deux choses séparées.
T'auras beau dire tout ce que tu veux, le compilo fait un nombre incalculable de tests, surtout avec un langage à typage fort et statique. Que tu le veuilles ou non, quand le dev compile il fait une première passe de tests. D'ailleur les méthodes de dev récentes dites "agiles" comme l'XP préconise l'utilisation intesive des TESTS unitaires. Et bizzarement dans le cycle de dev on les faits souvent s'exécuter juste après la compilation, comme si c'était la suite logique des premiers tests...

Visiblement tu n'as rien compris à ce qu'est un compilo, à ce qu'il est censé faire. Il n'est pas censer que "pondre" du code, un compilo c'est avant tout un analyseur lexical et syntaxique qui constitue une première couche de TESTS et un générateur de code. C'est loin d'être seulement la 2ème partie.

Tu dis que l'avenir est aux outils d'analyse de code : mine de rien le compilo est l'un de ses outils, rien n'empêche d'utiliser d'autres outils à côtés.

C'est un peu comme les gens qui denigrent au lieu d'essayer de faire avancer le schmillibilick en envoyant des patches quand ils sont de bonnes idees.
Parfois il faut mieux se faire une raison et laisser tomber une techno plutôt que de s'evertuer à envoyer des "patchs" pour tenter de transformer un cochon en une poule dans l'espoir qu'elle nous ponde des oeufs.

Oué enfin dans le contexte d'une grosse appli, se passer d'un typage fort statique (et tous les avantages en matières de vérification/optimisation), tout ca pour pouvoir s'amuser à coder dans le débogueur je trouve cela pour le moins douteux comme justification...

La plateforme autour d'Objective-C, notamment par Apple, est effectivement un bon exemple de plateforme complète, mais uniquement pour le desktop. Pour ce qui concerne les serveurs d'application par contre c'est pas du tout ca à mon avis.

Pour Ruby on Rails, ca semble être un joli jouer pour faire du RAD, mais pour faire une vrai grosse appli 3-tiers, c'est pareil c'est pas du tout comparable à J2EE. Tout celà allié à la vélocité (hem) de Ruby tu vas rigoler à la monter en charge.

N'importe quoi qu'est ce qu'il faut pas entendre...
T'as déjà entendu parler de compilation incrémentale ?
Tu crois franchement que tu as besoin de recompiler systématiquement toute l'appli ?
La phase de compilation c'est de l'ordre de la seconde lors d'une phase de dev normale. Avec certains IDE (Eclipse, Visual Studio) c'est même fait en background avec retour instantané (surlignage de la faute) lorsque le developpeur tappe son code.

Et puis franchement cette phase de "compilation" c'est aussi pour gagner du temps à l'exécution. Bref, c'est tout benef, il n'y a aucun inconvénient en terme de productivité, au contraire c'est une première phase de test qui permet d'éviter bien des conneries.

avoir une étape de compilation allonge le cycle de développement
T'as qu'à considérer l'étape de compilation comme une étape de tests générés et exécutés automatiquement. Tiens tout à coup c'est beaucoup plus productif et ca enlarge plus ton cycle de developpement.

De même que Java est un langage destiné à faire des applets.
Et ? Quel est le rapport avec ma phrase ?
Je dis que Python est un langage de script, c'est un fait. L'utilisation que tu fais d'un langage comme Java dépend de ses API et peut fluctuer.
Je vois pas où est le troll, j'essai de montrer que les avantages de Python réside dans ses choix de conception "dynamique", et qui sont tout à fait pertinent dans un contexte de langage de script. Dans un contexte d'application côté serveur où l'on recherche les perfs mais aussi la sécurité, Python n'a plus aucun intérêt face aux autres solutions.
C'est pas parcque tu vas réussir à manger un steack avec une cuillère que c'est pertinent.

Comme d'hab je parle de l'ensemble, du niveau d'intégration des API dans la plateforme, pas des langages en soit.