En fait, on perds le côté fonctionnel de scheme pour une programmation plus impérative (boucles, itérateurs, etc.).
Les macros ne sont plus hygiéniques, ce qui permet quelques bidouilles (liées elles aussi aux effets de bord) et fait perdre la sûreté des macros (on ne peut plus utiliser une macro dans n'importe quel contexte, l'environnement lexical peut interférer avec elle).
Alors, quel est l'avantage de Arc sur Scheme ? Un peu de sucre syntaxique ? Moi je ne suis pas convaincu du tout du tout
ps : à lire : la vision de l'auteur de l'objet et de l'héritage, et pourquoi Arx n'intègre pas ses notions : http://paulgraham.com/noop.html
Je connais très bien scheme, et j'ai parcouru un peu le tutorial. Pour l'instant les seules différences notables que j'ai vu sont syntaxiques :
(set! x 12) => (= x 12)
(set-car! '(1 2) 11) => (= (car '(1 2)) 11)
(let ((x 1) (y 2)) (cons 1 2)) => (with (x 1 y 2) (cons x y))
Ca commence mal ! En scheme le symbole "!" est utilisé pour représenter l'affectation, l'effet de bord, le mal pour celui qui aime les langages fonctionnels, le compromis pour celui qui aime l'efficacité. Une convention veut que toute fonction qui utilise effet de bord se termine pas un point d'exclamation, c'est facile à voir
Utiliser "=" pour l'affectation fait déjà perdre cette convention tellement utile.
En bref, quels sont les principales différences avec scheme, quels sont les avantages de arc par rapport à scheme, quels sont les inconvénients ?
Vous avez raison de mettre l'accent sur les données, puisque dans un grand projet SIG, elles représentent environ 80% du budget. Et l'IGN les vends tres cher...
La France est un des seuls pays d'europe où il y a un monopole d'état. Il n'y a pas de place pour de la concurence, et l'IGN peut fixer ses prix sans risques.
Certaines directives européennes vont sans doute changer la donne... si la France les respecte !
Les algorithmes génétiques sont surtout du succes aupres des gens qui pensent que copier la nature aboutira forcément à une réussite, puisque la nature est tellement belle. Dans le même genre il y a les réseaux de neurones.
En fait, ce sont des programmes dit heuristiques, c'est à dire qu'ils étudient beaucoup de solutions au problemes, et gardent la meilleure qu'ils ont trouvée. Les différence entre les algorithmes heuristiques sont surtout issues de la façon de generer les soutions étudiées.
Dans un algorithme génétiques, on a plein de solutions, on en prends deux et on en fait une troisieme, qui hérite du "patrimoine génétique" des deux précédentes... et on ne garde que les meilleures, à la darwin.
Comme il l'a été dit plus haut, les heuristiques sont nécéssaires pour trouver des solutions à peu pres correctes aux problemes NP-complets, pour lesquels il n'est pas possible de trouver la solution optimale en un temps raisonnable.
Maintenant l'algorithme génétique n'apporte pas grand chose aux autres méthodes plus "traditionnelles" et généralement issues de la programmation mathématique ou de l'intelligence artificielle orienté mathématique, comme les algorithmes min-max, la méthode du gradient...
La pluspart des émulateurs sont portés sous linux... Prends la version pour arcade (mame), supernes ou toute autre console avec une version acceptable (je déconseille la version amstrad cpc par exemple !!)
Attention, les émulateurs sont généralement libres, mais jamais les ROMS. Pour rester dans la legalité, il faut acheter une cartouche de bubble bobble pour 1 euro dans une brocante, et alors tu pourra jouer en toute légalité à bubble bobble sous linux.
Patcher la méthode < de la classe Integer, c'est rigolo, mais ça risque quand même de faire planter tout le reste du code, y compris le code des classes smalltalk existantes.
Par contre, il y avait un truc que j'aimais bien faire : patcher la méthode d'affichage graphique des caracteres pour les afficher à l'envers (comme dans un miroir). A peine la méthode validée, toute l'interface graphique de smalltalk, du gestionnaire de classes au débogueur, était affichée à l'envers.
C'est un peu simplique comme exemple... Le choix des classes et des objets est un gros travail, et ce n'est pas parce qu'on manipule des cassés et des rectangles qu'on doit forcément avoir une classe Carre et une classe Rectngle.
C'est un peu comme si vous disiez, comment faire une base de données sur les animaux d'un parc naturel sans héritage multiple, alors que certains animaux sont à la fois damifferes et des invertebrés...
Smalltalk est completement objet. Tout ce qu'on pouvait manipuler aves Smalltalk était indirectement instance d'une sous classe de Object : les entiers, les classes, les métaclasses, les booléens (true et false sont les deux instances uniques de la classe Boolean), l'objet vide, nul (instance de la class Null)...
Je ne connais pas de langage qui soit autant "objet" que smalltalk, à part peut-être certaines implémentations en lisp à l'interêt principalement éducatif.
Smalltalk est un tres, tres beau langage avec lequel j'ai pu m'amuser en entreprise il y a quelques années. Cela fait bien longtemps que je ne l'ai pas vu tourner. Je ne sais même pas s'il est encore mis à jour.
Les problemes de smalltalk étaient les suivants :
- Les concepts de l'interface graphique (MVC - Modele vue contrôleur) étaient tres puissants mais difficiles à apprehender
- Le systeme de classe étais un peu complexes pour un débutant. Chaque classe créée par le développeur donnait lieu à la création se sa méta-classe. La classe Collection était instance de la metaclass "class Collection". La classe Object Class étais sous-classe de la classe Metaclass, elle-même indirectement sous-classe de Object (comme toutes les classes de smalltalk). Comme vous voyez ce n'est pas simple...
- La machine virtuelle prenait beaucoup de mémoire. Elle incluait un environnement de développement, un débogeur et ln compilateur, tout tres tres bien faits mais gourmands...
- Le typage statique est inexistant ou presque. Ce n'est qu'à l'execution que la machine virtuelle peut détecter qu'une methode appellée n'existe pas. Pour couronner le tout, il est possible de faire de la meta-programmation, et d'appeller une méthode par son nom. Il n'est alors même plus possible en regardant le code de savoir quelle est le nom de la méthode appellée...
Le compilateur, comme tout l'environnement de développement, étais écrit en Smalltalk. Il produisait du code-ocyet (bytecode) interpreté par une machine virtuelle, coeur de l'architecture smalltalk. Les methodes primitives étaient les seules méthodes ne contenant pas de code smalltalk, et faisaient directement appel à la machine virtuelle. Par exemple, la méthode + de la classe Integer, ou les méthodes de bas niveau ayant trait à l'interface graphique.
Le concept de fermeture si cher à Lisp existait dans smalltalk. Ainsi le bloc [:x :y | (x>y) itTrue: [x] ifFalse: [y]] prends en entrée deux nombres et en renvoie le plus grand. Notez la méthode ifTrue:ifFalse, implementée dans la classe Boolean, qui prends deux blocs sans arguments en entrée et execute l'un ou l'autre selon la valeur de l'objet courant (self). Notez aussi que ce type de code est totalement générique : tant que la classe dont l'objet x est instance implémente la méthode >, accepte y comme argument, et renvoie un booléen, le code fonctionnera.
Les apples de méthodes étaient evidemment tous résolus dynamiquement, il n'étais pas question comme en c++ de devoir déclarer qu'une méthode était virtuelle. Toutes les méthodes étaient virtuelles sans exception. Les méthodes de type static étaient implémentées comme des méthodes standard dans la métaclasse. Par exemple, la méthode new de la classe "class Table" renvoyait une instance de la classe "Table", non sans lui avoir envoyé le message init (i.e. appellée la méthode init sur cet objet).
[^] # Re: Différences notables avec scheme ?
Posté par celastus . En réponse à la dépêche Le langage Arc, issu de Common Lisp et Scheme, a un mois. Évalué à 3.
Les macros ne sont plus hygiéniques, ce qui permet quelques bidouilles (liées elles aussi aux effets de bord) et fait perdre la sûreté des macros (on ne peut plus utiliser une macro dans n'importe quel contexte, l'environnement lexical peut interférer avec elle).
Alors, quel est l'avantage de Arc sur Scheme ? Un peu de sucre syntaxique ? Moi je ne suis pas convaincu du tout du tout
ps : à lire : la vision de l'auteur de l'objet et de l'héritage, et pourquoi Arx n'intègre pas ses notions : http://paulgraham.com/noop.html
# Différences notables avec scheme ?
Posté par celastus . En réponse à la dépêche Le langage Arc, issu de Common Lisp et Scheme, a un mois. Évalué à 7.
(set! x 12) => (= x 12)
(set-car! '(1 2) 11) => (= (car '(1 2)) 11)
(let ((x 1) (y 2)) (cons 1 2)) => (with (x 1 y 2) (cons x y))
Ca commence mal ! En scheme le symbole "!" est utilisé pour représenter l'affectation, l'effet de bord, le mal pour celui qui aime les langages fonctionnels, le compromis pour celui qui aime l'efficacité. Une convention veut que toute fonction qui utilise effet de bord se termine pas un point d'exclamation, c'est facile à voir
Utiliser "=" pour l'affectation fait déjà perdre cette convention tellement utile.
En bref, quels sont les principales différences avec scheme, quels sont les avantages de arc par rapport à scheme, quels sont les inconvénients ?
[^] # Re: je dirais meme mieux...
Posté par celastus . En réponse à la dépêche La FSF donne $60,000 pour la libération de Ryzom. Évalué à 6.
Un sot portant un seau va à la mairie pour récupérer le sceau du maire.
En sortant, l'étroit sot tombe
[^] # Re: Quand est-ce que l'IGN comprendra ?
Posté par celastus . En réponse à la dépêche Publication d'une nouvelle version de GRASS. Évalué à 1.
La France est un des seuls pays d'europe où il y a un monopole d'état. Il n'y a pas de place pour de la concurence, et l'IGN peut fixer ses prix sans risques.
Certaines directives européennes vont sans doute changer la donne... si la France les respecte !
[^] # Re: questions...
Posté par celastus . En réponse au message elections sur internet. Évalué à 1.
Par une liste de noms et d'adresses postales
> Quel est le mode de recensement des utilisateurs?
C'est un sous-ensemble des employés d'une entreprise
> Comment les utilisateurs sont-ils définis actuellement?
Des regles de gestion claires permettent de définir, à partir du fichier des employés de l'entreprise, qui est électeur et qui ne l'est pas
# algo génétique
Posté par celastus . En réponse à la dépêche Améliorer les performances du noyau avec un algorithme génétique. Évalué à 4.
En fait, ce sont des programmes dit heuristiques, c'est à dire qu'ils étudient beaucoup de solutions au problemes, et gardent la meilleure qu'ils ont trouvée. Les différence entre les algorithmes heuristiques sont surtout issues de la façon de generer les soutions étudiées.
Dans un algorithme génétiques, on a plein de solutions, on en prends deux et on en fait une troisieme, qui hérite du "patrimoine génétique" des deux précédentes... et on ne garde que les meilleures, à la darwin.
Comme il l'a été dit plus haut, les heuristiques sont nécéssaires pour trouver des solutions à peu pres correctes aux problemes NP-complets, pour lesquels il n'est pas possible de trouver la solution optimale en un temps raisonnable.
Maintenant l'algorithme génétique n'apporte pas grand chose aux autres méthodes plus "traditionnelles" et généralement issues de la programmation mathématique ou de l'intelligence artificielle orienté mathématique, comme les algorithmes min-max, la méthode du gradient...
[^] # Re: moi aussi
Posté par celastus . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 1.
[^] # Re: Upload ou download?
Posté par celastus . En réponse à la dépêche p2p: premières résiliations d'abonnements. Évalué à 1.
D'une maniere générale, ce n'est pas judicieux de frimer avec sa collec de divx de super films récents...
[^] # Re: Bravo...
Posté par celastus . En réponse à la dépêche Slune 1.0. Évalué à 1.
Attention, les émulateurs sont généralement libres, mais jamais les ROMS. Pour rester dans la legalité, il faut acheter une cartouche de bubble bobble pour 1 euro dans une brocante, et alors tu pourra jouer en toute légalité à bubble bobble sous linux.
[^] # Re: révolutionnaire !
Posté par celastus . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 1.
Par contre, il y avait un truc que j'aimais bien faire : patcher la méthode d'affichage graphique des caracteres pour les afficher à l'envers (comme dans un miroir). A peine la méthode validée, toute l'interface graphique de smalltalk, du gestionnaire de classes au débogueur, était affichée à l'envers.
[^] # Re: sortez couvert de certitudes, ca evite d'attraper la maladie du dout
Posté par celastus . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
C'est un peu comme si vous disiez, comment faire une base de données sur les animaux d'un parc naturel sans héritage multiple, alors que certains animaux sont à la fois damifferes et des invertebrés...
[^] # Re: révolutionnaire !
Posté par celastus . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 9.
Je ne connais pas de langage qui soit autant "objet" que smalltalk, à part peut-être certaines implémentations en lisp à l'interêt principalement éducatif.
Smalltalk est un tres, tres beau langage avec lequel j'ai pu m'amuser en entreprise il y a quelques années. Cela fait bien longtemps que je ne l'ai pas vu tourner. Je ne sais même pas s'il est encore mis à jour.
Les problemes de smalltalk étaient les suivants :
- Les concepts de l'interface graphique (MVC - Modele vue contrôleur) étaient tres puissants mais difficiles à apprehender
- Le systeme de classe étais un peu complexes pour un débutant. Chaque classe créée par le développeur donnait lieu à la création se sa méta-classe. La classe Collection était instance de la metaclass "class Collection". La classe Object Class étais sous-classe de la classe Metaclass, elle-même indirectement sous-classe de Object (comme toutes les classes de smalltalk). Comme vous voyez ce n'est pas simple...
- La machine virtuelle prenait beaucoup de mémoire. Elle incluait un environnement de développement, un débogeur et ln compilateur, tout tres tres bien faits mais gourmands...
- Le typage statique est inexistant ou presque. Ce n'est qu'à l'execution que la machine virtuelle peut détecter qu'une methode appellée n'existe pas. Pour couronner le tout, il est possible de faire de la meta-programmation, et d'appeller une méthode par son nom. Il n'est alors même plus possible en regardant le code de savoir quelle est le nom de la méthode appellée...
Le compilateur, comme tout l'environnement de développement, étais écrit en Smalltalk. Il produisait du code-ocyet (bytecode) interpreté par une machine virtuelle, coeur de l'architecture smalltalk. Les methodes primitives étaient les seules méthodes ne contenant pas de code smalltalk, et faisaient directement appel à la machine virtuelle. Par exemple, la méthode + de la classe Integer, ou les méthodes de bas niveau ayant trait à l'interface graphique.
Le concept de fermeture si cher à Lisp existait dans smalltalk. Ainsi le bloc [:x :y | (x>y) itTrue: [x] ifFalse: [y]] prends en entrée deux nombres et en renvoie le plus grand. Notez la méthode ifTrue:ifFalse, implementée dans la classe Boolean, qui prends deux blocs sans arguments en entrée et execute l'un ou l'autre selon la valeur de l'objet courant (self). Notez aussi que ce type de code est totalement générique : tant que la classe dont l'objet x est instance implémente la méthode >, accepte y comme argument, et renvoie un booléen, le code fonctionnera.
Les apples de méthodes étaient evidemment tous résolus dynamiquement, il n'étais pas question comme en c++ de devoir déclarer qu'une méthode était virtuelle. Toutes les méthodes étaient virtuelles sans exception. Les méthodes de type static étaient implémentées comme des méthodes standard dans la métaclasse. Par exemple, la méthode new de la classe "class Table" renvoyait une instance de la classe "Table", non sans lui avoir envoyé le message init (i.e. appellée la méthode init sur cet objet).
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par celastus . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 4.