Articles précédents : Développeur
- [12] Brevet sur le XML et sur le Fichier::Enregistre/Sauver?
- [114] Nouveau rebondissement dans l'affaire du pilote PWC
- [33] Sortie de l'émulateur Qemu 0.7.0
- [68] Toutes les API GNOME dans tous les langages et pour bientôt ?
- [10] Appel à contribution pour "l'outil d'analyse des contrastes de couleurs"
- [46] Sortie de Anjuta 2.0.0
- [110] KDE doit-il abandonner KHTML pour Webcore ?
- [54] Le basculement de KDE vers Subversion est terminé
- [64] wxWidgets 2.6 est sorti
- [31] Le développement du noyau continue autour de Git
Liens connexes
- Wiki en français sur Ruby (2871 hits)
- Une explication du modèle MVC (678 hits)
- Rolling with Ruby on Rails, article d'introduction sur Onlamp (477 hits)
- Article d'introduction à Ajax sur Ruby on Rails (1017 hits)
- Really getting started in Rails, à lire après les articles d'Oreilly (368 hits)
- Four Days on Rails : document de 40 pages (578 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Support d'Ajax dans Ruby on Rails
Posté par Lucas (page perso, ). Modéré le 18 juin 2005.
Ruby est un langage de script (comme Perl ou Python), totalement orienté objet, avec une syntaxe très propre qui rend la programmation élégante et amusante.
Ruby on Rails est un framework de développement d'applications Web en Ruby, utilisant le modèle MVC. Oui, c'est vrai, il en existe déjà des dizaines. Mais grâce (entre autres) à son utilisation de Ruby, Rails permet de développer des applications Web jusqu'à 10 fois plus vite qu'avec d'autres frameworks (NdM : ce type d'information est évidemment à prendre avec toutes la réserve nécessaire), avec un code bien plus concis. Ruby on Rails a provoqué ces derniers mois un petit ras de marée dans le monde des développeurs d'applications web, en remettant en cause le classique couple PHP/MySQL. D'autant plus que le support d'Ajax vient de lui être ajouté.
Ajax (Asynchronous Javascript and XML) est une vieille technologie : son composant de base, XMLHttpRequest, existe depuis 1998 et est utilisé un peu secrètement par de nombreux sites. Il permet de mettre à jour une page web sans avoir à recharger l'ensemble de la page (pour un petit exemple, postez un commentaire sur ce blog, c'est fait pour). Démocratisé par Google ces derniers temps (essayez par exemple de chercher quelque chose sur Google Suggest), son utilisation reste difficile, car il faut écrire du code compatible avec les différents navigateurs.
C'est là que Ruby on Rails montre tout son intérêt. Après avoir permis de développer des applications Web complexes sans écrire une ligne de SQL, Ruby on Rails permet de développer des applications Ajax en quelques minutes sans écrire une ligne de Javascript. Même si Ajax n'est pas la solution ultime, il permet de rendre des applications Web bien plus interactives et agréables pour les utilisateurs. Pas convaincu ? Essayez d'uploader un fichier sur cette page et admirez la barre de progression.
![[fr]](../../../images/fr.png)
Wiki en français sur Ruby (2871 hits)![[en]](../../../images/en.png)
Une explication du modèle MVC (678 hits)-
Rolling with Ruby on Rails, article d'introduction sur Onlamp (477 hits)
-
Article d'introduction à Ajax sur Ruby on Rails (1017 hits)
-
Really getting started in Rails, à lire après les articles d'Oreilly (368 hits)
-
Four Days on Rails : document de 40 pages (578 hits)
> Lire la dépêche (120 commentaires, moyenne: 2,4).
Balèze
Ah ouais, tiens. Je connaissais pas Ajax et j'étais jusqu'alors persuadé que c'était pas possible, même avec du javascript. Balèze.
-
[^]Re: Balèze
Posté par blobmaster () le 19/06/2005 à 16:35. (lien). Évalué à 3.C'est même possible de faire du "remote scripting" sans les XML* en utilisant des iframes invisibles. C'est cochon mais ça permet à du php de générer le code Js (par exemple l'initialisation d'un tableau) et de mettre à jour les données en fonctions des actions de l'utilisateur. C'est même possible depuis longtemps.
Ceci dit niveau perf disons que ça s'améliore.
c.f.
http://linuxfr.org/comments/590765.html#590765(...)
A voir aussi :
http://www.framasoft.net/article3991.html(...)-
[^]Re: Balèze
Posté par Miair Patreau () le 19/06/2005 à 17:27. (lien). Évalué à 2.Mouais. Je vais regarder ça aussi, mais à mon avis, c'est bien plus moche quand quelque chose n'est pas supporté qu'avec les techniques Ajax.
-
consommation CPU côté client ?
mouais, moi je ne suis pas convaincu vu les performances des interpréteurs JavaScript. Déjà que DLFP rame à souhait rien que pour le comptage des commentaires lu/pas-lus ... Sur un gros article, c'est pas rare que Mozilla me demande 2x si je veux pas tuer la page. Pis encore, quand mon processeur est en fréquence basse, il est remonte à pleine puissance ... J'arrive des fois à des temps de rendu > 30s. (J'ai un ibook 533Mhz / 1GHz.)
Donc je m'interroge sur la performance. Surtout que les accès mobiles type Nokia 770 se multiplient.
-
[^]Re: consommation CPU côté client ?
-
[^]Re: consommation CPU côté client ?
Posté par Mathieu Pillard (page perso, ) le 19/06/2005 à 17:16. (lien). Évalué à 8.La toolbar rame actuellement parceque elle a été concue par étape, en se greffant par dessus linuxfr. En fait, elle parse 3 fois la page pour faire son travail, lequel est deja pas mal compliqué.
J'ai développé une nouvelle version de la toolbar et posté un journal a ce sujet, il reste certaines optimisations a faire, mais j'ai tout repris depuis zero ou presque et c'est maintenant 3 fois plus rapide qu'avant. J'ai fait des tests en forcant mon cpu a 1Ghz, et meme sur des tres grosses niouzes, les temps d'acces sont honorables avec cette version.
Bref, oui, JavaScript est pas super rapide, mais en l'occurence, le probleme de vient pas de l'interpreteur.
Google Suggest est un bon exemple, car on voit en temps réel la chose se charger, mais le service qui utilise cette technologie et qui est le plus populaire c'est Gmail !
une fois qu'on connais l'existance d'AJAX, c'est rigolo de voir que le fait de cliquer un peu partout dans ses mails ne recharge que la partie centrale de la page, et pas les menus ...
L'un des défaut de cette technologie, c'est qu'on ne peux pas directement rajouter un "Bookmark" vers la/les page(s) en question, ou utiliser le bouton précédent.
-
[^]Re: Google
Posté par Maurice Svay (page perso, ) le 19/06/2005 à 10:22. (lien). Évalué à 3.Plus généralement, ce défaut est lié aux mauvaises utilisations de Javascript. Il existe pourtant des solutions comme là: http://www.contentwithstyle.co.uk/Articles/38/fixing-the-back-butto(...)
-
[^]Re: Google
Posté par Gniarf () le 19/06/2005 à 13:07. (lien). Évalué à 7.ouais non, le défaut est lié aux chefs de projets/chefs de produits/managers etc qui te disent "réfléchis pas et bosse" quand tu leur signales que leurs superbes idées "c'est mal".
voir aussi les millions de page avec une entrée ou des menus en flash, et inutilisables sans.--
Windows has no users. It has hostages.
-
-
[^]Re: Google
Posté par TImaniac (page perso, ) le 21/06/2005 à 13:48. (lien). Évalué à 1.Oué bientôt il y en a un qui vas nous inventer les frames. Ah quand Ruby on Frames ?
Ruby On Rails
Quelqu'un aurait un retour d'expérience sur Ruby On Rails en situation réelle. Ça apporte beaucoup en terme de productivité par rapport à l'utilisation d'un Framework MVC J2EE par exemple ?
Et quels sont les outils de développement disponibles ?
-
[^]Re: Ruby On Rails
Posté par Stéphane TRAUMAT (page perso, ) le 19/06/2005 à 14:17. (lien). Évalué à 2.Dans tous les cas, pour être passé de Struts à JSF, JSF est bien meilleur en terme de productivité.
-
[^]Re: Ruby On Rails
Posté par Miguel Moquillon (page perso, ) le 20/06/2005 à 11:42. (lien). Évalué à 2.Surtoût qu'ils ne sont pas destinés à la même chose.
- Struts est un framework MVC sur lequel peuvent se gréffer des technos différentes pour les aspects Vue et Modèle. La partie Contrôleur est fournie par Struts, mais il fournit aussi ses propres technos côté Modèle et surtoût Vue pour les développeurs qui ne veulent pas s'embêter.
- JSF est une techno de gestion de Vues.
Ce qui fait que l'on peut utiliser JSF avec Struts car ils sont complémentaires et non opposés.-
[^]Re: Ruby On Rails
Posté par Stéphane TRAUMAT (page perso, ) le 20/06/2005 à 11:58. (lien). Évalué à 1.JSF est aussi MVC et je dirais que l'on a pas besoin de Struts.. le controler est pas fouttu pareil, pas la meme philosophie mais on fait du bon MVC avec JSF... et c surtout plus simple !
-
[^]Re: Ruby On Rails
Posté par Miguel Moquillon (page perso, ) le 20/06/2005 à 19:42. (lien). Évalué à 1.JSF jusqu'à présent ne supporte pas MVC. Si on veut faire du MVC avec, on doit se le palucher à la main. JSF reste pour l'instant, grosso modo, une technologie qui permet de standardiser dans J2EE la gestion, de façon flexible, de l'aspect présentation. Il n'apporte aucun contrôleur et n'implémente pas de gestion de contrôle entre Vue et Modèle via le Contrôleur.
-
-
-
-
[^]Re: Ruby On Rails
Posté par Strass (page perso, ) le 19/06/2005 à 16:58. (lien). Évalué à 2.Ca apporte énormément en terme de productivité. C'est même plaisant et fun à utiliser. Mais il ne faut pas oublier que Rails est un framework MVC dédié au web.
-
[^]Re: Ruby On Rails
Posté par Nicolas Delsaux (page perso, ) le 20/06/2005 à 08:40. (lien). Évalué à 0.
Quelqu'un aurait un retour d'expérience sur Ruby On Rails en situation réelle. Ça apporte beaucoup en terme de productivité par rapport à l'utilisation d'un Framework MVC J2EE par exemple ?
Dans la blogosphère J2EE, des messages ont signalé une augmentation considérable avec des temps de développements divisés par un facteur de 5 à 10 suivant les cas.
Et quels sont les outils de développement disponibles ?
Ruby pour Windows intègre un IDE complet écrit en Ruby+FOX (et franchement très lent chez moi).
On peut aussi utiliser un plugin Eclipse peu complet pouyr le Ruby.
En revanche, de manière spécifiquement dédiée à Rails, je ne sais pas trop ce qui peut exister.-
[^]Re: Ruby On Rails
Posté par gc (page perso, ) le 20/06/2005 à 10:21. (lien). Évalué à 4.Cependant, lorsque l'appli grossit, la vérification à la compilation dans un langage fortement typé, devient un avantage de plus en plus important.
Quelle est la taille des applications RoR dont tu parles ?-
[^]Re: Ruby On Rails
Posté par Miguel Moquillon (page perso, ) le 20/06/2005 à 11:47. (lien). Évalué à 1.Tu veux sûrement parlé de langages à typage statique. Bien que Ruby soit de typage dynamique, il supporte, comme Smalltalk, un typage fort.
-
[^]Re: Ruby On Rails
Posté par gc (page perso, ) le 20/06/2005 à 12:29. (lien). Évalué à 2.Non je parlais plus précisément de typage fort. Associé à la vérification à la compilation comme je le disais (vérification statique donc - pour le typage dynamique les types étant découvert à l'exécution) ça permet de détecter plus de problèmes dès la compilation (avec le coût d'être plus verbeux par contre).
-
[^]Re: Ruby On Rails
Posté par Damien (page perso, ) le 20/06/2005 à 15:04. (lien). Évalué à 1.Pas forcément... le typage statique a des inconvénients aussi (flexibilité, verbosité) et je suis pas certain que ça soit plus utile que des tests bien faits, surtout si on considère les autres avantages des tests (ça fait de la doc, des exemples de code, en test-first ça aide aux specs, c'est utile pour refactorer etc.)
À côté de ça le typage statique ne dispense pas de faire des tests... avoir une étape de compilation allonge le cycle de développement, etc-
[^]Re: Ruby On Rails
Posté par Fabien Penso (Jabber id, page perso, ) le 20/06/2005 à 15:09. (lien). Évalué à 3.je suis pas certain que ça soit plus utile que des tests bien faits
Enfin on n'a jamais dit qu'un typage statique évitait de faire des tests ... L'étape de compilation qui rallonge le cycle de développement ça fait sourire quand même :) Compilation incrémentale, tout ça. De plus des tests ne permettent souvent pas de tester _tout_, alors des vérification en plus personnellement je crache pas dessus.
-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 20/06/2005 à 15:51. (lien). Évalué à 5.avoir une étape de compilation allonge le cycle de développement
T'as qu'à considérer l'étape de compilation comme une étape de tests générés et exécutés automatiquement. Tiens tout à coup c'est beaucoup plus productif et ca enlarge plus ton cycle de developpement.-
[^]Re: Ruby On Rails
Posté par bobefrei () le 21/06/2005 à 07:50. (lien). Évalué à 2.Sauf que quand ton cycle de compilation/déploiement prend 5min, ça "n'enlarge" plus, ça fait perdre du temps.
-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 21/06/2005 à 09:52. (lien). Évalué à 4.N'importe quoi qu'est ce qu'il faut pas entendre...
T'as déjà entendu parler de compilation incrémentale ?
Tu crois franchement que tu as besoin de recompiler systématiquement toute l'appli ?
La phase de compilation c'est de l'ordre de la seconde lors d'une phase de dev normale. Avec certains IDE (Eclipse, Visual Studio) c'est même fait en background avec retour instantané (surlignage de la faute) lorsque le developpeur tappe son code.
Et puis franchement cette phase de "compilation" c'est aussi pour gagner du temps à l'exécution. Bref, c'est tout benef, il n'y a aucun inconvénient en terme de productivité, au contraire c'est une première phase de test qui permet d'éviter bien des conneries.-
[^]Re: Ruby On Rails
Posté par Damien (page perso, ) le 21/06/2005 à 10:33. (lien). Évalué à 4.La compilation c'est aussi un obstacle à certains outils... par exemple dans rails, ./script/console t'ouvre un interprète dans le contexte de l'appli. En smalltalk c'est courant de coder dans le débogueur.
Bien sûr c'est possible dans une certaine mesure et grâce à des artifices subtils (le compilo d'eclipse, zerolink dans XCode...) mais ça n'est pas aussi simple et clair qu'en ruby/python/smalltalk.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 21/06/2005 à 11:58. (lien). Évalué à 3.Oué enfin dans le contexte d'une grosse appli, se passer d'un typage fort statique (et tous les avantages en matières de vérification/optimisation), tout ca pour pouvoir s'amuser à coder dans le débogueur je trouve cela pour le moins douteux comme justification...
-
-
[^]Re: Ruby On Rails
Posté par Éric (Jabber id, page perso, ) le 21/06/2005 à 12:03. (lien). Évalué à 3.> La phase de compilation c'est de l'ordre de la seconde lors d'une phase de dev normale
Ah ? chez moi les compil prennent du temps. Pour avoir modifié des sources de PHP récement, à chaque modif ça recompilait le fichier, puis l'extension dont dépendait ce fichier, puis la libphp4 avec l'extension en statique (non, dynamique ça collait pas), puis finalement le php-cli qui va avec.
Le tout était *très* loin de la seconde et très loin d'être négligeable.
Et franchement non, la phase de test et la phase de compilation sont deux choses séparées.
Le but de la compilation c'est de produire du code machine. Le but d'une phase de test c'est de vérifier ton code. Certes le gcc pour pouvoir compiler fait des vérifications, mais rien n'empêcherait techniquement une phase de test sans compilation.
Si tu es concerné par les tests/vérifications l'avenir ce sont des outils d'analyse de code qui repèrent les mêmes choses (syntaxe, mauvais appels, contrôles de type, ...). Ca n'impose en rien une compilation (ou plutot ça ne devrait en rien l'imposer) et c'est une mauvaise justification de l'étape compilation.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 21/06/2005 à 12:35. (lien). Évalué à 1.En même temps tu prends exemple sur PHP qui est un langage interprété avec un typage dynamique.
Moi je te parle de C++, Java ou C#, avec un vrai compilo qui vérifies le typage statiquement (quand c'est possible) et vrai IDE.
Et franchement non, la phase de test et la phase de compilation sont deux choses séparées.
T'auras beau dire tout ce que tu veux, le compilo fait un nombre incalculable de tests, surtout avec un langage à typage fort et statique. Que tu le veuilles ou non, quand le dev compile il fait une première passe de tests. D'ailleur les méthodes de dev récentes dites "agiles" comme l'XP préconise l'utilisation intesive des TESTS unitaires. Et bizzarement dans le cycle de dev on les faits souvent s'exécuter juste après la compilation, comme si c'était la suite logique des premiers tests...
Visiblement tu n'as rien compris à ce qu'est un compilo, à ce qu'il est censé faire. Il n'est pas censer que "pondre" du code, un compilo c'est avant tout un analyseur lexical et syntaxique qui constitue une première couche de TESTS et un générateur de code. C'est loin d'être seulement la 2ème partie.
Tu dis que l'avenir est aux outils d'analyse de code : mine de rien le compilo est l'un de ses outils, rien n'empêche d'utiliser d'autres outils à côtés.-
[^]Re: Ruby On Rails
Posté par Stéphane TRAUMAT (page perso, ) le 21/06/2005 à 13:08. (lien). Évalué à 2.Pour la deuxième fois de ma vie, je suis d'accord avec Timaniac, dans des environnements comme Eclipse par exemple, la compilation n'est même plus une phase que l'on voit... elle se fait au fur et à mesure.
Et la protection qu'offre la compilation, meme si elle ne corrige qu'une partie des erreurs... beh c déja ca de pris !-
[^]Re: Ruby On Rails
Posté par golum () le 21/06/2005 à 15:05. (lien). Évalué à 3.Ce qui est contre productif c'est d'être obligé de mettre des déclarations de type partout alors qu'on veut simplement tester une idée.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Moi je préfère me concentrer sur l'idée en utilsant un langage dynamique. Tu developpes ta classe et ton test unitaire associé en même temps..
Après comme devermineur tu peux utiliser les "contrats" qui apportent plus de garanties que le simple type checking.
Si tu veux vraiment pousser, tu disposes d'outils de verification pour les langages dynamiques comme pychecker pour python.
Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
cf. debats de la communauté python
http://www.google.fr/search?q=python+optional+static+typing&sou(...)
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Ca n'en est qu'une étape et je ne suis pas le seul à le penser
http://fr.wikipedia.org/wiki/Compilation(...)
L'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...). Et n'oublions pas les optimisations à l'execution.
Bref la frontière entre langage interprété et complié est de plus en plus ténue en terme de performances
Par contre les inconvénients du typage fort subsistent.
http://www.mindview.net/WebLog/log-0025(...)-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 21/06/2005 à 15:36. (lien). Évalué à 0.Ce qui est contre productif c'est d'être obligé de mettre des déclarations de type partout alors qu'on veut simplement tester une idée.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
On a inventé les génériques :
Pile maPile;
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Tu developpes ta classe et ton test unitaire associé en même temps..
Genre toi humain t'es beaucoup plus fiable pour générer des tests unitaires exhaustifs en pouvant te permettre de te passer des vérifs qu'apporte un typage fort et statique.
Si encore tu me disais : moi je tests jamais les progs je comprendrais, t'assumerais effectivement jusqu'au bout, mais là non.
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), alors bon question productivité je préfères faire confiance au compilo et garder mes tests unitaires pour ce qu'il ne sait pas faire.
Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme pour les tests unitaires : il est fortement conseillé de les écrire D'ABORD. Tout va toujours dans le même sens : on met le maximum de contraintes (tests unitaires, typage, etc.) et on code APRES.
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...)
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
Par contre les inconvénients du typage fort subsistent.
C'est quoi déjà les inconvénients ?
Ah oui tu peux pas mettre n'importe quoi dans ta pile, et c'est super long à taper le type.
PS : déclarer le type d'un objet c'est aussi une forme de documentation pour celui qui relis le code.
Taper le mot "int" ou "MaClasse" c'est une part négligeable de la rédaction du code et cela permet de gagner un peu plus loin : l'IDE ayant le type il peut te proposer les méthodes applications à ton objet , et ca question productivité c'est un gain beaucoup plus important.-
[^]Re: Ruby On Rails
Posté par golum () le 21/06/2005 à 16:17. (lien). Évalué à 2.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ben c'est plus long que de ne pas l'indiquer
Il faut le mettre dans les declarations, dans les cast sans compter les
modificateurs à la pelle
On a inventé les génériques :
Pile maPile;
Quelle différence avec les templates C++
Tu es bien obligé de preciser le type d'objet lorsque tu l'utilises et donc tu as bien genéré un bytecode correspondant à ton "instanciation'"
Par exemple
List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Ben justement avec un langage dynamique tu n'est pas obligé de passer par de tels artifices.
En Java tu peux aussi passer par des interfaces (plus propre conceptuellement) mais tu es de toute façon obligé de rajouter du code
(cf le lien sur la page de Bruce Eckel que j'ai donné)
Genre toi ....
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), ....
Absolument pas. Tu ne dois pas tester les types d'objets avec tes test unitaires
Tu définis un contrat qui est nettement plus rigoureux(précondition/postconditions , invariants) et va plus loin que la simple vérification de type.
Après tu valides le tout au moment de l'assemblage de tes composants.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme .... et on code APRES.
cf . contrats
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Des trolls comme ca tu les gardes parce que moi aussi je peux jouer, genre:
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 21/06/2005 à 17:03. (lien). Évalué à 1.Ben c'est plus long que de ne pas l'indiquer
Pour le prototypage je reconnais qu'un langage sans typage peut être "pratique". Mais ca reste du prototypage. Ca rejoint l'idée première de ces langages qui restent des langages de "script", pas pou faire des grosses applis.
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Les templates en C++ c'est un peu affreux, j'en convient.
En Java le compilo remplace partout la référence au type par object avec un cast. Il n'y a donc pas de génération spécifique.
En C#, le typage est conservé dans le bytecode, le code spécifique est généré à la volée, tout en conservant toutes les informations sur la "généricité".
En C# non seulement c'est un gain non négligeable en terme de fiabilité (puiqu'il permet d'éviter de nombreux casts tout en permettant au compilo d'effectuer des vérifications), mais c'est aussi un gain de temps à l'exécution (une pile d'entier est allouée sur la pile, alors qu'une pile d'objet ne l'est pas).
Enfin pour te montrer que le typage est si "important", il a constitué pour Java et C# une des principales améliorations et atouts de leur évolution, parcque réclamé par les dev.
(cf le lien sur la page de Bruce Eckel que j'ai donné)
J'ai du mal à comprendre son point de vue. Je vois pas pouquoi il posse 2 notions qui sont complémentaires. Tout est bon pour améliorer la qualité du code, que ce soit le typage statique et fort, les tests unitaires, les contrats, etc.
Le but étant d'automatiser le maximum de tâche (une machine se trompe rarement), c'est pourquoi sont apparus les Garbage collector entre autre.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Arf effectivement si tu poses bien tes contrats tu vas résoudre pas mal de problème.
Mais on en revient toujours au même point : c'est l'humain qui rédige les contrats, et à moins d'avoir des outils comme le langage B pour formaliser tout ca et s'assurer de la validifé des contrats, il restera toujours une marge d'erreur.
Si tu rédiges des contrats en Python, ils te péteront à la tronche à l'exécution. J'espère que ca ne sera pas chez le client le jour où un contrat aura été mal rédigé.
Enfin tu me fais sourir quand même : tu veux pas écrire le type de tes variables par "gain de temps", et tu consommes une bonne partie de celui-ci à la rédaction des contrats. Cette reflexion sur les contrats doit en plus t'amner bien souvent à "réfléchir" sur le type à l'exécution de tes variables.
De plus préciser le type d'un paramètre par exemple fait parti de la signature d'une méthode, si tu mets plusieurs méthodes dans un même "conteneur", t'as une interface, qui constitue déjà une sorte de contrat, qui lui a l'avantage d'être checkable à la compilation, et donc qui sera vérifier par un outil avant d'aller péter le cas échéant chez le client.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Ben dans le cas d'un langage typé fort et statiquement, si c'est une des finalités. Si pour toi contribuer à améliorer la qualité du code produit n'est pas dans les objectifs d'un compilo...
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Je te ferais remarquer que gcj tourne sur un peu plus d'architecture, et il est tout à fait capable de compiler "à la volée" (JIT) le code intermédiaire : tu ne perds pas la portabilié. Et ayant généré un exécutable pour la machine cible, c'est celui-ci qui sera de nouveau exécuté. Non là tu ne perds pas la portabilité.
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
Genre le refactoring tu trouves pas ca pratique ? En python t'as jamais envie d'extraire une interface d'une classe ? Ah ben non désolé y'a même pas la notion d'interface :) T'as jamais besoin de renommer une variable ? Et là tu vois un parfait exemple d'utilité du refactoring : tu modifies le type d'une variable, le refactoring applique les modifs partout, et bien le compilo te gueuleras dessus si jamais une erreur de typage a été introduite quelque part.
EN Python t'as intérêt de te rappeler quelles sont les conséquences de tes changements.
Si pour toi la complétion automatique de méthode n'est pas un gain de productivité je ne cherche plus à comprendre... Le typage fort instaurant de plus de nombreux tests automatique, il permet d'obtenir un peu plus de fiabilité, au final de bugs en moins et donc de la productivité en plus.
Enfin franchement j'ai du mal à te suivre : tu semble "fan" des contrats (j'abonde dans ton sens), mais tu refuses le typage statique, alors que les 2 notions cherchent le même but et sont complémentaire : assurer une certaine qualité du code. Enfin tu sembles préférer faire confiance exclusivement à ta rédaction des contrats plutôt que de confier des vérifications de base à un outil dont c'est en parti le boulot.-
[^]Re: Ruby On Rails
Posté par golum () le 21/06/2005 à 22:21. (lien). Évalué à 2.Tu parles de protoypage en réduisant les langages dynamiques au rôle de langages de script.
Mais si on suit ton raisonnement , on prototype rapidement avec un tel langage et après on réecrit tout avec un langage fortement typé pour assurer performance et sécurité ( ou on regénère du code à partir d'UML). Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
La démarche que j'explicite est différente.
Tu prototypes sans contrainte de type au début ce qui te permet d'explorer différentes pistes ou architectures.Tu ecris tes tests unitaires en même temps mais tu introduis tes contrats progressivement et itérativement à mesure que ta conception se précise.
Tu ne livres pas de code non testé en prod puisque ton code est testé et validé par les contrats. Tu relâches les contraintes progressivement à mesure que la qualité de ton code s'améliore (tout comme les niveaux de logging ou les options de debug) et tu conserves malgré tout une plus grande souplesse durant la phase de conception.
Concernant les IDE :
Bien entendu les fonctionnalités que tu decris sont intéressantes même pour un langage dynamique. Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
La compilation JIT n'a d'utilité que pour des langages compilés comme Java.
L'expressivité et la concision de langage comme Python ou Ruby rendent moins crucial le besoin d'outils performants de refactoring, d'introspection.... Python a ses défauts inhérents à son design mais Java n'est pas exempt non plus.Relis mon post , j'ai bien précisé qu'il s'agissait d'un troll en réaction à tes à prioris
Bref tout est affaire de compromis entre performance et productivité.
Il faut donc définir sa stratégie en fonction des besoins.
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
cf. notre thread sur
http://linuxfr.org/comments/589849,1.html(...)
Si tu es interessé par les contrats tu retrouveras un excellent article de synthèse sur le defunt "Développeur Reference"
http://web.archive.org/web/20031204022702/www.devreference.net/devr(...)
Perso je l'utilise au travers d'un module POA dans le cadre d'un petit dev associatif et j'e ne m'en plains pas:
http://www.logilab.org/projects/aspects/documentation/contracts(...)
Mais tu trouveras sûrement de meilleurs equivalents pour .net, java ou ruby-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 22/06/2005 à 07:52. (lien). Évalué à 2.Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
Sauf qu'en général le prototype c'est pas une "référence". C'est pas forcement "bien" de partir de son code, il faut mieux parfois reprendre tout à 0 de façon plus propre, lorsque les différentes idées dans le prototype commence à se mettre en place.
Toi tu proposes d'améliorer au fure et à mesure la qualité du code de ton prototype. Pourquoi pas. Je ne suis pas partisan de cette manière de faire, je préfères faire le plus propre possible dès le début, en me basant sur un modèle plus abstrait validé "théoriquement".
Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
A l'arrivé on est parfois plus productif puisque l'IDE propose automatiquement les méthodes qui s'applique à un objet. Dans un langage où le type n'est connu qu'à l'exécution ca va être "balèze". Souligner les fautes est également productif à mon goût.
Bref tout est affaire de compromis entre performance et productivité.
Je ne parlais pas de performances, là j'aurai trop epru de troller ;)
Je préfères me contenter de parler de compromis entre productivité et "qualité".
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
Très bonne conclusion avec laquelle je suis d'accord. Cela va assez dans mon sens : les grands comptes qui font de "grosses" applis ont besoin du maximum d'outils pour vérifier et valider des bouzins énormes. D'où l'idée qu'un typage statique fort va dans le sens de la qualité (et avec un bon IDE sans rien sacrifier à la productivité à mon goût).
J2EE va vraiment dans le sens des grosses applis, Python/Ruby pour le RAD. Mono je le situerais bien entre les 2. Peut être pas parfait dans un cas ni dans l'autre, mais à "l'aise" dans les 2.
Pour la prog par contrat je n'avais regarder que du côté de Eiffel.
Sinon une variante de Python avec typage fort et statique : Boo pour Mono.
-
-
-
-
[^]Re: Ruby On Rails
Posté par bobefrei () le 21/06/2005 à 17:38. (lien). Évalué à 2.>Personne ne t'empêche de tester une idée dans un langage à typage "faible".
Comme ça tu perds du temps à porter ton prototype dans un autre langage...
>De plus c'est pas non plus super long d'écrire le type hein.
Un seul non, mais sur un programme ça représente une grande partie de ce que tu tapes. Surtout avec Java/C++/C# qui t'obligent à taper plusieurs fois la même info:
MonType obj = new MonType();
MaListe<MonType> Liste = new MaListe<MonType>(obj);
MonType obj2 = Liste.first();
Une bonne syntaxe associé à un interpréteur/compilateur intelligent permette de déduire le type des instances:
obj := new MonType()
Liste := new MaListe(obj)
obj2 = Liste.first();
( := est là pour faire différence entre instanciation et affectation )
Au delà de cette syntaxe fictive, des langages comme OCAML implémente ce genre de chose sous la forme de l'inférence de type.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 22/06/2005 à 07:42. (lien). Évalué à 2.Tout bon IDE te complète automatiquement le nom du type après avoit saisi "new". Conclusion tu tapes une seule fois le type, ce n'est donc pas plus long.
De plus tu peux très bien vouloir parfois ne pas mettre le même le même type à gauche et à droite. Typiquement tu peux instancier un type dérivé et ne conserver qu'une référence à une interface, pour t'obliger à l'utiliser en tant que tel.-
[^]Re: Ruby On Rails
Posté par reno () le 23/06/2005 à 11:01. (lien). Évalué à 4.Bah, s'il faut un IDE a la Eclipse qui utilise des centaines de Mo de RAM pour programmer..
De plus, à la lecture, cela reste plus lourd.
Pour ton dernier point, je ne connais pas bien Ocaml mais en Limbo (un language tournant sur Plan9), la syntaxe suivante est utilisée:
my_var1 = my_var2; affecte la valeur de my_var2 à my_var1, my_var1 devant être déclaré avant.
my_var1 := my_var2; déclare my_var1 comme étant du type de my_var2, et lui affecte sa valeur.
my_var1 : my_type = my_var2; déclare my_var1 comme étant du type my_type et lui affecte la valeur de my_var2.
my_var1 : my_type; déclare my_var1 comme étant du type my_type avec une valeur par défaut correspond au type.
Simple et de bon gout.
-
[^]Re: Ruby On Rails
Posté par bobefrei () le 23/06/2005 à 15:50. (lien). Évalué à 2.Il est dommage de compenser les faiblesses d'un langage par son IDE.
Pour le problème de l'instanciation d'un type et l'affectation à une référence vers un parent ou une interface, il suffit d'une conversion:
Ref = new MaClasse() as MonInterface
Ce genre de détail de syntaxe semble dérisoire, mais si ça rend un code plus lisible et plus agréable, ça vaut le coup.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 23/06/2005 à 16:26. (lien). Évalué à 1.Il est dommage de compenser les faiblesses d'un langage par son IDE.
Pourquoi dommage ? C'est le résultat qui compte, et avec un bon IDE, le typage devient un atout alors pourquoi s'en priver :)
Ref = new MaClasse() as MonInterface
C'est vrai que par rapport au C# ca change tout :
MonInterface Ref = new MaClasse();
Ce genre de détail de syntaxe semble dérisoire, mais si ça rend un code plus lisible et plus agréable, ça vaut le coup.
Désolé je trouves que MonInterface Ref est aussi lisible, voir plus ;)
De toute façon quand tu cherches à faire cela c'est pour "s'imposer" d'utiliser l'interface et non le véritable type. Imagine par exemple que tu es une classe A qui implémente 2 intefaces :
interface A{
string ToString();
}
interface B{
string ToString();
}
Ma classe est alors :
class C : A, B
{
public A.ToString(){return "je suis un A ! ";}
public B.ToString(){return "je suis un B ! ";}
}
Ce qui fait qu'à l'utilisation si j'ai une référence vers un A :
A var = new C();
je n'ai pas la même chose qu'avec :
B var = new C();
quand je fais :
var.ToString()
COmment tu fais dans un langage dynamique si tu ne peux pas préciser "en dur" le type de la référence ?
Comment l'IDE peut te proposer la bonne méthode ?
Je sais comment ils ont résolu le problème en Python : ils ont pas mis d'interface ;)-
[^]Re: Ruby On Rails
Posté par bobefrei () le 24/06/2005 à 11:20. (lien). Évalué à 1.On n'a pas toujours accès à un bon IDE et cela reste du bricolage.
Tu prends des cas particuliers alors que le type d'écriture dont je parle est faite pour améliorer le cas général.
Pour ton exemple avec les classes A, B, C, ce n'est pas un problème:
A var = new C(); serait remplacé par var = new C() as A;
Mais l'avantage du calcul automatique des types n'est pas à la création mais à l'affectation, aux paramètres...
Si tu écris A = B, A prends le type de B, pas besoin de le préciser sauf si tu veux faire une conversion ou utiliser un sous-type.
Autre exemple prends la fonction:
int addition(int a, int b)
{
return a + b;
}
N'est-il pas plus simple d'écrire:
addition(a, b)
{
return a + b;
}
Comme on fais une addition, a et b seront:
- des nombres entiers ou flottants avec un typage laxiste comme en Java/C++.
- des entiers avec typage plus strict comme OCAML où l'addition entre nombres flottants s'écrit +., car il s'agit d'une opération différente.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 11:56. (lien). Évalué à 1.On n'a pas toujours accès à un bon IDE et cela reste du bricolage.
Gni ? Tu peux t'expliquer là ?
Tu prends des cas particuliers alors que le type d'écriture dont je parle est faite pour améliorer le cas général.
Pas du tout, j'utilises en permanence les interfaces. Ce n'est pas un cas particulier, il arrive de devoir implémenter des interfaces qui ont les mêmes méthodes.
A var = new C(); serait remplacé par var = new C() as A;
Mon dieu c'est ouachement plus kler :) Ca change strictement rien au niveau visibilité. Et tu ne m'expliques toujours pas comment en Python tu ferais pour dériver 2 méthodes avec la même signature provenant de 2 classes différentes.
N'est-il pas plus simple d'écrire:
addition(a, b)
{
return a + b;
}
Ah bah oui comme ca je vais pouvoir faire :
addition(patate, carotte)
et paf belle erreur de runtime.
C'est magnifique dis donc. T'en a d'autres des comme ca ?-
[^]Re: Ruby On Rails
Posté par bobefrei () le 24/06/2005 à 13:13. (lien). Évalué à 2.> Gni ? Tu peux t'expliquer là ?
T'as déjà développer autre chose que des sites avec J2EE ou .NET? Je développe souvent pour PDA (Pocket PC, Palm) et plus rarement pour des systèmes embarqués, récemment j'ai fait des applications de tests de charge en cluster... Dans ces environnements, il n'y a pas toujours d'IDE complet disponible ou ton employeur n'en achètes pas ou ta machine de travail n'est pas assez puissante pour en faire tourner un, etc.
>Pas du tout, j'utilises en permanence les interfaces.
Parce que tu utilises toujours le même langage, il y a d'autres paradigmes...
>Ah bah oui comme ca je vais pouvoir faire :
>addition(patate, carotte)
Si patate et carotte ne sont pas des entiers, tu auras une erreur pendant la phase de vérification, pas à l'exécution.
> C'est magnifique dis donc. T'en a d'autres des comme ca ?
Lis ça avant de prendre un ton ironique qui montre que tu n'as rien compris: http://en.wikipedia.org/wiki/Type_inference(...)-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 13:25. (lien). Évalué à 2.Dans ces environnements, il n'y a pas toujours d'IDE complet disponible ou ton employeur n'en achètes pas ou ta machine de travail n'est pas assez puissante pour en faire tourner un, etc.
Bah pour les PDA, y'a Visual Studio.
Et franchement sur ce genre de machine t'as le problème des perfs tout de même, alors bon Ruby & Co voilà quoi. Faudrait pas faire n'importe quoi non plus. Sur tes clusters aussi tu fait mumuse en Python ? Non mais franchement.
Parce que tu utilises toujours le même langage, il y a d'autres paradigmes...
Yahooooo... Donc c'est quoi les paradigme révolutionnaire de Python ? Non parcque mon paradigme c'est l'objet, les Design Pattern, etc, c'est pas limité à un seul langage, c'est reconnu et fortement répendu.
Si patate et carotte ne sont pas des entiers, tu auras une erreur pendant la phase de vérification, pas à l'exécution.
Ah bon ? Quel vérification ? Par quel outil ?
Si je fais :
if(rand() < 0.5)
o = new Carotte
else
o = new Patate
addition(new Patate, o)
Il va se passer quoi ? Tu m'expliques ?
Lis ça avant de prendre un ton ironique qui montre que tu n'as rien compris
Je sais très bien j'ai déjà codé en Caml. C'est pas le problème. Je critiques pas Caml, je critiques les langages comme Python ou Ruby qui ont un typage exclusivement dynamique et où l'inférence de type est impossible à établir (because en Python tu peux "modifier" une classe dynamiquement).-
[^]Re: Ruby On Rails
Posté par bobefrei () le 24/06/2005 à 13:48. (lien). Évalué à 2.> Bah pour les PDA, y'a Visual Studio.
Pour Pocket PC uniquement et il coute cher.
>Et franchement sur ce genre de machine t'as le problème des perfs tout de même, alors bon Ruby & Co voilà quoi.
Pour la petite histoire:
.NET est très très lent sur Pocket PC certainement parce que Winforms est pourri, car dans mon équipe on obtient des programmes plus réactifs avec une autre solution avec un serveur web embarqué et des pages HTML/Javascript...
Yahooooo... Donc c'est quoi les paradigme révolutionnaire de Python ?
Arrête de tout ramener à Python, ça fait au moins 8 posts qu'on parle des langages en général!
Ah bon ? Quel vérification ? Par quel outil ?
Si je fais :
if(rand() < 0.5)
o = new Carotte
else
o = new Patate
addition(new Patate, o)
Il va se passer quoi ? Tu m'expliques ?
Tu auras une erreur, car:
- soit o n'existait pas avant, donc il n'est dans l'espace de nom de la ligne addition(new Patate, o), mais dans celui du if et du else. Ce sont d'ailleurs deux variables o distinctes.
- soit o existait avant et il aura donc un type, par exemple Carotte, et la ligne o = new Patate sera donc incorrecte.
Pour l'application de ce principe à des langages en gardant le côté dynamiques, il faudrait l'introduire sous forme d'avertissement ou ajouter un mot clef pour dire qu'une classe peut être modifié dynamiquement ou non...-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 13:59. (lien). Évalué à 2.Pour Pocket PC uniquement et il coute cher.
Visual Studio Express c 50$. Si ta boite est pas prêt à payer ca voilà quoi.
.NET est très très lent sur Pocket PC certainement parce que Winforms est pourri, car dans mon équipe on obtient des programmes plus réactifs avec une autre solution avec un serveur web embarqué et des pages HTML/Javascript..
Blablabla. Mauvais codeur, changer de codeur, pas de techno.
Arrête de tout ramener à Python, ça fait au moins 8 posts qu'on parle des langages en général!
Oué je viens de me rendre compte qu'on discutait pas mal dans le vide parcque justement on parlait pas de la même chose. Moi je parlais Ruby et Python (qui sont très similaire) et qui sont les sujets de la news.
- soit o existait avant et il aura donc un type
Faut savoir le type est défini ou il ne l'est pas ?-
[^]Re: Ruby On Rails
Posté par bobefrei () le 24/06/2005 à 14:27. (lien). Évalué à 2.>Blablabla. Mauvais codeur, changer de codeur, pas de techno.
Arg je m'avoue vaincu devant une argumentation aussi bien construite, basée sur des preuves irréfutables, issu d'une profonde réflexion et surtout très constructive.
>Faut savoir le type est défini ou il ne l'est pas ?
Blablabla, oui par inférence, tu comprends rien à rien.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 14:46. (lien). Évalué à 2.Arg je m'avoue vaincu devant une argumentation aussi bien construite, basée sur des preuves irréfutables, issu d'une profonde réflexion et surtout très constructive.
Bah non mais bon tu me sors une phrase comme ca pif paf poum venant de nulle part remetant unilatéralement en cause une techno sans supposer un seul instant que le jugement du codeur pouvait être biaisé par ses compétences et son expérience. Je répond à ton argumentation pertinente par une autre toute aussi pertinente ;)
Blablabla, oui par inférence, tu comprends rien à rien.
Je viens de t'expliquer que je parlais de langages compilés avec typage statique et fort vs langages à typage dynamique comme Ruby ou Python. Donc arrête de la ramener avec l'inférence, je trouve ca cool l'inférence, je trouve Caml cool. Voilà. Je vais arrêter la conversation là si tu ne veux absolument pas revenir dans le sujet de la conversation.-
[^]Re: Ruby On Rails
Posté par bobefrei () le 24/06/2005 à 15:08. (lien). Évalué à 2.>venant de nulle part
Pas de nulle part, elle vient du travail que l'on fournit en ce moment comme je l'ai dis. Ce n'est pas biaisé par nos compétences, tu peux faire l'expérience suivante:
Prends le compact framework, un pocket pc et VS.NET.
Dessine un formulaire dans l'éditeur avec une vingtaine de contrôles dessus.
Mesure le temps qu'il faut pour l'afficher.
Sans avoir tapé une seule ligne de code, ça va déjà mettre 10s se charger... On est obligé de gérer un système de cache pour compenser cette lenteur.
Pour revenir au type dynamique vs typage fort, si tu ne veux pas prendre en compte les outils annexes qui permettent de faire des vérifications sur les langages dynamiques comme cela t'as été signalé dans les posts précédents...-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 15:15. (lien). Évalué à 2.Sans avoir tapé une seule ligne de code, ça va déjà mettre 10s se charger... On est obligé de gérer un système de cache pour compenser cette lenteur.
Vas-y envoi moi les 2 programmes, le serveur web+html et l'appli WinForms que je compares.
Pour revenir au type dynamique vs typage fort, si tu ne veux pas prendre en compte les outils annexes qui permettent de faire des vérifications sur les langages dynamiques comme cela t'as été signalé dans les posts précédents...
C'est pas du tout au point, et comme je te l'ai dis, le langage en soit ne le permet pas, bref ces outils ne seront jamais parfait, on n'aura jamais aucune certitude par rapport à un langage typé statiquement avec une norme bien définie.
De plus même avec la présence de ces outils (en supposant qu'ils existent et qu'ils soient performants), cela n'améliorera pas intrinséquement lespossibilités d'optimisations nombreuses qu'apporte le typage statique.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 15:23. (lien). Évalué à 2.Pour reprendre ton exemple :
addition(a,b)
{
return a+b
}
dans un langage dynamique ala Python/Ruby.
Je veux déployer ma superbe bibliothèque mathématique, mais avant je veux vérifier qu'elle ne plantera pas trop chez ses utilisateurs.
Je la passe avec le superoutilquitue. Que vas-t-il faire ?
Il ne va quand même pas me dire que y'a une erreur : dans bien des cas cela va marcher et je voulais justement éviter de typer. Et même s'il me dit que y'a une erreur que dois-je faire ?
C'est la philosophie même de ces langages qui va à l'encontre de toute tentative de typage statique et donc de vérification à priori. C'est ca que je critiques dans un cadre de qualité logicielle. CAML n'entre évidemment pas dans cette catégorie de langages.
-
[^]Re: Ruby On Rails
Posté par bobefrei () le 24/06/2005 à 15:39. (lien). Évalué à 2.>Vas-y envoi moi les 2 programmes, le serveur web+html et l'appli WinForms que je compares.
Pour la winform tu peux le faire toi même, crée un projet bidon et mets une forme avec des contrôles. Par contre l'autre appli, je n'ai pas le droit de la sortir d'ici, mais le serveur web vient des outils d'iAnywhere mBusiness tu dois pouvoir télécharger une démo sur leur site.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 15:42. (lien). Évalué à 2.Et c'est quoi le langage dynamique qui tourne derrière ? Python ? Ruby ? PHP ? Nan parcque bon on peut faire un serveur web en .NET, et si les perfs sont comparable à ce qu'on optient sur PC je vais rigoler :)
-
[^]Re: Ruby On Rails
Posté par bobefrei () le 26/06/2005 à 13:49. (lien). Évalué à 2.Tout est fait en HTML+Javascript.
Dans une application de ce type, deux tâches demandent des performances: l'affichage et la gestion des données. Les langages de scripts les délèguent au navigateur web ou à des API comme Qt ou GTK pour la première et à un SGBD pour la seconde.
L'errreur de Microsoft avec le Compact Framework c'est d'avoir voulu faire de Winform un simple binding vers la GUI de win32. Résultat c'est super lent.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 26/06/2005 à 21:14. (lien). Évalué à 2.Tout est fait en HTML+Javascript.
Yahoo, t'as une appli qui fait rien de dynamique, bref c'est quasiment pas une appli. Forcement, c'est facile de comparer...
Dans une application de ce type, deux tâches demandent des performances:
Oué effectivement quand t'as une appli qui fait rien c'est facile. Si t'as pas besoin d'appliquer d'algo pour manipuler les données, etc.
Maintenant fait une vrai appli HTML puisque c'est rapide sur ton PDA qui demande, aller soyons fou, un peu de "dynamisme", tu vas être obligé d'utiliser autre chose que le simple JAvascript, un truc ala PHP, qui par exemple à besoin de charger des données dans une base. Et là .NET se démerde très bien, .NET est même réputé pour ses hautes perfs dans le domaine serveur web. ON va rire quand on va sortir un interpréteur PHP ou Python côté serveur web sur le PDA.
L'errreur de Microsoft avec le Compact Framework c'est d'avoir voulu faire de Winform un simple binding vers la GUI de win32. Résultat c'est super lent.
Genre c'est vrai t'utilises un langage comme Python ou Ruby, ca sera pas du tout un binding vers la GUI de Qt ou GTK.
Franchement tes arguments sont bidons, tu compares jamais ce qui est comparable. Comparer une page HTML+javascript avec une plateforme comme le Compact Framework voilà quoi. ENfin ca confirme un peu ce que je disais à la base : quand le dev ne sait déjà pas choisir les bons outils adapter aux bons besoins...-
[^]Re: Ruby On Rails
Posté par bobefrei () le 27/06/2005 à 07:48. (lien). Évalué à 2.Tu trouves mes arguments bidons parce que tu ne te renseignes pas avant de poster et que tu préfères raconter n'importe quoi juste pour le plaisir répéter ton mantra ".NET c'est mieux" plutôt que de chercher à découvrir et comprendre l'intérêt des autres plateformes.
Fais toi engager comme consultant Microsoft ou Sun, tu y seras plus utile que sur linuxfr...-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 27/06/2005 à 08:50. (lien). Évalué à 2.tu ne te renseignes pas avant de poster
Pas besoin de me renseigner pour être persuadé qu'aucun framework graphique n'est écrit dans un langage de haut niveau comme Python ou Ruby, et en déduire qu'il est tout à fait normal qu'ils aient le même système de binding que les WinForms au dessus de win32. Il n'y en a qu'un qui l'a fait : Java avec AWT/Swing, et quand on voit le résultat on comprend l'intérêt des bindings.
Désolé j'ai essayé d'argumenter. Tu essai de me démontrer que .NET c'est lent sur PDA comparé à une page HTML+Javascript. Comment veux-tu qu'on arrive à quelque chose ! Pourquoi tu ne fais pas un peu plus preuve d'honnêteté dans tes comparaisons ?-
[^]Re: Ruby On Rails
Posté par bobefrei () le 27/06/2005 à 09:11. (lien). Évalué à 2.Tu essai de me démontrer que .NET c'est lent sur PDA comparé à une page HTML+Javascript. Comment veux-tu qu'on arrive à quelque chose ! Pourquoi tu ne fais pas un peu plus preuve d'honnêteté dans tes comparaisons ?
Et ton honnêteté c'est de parler sans vérifier?
C'est ce que je constate pour notre application, point. On a fait deux maquettes, l'une avec les outils Microsoft, l'autre avec les outils Sybase. Le résultat est là. Si ça ne concorde pas avec tes croyances tant pis.
Je suis ingénieur pas propagandiste, mon but c'est de prendre la meilleure solution. Sur mon précédent projet, le CF était préférable, car il y avait des graphiques complexes à faire. Sur l'actuel, c'est surtout de la gestion de données et de la synchro, le framework Sybase est plus adapté.
Les langages de scripts ont largement leur place à côté des plateformes plus lourdes. Répéter sans cesse le contraire sans chercher leurs avantages, c'est ça qui est malhonnête.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 27/06/2005 à 09:47. (lien). Évalué à 2.Les langages de scripts ont largement leur place à côté des plateformes plus lourdes. Répéter sans cesse le contraire sans chercher leurs avantages, c'est ça qui est malhonnête.
Mais tout à fait, je suis entièrement d'accord, quand une page HTML avec Javascript suffit, il n'y a aucun intérêt d'utiliser l'artillerie lourde comme le Compact Framework. D'où mon étonnement depuis le départ , et ma remarque comme quoi il faut parfois savoir choisir des technos adaptées.
Tu me dis de tester, je veux bien, mais tu veux pas me filer ton "appli" HTML+Javascript. Alors donne moi plus d'infos au moins : que fait l'appli ? gestion persistence ? traitement des données ?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Ruby On Rails
Posté par bobefrei () le 24/06/2005 à 13:29. (lien). Évalué à 2.>Et tu ne m'expliques toujours pas comment en Python tu ferais pour dériver 2 méthodes avec la même signature provenant de 2 classes différentes.
En Python je ne sais pas, je n'en fait pas souvent. Pourquoi tu me parles de Python?-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 24/06/2005 à 14:01. (lien). Évalué à 2.Parcque depuis le début on parle des langages inteprété à typage dynamique.
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Ruby On Rails
Posté par Éric (Jabber id, page perso, ) le 21/06/2005 à 18:07. (lien). Évalué à 2.> En même temps tu prends exemple sur PHP qui est un langage interprété avec un
> typage dynamique.
> Moi je te parle de C++, Java ou C#, avec un vrai compilo qui vérifies le typage
> statiquement (quand c'est possible) et vrai IDE.
Tu n'as pas compris. Je parle de développer PHP, pas de développer "avec" PHP. Je parle donc bien de développer en C ou C++ (ici c'était du C++ mais ça ne change pas grand chose) avec un vrai compilo et un typage statique.
Et oui c'était horriblement lent. Dans les dernières phases je passais plus de temps en compil qu'en test/modif
> T'auras beau dire tout ce que tu veux, le compilo fait un nombre incalculable de
> tests, surtout avec un langage à typage fort et statique.
Oui. La question c'est : est-ce qu'il est indispensable que ton langage à typage fort et statique soit un langage compilé pour pouvoir faire ce genre de vérification ? la réponse est "non".
Donc non, que tu le veuilles ou non la compilation n'est pas nécessaire pour ta phase de test et non le fait de vouloir controler tous les types n'est pas une raison pour supporter la compilation.
> Visiblement tu n'as rien compris à ce qu'est un compilo, à ce qu'il est censé faire.
> Il n'est pas censer que "pondre" du code, un compilo c'est avant tout un
> analyseur lexical et syntaxique qui constitue une première couche de TESTS et un
> générateur de code. C'est loin d'être seulement la 2ème partie.
Je ne dis pas le contraire, mais il passe aussi un temps non négligeable sur tout le reste (pour reprendre mon exemple, recompiler les fichiers modifiés c'était rapide, c'était pour reconstruire les libs et binaires derrière avec toutes les liaisons qui était long, et là les contrôles de types et l'analyse lexicale étaient déjà faits).
Que tu veuilles faire toute cette analyse je comprend. Mais non faire toute cette analyse ne justifie pas de passer du temps supplémentaire pour faire la compilation.
Tu peux t'en servir comme ça, mais tu perd inutilement du temps sur des trucs qui ne servent pas à tester, et donc qui sont inutiles à ton but premier.-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 22/06/2005 à 07:35. (lien). Évalué à 2.La question c'est : est-ce qu'il est indispensable que ton langage à typage fort et statique soit un langage compilé pour pouvoir faire ce genre de vérification ? la réponse est "non".
Arf evidemment vu comme ca. Mais bon d'une manière générale les langages dynamiques interprétés ne sont justement pas typés fortement, et encore moins statiquement.
Pour le reste je suis assez d'accord. En fait je crois que votre préocupation concernant la vitesse de compilation cible avant tout C++. J'avoue que C++ voilà quoi, ca me gave et effectivement, pour peux qu'on utilise beaucoup les templates... Je préfères largement coder en C# ou Java, là je n'ai pas ces problèmes de compilation "lente", et donc pour moi le compilo n'est qu'une étape sans aucun désavantage.-
[^]Re: Ruby On Rails
Posté par Éric (Jabber id, page perso, ) le 22/06/2005 à 08:52. (lien). Évalué à 3.> Mais bon d'une manière générale les langages dynamiques
> interprétés ne sont justement pas typés fortement, et encore moins
> statiquement.
Typage fort beaucoup de langages le sont (reste à voir ce qu'on met derrière le terme de typage fort mais je pense qu'il y a pas mal de langages qui peuvent valider ça). Typage statique effectivement, c'est moins habituel.
Mon idéal pour le genre d'appli auxquelles je participe ça serait un langage interprété ou semi interprété, types forts, avec un typage statique optionnel et un analyseur de code :
- tu profites de l'interpréteur "ca s'exécute à la moindre modif" voire du "debuggueur en cours de frappe"
- tu profites du typage statique : tu rajoutes les contraintes de type si tu le souhaites là où le code est plus délicat ou si tu souhaites renforcer les contrôles pour valider ton code
- tu as un analiseur potentiellement lent et long qui sait faire de la détection de type quand tu ne l'a pas déclaré toi même, et sait exploiter les types statiques pour vérifier les concordances.
Le problème c'est que je ne suis pas sûr que le tout soit conciliable avec la notion de langage dynamique tel qu'on la voit dans un python ou un ruby-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 22/06/2005 à 09:07. (lien). Évalué à 2.- tu profites de l'interpréteur "ca s'exécute à la moindre modif" voire du "debuggueur en cours de frappe"
Le prochain Visual Studio permet cela avec des langages comme C#. Je me demandes comment ils font mais visiblement pas besoin de garder le fardeau de l'interpréteur (qui mine de rien en est un question perf).
tu rajoutes les contraintes de type si tu le souhaites là où le code est plus délicat ou si tu souhaites renforcer les contrôles pour valider ton code
J'aime pas le "si" tu le souhaites. Je préfères que le langage le contraigne au développeur, pour le "forcer" à produire un code de meilleur qualité. C'est aussi ca le rôle d'un langage : ne pas être trop laxiste et forcer l'utilisateur. L'excuse du gain de temps en ne typant pas n'est pas du tout valable pour moi.-
[^]Re: Ruby On Rails
Posté par Éric (Jabber id, page perso, ) le 22/06/2005 à 09:45. (lien). Évalué à 4.> Le prochain Visual Studio permet cela avec des langages comme C#.
Intéressant.
> J'aime pas le "si" tu le souhaites. Je préfères que le langage le
> contraigne au développeur, pour le "forcer" à produire un code de
> meilleur qualité.
J'ai toujours eu l'opinion inverse en fait. L'informatique, la programmation, le langage, ce sont des outils pour aider l'utilisateur et le développeur. Dès qu'ils deviennent une contrainte c'est qu'il y a un défaut quelque part dans la procédure.
Si le développeur veux mettre des types partout il faut que le langage lui permette. Si le développeur pense aller plus efficacement sans les contrôles de type à court terme qu'il le fasse aussi. Si tu veux une contrainte alors demande à ton analyseur de code de te mettre un warning à chaque type manquant, mais ce n'est pas le rôle du langage.
Si tu veux forcer une syntaxe limitée pour rendre clair le code je comprend. Par contre je ne vois pas de raison de forcer le développeur à mettre des contrôles s'il n'en veut pas. S'il en veut il est assez grand pour les mettre et demander à un outil de vérifier qu'il les met.
Pour les gains de temps en développement je pense que ça dépend des habitudes. En fait je suis sûr de perdre du temps en typant mais je suis sur que ça se regagne de l'autre coté avec l'IDE qui peut proposer des completion plus pertinentes et plus souvent, ou aider beaucoup plus à la frappe. Ce qui me gêne beaucoup plus c'est la lecture du code qui contient tous les contrôles (types, accès, ...). C'est en général super lourd à lire et ça ça joue beaucoup dans la clarté pour quelqu'un qui n'a pas l'habitude. Je le comprend dans une phase de stabilisation/test, mais dans la phase de développement/conception je préfère un code clair et concis avec le moins de contrôles possibles.-
[^]Re: Ruby On Rails
Posté par Fabien Penso (Jabber id, page perso, ) le 22/06/2005 à 11:02. (lien). Évalué à 1.Dès qu'ils deviennent une contrainte c'est qu'il y a un défaut quelque part dans la procédure.
Bah tiens... Prends un projet de 1 million de ligne de code, avec 50 développeurs, sur une durée de 3 ans, réfléchis au problème d'en être chef et tu comprendras tout l'intérêt d'utiliser un langage qui donne des obligations, surtout quand 20% des développeurs sont des incompétents que tu peux pas virer pour pleins de raisons.-
[^]Re: Ruby On Rails
Posté par Éric (Jabber id, page perso, ) le 22/06/2005 à 11:53. (lien). Évalué à 2.> Bah tiens... Prends un projet de 1 million de ligne de code, avec 50
> développeurs, sur une durée de 3 ans
Oui, mais des projets de 150 ans/homme on en trouve pas non plus tous les jours. Ca n'est pas forcément représentatif. En tout cas ça ne concerne pas tout le monde.
Mais ce que tu dis ne contredit en rien mes propos. Tu es chef ? tu veux contrôler plus ton projet ? alors tu imposes à tes équipes de passer par l'analyseur qui contrôle les types.
Il n'y a aucune raison pour imposer à sur le langage (donc à tout le monde) juste pour quelques projets de taille énorme. Je ne dis pas que le contrôle est mal, ce que je dis c'est qu'il faut que ce soit un choix, pas une contrainte. Si c'est ton choix ou celui de ton chef tu lances cette vérification, ça s'arrête là.
Puis bon, si tes développeurs sont incompétents ce n'est malheureusement pas un typage statique contrôlé qui va résoudre tes problèmes ;)-
[^]Re: Ruby On Rails
Posté par Frederick Ros (page perso, ) le 22/06/2005 à 12:01. (lien). Évalué à 1.>Puis bon, si tes développeurs sont incompétents ce n'est malheureusement pas un typage statique contrôlé qui va résoudre tes problèmes ;)
Tu l'as dit .. des sous-equipes sur de petites parties, des unit-test obligatoires (mieux du TDD) et de la revue de code .... c'est quand meme mieux non ?-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 22/06/2005 à 12:09. (lien). Évalué à 2.Non c'est pas mieux du tout.
Y'a mieux : des sous-equipes sur de petites parties, des unit-tests obligatoire, de la revue de code... et du typage statique.-
[^]Re: Ruby On Rails
Posté par Frederick Ros (page perso, ) le 22/06/2005 à 13:32. (lien). Évalué à 1.> et du typage statique.
Sans rentrer dans votre debat, je ne suis pas forcement pour ... :) Viva el Duck Typing !
-
-
-
[^]Re: Ruby On Rails
Posté par TImaniac (page perso, ) le 22/06/2005 à 12:07. (lien). Évalué à 2.Oui, mais des projets de 150 ans/homme on en trouve pas non plus tous les jours.
Non mais des projets de plusieurs centaines de milliers de ligne de code avec plusieurs développeurs sur plusieurs années il y en a une floppée, je dirais même que c'est la majorité. Et bizzarement dans tous ces projets tu retrouve rarement du Python ou du Ruby ;)
En espérant juste que ton logiciel ne devienne pas plus ambitieux.
alors tu imposes à tes équipes de passer par l'analyseur qui contrôle les types.
Tu te prends pas la tête et tu imposes un langage typé statiquement et fortement, auquel toute ton équipe est de préférence habitué.
. Je ne dis pas que le contrôle est mal, ce que je dis c'est qu'il faut que ce soit un choix, pas une contrainte.
Bah voilà c'est bon, on a déjà ca : pour les vrais gros projets où tu recherches un minimum de qualité tu prends un langage typé, compilé (parcque bon tu veux aussi des perf
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
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.