TImaniac a écrit 6423 commentaires

désolé d'avoir déliré, j'aurai du employer le terme de "ultra-innovation" plutôt que "nouveauté". Enfin j'ai compris et t'aurais du comprendre que j'avais compris :)

Mais celà ne change rien à ce que je dis, celà ne sert à rien de proposer quelque chose d'innovant si c'est pour faire table rase de l'existant.

Pour moi j'associerai désormais TrucStep à la plateforme de MacOSX, mais en aucun cas j'associerai cette plateforme à un choix de portabilité parcque celà s'intègre nul part (ou tout de moins rien n'est fait dans ce sens)

Bon maintenant je vais aller chercher moi même ce qu'il y a d'innovant dans cette plateforme (désolé, je ne vais pas comparer avec ce qu'il y avait y'a 10 ans mais avec ce qu'il y a maintenant) puisque personne veut m'expliquer concrêtement ce que ces superbres APIs vont m'offrir de mieux.

Attention je ne veux pas troller sur Objective-C, je ne connais absolument pas ce langage, je me demandais juste si les APIs dispo étaient limité à GNUStep

Je me rend bien compte que la plateforme GNUStep a été pensée dans un nouvel environnement, peut être innovant (j'ai pas testé je ne jugerai donc pas).

Mais voilà, ce que je trouve dommage dans GNUStep, c'est qu'elle propose trop de nouveauté et pas assez de possibilité d'intégration dans l'existant. Tu le dis toi même, utiliser GTK ou Qt pour la partie graphique tout en conservant la plateforme GNUStep, c'est pas l'idéal et y'a pas beaucoup de bindings.

J'ai pris l'exemple de mono parceque je connais bien cette plateforme, et que bien entendu je cherche à comparer une nouveauté (même s'il elle a 10 ans) avec ce que je connais.

La news dit clairement que GNUStep ca roxe, et beaucoup ont l'air de se demander pourquoi elle n'est pas utilisé. Je lis partout que un des gros avantage de rapidité de développement (notamment sur leur site), c'est la portabilité. Mais tu le dis toi même, elle n'est pas bien utile pour l'interface puisque c'est GWorkspace son environnement de prédilection.

Moi je veux une plateforme qui me propose un environnement mais qui me propose aussi de m'intégrer dans les autres environnement. Je trouves celà beaucoup plus important dans le cadre d'une portabilité.

pour la doc/tuto C#/qt#, le plus simple est de suivre les exemples Qt, à la syntaxe du C# près Qt est utilisé de la même manière.
Perso c'est ce que je fais pour GTK#, je look la doc officielle de GTK.

Pour un format XML de qt, ben, désolé je peux pas t'aider j'en connais pas.

GNUstep s'intègre parfaitement à WindowMaker.
Vi mais comme tu me l'as gentiment fait remarqué dans un de mes commentaires précédents, pour moi l'existant desktop actuellement c'est Gnome et KDE. WindowMaker voilà quoi.
Ca sert à rien d'avoir une plateforme portable si elle ne s'intègre pas dans les environnements les plus utilisés, surtout pour une plateforme desktop.
"C'est super portable, mais on vous conseille d'utiliser WindowMaker"
youpi.

Donc, sur Apple les menus d'applications Qt seront "ergonomique" par rapport au reste des applications.
Youpi alors t'as trouvé une astuce de KDE pour ressembler à Apple et tu crois avoir contredis ma affirmation qui dit que les applications 100% portables s'intègre très mal lorsqu'elle change d'environnement.
Moi je veux rien configurer, je veux utiliser mon application de la même manière que j'utilise les autres applications de mon environnement, sans de voir m'adapter aux particularités "ergonomiques" issue de l'environnement initial de développement.

Pour obtenir une meilleure intégration, il faudra multiplier les types de fenêtres prédéfinies genre dialogue etc.
Dans la plateforme ? Oui c'est une solution, mais on perd une grosse partie des spécificités de chaque plateforme en se contentant des points communs. Ou alors on en est rendu à "imiter" certains composants absent de tel ou tel environnement.
Et puis il ne faut pas oublier qu'il n'y a pas que les fenêtre prédéfinies qui demandent de l'intégration, c'est tout l'interface qui doit être pensée en conséquence.

A l'heure actuelle, la seule solution est de faire une application ou la couche de présentation est bien différenciée du reste de l'application, et de réécrire cette couche pour chaque environnement cible. C'est la seule manière d'avoir une solution de qualité, on se contentera de la portabilité de s autres couches.

J'espère que tu comprends mieux pourquoi je trouves que cette plateforme est jolie mais a oublié le principal objectif de toute solution desktop : l'intégration. Je crois que c'est une des principales causes de ce qui lui arrive. Heuresement que MacOSX l'utilise, parcque sinon j'y verrais pas beaucoup d'intérêt...

tu ne comprends pas du tout ce que j'entend par intégration...

T'as sûrement remarqué, on peut faire tourner une application KDE sous Gnome et inversement. Tu trouves pas qu'il y a de nombreux problèmes d'incohérence d'ergonomie entre les interfaces ? Pourquoi à ton avis on trouve des applications gMachin et kMachin si une seule suffisait ?

Pourquoi KDE existe ? pourquoi Gnome existe ? S'il n'y avait aucune différence, que la seule était le window mamager, y'a longtemps que les projets auraient fusionné...

Je parle d'ergonomie, il y a des chartes graphiques à respecter dans chaque environnement, et aussi une charte d'ergonomie (nom des menu, emplacement des boutons, format d'une fenêtre de conf, accessibilité, etc.)

Je cherche pas des poux à GNUStep, je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé).

Mais vraiment n'importe quoi... depuis quand l'interface n'a pas besoin d'être portable ?
Depuis que de nombreux programmeurs croivent que Java & Co vont résoudre tous les problèmes de portabilité, se sont ensuite rendu compte que y'avait un problème d'intégration visuelle (en partie résolu avec des thèmes utilisant les toolkit natifs) et maintenant un autre problème : intégration ergonomique, et là je ne connais aucun toolkit qui peut se vanter d'être portable tout en respectant l'intégration.

Icaza le dit clairement, la portabilité c'est bien, mais pas au détriment de l'interface.
Mono propose GTK# pour utiliser GTK. Après le fait est que GTK tourne sous MacOSX et Windows, celà peut être une solution portable efficace lorsqu'on ne se soucis pas de faire un soft de qualité (on veut juste qu'il marche partout).
Après Mono marche très bien avec les WinForms sous Windows, et ils bossent d'arrache pied sur Cocoa#, sachant que Qt# est existe également. A ton avis pourquoi ils s'amusent avec tous ces toolkit ? Pour faire joli ?

Un journal avec déjà de nombreux commentaires sur le sujet :
http://linuxfr.org/~pterjan/15684.html(...)

Sinon il semblerait que les DSLAM de Free supporte également la nombre READSL qui ne vise pas à augmenter le débit mais à accroître la distance entre le client et le DSLAM (8km)

Bref, que du bon.

Ceux qui ont râlé tout l'été en attendant leur freebox, savent maintenant pourquoi : ce sont les premiers a avoir la freebox v4 compatible l'ADSL 2, ca vallait le coup d'attendre.

Quand tu développes en Objective-C, tu utilise le framework GNUstep...
Ah bon le langage est limité à la plateforme ? (???)

Je ne vois pas le rapport avec Gtk ou Qt...
Ben si, moi j'en vois 1 : si j'ai envie d'intégrer une appli écrite en Objective-C dans un environnement Gnome ou KDE. S'il n'y a aucune possibilité d'intégration de cette plateforme aux environnements existant, je comprends nettement mieux pourquoi personne n'utilise NeXTStep en dehors de l'environnement MacOSX qui a été développé pour...

C'est gentil la portabilité
C'est gentil un beau langage
C'est gentil une belle plateforme super puissante et performante qui n'a pas bougé depuis 10 ans et qui va grandement augmenter ma productivité

Mais si je ne peux même pas concevoir une application desktop qui s'intègre ailleur que dans un environnement dédié, ben je dis que c'est normal que ce soit au même stade depuis 20 ans.

Un projet comme Mono a l'avantage de ne pas promettre systématiquement la portabilité, ils préfèrent supporter plusieurs environnement (Windows, Gnome et Cocoa) et promettre la portabilité de ce qui DOIT etre portable (bref, pas l'interface)

Maintenant, question à 2 euros, que me propose GNUStep pour m'intégrer à l'existant ? Je peux facilement utiliser GTK ou Qt ? Nan parcque en l'absence d'environnement comme Gnome ou KDE pour GNUStep, je ne peux qu'envisager GNUStep sur plateforme MacOSX...
C'est pas le tout de promettre l'interopérabilité, mais si celà doit se faire au détriment de l'ergonomie parcqu'il n'y a pas d'intégration voilà quoi...

Je viens de lire l'introduction du projet GNUStep et notamment le paragraphe concernant les "avantages" de GNUStep.
Ben, à part le fait qu'il sont apparement plutôt fier du fait que le framework n'a quasiment pas bougé depuis 10 ans (ce dont je m'en fou pas ma à vrai dire, ce uqi compte pour moi, c'est ce que je peux faire maintenant et si je peux toujours faire tourner ce que j'avais fait avant), je n'ai vraiment rien vu de spécial qui fait que cette plateforme roxe largement J2EE ou .NET.
Donc bref, c quoi qui enlarge mon penis ?

sans aller jusque au ratio 1 pour 2, il est clair qu'en 96kbps le wma s'écoute plutôt bien, qasiment comme du mp3 160. Faut pas se leurer, mais si on peut mettre 3 albums au lieu de 2 sur son lecteur c'est déjà pas mal même si c'est pas le double :)

Clap clap clap, celà va vraiment faire avancer le schmilblick.

Délais d'ouverture de ligne aléatoire ? A part chez Wanadoo (me demande pas pourquoi, pourquoi c'est pareil chez tout le monde ?

Débit erratique, si tu suivais un peu, tu verrais que les reseaux de Free sont loin d'etre surchargés, le problème vient dans quasiment otus les cas de la qualité de la ligne du client, et celà Free ne peut rien y faire, et celà serait pareil chez tous les fournisseurs.

Hotline il y a effectivement des défauts, mais question incompétence et attentes, j'ai plein d'exemple chez Wanadoo ou Neuf.
La téléphonie fonctionne mal ? Pareil que plus haut, celà vient de la qualité de la ligne, à vrai dire je n'ai plus entendu personne se plaindre depuis plusieurs mois, au début il y avait effectivement des soucis techniques, comme pour la TV, mais maintenant celà fonctionne plutot pas mal du tout.

Quand au SAV j'en sais rien je ne l'ai pas expérimenté.

Alors voilà c'est bien gentil de raler, mais celà m'étonnerai que tout celà te soit arrivé à toi, où alors tu n'as vraiment pas de po. Dans tous les cas celà ne sert strictement à rien de généraliser, puisqu'on rencontre les memes problèmes chez tous les FAIs.

A noter que si tu voulais un service nickel, sans retard, avec un débit de crete en permanence et tout et tout, tu le paierais 60 euros ton forfait chez Wanadoo. Et encore, tu n'aurais pas plus de certitude sur la qualité de la ligne.

l'ADSL 2+ permet de plus haut débit mais également des synchro un peu plus loin. Meme si le gain n'est pas phénoménal, celà n'est pas négligeable, et si certaines personnes peuvent grace à cette techno avoir du Haut Debit, je trouve celà vraiment important, tout aussi important que le fait de fournir les freebox en moins de 2 semaines par exemple.

Mais c'est bien gentil de dire que tout est déjà présent dans GNUStep, qu'il n'y a besoin de rien recoder, et blablabla c'est mieux que les autres solutions, mais perso des plateformes comme ça j'en connais pas mal, par exemple Java ou Mono pour ne pas les citer. Alors en quoi GNUStep enlarge plus mon penis qu'une autre solution ?
Et quel IDE permet de tirer pleinement partie de cette plateforme ? Parcque bon, question productivité, on peut y aller à coup de Visual Studio, et là aussi tu vas pouvoir anlarger ton penis en encore moins de temps...

Sérieux je veux des arguments.

"permet de programmer des applications en quelques heures au lieu de jours, semaines ou jamais"

On peut avoir des arguments ? En quoi cette plateforme, surement superbe, permet-elle de développer plus rapidement une application ? qui de plus s'intègrera dans tous les environnements sur toutes les plateformes ? Parcque bon, celà fait quand meme longtemps que ca se saurait si ce saint graal avait été atteind...

Sinon ben bon anniversaire, et contrairement à ce qui est dit plus haut, celà peut-etre très beau, cf Cocoa.

tu fais du hors-sujet, là on ne débat pas de l'intéret des brevets, c'est juste une blagounette.

Bon bah ca y est, celà fait un brevet de plus violé par Linux.

Attention à ne pas confondre la comparaison des langages avec la comparaison des plateformes.

On teste pas une plateforme comme J2EE en faisant un Hello World.

Ensuite il n'y a sûrement pas grand chose que tu ne puisse pas faire en PHP par rapport à J2EE. Donc celà ne sert pas à grand chose d'essayer de trouver un exemple.

J2EE est plus complexe que PHP, c'est un fait. Mais pourquoi ? Ils se sont amusés à compliquer J2EE pour enmerder le programmeur ? Ben non. C'est juste qu'il y a pleins de notions et de principes de fonctionnement à assimiler pour pouvoir faire de grosses applications (pas un hello world) sans avoir à tout re-concevoir, de nombreuses briques complexes mais bien utiles étant présentes en STANDARD (pooling, transactions, etc.) et surtout qui s'intègrent avec l'existant de façon élégante.

On ne code pas (j'ai pas dis on peut pas) les composant métiers en PHP, PHP n'est qu'une façade et est fortement limité aux applications Web.

Voilà, donc PHP peut être une alternative à J2EE lorsque l'application concernée est une application orientée web, qui n'a pas vraiment besoin de s'intégrer à un existant.
Les pro-PHP ne comprennent pas ce que J2EE peut faire en plus (bah vi ils en ont jamais eu besoin), alros que les pro-J2EE voient clairement les limitations qu'apporte PHP.

Après peut-être que PHP pourra plus tard prétendre concurrencer J2EE au niveau de l'intégration (grâce à Sun par exemple), mais en l'état actuel ces 2 plateformes ne sont comparables que sur une petit sous-ensemble d'application.

Voilà, c'est mon avis et je le partage avec moi-même.

Je ne sais pas ce qu'il va dire, mais je penses que celà est due au fait que l'itanium cassait la compatibilité avec une bonne partie de l'existant sous Windows. Après est-ce vraiment la faute à Windows, sachant surtout que c'est Intel qui a défini le jeu d'instruction qui les enmerde maintenant... Disons que Windows a populariser la plateforme de Intel, ce qui n'a pas dû leur déplaire, mais maintenant ils sont plus ou moins "embêter" par ce jeu d'instruction qui ressemble plus à un fardeau qu'autre chose :)

HTML ne sert qu'a structurer un document rien de plus, rien de moins
Houlà malheureux :)
HTML sert à présenter, pas structurer un document :)
Et puis dire que c'est fait pour l'impression, disons que celà n'a jamais été sa fonction première, les trucs media print ont été rajouté au HTML (même pas, au CSS) comme les liens hypertexte ont été ajoutés aux PDF, c'est pour celà que c'est fait pour :)

Bon allez hop je répond à tout le monde à la fois, apparement je me suis mal fait comprendre :)
J'ai pas dit qu'on pouvait pas faire de web services en PHP.
J'ai dis que c'était pas fait pour. Nuance.
Ce que j'entend par là c'est que dans la pratique on peut effectivement faire de la communication SOAP avec à peu près n'importe quoi, et donc implémenter entre autre le protocole des Web Services tranquillement en PHP, je n'en doute absolument pas.

Ce que je veux dire c'est qu'un web services non trivial se contente rarement de renvoyer une bête réponse à l'utilisateur, et fait parfois (souvent ?) appel à une solution qui n'a absolument aucune intérêt à être implémenté en PHP par rapport à Java ou autre. C'est en ça que je dis que les Web Services en PHP voilà quoi. On peut mais c'est pas fait pour, et c'est surtout beaucoup plus confortable sur d'autres plateformes.

"PHP a d'ores et déjà gagné ses galons en matières d'applications Web, PHP 5 devrait être l'occasion de voir PHP gagner l'univers des Web services et des middleware applicatifs pour le moment chasse gardée de Java."
(tiré de l'interview)
Y'a un gros conditionnel dans la phrase, et les Web Services sans middleware applicatifs comme il dit, ben voilà quoi.

J'espère m'être mieux fait comprendre, je me rend moi même compte que mon post n'était pas clair.

Non, c'est vrai que un parc hétérogène de terminaux ca doit être génial... J'imagine tout de suite la hotline de Free :
- "vous avez quelle version de firmware ?"
- "version 6.43.2 alpha 4 warlord-mega-boost-GPL"
-"..."

Tu veux parler de Web Services ? Tout dépend de la nature de la fonctionnalitée fournit. Mais franchement je ne vois pas du tout ce que viens faire PHP là dedans, PHP c'est pour faire du web dynamique, pas encore des Web Services.

Tu veux que je te trouves un site en PHP qui bug un peu, globalement lent, avec de belles erreurs ?
Nan sérieux me dis pas que tu juge la qualité d'une plateforme à l'utilisation qu'en fait un mauvais programmeur :)

Pour l'histoire des onglets, ben en fait faut comprendre ce qui est dispo dans .NET : tu as à ta disposition un ensemble de "widgets" prédéfinis, qui se programment exactement comme leurs équivalent dans les applications lourdes. Celà permet de concevoir très rapidement un site web avec des briques de bases, d'ailleur celà peut se dessiner de la même manière sous Visual Studio, la seule différence venant de l'interface, qui est du HTML.
Bien entendu, celui qui recherche la productivité seulement, peut se contenter de cette solution. Mais après libre au développeur de modifier les paramètres par défaut pour relooker entièrement son site. Tu retrouves le même concept dans le monde Java depuis peu, en moins abouti cependant.
Solution 2 : tu ne tient pas du tout compte de ces composants, et tu te refais une interface avec des composants de moins haut niveau, ou directement à base de HTML comme tu le ferais en PHP.
Il faut bien voir que ce n'est qu'un des aspects de ASP.NET, cet aspect ne permet pas d'avoir un contrôle total sur le code généré, les widgets prédéfinis générant automatiquement le code associé (heuresement, sinon je verrais pas l'intérêt)

Erf, j'ai pas l'impression de faire un discours marketing... Je t'ai proposé un exemple d'application multimédia, mais je peux t'en trouver 50000 exemples que tu ne peux pas faire avec PHP en l'état actuel.
Il ne suffit pas comme tu dis de faire un wrapper vers une libc, parcque tu oublies que PHP se veut portable, et là c'est beaucoup plus délicat : il faut vraiment que tu prennes tes doigts et que tu codes, ca se fait pas en 5 minutes une plateforme de la taille de J2EE ou .NET

Effectivement, ils auraient du rajouter dans la news "concurrents *dans le domaine Web*"
Voilà voilà, mais celà n'a justement pas été précisé, et c'est ce que je regrette : certains vont croire que .NET ou J2EE ne permettent que de faire des appli web (dans le cas de .NET j'en ai même vu qui croyait que c'était uniquement pour faire des Web Services...), d'autres qui vont croire que PHP va être la solution miracle pour concurrencer les 2 autres plateformes, avec la simplicité en plus. Alors que cet atout, la simplicité, n'est valable que parcque PHP est limité à un domaine bien particulier...