Par contre, Rails fait beaucoup de choses en plus, entre autres analyser la base de données pour en déduire la structure de ses objets, et charger dynamiquement des extensions à la lib du langage, ce qui fait que sur un serveur qui lance un process à chaque requête, on perd un temps monstre au chargement.
Personnellement, je ne trouve pas que les scripts en ligne de commande de RoR soient innovants.
Il n'y a pas grand chose de Rails qui soit réellement innovant: les scripts qui génèrent du code, la possibilité de redéfinir le code dynamiquement, l'analyse de la base de données pour construire les objets, les langages de templates, l'intégration du système de tests, le système de modification incrémentable de la base, tout ça existe déjà ailleurs sous différentes formes.
Ce qui fait le succès de Rails, c'est surtout que tout est packagé autour d'un langage qui est expressif sans être dépaysant, et le fait que des conventions bien choisies évitent de devoir se coltiner avec ce dont on n'a pas besoin.
La modification dynamique de code, par exemple, ça existait depuis au moins aussi longtemps que Lisp, mais Lisp est plus difficile d'accès quand on vient de langages comme Java ou PHP.
Un vrai framework offre avant tout un cadre de conception, une manière de développer, une façon d'organiser son code, ses fichiers : tu ne met pas tes classes n'importe où
Ruby offre un cadre de conception, une manière de développer, une façon d'organiser son code, et tu ne mets pas tes classes n'importe où. Un exemple ?
require 'toto/titi'
Pourquoi on n'a pas donné un chemin sur le système de fichiers ? Parce qu'on ne met pas ses classes n'importe où, il y a une liste de chemins d'includes, qui sont parcourus dans l'ordre pour trouver tes classes. Les fonctions, les objets, les namespaces, les conventions de nommage, qu'est-ce qui fait partie du langage et qu'est ce qui fait partie du framework ?
Si tu n'est pas convaincu quand je dis qu'un langage+une bibliothèque forment un framework, essaye de prendre le problème à l'envers, et demande toi si un framework est un langage ou pas. Quand tu prends un bout de code de Rails:
class Blabla < ActiveRecord::Base
has_many :clients
validates_uniqueness_of :name
accessor :toto
end
Ces instructions sont des ajouts du framework. Sauf la dernière qui est une instruction de Ruby. Quelle est la différence avec des mots clés du langage, ou avec une bibliothèque de fonctions ? Qu'est-ce qui empêcherait de faire un compilateur du langage définir par Rails vers un autre langage ? Du point de vue de l'utilisateur, Rails définit un langage avec un peu plus d'instructions qu'en Ruby (d'ailleurs Rails modifie certains objets de la lib standard pour leur rajouter des fonctions), un peu plus de conventions, mais quoi d'autre ?
Je ne dis pas que PHP, Ruby et Rails ont la même puissance d'expression, mais faire une distinction entre langage et framework est arbitraire.
Et surtout, un framework est trés souvent orienté vers un type d'application précis.
Difficile de tracer une ligne de démarcation nette entre framework et langage. PHP est certes un langage, mais généralement quand on parle de PHP on parle du langage et de sa bibliothèque standard, ce qui en fait... un framework.
En prenant le problème dans l'autre sens, Rails définit un langage de programmation en rajoutant des "mots" et des "concepts" au langage Ruby.
Utiliser les lignes de code comme mesure, c'est biaisé: il faut généralement plus de lignes en PHP qu'en Ruby pour exprimer la même chose. C'est encore plus accentué avec Rails, qui repose sur tout un tas de conventions qui évitent d'écrire du code.
Python c'est pas le language le plus orienté web que je connaisse.
Ruby n'est pas franchement plus orienté web que Python (à part peut-être la présence depuis longtemps d'erb, qui permet de mettre du ruby dans du HTML, à la PHP). Il ne faudrait pas que le succès de Rails, qui n'est qu'un framework, fasse penser que Ruby n'est qu'un langage pour le Web.
C'est plutôt le format des écrans qui n'est pas très pertinents, à mon avis.
Ou alors c'est le fait de mettre son navigateur en plein écran sur un moniteur 16/9e, qui n'est pas très pertinent.
Parce que moi mon écran large du bureau, je l'aime beaucoup. Il me permet de lire des PDF en affichant deux pages continues à l'écran, d'avoir deux emacs de code l'un à côté de l'autre...
Alors moi je pratique beaucoup Neverputt, qui a l'avantage de pouvoir se jouer même quand il pleut/neige. Par contre il faut un driver un peu mieux que Vesa.
Tétrapilectomie: les ordinateurs ne savent pas plus résoudre les échecs que le Go: l'espace de possibilités et trop grand dans les deux cas (il est quand même beaucoup plus grand dans le cas du Go). Par contre, les ordinateurs sont mauvais au Go, et au niveau des meilleurs humains aux échecs.
Concernant le Zen, j'avoue avoir du mal à voir le lien avec la geekitude, même si j'ai aussi rencontré une certaine proportion de geeks intéressés. Peut-être que cela vient de la "mode orientaliste" générale. En tout cas le Zen me semble être l'opposé de la pensée logique et mécaniste dont on a besoin pour être un bon computer geek.
Cela dit, je suis assez attiré par des systèmes comme Mac OS X malgré le fait qu'il soient proprio. Le système est intéressant, les concepts de l'interface graphique sont bons, d'ailleurs tout le monde s'en inspire largement.
C'est ce que j'entends dire partout, alors j'ai fini par le croire, sans avoir jamais essayé Mac OS. Mais d'un autre côté, je suis persuadé que l'ergonomie d'ion3 me manquerait, si un jour on m'obligeait à y renoncer.
On n'est pas *enfermé* dans le proprio non plus. Si on a le choix de ne pas utilise l'OS proprio mais que l'on a aussi une alternative ça me va.
Le problème, c'est que l'existence de l'alternative dépend fortement du nombre de ses utilisateurs. Si GNU/Linux reste cantonné, au mieux, au dual/boot sur les macs, il ne faudra pas s'étonner de ne pas avoir apparaître de drivers pour le matériel des macs, ou bien de devoir les attendres un ou deux ans.
Parce que bon, il ne faut pas se faire d'illusions... s'ils ont le choix au boot entre un système où tout est géré et un autre où quelques trucs manquent, la plupart des gens choisiront la facilité.
Le truc c'était surtout de souligner qu'il fallait pas idéaliser les choses du genre "le libre c'est génial ya que des avantages, le proprio c'est nul il y a que des inconvénients"
D'un autre côté, avec le proprio, tu banques aussi. Ce n'est pas un défaut du libre, même si je t'accorde qu'on risque de payer un peu plus cher dans le libre, parce que les économies d'échelle sont plus réduites.
Je ne crois pas qu'on puisse empêcher les "perdants" d'un vote de s'exclamer "ah, que ça aurait été mieux si nous avions gagné". L'ensemble des possibles non réalisés contient toujours des scénarios plus satisfaisants que la situation réelle.
De là à accuser ses "adversaires" d'avoir pourri le monde, il n'y a qu'un tout petit pas.
- où le parlement européen a au choix
[...]
3) est totalement squizzé comme dans le cas de l'EPLA où les pro-brevets profitent de la faiblesse de l'Union européenne pour faire signer un traité inter-étatique mettant carrément hors jeu le parlement européen.
En survolant l'article, j'ai eu l'impression que le parlement allait voter au sujet de l'EPLA. Or, tu dis qu'ils ont été squizzés ; j'ai raté un épisode ?
on ferait mieux d'apprendre aux enfants à lire/écrire/compter correctement. Parce que tant qu'ils ne savent pas ça, je ne vois pas comment ils peuvent se servir d'un ordinateur...
Il y a des gens qui suggèrent que, justement parce que quand on parle à un ordinateur on doit savoir écrire sans fautes, l'utilisation des ordinateurs pourrait motiver les enfants dans l'apprentissage de l'orthographe et de la grammaire.
Donc quand tu dis compiler une JVM, je comprend donc "avoir une JVM disponible pour cette plate-forme"
On est d'accord. Que ce soit Java ou Python, il faut un interpréteur, mais sur toutes les plateformes où un interpréteur existe, c'est "portable" :)
mais perl, python ne sont pas pour moi des languages de haut niveau, plus de script.
Je n'ai jamais vu personne faire une distinction entre "de haut niveau" et "de scripts". On fait plus souvent une distinction entre langage compilé et langage de scripts, mais même ainsi la séparation est très arbitraire. Dans la catégorie des langages qu'on appelle généralement "de scripts", on trouve quand même Ruby, pour lequel il est difficile de prétendre qu'il est de plus bas niveau que Java.
Note qu'en disant que Java n'était pas "le plus portable", je ne voulais pas le critiquer, simplement souligner qu'on trouve des langages récents, novateurs et libres qui sont au moins aussi portables que Java. Après, à chacun de choisir selon ses goûts, on peut aussi faire du Java en n'utilisant que des outils libres.
(À titre personnel, j'avoue détester ce langage. Mais tout le monde s'en fiche, et ils ont raison.)
Compiler une JVM ?
Tant que ta plate-formes aie une JRE fonctionnelle, il n'y a pas de problème.
Une JVM, c'est un interpréteur pour le bytecode Java. Java tourne sur une plateforme s'il est possible de compiler une JVM sur cette plateforme.
Tu peux remplacer "Java" dans la phrase ci-dessus par n'importe quel langage, que ce soit Python, Ruby, Perl, Lisp... c'est toujours valable. Je ne sais pas sur combien de plateformes on trouve l'interpréteur Python, mais je doute que ce soit moins portable que Java. Déjà, c'est disponible sous Windows, les variantes de Linux et de BSD, MacOS X compris. Le grand succès marketing de Sun, ça a été de faire croire que le concept de machine virtuelle était propre à Java.
Au final, quand tu dis que Java est le plus portable des langages de dernières générations, quelque chose me dit que tu ne le compares qu'à .NET. Il y a même un paquet de langages de haut niveau (et plus novateurs) qui sont compilables, au choix, en natif ou en bytecode Java, et qui sont par conséquent au moins aussi portables que Java. Voir par exemple OCaml, mais ce n'est pas le seul.
Je ne crois pas qu'il parlait d'un programme écrit en C et Python, mais d'un programme écrit en Python, exécuté par un interpréteur codé en C. Pour être portable, tu as besoin de compiler l'interpréteur Python, exactement comme pour Java où tu as besoin de compiler une JVM.
Je vais me faire démolir, mais pour moi MySQL n'est pas un SGBD. La première "fonctionnalité" qu'on demande à un SGBD, c'est de gérer des données et de s'assurer un minimum de leur intégrité. En particulier, quand tu as fait un INSERT et que la requête a marché, tu t'attends à ce que tes données soient dans ta base.
MySQL ne te propose pas cette garantie. Si tes données ne se conforment pas à ce qu'il attend, au lieu de faire échouer la requête, il va essayer de transformer tes données pour les faire rentrer, sans te le dire. En particulier, il va tronquer les chaînes trop longues, et mettre les dates invalides à 0.
Rien qu'à cause de cette raison, je pense que MySQL reste limité aux sites web qui ne traîtent pas de données importantes. Il est utilisé pour des sites importants, mais c'est par flemme d'apprendre autre chose ou par incompétence.
Autant le correcteur d'orthographe peut être utile (pour les fuates de farppe par exemple [...])
Un correcteur grammatical, c'est utile aussi pour les gens qui maîtrisent parfaitement la grammaire: il n'y a rien de plus facile sur un ordinateur que de vouloir changer une phrase en cours de route, mais il est aussi très facile d'oublier de modifier tous les bouts de la phrase pour qu'elle s'adapte à la modification. C'est l'équivalent grammatical d'une faute de frappe: je copiecolle un morceau, je supprime une préposition, mais j'oublie de changer un accord, et paf.
[^] # Re: Ridicule
Posté par Yusei (Mastodon) . En réponse au journal PHP eats rails. Évalué à 1.
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
Par contre, Rails fait beaucoup de choses en plus, entre autres analyser la base de données pour en déduire la structure de ses objets, et charger dynamiquement des extensions à la lib du langage, ce qui fait que sur un serveur qui lance un process à chaque requête, on perd un temps monstre au chargement.
[^] # Re: completement nulle comme étude.
Posté par Yusei (Mastodon) . En réponse au journal PHP eats rails. Évalué à 4.
Il n'y a pas grand chose de Rails qui soit réellement innovant: les scripts qui génèrent du code, la possibilité de redéfinir le code dynamiquement, l'analyse de la base de données pour construire les objets, les langages de templates, l'intégration du système de tests, le système de modification incrémentable de la base, tout ça existe déjà ailleurs sous différentes formes.
Ce qui fait le succès de Rails, c'est surtout que tout est packagé autour d'un langage qui est expressif sans être dépaysant, et le fait que des conventions bien choisies évitent de devoir se coltiner avec ce dont on n'a pas besoin.
La modification dynamique de code, par exemple, ça existait depuis au moins aussi longtemps que Lisp, mais Lisp est plus difficile d'accès quand on vient de langages comme Java ou PHP.
[^] # Re: Lignes de code
Posté par Yusei (Mastodon) . En réponse au journal PHP eats rails. Évalué à 3.
Ruby offre un cadre de conception, une manière de développer, une façon d'organiser son code, et tu ne mets pas tes classes n'importe où. Un exemple ?
require 'toto/titi'
Pourquoi on n'a pas donné un chemin sur le système de fichiers ? Parce qu'on ne met pas ses classes n'importe où, il y a une liste de chemins d'includes, qui sont parcourus dans l'ordre pour trouver tes classes. Les fonctions, les objets, les namespaces, les conventions de nommage, qu'est-ce qui fait partie du langage et qu'est ce qui fait partie du framework ?
Si tu n'est pas convaincu quand je dis qu'un langage+une bibliothèque forment un framework, essaye de prendre le problème à l'envers, et demande toi si un framework est un langage ou pas. Quand tu prends un bout de code de Rails:
class Blabla < ActiveRecord::Base
has_many :clients
validates_uniqueness_of :name
accessor :toto
end
Ces instructions sont des ajouts du framework. Sauf la dernière qui est une instruction de Ruby. Quelle est la différence avec des mots clés du langage, ou avec une bibliothèque de fonctions ? Qu'est-ce qui empêcherait de faire un compilateur du langage définir par Rails vers un autre langage ? Du point de vue de l'utilisateur, Rails définit un langage avec un peu plus d'instructions qu'en Ruby (d'ailleurs Rails modifie certains objets de la lib standard pour leur rajouter des fonctions), un peu plus de conventions, mais quoi d'autre ?
Je ne dis pas que PHP, Ruby et Rails ont la même puissance d'expression, mais faire une distinction entre langage et framework est arbitraire.
C'est aussi le cas de beaucoup de langages.
[^] # Re: Lignes de code
Posté par Yusei (Mastodon) . En réponse au journal PHP eats rails. Évalué à 1.
En prenant le problème dans l'autre sens, Rails définit un langage de programmation en rajoutant des "mots" et des "concepts" au langage Ruby.
# Lignes de code
Posté par Yusei (Mastodon) . En réponse au journal PHP eats rails. Évalué à 6.
[^] # Re: pas grand chose à voir en effet....
Posté par Yusei (Mastodon) . En réponse au journal PHP eats rails. Évalué à 4.
Ruby n'est pas franchement plus orienté web que Python (à part peut-être la présence depuis longtemps d'erb, qui permet de mettre du ruby dans du HTML, à la PHP). Il ne faudrait pas que le succès de Rails, qui n'est qu'un framework, fasse penser que Ruby n'est qu'un langage pour le Web.
[^] # Re: Et le cache ?
Posté par Yusei (Mastodon) . En réponse au journal Web design et bas débit. Évalué à 3.
Ou alors c'est le fait de mettre son navigateur en plein écran sur un moniteur 16/9e, qui n'est pas très pertinent.
Parce que moi mon écran large du bureau, je l'aime beaucoup. Il me permet de lire des PDF en affichant deux pages continues à l'écran, d'avoir deux emacs de code l'un à côté de l'autre...
[^] # Re: Vulnérabilité dans IE7 découverte
Posté par Yusei (Mastodon) . En réponse au journal faites péter les connec Aie_i_7 IS OUT. Évalué à 3.
Ils n'auraient jamais dû passer en open source, ça facilite vraiment trop la tâche des pirates...
[^] # Re: Je casse un tabou
Posté par Yusei (Mastodon) . En réponse au journal Quel sport pratique le geek ??. Évalué à 10.
[^] # Re: Golf
Posté par Yusei (Mastodon) . En réponse au journal Quel sport pratique le geek ??. Évalué à 3.
[^] # Re: Diabolos
Posté par Yusei (Mastodon) . En réponse au journal Quel sport pratique le geek ??. Évalué à 8.
[^] # Re: arts martiaux
Posté par Yusei (Mastodon) . En réponse au journal Quel sport pratique le geek ??. Évalué à 2.
Concernant le Zen, j'avoue avoir du mal à voir le lien avec la geekitude, même si j'ai aussi rencontré une certaine proportion de geeks intéressés. Peut-être que cela vient de la "mode orientaliste" générale. En tout cas le Zen me semble être l'opposé de la pensée logique et mécaniste dont on a besoin pour être un bon computer geek.
[^] # Re: Simple
Posté par Yusei (Mastodon) . En réponse au journal [HS] est-ce mal ?. Évalué à 2.
C'est ce que j'entends dire partout, alors j'ai fini par le croire, sans avoir jamais essayé Mac OS. Mais d'un autre côté, je suis persuadé que l'ergonomie d'ion3 me manquerait, si un jour on m'obligeait à y renoncer.
Le problème, c'est que l'existence de l'alternative dépend fortement du nombre de ses utilisateurs. Si GNU/Linux reste cantonné, au mieux, au dual/boot sur les macs, il ne faudra pas s'étonner de ne pas avoir apparaître de drivers pour le matériel des macs, ou bien de devoir les attendres un ou deux ans.
Parce que bon, il ne faut pas se faire d'illusions... s'ils ont le choix au boot entre un système où tout est géré et un autre où quelques trucs manquent, la plupart des gens choisiront la facilité.
[^] # Re: bof
Posté par Yusei (Mastodon) . En réponse au journal [HS] est-ce mal ?. Évalué à 2.
D'un autre côté, avec le proprio, tu banques aussi. Ce n'est pas un défaut du libre, même si je t'accorde qu'on risque de payer un peu plus cher dans le libre, parce que les économies d'échelle sont plus réduites.
[^] # Re: Un peu HS
Posté par Yusei (Mastodon) . En réponse à la dépêche Les brevets et l'innovation en danger au Parlement europeen. Évalué à 7.
De là à accuser ses "adversaires" d'avoir pourri le monde, il n'y a qu'un tout petit pas.
[^] # Re: Le retour des brevets en Europe, hélas hors de l'Union européenne
Posté par Yusei (Mastodon) . En réponse à la dépêche Les brevets et l'innovation en danger au Parlement europeen. Évalué à 5.
En survolant l'article, j'ai eu l'impression que le parlement allait voter au sujet de l'EPLA. Or, tu dis qu'ils ont été squizzés ; j'ai raté un épisode ?
[^] # Re: Benôit sillard de l'Education Nationale est contre ...
Posté par Yusei (Mastodon) . En réponse à la dépêche Où en est le projet One Laptop per Child ?. Évalué à 2.
Il y a des gens qui suggèrent que, justement parce que quand on parle à un ordinateur on doit savoir écrire sans fautes, l'utilisation des ordinateurs pourrait motiver les enfants dans l'apprentissage de l'orthographe et de la grammaire.
[^] # Re: Java = le diable ?
Posté par Yusei (Mastodon) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 2.
On est d'accord. Que ce soit Java ou Python, il faut un interpréteur, mais sur toutes les plateformes où un interpréteur existe, c'est "portable" :)
Je n'ai jamais vu personne faire une distinction entre "de haut niveau" et "de scripts". On fait plus souvent une distinction entre langage compilé et langage de scripts, mais même ainsi la séparation est très arbitraire. Dans la catégorie des langages qu'on appelle généralement "de scripts", on trouve quand même Ruby, pour lequel il est difficile de prétendre qu'il est de plus bas niveau que Java.
Note qu'en disant que Java n'était pas "le plus portable", je ne voulais pas le critiquer, simplement souligner qu'on trouve des langages récents, novateurs et libres qui sont au moins aussi portables que Java. Après, à chacun de choisir selon ses goûts, on peut aussi faire du Java en n'utilisant que des outils libres.
(À titre personnel, j'avoue détester ce langage. Mais tout le monde s'en fiche, et ils ont raison.)
[^] # Re: Java = le diable ?
Posté par Yusei (Mastodon) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 2.
Une JVM, c'est un interpréteur pour le bytecode Java. Java tourne sur une plateforme s'il est possible de compiler une JVM sur cette plateforme.
Tu peux remplacer "Java" dans la phrase ci-dessus par n'importe quel langage, que ce soit Python, Ruby, Perl, Lisp... c'est toujours valable. Je ne sais pas sur combien de plateformes on trouve l'interpréteur Python, mais je doute que ce soit moins portable que Java. Déjà, c'est disponible sous Windows, les variantes de Linux et de BSD, MacOS X compris. Le grand succès marketing de Sun, ça a été de faire croire que le concept de machine virtuelle était propre à Java.
Au final, quand tu dis que Java est le plus portable des langages de dernières générations, quelque chose me dit que tu ne le compares qu'à .NET. Il y a même un paquet de langages de haut niveau (et plus novateurs) qui sont compilables, au choix, en natif ou en bytecode Java, et qui sont par conséquent au moins aussi portables que Java. Voir par exemple OCaml, mais ce n'est pas le seul.
[^] # Re: Java = le diable ?
Posté par Yusei (Mastodon) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 4.
[^] # Re: Pourquoi
Posté par Yusei (Mastodon) . En réponse au journal Les choix étranges du libre. Évalué à 2.
Bon ok, j'avoue, je ne sais pas si ça marche bien, et je ne sais pas si ça existe depuis aussi longtemps que phpmyadmin.
[^] # Re: Pour MySQL...
Posté par Yusei (Mastodon) . En réponse au journal Les choix étranges du libre. Évalué à 1.
MySQL ne te propose pas cette garantie. Si tes données ne se conforment pas à ce qu'il attend, au lieu de faire échouer la requête, il va essayer de transformer tes données pour les faire rentrer, sans te le dire. En particulier, il va tronquer les chaînes trop longues, et mettre les dates invalides à 0.
Rien qu'à cause de cette raison, je pense que MySQL reste limité aux sites web qui ne traîtent pas de données importantes. Il est utilisé pour des sites importants, mais c'est par flemme d'apprendre autre chose ou par incompétence.
[^] # Re: Souricide
Posté par Yusei (Mastodon) . En réponse au journal Tendinites et douleurs articulaires liées à l'informatique.. Évalué à 2.
# Grand public
Posté par Yusei (Mastodon) . En réponse au journal reflexion sur la fin de week ou se soumettre à La Question de mode. Évalué à 6.
http://www.xs4all.nl/~marcone/bsdversuslinux.html
[^] # Re: une solution alternative
Posté par Yusei (Mastodon) . En réponse à la dépêche La correction grammaticale sous Linux x86 avec Antidote. Évalué à 7.
Un correcteur grammatical, c'est utile aussi pour les gens qui maîtrisent parfaitement la grammaire: il n'y a rien de plus facile sur un ordinateur que de vouloir changer une phrase en cours de route, mais il est aussi très facile d'oublier de modifier tous les bouts de la phrase pour qu'elle s'adapte à la modification. C'est l'équivalent grammatical d'une faute de frappe: je copiecolle un morceau, je supprime une préposition, mais j'oublie de changer un accord, et paf.