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 (893 clics)
- Architecture REST (894 clics)
- Blog de Ruby on Rails (331 clics)
- Rails 2 Upgrade Notes (310 clics)
- Summary of Major Rails 2 Features (319 clics)
- Ruby on Rails sur dmoz (702 clics)
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.
![[en]](../../../images/en.png)
Ruby on Rails (893 clics)![[fr]](../../../images/fr.png)
Architecture REST (894 clics)-
Blog de Ruby on Rails (331 clics)
-
Rails 2 Upgrade Notes (310 clics)
-
Summary of Major Rails 2 Features (319 clics)
-
Ruby on Rails sur dmoz (702 clics)
> Lire la suite (154 commentaires, moyenne: 2,1). [dépêche : 5949 caractères]
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 () 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 () 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à.--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.-
[+] [^]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 ==
--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.-
[^]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.--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
-
-
-
-
[^]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--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.-
[^]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.--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
-
-
-
-
[^]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 () 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 (page perso, ) 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 ?
Posté par Gniarf () le 13/12/2007 à 14:04. (lien). Évalué à 3.> 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 ?
d'ailleurs Ruby rame depuis le début :(--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
-
[^]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 () 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 () 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 () 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 () 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 () 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 () 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 () 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 () 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 () 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 () 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 () 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 (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).-
[^]Re: Célèbre ?
Posté par patrick_g (page perso, ) le 12/12/2007 à 06:47. (lien). Évalué à 2.Y'a pas Fabien Penso qui avait dit sur son blog qu'il bossait sur une réécriture de dlfp en RoR ?
-
[^]Re: Célèbre ?
Posté par Guid (page perso, ) le 12/12/2007 à 08:39. (lien). Évalué à 3.Et le passage à Rails posera probablement des problèmes de tenu en charge.
C'est quoi cet a priori ?--
If you and dead people can read hex, how many people can read hex?-
[^]Re: Célèbre ?
Posté par Ontologia (page perso, ) le 12/12/2007 à 12:42. (lien). Évalué à 2.ça vaut ce que ça vaut, mais d'après shootout, Ruby est quelques peu plus lent que PHP :
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
A ajouter au fait qu'il n'y a pas de module apache Ruby, qu'il est nécessaire de rajouter un serveur, c'est peut être là un problème de montée en charge qui a impliqué cette réputation ? Ce pourrait être une hypothèse..-
[^]Re: Célèbre ?
Posté par Yusei () le 12/12/2007 à 12:53. (lien). Évalué à 2.Ruby est plus lent que PHP.
Rails de base est plus rapide que PHP de base, parce qu'il fournit plein de caches à différents niveaux sans effort de programmation.
Par contre, il faudrait comparer Rails à un framework PHP proposant les mêmes outils.
Pour info, il existe un module apache Ruby, mais il n'est pas utilisé par Rails, probablement parce qu'il n'est pas assez puissant. Il ne permet que d'intégrer du Ruby dans des pages web, à la PHP.
-
[^]Re: Célèbre ?
Posté par Guid (page perso, ) le 12/12/2007 à 15:13. (lien). Évalué à 2.De toute façon, c'est un domaine où la "scalabilité" est cruciale, alors avec un bon load balancing et un nombre suffisant de serveurs, ça devrait plus poser de problème, si ?
--
If you and dead people can read hex, how many people can read hex?-
[^]Re: Célèbre ?
Posté par Antoine () le 12/12/2007 à 22:12. (lien). Évalué à 4.De toute façon, c'est un domaine où la "scalabilité" est cruciale, alors avec un bon load balancing et un nombre suffisant de serveurs, ça devrait plus poser de problème, si ?
L'association Linuxfr compte sur toi pour acheter tous ces serveurs :)
-
-
-
-
[^]Re: Célèbre ?
Posté par Bruno Michel (page perso, ) le 12/12/2007 à 09:46. (lien). Évalué à 7.DLFP marche, mais plus personne n'est capable de le faire évoluer. Ca fait des années qu'il y a des entrées dans le tracker qui devraient être faites (voter pour les journaux, pouvoir éditer ses journaux, OpenID, le planet, captcha trop difficile, etc.). Si ce n'est pas fait, ce n'est pas par manque de temps, mais bien à cause du framework (templeet). En rails, ca ferait longtemps que ca aurait été fait.
-
[^]Re: Célèbre ?
Posté par Benoît Sibaud (Jabber id, page perso, ) le 13/12/2007 à 19:50. (lien). Évalué à 3.Ah non, c'est par manque de temps ou d'envie en ce qui me concerne. Sur les exemples cités en tout cas.
-
-
-
-
-
[^]Re: Célèbre ?
Posté par gertrude () le 26/12/2007 à 12:34. (lien). Évalué à 1.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...
Hahaha :) MDR!!!
Qu'est ce qu'on s'en tape des "$" .... en plus, il y en a (et je ne vois pas ce qui empeche des les utiliser si on es un dev php accro à cette syntaxe pourrave) donc je ne vois pas ce qu'il y a de chiant.
Comparativement, je pourrais donc qualifier PHP de laxatif vu que par rapport à Ruby on Rails c'est quand même beaucoup plus de taf
Enfin bref ça fait toujours plaisir une petite blague comme ça dès le matin
-
-
[^]Re: Célèbre ?
Posté par Jordan Bracco (Jabber id, page perso, ) le 11/12/2007 à 21:21. (lien). Évalué à 1.Tu préfères PHP ? Mais ça a une syntaxe PHP ?!
-
[^]Re: Célèbre ?
Posté par zerchauve () le 11/12/2007 à 21:26. (lien). Évalué à 2.ceci dit PHP ca a au moins des performances :)
--
-- 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 totoro () le 12/12/2007 à 09:19. (lien). Évalué à 2.
ceci dit PHP ca a au moins des performances :)
Faudrait p'tet comparer ce qui est comparable parceque dans le même genre servir des pages statiques c'est plus performant qd même ;).
Enfin une comparaison Symfony/RoR/Django est sûrement plus pertinente http://wiki.rubyonrails.com/rails/pages/Framework+Performanc(...)--
dyslectics have more fnu-
[^]Re: Célèbre ?
Posté par baud123 (Jabber id, page perso, ) le 12/12/2007 à 10:30. (lien). Évalué à 3.à voir les commentaires de ton lien, le test ne semble pas si représentatif (ou en tout cas aux dépens de PHP et de la configuration MySQL retenue) : utilisation de connexions persisitentes à MySQL (causant des erreurs et surcharge de MySQL), utilisation d'un reverse proxy pour RoR mais pas pour PHP...
si quelqu'un a d'autres méthodes utilisées pour vérifier la tenue à la montée en charge, ça m'intéresse.-
[^]Re: Célèbre ?
-
-
-
-
[+] [^]Re: Célèbre ?
Posté par TheGuit (page perso, ) le 11/12/2007 à 21:30. (lien). Évalué à -1.Ruby n'as pas du tout une syntaxe PHP.
--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Célèbre ?
Posté par pa_pitufo_pa () le 13/12/2007 à 14:34. (lien). Évalué à 1.Ruby n'as pas du tout une syntaxe PHP.
merci
-
-
[^]Concours de b.....
Posté par desfrenes (page perso, ) le 11/12/2007 à 22:28. (lien). Évalué à 2.On part d'une news sur un framework... pour finir par troller sur PHP. Bref, rien à voir tout ça.
Dés qu'on parle de Rails il y a toujours quelqu'un pour comparer avec PHP et dés qu'on parle d'un framework en PHP il y a toujours quelqu'un pour comparer avec Rails. Drôle de phénomène.
Sinon pour le débat sur les syntaxes C-like/Ruby... quand on fait déjà du javascript, de l'actionscript ou même du java (enfin bref, rien que des trucs pas du tout répandus dans le web...;-) ), ne pas avoir à prendre de nouvelles habitudes avec une syntaxe trés (trop?) différente ça peut quand même, peut-être, aider à adopter le nouveau langage. non?
Bon d'accord, j'avoue, les mot-clés m'ont traumatisé depuis les cours forcés de visual basic, ahahaha !
Sinon question aux utilisateurs de Rails pour satisfaire ma curiosité... si on ne veut pas faire d'activeRecord mais plutôt du DAO... gérable avec Rails ou c'est hors-cadre ?
@+!-
[^]Re: Concours de b.....
Posté par Yusei () le 11/12/2007 à 22:36. (lien). Évalué à 2.Je ne sais pas ce qu'est DAO, mais ActiveRecord n'est qu'un composant indépendant des autres. On peut utiliser ActiveRecord hors de Rails, ou bien des modèles n'héritant pas d'ActiveRecord dans Rails. Rien ne t'empêche de coder tes modèles comme tu l'entends, le reste du framework ne s'en souciera pas. Tu perdras juste quelques facilités au niveau de la création et de la modifiation de tes modèles via des formulaires.
En implémentant les bonnes méthodes dans tes modèles, tu récupères ces facilités sans utiliser ActiveRecord, mais c'est peut-être un peu plus pénible.-
[^]Re: Concours de b.....
Posté par desfrenes (page perso, ) le 11/12/2007 à 22:46. (lien). Évalué à 2.En gros, est-ce qu'on peut ne pas faire comme ça : http://martinfowler.com/eaaCatalog/activeRecord.html
mais plutôt faire comme ça : http://martinfowler.com/eaaCatalog/dataMapper.html
J'imagine que oui, mais en réalité je me demande jusqu'à quel point ça peut retirer de l'intérêt au framework. La question cachée c'est, à part l'activerecord les doigts dans le nez, qu'est-ce qui déchire sa race dans Rails ? :-)-
[^]Re: Concours de b.....
Posté par Yusei () le 11/12/2007 à 23:05. (lien). Évalué à 7.Je vais répondre séparément aux deux questions.
D'abord, est-ce qu'on peut ?
Dans une certaine mesure, ActiveRecord permet déjà tout ça, mais peut-être pas de la manière la plus élégante qui soit. C'est à dire qu'il est conçu pour te permettre d'utiliser une BDD qui existe déjà, si tu ne peux pas la créer en respectant les conventions qu'il aime bien.
Après, si tu atteinds vraiment les limites de ce qu'AR permet, ou bien si ça devient vraiment trop porc, tu peux coder ton propre truc pour faire ça. Deux possibilités: soit tu le codes comme tu veux, sans te préoccuper de Rails, et tu perdras quelques aides fournies par Rails dans la suite, soit tu prends soin de faire les choses comme Rails apprécie.
Si tu veux conserver tout ce que permet Rails, en gros tu vas avoir besoin de réimplémenter à ta sauce les méthodes d'AR. Du moment qu'elles sont nommées pareil, ça va fonctionner. En particulier, si tes modèles possèdent des méthodes "save", "update_attributes", "delete" et "find", tu couvres la plupart des cas.
Ensuite, quel intérêt dans Rails à part AR ?
Déjà, tu as un framework MVC tout prêt, c'est un début. Si aucun de tes modèles n'hérite d'ActiveRecord, ça ne t'empêche pas de les utiliser, et ça fonctionne très bien. Pouvoir coder du web en autre chose que PHP, pour moi, c'est déjà un plus.
Le framework, en plus d'AR, est composé d'ActionController, ActionView, et quelques trucs mineurs (ActionMailer...).
Si tu combines AC et AV, tu vas disposer:
- d'un moteur de templates pour générer du XHTML, XML, Javascript, avec du code ruby dedans, un peu à la PHP
- d'un autre moyen pour générer des documents XML, sous forme arborescente cette fois
- des outils nécessaires pour que tu puisses développer ta propre gestion des vues qui ne sont pas couvertes par les cas précédents
- d'une gestion très simple des urls "jolies", c'est à dire qu'au lieu d'avoir catalogue.php?action=voir&id=3, tu vas avoir http://hote/catalogue/voir/3
- d'un système de vues partielles ou de composants, qui te permettent d'éviter de dupliquer ton code de présentation
- de plein d'outils tout faits pour intégrer de l'ajax
- de plusieurs systèmes de caches, chacun adapté à différents types d'applications (selon que tes pages sont plus ou moins dynamiques)
J'en oublie certainement :) En plus de ça, tu as un système de plugins vraiment bien fait. Tellement bien fait que tu te retrouves parfois à faire toi-même un plugin pour ta propre application, parce que ça rend le code vraiment plus élégant de faire comme ça. Tu as également un framework de tests qui est très élaboré. Plus un profiler, un débugger, etc. qui te permettent d'interrompre l'exécution de ton programme et d'aller l'inspecter, puis de reprendre. C'est très classique pour un développeur C ou Java, mais je n'ai aucune idée de comment on peut faire ça en PHP, par exemple.-
[^]Re: Concours de b.....
Posté par Yusei () le 11/12/2007 à 23:17. (lien). Évalué à 2.Il y a peut-être un truc qui n'est pas clair dans ce que je dis au début. La raison pour laquelle on peut remplacer ActiveRecord par autre chose assez simplement, c'est que Ruby utilise le duck typing: si ça ressemble à un canard, et que ça fait kwak comme un canard, alors c'est un canard.
Donc si ton modèle ressemble à un modèle ActiveRecord, tu peux l'utiliser à la place d'un modèle ActiveRecord, n'importe où. Ressembler, en Ruby, ça veut dire répondre aux mêmes méthodes (de la même manière, c'est à dire en prenant les mêmes paramètres et en renvoyant le même type de valeur).
Comme le code est assez bien découpé, le nombre de méthodes auxquelles un objet doit répondre pour ressembler à un objet AR est relativement réduit. C'est pour ça qu'il doit être assez facile d'implémenter un autre système pour avoir des données persistantes. Tu as besoin d'avoir de quoi enregistrer, lire, modifier, obenir la liste des attributs, éventuellement leurs types, et c'est à peu près tout.
(Mais, peut-être faut-il encore le préciser, dans de nombreux cas tu n'as même pas besoin que tes modèles ressemblent à des modèles AR)-
[^]Re: Concours de b.....
Posté par Ummon () le 11/12/2007 à 23:25. (lien). Évalué à 3.(HS)
Personnellement je préfère les interfaces (au sens Java/C#) au duck typing : si l'empreinte génétique est celle d'un canard alors c'est un canard, c'est quand même plus rigoureux.-
[+] [^]Re: Concours de b.....
Posté par baud123 (Jabber id, page perso, ) le 12/12/2007 à 10:32. (lien). Évalué à -1.pan ! pan !
~~> [ ] :D
-
[^]Re: Concours de b.....
Posté par Yusei () le 12/12/2007 à 11:00. (lien). Évalué à 5.C'est plus rigoureux, mais ça t'oblige à recopier tout le génome du canard dans ton mutant, même les bouts dont tu n'as pas besoin. Avec le duck typing, tu n'as besoin d'implémenter que les méthodes que tu utilises.
En particulier, si tu as seulement besoin que ton "canard" flotte, tu n'as pas besoin d'implémenter le cancannement. Et donc, tu peux faire:
class Sorcière
def flotte
...
end
end
Et ensuite utiliser ta sorcière comme un canard dans certains cas, malgré le fait qu'elle ne fasse pas "coin".
L'idéal serait de pouvoir faire les deux, et de pouvoir spécifier dans la signature de ta méthode que tu veux un objet répondant à un ensemble de méthodes. Je crois me souvenir avoir vu quelque chose de semblable dans le système d'objets d'OCaml. Le type des objets était représenté par la liste de leurs méthodes, si je ne me trompe pas.-
[^]Re: Concours de b.....
Posté par Guillaume Rossignol () le 12/12/2007 à 17:17. (lien). Évalué à 2.En fait, on veux surtout savoir si la sorcière pèse le même poids qu'un canard...
=> []-
[^]Re: Concours de b.....
-
-
-
-
-
[^]Re: Concours de b.....
Posté par desfrenes (page perso, ) le 11/12/2007 à 23:26. (lien). Évalué à 1.Bon... et bien à priori à peu prés les mêmes possibilités, à peu prés les mêmes avantages et à peu prés les mêmes problèmes que tous les frameworks web alors ;-)
- d'un moteur de templates -> vu partout
- d'un autre moyen pour générer des documents XML -> je ne vois pas précisément ce que tu veux dire mais bon... ça doit se trouver...
- d'une gestion très simple des urls "jolies" -> vu partout
- d'un système de vues partielles ou de composants-> pas nouveau
- de plein d'outils tout faits pour intégrer de l'ajax-> houlà!!! surtout pas, non merci, j'ai déjà tout ce qu'il me faut :-)
- de plusieurs systèmes de caches-> vu ailleurs
- profiler, un débugger -> vu ailleurs
L'intérêt, le pourquoi du buzz, doit être ailleurs, peut-être dans la façon dont tout ça travaille de concert, peut-être dans même dans Ruby. Dommage que je ne dispose pas d'assez de temps en ce moment pour le découvrir par moi-même.-
[^]Re: Concours de b.....
Posté par Bruno Michel (page perso, ) le 12/12/2007 à 00:08. (lien). Évalué à 5.A mon avis, la période du buzz autour de rails est passée. Rails a été le premier à proposer pas mal de choses qui ont été maintenant reprises dans la plupart des frameworks MVC actuels.
J'aurais tendance à penser que Rails a toujours un coup d'avance sur les autres frameworks. Etant parti plus tôt, il est le premier à arriver à maturité (d'après ce que j'ai entendu, les frameworks PHP, ce n'est pas encore cela, pour les autres je ne sais pas). Il possède également une communauté plus importante que les autres frameworks, ce qui lui permet également d'avoir un grand nombre de plugins (cf [http://agilewebdevelopment.com/plugins/list]).
J'ai également l'impression que Rails est toujours le leader, même si c'est nettement moins marqué que par le passé. Par exemple, Rails a tranché pour REST (contre SOAP), et je ne serais pas surpris que cela devienne la norme pour les frameworks l'année prochaine. Sur les tests unitaires, Rspec [http://rspec.rubyforge.org/] me semble également très en avance sur ce que l'on peut trouver ailleurs.
Enfin, je préfère largement Ruby à PHP, mais c'est un choix tout personnel :)-
[^]Re: Concours de b.....
Posté par IsNotGood () le 12/12/2007 à 04:12. (lien). Évalué à 1.> J'aurais tendance à penser que Rails a toujours un coup d'avance sur les autres frameworks.
Je connais peu Java, mais le peu que j'ai vu de java/jboss est impressionnant.
Au passage RH a libérer du code (GPLv2 après avoir acheté à Exadel qui l'avait mis en proprio) :
http://www.redhat.com/developer_studio/?intcmp=70160000000HE(...)
http://www.jboss.com/products/devstudio
http://jboss.com/partners/exadel
Ce qui est "amusant", c'est que RH dit vendre beaucoup plus DevStudio pour Windows que pour RHEL. Si ça limite l'essor de .net et C# c'est tant mieux.
-
-
[^]Re: Concours de b.....
Posté par Yusei () le 12/12/2007 à 07:43. (lien). Évalué à 2.Je n'avais pas pour but de faire un post décrivant pourquoi Rails est mieux que les autres, il me demandait juste quels étaient les intérêts de Rails en dehors d'ActiveRecord. Effectivement, tout ce qu'on peut faire avec Rails, on peut le faire avec Java et un framework web. L'argument de vente de Rails, c'est qu'on le fera plus vite et pour moins cher (ie. moins de programmeurs).
Après, plus spécifiquement, parmis les avantages propres à Rails, le langage Ruby est un élément de réponse, et après on trouve la philosophie de conception (convention plutôt que configuration, etc.)
-
-
-
[^]Re: Concours de b.....
Posté par Bruno Michel (page perso, ) le 11/12/2007 à 23:48. (lien). Évalué à 2.J'ai un peu de mal à voir à quoi correspond le design pattern data mapper, mais il existe d'autres ORM en Ruby en dehors d'Active Record. Citons par exemple DataMapper [http://datamapper.org/] et Sequel [http://sequel.rubyforge.org/].
D'autre part, quitte à ne pas utiliser Active Record, ca peut valoir le coup d'essayer d'autres frameworks en Ruby comme Merb [http://merbivore.com/].-
[^]Re: Concours de b.....
Posté par desfrenes (page perso, ) le 11/12/2007 à 23:53. (lien). Évalué à 1.Sur le papier, ça me plait déjà mieux :-)
"Unlike Rails, Merb is ORM-agnostic, JavaScript library agnostic, and template language agnostic, preferring plugins that add in support for a particular feature rather than trying to produce a monolithic library with everything in the core."-
[^]Re: Concours de b.....
Posté par gallenza () le 12/12/2007 à 15:01. (lien). Évalué à 2.Sur la papier seulement alors !
C'est comme du côté des frameworks python : Django a tout intégré, et Pylons récupère des bouts d'un peu partout.
Le problème c'est que ce qui fait la valeur ajoutée/utilisabilité/performance d'un framework, c'est bien l'intégration, qui fait que tout se goupille bien parce que c'est fait pour.
Au final y'a pas photo...
-
-
[^]Re: Concours de b.....
Posté par ccomb (Jabber id, page perso, ) le 13/12/2007 à 17:14. (lien). Évalué à 1.Juste en passant, il existe un bon moyen de dégager la couche ORM, c'est d'utiliser une base de donnée objet... (il n'y en a pas qu'une)
-
[+] [^]Re: Concours de b.....
Posté par TheGuit (page perso, ) le 13/12/2007 à 18:46. (lien). Évalué à -1.Ouais mais elle sont toute pourris ^^
--
plus tu cours moins vite ..... mais ca fatigue quand meme-
[^]Re: Concours de b.....
Posté par ccomb (Jabber id, page perso, ) le 14/12/2007 à 01:56. (lien). Évalué à 2.Oh mais oui alors, c'est vrai, j'y avais pas pensé, elles sont pourries. :)
mmmh bien. ok.
-
-
-
-
-
-
-
-
-
[^]Re: Célèbre ?
Posté par zerchauve () le 11/12/2007 à 21:01. (lien). Évalué à 4.faut que tu arretes le cirage quand meme hein :)
ca fait un peu trop fanboy, quand tu fais une ressucée de tous les posts de DHH, de 37signals and co "evolution not revolution", blablabla
la communauté rails n'est pas du tout ENORME. Elle est certes importante, mais c'est vraiment peau de zob par rapport au monde Java quand meme (les frameworks toussa) etc..
Quant au "plus celebre" faut ptetre se calmer. Le plus hype c'est sur. Le plus celebre je sais pas hein, encore une fois y a quand meme deux trois trucs en java qui trainent... et pas beaucoup de sites en Ruby dans les 500/1000 plus gros du monde.
Mais j'avoue que le buzz est monstrueux, et que l'outil est super intéressant, surtout pour des applis d'entreprise (pas si sur que ca que ca percera pour des sites communautaires importants avec grosse charge et tout et tout... oui je sais pour twitter et je trouve quand me que twitter ca rame sa maman)
Et je précise que je ne fais QUE du Rails, depuis un moment deja...--
-- 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:05. (lien). Évalué à 0.Je n'est effectivement pas osé parler des Framework Java, qui sont a mon avis beaucoup plus connu, et beaucoup plus utilisé de par le monde.
--
plus tu cours moins vite ..... mais ca fatigue quand meme
-
[^]Re: Célèbre ?
Posté par Slainer (Jabber id, page perso, ) le 11/12/2007 à 21:27. (lien). Évalué à 2.Quand j'ai dis "plus célèbre", je parlais de frameworks dits "Web 2" (Symfony, CakePHP, Django, etc), pas de langage, ni de framework MVC ou "enterprise", je ne doute pas qu'on trouve plus de sites sur Java que sur sur Rails.
-
-
[^]Re: Célèbre ?
Posté par IsNotGood () le 11/12/2007 à 22:14. (lien). Évalué à 1.> sûrement tu n'es pas développeur
Ratais, je suis développeur (quasi exclusivement C++ actuellement).
> oui, Rails est - devenu en quelques années - le plus célèbre des frameworks Web
Ben les sites faient en ruby sont rares (ou alors ce n'est pas visible et je ne l'ai pas remarqué).
Qu'il y a-t-il comme fournisseur qui propose du ruby ?
Free ?
Que Ruby/ROR soit "hype", qu'il est une progression "fulgurante", etc. OK.
Mais célèbre...
Où peut-être tu veux dire "célèbre" dans une communauté ?
Les développeurs web 2.0 ?
> 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.
Je répète, je ne mets pas en cause Ruby on Rails. Mais merci pour ton avis. Merci à linuxfr de popularisé plus largement Ruby et Ruby on Rails. Il semble avoir des innovations et donc il le mérite très probablement (je suis mal placé pour en juger).
-
Herbergement
Un hebergeur "gratuit" qui supporte le ruby et encore mieux qui fournisse RoR ?
-
[^]Re: Herbergement
-
[^]Re: Herbergement
-
[^]Re: Herbergement
Posté par baud123 (Jabber id, page perso, ) le 12/12/2007 à 10:37. (lien). Évalué à 3.y aurait-il des retours d'expérience sur :
- la tenue à la charge pour des sites sur serveur mutualisés ? (ou des métriques : tel serveur tient tant de sites avec chacun tant de visiteurs...)
- la mise en oeuvre de sécurité entre sites sur serveur mutualisé ?
ce qui permettrait de répondre objectivement à http://faq.tuxfamily.org/WebArea/Fr#Pourquoi_TuxFamily_ne_fo(...) (déjà pour Ruby)
-
Un Troll...
... de temps en temps ça ne fait pas de mal.
Personnellement j'ai toujours aimé le Ruby pour pleins de raisons (depuis bien avant Rails)... mais une chose qui me fait un peu peur c'est la lenteur du bouzin.
Petite comparaison : Erlyweb / Rails :
http://yarivsblog.com/articles/2007/12/09/erlyweb-vs-ruby-on(...)
(j'aime aussi l'Erlang)
(oui je sais, 1: le test n'est pas significatif, 2: ya pas que les performances brutes qui comptent, 3: etc..)
Bon je me taille avant que tout pète ->[]
-
[^]Re: Un Troll...
Posté par Yusei () le 11/12/2007 à 22:32. (lien). Évalué à 2.Sans aller jusqu'à nier que Rails puisse être lent, les tests me paraissent douteux, et il faudrait avoir des détails sur la configuration mise en place. On ne sait même pas si mongrel est lancé en environnement "développement" ou "production", quels types de caches sont activés, si plusieurs processes sont lancés ou si c'est un seul process qui gère les requêtes en série...
Si on ne fait aucun réglage particulier et qu'on reste en mode developpement, alors tout le framework est lancé/interprété à chaque requête. Forcément, c'est un peu lourd. Quand on passe en mode production, une énorme partie du code est pré-chargée, ce qui accélère énormément les choses. Seules les vues sont interprétées à chaque requête, sauf erreur.
Ensuite, dès qu'on a plusieurs mongrels et un apache pour répartir les requêtes, le débit augmente tant qu'on a de la RAM pour lancer des mongrels.
Enfin, selon le type de contenu, on peut mettre en place très facilement des systèmes de caches plus ou moins efficaces. Pour le type de contenu du bench, on devrait obtenir un débit identique à celui d'apache sur des pages fixes, une fois que chaque page a été mise en cache. Mais bon, je conçois que le but du bench n'ait pas été de mesure les performances du système de cache.-
[^]Re: Un Troll...
Posté par Erwan (page perso, ) le 12/12/2007 à 06:42. (lien). Évalué à 3.Je connais bien l'un des deux devs de Twitter (je connais les deux en fait) et le principal problème de Rails c'est que quand tu fais un gros site web, d'une part le rendre "scalable" demande plus de boulot, et d'autre part tu dois ajouter des serveurs plus souvent qu'un site en PHP (ou en Ruby "pur").
Par exemple, (et là ça devient un peu polémique parce que Hansson affirme qu'ils ont tort et auraient pu grossir en gardant ActiveRecords) ils ont du arrêter d'utiliser ActiveRecords pour avoir une séparation claire entre un site web "stateless" et la couche de données. En gros, perdant un des principaux avantages de Rails.
-
-
[^]Re: Un Troll...
Posté par Dring FirebirdVsMySql () le 11/12/2007 à 22:37. (lien). Évalué à 1.Je viens de lire le comparatif, et je suis attéré par la syntaxe en Erlang. Je suis le seul à penser que taper :
<<"ma chaine">>
...plutôt que...
"machaine"
...ça dénote déjà un manque d'esprit pratique ? Comment peut-on imaginer une syntaxe ou taper une chaîne de caractères exige déjà 6 caractères de contrôle là où la plupart des langages, y compris les plus vieux, n'en demandent que 2 ?
Bon, je connais pas Erlang et ses avantages, mais après avoir lu ça j'ai pas trop envie de creuser. J'ai tort ?--
Non, rien.-
[^]Re: Un Troll...
Posté par Ummon () le 11/12/2007 à 22:59. (lien). Évalué à 1."ma chaine" existe et est effectivement un string() représenté sous la forme d'une liste d'entiers (oui je sais, gaspillage, toussa).
<<"ma chaine">> est une syntaxe binaire ou chaque caractère est représenté par un octet (sauf codage genre utf-8).
Personnellement je n'ai jamais utilisé la deuxième solution, je pense qu'il l'a utilisé pour ces meilleures performances.
-
[^]Re: Un Troll...
Posté par Ummon () le 11/12/2007 à 23:05. (lien). Évalué à 2.Ah, et j'oublié... oui, tu as tord. Erlang est un langage très intéressant !
http://fr.wikipedia.org/wiki/Erlang_%28langage%29
et
http://www.framasoft.net/article2089.html-
[^]Re: Un Troll...
Posté par Dring FirebirdVsMySql () le 12/12/2007 à 14:14. (lien). Évalué à 1.Sache jeune padawan que je n'aurais jamais tord. Avoir tort me suffira largement ;-)
Effectivement, la page sur Wikipédia est très enrichissante, mais ça n'empêchera pas la syntaxe de me rebuter. Après, j'ai peu l'occasion de faire du traitement en parallèle, donc je survivrais.--
Non, rien.-
[^]Re: Un Troll...
Posté par baud123 (Jabber id, page perso, ) le 12/12/2007 à 15:06. (lien). Évalué à 3.et Thor tue, hum ah non spa ça ;-)
-
[^]Re: Un Troll...
Posté par Ummon () le 12/12/2007 à 15:57. (lien). Évalué à 1.Oui pardon pour la faute (on peut pas éditer... toussa..)
Par contre je trouve l'excuse de la syntaxe pour ne pas aller voir plus loin plutôt mauvaise. Je suis d'accord que c'est un effort à fournir au début mais une fois qu'on a un peu tout vu ça n'est plus un problème majeur sans compter que la syntaxe d'Erlang est plutôt facile d'après moi.
-
-
-
[^]Re: Un Troll...
Posté par reno () le 12/12/2007 à 06:51. (lien). Évalué à 3.Erlang est un vieux langage.. C'est pour ça que sa syntaxe est très "différente".
L'avantage de Erlang c'est sa 'scalabilité' (aucune idée comment traduire ça correctement en Français): avec Erlang on peut exploiter des muti-processeurs "efficacement" dans le sens ou N processeur peut impliquer N fois plus rapide en Erlang (ce qui est *très* interressant vu l'évolution actuelle des CPUs) mais attention:
- sur un mono-processeur Erlang est beaucoup plus lent que le C donc même si c'est une application "Erlang-friendly" il faudra avoir 2-3 CPU pour atteindre les mêmes perf que le C sur un seul CPU!
- toutes les applications ne fonctionnent pas bien en multi-processeurs: certains ont leurs performances qui restent faible même quand on ajoute des processeurs..-
[^]Re: Un Troll...
Posté par Ummon () le 12/12/2007 à 08:35. (lien). Évalué à 3.Erlang est peut-être un vieux langage mais il évolue toujours actuellement (la R12 est sortie il y a une semaine). Juste en passant le C date du début des années 70 alors qu'il est encore très utilisé dans certains domaines, Linux par exemple. mais justement il y a des domaines où d'autres langages s'en sortent mieux comme par exemple la programmation répartie/parallèle dans lequel Erlang excelle et pour lequel il a été conçu.
Erlang a des objectifs précis : "tolérance à la faute" et "monté en charge", Il ne se veut pas comme un remplaçant du C.
Pour donné un exemple "grand public", ejabberd est un serveur XMPP(Jabber) réalisé en Erlang et qui s'en sort pas trop mal : http://www.jabber.org/admin/jsc/-
[^]Re: Un Troll...
Posté par reno () le 12/12/2007 à 10:52. (lien). Évalué à 2.>>Erlang est peut-être un vieux langage mais il évolue toujours actuellement (la R12 est sortie il y a une semaine).<<
Sais-tu ce qu'apporte quoi la R12?
Il y a eu une version avant qui était "majeur": elle apportait le support du SMP a Erlang de manière transparente: avant il fallait le programmer pour utiliser plusieurs CPU, maintenant les processus peuvent être sur des CPUs different de maniere transparente (je crois).-
[^]Re: Un Troll...
Posté par Ummon () le 12/12/2007 à 11:01. (lien). Évalué à 1.Ya tout ici : http://erlang.org/doc/highlights.html
Notamment, par exemple, un module "Array" ( http://erlang.org/doc/man/array.html ).
-
-
-
[^]Re: Un Troll...
Posté par Sylvain Sauvage () le 12/12/2007 à 10:08. (lien). Évalué à 2.'scalabilité' (aucune idée comment traduire ça correctement en Français)
Extensibilité, capacité de monter en charge…-
[^]Re: Un Troll...
Posté par baud123 (Jabber id, page perso, ) le 12/12/2007 à 13:03. (lien). Évalué à 2.passage à l'échelle, tenue en charge, linéarité des performances...
-
-
-
mise à jour?
Je suis pas spécialiste de Rails, j'en ai fait un moment mais dû stopper pour d'autres activités or, j'aimerais m'y replonger à présent. Les bouquins que j'ai datent maintenant. A votre avis, qu'est-ce que cette version implique comme temps/ressources de réapprentissage?
euh... oui merci d'avance :)
"Le logiciel libre c'est comme le sexe : c'est souvent poilu." (Lanus Tordable)
-
[^]Re: mise à jour?
Posté par Slainer (Jabber id, page perso, ) le 12/12/2007 à 07:41. (lien). Évalué à 2.Les bouquins écrits pour Rails 1.2 comme Agile Web Development with Rails 2nd Edition suffisent.
Comme dit plusieurs fois du code qui fonctionne sur Rails > 1.2.3 fonctionne avec Rails 2.0 sans modification. Si des parties du code utilisent des fonctions de Rails qui ont été externalisées il suffit d'installer ces plugins dans Rails 2.
Au niveau des nouvelles conventions dans Rails 2 elles ne sont pas nombreuses (les vues à appeler dans le style : vue.minetype.render plutôt que vue.render (edit.html.haml plutôt que edit.haml))...-
[^]Re: mise à jour?
Posté par Lanus Tordable () le 12/12/2007 à 19:40. (lien). Évalué à 1.Merci à toi!
--
"Le logiciel libre c'est comme le sexe : c'est souvent poilu." (Lanus Tordable)
-
ROR et ses limites
La version précédente de RoR avait un problème rédhibitoire, le serveur était mono threadé. Donc, pour bosser et faire une démo qui impressionne, ça passe, sinon, ça devient de suite plus compliqué. Il faut lancer tout un tas de serveur, et utiliser un serveur web comme lighttpd qui fait du roundrobin sur tout ça. Du cluster sur une seul machine. J'ai peut être pas les yeux en face des trous, mais je n'ai pas vu si la version 2 corrige ce problème.
Autre problème, RoR est une application, sans possibilités de contraindre simplement l'utilisation mémoire ou le temps maxi pour exécuter une page, ce qui le rends inutilisable sur un hébergement mutualisé dans le genre de Free.
Autre fantasme, la migration d'un site en PHP qui va bien mais pas joli, vers du RoR qui rulez. Il y a eu récemment un post sur SlashDot sur ce sujet. Le type avait embauché un des dev de RoR pour faire la migration, et au bout de 2 ans, ils ont jeté l'éponge. RoR est un logiciel de prototypage, très bien pour créer from scratch un site, et surtout pas quelque chose vers quoi migrer.
La gestion des sessions en Cookie, comme évolution me parait tout simplement risible. La taille des cookie est limité, et les logiciels civilisé savent gerer les sessions en RAM, sauf si ils sont en cluster ou il faut passer à quelque chose de de suite nettement plus compliqué. PHP a le bon de laisser l'admin s'occuper du choix, sans faire passer une astuce pour une évolution.
La qualité indéniable de RoR est d'être un aiguillon pour tous les autres, il n'y a qu'a voir l'arrivé de Grail, PHPCake ou Django. Un serveur peut être simple, et le volume des fichiers de configurations ne doit pas dépasser le volume de code. Le MVC, l'ORM, l'intégration d'un framework JS, un outil de build, le REST et JSON font maintenant parti des ingrédients d'un bon framework web.
-
[^]Re: ROR et ses limites
Posté par EppO (page perso, ) le 12/12/2007 à 10:03. (lien). Évalué à 1.Le passage des sessions en cookie n'est pas une évolution mais le nouveau réglage "par défaut". On peut toujours avoir le choix de stocker la session sur le filesystem (PStore), en base (avec activerecord, sur memcache, drb, ...).
Quand au serveur fourni, je ne le considère pas pour un usage en production, il est évident qu'il est très pratique pour du développement mais ca ne vaut pas un apache ou même mieux un lighttpd bien configuré avec un cluster de moteur FastCGI.-
[^]Re: ROR et ses limites
Posté par Thomas () le 14/12/2007 à 13:41. (lien). Évalué à 2.Le serveur fourni avec est uniquement pour le développement. Il a été conçu pour le développement. Et partout dans la doc il est répété qu'il ne doit être utilisé que pour ça. Donc les reproches basés sur la lenteur de Webrick n'ont pas lieu d'être.
-
Django
Intéressante cette page, pour qui connait peu Rails, comme moi.
Je voulais savoir quelles sont les grosses différences par rapport à Django. J'ai développé plusieurs sites avec et je l'apprécie beaucoup, le trouvant rapide et efficace. J'ai survolé Rails en testant guère plus loin que quelques hello world. Je ne demande pas qui est le mieux, mon lance-troll est éteind; juste quels sont les avantages majeurs de l'un et l'autre. Il y a des fonctionnalités très alléchantes dans Rails qu'il n'y a pas dans Django, je pense à ActiveRdf [ http://www.activerdf.org/ ] notamment qui me fait envie.
-
[^]Re: Django
Posté par Dreammm () le 13/12/2007 à 08:44. (lien). Évalué à 4.J'ai le profil exactement inverse de toi, je mange du rails tous les jours, et j'ai survolé Django.
Une chose très intéressante dans Django et qui n'existe pas dans rails, c'est l'approche composante : dans Django, tu peux utiliser des composants pour bâtir ton application, et chaque composant à un espace MVC séparé (si j'ai bien compris). Dans rails, tu as un ensemble MVC mis en commun, et le rajout d'un plugin vient taper là dedans.
Cette page a été générée par Templeet en 0.4722s (dont 0.0352 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.