Articles précédents : Développeur
- [102] KDE veut changer de licence
- [56] CodeWorker 4.4
- [7] Copix 3.0.1
- [8] Publication d'une « Base audio libre de mots tchèques »
- [23] Première 'Release Candidate' de Gambas 2
- [18] OpenKomodo, un nouvel IDE libre
- [28] Trophées du Libre 2007 : Les finalistes annoncés
- [15] Sortie de Posteet, le réseau social de partage d'astuces et de codes
- [38] Seaside 2.8 est sorti
- [32] Les verbes irréguliers anglais enfin libres !
Liens connexes
- Ruby on Rails (787 hits)
- Architecture REST (741 hits)
- Blog de Ruby on Rails (251 hits)
- Rails 2 Upgrade Notes (236 hits)
- Summary of Major Rails 2 Features (259 hits)
- Ruby on Rails sur dmoz (579 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Sortie de Ruby on Rails 2.0
Posté par EppO (page perso, ). Modéré le 11 décembre 2007.Le développement qui a duré une année a permis l'ajout de nombreuses fonctionnalités, la résolution de beaucoup de bugs, une orientation tournée vers le REST, et pas mal d'allégements au niveau du core (externalisation de fonctionnalités en greffons).
DHH, le créateur du framework Ruby on Rails, a commenté ces nouveautés lors de Paris on Rails. Pour les absents, des slides et/ou des podcasts des présentations devraient être mis en ligne prochainement.
Ruby on Rails (787 hits)
Architecture REST (741 hits)
Blog de Ruby on Rails (251 hits)
Rails 2 Upgrade Notes (236 hits)
Summary of Major Rails 2 Features (259 hits)
Ruby on Rails sur dmoz (579 hits)
> Lire la dépêche (154 commentaires, moyenne: 2,1).
Rails a tranché dans le débat REST - SOAP au profit du REST.
Le module ActionWebservice a été sorti du core et placé en greffon pour ceux qui veulent continuer à utiliser du SOAP. ActiveResource est le nouveau module qui est similaire à ActiveRecord mais avec une approche ressource.
Au passage, l'url des ressources a été modifié, l'utilisation du point virgule ( ; ) pour séparer l'action de la ressource a été remplacé par un slash ( / ), à cause de navigateurs et bibliothèques HTTP qui ne le supportaient pas en tant que séparateur de requêtes.
Multi-vues
Rails 2.0 sépare le format du template (html, xml, atom, rss, ...) du moteur de rendu. Le template show.rhtml devient donc show.html.erb (ERB étant le moteur de rendu par défaut).
D'autres moteurs de rendus existent aussi, builder utilisé pour générer du atom+xml, et HAML principalement utilisé aujourd'hui pour générer des templates adapté à l'iPhone.
Identification des records
On avait l'habitude en version 1.2.X d'utiliser person_url ou person_path pour générer des URLs du record person, il est plus facile avec Rails 2.0 de gérer les redirections ou les liens:
# person est une instance de la classe Person,
# qui sera mappé en person_url
redirect_to(person)
link_to(person.name, person)
form_for(person)
Authentification HTTP
L'authentification basique HTTP est maintenant supportée, ce qui permet facilement de sécuriser efficacement les appels d'APIs
Javascript, CSS et images
Il est plus facile en tant que développeur de séparer ses fichiers javascripts ou CSS en plusieurs parties logiques que de maintenir un seul gros fichier. Mais cela génère du coup un surcoût au niveau HTTP car cela génère des requêtes de beaucoup de fichiers.
Il est maintenant possible de mettre en cache ses fichiers javascript et CSS en un seul fichier en production, tout en les gardant séparés pour le développement.
Pour augmenter le nombre de connexions conccurrentes, il est possible de spécifier dans les fichiers de configuration des adresses de serveurs qui hébergeront les fichiers statiques :
ActionController::Base.asset_host = “assets%d.example.com”
Sécurité
Rails 2.0 embarque un mécanisme interne pour contrer les attaques CSRF sur les formulaires et les appels AJAX.
De même pour les attaques XSS, la méthode sanitize qui utilisait une blacklist pour fonctionner, ce qui compliquait la tâche pour la mise à jour de cette liste, utilise dorénavant une whitelist qui garantira une meilleure protection.
Gestion des exceptions
En plus de pouvoir gérer les exceptions par action (par un bloc rescue), une nouvelle macro rescue_from permet de capter toutes les exceptions d'un certain type de manière globale aux controllers.
Session basée sur les cookies
Les sessions ne sont plus stockées par défaut sur le système de fichiers du serveur web mais au niveau du client sous une forme qui ne peut pas être forgée. En revanche, le contenu sera visible, donc ce mécanisme de stockage de sessions n'est pas adapté si vous avez besoin d'y stocker une information que ne doit pas voir l'utilisateur.
Profileur de requêtes
Pour détecter les points de contention de votre application, il est possible grâce à un nouveau script de générer un rapport qui détaillera tout cela (script/performance/request)
Performance
La plus grosse avancée au niveau des performances se situe au niveau du cache introduit directement dans l'ActiveRecord, ce qui permet de mettre en cache des requêtes SELECT similaires qui permettra d'éviter des requêtes inutiles sur la base de données.
Les fixtures ont été grandement améliorées, on parle de gain pouvant atteindre 100 à 200%.
Beaucoup de chose dans le core de Rails ont été externalisés en greffon (tous les acts_as_*, in_place_editor, autocomplete_for, paginate, ...), ce qui allège considérablement le core et permet de charger uniquement ce qui est nécessaire.
Migrations plus sexy
Un nouveau format, plus efficace et moins verbeux a été mis en place :
Avant
create_table :people do |t|
t.column, "account_id", :integer
t.column, "first_name", :string, :null => false
t.column, "last_name", :string, :null => false
t.column, "description", :text
t.column, "created_at", :datetime
t.column, "updated_at", :datetime
end
Après
create_table :people do |t|
t.integer :account_id
t.string :first_name, :last_name, :null => false
t.text :description
t.timestamps
end
XML en entrée, JSON pour la sortie
Il existe maintenant la désérialisation en XML et la sérialisation en JSON.
Le debuggueur de retour !
Grâce au paquet (gem) ruby-debug, il suffit de placer le mot clé debugger quelque part dans le code et de lancer le serveur avec l'option -u pour bénéficier d'un point d'arrêt directement dans le terminal exécutant le serveur, avec possibilité de retour arrière, lister les variables...
Comment installer Rails 2.0
Pour installer Rails, il est plus facile de passer par la commande gem (installateur de paquets ruby) :
gem install rails
Ca marche aussi pour la mise à jour, mais pensez bien à installer les greffons qui ont été éjectés du core et que vous utilisez !
[+] Célèbre ?
> Ruby on Rails, le célèbre framework
Je ne le connais pas, j'imagine que beaucoup beaucoup de gens ne l'a pas utilisé ni le connait.
Perl, php, python, java doivent être plus "célèbre".
NB : Je ne remet en rien en cause les mérites de Ruby (que j'ignore totalement ; oui, c'est de ma faute).
-
[^]Re: Célèbre ?
Posté par Slainer (Jabber id, page perso, ) le 11/12/2007 à 20:41. (lien). Évalué à 6.Hello !
Bon, encore un qui mélange Framework et langage !
Perl c'est un langage, PHP un langage, Java un langage.
Ruby c'est un langage et Rails un framework Web 2 basé sur Ruby.
Et pour ta non connaissance de Rails, sûrement tu n'es pas développeur ou alors tu t'intéresses pas aux actualités... Mais je te confirme : oui, Rails est - devenu en quelques années - le plus célèbre des frameworks Web, bien loin devant ceux en PHP par exemple. Recherche le nombre de livres traitant de Rails sur amazon.com tu verras (doit bien y avoir quelques dizaines).
Ayant essayé de nombreux frameworks Web, Ruby on Rails est celui qui m'a le plus branché, et celui que je conseille à tous les développeurs Web. Ruby est très facile à appréhender, très lisible, et les automatismes de Rails font qu'il est possible de se lancer dans le développement d'un site Web avec un potentiel "fun" énorme.
Rails ne serait jamais devenu incontournable sans son énorme communauté de passionnés qui ont développé des centaines de plugins et d'améliorations...
Pour parler de Rails 2 il s'agit moins d'une révolution, mais d'une très belle évolution et maturation. Le coeur du projet a bien été nettoyé des fonctions non essentielles qui ont été éclatées sous forme de plugins optionnels.-
[^]Re: Célèbre ?
Posté par EppO (page perso, ) le 11/12/2007 à 20:55. (lien). Évalué à 3.Il n'a effectivement pas la même réputation aux Etats-Unis qu'en France, malheureusement, mais ca vient doucement :)
Pour les modules du core qui ont été replacés en plugins, j'ai oublié de mentionner les connecteurs de bases de données: tous les connecteurs de bases de données autre que MysSQL, PosgreSQL ou sqlite ont été mis en plugin (ce qui facilite l'ajout de nouveaux connecteurs car il est plus facile de proposer un plugin qu'un patch sur le core de rails)
-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 11/12/2007 à 20:58. (lien). Évalué à 3.Ouais enfin RoR ca n'as que 3 ans, et la premiere version stable n'a que 2 ans, donc bon meme si c'est déja pas mal en informatique, c'est quand meme tres tres court et je peux comprendre qu'on ne sois pas au courant.
C'est surement un tres bon framework pour le web, mais je l'ai connu apres avoir entendu parler d'autre framework pour PHP (vu que c'est le language que je pratique).
Mais effectivement Rails est précurseur pour beaucoup de choses et est une sorte de réference.
Pour ce qui est de son incontournabilité, je serais beaucoup plus mitigé ! Déja il faut vouloir faire du Ruby. Il font donc se taper la syntaxe du ruby, a laquelle perso je n'accroche mais alors pour pas un sous, il faut aussi ensuite trouvé un hebergeur qui accepte Ruby, et enfin il faut accroché au mode de fonctionnement de Rails.
Donc pour se lancer dans un projet web je prefere largement resté sur un PHP avec un Framework qui me plait.
Dernier point, toutes ces techno sont tres jeunes, on sort a peine la version 2 de RoR et c'est a peu pres parreil dans les autre language, les framework de ce style sont tous tres jeunes, donc a mon avis il faudrat de nombreuse années avant que ces techno prenne pied chez la majorité des developpeurs.--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par zerchauve () le 11/12/2007 à 21:09. (lien). Évalué à 5.c'est vrai que faire du Ruby c'est chiant, y a que des objets, c'est pas très verbeux, les nom des methodes sont homogènes et intuitives, y a pas de $ et d'{ ... c'est vraiment trop chiant...
sinon pour l'histoire des hebergeurs c'est à la fois pas vrai et surtout pas bien grave, Rails et Ruby ne sont pas là pour remplacer les 25 lignes de "colles" en PHP qu'il y a sur beaucoup de sites (c'est pas forcément une critique pour php hein, ca a son utilité)--
-- Le voilà qui s'en va, un des prototypes personnels de Dieu... Trop bizarre pour vivre, trop unique pour mourir-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 11/12/2007 à 21:28. (lien). Évalué à 8.Mouarf :)
Ou ai-je dit que Ruby etait chiant ?, j'ai dit que j'accorchai pas.
Pour les hebergeurs, c'est une constatation toute simple, j'ai fait le tour des differents lien que j'avais qui proposais de l'hebergement (pas forcement gratuit) et j'en ai pas trouvé qui proposais, Ruby, j'ai donc cherché, et apparement y en a quelques uns mais ca reste tres marginal, on trouve apparement bien plus d'hebergement proposant Python que d'hebergement proposant Ruby.
Alors apres y a peut etre un truc que j'ai pas capté avec Ruby, et peut etre qu'il y a pas besoin de l'installé pour s'en servir, vu que tu semble dire que c'est pas bien grave ....
Apres donne moi un truc a faire et je suis sur que mes ligne de code seront bien plus moche si je le fait en Ruby que si je le fait en PHP. On peut tres bien faire quelque choses de tres propre en PHP, et on peu je suis sur faire quelque choses d'horrible en Ruby.
C'est pas pasque le succes de PHP fait qu'une grande majorité des débutant se lance dans PHP en bidouillant sans vraiment apprendre les bases et donc font des trucs à se faire suicider Rasmus avec son string qu'on peut en tirer des conclusions sur la qualité du language !--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par zerchauve () le 11/12/2007 à 21:32. (lien). Évalué à 1.ben pour avoir pendant trop longtemps du PHP c'est quand meme super dur de faire quelque chose de joli hein....
voir les frameworks genre CakePHP qui essayent de pomper Rails (au lieu d'etre originaux) ce me fait un peu de la peine tellement c'est affreux.
Quant a Rasmus, il a des tonnes de qualités, mais franchement (comme Rick Hunter) qu'est ce qu'il y connait aux applis web hein....--
-- Le voilà qui s'en va, un des prototypes personnels de Dieu... Trop bizarre pour vivre, trop unique pour mourir-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 11/12/2007 à 21:41. (lien). Évalué à 1.Ben je sais pas comment tu te débrouille car depuis la version 5 de PHP le modele Objet est bien meilleur (et va encore progresser avec la version 6) et du coup programmer proprement n'est plus quelque choses d'innacessible, suffit de s'appliquer et de reflechir bien a son truc.
Apres pour les framework PHP je dois te dire que perso je n'es jamais utilisé de framework sur un projet réel donc je ne me prononcerai pas sur eux, parreil je ne me suis pas plongé dans le code de Rails pour tout comprendre et pouvoir comparer avec ceux fait en PHP.--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par IsNotGood () le 11/12/2007 à 22:23. (lien). Évalué à 9.> du coup programmer proprement n'est plus quelque choses d'innacessible
On peut aussi programmer proprement en C. Il n'est pas nécessaire de faire de la programmation object en utilisant toutes ses subtilités.
J'ai fait beaucoup de C, c'était propre. Je fais beaucoup de C++, c'est toujours propre. La "propreté", c'est le développeur qui la fait, la cultive. Par exemple, tu peux prendre le meilleur des languages, si tu choisis des noms de fonctions ou de variables comme une patate, ça va être moche.
M'enfin, un peu d'aide du language ne fait pas de mal.
-
[^]Re: Célèbre ?
Posté par Erwan (page perso, ) le 12/12/2007 à 06:32. (lien). Évalué à 2.Tiens, je viens de tomber sur un blog post qui illustre bien la propreté de PHP:
http://zestyping.livejournal.com/124503.html
Alors PHP, je l'utilise pour certains projets, ça a son utilité parfois, mais même quand tu programmes proprement tu peux tomber sur des aberrations qui peuvent rendent les bugs difficiles à identifier.-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 12/12/2007 à 11:17. (lien). Évalué à 0.Y a une logique derreire ca et n'importe quel livre de base en PHP l'explique.
Le transtypage de PHP est tres puissant, mais il faut savoir ce qu'il fait pour éviter les erreurs.
Le gros soucis de PHP c'est que ce n'est pas un language de débutant, mais qu'il est utilisé en tant que tel !
Je ne connais pas assez le Ruby et je ne sais pas ce que fait quelque choses du genre :
machaine = "3"
monentier = machaine
mais du coup a j'imagine qu'il doit y avoir une methode spécifique la classe entier pour recuperer la valeur entiere contenu dans un string, un peu comme en Java ?--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 12/12/2007 à 11:25. (lien). Évalué à 3.j'imagine qu'il doit y avoir une methode spécifique la classe entier pour recuperer la valeur entiere contenu dans un string
C'est le contraire: un String sait se convertir en entier ou en flottant. Un nombre (et n'importe quel objet) sait se convertir en String, etc. Les méthodes standards s'appellent to_i (integer), to_f (float), to_s (string), etc.
Cette manière de faire est un peu plus propre, car ça signifie que quand tu programmes ta classe d'objet, il suffit de leur ajouter une méthode to_i, to_s, etc. selon tes besoins. Dans l'autre manière de faire, il faudrait créer un Integer.parseIntFromToto(Toto t) pour créer un entier à partir d'un Toto. Je préfère n'avoir à modifier que ma propre classe, et pouvoir appeler toto.to_i.-
[+] [^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 12/12/2007 à 11:43. (lien). Évalué à -1.Ca veux dire qu'il faut surcharger la classe Entier si tu veux pouvoir accepter un transtypage vers un type non définie a la base dans la classe Entier ?
Je trouve la méthode Java moins chiante perso.
La vrai question est : Est ce le type de destination qui doit connaitre la méthode de transtypage, ou le type de départ.--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 12/12/2007 à 12:31. (lien). Évalué à 2.Je ne dis pas qu'il faut le faire, rien ne t'empêche de coder ta méthode de transtypage où tu veux et comme tu veux. Pour les conversions basiques, il est souvent plus logique que ce soit l'objet qui sache se convertir lui même dans un autre type.
C'est aussi une question de syntaxe. Si tu préfères faire "i = Fixnum.from_string(str)" au lieu de "i = str.to_i", pourquoi pas. Après, ça va produire des cas étranges. Par exemple si ton string contient un nombre très grand, au lieu d'obtenir un Fixnum tu vas obtenir un Bignum, ce qui est un peu surprenant quand tu écris Fixnum.from_string.
Je ne sais pas si c'est un débat très intéressant, mais je voudrais encore apporter un exemple dans lequel je pense que la solution de Ruby est plus élégante:
a = Catalogue.find(:all).to_a.reverse
Catalogue est un modèle de Rails (ActiveRecord). "find" renvoit un truc qui ressemble superficiellement à un Array, mais parfois on a besoin d'un vrai Array, d'où la conversion avec to_a.
Maintenant, suivant l'autre approche:
a = Array.from_active_record_model_query_result(Catalogue.find).reverse
Ok, le nom de méthode que j'ai choisi est peut-être artificiellement long, mais c'est pour souligner que tu as dû créer un constructeur dans Array qui est très spécifique. Ça ne fonctionne que sur le genre de trucs renvoyé par "ActiveRecord::Base#find".
Est-ce que ce constructeur de tableau a sa place dans Array, ou dans ActiveRecord ? Je pense que tu seras d'accord: c'est propre à ActiveRecord, ça ne doit pas être une méthode de Array.
On peut imaginer une solution intermédiaire, en faisant: ActiveRecord::Base.array_from_query_result( Catalogue.find(:all) ), mais bon, c'est encore plus laid.-
[+] [^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 12/12/2007 à 14:12. (lien). Évalué à -1.Mouais je reste moyen convaicu par le fait que cela doivent etre au type de départ de connaitre tous ces types d'arrivé.
Apres je sais pas trop comment se débrouille Java enfait car il existe un methode toArray() dans les objet implementant List je crois.
Du coup j'ai l'impression qu'un hybride serait fait, tous les objets peuvent se transtyper en chaine (toString) ou en array (toArray) et apres pour les transtypage plus complexe on fait avec ca et une methode dans la classe d'arrivé.--
plus tu cours moins vite ..... mais ca fatigue quand meme
-
-
[^]Re: Célèbre ?
Posté par Jean-Philippe Garcia Ballester (Jabber id, page perso, ) le 12/12/2007 à 13:02. (lien). Évalué à 2.Ca veux dire qu'il faut surcharger la classe Entier si tu veux pouvoir accepter un transtypage vers un type non définie a la base dans la classe Entier ?
Les classes en ruby sont extensibles au fur et à mesure de l'execution.
Donc il suffit de mettre :
class Integer
def to_toto
# Le code qui va bien
end
end
et tu peux appeller 42.to_toto
-
-
-
[^]Re: Célèbre ?
Posté par Antoine () le 12/12/2007 à 21:58. (lien). Évalué à 5.Y a une logique derreire ca et n'importe quel livre de base en PHP l'explique.
Mouais... La logique, c'est surtout que ça été conçu par un guignol qui a trouvé intelligent d'avoir des conversions implicites dans tous les sens histoire de taper x au lieu de str(x).
-
-
[^]Re: Célèbre ?
Posté par Gniarf () le 12/12/2007 à 15:39. (lien). Évalué à 6.oui enfin toto il compare volontairement des pommes et des oranges, il s'étonne d'obtenir n'importe quoi et en plus il est fier de lui.
c'est peut-être pas le langage qu'il faut changer, là.--
Windows has no users. It has hostages.-
[+] [^]Re: Célèbre ?
Posté par Jean-Philippe Garcia Ballester (Jabber id, page perso, ) le 12/12/2007 à 15:51. (lien). Évalué à -1.oui enfin toto il compare volontairement des pommes et des oranges, il s'étonne d'obtenir n'importe quoi et en plus il est fier de lui.
Je ne suis pas d'accord du tout. Pourquoi est-il interdit de demander si une pomme est égale à une orange ?-
[+] [^]Re: Célèbre ?
Posté par Gniarf () le 12/12/2007 à 18:05. (lien). Évalué à -1.en C tu ne vas pas comparer "pomme" et "orange" ou "pomme" et orange avec un = ou ==
--
Windows has no users. It has hostages.-
[^]Re: Célèbre ?
Posté par Jean-Philippe Garcia Ballester (Jabber id, page perso, ) le 12/12/2007 à 19:27. (lien). Évalué à 4.Quel rapport entre le C et les autres langages ? Si c'est comme ça en C, alors c'est que c'est normal ?
Moi ça me semble normal de dire qu'une pomme n'est pas égale à une orange. La comparaison me semble légitime, et devrait renvoyer toujours "faux".
De plus, si on admet qu'il n'est pas cohérent de comparer des objets de types différents, alors pourquoi PHP autorise ces comparaisons, et renvoie une réponse contre-intuitive ? Lorsque le programmeur fait n'importe quoi, un bon langage se doit de renvoyer une erreur.-
[^]Re: Célèbre ?
Posté par Gniarf () le 13/12/2007 à 01:16. (lien). Évalué à 1.le rapport avec le C et le fait qu'on compare le contenu de deux chaines avec strcmp() et pas = ou != ou == ? http://fr.wiktionary.org/wiki/exemple
sinon, "un langage strict se doit de renvoyer une erreur" je veux bien.--
Windows has no users. It has hostages.
-
-
-
-
[^]Re: Célèbre ?
Posté par Erwan (page perso, ) le 12/12/2007 à 17:03. (lien). Évalué à 3.Quand j'essaye de comparer un entier et une chaine de charactere, je préfère un langage qui me dit "types incompatibles" (du coup je sais que je dois convertir, et je sais comment) qu'un langage qui continue a fonctionner sans rien dire.
Le vrai problème c'est que l'erreur est humaine, mais sans message d'erreur clair pour mettre le doigt dessus et réparer, ça peut devenir un enfer.-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 12/12/2007 à 17:43. (lien). Évalué à 1.Ben apres c'est une habitude. Moi j'essaye jamais de comparer des entiers a des chaines de caractere, sauf quand je sais exactement ce que je fais. Bref pour moi ca ne me pose pas de probleme vu que j'ai apprit comment fonctionnait le language avant de m'en servir, c'est plus problématique quand on essaye de bricoler avec PHP.
Perso le PHP demande beaucoup beaucoup plus de rigueur du fait de sa permissivité. Quand un language a un haut niveau de repport d'erreur on a tendance a se reposer sur lui, et du coup le jour ou il laisse passé un trucs qu'on avait pas prévu ben on est tout pantois.--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par Antoine () le 12/12/2007 à 21:58. (lien). Évalué à 4.Perso le PHP demande beaucoup beaucoup plus de rigueur du fait de sa permissivité. Quand un language a un haut niveau de repport d'erreur on a tendance a se reposer sur lui, et du coup le jour ou il laisse passé un trucs qu'on avait pas prévu ben on est tout pantois.
Ah oui ça c'est l'argument qui tue : PHP est nul, mais comme on sait que PHP est nul on ne risque pas d'être surpris. Il respecte donc le Principle of Least Astonishment.-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 12/12/2007 à 22:35. (lien). Évalué à 2.J'ai commencé par Perso pour indiqué que c'etait ma vision de la choses ;)
J'ai pas dit que c'etait forcement bien mais perso quand je code en PHP j'ai tendance a bien tout reverifier 15 fois, alors qu'en Java j'ai tendance a me reposer un peu plus sur le repport d'erreur. J'ai pas dit que c'etait foncierement bien. Mais je n'es jamais prétendu etre un bon programmeur.
En meme temps je fait du PHP donc du coup ca montre bien tout de suite a quel point je suis limité, car comme tu dit PHP est nul.--
plus tu cours moins vite ..... mais ca fatigue quand meme
-
-
[^]Re: Célèbre ?
Posté par Ontologia (page perso, ) le 12/12/2007 à 23:52. (lien). Évalué à 4.On rentre dans des questions de goûts et de couleur.
Personnelement, étant assez tête en l'air, je préfère avoir un compilateur hyper chiant, qui ne m'autorise absolument aucun écart, aucun code "dangereux" et me garantit donc aucune surprise.
C'est la garantie de ne pas passer des heures à debugger des conneries.
Parce que passer 1 journée à debuguer un truc que j'ai écrit en moins d'une heure, ça m'est arrivé, et c'est très frustrant, sans compter qu'il faut faire avaler la pilule à ton chef, qui le prend pour de l'incompétence pur.
Les langages non typés ne me dérange pas, mais à condition qu'ils ne soient pas dynamiquement typés, hors PHP l'est :-(-
[^]Re: Célèbre ?
Posté par Bozo le clown () le 13/12/2007 à 06:46. (lien). Évalué à 1.Peux tu citer un langage faiblement typé et statiquement typé et nous indiquer en quoi ca pourrait être moins dérangeant ?
C'est une vraie question .
-
-
-
-
-
-
[^]Re: Célèbre ?
Posté par Ontologia (page perso, ) le 12/12/2007 à 12:28. (lien). Évalué à 5.Ben je sais pas comment tu te débrouille car depuis la version 5 de PHP le modele Objet est bien meilleur
Oui, sauf que contraîrement à Ruby, PHP n'es pas totalement objet :
Tu n'as pas de type Block en Php, c'est à dire que tu ne peux pas (à ma connaissance) définir de blocs de contrôle dans la librairie du langage.
En ruby, comme en Smalltalk ou en Lisaac, times est une méthode d'un entier auquel tu passes un block, c'est à dire une fonction qui prend en argument un entier et exécute le code :
3.times do |it|
puts bonjour("petit canard")
puts it
end
C'est à mon avis un des principaux intérêt de Ruby.
(Après, et je peux pas m'en empêcher, ça va quand même beaucoup moins loin que Lisaac, mais ne crachons pas dans la soupe, c'est un très beau langage, et surtout une très bonne idée)-
[^]Re: Célèbre ?
Posté par Ernest H (Jabber id, ) le 13/12/2007 à 00:10. (lien). Évalué à 3.Cette façon de pouvoir appliquer une méthode à une valeur continue de m'effrayer. Le reste de la déclaration de la boucle aussi, ça donne vraiment l'impression de faire les choses à l'envers pour le plaisir de les faire à l'envers. Mais bon, peut-être que je m'y ferai un jour, je me suis bien habitué à ne plus faire
0 3 FOR i
"Petit canard" BONJOUR
i
NEXT
-
-
-
[^]Re: Célèbre ?
Posté par totoro () le 12/12/2007 à 09:10. (lien). Évalué à 2.
voir les frameworks genre CakePHP qui essayent de pomper Rails (au lieu d'etre originaux) ce me fait un peu de la peine tellement c'est affreux.
Je ne sais pas si c'est le meilleur mais RoR est clairement devenu un référence dans le monde des frameworks web, il paraît donc relativement logique de d'autres s'en inspire avec plus ou moins de bonheur--
dyslectics have more fnu
-
[^]Re: Célèbre ?
Posté par Gniarf () le 12/12/2007 à 15:07. (lien). Évalué à 1.> voir les frameworks genre CakePHP qui essayent de pomper Rails (au lieu d'etre originaux) ce me fait un peu de la peine tellement c'est affreux
la bonne blague, RoR a également pompé sur ses prédécesseurs et a fait des choix classiques (patterns MVC, Active Records...), la seule originalité technique est le choix de Ruby--
Windows has no users. It has hostages.-
[^]Re: Célèbre ?
Posté par zerchauve () le 12/12/2007 à 17:56. (lien). Évalué à 3.**baillement**
tu as deja regardé CakePHP pour comprendre ce que je veux dire par "pomper" ?
sinon effectivement AR et MVC sont vieux, mais je suis pas sur que quiconque ai jamais dit que Rails les avaient inventés.
Ce qui est mis en avant et (je pense) novateur c'est la convention qui prime sur la configuration. Un peu dictatorial mais bon, la philosophie est très Apple-ienne.
M'enfin je vais surement me prendre un bonne remarque Gniarfienne de merde derrière, du genre "pfffouaaa mais tu dis n'importe quoi ca pue etc..."
trolle bien.--
-- Le voilà qui s'en va, un des prototypes personnels de Dieu... Trop bizarre pour vivre, trop unique pour mourir-
[^]Re: Célèbre ?
Posté par Gniarf () le 12/12/2007 à 18:59. (lien). Évalué à 2.> **baillement**
> tu as deja regardé CakePHP pour comprendre ce que je veux dire par "pomper" ?
lui et les autres, merci. sinon, toi, ca va ?
> sinon effectivement AR et MVC sont vieux, mais je suis pas sur que quiconque ai jamais dit que Rails les avaient inventés.
> Ce qui est mis en avant et (je pense) novateur c'est la convention qui prime sur la configuration. Un peu dictatorial mais bon, la philosophie est très Apple-ienne.
quelques unes génantes ou plutôt définitivement trop alien mais bon on peut s'en sortir quand même. et puis sinon on peut toujours changer de crèmerie, il n'y a pas qu'Apple dans la vie.
ces conventions (enfin, celles qui ne me foutent pas des batons dans les roues) sont effectivement le gros apport par rapport à ce qui existait avant. oui, c'est un framework cohérent, bien foutu, j'avais trouvé. les réserves des trolleurs habituels (le clan J2EE et son "pouah, ca va pas monter en charge") ne m'ont pas spécialement inquiétées, ni même perturbées, en fait.
il est normal que les gens voulant reproduire avec d'autres langages comme PHP ou Python ce qu'ils ont apprecié dans RoR "pompent" ce côté conventions/séparation dans des répertoires bien rangés/tests/migrations/etc... : une dernière réussite qu'on ne remarque pas de prime abord est que RoR tient debout tout seul, contrairement à d'autres bidules pas livrés en un seul morceau, aux ressources très éparpillées, très disparates, à recoller soi-même avec du scotch sans jamais trop savoir si on a bien pris les bons morceaux et les bonnes versions
> M'enfin je vais surement me prendre un bonne remarque Gniarfienne de merde derrière, du genre "pfffouaaa mais tu dis n'importe quoi ca pue etc..."
toujours ce syndrôme de Tourette, c'est triste.
> trolle bien.
pfffouaaa mais tu dis n'importe quoi ca pue, voilà, j'espère que ça t'aura réchauffé le coeur.--
Windows has no users. It has hostages.
-
-
-
-
[^]Re: Célèbre ?
Posté par Slainer (Jabber id, page perso, ) le 11/12/2007 à 21:52. (lien). Évalué à 4."Apres donne moi un truc a faire et je suis sur que mes ligne de code seront bien plus moche si je le fait en Ruby que si je le fait en PHP." >
MWAHAHAHAHAhahahahah ! ça fait du bien une franche rigolade le soir. Nan t'es sérieux là ou c'est juste un méchant troll pas beau ?
Moi je pense juste que certains développeurs se sont trop attachés à la syntaxe C-style. Forcément, lorsqu'on fait que ça toute la journée on s'habitue et on trouve que les langages n'ayant pas ce style de syntaxe sont nuls (ou bien réservés aux newbies).
Moi aussi j'ai trouvé ça bizarre au début après des années de programmation PHP de voir des bouts de code ruby.
Au final c'est une question de goût. Certains développeurs se sont peut être tellement habitués à la syntaxe C qu'ils ne pourront jamais se faire à Ruby.
Mais la question est : quelle personne n'ayant jamais fait de prog pourrait trouver un bout de code du style :
for($i=0; $i < 3; $i++) {
echo "Ho !"
}
plus lisible qu'un :
3.times do
puts "Ho !"
end
J'apprécie aussi de nombreux mots clés tels que "unless" plutôt que l'opérateur not (!) dans les expressions booléennes ou bien le ? qui suit les méthodes renvoyant un booléen. Exemple : exit unless result.nil?
Bon je m'arrêterai là. Tout ça pour dire que je suis un ancien adorateur de PHP qui a bien switché dans le monde joyeux de Ruby.-
[^]Re: Célèbre ?
Posté par IsNotGood () le 11/12/2007 à 22:34. (lien). Évalué à 2.La différence est sur le "for" et "times do". Mais tu compares deux choses différentes.
> for($i=0; $i < 3; $i++)
for est d'un usage très général. Par exemple, comment tu fais "for(;;)" avec "times do" ?
Le language doit rester général et ne pas avoir 10 000 mots clés pour chaque cas.
Le "times do", tu peux le faire avec une "hideuse" macro (j'ai oublié un peu le php) :
#define TIMES_DO(nb) for(int i_times_do=0 ; i_times_do < (nb) ; i_times_do++)
Donc ton exemple devient
TIMES_DO(3) {
printf("Ho !")
}
Et voilà.
PS : évitez les macros à la con comme TIMES_DO. Apprennez le language que vous utilisez.-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 11/12/2007 à 22:43. (lien). Évalué à 4.Juste pour info, "times" n'est pas un mot clé, c'est une méthode appartenant aux nombres entiers. Plus précisément, c'est un itérateur. On trouve aussi des itérateurs "upto" et "downto" permettant de faire des "for", par exemple 3.upto(5).
Utiliser des méthodes appartenant à ce qu'on considère généralement comme des "types de base" peut paraître bizarre, mais ça donne généralement un moyen assez élégant de faire du code autodocumenté. Et une fois qu'on est habitué aux itérateurs, ce genre d'écriture devient très naturel. On apprécie justement de ne pas avoir besoin d'un mot clé pour faire tout ça (le mot clé while existe quand même pour les cas plus compliqués).
Dans un autre style, mais toujours montrant comment on utilise des méthodes pour avoir du code autodocumenté, rails fournit plein d'aides supplémentaires. On peut écrire:
3.gigabytes (renvoie une quantité de bytes)
3.months (renvoie une durée en secondes)
3.months.from_now (renvoie une date)
L'enchaînement months.from_now fonctionne parce que Fixnum#from_now crée une date à partir d'un nombre qui est interprété comme un nombre de secondes. Je trouve ça élégant.
-
[^]Re: Célèbre ?
Posté par Farzad FARID (page perso, ) le 11/12/2007 à 23:03. (lien). Évalué à 1.for est d'un usage très général. Par exemple, comment tu fais "for(;;)" avec "times do" ?
Le language doit rester général et ne pas avoir 10 000 mots clés pour chaque cas.
Le "times do", tu peux le faire avec une "hideuse" macro (j'ai oublié un peu le php)
A ton tour tu compares des pommes et des poires puis tu déguises une poire en pomme :)
L'instruction "N.times do ... end" est un itérateur auquel on passe en argument un bloc de code, pas une simple instruction de boucle. Ce sont deux concepts qui n'existent pas en PHP, en tout cas pas avec la simplicité et l'intégration qu'offre Ruby.
Certes il y a ça [1] mais c'est loin d'être élégant et naturel à écrire...
D'autre part, un exemple tel que 3.times do puts "Hello" end est juste là pour illustrer les itérateurs, et ne donne pas vraiment une idée de la puissance réelle de ceux-ci et de leur l'utilité dans un contexte plus complexe (par exemple la création d'un framework tel que Rails).
Ces concepts ne sont certes pas novateurs (les itérateurs par exemple existent en Smalltalk depuis longtemps), mais Ruby est celui qui les implémente le mieux parmi les langages les plus couramment utilisés [2].
1 : http://frederic.bouchery.free.fr/?2004/11/01/30-Creer-Un-Ite(...)
2 : http://www.tiobe.com/tpci.htm-
[^]Re: Célèbre ?
Posté par desfrenes () le 11/12/2007 à 23:08. (lien). Évalué à 2."Ce sont deux concepts qui n'existent pas en PHP"
ça a le même nom... c'est la même chose ? ;-)
http://frederic.bouchery.free.fr/?2004/11/01/30-Creer-Un-Ite(...)-
[^]Re: Célèbre ?
Posté par IsNotGood () le 11/12/2007 à 23:40. (lien). Évalué à 0.> http://frederic.bouchery.free.fr/?2004/11/01/30-Creer-Un-Ite(...)
Du devrait relire le commentaire auquel du répond.-
[^]Re: Célèbre ?
-
-
-
[^]Re: Célèbre ?
Posté par Antoine () le 12/12/2007 à 22:03. (lien). Évalué à 2.mais Ruby est celui qui les implémente le mieux parmi les langages les plus couramment utilisés
Mmmh plus précisément ? En quoi les implémente-t-il "mieux" que, par exemple, Python ?-
[^]Re: Célèbre ?
Posté par Farzad FARID (page perso, ) le 13/12/2007 à 09:53. (lien). Évalué à 2.Mmmh plus précisément ? En quoi les implémente-t-il "mieux" que, par exemple, Python ?
- Parce que Ruby a intégré les itérateur et les blocs de code depuis la première version ?
- Parce qu'en Ruby tout les types (y compris les nombres) sont des de vrais objets, extensibles et modifiables par le développeur, et ce depuis le début ?
- Parce qu'en Python tout ceci n'a été ajouté que tardivement, et que ça se ressent dans la syntaxe ?
J'ai utilisé Python pendant plus de 12 ans, j'aime beaucoup ce langage, et je parle donc en connaissance de cause.-
[^]Re: Célèbre ?
-
[^]Re: Célèbre ?
Posté par Antoine () le 13/12/2007 à 20:17. (lien). Évalué à 2.- Parce que Ruby a intégré les itérateur et les blocs de code depuis la première version ?
Je ne vois pas le rapport entre "implémenté avant" et "mieux implémenté".
Parce qu'en Ruby tout les types (y compris les nombres) sont des de vrais objets
En Python aussi. Oui, y compris les nombres, les classes, les modules, les fonctions...
Parce qu'en Python tout ceci n'a été ajouté que tardivement, et que ça se ressent dans la syntaxe
Ca ne se "ressent" que parce que tu as une vision religieuse des choses liée à ton expérience avec Ruby. En fait c'est très naturel : une fonction est la même chose qu'une méthode (on peut d'ailleurs binder l'une sur l'autre), c'est donc normal que le self soit explicite. De même le cls est explicite sur les méthodes de classe.
Et c'est avant tout justifié par un principe directeur de Python : explicit is better than implicit. En Python il y a peu de magie, la logique est apparente partout, contrairement à Perl et dans une moindre mesure Ruby.
Dire que c'est à cause d'une limitation quelconque du langage qu'il n'y a pas de self implicite est une grossière erreur : il n'aurait pas été compliqué de modifier l'instantiation des méthodes pour rajouter la logique correspondante. Il y a même des gens qui se sont amusés à implémenter cela en pur Python, sans toucher à l'interpréteur ( http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3623(...) ).
... Ceci dit, la question d'origine est "en quoi les itérateurs de Ruby sont-ils mieux implémentés", et tu n'as pas répondu. :-)-
[^]Re: Célèbre ?
Posté par Farzad FARID (page perso, ) le 14/12/2007 à 17:32. (lien). Évalué à 2.Euh non je ne peux pas te répondre car encore une fois tu diverges du sujet initial... Je n'ai jamais parlé de "self", et je ne vois pas ce que cela vient faire ici :)
Apparemment tu n'as pas fait de Python 1.x comme j'ai pu en faire, avant que ça devienne un vrai langage à objets, et tes explications sur "self" sont peu convaincantes.
J'arrête de commenter, ça ne sert à rien, je retourne à mon développement Rails.
Happy Python hacking, et sans rancune, il y a de la place pour tous les langages sur terre, du moment qu'on n'utilise pas la pensée magique pour en vanter les mérites ;)-
[^]Re: Célèbre ?
Posté par Antoine () le 14/12/2007 à 18:56. (lien). Évalué à 2.tu n'as pas fait de Python 1.x comme j'ai pu en faire
Effectivement je n'en ai pas fait. Ceci dit ce n'est pas terriblement important, vu que Python en est à la version 2.5 et qu'une alpha (très alpha certes) de la 3.0 est déjà sortie...
encore une fois tu diverges du sujet initial
La paille et la poutre ?
Bon, on ne saura apparemment jamais pourquoi "les itérateurs de Ruby sont mieux implémentés". Merci pour cette belle intervention :)
-
-
-
-
-
-
-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 11/12/2007 à 23:27. (lien). Évalué à 2.Le sens que je voulais donner à ma phrase c'est que ce n'est pas le language qui fait qu'on fait un code propre. C'est bien le programmeur. En l'occurence je suis plus PHP (egalement un peu Java) et ben sur du Ruby je n'aurais pas l'esprit tourné Ruby et je ne pense pas faire un code aussi jolie qu'un programmeur Ruby pourrait le faire.
Apres les question sur les boucle bon je serais tenté de te dire que ton exemple couvre quelque choses qui risque d'etre utilisé une fois tous les 32 du mois. Apres pour ce qui est des itérateur entre un :
foreach($array as $element)
{
echo $element."\n";
}
et
array.each do |element|
puts element+"\n"
On a deux syntaxe assez lisible je trouve.--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par IsNotGood () le 11/12/2007 à 23:58. (lien). Évalué à 3.> foreach($array as $element)
Je ne sais pas si un foreach de php peut être considéré comme un itérateur. foreach est pratique.
Dans le cas du C++ (et sa librairie standard), il y a des itérateurs. Un itérateur est un type, donc il peut être utilisé avec toute classe (si elle l'implémente).
Par exemple :
// recherche la position de val dans list
X::const_iterator pos = find(list.begin(), list.end(), val) ;
// depuis val jusqu'à la fin
while (pos != list.end()) {
[...]
pos++ ;
}
Qu'on peut aussi écrire pour les accros du for() :
for (X::const_iterator pos = find(list.begin(), list.end(), val) ; pos != list.end() ; pos++) { [...] }
list peut être presque n'importe quoi (vecteur, liste chainée, map, flux E/S, etc). Donc c'est utilisable avec les modèles. Le polymorphisme est supporté via mem_func. M'enfin, force est de reconnaitre que ce n'est pas trivial.-
[^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 12/12/2007 à 00:08. (lien). Évalué à 1.Ben a partir du moment ou tu peux te servir de foreach sur des objet ca compte nan ? Comme en Java quand une classe implemente la classe itérator on peu s'en servir dans un "foreach" java.
--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par IsNotGood () le 12/12/2007 à 03:29. (lien). Évalué à 1.> Ben a partir du moment ou tu peux te servir de foreach sur des objet ca compte nan ?
Pourquoi pas.
De toute manière la qualité d'un language ne se limite pas à la somme de ses fonctionnalités. Il y a tant de compromis...
J'ai utilisé php, j'ai adoré.
-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 12/12/2007 à 11:20. (lien). Évalué à 4.Foreach est une forme d'itérateur, mais c'est un peu moins générique malgré tout. Le problème, c'est qu'en utilisant un mot clé au lieu d'une méthode d'instance, on fixe une fois pour toutes le comportement de l'itérateur: il est censé énumérer les éléments d'un contenant, dans un ordre prédéfini (par l'objet contenant).
Il y a des tonnes d'autres manières d'imaginer une itération:
- on peut vouloir parcourir les éléments dans un autre ordre que celui "intuitif"
- sur une table de hachage, on peut vouloir parcourir les clés ou les valeurs
- on peut vouloir parcourir un arbre ou un graphe de plusieurs manières (profondeur, largeur...)
- on peut vouloir parcourir un graphe en spécifiant de quel sommet on part
- on peut vouloir faire autre chose qu'exécuter du code sur chaque élément, par exemple construire un tableau contenant les résultats de chaque visite d'un élément. Ça oblige, soit à faire du code pas très beau, soit à ajouter un mot clé "map" au langage, qui souffrira des mêmes limitations que foreach sur l'ordre du parcours.-
[^]Re: Célèbre ?
Posté par Ontologia (page perso, ) le 12/12/2007 à 12:51. (lien). Évalué à 1.En lisaac, je me suis amusé à faire aussi
- foreach_while cond:BLOCK do action:BLOCK
qui exécute la fonction action sur la liste, tant que cond renvoi vrai, pour l'élément.
de même :
- foreach_until cond:BLOCK do action:BLOCK
plus marrant, on a écrit une méthode sur la lib INTEGER, qui permet de faire des espèces de compréhensions
1.to 50 items {i : INTEGER ; i*2} do {
j : INTEGER;
j.print;
" est pair\n".print;
};
En gros on lui donne l'ensemble de départ, une fonction, et il parcours le block en calculant la compréhension.
Bon c'est à améliorer..-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 12/12/2007 à 13:03. (lien). Évalué à 2.Pour le foreach_while, c'est possible aussi en Ruby, mais de manière moyennement élégante, en écrivant quelque chose du genre:
class Toto < Array
def each_while(cond)
self.each { |item|
break unless cond.call(item)
yield(item)
}
end
end
t = Toto.new
0.upto(9) { |i| t << i }
t.each_while( lambda { |i| i < 5 } ) do |i|
puts i
end-
[^]Re: Célèbre ?
Posté par Stephane Wirtel () le 12/12/2007 à 14:18. (lien). Évalué à 5.t.select { |i| i < 5 } do |i|
puts i
end
oups :d
-
[^]Re: Célèbre ?
Posté par Farzad FARID (page perso, ) le 12/12/2007 à 14:56. (lien). Évalué à 2.Plus élégamment, sans avoir besoin de dériver ou modifier la classe Array, en corrigeant l'exemple précédent :
# On construit un tableau de 10 entiers
t = Array.new
10.times { |i| t << i }
# On simule "foreach_while"
t.select { |i| i < 5 }.each { |i| puts i }
Elégant et compact, du Ruby quoi :)-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 12/12/2007 à 17:31. (lien). Évalué à 2.Sauf erreur, ça construit un nouveau tableau, donc ce n'est pas toujours souhaitable. De même, il est souvent préférable d'utiliser un reverse_each plutôt que de construire un tableau inversé avec reverse, et ensuite appeler each dessus. Il n'y a pas de mal à créer de nouveaux itérateurs, et Ruby est déjà bien assez lent sans qu'on l'aide en créant plein d'objets inutiles :)
Par contre dans mon exemple, je n'aurais pas dû dériver la classe Array mais lui ajouter une méthode, ça aurait été plus simple.
-
[^]Re: Célèbre ?
Posté par Antoine () le 12/12/2007 à 22:09. (lien). Évalué à 1.# On construit un tableau de 10 entiers
t = range(10)
# On convertit tout en itérant et on accumule le tout
print "\n".join(str(i) for i in t)
Concis et stylé, du Python quoi !
Vous en avez d'autres, des exemples stupides ? :)-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 12/12/2007 à 22:44. (lien). Évalué à 3.Ca ne fait pas la même chose que nos "exemples stupides", et en plus c'est assez moche, selon moi. Je suppose que "str(i) for i in t" construit un tableau ou une liste, mais j'ai du mal à comprendre pourquoi join est une méthode de la chaîne. Est-ce que ça ajoute avant la chaîne, et donc avant le retour à la ligne ?
Ou alors "toto".join n'est pas un appel de méthode comme ça en a l'air, mais "." est l'opérateur de concaténation, auquel cas il n'y a plus aucun doute, tu mets le retour à la ligne avant le texte, c'est normal ?-
[^]Re: Célèbre ?
Posté par Ernest H (Jabber id, ) le 13/12/2007 à 00:27. (lien). Évalué à 3.[str(i) for i in t] ça revient au même que $\{str(i); i \in t\}$. Le fait de mettre des parenthèses plutôt que des crochets fait que le tableau n'est pas construit (mais on peut itérer dessus).
s.join(liste) crée la chaine constituée des éléments de liste séparés par s. Donc là il met des passage à la ligne entre chaque paire de nombres (et il y aura un pasage à la ligne de moins que de nombres, comme il faut quoi).-
[^]Re: Célèbre ?
Posté par pa_pitufo_pa () le 13/12/2007 à 14:29. (lien). Évalué à 1.Donc concis, stylé mais imbitable, sympa comme langage.
-
[^]Re: Célèbre ?
Posté par Ernest H (Jabber id, ) le 13/12/2007 à 16:51. (lien). Évalué à 1.je ne vois pas comment tu peux dire que c'est imbitable à moins de n'avoir jamais fait de maths ! Ou alors tu n'as pas compris que le morceau entre $, c'était du LaTeX pour montrer qu'une liste, c'est jamais qu'un ensemble...
-
[^]Re: Célèbre ?
Posté par Thomas Douillard () le 14/12/2007 à 10:06. (lien). Évalué à 4.une liste, c'est jamais qu'un ensemble...
Mouais, une liste c'est surtout une séquence d'éléments. On dit plutôt une collection d'ailleurs. Genre un ensemble mathématique il y a pas forcément d'ordre, une liste est ordonée, on peut voir ça comme un ensemble de couple {(1,e_1), ... ,(i,e_i), ... ,(k,e_k)} avec i différent pour tous les couples et i<=k, i>0. Donc non, une liste c'est différent d'un ensemble. Après effectivement tu peux utiliser une liste (de "e") comme une sorte d'implémentation d'un ensemble (de "e").-
[^]Re: Célèbre ?
Posté par Ernest H (Jabber id, ) le 14/12/2007 à 15:08. (lien). Évalué à 1.Je n'avais pas envie de dire "un multi-ensemble ordonné".
-
[^]Re: Célèbre ?
Posté par Sylvain Sauvage () le 14/12/2007 à 18:53. (lien). Évalué à 3.Si tu mélanges les pommes et les oranges, faut pas t’étonner qu’on te réponde « c’est pas une couleur »…
-
-
-
-
-
-
[^]Re: Célèbre ?
Posté par Antoine () le 13/12/2007 à 20:25. (lien). Évalué à 2.Je suppose que "str(i) for i in t" construit un tableau ou une liste
Non justement, ça construit un itérateur, d'où le rapport avec vos exemples.
Et si vos exemples sont stupides, c'est parce qu'ils portent sur un type de code qui est absolument inutile dans la vraie vie (afficher tous les entiers de 1 à 10, chouette...). Un langage qui est plus "joli" sur des exemples totalement académiques, la belle affaire.
j'ai du mal à comprendre pourquoi join est une méthode de la chaîne
Et tu n'as pas de mal à comprendre pourquoi "times" est une méthode des entiers en Ruby ? Marrant ça, je croyais que la notation objet était naturelle pour les rubyistes ?
Ou alors "toto".join n'est pas un appel de méthode comme ça en a l'air, mais "." est l'opérateur de concaténation
Heu, comment dire, peux-tu lire un peu de doc sur Python histoire qu'on évite ce genre de question basique ? :-)-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 14/12/2007 à 03:53. (lien). Évalué à 4.Je te trouve un peu méprisant, ce qui est ironique sachant que même quand on t'explique que tu n'as pas compris nos exemples, tu as l'air trop "stupide" pour essayer de le faire.
Pour la dernière fois (parce que t'es lourd et que j'arrête là), nos exemples n'affichent pas les nombres de 1 à 10, nos exemples montrent différentes manière d'écrire un itérateur "foreach_while".
Et tu n'as pas de mal à comprendre pourquoi "times" est une méthode des entiers en Ruby ? Marrant ça, je croyais que la notation objet était naturelle pour les rubyistes ?
J'ai du mal à comprendre pourquoi join est une méthode de la chaîne, et pas du tableau. Maintenant que quelqu'un de plus serviable que toi m'a expliqué ce que ça faisait au lieu de me demander d'apprendre le Python avant de vouloir discuter, je ne comprends toujours pas la raison de ce choix. Ce n'est pas la chaîne que l'on joint avec quelque chose, c'est le tableau que dont on joint les éléments en les collant avec la chaîne. Intuitivement, je penserais que join est une méthode du tableau, comme c'est le cas dans beaucoup de langages.
Quant au fait d'apprendre le Python avant d'avoir le droit de te répondre, j'oserais souligner que c'est toi qui a pris l'initiative de participer à cette discution où l'on parle essentiellement de Ruby. Je ne vois pas pourquoi on devrait apprendre ton langage favori avant de te répondre.-
[^]Re: Célèbre ?
Posté par Antoine () le 14/12/2007 à 08:08. (lien). Évalué à 1.nos exemples montrent différentes manière d'écrire un itérateur "foreach_while".
C'est bien ce que j'appelle un exemple académique sans incidence sur le monde réel. Dans la vraie vie, on a autre chose à faire que d'implémenter ou réimplémenter des "itérateurs foreach_while", cette dernière chose n'ayant aucune utilité.
J'ai du mal à comprendre pourquoi join est une méthode de la chaîne, et pas du tableau.
Précisément parce que join peut accepter autre chose que des listes en argument. Dans mon exemple join reçoit un itérateur. N'importe quel objet peut être un itérateur s'il implémente le protocole idoine (très simple).
Mais dans la notation "5.times { ... }", on pourra arguer de même que c'est le bloc de code qui s'exécute cinq fois, et non le nombre 5 qui effectue l'opération de répéter le bloc. Ou alors pourquoi pas "true.if { ... }" ? (et là je suis sûr qu'il y en a qui vont me répondre qu'ils l'ont fait)
Quant au fait d'apprendre le Python avant d'avoir le droit de te répondre
Oui mais savoir que le signe "." réalise un accès d'attribut ou de méthode plutôt qu'une concaténation de chaînes, ce n'est pas à proprement parler apprendre le Python, c'est juste savoir grosso modo à quoi ressemble le langage :-)
Ainsi je n'ai pas eu besoin d'apprendre le Ruby pour comprendre vos exemples.-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 14/12/2007 à 20:51. (lien). Évalué à 4.Alors pour info, d'une part avoir des itérateurs conditionnels est utile dans le monde réel, parce qu'il arrive qu'on n'ait pas envie de parcourir toute une liste, d'autre part cet exemple soi-disant académique sert essentiellement à illustrer comment on peut passer plus d'un bloc à une fonction, ce qui est également utile tous les jours dans le monde réel.
Si tu penses que pour aborder un aspect d'un langage (itérateurs et blocs) il faut étudier des cas concrets, je peux t'en sortir à la pelle, mais ça risque de prendre un peu plus de place. Par exemple je peux t'écrire un exemple où on veut parcourir un graphe en profondeur, et s'arrêter au premier sommet non marqué. C'est typiquement une variante de foreach_while.
Concernant la remarque sur join, je suis bien d'accord que ça ne s'applique pas qu'aux tableaux ou aux listes, ça s'applique à tout ce qui est énumérable. C'est pour cette raison que c'est une méthode appartenant au module Enumerable en Ruby. Ce module est implémenté par Array, mais aussi par d'autres objets. Je ne vois toujours pas en quoi on peut penser que c'est une méthode de String, mais admettons, c'est peut-être une autre manière de voir qui est valide.
Enfin, concernant l'opérateur ".", je pense que mon raisonnement est devinable dans la manière dont j'ai écrit mon post. D'abord j'ai supposé que c'était un appel de méthode, parce que c'est ce à quoi je suis habitué, mais je ne trouvais pas ça logique. Ensuite, je me suis rappelé qu'en Perl ou PHP, le point était l'opérateur de concaténation, d'où ma question.-
[^]Re: Célèbre ?
Posté par Antoine () le 14/12/2007 à 21:20. (lien). Évalué à 1.Par exemple je peux t'écrire un exemple où on veut parcourir un graphe en profondeur, et s'arrêter au premier sommet non marqué. C'est typiquement une variante de foreach_while.
Oui mais tu n'as nullement besoin du foreach_while avec ses blocs de code. Tu peux très bien utiliser une fonction de haut niveau prenant en paramètre un itérateur et un prédicat, et retournant un nouvel itérateur qui renvoie la même chose que le premier jusqu'à ce que le prédicat devienne vrai.
C'est exactement ce que fait la fonction takewhile() du module standard itertools en Python ( http://docs.python.org/lib/itertools-functions.html ).-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 15/12/2007 à 10:54. (lien). Évalué à 3.Je suis vraiment très bête, je n'arrive plus à comprendre ce que tu veux dire. Est-ce que j'ai donné un exemple idiot et académique, ou bien est-ce que j'ai donné un exemple trop spécifique et que j'aurais dû généraliser à tous les itérateurs ?
Formulé autrement, est-ce que tu changes de thèse à chaque message parce que tu essayes seulement de prouver que ton interlocuteur a tort ?
Au cas où tu serais de bonne foi, ce qui me semble improbable, je voudrais te faire remarquer qu'il s'agit d'un exemple sorti en 5 minutes dans une discution sur les itérateurs, pas d'une thèse de doctorat sur les langages, ou d'un cours de génie logiciel. Il s'agit d'une illustration de comment on peut écrire un certain type de choses, plus précisément de comment on peut "passer" plus d'un bloc à un itérateur.
Il est assez facile d'écrire la même chose en permettant de choisir l'itérateur, mais le code est moins accessible à quelqu'un qui ne connaît pas Ruby, et donc illustre beaucoup moins le sujet de la discution. Ca donne quelque chose comme ça:
class Object
def takewhile(iterateur, predicat)
self.send(iterateur) do |element|
break unless predicat.call(element)
yield(element)
end
end
end
(0..10).takewhile(:each, lambda { ... }) do |element|
...
end
Ca ne marche pas bien avec les itérateurs qui renvoient plus d'un élément à la fois, mais j'ai la flemme de faire un exemple parfait, surtout aussi stupide et académique. Tu remarqueras que le code est presque identique au précédent, puisque la seule différence est qu'on passe l'itérateur en paramètre, en plus du bloc et du prédicat.-
[^]Re: Célèbre ?
Posté par Antoine () le 15/12/2007 à 12:23. (lien). Évalué à 0.Est-ce que j'ai donné un exemple idiot et académique, ou bien est-ce que j'ai donné un exemple trop spécifique et que j'aurais dû généraliser à tous les itérateurs ?
Les deux :-)
Ainsi, la raison pour laquelle la fonction takewhile() est fournie dans les modules standard de Python, c'est qu'elle y est écrite en C et permet donc des gains de performance substantiels sur certains algorithmes. Sinon, c'est une primitive qui s'écrit en quatre lignes de Python, ça n'a donc pas grand intérêt de l'abstraire : pareil pour le foreach_while.
La morale, c'est que l'exemple donné des trucs géniaux qu'on peut faire avec les itérateurs de Ruby 1) se fait aussi sans problème dans d'autres langages 2) n'apporte à peu près rien en pratique.-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 15/12/2007 à 15:10. (lien). Évalué à 2.1) Je suis au regret de t'annoncer que tout ce qu'on peut faire en Python peut se faire en C. Ou en Java, ou en Perl, ou en Brainfuck.
2) De la même façon que "for" n'apporte rien face à "while", ou bien que Python n'apporte rien face au C, je suppose. On peut toujours tout faire en C, peu importe que ce soit inélégant et que ça prenne 30 lignes au lieu de 3. Sur l'utilité des itérateurs, je pense qu'actuellement le consensus est clair. De même sur l'utilité de la programmation fonctionnelle.
(Je commence à croire que tu considères que si c'est possible en Python, alors ça ne mérite pas d'être mentionné pour les autres langages. Ca expliquerait tous ces messages, en fait, et peut-être que j'ai eu tort de réagir.)-
[^]Re: Célèbre ?
Posté par Antoine () le 15/12/2007 à 20:40. (lien). Évalué à 2.Je commence à croire que tu considères que si c'est possible en Python, alors ça ne mérite pas d'être mentionné pour les autres langages.
Ce n'est pas que ça mérite pas d'être mentionné.
C'est juste que l'idée originale (exprimée par un posteur plus haut) que "Ruby est le seul langage populaire à avoir des itérateurs bien implémentés" est un mensonge.
Mais je suis d'accord que les mêmes concepts exprimés en C, assembleur ou même PHP sont bigrement moins élégants.
-
-
-
-
-
[^]Re: Célèbre ?
Posté par Batchyx () le 15/12/2007 à 09:27. (lien). Évalué à 1.<blockquote>Concernant la remarque sur join, je suis bien d'accord que ça ne s'applique pas qu'aux tableaux ou aux listes, ça s'applique à tout ce qui est énumérable.</blockquote>
Non. cela s'applique sur les énumérables qui retournent des chaînes et uniquement ceux la.
<blockquote>Je ne vois toujours pas en quoi on peut penser que c'est une méthode de String, mais admettons, c'est peut-être une autre manière de voir qui est valide.</blockquote>Si ça s'applique à l'objet basestring c'est que dans la liste il ne peut y avoir que des basestring.
Après on peut se poser la question de pourquoi on à pas une méthode générale qui prendrai autre chose que des chaînes. Mais cette méthode générique, dans le cas des chaînes devrait répétitivement faire des resultat+=unechaine, qui en python (tout comme strcat en C) est lent comme la pluie, et qui rendrait au final la méthode pas très intéressante.
Si la méthode join est intéressante, c'est qu'elle est optimisée pour traiter des chaînes et qu'elle doit sûrement accéder à la représentation interne des chaînes de la liste. Mettre cette méthode sur un objet liste ou un type énumerable, c'est autoriser qu'une méthode d'un objet aille fouiller dans la représentation interne de l'autre et c'est Mal.-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 15/12/2007 à 10:12. (lien). Évalué à 2.En Ruby, join s'applique à tout ce qui est énumérable, simplement parce que n'importe quel objet peut être converti en String à l'aide de la méthode to_s.
-
[^]Re: Célèbre ?
Posté par Antoine () le 15/12/2007 à 12:28. (lien). Évalué à 1.En Python, à peu près tous les objets sont aussi convertibles en chaîne avec le constructeur str() (qui appelle la méthode __str__() en sous-main), mais join() ne fait pas la conversion pour toi : explicit is better than implicit.
-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 15/12/2007 à 15:19. (lien). Évalué à 2.explicit is better than implicit
Si tu en es vraiment convaincu, tu pourrais éviter de garder ton argumentation implicite.
Pourquoi join ne convertit pas automatiquement en string, sachant que join n'accepte que les strings ? Ca veut dire que le langage t'oblige à expliciter quelque chose que tu dois toujours faire. Pourquoi ? Si j'ai besoin d'un string, pourquoi ne pas convertir l'objet en string ?
Il y a des cas où ce n'est pas évident, et dans ce cas la conversion ne doit pas être automatique. Par exemple, si j'écris "a + b" alors que a est un string et b un int, il n'est pas évident de conclure que je veux convertir "b" en string. Peut-être qu'en fait je voulais convertir "a" en int. Mais quand il n'y a pas d'ambiguité, forcer la convertion explicite n'a pas l'air justifié.-
[^]Re: Célèbre ?
Posté par Antoine () le 15/12/2007 à 20:51. (lien). Évalué à 2.Si tu en es vraiment convaincu, tu pourrais éviter de garder ton argumentation implicite.
Je n'en suis pas "vraiment convaincu", je rappelle juste la règle qui justifie ce choix. Après, chacun a le droit d'être en désaccord, c'est juste qu'il y a une cohérence dans la conception du langage.
Pourquoi join ne convertit pas automatiquement en string, sachant que join n'accepte que les strings
Précisément parce qu'ainsi, tu lèves les erreurs tôt plutôt que tard. Quiconque a déjà programmé en PHP sait à quel point c'est préférable ;-))
quand il n'y a pas d'ambiguité, forcer la convertion explicite n'a pas l'air justifié
Oui, comme ça une erreur dans ton programme apparaît cent lignes plus tard sous une forme incompréhensible plutôt qu'en levant la bonne exception au bon endroit...
D'autant que la conversion explicite n'est pas bien lourde à écrire. Par exemple : "".join(str(x) for x in my_iterator)
(on peut aussi choisir une notation plus fonctionnelle avec map ou imap)
-
-
-
-
-
-
-
-
-
-
[+] [^]Re: Célèbre ?
Posté par Farzad FARID (page perso, ) le 13/12/2007 à 09:56. (lien). Évalué à -1.Ton exemple n'a rien à voir avec celui que j'ai repris.
Merci d'avoir répondu à côté de la question, ça fait progresser la discussion dans la bonne direction.-
[^]Re: Célèbre ?
-
-
-
[^]Re: Célèbre ?
Posté par Yusei (page perso, ) le 14/12/2007 à 20:57. (lien). Évalué à 2.Au fait, ton exemple ne fait pas un foreach_while. Il prend tous les éléments qui vérifient la condition. Dans foreach_while, il faut s'arrêter au premier qui ne la vérifie pas. (Dans le cas précis de l'exemple, ça fonctionne uniquement parce que le tableau est trié)
-
-
-
-
-
-
-
-
-
-
[^]Re: Célèbre ?
Posté par IsNotGood () le 11/12/2007 à 22:16. (lien). Évalué à 1.> Rails et Ruby ne sont pas là pour remplacer les 25 lignes de "colles" en PHP
Comme dlfp ?-
[^]Re: Célèbre ?
Posté par Bruno Michel (Jabber id, page perso, ) le 12/12/2007 à 00:25. (lien). Évalué à 3.DLFP, qui utilise PHP (le langage) et templeet (le framework), n'est pas forcément un très bon exemple. Je pense que je pourrais convertir des gens à RoR rien qu'en leur montrant certains templates utilisés.
Sinon, DLFP serait un très bon candidat pour passer sous Rails. Le seul obstacle, c'est la quantité de code à migrer (on parle de 30 000 lignes de code pour les templates) par rapport au peu de temps libre dont les admins dispose.-
[^]Re: Célèbre ?
Posté par IsNotGood () le 12/12/2007 à 03:38. (lien). Évalué à 1.C'était de l'humour.
> Sinon, DLFP serait un très bon candidat pour passer sous Rails.
Non, c''est un très mauvais candidat. Dlfp marche. Les quelques reproches sur dlfp n'ont pas de réponse par manque de temps. Pas à cause de php.
Et le passage à Rails posera probablement des problèmes de tenu en charge. Or le budget de dlfp est très serré (pas de pub).
-
-
-
-
-


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.