TImaniac a écrit 6423 commentaires

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.

[décuvé]
Pas les moyens ou pas le besoin? Certainement un peu des deux
Pas les moyens, j'en suis convaincu : le besoin est évident, même s'il ne concerne pas tout le monde ce genre de plateforme a des avantages indéniables, Mono ou JBoss en sont les meilleurs exemples.

Elles le sont pour moi et pour nombre de développeurs.
Je crois surtout qu'une grande partie des dev n'a pas essayer ces solutions, de par l'absence de plateforme libre dans le passé : c'est relativement nouveau dans le monde du libre, c'est d'ailleur pour cela qu'il y a beaucoup de "bruit" autour de Mono et autre Classpath.
C'est facile à vérifier : tu codes en PHP, tu essaies ASP.NET et tu reviens à PHP. C'est douloureux.

Si tu trouves que les développeurs libres ne font pas ce que tu veux, tu peux soit mettre la main à la pâte, soit retourner jouer sous windows et payer des licences.
Désolé, j'ai pas zindows sur mon PC ni aucun soft où il faut payer une licence.

Bref machin machin, de toute facon je crois qu'on a les mêmes valeurs. Le fait est que le libre n'a pas la chance d'avoir les moyens de concevoir une plateforme entière libre sur le modèle de Javaé/.NETL. C''esst bien dommage que le proprio est encore cet avantegage d'avoir le temps de concevoir dfe telle pltagefoeme et que le libre n'est que la possibilité de copier sans innovoer mais c'est un fait : ils sont un avantage technologique indusctiable. Nous avons toutes les idées, les hbommes pour coppier mais pas les moyens d'innovezr. Dommage.
BOn ben je suis à moitié tocher donc sur ce je te souhaites une bonne nuit @ plus dans l'buds :)

Mouarf. Ce n'est pas du tout parcque les développeurs du libre n'aime pas les contraintes. C'est du n'importe quoi ca. A quoi sert freedesktop.org ? Pourquoi il y a-t-il des HIG pour la plupart des desktops ? Et plus fort pourquoi y a-t-il des implémentations libre de framework proprio si ce n'est justement pas de chercher ce "graal" manquant sous Linux : l'intégration ?

Le libre ne préfère rien du tout à l'intégration. C'est juste que le libre n'a pas les moyen de gérer un framework de cette ampleur. C'est pas l'envie qui leur manque.

Et on a toujours le choix, la preuve y'a .NET ET Java. Si on suit ton raisonnement le libre devrait proposer une alternative à ces 2 là, juste pour le plaisir d'avoir le choix.

Et puis je te rappelles que l'intégration est également un gage d'interopérabilité puisqu'il faut respecter des contraintes dans les 2 cas.

Non je viens de te dire que ce n'est pas les fonctionnalités mais l'intégration, la sécurité et la productivité qui font le succès de .NET/Java. (Et des perfs décentes)
C'est quand même pas trop restrictif !
Mais le principal ecueil c'est l'intégration, construire un framework cohérent de l'ampleur de ces 2 plateformes est un boulot monstre qui est loin d'être à la portée du premier projet libre venu.

Effectivement difficile d'utiliser de l'objet avec Erlang... Mais c'est là où je voulais en venir : il est beaucoup plus facile de développer un client Java qui appelle ton serveur Java en utilisant RMI : tu ne change pas de paradigme (tu restes objet des 2 côtés) et tu utilises une techno parfaitement intégrée (RMI).
Avec Erlang d'un côté et Python/C++ de l'autre voilà quoi.

De toute façon, pour recentrer le forum, la question n'est pas intégré ou hétérogène, mais est-ce que ces plateformes libres peuvent elles répondre aux mêmes problèmes que Java/.NET avec leurs solutions à elles (intégré ou pas).
Non le problème c'est d'évoluer. Je me doute qu'on pourra toujours faire la même chose avec telle ou telle techno. Les plateforme de type .NET/Java apportent de nombreux "+", non pas en terme de fonctionnalités mais en terme d'intégration de technos dans une même plateforme unifiée, productive et sécurisée. C'est ce qui fait le succès de ces technos et c'est ce qui fait qu'elle attirent les développeurs : d'où l'apparition d'implémentation libre de ces plateformes, en l'absence de réel concurrent libre.
Donc pour rechercher une plateforme équivalente, il ne faut pas voir que la facon de créer une solution, mais rechercher une plateforme qui a les mêmes atouts qui font le succès de Java/.NET. Parcque sinon on serait resté à l'assembleur. C'est vrai quoi en cherchant bien on aurait pu tout faire avec et donc répondre à tous les problèmes.

Pour remplacer RMI, on peut faire du RPC
C'est pas du tout comparable. RMI c'est un modèle de communication entièrement objet, et vraiment transparent pour le programmeur. C'est à des années lumières question productivité de RPC.

Pour la maintenance, je ne vois pas quel problème tu auras en plus par rapport à une solution J2EE
Je l'ai dis, le support de plateformes et technos hétérogènes.

un moteur de recherche de mp3 sur le web distribué (en Erlang), une interface web en PHP et un programme en Python pour calculer un "taux d'affinité" entre une musique et un utilisateur
C'est bien ce que je dis, ca ressemble plus à du LAMP qu'à un environnement complètement unifié et intégré comme Java.

Corba c'est un protocole et un standard. Ce sont les impléméntations qui divergent.
Oué bah c'est aussi le but de Mono/.NET : proposer un standard indépendant des langages...

Et là ca ne te dérange plus de changer de techno et de langage, bizarre.
Oué bon ok. En fait il manque quelques trucs à Mono pour être à la hauteur de Java côté fonctionnalité. Même si Python a des fonctionnalités proche de Mono il reste un fossé énorme côté performances. Et même fonctionnalités. Que je sache il n'y a a aucune équivalent à ce que propose ASP.NET chez Python.

Quant aux performance le JITs c'est récent et il n'est pas exclu que des progrès soient accompli avec python aussi. Ppour ;l'instant ce n'était pas la priorité mais chaque nllle version de Cpython améliore les perforamances sans compter le projet Psyco.
Le plus rigolo c'est que l'implantation de Python la plus rapide tourne sur .NET/Mono :-p
Psycho c'est gagné en perf pour perdre en portabilité. Désolé mais ca vaut pas un bon vieux JIT.

Bref on est dans du plus pur troll.
Je crois surtout que tu n'as jamais programmer une application pour J2EE ou une application pour Mono/.NET. Tu cernerais tout seul les différences et tu aurais conclus par toi même qu'il y a un fossé entre les catégories même si certaines utilisations peuvent se recouper.

En même temps la fondation Mozilla participe à ce que tu rejettes en pétant les couilles de ceux qui veulent utiliser les noms et icones officiels dans des versions modifiées.

Tu cherches un concurrent ou une copie?
Je cherche quelque chose qui me propose de répondre aux mêmes solutions.
Donc un concurrent à Java doit me fournir une plateforme avec des API tout aussi garnies, des perfs décentes et un langage "productif".

Tu fais comment? Je n'ai pas vu cette possibilité dans Java...
Bah si tu modifies un .class lors des prochains chargements de cette classe cette nouvelle version sera pris en compte, même si des instances existent déjà.

Lesquels? Si tu n'utilises pas cette possiblité, elle ne va pas te manger!
Ca c sûr. Mais du coup je me demandes toujours quel intérêt à le langage Python, puisqu'on m'avance toujours cet argument.

Si tu en lis un consacré à Python, ils implémenteront ça d'une autre façon.
Euh désolé j'ai jamais lu de bouquin de DP appliqué à Java. Le plus fameux, le GoF fait référence au C++.
Trouve moi un livre consacré aux DP en Python. Le modèle objet de python est vraiment pas beau à voir, on sent bien que c'est un "rajout" bricolé.

Tu proposes un cluster parcque tu sais pertinement que Erlang a des perfs pitoyables ? :-)

Maintenant tu me proposes quoi pour remplacer JSP et les web-services ?
Tu me proposes quoi pour remplacer RMI ? Me dis pas que tu comptes faire du RPC avec ton client lourd en Python/C++ quand même :)

Non sérieusement c'est joli ton truc, mais paye ta maintenance : des technos par forcement compatibles avec des langages hétéroclyte, ca va être facile à maintenir tout ca dis donc.

Tiens d'ailleur tu me montres un exemple d'utilisation de ta combo qui tue ?

RMI c'est bien parcque c'est intégré au langage et ca supporte complètement Java. Corba c'est rigolo mais c'est intégré dans rien du tout. C'est tellement bien que c'est c'est une des raisons qui a poussé Icaza à faire Mono.

Bref tu considères que le tout intégré c'est la panacée mais c'est aussi la contrainte d'où le succès grandissant des solutions LAMP
Tout à fait : ca boxe pas dans la même catégorie, pour certains trucs Java est pas adapté et inversement, mais à par C# j'en connais aucun qui rivalise Java dans son domaine de compétence.

il s'exprime pleinenent sur le poste de travail car il s'intègre bien avec tout un tas de toolkit.
Oué mais là ca n'a pas plus d'intérêt que C#/Mono qui a les mêmes avantage. Désolé mais je n'arrive vraiment pas à voir ce que Python a de plus. Je vois très bien ce qu'il y a en moins mais pas en plus.

Quant aux parts de marché, Zope n'est pas soutenu par les mastodontes commme IBM BEA Sun & Co donc forcément ca ce ressent
S'il Zope n'est pas soutenu il y a peut être aussi une raison. IBM aurait très bien pu se tourner vers autre chose que Java.

Sauf que ce que j'explique c'est que c'est en train de changer.
Zope ca fait des années qu'on en parle, n'empêche que le soufflé est vite retombé. J'ai du mal à voir comment il va remonter :)

Pour la charge, ben c'est pas le langage Python qui va aider, ca n'a jamais été une foudre de guerre hein ;)

Zope/Plone/Python est une bonne alternative qui aurait pu figurer dans cette étude.
Cela dit que je suis d'accord qu'il aurait été intéressant d'avoir d'autres plateformes dans cette comparaison. Mais ne perdons pas de vu que le document vise avant tout à apprécier l'impact des brevets logiciels sur des implémentations libre de framework proprio.

Ca dépend, comme souvent pour ce genre de grosse applis, si t'as une architecture classique n-tiers avec plusieurs "interfaces" classiques : un client lourd (typiquement RMI), un client "web" (JSP) d'autres clients web (web-services), je suis pas du tout convaincu que Erlang sera tout aussi pertinent.
Il suffit pas de savoir gérer les transactions, il faut savoir "tout" gérer. Ce qui fait de Java une usine à gaz pas toujours utile (d'où le nombre important de plus "petits" projets écrits dans des frameworks moins "lourd" comme PHP ou Python), mais qui fait aussi que Java est un des seuls à boxer dans sa catégorie.

Ah oui et puis erlang il a beau gérer les transactions, quand tu vois les perfs du langage tu pries pour qu'il n'y est pas trop de monde à faire mumuse avec le serveur ;)

Héhé boubou ca tu peux je rajouter dans ton document ;)

un tableau qui montre clairement que Python n'a pas du tout de plateforme unifiée pour faire serveur d'application.

Ton document reprends point par point les technos J2EE en tantant de trouver un équivalent en Python. On s'en fou qu'il y est un remplacant point par point, il faut un remplacant global capable de remplacer l'ensemble. Le jour où y'aura une plateforme complète et unifiée capable de faire tout ce que fait Java alors je dirais ok.

Enfin visiblement le marché me donne raison : les parts de marché de Zope (qui existe quand même depuis un certain temps) sont ridicules.

Ah oui au fait c'est quoi l'équivalent de RMI en Python ?

Ecoutes, j'essai de montrer que l'intégration est un atout, je dis pas qu'il n'y a pas d'autres solutions. Donc quand je dis qu'il n'y a pas de plateforme équivalente à C#/Java je parle aussi de l'intégration.

Tu mélanges un peu tout:
Je mélange pas, je prends plusieurs caractéristiques.

le typage fort est bien pour détecter les erreurs à la compilation, mais le typage de Java n'est pas non plus super contraignant
C'est toujours mieux que Python, même si ce n'est pas aussi bien que les contrats en Effel. Seulement Effel n'a pas tous les APIs de Java. Tout est une histoire de compromis. Je demande un concurrent à Java ou C#, il faut choisir, tu ne peux pas dire une fois : Python gnagna et une autre fois Effel gnagna.

(Moi j'en vois un: mettre à jour un programme sans l'arrêter.)
Ah parcqu'en Java on est obligé d'arrêter le programme ?
Désolé mais d'une manière générale cela n'a quand même que peu d'utilité dans la pratique, et pourtant quand je demande : et qu'apporte Python ? On me ressort systématiquement cette possibilité. Pourtant moi j'y vois surtout des inconvénients.

- quel est le rapport entre la notion d'interface et la sécurité?
Avec les interfaces tu peux déjà mettre en place une première notion de contrat : une interface n'est rien d'autre qu'un contrat quand aux APIs exposés par une classe. C'est loin de Effel mais c'est déjà fort pratique. Il suffit de lire un bouquin de design pattern pour s'apercevoir que beaucoup de collaboration font appelle à des interfaces. Les interfaces font cruellement défaut à Python.

Ca va faire plaisir à tous ces gens ce que tu dis
Ma phrase n'avait de sens que dans son intégralité. Je vois même pas l'intérêt de ta remarque puisque tu est d'accord quand je te parle de transactionnel.

En plus ce sont peut-être pas les mêmes niches de marché.
C'est ce que j'explique : Python est loin d'être pertinent dans toutes les utilisations, et de ce fait ne couvre pas la même chose que Java ou C#, et donc ne boxe pas dans la même catégorie. CQFD.

Pour Python, il me semble qu'il existe plusieurs solutions de persistence et donc il doit y avoir de quoi gérer les transactions.
Vois pas le rapport. Java propose un ensemble d'API standards pour serveur d'application qui gère tout de A à Z. Il n'y a rien de comparable en Python.
Quand au bench Python vs Java, Python utilise plus de mémoire mais est nettement plus lent, plus de 15x plus lent dans certains tests. Ca se passe de commentaire. Fait le même temps en comparant Python à C# pour rire.
Erlang n'en parlons pas.
Php encore moins.

Même si tu vas trouver des API à droites à gauche pour tel ou tel langage, ce qui fait la force des plateformes associés à C#/Java c'est l'uniformité et l'intégration de ces APIs : ce n'est pas un assemblage de briques hétéroclyte mais un ensemble cohérent.

Pour ce qui est des IDE, il existe aussi un plugin C# pour Eclipse, mais autant dire qu'il n'y a aucun rapport entre faire du Java avec Eclipse et utiliser un autre langage dans Eclipse.

C'est pas pour autant que c'est pertinent.
Python est lent, pour un site web j'espère que tu n'as pas 100000 utilisateurs avec gestion de transactions. Et dans ce genre de cas tu aimes bien avoir un minimum de sécurité et de qualité. Désolé mais le côté "laxiste" du langage Python ne va pas du tout dans ce sens.

Que je sache en PHP tu peux te toucher pour espérer faire un serveur d'application. PHP ne se suffit pas lui-même il lui faut communiquer avec un autre langage.

Tous les langages ont pratiquement des APIs dans tous les domaines, c'est pas parcque les APIs sont dispos que la plateforme qu'il est pertinent de les utiliser.

Sans parler des perfsn, on peut aussi parler du langage en soit : question sécurité Python n'offre rien du tout : pas de typage fort, la possibilité de modifier dynamiquement une classe, pas de notion d'interface, que des trucs rigolos mais parfaitement inutile dans un cadre industriel.

Python est avant tout un langage de script, il n'a pas la même vocation que Java ou C#. On aura beau proposer des API similaires à Java il y aura toujours ses choix de conceptions qui en feront un mauvais choix dans des contextes ou la qualité et la sécurité sont prédominants.

System.Collections c'est pas dans le standard, peut être ?
Euh System.Collections n'a strictement rien d'innovant, ils peuvent toujours essayer et obtenir un brevet, un prior art sera facile à démontrer.

Ce document indique explicitement qu'une implémentation de Jave en open source est possible, sans enfreindre les brevets associés
Aujourd'hui mais demain ?

On ne sait pas officiellement pourquoi.
C'est bien pour ca que je prends pas leur avis en compte :) La plupart des autres distributions ont intégrés Mono, seul RedHat fait de la résistance sans donner d'explication.

La situation est radicalement différente pour .NET : on ne sait pas si une implémentation open source est possible car aucun document en valeur légale n'est disponible publiquement concernant ce point.
Ah non !
A l'heure actuelle il n'y a absolument rien qui empêche une implémentation libre de Mono, MS n'a pas donné son autorisation et n'a pas à la donner : il n'a pas encore les brevets pour le protéger.
Donc peut être que demain MS fera chier. Aussi vrai que peut être que demain Sun fera chier. Donc c'est exactement pareil. Surtout que les brevets MS peuvent s'appliquer à Java.

Imaginons qu'un des brevets soient violer dans Java par Sun, Sun et MS ayant passé un accord ils ne s'attaquent pas mutuellement, mais MS demande à Sun de plus autoriser l'utilisation des brevets en question dans des implémentations libre. que pasa ?