TImaniac a écrit 6423 commentaires

mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique. La théorie c'est bien, si elle a pour objectif d'améliorer la pratique, mes critiques ne vont que dans ce sens.

Parce que j'y crois, et te prierai de ne pas me casser mes rêves ;-)
Rêver est une chose, prendre ses désirs pour des réalités en est une autre. Ce que je te reproche ce n'est pas ton approche théorique des langages informatiques mais le ton prétentieux que tu y ajoutes. Un peu d'humilité dans l'approche servirait bien mieux tes propos, ne serait-ce qu'à cause du nombre important de langages "joli d'un point de vue théorique" qui n'ont jamais dépassé le cadre universitaire.

Je te rappelle que les [a href="http://isaacproject.u-strasbg.fr/li/li_benchs.html"]benchs[/a] montrent qu'on peut être plus rapide que du C avec 40% de lignes de code en moins.
Merci de parler enfin des réels atouts de Lisaac (même si on en avait déjà parlé dans d'autres journaux).
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens, la première qualité de la syntaxe réside pour moi dans sa lisibilité et dans sa facilité de relecture par une tierce personne. Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac, en précisant que pour moi c'était plus un boulet qu'un atout dans la vraie vie de programmeur... tu veux pas argumenter là dessus ?
Concernant la vitesse, je doute que vous obteniez des gains exceptionnel style de facteur 4 ou 5. Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?
L'approche d'optimisation "par le bas" au niveau assembleur à l'aide de matos spécialisé a des améliorations bien plus importantes. A quoi sert de gagner 20% de temps d'encodage d'une vidéo en MPEG2 quand un encodeur hard va te faire gagner 300% de temps ?
Une piste beaucoup plus intéressante à mon sens c'est la parallélisation. Je te vois venir avec tes grands sabots, tu vas me dire que ca tombe bien Lisaac enlargeant ton penis il va aussi me permettre de paralléliser le bousin tout seul. Je veux du concrêt. Parcque le coup du "ca marche en théorie" se finit souvent par "ca marchera jamais en pratique".

- Un langage système permettant d'écrire un OS, sans nécessiter autre chose que quelques lignes d'assembleur.
Mouaich. Et vous avez résolu le problème des ressources nécessaires pour compiler le bouzin ? Parcqu'un OS c'est pas un simple encodeur.
Et le problème de la modularité ? Vous allez systématiquement devoir faire le choix entre optimisation globales qui va tendre vers du monolithique et souplesse d'architecture qui empêchera les optimisations globales et donc l'intérêt du langage.

Alors effectivement, toi, ingénieur d'informatique de gestion, tu t'en tapes des perfs, et c'est normal.
Non je m'en tapes pas, y'a pleins de moment où c'est critique. Je fais dans l'audio/vidéo, et je t'assures que ca devient problématique de faire tourner des algos de reconnaissance vidéo en temps réel sur un flux encodé en H264. Et là t'es content d'avoir des décodeurs hardware.

Pour le moment, pour être réaliste, elle s'adresse principalement aux codeur des domaines de l'embarqué, des système où le C est obligatoire.
Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ? Sachant que j'ai soulever des inconvénients qui sont valables dans le cadre de l'embarqué également : modularité, constructions syntaxique standard vs personnalisées, etc. Sans parler du fait que même dans le monde de l'embarqué des critères comme la portabilité et la sécurité peuvent être mis en avant...

Il est vrai que la TODOliste est encore énorme, et ce compilateur deviendra de plus en intéressant :
Pour moi le plus urgent reste de résoudre les problèmes qui ferait de Lisaac un langage utilisable. Après vous pourrez poursuivre les optimisations. Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là et qu'au final le principe même du langage ne répond pas aux besoins des ingénieurs, quel est l'intérêt ?

J'ai autant l'impression que les atouts de Lisaac résident dans le compilo que dans le langage, des atouts du compilo ne peuvent-ils par être repris dans d'autres langages pour les améliorer ? Ne serais- ce pas une approche plus "utile" ?

mais il a un énorme potentiel, et je veux au moins tenter l'aventure.
Moi j'ai surtout peur que vous passiez à côté de certaines qualités essentiels d'un langage de nos jours. Les perfs et la beauté du code, c'est pour moi de l'époque ancienne. Au temps des hackers. C'est toujours des critères valides dans de nombreux domaines, mais ils ne sont plus suffisant.

Sinon en master, si il y en a qui n'ont jamais fais de programmation objet à défaut de java, ils viennent d'où ? d'une licence info ? parce que c'est quand même un peu gros là.

Oué je me suis un peu perdu dans le nouveau découpage universitaire :) A l'époque je débarquais de post-DUT en licence (bac+3), donc les autres venait de l'équivalent de licence 2 math/info. Mais bon globalement en info je me suis fait chier en licence (à bac+3 donc), en maîtrise aussi parcque bon on a pris de l'avance en licence pour s'occuper, et en fait y'a qu'en dernière année qu'on avait l'impression de voir le côté "ingénieur".

Cela dit je comprend la problématique de faire apprendre de l'informatique à l'entrée en fac à des gens qui ne seront pas destinés à en faire. Cela dit j'ai plus l'impression que la question n'est pas là : j'ai l'impression qu'on fait apprendre des langages "académiques" parcque bon on sait jamais, il va peut être finir chercheur et pas ingénieur, il faut donc mieux un langage conceptuel. Mais bon dans la vraie vie c'est 90% d'ingénieurs/développeurs et pas des chercheurs. Manque de bol c'est 90% de chercheurs comme profs.
A mon avis il faudrait mieux présenter du Java (ou du Pascal ou du C, enfin un truc proche de la vraie vie quoi) même dans les premiers modules de fac : ca motiverait probablement pas les mêmes gens.
En tout cas une fois arrivée à Bac+5 on a pas du tout le même bagage technique au final, et ca se ressent à l'entrée dans le monde du travail. Heuresement, le Java est facile à apprendre sur le tas, mais faut plus espérer leur demander coder en C++ :-( Tu leur dis gentiment que ca sert à rien de mettre Scheme ou Lisp dans leur CV entreprise...

Moi ce que je vois dans ce classement, c'est ce que je constate dans la vraie vie : le support du matos se perd. Regarder la position d'ubuntu 7.10 par rapport à la 6.10 ou la 5.05. L'inverse aurait été plus logique non ?
En fait non, c'est conforme à ce que je constate : en 4 ans d'utilisation de Linux sur une même machine, la carte réseau n'a plus été supportée après je sais plus quel migration d'une fedora x à une fedora x+1 (je l'ai changé), l'installation d'une ubuntu m'a fait perdre le support du tuner TV de ma radeon AIW... et l'installation encore plus récente d'une opensuse 10.3 m'a carrement fait comprendre que ma radeon était has been (impossible de la faire marcher et c'est pas faute de bidouiller du xorg.conf). Quand j'avais acheté un écran 20" Wide, obligé de me farcir du xorg.conf pour cette résolution "non standard'' (qui existait quand même depuis 2 ans à Darty).
Alors à part l'installation d'un nouvel écran, le reste n'a été que régression de support de matos.
Voilà mon expérience, le support matos Linux, c'était mieux avant. Bon troll ;)

Je comprends tout à fait ta comparaison.
Cela dit le designer a intérêt à prendre ne compte les contraintes de la vraie vie, imagine la maquette d'une voiture, la voiture peut être belle mais pas aérodynamique pour 2 sous et consommer 3 tonnes d'essences.

Mais effectivement on ne peut pas faire que critiquer Lisaac. Celà dit je trouve intéressant de soulever certains points de comparaison avec les langages "modernes" actuels. Rien ne montre effectivement qu'il n'est pas possible de cibler une machine virtuelle en Lisaac. Mais faut y penser dès le début si c'est un réel objectif (je ne crois pas que ca soit le cas de toute façon) : une machine virtuelle impose des contraintes (jeu d'instruction, gestion mémoire, gestion des droits, etc.) que le langage doit prendre en compte et des fonctionnalités qui peuvent/doivent être exposées.

La 2ème question à se poser c'est la pertinence de certains choix fait dans Lisaac, notamment le côté "simple" de la grammaire permettant d'augmenter facilement les constructions syntaxique (simuler une boucle for while ou un autre truc innovant). C'est joli, bandant... oui mais pourquoi Java ou C# ne propose pas ce genre de chose ? (c'est pas une nouveauté en soit)
Ce qui peut paraître séduisant en premier abord et vu comme une qualité dans un objectif "universitaire" peut être un boulet dans la vraie vie. Regardons le C++ : mine de rien ont peut reproduire la syntaxe de pleins d'autres langages uniquement avec le système de macro (j'ai même vu du Lisp en macro C++... et pourquoi pas du Lisaac, soyons fou ;) ). On en arrive à des constructions en C++ qui sont sûrement bandantes pour le hacker qui l'a codé, mais qui sont imbittable par le commun des mortels, et j'en vois tous les jours.
En limitant à l'aide de mots clés (for while foreach, etc.) les constructions les plus courantes, on limite certes la concision et l'expressivité, mais on améliore aussi la compréhension du code par une autre personne. C'est probablement ce qui a fait une partie du succès de Java. Beaucoup d'autres simplifications également. Ce qui apparaît comme des contraintes pour un "universitaire" est en fait un atout dans la vraie vie. Lever ces contraintes comme le propose Lisaac élimine une qualité essentielle d'un code source. Et dans le mondre du libre on devrait être attaché à cet aspect.

Une machine virtuelle c'est pareil. En apparance c'est une érésie, les perfs s'en ressentent largement. Seulement les avantages sont aujourd'hui beaucoup plus important que les inconvénients (sécurité, portabilité, productivité, etc.) dans beaucoup de scénarios d'utilisation.

Tout ca pour dire que je ne suis pas contre avoir des langages "de recherche", "universitaire". Mais l'objectif devrait pourtant être le même : améliorer les langages offerts aux utilisateurs, répondre à leurs besoins.

Bon j'ai encore fait dérivé le sujet mais j'espère que tu trouveras ca plus intéressant comme discussion ;)

Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
En même temps j'ai pas prétendu grand chose, j'ai juste essayé de dire que je ne voyais rien de révolutionnaire qui va démultiplier les perfs ou je sais pas quoi.
Ce qui est horripilant, c'est le ton prétentieux d'Ontologia : même si ce n'est pas l'intention, ca pu systématiquement la pub à plein nez pour le langage révolutionnaire où tout est prévu. C'est pas moi qui est avancé la comparaison avec la locomotive. C'est ce genre de phrase qui forcent des réactions pas forcement constructives.
Rien que le fait que de prendre Lisaac comme exemple de langage pour parler de choses plus générale, on sent bien la mise sur un piédestral du langage. Le tout avec un air prédicateur de la future révolution en marche (je suppose que dans sa tête c'est le TGV, la locomotive c'est déjà loin).

Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires".
Oué mais bon y'a aussi beaucoup de branlette intellectuelle là dedans. Ca me gène pas en soit, c'est fort intéressant et il en découle souvent des applications pratiques plus qu'innovante. Mais sa façon de présenter les choses donne sérieusement envie de le remettre (Ontologia) les pieds sur terre, la réalité de Lisaac aujourd'hui comparé aux autres langages. Lisaac a sûrement pleins d'atout, mais il n'est pas universel et n'a pas tous les atouts réunis des autres langages et ne peut mon sens pas prétendre tous les remplacer.

Ce que j'attendais plutôt avec ma réaction initiale à la comparaison avec la locomotive, c'est une liste des atouts de Lisaac qui pourrait en faire un langage sexy face à l'existant. A la place ca a dérivé. La question reste donc posée.

M'enfin, le Java aussi on peut le mixer avec du C, et plus haut tu le cites pour ses apports en matière de sécurité, faudrait savoir.
A la grosse différence que je peux configurer la VM pour se mettre dans un contexte où ces appels natifs ne sont pas autorisés.
En Lisaac, c'est de la responsabilité de celui qui a écrit le code, vu qu'il n'y a pas de contrôle à l'exécution, bref de la responsabilité du créateur, potentiellement avec des intentions malveillantes.

C'est évident que rien ne sera prouvé sur le C !
On est d'accord. Mais il y a-t-il un mode "strict" dans le compilo Lisaac pour se mettre dans des conditions où l'ont peut espérer prouver le code ? (sans C quoi) J'ai pas trouvé mais j'ai peut être mal cherché.

et on ne parle pas de sécurité mais de prouver les contrats, cela n'a à peu pret rien voir.
J'ai parlé de sécurité dès le début, avant même de parler de preuve. J'ai pris après 2 contextes de sécurités : la sécurité offerte par les méthodes formelles pour prouver qu'un code fait bien ce qu'il doit faire (méthode B comme exemple cité), et la sécurité au sens protection contre un code malveillant (style une machine virtuelle). Relis le thread, juste après la locomotive.

Le même rapport qu'il y a avec "comme il est sans doute possible de le faire en Lisaac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charrette."
Ecoutes, visiblement il a voulu dire qu'il n'y avait pas de raison que Lisaac ne soit pas adopté, la locomotive a bien été adoptée alors que la charette existait déjà. Sous-entendu Lisaac est aussi révolutionnaire que la locomotive. Ben je cherche ce côté révolutionnaire que les autres charettes actuelles n'ont pas. J'ai pris 2 exemples de domaines sur lesquels vous n'avez rien prouvez du tout vis à vis de Lisaac à part dire "c'est prévu" qui fait plus penser à un discours pré-electoral qu'à une réalité...

http://www.linuxfr.org/comments/893742.html#893742
Bon après j'ai citer des qualités comme ca, on peut discuter d'autres trucs, ou pas.

Moué, enfin pourquoi ne pas leur apprendre directement le Java ? Enfin un langage qui a des chances d'être utilisé tôt ou tard par la majorité des étudiants.
Nan parcque franchement quand tu débarques en master et que t'as les mecs qui viennent de licence et qui te demande ce qu'est "Windows NT" et savent seulement programmer en Lisp ou en scheme, bah tu te tapes des cours de Java à BAC+4. Youpi.
Alors que là bon à ce niveau là on préfèrerai passer à autre chose, notamment tout le reste du cycle de vie d'un projet informatique qui a du coup à peine le temps d'être survolé.

Bon bah alors vas-y, montre moi que Lisaac va m'apporter de manière significative (au moins autant que la locomotive) plus de sécurité que m'en apporte les autres langages actuellement existant(Java, C#, B, etc.). Déjà je suis même pas convaincu que Lisaac en apporte autant que ces autres langages, alors delà à en apporter plus, il ne tient qu'à toi d'apporter des éléments !

Il est prévu de faire de le preuve dans Lisaac. La simplicité de la syntaxe aide à cela.
Je sais pas si ca a changé depuis la dernière fois que je me suis intéressé aux specs du langage, mais dans mes souvenirs on pouvait allègrement mixé du Lisaac avec du code écrit en C. Partant de là, niveau preuve et sécu...

Et qu'est-ce qui permet de dire cela ?
Très bonne question. Ce n'est pas moi qui est cherché à faire ce parallèle hein.
Tu crois que les lib fleuves sont l'aboutissement de tout langage ?
C'est quoi le rapport ?

Ben montre moi un programme écrit en Java (pas en bytecode hein) qui permet potentiellement de faire faire n'importe quoi à la JVM sans qu'elle s'en rendre compte.
Dans tous les cas tu peux admettres que même si une JVM n'est pas une garantie, elle offre une meilleur sécurité. Ce n'est pas certainement pas acceptable si on parle de code mal-intentionné mais c'est toujours bon à prendre pour se protéger de code mal écrit.

mais d'un coté tu dis que les langages de haut niveau sont trop complexes et n'apportent rien
J'ai écris ca où ? Je n'ai pas généralisé, je parle de Lisaac. En l'occurence je ne vois rien de révolutionnaire en pratique dans ce langage comme a pu l'être la locomotive par rapport à la charette. J'ai pris l'exemple de la sécurité (au sens qualité/bug et au sens protection contre code malveillant), c'est tout.

Choisi ton camps camarade.
Non. Ce n'est pas le but.

Tout ce que je dis est que du point de vue de l'OS
Oué c'est pas faux, mamoi j'ai juste rajouté qu'une machine virtuelle qui a un modèle n'offrant d'accès bas niveau comme une JVM ajoute une couche de sécurité en plus de l'OS.

La façon la plus simple de faire celà est d'aller modifier le bytecode d'une des classe de base.
Tu te rends bien compte que tu triches. Forcement, en java à partir du moment où tu peux écrire dans un fichier tu peux t'amuser à faire écrire à ton programme un Java un bout de code en C ou modifier un fichier de bytecode.

Bref on a tout ce qu'il faut pour envoyer la JVM dans le mur
Si la JVM est bien faite, tu dois pouvoir la configurer pour interdire au programme exécuter d'intéragir avec les .class du code exécuté. J'avoue ne pas être un spécialiste de la sécu des JVM, mais je suppose qu'une JVM configurée pour exécuter du code provenant du net (style une applet) empêche ce genre d'astuce.
En tout cas dans l'environnement .NET proche de celui de Java, l'environnement ne laisse pas les composants faire ce genre de connerie s'il ne sont pas de confiance.
Bref, y'a un modèle "virtuel" intermédiaire avant l'OS qui autorise l'application de tout un ensemple de règles de sécurité plus fines et qui sont toujorus bonnes à prendre avant l'OS.
Je vois bien une applet écrite en C qui tourne dans un navigateur web. A moins de sandboxer le navigateur dans son ensemble (ce qu'est obligé de faire MS avec IE par exemple), par défaut l'applet C pourrait faire toutes les conneries puisque tournant avec les mêmes droit que le navigateur qui héberge le code. A moins de s'amuser à forker sur un compte avec des droits réstreind toussa. Lourd, coûteux et pas forcement adapté.

Pour en revenir à la choucroute initiale, ca ne change rien au problème : Lisaac n'apportera pas grand chose de ce point de vue là.

. Le contraire serait inquiétant.
Je ne prétend rien du tout, ni dans un sens ou dans l'autre. Je dis juste que la méthode B permet de prouver le programme écrit, l'environnement t'embêtant jusqu'à ce que t'es prouvé l'intégralité de ton code. En C t'as aucune contrainte à la compilation, et à l'exécution il n'y a que l'OS pour effectuer des contrôles de sécurité.

La preuve permet de certifier un comportement, mais ne met pas à l'abri des plantages loin de là.
Pas besoin d'étaler ta science, j'ai jamais dit le contraire. Je dis juste que ca offre une meilleure sécurité. Il est évident qu'on n'est pas à l'abris des comportements extérieurs au programme, à commencer par ceux du matos. J'ai également cité le problème des spécifications qui sont toujours rédigées par un humain.

je suis au regret de t'apprendre qu'un programme écrit en Java a exactement les mêmes droits qu'un programme écrit en C.
Je te mets au défi d'écrire un programme en Java pur (pas d'appel à du code natif hein) qui va taper n'importe où dans la mémoire ailleur que là où elle est autorisé par l'espace que lui a allouée la VM. Tu peux pas sortir des sentiers battus (sauf faille dans la VM bien entendu), et la première barrière n'est pas l'OS mais bien l'environnement contrôlé par la VM.
Idem pour une application en ActionScript ou en C# par exemple. Le modèle de VM intermédiaire facilite grandement la vérification du code à exxécuter, et permet d'accorder plus ou moins de confiance et de droit à celui-ci. L'OS constitue une autre barrière qui vient éventuellement combler les lacunes du modèle et de l'implémentation de la VM, mais dans l'absolu ces langages offrent plus de sécurité qu'un programme écrit en C.

Le framework java permet de limiter la casse sur les plus grosses erreurs
Euh... t'appelle quoi le "framework" ? Si c'est juste l'ensemble des libs, je vois pas le rapport.

Pour être honnête je en connais pas Lissac, mais l'avantage majeur des langages de haut niveau est de permettre à des non initiés de modifier facilement une partie du programme suivant leur besoin.
Y'a des outils adaptés pour ca : moteurs de règles, moteurs de script avec langage métier dédié, etc. Lisaac se veut un langage généraliste (dans sa grammaire en tout cas), et ca c'est déjà imbittable pour la plupart des non développeurs.

Par tous les pseudos "experts" qui ont créé ce buzz. C'est pas tant la communauté Ruby que la communauté de journaleux en mal d'annonce technologique.

La difficulté de maintenance et d'évolution est liée à la difficulté du développement ...
Absoluement pas. La difficulté de maintenance et d'évolution vient plutôt des attentes des utilisateurs clients en terme de performance, de rapidité d'intervention en cas problème, de la conception en amont de la plateforme en ayant réfléchi à son "évolutivité", à son intégration éventuelle avec d'autres applications/middlewares, aux capacité de de montée en charge, etc.

Rails n'a pour l'instant pas la prétention de concurrencer PHP sur du mutualisé, c'est à dire à destination du grand public.
Voilà pourquoi entre autre Ruby ne s'est pas démocratisé comme prévu au près du grand public. L'absence d'acteur majeur est la raison pour laquelle Ruby ne s'est pas démocratisée dans les entreprises.

Perso je te dirais d'essayer Ruby et Rails mais je doute de ta partialité de jugement de toute manière.
Tu remarqueras que j'ai surtout comparé avec Java et PHP, et je peux t'assurer que je suis vraiment pas fan du 2ème :)

De toute manière la tenue en charge et les millions de users importe peu à 99% des entreprises.
En entreprise il peut y avoir d'autres sortes d'utilisateurs : des grosses applis internes (banques, assurances, etc.) qui demande des architectures N-tiers parfois avec de hautes performances.

Au final tu cantonnes toi même Ruby à un petit marché : les besoins internes des entreprises, mais qui n'ont pas trop de besoin quand même. Je rajouterai : et qui ont les compétences en interne.

Je ne doute pas que depuis les framework PHP ont été amélioré, mais Rails a et aura longtemps une longueur d'avance.
Oué bah moi je dis justement que cette longueur d'avance diminue et va bientôt être complètement effacée. Dans le monde qui m'intéresse, le framework ASP.NET MVC Framework n'a pas grand chose à envier à Rails.

Le temps de dev c'est ce qui coûte le plus....
Grossière erreur :) Ca représente kedal le temps dev dans un projet. Le plus gros du boulot c'est la maintenance et les éventuelles évolutions (liées aux fonctionnalités ou à la montée en charge).

De plus il est à mes yeux pratiquement impossible de migrer rapidement et facilement des développeurs PHP en Java.
Faut savoir, une fois ca concurrence Java et pas PHP et là tu migres depuis PHP :) Soit. En Java je sais pas, par contre j'ai déjà eu l'occasion de migrer du PHP en ASP.NET, c'est pas compliqué. Que va m'apporter RoR en plus ?

Et même s'il y a un travail plus conséquent qu'en PHP pour la tenue en charge, cela reste plus simple et rapide à développer qu'une usine à gaz en J2EE.
Ah bon ? Nan parcque je connais aucune grosse architecture en RoR justement. Un truc qui tienne la charge et des millions d'utilisateurs.

Coté IDE sort de ta grotte et regarde Eclipse / Aptana / Ruby In Steel (http://www.sapphiresteel.com/), etc.
Comparé à l'écosystème Java... Moi je veux un IDE qui me permette de tout développer dans mon architecture n-tiers, de ma couche web (avec designer graphique) à la couche d'accès aux données en passant par la couche métier et les services. Le tout intégré, avec environnement de test, d'analyse de performance, gestion de version, etc. Nan parcque là à part la coloration syntaxique, la complétion et le débuggage... Ok c'est le minimum...

Il faudra argumenter un peu plus tout de même...
Bah un programme écrit en B peut être prouvé, donc même s'il génère du code "natif", il est vérifiable "à priori" (évidemment les spec du programment restent écrites par un humain...). C'est plus une sécurité vis-à-vis d'un plantage "non prévu".
Pour Java, il y a une couche d'abstraction entre le code généré et le code réellement exécuté, autorisant un certain nombre de vérifications supplémentaire par rapport à un programme natif compilé à partir d'un langage autorisant à peu prêt tout et n'importe quoi comme accès bas niveau. C'est une sécurité (toute relative) vis-à-vis de certains types d'erreur de programmation mais aussi une sécurité vis-à-vis de code malveillants.

C'est sûr qu'il n'y a aucune différence de productivité entre l'assembleur et le C, le C et Java, Java et Perl.
J'ai pas parlé de productivité mais de complexité. Globalement il est tout à fait possible de faire des grosses applications en C/C++ ou en Java comme il est sans doute possible de le faire en Lissac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charette.

Sinon tu parles de PHP mais il ne me semble pas que les début de PHP ont été foudroyant ...
Le truc c'est que PHP avait de net avantages par rapport aux concurrents : web dynamique, simple et libre/gratuit (par rapport à ce que se faisait à l'époque). Ces atouts combinés n'avaient pas d'équivalent et l'ont rendu populaire auprès des développeurs amateurs et des plateformes d'hébergement. On connait la suite.

Sinon il y a encore peu de site grand public en Rails, mais je t'assure qu'il est de plus en plus utilisé en interne,
Ca reste anecdotique non ? Enfin par rapport au buzz initial en tout cas...

Or il est plus délicat de proposer du mutualisé en Rails qui se propose donc comme alternative à Java.
C'est tout le problème : Java vise un public "professionnel" et donc une plateforme complète pour produire des solutions beaucoup plus exigentes (N-tiers, architecture distribuée, etc.) avec support/services de nombreux acteurs du marché, outils de dev/déploiement/exploitation.

Marrant ta signature comparée à la mienne ;)

Parcqu'au final c'est pas plus compliqué de conduire une locomotive que de s'occuper de chevaux ? Que le gain de confort/vitesse/sécurité est indéniable et conséquent ? Parcqu'il permet de transporter bien plus de personnes et de marchandises ?
Lissac n'apportera jamais un facteur 10x en vitesse par rapport au langage C, il n'apportera pas la sécurité qu'apporte un programme écrit en B ou même en Java, il ne permettra pas d'écrire des programmes plus complexes que dans un autre langage (la limite étant surtout liée aux compétences humaines et non techniques), etc.

Ou en Java Grails combiné avec JRuby par exemple.
En .NET y'a aussi MonoRails ou le ASP.NET MVC Framework, qui peut être associé à IronPython et bientôt IronRuby.
Bref ces plateformes offrent le choix des langages et le choix du framework.
Il ne reste pas beaucoup d'avantage à RoR, par contre il lui reste toujours les mêmes inconvénients : pas beaucoup d'acteurs de service et donc pas beaucoup de support ou de compétences, pas beaucoup d'outils (notamment IDE), intégration avec technos existantes limitées, pas d'acteur "principal" garant de la pérénité de la techno (style Sun, IBM ou Microsoft), pas de gros site de référence ayant éprouvé RoR (style Google et autre MySpace ou FaceBook).
Autant de raison qui font qu'en 4 ans RoR ne soit pas plus adopté que ca et s'il n'y a pas d'engagement plus flagrant de gros acteurs autour de cette techno, elle n'est pas prêt d'être adoptée au même titre que l'est par exemple PHP.

Oué bah oué, et ? JRuby ca permet aussi d'utiliser la syntaxe Ruby sans Rails. A l'inverse les frameworks MVC pour Java ou autre se multiplient : on peut donc développer avec un framework similaire à RoR sans la syntaxe Ruby : en Java, en C#, en Python ou je sais pas quoi.
On est d'accord, tout ce qui faisait la plateforme RoR initiale (à savoir un framework web MVC associé à l'environnement Ruby) a été repris ailleurs en intégralité ou en partie.

Ce qui fait la force de Rails n'est pas que le framework, loin de là, c'est surtout Ruby.
C'est aussi ce qui est en train d'être repris dans les autres technos : JRuby ou IronRuby par exemple.
Bref il ne va bientôt plus rester beaucoup d'intérêt spécifique à RoR.

C'est très subjectif... ca veut dire quoi "se porte très bien" ?
Quelle est la proportion d'utilisation de RoR par rapport aux autres techno web (PHP, Java, etc.) ? Quelle est l'évolution de cette proportion depuis 4 ans ?
L'impression générale (mais il me manque des chiffres à l'appui) c'est quand même que l'excitation du début est largement retombée et qu'il n'y a pas de réelle adoption large, faute d'acteur majeur dans le secteur (qu'il soit utilisateur de la techno, fournisseur de service ou fournisseur de softs). Un Google aurait (pourrait) changer la donne.
Bref le buzz est retombé, même si en soit la techno est loin d'être morte et a des utilisateurs.
A mon avis ca va pas s'arranger : les autes techno concurrentes (Java, PHP, ASP.NET, etc.) sont en train de s'approprier ce qui fait la force de RoR et limiter un peu plus l'intérêt de ce dernier.

Pas dans la catégorie "computers", dans la catégorie "notebook". Ca change tout : c'est un marché beaucoup plus restreint avec un public spécifique.
Il ferait téléphone il aurait jouer dans la cours de l'iPhone et donc potentiellement du "grand public".