avec l'excuse des emplois, on aurait encore les poiçonneurs au métro
Si tu me lis attentivement, tu constateras qu'en aucun cas je n'invoque ou ne cherche des excuses. Des excuses à propos de quoi, à quel titre ?
Les poinçonneurs du métro sont particulièrement mal choisis ; savoir-faire proche de zéro, utilité purement économique, tant que le progrès technique n'avait pas fait mieux. Pour les employés de l'édition, de le même manière que ceux, disparus, de l'imprimerie dont j'ai dit pourquoi, particulièrement pour les correcteurs, on peut les regretter, la perte est celle d'emplois intellectuels utiles à une certaine forme de production.
Ce que je crains ce n'est pas la perte d'un métier mais celle de certaines connaissances intellectuelles.
Par ailleurs on a pu voir le gag (est-ce un gag ?) de la disparition de 1984 pour certains clients d'Amazon.
Pour le livre classique, la perte du support équivaut à la perte du contenu. On a fait un progrès : désormais, on peut conserver le support et perdre le contenu.
Question d'habitude : tu peux faire exactement la même chose avec un lecteur d'ebook.
Avec les supports classiques, je ne cherche rien à faire quand je mémorise. C'est un résultat que j'obtiens à mon insu, sans le rechercher. Je ne suis pas sûr du tout d'obtenir le même résultat avec un livre électronique. La mémoire dont je parlais est étroitement liée à la manipulation physique de l'objet livre. Autant il est possible de se repérer spatialement sur les propriétés gauche et droite et en haut et en bas des pages, autant le repérage en début et en fin de livre risque de sauter.
Je ne parlerai pas par crainte d'être partial de la notion physique d'être en fin de livre (est-ce que je veille un peu pour le finir ?) parce que le nombre de pages qui restent à lire se voit bien. Il est possible de trouver des succédanés.
J'oubliais. Je suis intoxiqué jusqu'à la moelle par la lecture et par les livres. Il est normal que je craigne que le livre électronique soit une pauvre contrepartie au vrai livre.
Ce qui me surprend, c'est le conservatisme par rapport à la technologie
Je ne suis pas un conservateur. Pour la musique enregistrée, ça fait longtemps que j'ai converti en FLAC mes CD. Pour acheter directement du FLAC ou équivalent libre, j'attends qu'on m'en propose. En l'espèce le conservatisme n'est pas de mon côté. Je ne porte plus de chandails en laine d'animal, mais en polaire, tant qu'il y a du pétrole. J'attends des FAI qu'ils respectent la neutralité d'Internet, qu'on puisse faire de la téléphonie, et plus, sur IP. De ce côté-là aussi, ce n'est pas de mon bord que le progrès est bloqué.
C'est pourquoi quand les marchands veulent me faire croire qu'ils sont plus progressistes que moi je me méfie... Dans le livre électronique, le principal progrès qu'ils attendent sont peut-être bien les DRM...
Ceci dit, si un jour il n'y a plus que ça, je lirai mes livres sur un support électronique. C'est d'ailleurs un support qui se prête assez bien à certains types d'ouvrages, au contenu particulièrement labile, tels que les manuels de logiciels, toujours en évolution, ou les mémoires des vedettes du moment.
Il y a plusieurs sortes de rééditions. L'acte d'éditer, que ce soit des livres nouveaux, des rééditions de livres épuisés ou des livres tombés dans le domaine public est avant tout une entreprise intellectuelle avec des emplois, salariés ou non, de ce type. On garde une population de personnes compétentes dans ce domaine, qui embrasse tous les autres, architecture, littérature, sciences, etc. Le fait même que le moyen de production peut être qualifié d'archaïque par certains permet de voir encore des aventures de petits éditeurs qui échappent, pour un temps parfois, à la concentration éditoriale.
Rééditer, c'est aussi créer des notes sur le texte, choisir des illustrations, expliquer des tournures anciennes. Je lis en ce moment une rééditions du Ventre de Paris d'Émile Zola, et je suis étonné par la teneur des notes en bas de page, qui expliquent des expressions ou des tournures de phrases que je connais la plupart du temps. Oui mais voilà j'ai cinquante-deux ans et, renseignement pris auprès d'eux, souvent mes enfants ne les connaissent pas. Ces notes augmentent la lisibilité du texte par des lecteurs d'aujourd'hui. L'édition est autre chose que de la copie bit à bit.
Une chose n'a pas été évoquée : le processus de mémorisation. Quand dans un texte quelque chose me frappe, ou m'intéresse particulièrement, je suis souvent capable des années après l'avoir lu de me remémorer le livre, parfois la revue où ça se trouve, l'emplacement dans le livre, vers le début ou vers la fin pour ne pas parler du milieu, si c'est sur le page de gauche ou de droite et, sur cette page, si c'est vers le haut ou vers le bas. Renseignement pris auprès d'un échantillon représentatif de plusieurs personnes de mon entourage et de mes amis, je ne suis pas le seul dans ce cas. Par contre j'ai beaucoup de mal à mémoriser les informations que j'acquiers par écran interposé, qui se mélangent souvent dans ma tête comme une bouillie où je ne distingue plus les sites de provenance et les auteurs.
Pour en revenir, en dernier, sur le maintien d'une population intellectuelle compétente, il faut se rappeler ce qui est déjà arrivé au livre avec l'apparition de la photocomposition et la disparition des ouvriers du livres, parmi lesquels les imprimeurs et, surtout, les correcteurs. Ces derniers formaient une authentique aristocratie ouvrière qui en faisaient les gardiens, parmi d'autres, de la langue française. Ils pouvaient téléphoner à un membre de l'Académie française pour lui demander si tel détail d'un de ses livres en éditions était un effet de style ou tout bonnement une faute d'orthographe ou, pire, de français. À comparer avec les multiples erreurs de ce genre qui émaillent désormais une certaine production éditoriale de notre époque. Ceci est bien expliqué dans un livre ou un article de Cavanna ; pour me contredire je ne sais plus où...
Ça fait trois fois au moins que tu racontes la même ânerie, sur le ton docte de l'expert : le langage C n'est pas une machine virtuelle, on peut plutôt le considérer comme un assembleur portable.
Sauf qu'en SmartEiffel (c'est là que ça a été inventé) et en Lisaac, tes contrats sont hérités.
Les contrats sont dans la spécification initiale du langage Eiffel (à une époque où il n'y avait encore aucune implémentation). SmartEiffel est une implémentation particulière de ce langage. De plus en plus particulière...
Oui, et au train où vont les choses, je ne serais pas étonné que Lisaac soit bientôt plus utilisé que SmartEiffel... Avec la version 2, tout le monde a fui. Il y a même un programmeur SmartEiffel 1.1 que je soupçonne de pulsions homicides contre le team depuis que toute la compatibilité entre les versions a été jetée aux orties. Il avait fait un gros projet qui, je crois, était une interface graphique de programmation pour le langage Ruby. Mais c'est une autre histoire...
Bien sûr que non. Avec un langage qui propose des assertions par contrat on peut éviter la plupart de ces call sur null.
Chez Eiffel Software, qui propose un compilateur Eiffel, donc avec la programmation par contrat (qu'on utilise en produisant des assertions), ils ont dû trouver, mais ils ne doivent pas avoir ton niveau, que celle-ci ne permet pas totalement d'éviter les void calls. C'est pourquoi, avec la dernière mouture du compilateur/environnement de développement, il y a un mécanisme spécifique pour résoudre le problème avant la compilation.
Alors, oui, éviter les void calls avant l'exécution, ça vaut le coup. Merci à l'équipe de Lisaac pour ça. Et non, le recours aux contrats et autres assertions ne peut pas les éviter totalement. C'est le totalement qui est important.
Incidemment, mettre les noms de classes et de types en majuscules ne me dérange pas, c'est déjà ce que je fais :) Je sais, je suis minoritaire...
Lisaac est donc maintenant compatible 16, 32, 64 bits et non plus seulement 32 bits.
Je ne vois dans cette phrase rien qui revendique un quelconque caractère révolutionnaire ou avant-gardiste. Nulle part il n'est demandé au lecteur de s'extasier devant la caractéristique annoncée. C'est tout bonnement de l'information, il n'y a pas de quoi péter un câble, ou le trollomètre.
désolé, on va pas s'extasier sur le support 16 ou 64 bits
C'est que tu ne vois pas l'intérêt de pouvoir utiliser un langage de haut niveau qui permet de faire de la programmation système, proche du matériel, et qui permet d'adresser des cibles en 16, 32 et 64 bits. Si tu n'en as pas besoin, on ne t'en veut pas, c'est juste que ce n'est pas ton problème.
Ceux qui font de la programmation pour l'embarqué peuvent être autrement intéressés.
Dans une de mes machines, des trous sont disposés en quinconce, je regroupe les cotes en x et en y. Ce n'est pas follement indispensable mais ça me plaît et je trouve que ça améliore la lisibilité en condensant un peu le code là où il a peu d'intérêt algorithmique en regroupant des termes de même nature.
dx1 := -600; dx2 := -124; dx3 := 352
dy1 := 1025; dy2 := 1300; dy3 := 1575; dy4 := 1850
-- dz := 0
puis par la suite :
create Result.make_from_array
(« create {POSITION_ROBOT}.make (dx1, dy1, dz),
create {POSITION_ROBOT}.make (dx2, dy2, dz),
create {POSITION_ROBOT}.make (dx3, dy3, dz),
create {POSITION_ROBOT}.make (dx1, dy3, dz),
create {POSITION_ROBOT}.make (dx2, dy4, dz) »)
ou
aller_xy_absolu (x, y: INTEGER) is
do
x_consigne := x; y_consigne := y
[...]
end
Voilà, c'est du sucre syntaxique, pas de quoi verser le sang, mais je trouverais dommage d'avoir à s'en passer par je ne sais quel intaigrisme.
Dans le même genre, les points virgules sont autorisées en fin de ligne mais sont inutiles. Pourquoi les autoriser dans ce cas ? Je n'ai pas le droit de mettre un point d'interrogation à la fin de ma ligne, pourtant, on pourrait l'ignorer de la même manière.
C'est pratique de les autoriser, cela permet par exemple de grouper plusieurs instructions sur la même ligne aux fins d'améliorer la lisibilité.
As-tu pensé à des entrées et sorties déportées genre Wago ? Tu en as des purement passives et d'autres ayant un comportement autonome programmable. Il y en a même qui sont livrées avec un système d'exploitation RT-Linux.
Pour celles qui sont passives (série 750-3xx) l'USB n'est pas disponible directement mais tout le reste est OK (Ethernet, RS232, RS485, Profibus, Can, etc.). Avec un module de tête RS232 (de tête 750-312 ou750-316) si tu utilises un convertisseur USB/série ça correspond à ta description. Attention, c'est du matériel professionnel, donc assez cher. Il faudra aussi te trouver ou te faire un soft exploitant le protocole Modbus sous Linux, mais ça ne doit pas être la mer à boire, vu que les specs sont publiques.
Ce n'est pas moribond, c'est marginal. Je m'en sers pour mon boulot mais ne comptez pas sur moi pour en faire un plat, une fois que tout le monde aura admis l'aveuglante évidence que c'est le meilleur langage du monde.
Sinon, question compilateur c'est vrai qu'il n'y a pas foule, mais il n'y a tout de même pas que EiffelStudio de Eiffel Software, il y a aussi GEC (Gobo Eiffel Compiler), pas assez avancé pour être utilisé en production et tecomp, The Eiffel Compiler qui est à la fois un compilateur et un interpréteur et qui n'en est pas encore à la version 1.0.
Euh tu connais beaucoup de bibliothèques modernes ou langages modernes qui utilise des codes d'erreur ?
Ben oui au moins Eiffel que je connais un peu. La Bibliothèque GOBO propose dans KL_EXCEPTION une catégorisation des exceptions. Elle permet aussi d'engendrer ses propres exceptions, pour décider que tel événement se produisant dans tel contexte est anormal et doit lever une exception.
C'est du Eiffel, pas du C ou du C#. Mets-toi dans le cas ou openFile viole un contrat et lève une exception.
Cette manière de gérer les exceptions se trouve dans Object Oriented Software Construction de Bertrand Meyer (première et seconde édition) qui, il est vrai, ne sait pas bien faire les API.
Un exemple concret en Eiffel. Quand j'ouvre des fichiers qui sont censés exister, dans le cas où justement ils existent, il arrive que le système d'exploitation échoue à les ouvrir. Ma procédure d'ouverture est munie d'une clause de sauvetage qui permet plusieurs tentatives avant d'abandonner ou de retenter la chose différemment.
J'ai des clauses de ce genre aussi pour la gestion des dll externes à mes programmes et en général pour la gestion des résultats dont la fourniture est externe à mes programmes.
[^] # Re: Bof
Posté par Philip Marlowe . En réponse au journal [HS] l'hyperlivre ou l'hypermoyen d'organiser l'hyperconsumérisme des hyperpigeons. Évalué à 3.
Si tu me lis attentivement, tu constateras qu'en aucun cas je n'invoque ou ne cherche des excuses. Des excuses à propos de quoi, à quel titre ?
Les poinçonneurs du métro sont particulièrement mal choisis ; savoir-faire proche de zéro, utilité purement économique, tant que le progrès technique n'avait pas fait mieux. Pour les employés de l'édition, de le même manière que ceux, disparus, de l'imprimerie dont j'ai dit pourquoi, particulièrement pour les correcteurs, on peut les regretter, la perte est celle d'emplois intellectuels utiles à une certaine forme de production.
Ce que je crains ce n'est pas la perte d'un métier mais celle de certaines connaissances intellectuelles.
Par ailleurs on a pu voir le gag (est-ce un gag ?) de la disparition de 1984 pour certains clients d'Amazon.
Pour le livre classique, la perte du support équivaut à la perte du contenu. On a fait un progrès : désormais, on peut conserver le support et perdre le contenu.
Question d'habitude : tu peux faire exactement la même chose avec un lecteur d'ebook.
Avec les supports classiques, je ne cherche rien à faire quand je mémorise. C'est un résultat que j'obtiens à mon insu, sans le rechercher. Je ne suis pas sûr du tout d'obtenir le même résultat avec un livre électronique. La mémoire dont je parlais est étroitement liée à la manipulation physique de l'objet livre. Autant il est possible de se repérer spatialement sur les propriétés gauche et droite et en haut et en bas des pages, autant le repérage en début et en fin de livre risque de sauter.
Je ne parlerai pas par crainte d'être partial de la notion physique d'être en fin de livre (est-ce que je veille un peu pour le finir ?) parce que le nombre de pages qui restent à lire se voit bien. Il est possible de trouver des succédanés.
J'oubliais. Je suis intoxiqué jusqu'à la moelle par la lecture et par les livres. Il est normal que je craigne que le livre électronique soit une pauvre contrepartie au vrai livre.
Ce qui me surprend, c'est le conservatisme par rapport à la technologie
Je ne suis pas un conservateur. Pour la musique enregistrée, ça fait longtemps que j'ai converti en FLAC mes CD. Pour acheter directement du FLAC ou équivalent libre, j'attends qu'on m'en propose. En l'espèce le conservatisme n'est pas de mon côté. Je ne porte plus de chandails en laine d'animal, mais en polaire, tant qu'il y a du pétrole. J'attends des FAI qu'ils respectent la neutralité d'Internet, qu'on puisse faire de la téléphonie, et plus, sur IP. De ce côté-là aussi, ce n'est pas de mon bord que le progrès est bloqué.
C'est pourquoi quand les marchands veulent me faire croire qu'ils sont plus progressistes que moi je me méfie... Dans le livre électronique, le principal progrès qu'ils attendent sont peut-être bien les DRM...
Ceci dit, si un jour il n'y a plus que ça, je lirai mes livres sur un support électronique. C'est d'ailleurs un support qui se prête assez bien à certains types d'ouvrages, au contenu particulièrement labile, tels que les manuels de logiciels, toujours en évolution, ou les mémoires des vedettes du moment.
[^] # Re: Bof
Posté par Philip Marlowe . En réponse au journal [HS] l'hyperlivre ou l'hypermoyen d'organiser l'hyperconsumérisme des hyperpigeons. Évalué à 1.
[^] # Re: Bof
Posté par Philip Marlowe . En réponse au journal [HS] l'hyperlivre ou l'hypermoyen d'organiser l'hyperconsumérisme des hyperpigeons. Évalué à 1.
[^] # Re: Bof
Posté par Philip Marlowe . En réponse au journal [HS] l'hyperlivre ou l'hypermoyen d'organiser l'hyperconsumérisme des hyperpigeons. Évalué à 3.
Rééditer, c'est aussi créer des notes sur le texte, choisir des illustrations, expliquer des tournures anciennes. Je lis en ce moment une rééditions du Ventre de Paris d'Émile Zola, et je suis étonné par la teneur des notes en bas de page, qui expliquent des expressions ou des tournures de phrases que je connais la plupart du temps. Oui mais voilà j'ai cinquante-deux ans et, renseignement pris auprès d'eux, souvent mes enfants ne les connaissent pas. Ces notes augmentent la lisibilité du texte par des lecteurs d'aujourd'hui. L'édition est autre chose que de la copie bit à bit.
Une chose n'a pas été évoquée : le processus de mémorisation. Quand dans un texte quelque chose me frappe, ou m'intéresse particulièrement, je suis souvent capable des années après l'avoir lu de me remémorer le livre, parfois la revue où ça se trouve, l'emplacement dans le livre, vers le début ou vers la fin pour ne pas parler du milieu, si c'est sur le page de gauche ou de droite et, sur cette page, si c'est vers le haut ou vers le bas. Renseignement pris auprès d'un échantillon représentatif de plusieurs personnes de mon entourage et de mes amis, je ne suis pas le seul dans ce cas. Par contre j'ai beaucoup de mal à mémoriser les informations que j'acquiers par écran interposé, qui se mélangent souvent dans ma tête comme une bouillie où je ne distingue plus les sites de provenance et les auteurs.
Pour en revenir, en dernier, sur le maintien d'une population intellectuelle compétente, il faut se rappeler ce qui est déjà arrivé au livre avec l'apparition de la photocomposition et la disparition des ouvriers du livres, parmi lesquels les imprimeurs et, surtout, les correcteurs. Ces derniers formaient une authentique aristocratie ouvrière qui en faisaient les gardiens, parmi d'autres, de la langue française. Ils pouvaient téléphoner à un membre de l'Académie française pour lui demander si tel détail d'un de ses livres en éditions était un effet de style ou tout bonnement une faute d'orthographe ou, pire, de français. À comparer avec les multiples erreurs de ce genre qui émaillent désormais une certaine production éditoriale de notre époque. Ceci est bien expliqué dans un livre ou un article de Cavanna ; pour me contredire je ne sais plus où...
[^] # Re: il me manque les extensions ki-vont-bien
Posté par Philip Marlowe . En réponse au sondage Chromium / Google Chrome sous Linux. Évalué à 3.
# le coin du feignant
Posté par Philip Marlowe . En réponse au journal Crème anglaise.. Évalué à 2.
http://www.marmiton.org/Recettes/Recette_creme-anglaise-au-m(...)
http://www.marmiton.org/Recettes/Recette_creme-anglaise-au-m(...)
Ça fait un moment que je n'en ai pas fait, mais j'obtenais de bons résultats. Je verse plutôt dans le Tiramisu ces temps-ci.
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Les contrats sont dans la spécification initiale du langage Eiffel (à une époque où il n'y avait encore aucune implémentation). SmartEiffel est une implémentation particulière de ce langage. De plus en plus particulière...
# Bravo !
Posté par Philip Marlowe . En réponse au journal Greg Egan: Océanique. Évalué à 9.
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Chez Eiffel Software, qui propose un compilateur Eiffel, donc avec la programmation par contrat (qu'on utilise en produisant des assertions), ils ont dû trouver, mais ils ne doivent pas avoir ton niveau, que celle-ci ne permet pas totalement d'éviter les void calls. C'est pourquoi, avec la dernière mouture du compilateur/environnement de développement, il y a un mécanisme spécifique pour résoudre le problème avant la compilation.
Un peu de lecture :
http://qconlondon.com/london-2009/presentation/Null+Referenc(...)
http://www.ddj.com/architect/219500827?cid=RSSfeed_DDJ_All
Alors, oui, éviter les void calls avant l'exécution, ça vaut le coup. Merci à l'équipe de Lisaac pour ça. Et non, le recours aux contrats et autres assertions ne peut pas les éviter totalement. C'est le totalement qui est important.
Incidemment, mettre les noms de classes et de types en majuscules ne me dérange pas, c'est déjà ce que je fais :) Je sais, je suis minoritaire...
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Je ne vois dans cette phrase rien qui revendique un quelconque caractère révolutionnaire ou avant-gardiste. Nulle part il n'est demandé au lecteur de s'extasier devant la caractéristique annoncée. C'est tout bonnement de l'information, il n'y a pas de quoi péter un câble, ou le trollomètre.
[^] # Re: Surprise
Posté par Philip Marlowe . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
C'est que tu ne vois pas l'intérêt de pouvoir utiliser un langage de haut niveau qui permet de faire de la programmation système, proche du matériel, et qui permet d'adresser des cibles en 16, 32 et 64 bits. Si tu n'en as pas besoin, on ne t'en veut pas, c'est juste que ce n'est pas ton problème.
Ceux qui font de la programmation pour l'embarqué peuvent être autrement intéressés.
[^] # Re: Première remarques
Posté par Philip Marlowe . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 2.
dx1 := -600; dx2 := -124; dx3 := 352
dy1 := 1025; dy2 := 1300; dy3 := 1575; dy4 := 1850
-- dz := 0
puis par la suite :
create Result.make_from_array
(« create {POSITION_ROBOT}.make (dx1, dy1, dz),
create {POSITION_ROBOT}.make (dx2, dy2, dz),
create {POSITION_ROBOT}.make (dx3, dy3, dz),
create {POSITION_ROBOT}.make (dx1, dy3, dz),
create {POSITION_ROBOT}.make (dx2, dy4, dz) »)
ou
aller_xy_absolu (x, y: INTEGER) is
do
x_consigne := x; y_consigne := y
[...]
end
Voilà, c'est du sucre syntaxique, pas de quoi verser le sang, mais je trouverais dommage d'avoir à s'en passer par je ne sais quel intaigrisme.
[^] # Re: Première remarques
Posté par Philip Marlowe . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 1.
Dans le même genre, les points virgules sont autorisées en fin de ligne mais sont inutiles. Pourquoi les autoriser dans ce cas ? Je n'ai pas le droit de mettre un point d'interrogation à la fin de ma ligne, pourtant, on pourrait l'ignorer de la même manière.C'est pratique de les autoriser, cela permet par exemple de grouper plusieurs instructions sur la même ligne aux fins d'améliorer la lisibilité.
# E/S déportées ?
Posté par Philip Marlowe . En réponse au message Piloter une carte E/S par USB. Évalué à 1.
Pour celles qui sont passives (série 750-3xx) l'USB n'est pas disponible directement mais tout le reste est OK (Ethernet, RS232, RS485, Profibus, Can, etc.). Avec un module de tête RS232 (de tête 750-312 ou750-316) si tu utilises un convertisseur USB/série ça correspond à ta description. Attention, c'est du matériel professionnel, donc assez cher. Il faudra aussi te trouver ou te faire un soft exploitant le protocole Modbus sous Linux, mais ça ne doit pas être la mer à boire, vu que les specs sont publiques.
http://www.wagocatalog.com/okv3/index.asp?lid=3&cid=13&a(...)
Ce genre de matériel est proposé par plein d'autres fournisseurs, comme Phoenix Contact, par exemple.
[^] # Re: Le langage aussi?
Posté par Philip Marlowe . En réponse au journal SmartEiffel RIP. Évalué à 3.
Sinon, question compilateur c'est vrai qu'il n'y a pas foule, mais il n'y a tout de même pas que EiffelStudio de Eiffel Software, il y a aussi GEC (Gobo Eiffel Compiler), pas assez avancé pour être utilisé en production et tecomp, The Eiffel Compiler qui est à la fois un compilateur et un interpréteur et qui n'en est pas encore à la version 1.0.
[^] # Re: Programme fidélité
Posté par Philip Marlowe . En réponse à la dépêche Journées Rencontres du Libre les 15 & 16 mai 2009 à l'Université du Sud Toulon et du Var. Évalué à 1.
[^] # Re: Investissement
Posté par Philip Marlowe . En réponse au journal Clavier Bepo Typematrix : on va y arriver !. Évalué à 1.
[^] # Re: pas possible ?
Posté par Philip Marlowe . En réponse au journal Contrats et exceptions. Évalué à 1.
[^] # Re: pas possible ?
Posté par Philip Marlowe . En réponse au journal Contrats et exceptions. Évalué à 1.
Ben oui au moins Eiffel que je connais un peu. La Bibliothèque GOBO propose dans KL_EXCEPTION une catégorisation des exceptions. Elle permet aussi d'engendrer ses propres exceptions, pour décider que tel événement se produisant dans tel contexte est anormal et doit lever une exception.
[^] # Re: pas possible ?
Posté par Philip Marlowe . En réponse au journal Contrats et exceptions. Évalué à 1.
Cette manière de gérer les exceptions se trouve dans Object Oriented Software Construction de Bertrand Meyer (première et seconde édition) qui, il est vrai, ne sait pas bien faire les API.
[^] # Re: pas possible ?
Posté par Philip Marlowe . En réponse au journal Contrats et exceptions. Évalué à 2.
J'ai des clauses de ce genre aussi pour la gestion des dll externes à mes programmes et en général pour la gestion des résultats dont la fourniture est externe à mes programmes.