aide





[ Précédent :: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 :: Suivant ]

Re: Ruby On Rails

Posté par Miguel Moquillon (page perso, ) le 22/06/2005 à 13:10. (lien). Évalué à 2.

Je ne vais pas répondre point par point à l'ensemble de ton post long.
Je crois que je ne me suis pas fait bien comprendre.

Dire que quand une variable référence un valeur d'un certain type n'implique pas que le langage est fortement typé.
De même, d'une variable qui référence une valeur d'un certain type, puis plus loin d'un autre type n'implique pas non plus que ton langage soit faiblement typé.
Si jamais ton langage te permet, par exemple, d'additionner un entier avec une chaîne de caractères (ton exemple) qui sont donc de deux types complétement différents, alors ton langage supporte le typage faible. Dans un typage fort, on ne peut utiliser une opération sur un type autre que celui attendu et il ne peut avoir de coercition mathématiquement incorrect. Par contre, le fait d'additionner un entier avec un réel ne posent pas de pb parce que l'un est sous-type de l'autre (on ne va pas entrer dans les détails du sous-typage), et dans ce cas on a souvent un transtypage implicite et qui est mathématiquement correcte.
Bien sûr cette condition n'est pas suffisante en elle même pour dire qu'un langage est typé fort.
Après, l'usage implicite ou explicite de coercition affaiblit la force du typage de ton langage ; c'est pour ça que l'on dit que tel langage à un typage plus fort qui tel autre, les deux étant de typage fort.

A côté de ceci, C est un langage à typage statique faible.

Le typage fort ou faible n'est pas une question de cuisine selon les points de vues. Des théories mathématiques ont déjà été élaborées pour décrire le typage (Hoar, Liskov, Cardelli pour ne citer que les plus connus).

[ Répondre ]

Re: Ruby On Rails

Posté par Miguel Moquillon (page perso, ) le 21/06/2005 à 12:30. (lien). Évalué à 3.

PHP est un langage à typage faible (certains disent qu'il n'est pas typé même). Autrement dit, ta variable n'est pas d'un type bien définie.
Quand tu écris $a = "3 maisons" on lui a assigné une valeur de type chaîne de caractères. Mais lorsque tu fais $a + 1, si ta variable était de type fort, alors une erreur aurait été levée parce que l'on ne peut pas additionner une chaîne avec un entier. Au lieu de cela, le runtime a considéré juste la variable $a comme un entier et a donc appliqué un transtypage horrible (horrible car même le transtypage dans ce cas aurait dû aboutir à une erreur) ; c'est la raison aussi pour laquelle PHP est considéré comme non typé.
Si par contre, on avait $a = $a + 1 => "3 maisons1" alors on aurait pu dire qu'effectivement $a pourrait être de typage fort avec un transtypage implicite correcte qui est de convertir l'entier 1 en sa représentation chaîne de caractères avant de la passer à l'opération de concaténation '+' (si '+' est l'opérateur de concaténation bien sûr)

[ Répondre ]

Re: Ruby On Rails

Posté par Miguel Moquillon (page perso, ) le 21/06/2005 à 11:20. (lien). Évalué à 3.

C'est une définition érronée. Il a mélangé typage fort avec statique.
En gros (avec des imprécisions) :
- le typage statique : le type des données sont connues à la compilation et sont stipulés par le codeur.
- le typage dynamique : le type des données ne sont connues qu'à l'exécution.
- typage fort : une donnée est d'un type et d'un seul bien définie.
- typage faible : une donnée n'est pas de type bien définie.

[ Répondre ]

Re: Pourquoi Lisaac ?

Posté par Miguel Moquillon (page perso, ) le 21/06/2005 à 09:12. (lien). Évalué à 2.

Effectivement, l'aspect compilation/VM m'avait échapée :)

Sinon, les langages objet à VM ne sont pas tous peu performant. En fait, il n'y en a qu'un dont les perfs sont lamentables : Java.
Ceci est dû en partie à une différence de conception mais aussi d'approche. Dans Java, la VM est juste une machine à exécuter une application. Dans Smalltalk ou slate par exemple, la VM est plus un conteneur à objets ; en fait c'est bien une véritable machine dédiée à la gestion du cycle de vie des objets (c'est donc un véritable environnement d'exécution objet).

A part ceci, effectivement je n'ai pas très bien évalué les possibilités de Lisaac. Je me suis juste amusé un peu comme ça. Il y a un petit truc qui me dérange dedans, c'est son orientation "structure des objets". Avec io ou slate, le dév est orienté plus sur les objets eux-mêmes en tant que tel que sur leur structuration sous forme de prototype ; c'est une approche plus "dynamique" (ce que sont les objets, des entités avant tout dynamique).

[ Répondre ]

Re: Ruby On Rails

Posté par Miguel Moquillon (page perso, ) le 20/06/2005 à 19:42. (lien). Évalué à 1.

JSF jusqu'à présent ne supporte pas MVC. Si on veut faire du MVC avec, on doit se le palucher à la main. JSF reste pour l'instant, grosso modo, une technologie qui permet de standardiser dans J2EE la gestion, de façon flexible, de l'aspect présentation. Il n'apporte aucun contrôleur et n'implémente pas de gestion de contrôle entre Vue et Modèle via le Contrôleur.

[ Répondre ]

Pourquoi Lisaac ?

Posté par Miguel Moquillon (page perso, ) le 20/06/2005 à 19:28. (lien). Évalué à 4.

Bonjour,

Juste une question : pourquoi Lisaac comme langage objet à prototypes. Il existe des langages à prototypes bcp plus avancés que Lisaac actuellement : io et slate pour ne citer que ces deux là par exemple.

[ Répondre ]

Re: Ruby On Rails

Posté par Miguel Moquillon (page perso, ) le 20/06/2005 à 11:47. (lien). Évalué à 1.

Tu veux sûrement parlé de langages à typage statique. Bien que Ruby soit de typage dynamique, il supporte, comme Smalltalk, un typage fort.

[ Répondre ]

Re: Ruby On Rails

Posté par Miguel Moquillon (page perso, ) le 20/06/2005 à 11:42. (lien). Évalué à 2.

Surtoût qu'ils ne sont pas destinés à la même chose.
- Struts est un framework MVC sur lequel peuvent se gréffer des technos différentes pour les aspects Vue et Modèle. La partie Contrôleur est fournie par Struts, mais il fournit aussi ses propres technos côté Modèle et surtoût Vue pour les développeurs qui ne veulent pas s'embêter.
- JSF est une techno de gestion de Vues.

Ce qui fait que l'on peut utiliser JSF avec Struts car ils sont complémentaires et non opposés.

[ Répondre ]

Moi aussi !

Posté par Miguel Moquillon (page perso, ) le 03/06/2005 à 19:39. (lien). Évalué à 2.

Salut,

Après lecture de ton journal, je me suis aussi penché sur mes log d'authentification. Et j'ai les même traces !

Pour mon serveur SSH, j'ai juste activé la connexion par clé publique (les clés des serveurs distants doivent être listés parmi ceux autorisés) + par user/challenge (pas par mot de passe).
Le root n'est pas non plus autorisé à se connecter par ssh.

Bien que cela devrait suffire, j'ai toutefois quelques inquiétudes.
La dernière tentative d'attaque date du 1er juin.

[ Répondre ]

Brevets

Posté par Miguel Moquillon (page perso, ) le 02/06/2005 à 13:21. (lien). Évalué à 9.

N'oublions pas tout de même que Microsoft a déposé des brevets sur les procédés de lecture et d'écriture d'un document au format XML selon la grammaire MS Office.

Donc, même si Microsoft ouvre les spécifications des différentes grammaires XML de sa suite MS Office, toute tentative de lecture d'un document XML MS Office ou toute écriture d'un document sous ce dernier format tombe sous la portée de ses brevets. Il peut ainsi donc soit interdire juridiquement ces procédés, soit demandé de bon royalities; autrement dit par ces moyens mettre de côté les logiciels libres.

De plus, je ne vois peu d'entrerprises ou communautés avec des reins assez solides pour trainer Microsoft dans de longues et difficiles procés pour invalider ses brevets.

[ Répondre ]

Re: il est où le vote des journaux ???

Posté par Miguel Moquillon (page perso, ) le 26/05/2005 à 19:11. (lien). Évalué à 10.

C'est une question d'équilibre. Le compromis tends vers un équilibre bas, tandis que le concensus tend vers un équilibre haut.
Or, comme par hasard, la démocratie s'appuie sur un concensus (et pas sur une majorité comme bcp trop de monde croit), raison pour laquelle, entre autre, la démocratie peut paraitre difficile à appliquer.

A cette phrase toute faite, je pourrais aussi donner celle là :
"A ne pas être assez ambitieux, on rate trop d'occasions pour réellement avancer".

Evidemment, comme la tienne, même s'il y a un fond de vérité, elle ne signifie finalement pas grands choses.

[ Répondre ]

Re: Les conséquences du non ?

Posté par Miguel Moquillon (page perso, ) le 27/04/2005 à 13:18. (lien). Évalué à 2.


L'intérêt du conseil n'est pas de plomber ses relations avec le parlement.

A mon opinion, fondé sur le contenu du TCE relatif aux institutions, l'intérêt du Conseil des Ministres et de faire accepter les lois et lois cadres qui répondent à la stratégie du Conseil Européen. Si ceci doit passer par un conflit avec le Parlement, je pense qu'ils n'hésiteront pas. Maintenant, bien sûr, il est possible qu'il y est peu de choses avec lesquelles ces deux institutions risquent d'entrer réellement en conflit.


Sur le papier on peut le dire. Dans la pratique c'est beaucoup moins évident. Ça doit donner un petit avantage au Conseil. Mais dans les cas où les désaccords sont profonds, je ne vois pas le conseil jouer à ce "petit jeu".

Pourtant, c'est bien à ce petit jeu que joue le Conseil des Ministres avec la directive sur les brevets logiciels. Si, et je l'espère, le Parlement Européen arrive à nouveau à bien amender la directive, nous serons alors en mesure de mieux apprécier la procédure de co-décision et l'influence (sous les traités actuels) du Conseil des Ministres. Ceci permettra alors de mieux percevoir son pouvoir une fois le TCE appliquée (étant donné que son pouvoir est renforcé par le TCE).

[ Répondre ]

Re: Les conséquences du non ?

Posté par Miguel Moquillon (page perso, ) le 26/04/2005 à 20:36. (lien). Évalué à 2.

Je voudrais juste te dire qu'il n'y a pas lieu de comparer les institutions françaises avec celles de la futur Union Européenne. Pas plus que les institutions françaises que celle de l'UE sont démocratiques. Les institutions françaises sont avant tout républicaines. Donc, s'appuyer sur ces dernières pour montrer que celles européennes sont "mieux" est un peu tiré par les cheveux. De plus, l'UE n'est pas un Etat mais une confédération d'états (le terme confédération est certe malheureux puisque l'UE ne sera pas réellement une confédération même si le TCE laisse des portes ouvertes).

[ Répondre ]

Re: Les conséquences du non ?

Posté par Miguel Moquillon (page perso, ) le 26/04/2005 à 20:30. (lien). Évalué à 3.

Non, c'est malheureusement vrai.
D'abord, directive européenne est un terme des traité actuels. Avec le TCE, on parle de lois et lois-cadre.
Ensuite :
- Qualifié la procédure de codécision entre le Parlement et le Conseil des Ministres de contre pouvoir est, AMHA, tiré par les cheveux. Je parlerai ici plutot d'"encadrement" des décisions avec cette procédure de codécision.

- le Parlement Européen vote le président de la Commission sur présentation du Conseil Européen, n'oublions pas cela. De plus, c'est le Conseil Européen avec consultation (ils parlent d'un commun accord) du président de la Commission qui décide de la composition de ladite Commission (sic). (Article I-27)

- Ensuite, le Parlement ne pourra demander des comptes à la Commission que par une motion de censure ... sur sa gestion (ce qui est le cas sous les traités actuels). Par contre, au travers de la sous-section 4 de la section I du Titre IV, Chapitre I de la partie III (les articles III-347 à III-352), relatives à la Commission Européenne, nous voyons bien que c'est le Conseil des Ministres qui est doté d'un véritable contrôle sur la Commission. Ce qui fait que dans certains cas (ceux où le Parlement et le Conseil ne s'accordent pas et que des intérêts du Conseil priment), la procédure de co-décision est plus ou moins biaisée (ceci est mon opinion).

- l'article III-396 parle bien de la procédure de co-décision.

[ Répondre ]

Re: Les conséquences du non ?

Posté par Miguel Moquillon (page perso, ) le 26/04/2005 à 20:07. (lien). Évalué à 3.


Tu es donc pour une concurrence faussée, que l'Europe favorise plutot l'entreprise de tel pays par rapport à celle d'un autre? ...

Je voudrais juste remettre les choses à leur place ici.
Dire "je ne suis pas pour une concurrence libre et non faussée" ne signifie pas pour autant être pour une concurrence faussée au sens où des entreprises sont plus favorisés que d'autre par l'action, par exemple, de l'Etat.
Le discours "concurrence libre et non faussée" est une théorie économique libérale qui a été elle même battue en brêche par des libéraux ! Actuellement, ce sont surtout plus des idéologues libéraux (très présents dans les milieux politiques) que de véritables économistes qui pronent ce genre de discours.
Ce qui vient plus à l'opposé, du point de vue science économique (un bien grand mot ça), de la concurrence, c'est la coopération. La croissance endogène (une autre théorie économique) reprend le concept de coopération.

Sinon, pour apporter de l'eau au moulin, ce sont principalement les articles III-161 et III-162 qui définissent le contour de la "concurrence libre et non faussé" : les entreprises ne doivent pas se rapprocher pour fausser la concurrence et sont interdits toute entreprise en position de dominance et qui, par celle-ci, fausse la concurrence ou la libre circulation des biens et services. Toutefois, avec le paragraphe 3 de l'article III-161, la coopération entre entreprises est autorisée. Néanmoins, celle-ci reste sous contrôle de réglements adoptés par le Conseil des Ministres seul (pas de codécision avec le Parlement Européen ici) et évidemment proposés par la Commission Européenne (article III-163). Autrement dit, tout ça reste sous le regard vigilent à la fois du Conseil des Ministres et de la Commission.

[ Répondre ]

Re: mon avis.

Posté par Miguel Moquillon (page perso, ) le 25/04/2005 à 13:38. (lien). Évalué à 6.


L'informatique a évoluée et de nouveaux besoins sont apparus, les principaux étant la sécurité et la productivité, ...

Le langage C n'était qu'une illustration au premier point, sur les performances. Pour l'époque il répondait bien aux besoins.
Maintenant, bien sûr, il y a d'autres considérations à prendre, n'empêche que l'excuse à deux balles de faire des gros lourdaux parce que les machines dans 10 ans seront plus performantes me laissent plutot froid ... ou en colère.


Là encore l'informatique a évolué : le système de communication inter-programme d'Unix est complètement dépassé ...

Je parlais du concept : les outils qui rendent chacun 1 et 1 seul service et par la combinaison du tout on accomplissait des tâches plus complexes. Le système de communication inter-processus d'Unix répondait de façon pertinente à celui-ci et ceci était aussi une illustration dans mes propos. Mais comme tu le dis, les besoins évoluent. Or, les solutions eux n'ont pas évolués ou alors sans répondre à ce concept d'Unix.


Le système de fichier devient ainsi un espace hiérarchique de nommage d'objets de nature diverse.
Ce principe était surtout nécessaire dans le cadre de l'environnement pré-cité visant à faire communiquer les programmes. Mais là encore l'absence totale d'information sur la nature et la structuration des infos limite clairement l'utilité de simples flux binaires référencés par des fichiers.

Le système de fichier comme un espace de nommage d'objets n'est pas seulement utile pour les programmes, mais aussi pour l'utilisateur qui intéragit avec l'information. L'objet peut très être considéré comme une information ou un composé d'information. Or, c'est ce dernier que souhaite, AMHA, manipuler l'utilisateur et non telle ou telle appli. Le pb actuel est que le concept de filesystem-centric (donc j'ai donné ici aussi une illustration avec l'espace de nommage) n'est malheureusement plus apréhendé dans la conception des outils actuels. Voir même, par rapport à ce concept, on ne s'attache plus à faire évoluer de façon cohérente les systèmes de systèmes de fichiers pour répondre aux nouvelles attentes des utilisateurs.


La philosophie d'Unix n'était destinée qu'aux informaticiens, et si tu veux uniquement tenir compte de la philo alors oui, Unix est mort, ceux qui survivent sont ceux qui ont su évoluer et s'ouvrir à d'autres utilisateurs (MacOSX, Linux, etc.). Qui s'en plaindra ?

Je ne suis pas d'accord avec toi. La philosophie d'Unix était destiné avant tout à la conception d'un système qui réponde aux attentes avancées de ses utilisateurs, qu'ils soient informaticien ou simple secrétaire. Le pb est que si à l'origine ce système a répondu aux exigences de ses utilisateurs (d'où son rapide succès), les différentes sociétés qur Unix n'ont pas prises en compte ses précéptes. Et aujourd'hui il en est de même de la communauté libre.
Unix, ce n'est pas seulement un noyau. C'est plus que cela. Et je crois bien que cela fait depuis un certain temps qu'Unix est à l'agonie.
Mais personne s'en plaindra parce que très peu savent ce qu'est Unix et on continuera à s'agacer avec des systèmes bancales, lourdaux, qui simulent des réponses à tes attentes quand ils ne te convainquent pas que tes attentes c'est truc et pas machin.

[ Répondre ]

Re: 2 cts

Posté par Miguel Moquillon (page perso, ) le 25/04/2005 à 13:16. (lien). Évalué à 2.

Je ne savais qu'il pouvait faire ça. Merci pour le tuyau :)

[ Répondre ]

Re: annuaire vs. moteur

Posté par Miguel Moquillon (page perso, ) le 25/04/2005 à 13:12. (lien). Évalué à 3.

Le pb vient que l'on ne dispose pas des outils adéquats et qui font correctement le boulot et jusqu'au bout, le tout de façon transparente pour l'utilisateur.

[ Répondre ]

Re: mouai

Posté par Miguel Moquillon (page perso, ) le 25/04/2005 à 13:05. (lien). Évalué à 3.

Tu classes tes documents en fonction d'une hiérarchie de répertoires, mais pas uniquement. Et ceci de la même façon que tu créés des catégories pour classer l'information que tu manipules. S'il s'avère complexe, c'est avant tout par ton fait, et tu aurais la même complexité avec d'autres techniques. Après, c'est une question de point de vue sur ton information (voir Plan 9 par exemple qui résout ce pb de façon élégante). Et non ça ne prend pas trop de temps de créer tes répertoires (catégories) et d'y classer tes docs si tu disposes des outils adéquat (c'est là où le bas blesse, j'en convient, car cela fait belle lurette que nous avons perdu l'aspect filesystem-centric dans nos applications quotidiennes).

Sinon, effectivement, les besoins évoluent. Mais les bases sous Unix (filesystem-centric) existent et permettent, AHMA, efficacement d'implémenter des solutions répondant à ces besoins. Le pb est que ces bases ne sont même pas prises en comptes. Au lieu de les faire évoluer, les améliorer, on préfère implémenter des idées venant du monde MS Windows ou MacOS qui sont avant tout application-centric.

Bien sûr, tout n'est pas noir non plus et il y a des tentatives. Par exemple, le système de fichier ReiserFS 4 qui permet d'ajouter des méta données relatives à un fichier ou groupe de fichiers.

En fait, parce que tout est fichier, tu peux très bien imaginer un fichier de fichiers, ces derniers étant des groupes d'information, et qui permettent de référencer d'autres fichiers ... dans d'autres fichiers ou dans le même fichier composé ! Je pense qu'à ce niveau là (mais peut être que je me trompe) nous sommes limité que par notre perception (qui est tiré de nos connaissances actuelles et de nos habitudes) et par notre imagination.

[ Répondre ]

Re: Unix, que sont devenus tes concepts ?

Posté par Miguel Moquillon (page perso, ) le 25/04/2005 à 12:49. (lien). Évalué à 2.

Tout à fait. Plan 9 est au jour d'aujourd'hui le système qui a poussé le plus loin le concept de filesystem-centric. Ce qui est dommage, c'est qu'il soit arrêté d'être développé et qu'aucun autre Unix tente de récupérer ses bonnes idées. J'ai l'impréssion déasagréable que l'on préfère reprendre les idées de MS Windows ou MacOS :(

[ Répondre ]

[ Précédent :: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 :: Suivant ]