outs a écrit 297 commentaires

A mon avis voila ce qu'il va se passer dans le futur :

*VisualEiffel va mourrir
*SmartEiffel va diverger completement (ils ont déclaré qu'ils ne suivront pas le standard ECMA). Donc cela ne sera plus de l'eiffel mais du smarteiffel.
*EiffelStudio va intégrer le compilateur Gobo pour faire des compilations optimisé non incrémentale (eiffelstudio n'est pas très fort sur ce point mais est incrémentale). Les deux projets visent a implémenter ECMA.

Mes deux cents et rien de plus.

Bon je me répond à moi même.

Je confirme qu'avec la version libre d'EiffelStudio on peut a la fois faire du propriétaire et du libre.

cf : http://blog.daniel-baumann.ch/2006/04/05#20060406_eiffelstud(...)

Donc la mention sur le site officiel est incorrecte. vu que les bibliothèques standard sont dans une license style BSD.

L'Eiffel ne gère pas les "namespace" et ce point là est très génant si on veut avoir une grosse bibliothèque "a la CPAN".[...]Il parait que Benoit Sonntag n'est pas chaud pour rajouter cette fonctionalité dans Lisaac.

Ouais mais en fait les namespaces ne font que repousser le problème des conflits de nom dans les namespace. Si par exemple en C++ je veux utiliser le namespace std, je peux pas. C'est juste qu'il y a moins de problème car il y a moins de namespace différent dans le monde que de nom de classe.

Eiffel possède aussi un mécanisme pour gérer les conflits de nom mais ce n'est pas dans le fichier source mais dans le fichier "make" d''eiffel. A cet endroit on peut résoudre les conflit de nom de classe et même renommer des classes c'est plus sympa je trouve. J'ai réfléchit un peu a ca et finalement je trouve que les problème de conflits de nom c'est plus un problème des gestion de projet que de programmation donc c'est normal de régler ça dans les fichiers "a la make". A priori Lisaac utilisera le même système

Mais bon la on est clairement plus du tout dans le sujet (a savoir les ide, pas savoir si en machin on code mieux qu'en truc).

Heu, le sujet c'est pas de partir en flameware Emacs/eclipse. Juste de donner quelques idée d'IDE possible qui pourraient être utilisé pour rajouter un plug-in pour un nouveau langage.

Enfin moi je dis ca je dis rien.

Non c'est juste qu'il faut contenter tout le monde, suffit de regarder le troll ahem la discussion un peu plus bas.

compatibilité ! que de massacres avons nous fait en ton nom ...

il faut hériter d'une classe pour pouvoir traiter les exceptions

Comme pour n'importe quelle classe utilitaire en Eiffel. oui les classe sont aussi des bibliothèques en eiffel, mais dans la nouvelle version il faut utiliser l'héritage d'implémentation plutot que l'héritage normal (ce qui est plus logique je suis d'accord).

Sinon tout dépend de ce que tu entend par exception :

-si tu veux t'en servir pour programmer comme en Java (genre récuperer une execption sur une conversion String->int pour afficher une message utilisateur) alors les exeptions en eiffe sont nullesl. L'idée de base est que les exceptions (c'est à dire des goto déguisée) détruisent la structure du programme et eiffel est protégé contre cela.

-sinon si tu veux ten servir pour gérer les erreurs. alors eiffel a le concept de conception par contrat qui généralise l'usage des exceptions.

Pourquoi pas EiffelStudio ?

syntaxe en couleur : OK
une aide contextuelle : OK
dans l'idéal la doc de la fonction qui s'affiche quand tu remplis les paramètres comme chez windev (facultatif), : JE CROIS
l'autocomplétion OK
Gestion des diagramme UML : OK
compilation a la volé : OK (enfin ca se déclenche quand on fait sauvegarder, ce que je trouve mieux que dans Eclipse d'ailleur).
En plus si l'étudiant est Nancéen il a des chance de déjà connaitre Eiffel.

par contre :
système de plugin : HEU ca n'a jamais été fait, je ne sais pas a quel point cela demanderai du travail.

Enfin j'ai quand même un gros doute, c'est surement possible mais je pense que cela nécessite un gros travail.

Emacs n'a jamais été dans le style Unix. Le style unix c'est des petite applis spécialisée qui l'on fait fonctionner ensemble.

Ca a toujours été un reproche fait a Emacs de ne pas respecter la philosophie Unix

Bha c'est juste mon opinion personnelle après avoir que l'on m'ait répondu 36-milles fois <<ouais mais moi je préfère gérer moi-même la mémoire, j'ai pas besoin q'un langage/compilo le fasse pour moi. Je veux pouvoir tout maitriser>>

Mais je suis sur que c'est plus facile d'expliquer le succes ou l'échec des langages en utilisant seulement des argument sociaux ou commerciaux

Je me permets de remarquer que la production de logiciels libres ne souffre pas des mêmes soucis

C'est vrai c'est d'ailleur une des raison pour laquelle on est tous là.

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

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

Oui c'est *exactement* ça ...

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 suis peut être (très) désabusé mais le principal but de l'industrie logicielle n'est *pas* de faire des produits de qualité mais de gagner de l'argent en *vendant* du logiciel. Et pour cela ce n'est pas nécessaire de faire de la qualité.

Prouvez moi le contraire ca me remontera le moral ...

ah ouais tu utilise VisualEiffel ? Je serai intéressé pour en savoir plus

Ouinnn !
Mais bon sang c'est quoi un reseau WiMAX ?
je suis si nul que ca ?

J'ai bien lu tout le communiqué de presse, ca a toujours l'air génial dans ce genre de papier ...

Mais concretement c'est quoi ? j'ai pas compris ...

Ben si ca ce trouve s'en était du gtk1,2, je ne sais pas ... :)
Je suis pas très attentif a ce genre de chose vu que de toute facon en ce moment je dois utiliser une interface un peu étrange rajoutée pardessus xemacs, alors tout me parait merveilleusement ergonomique =)

En ce qui concerne l'entreprise en question (Eiffel software une division de ISE) elle fait surtout son beurre avec des grands comptes capable de fonctionner de manière relativement indépendante du marché. Le principal but des commerciaux est d'arriver a négocier un contrat avec la direction sur l'utilisation de la technologie eiffel dans tous le département info (en gros). Par exemple chez Axa ils ont passé l'intégralité des logiciels qui étaient en Fortran et en C (sous VMS) en eiffel.

Sinon ils ont jamais été présent sur les marchées plus petit, je ne sais pas si c'est un échec. Mais j'ai l'impression qu'ils n'ont en fait jamais essayé.

Enfin c'est quand même un avantage pour eux car du coup les clients sont plutot fidéle, forcement car ISE est la seul société a proposer un service sur Eiffel... Mais je pense pas qu'ils quitteraient ISE même si ils sont plus indépendant maintenant grace a la libération du code, d'ailleurs je pense qu'ils doivent être content de leur collaboration avec ISE et de l'utilisation d'Eiffel.

Par contre avec la montée des langages plus souple que C++ comme Java (même si eiffel peut être considéré comme supérieur techniquement la différence est moins grande aujourd'hui) ISE devait avoir du mal a trouver de nouveau client. Peut-être que le libre leur ouvrira d'autre marché. Ca me semble difficile quand même y'a pas de miracle, il fallait faire ca y'a 10 ans.

Bon personnelement je m'en fout, Eiffel software n'a jamais été capable de promouvoir Eiffel ailleur quand dans les marché de niches. Pourtant il y avait de quoi faire. Toujours est-il que maintenant on peu utiliser EiffelStudio comme on veut.

Voici la page web qui a servie à déclencher la mise en place de la version libre :

http://origo.inf.ethz.ch/~schoelle/

Y'a un gros bouton rouge au milieu :) (mais sans fonctionnalitée autour)

J'ai pas trouvé le support gtk d'eiffelsutdio limité, tu parle de quoi exactement ?

Par contre y'a le concept IHM de l'IDE qui est étrange, ca c'est vrai. Au lieu de cliquer sur l'icone d'un outil et d'amener le curseur sur la cible de l'outil on fait l'inverse : on clique droit sur la cible et on l'amene sur l'icone ... Enfin ca a été inventé y'a 10 ans ce truc. On va dire que ca fait partit du folkore Eiffel

Pour le reste : c'est le moins que l'on puisse dire ! :)

Il faut bien replacer la déciser de libérer dans le contexte délicat ou se trouve le monde d'eiffel depuis la scission provoqué par le standardisation EMCA qui n'en était pas une. (en gros ECMA est une nouvelle version du langage non validé plutot qu'une standardisation de ce qui ce fait). Pour le moment aucun compilateur n'implémenta la norme ECMA et a mon avis c'est pas près d'arriver. A mon avis il fallait juste rajouter les concepts intéressant comme les agent (une facon de faire du fonctionnel en objet) et l'héritage d'implémentation et garde la conpatibilité ascendante.

Le problème amha est que dans la tête des utilisateurs Eiffel c'est le langage parfait (enfin ils en ont tous une vision différentes)... du coup personne n'est pret a faire de concession pour assurer la conhérence future du langage et prefere fonctionner en autarcie. Ce qui résume quand même pas mal la situation d'eiffel.

Reste quand même qu'utiliser EiffelStudio pour remplacer un langage comme Delphi et faire une appli sympa rapidement c'est cool maintenant que c'est libre. (En attendant Lisaac que je trouve encore meilleur mais chut ... :)

Par contre c'est exactement la stratégie utilisée par VisualEiffel : la bilbiothèque standard est en GPL.

D'un autre coté VisualEiffel est clairement a la traine sur EiffelStudio pour l'environnement et sur SmartEiffel pour la qualité de code. donc on s'en fout

Tout a fait mais la bibliothèque n'est pas en GPL mais en "Eiffel forum license". Qui me semble être une BSD-like. Y'a sa description sur le site de la FSF.

Cela dit j'ai quand même eu un doute en rédigant la new car le site web est effectivement pas clair. Si quelqu'un pouvait me confirmer ? je suis pas expert en licence.

Pas facile de trouver la pertinence des dépendances, on pourrait imaginer quelques heuristiques comme
*si le lien est présent dans la définition en haut de la page alors c'est dépendant.
*si le lien est dans une section du style "Voir aussi" alors ca ne l'est pas.
*Sinon peut-être avec la place grammaticale du mot qui représente le lien dans la phraese (si il y en a une).

Enfin c'était juste une idée en l'air.

Est-ce que l'on pourrait se servir de ton logiciel pour prendre un bout de wikipedia et en faire un document linéaire ?

J'imagine que les cycles de lien doivent poser problème. De plus les liens ne doivent pas avoir assez de sémantique pour pouvoir faire une traduction dans ton format.

Mais l'idée me parait sympa. alors ?

- TA Spring : clone libre de Total Annihilation qui permet de jouer à TA ainsi qu'aux modes qui ont été développés.

Ouais ils ont finit de passer a la version multiplateforme y'a juste encore un problème : impossible de faire une partie entre un joueur Windows et un joueur Linux par cause une sombre histoire de flottant.

Sinon ca marche bien et il y a de plus en plus de monde, au alentour d'une centaine de personne connectée sur le serveur

Ben justement si on parle pas d'objet on ne peut pas voir le rapport car justement lisaac et isaac c'est de l'objet. Je ne comprend que tu ne vois pas les avantages, mais franchement je ne pense pas que l'on trouvera un jour tous les details techniques d'un projet dans les commentaires de dlfp.

J'arreterai donc cette conversation ici...

Mais t'inquiete pas quand j'aurais eu plus le temps d'apronfondir tout ca je reposterai un truc et on pourra de nouveau troller ...

De toute manière on a juste le code en C de libre pour le moment et il faudra revoir tout ca en detail quand on aura toutes les sources en lisaac.