Philip Marlowe a écrit 1184 commentaires

Pourriez-vous offrir napoleon@waterloo.eu à un certain Premier Ministre, amoureux malheureux de l'Histoire, qui n'avait pas craint d'appeler le début de son action Les Cent Jours, en oubliant comment ceux-ci s'étaient terminés ?

La rubrique de Denis Bodor, Les livres du mois omet de préciser le prix de ceux-ci, et c'est donc une information importante qui manque. A part ça, c'est une bonne rubrique dans un excellent journal.

Google est un excellent moteur de recherche qui me parait actuellement exempt de reproches.

N'exagérons rien tout de même. Voici un extrait de l'article Démocratie et notoriété sur Internet qu'a publié le mathématicien Jean-Paul Delahaye dans le numéro du mois de novembre 2005 de la revue Pour la science :

La firme Google détient un pouvoir considérable en choisissant elle-même les spécificités de ses algorithmes et il serait normal que chacun soit informé sur ses méthodes qui sont imposées dans la plus grande opacité et le plus total arbitraire aujourd'hui. Google juge chaque page, cela a parfois des conséquences graves pour les individus et les sociétés comerciales dont le succès dépend directement du Pagerank que Google leur attribue : il est donc nécessaire que soit rendue publique la méthode de classement. Chacun a le droit de savoir selon quelles lois on le juge. Même s'il est vrai que la façon la plus efficace pour avoir un bon Pagerank est simplement d'être un bon site que tout le monde souhaite référencer, la notation secrète produite par Google est en contradiction avec le génial principe d'équité totale du surfeur aléatoire.

D'après ce que j'ai compris Eric Bezault et ses acolytes veulent faire de Gobo Eiffel Compiler un compilateur en ligne de commande, au moins dans un premier temps. D'autre part la volonté de se conformer au standard ECMA (qui est un vaste programme...) n'est pas l'apanage de GEC. C'est aussi la volonté d'Eiffel Software.

Là le EiffelStudio il me fait penser aux versions d'évaluation de Visual Studio et autres softs proprio, où la licence indique clairement que "l'IDE ne peut être utilisé à des fins commerciales".

Il est clairement indiqué dans tous les cas qu'on ne se trouve pas devant une version limitée ou d'évaluation de EiffelStudio, qu'elle soit commerciale ou GPL. Je ne vois donc pas ce que l'on peut faire comme comparaison entre deux objets de nature non comparable. D'autre part, comme tu as l'air de bien connaître la GPL, tu dois savoir que l'on peut utiliser un soft sous licence GPL à des fins commerciales.

Même Visual Studio est moins restrictif : les compilo/libs permettent de coder avec la licence que l'on veut sans rien nous imposer. C'est pas pour autant qu'ils arrivent pas à vivre de leur IDE hein ;)

Par contre là tu veux opposer deux objets de nature comparable et de comportement identique s'il s'agit de EiffelStudio version commerciale : on les achète l'un et l'autre pour en faire ce que l'on veut. A moins qu'on m'ait caché une version libre de VisualStudio ?

Quand vous comprendrez que GPL n'est pas l'anti-thèse de commercial, et qu'il y a plein de variantes de la GPL, vous aurez un peu mieux compris comment fonctionne le libre et comment utiliser "correctement" la GPL (et accessoirement comment construire un modèle économique rentable dans le monde libre).

Tu devrais expliquer cela en détail à Bertrand Meyer, le créateur d'Eiffel, fondateur de Eiffel Software et initiateur de la double licence de EiffelStudio, qui ne doit pas avoir bien compris. Ce que je crois avoir compris, peut-être avec des moyens limités, c'est que Eiffel Software, dont les revenus dépendent de la vente de ses produits commerciaux, met EiffelStudio sous une licence libre qui ne peut pas être contournée pour faire du tort à la vente de la version commerciale d'EiffelStudio, même si ça empêche sa plus large propagation. Peut-être pour ne pas faire l'expérience amère de disparaître par là où ils auraient réussi...

Tu peux faire tes suggestions là : http://www.eiffel.com/

Ce que tu indiques est une bonne manière pour que des profiteurs codent sous un environnement GPL des softs sous toute licence, y-compris propriétaire. Je voudrais te faire remarquer que vouloir s'approprier et modifier EiffelStudio exige un investissement technique considérable vu son degré d'aboutissement.

<ras des paquerettes>Le margoulin que tout ce qu'il veut c'est ne pas payer l'IDE, il en a rien à branler de tout ça...</ras des paquerettes>

[...] on gueule après les sociétés qui abusent des LL en ne reversant rien à la communauté (pourtant ils respectent les licences), là on a un peu le cas opposé : on "abuse" de l'IDE pour imposer sa licence [...]

A cheval donné, on ne regarde pas la bride. Je n'ai entendu auparavant personne se plaindre qu'Eiffel Software ne donnait pas son code. Le terme abus est vraiment peu pertinent. Le code, fruit d'années d'investissement, était totalement propriétaire et closed source. Il est rendu complètement libre au sens de la GPL. On peut l'étudier, l'adapter, le modifier, le forker si l'on veut ou si c'est nécessaire mais on ne peut pas changer sa licence. Si tu veux utiliser Eiffel pour coder des soft non GPL, tu peux utiliser SmartEiffel ou VisualEiffel (limité aux processeurs x86), ou tu peux acheter une version commerciale d'EiffelStudio.

Ca ne veut pas dire que je me fais la moindre illusion sur la future world domination d'Eiffel suite à son passage à la double licence dont GPL. Mais je ne pense pas qu'une autre licence l'aurait permise, outre qu'Eiffel Software se serait tiré une balle dans le pied.

C'est ce que j'explique dans le post auquel tu réponds : si tu ne veux pas faire un soft sous GPL, tu es libre d'utiliser un autre outil, ou d'acheter le produit... Rien ne t'empêche de créer un soft, par exemple sous licence MIT prêt à être transformé en, ou intégré dans un, produit propriétaire, à partir du moment ou tu le fais avec la version propriétaire d'EiffeStudio.

Je trouve cela très sain.

Celui qui veut faire des soft libres peut utiliser l'excellent EiffelStudio en GPL pour produire des soft en GPL (mais il a la liberté de choisir parmi plein d'autres outils, y-compris à base d'Eiffel, s'il veut le faire sous une autre licence, y-compris propriétaire).

Celui qui veut produire du code propriétaire, ou du code libre sous une licence autre que GPL, peut acheter EiffelStudio version propriétaire (environ 4800 $, ouf ! mais il paraît que l'on peut négocier le prix avec Eiffel Software lorsque, par exemple, on est développeur indépendant). Mais il peut acheter un autre environnement si celui-ci ne lui plaît pas.

Ce que j'aime dans cette démarche, c'est qu'elle handicape fortement le parasitisme de ceux qui voudraient contourner les circuits commerciaux d'Eiffel Software pour produire des softs propriétaires avec la version libre de l'environnement de développement (qui est loin de se limiter à un compilateur).

Update : désormais ça marche, grâce aux paquets xfonts-xxx-transcoded. Merci de vous être intéressés à mon problème.

Bah écoutes, si tu veux mettre des concepts à la Sather dans Lisaac

Ben pas du tout. C'était juste pour dire une blague, je connais à peine Sather. Et quitte à apprendre un nouveau langage, je me mettrais plutôt à Lisaac qui me semble avoir plus d'avenir.

Merci de votre aide, farvardin, dark_star et Xion345, même si je n'ai toujours pas réussi à résoudre le problème.

Pour XMMS, il utilise, je crois, les bibliothèque GTK1 liées en statique. Par contre ce n'est pas le cas pour Scilab qui utilise libfontconfig1. J'utilise KDE comme environnement graphique, ce qui fait que mes .gtkrc sont bien vides.

Bref, je ne comprends toujours pas, mais je cherche...

de toute facon tout le monde va passer a Isaac

Moins tous ceux qui seront passés à Sather...

Je te pertinente des deux mains. Résoudre des problèmes concrets, pour lesquels avoir une solution importe, fait faire des progrès rapides dans n'importe quel langage. En milieu scolaire, le seul travail qui m'ait vraiment intéressé était un programme de dérivation formel en C. J'aime les maths. Le C aussi, mais ce n'est pas ce que je choisirais pour refaire ce genre de choses.

Merci pour ces précisions qui m'avaient échappé. Il ne manque plus qu'une option de réabonnement à l'offre de couplage, en somme.

Je viens de recevoir mon offre de réabonnement pour Linux Magazine et Linux Pratique.

L'offre couplée : 79 ¤
Linux Magazine seul : 49 ¤
Linux Pratique seul : 26 ¤

Cherchez l'erreur...

VisualStudio est un outil qui permet de travailler d'une manière efficace.

Bravo pour le lapsus !

Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel.

C'est vrai ; il ya trois compilateurs Eiffel, bientôt quatre avec Gobo, tous au moins partiellement sous des licences libres. VisualEiffel est resté à la version 2 de la spécification du langage, et n'implémente donc pas les agents. EiffelStudio et SmartEiffel implémentent, eux, les agents, mais chacun de manière différente. VisualStudio veut implémenter petit à petit les spécifications de l'ECMA, alors que l'équipe de SmartEiffel affirme que c'est la spécification d'un langage différent ; par contre SmartEiffel rend sensible à la casse l'écriture des programmes, alors que les textes Eiffel sont insensibles à la casse depuis la création du langage...

Gobo veut faire des outils et des bibliothèques compatibles avec tous les compilateurs en activité. Comme VisualEiffel en fait partie et n'a pas les agents, les bibliothèques Gobo n'utilisent pas les agents. Si VE s'y met, il faut espérer que ce ne sera pas d'une troisième manière différente... Si l'on suit les mailing lists de Gobo, on peut voir que c'est SmartEiffel qui leur pose le plus de problèmes.

SmartEiffel a produit un compilateur incompatible depuis le 2.0 avec sa version précédente, la 1.1. Du coup, quelques un, dont Daniel Moisset ont créé une version 1.2 de SmartEiffel dont le but est d'être compatible avec le versions 1.1 et la dernière 2.x afin de faciliter la migration des programmes écrits dans la première vers la deuxième.

Mon avis est que SmartEiffel est devenu un compilateur expérimental, un laboratoire où les chercheurs de l'INRIA peuvent essayer leurs excellentes idées, mais qu'on ne peut pas considérer comme un outil de travail permettant de produire des logiciels aspirant à une certaine pérennité. VisualStudio est un outil qui permet de travailler d'une manière efficace. Désormais une version libre existe. Pourquoi ne pas s'en servir ?

Je ne suis pas non plus moi-même un spécialiste de la théorie des langages de programmation. De plus la question de la variance des arguments des routines héritées est ce que je maîtrise le plus mal. Il n'empêche que je suis les mailing lists Eiffel et que la question des catcalls, qui sont les produits de ces problèmes de variance y ont été abondamment abordés. Il me semble que SmartEiffel autant qu'EiffelStudio sont sécurisés à ce point de vue.

Si tu lis le papier de Castagna que je t'ai indiqué, tu verras que la question de la covariance et de la contravariance ne sont pas des notions opposées mais qu'elles recouvrent des objectifs de nature sémantiquement différentes.

Par ailleurs je ne promeus pas ici Eiffel comme un langage expérimental, mais comme un outil disponible aujourd'hui pour produire des logiciels, avec ses défauts. Comme tu le dis, on peut bien aussi utiliser C++... Le vrai défaut d'Eiffel, comme cela a été pertinemment évoqué ici, c'est sa relative pauvreté en bibliothèques et en frameworks.

Ca fait plusieurs fois que tu professes l'opinion selon laquelle la contravariance serait meilleure (ça veut dire quoi, meilleure ?) que la covariance des arguments des routines héritées. J'avais moi-même raconté quelques âneries à ce sujet et j'avais été repris (par Julien Puydt, je crois) qui m'avait aiguillé sur un papier de Giuseppe Castagna dont le titre est covariance and contravariance: a conflict without a cause.
http://www.di.ens.fr/~castagna/pub.frame.html

Si j'ai bien compris, l'avantage de la contravariance est qu'elle ne pose jamais de problème. Son inconvénient est qu'elle prive de toutes les possibilités où la covariance serait valide. Mantenant ce sont les compilateurs Eiffel qui analysent le code pour détecter les possibles catcalls. Choisir la contravariance comme l'ont fait les créateurs de Sather semble résulter d'une analyse, sinon simpliste, du moins manquant de finesse. On se prive de possibilités, de la même manière que d'autres langages n'implémentent pas l'héritage multiple, pour ne pas compliquer l'implémentation du compilateur.

Ceci dit, il est assez fréquent que j'entende parler de Sather là où se trouvent des discussions sur Eiffel. Existe-t-il des compilateurs Sather qui permettent de produire des applications de la vie réelle ? Y en a-t-il qui de plus proposent un environnement de développement avec quelques facilités ? Et y a-t-il des applications ou des services informatiques qui utilisent Sather ? Ces questions sont sans malice, j'avoue seulement mon ignorance dans ce domaine.

Mais par contre les développeur libre adorent utiliser des techniques/langages plus difficile d'utilisation.

Pour l'enquête psycho-sociologique, je me déclare incompétent :-)

Ah mon avis Eiffel a deux principaux défaut pour l'industrie informatique. Cela tient au fait que la méthode eiffel permet d'obtenir plus rapidement un résultat de meilleur qualité. Ce qui veux dire :
1. on gagne moins d'argent en utilisant eiffel car on programme plus vite : donc il y a moins d'heure de travail a facturer.
2. on gagne moins d'argent en utilisant eiffel car on produit moins de bug : donc on ne peut pas vendre des nouvelles versions/mise à jour pour corriger les bug.

Je me permets de remarquer que la production de logiciels libres ne souffre pas des mêmes soucis. La qualité tout de suite, c'est bon à prendre.

Oui, j'ai oublié des tas de caractéristiques, je voulais faire court. Dans les qualités, j'ai oublié une chose : cela existe et c'est prêt à l'emploi. Parmi les défauts, il faut citer la relative pauvreté des bibliothèques.

Je ne vois pas pourquoi il faudrait attendre l'arrivée des langages objet à prototypes pour coder avec des outils confortables et puissants.

Je n'ai pas l'impression que l'on évalue ce passage d'EiffelStudio au libre à sa juste valeur. Je vois même des commentaires tendant à déprécier l'intérêt du langage (qui, en effet, n'est pas parfait) ou l'activité des commerciaux d'ISE qui n'a pas conduit à une domination mondiale.

D'abord, en vitesse, les principales caractéristiques, maintes fois exposées, d'Eiffel.

La programmation par contrat permet de spécifier les applications ainsi que de les documenter. En passant, la gestion des exceptions est d'une remarquable simplicité : la génération d'une exception est la violation d'une assertion. Quand j'entrevois le pastis de la gestion des exceptions en, par exemple, Java, ça ne me donne pas envie. L'héritage, multiple bien sûr, ne simplifie pas la vie de ceux qui implémentent des compilateurs Eiffel ; mais celle du reste du monde. La généricité (qui peut certes être simulée par l'héritage, surtout quand il est multiple...) évite la duplication inutile de code et concourt à sa lisibilité.

Si l'on cherche un langage ayant ces trois caractéristiques, il n'y a pas pléthore. On peut ajouter une syntaxe d'une lumineuse clarté, héritée de Simula, de Pascal et d'Ada, l'identité entre la classe et le type, associée à l'unicité de leur représentation par un fichier ainsi que les nombreuses facilités, anciennes ou plus récentes, telles que l'héritage d'implémentation.

Le principal manque de la spécification d'Eiffel concerne les concepts de concurrence et d'application répartie. En ce qui concerne la concurrence, EiffelStudio implémente les threads et permet donc le multitâche. Bertrand Meyer a proposé une conception unifiée de ces concepts sous le nom de SCOOP (Simple Concurrent Object Oriented Programming). Son implémentation offrirait une remarquable facilité d'utlisation aux programmeurs, au prix d'une terrible difficulté pour ceux qui auraient à l'implémenter dans un compilateur.

Bertrand Meyer, le géniteur d'Eiffel, occupe désormais une position académique en tant que titulaire de la chaire de Génie Logiciel à l'Ecole Polytechnique Fédérale de Zurich. Parmi les projets de ses collègues ou élèves, on trouve :

une ébauche d'implémentation de SCOOP, SCOOPLI par Volkan Arslan
http://se.inf.ethz.ch/research/scoop.html
http://eiffelzone.com/esd/scoopli/index.html

AutoTest, un outil de test automatique de code Eiffel, écrit par Andreas Leitner et Ilinca Ciupa comme project de recherche
http://se.ethz.ch/people/leitner/auto_test/

Erl-G, une bibliothèque permettant la réflexivité et l'introspection du langage écrite par Andreas Leitner.
http://se.inf.ethz.ch/people/leitner/erl_g/

Il y a plein d'autres projets concernant Eiffel sur le site de l'ETH. On peut aussi y découvrir des jeux développés par les étudiants comme sujet d'étude.

Ces derniers temps, Eiffel Software promouvait les qualités du langage en tant qu'elles facilitent les pratiques d'outsourcing et d'offshoring, propres à faire grincer les dents de beaucoup de monde, à commencer par les miennes... Cette facilité de sous-traiter le travail logiciel liée à la capacité de bien spécifier, en particulier grâce à la conception par contrats, est une chose à prendre en compte dans l'élaboration collective de logiciels libres. De plus, l'extrême lisibilité du langage, y compris par les non-spécialistes, peut permettre une communication fructueuse entre les praticiens des aspects métier et ceux de la programmation. Je pense qu'un projet métier libre, genre dont on peut espérer la prolification, tirerait grandement parti des qualités d'Eiffel dans le cadre d'un travail distribué et décentralisé, qui sont les caractéristiques fréquentes des projets libres.

Je ne vous parle pas de l'environnement de développement, faites-vous en une idée par votre propre pratique. Je risque d'oublier des délices, entre la navigation dans le code et les multiples outils et facilités qu'il offre et qui font du développement sous EiffelStudio un vrai plaisir. Jusqu'ici, je me retenais de le dire, la chose étant purement propriétaire, maintenant je peux y aller !

En gros, j'ai l'impression, purement subjective probablement, que certains d'entre vous trouvent que la mariée est trop belle.

Tu as mal lu : elles y sont déjà.