Pourquoi utiliser Ruby au lieu de Smalltalk?
Ruby devient populaire , en grande partie grâce à l'influence Ruby sur Rails, mais on a l'impression qu'il se débat actuellement pendant son adolescence. Il y a beaucoup de similitudes entre Ruby et Smalltalk - maglev en témoigne. Malgré une syntaxe plus inhabituelle, Smalltalk a tout (sinon plus) la beauté orientée objet de Ruby.
D'après ce que j'ai lu, Smalltalk semble avoir Ruby battu:
- Maturité (développée dans les années 1970)
- La stabilité
- Support commercial
- Contrôle source distribué (comprend la structure du code, pas seulement la différence de texte)
- Plusieurs implémentations de la VM
- Prise en charge multiplateforme
- Le framework web bord de mer comme alternative forte à Rails
Il semble que Ruby réinvente juste la roue. Alors, pourquoi Ruby les développeurs utilisent SmallTalk? Qu'est-ce que Ruby n'a pas Smalltalk?
Pour mémoire: je suis un Ruby gars avec peu ou pas d'expérience en Smalltalk, mais je commence à me demander pourquoi.
Edit: Je pense que le problème de facilité de script a été résolu par GNU Smalltalk . Si je comprends bien, cela vous permet d'écrire Smalltalk dans d'anciens fichiers texte réguliers, et vous n'avez plus besoin d'être dans l'IDE Smalltalk. Vous pouvez alors exécuter vos scripts avec:
gst Smalltalk_file
Je suis plus un Pythonista qu'un utilisateur Ruby, cependant les mêmes choses valent pour Ruby pour à peu près les mêmes raisons).
L'architecture de Smalltalk est quelque peu insulaire alors que Python et Ruby ont été construits à partir de zéro pour faciliter l'intégration. Smalltalk n'a jamais vraiment gagné un corps de support d'application hybride dans la façon dont Python et Ruby ont, donc le concept de "Smalltalk comme langage de script intégré" n'a jamais fait son chemin).
Soit dit en passant, Java n'était pas la chose la plus facile à interfacer avec d'autres bases de code (JNI est assez maladroit), mais cela ne l'a pas empêché de gagner l'esprit. IMO l'interface l'argument est important - la facilité d'intégration n'a pas nui Python - mais cet argument n'a qu'un poids modéré car toutes les applications ne nécessitent pas cette capacité. De plus, les versions ultérieures de Smalltalk ont traité de manière substantielle l'insularité.La bibliothèque de classes de la plupart des principales implémentations Smalltalk (VisualWorks, VisualAge, etc.) était grande et avait la réputation d'une courbe d'apprentissage assez abrupte. La plupart des fonctionnalités clés de Smalltalk sont cachées quelque part dans la bibliothèque de classes, même des éléments de base comme les flux et les collections. Le paradigme linguistique est également quelque chose d'un choc culturel pour quelqu'un qui ne le connaît pas, et la vue fragmentaire du programme présenté par le navigateur est assez différente de ce à quoi la plupart des gens étaient habitués.
L'effet global est que Smalltalk a la réputation (quelque peu méritée) d'être difficile à apprendre; il faut pas mal de temps et d'efforts pour devenir un programmeur Smalltalk vraiment compétent. Ruby et Python sont beaucoup plus faciles à apprendre et à mettre à jour de nouveaux programmeurs).Historiquement, les implémentations Smalltalk traditionnelles étaient assez chères et nécessitaient du matériel exotique pour fonctionner, comme on peut le voir cette publication net.lang.st80 de 198 . Windows 3.1, NT et '95 et OS/2 ont été les premiers systèmes d'exploitation du marché de masse sur du matériel grand public capables de prendre en charge une implémentation Smalltalk avec une intégration de système native décente. Auparavant, le matériel Mac ou station de travail était la plate-forme la moins chère capable d'exécuter Smalltalk efficacement. Certaines implémentations (en particulier Digitalk) supportaient assez bien les systèmes d'exploitation pour PC et ont réussi à gagner du terrain.
Cependant, OS/2 n'a jamais connu autant de succès et Windows n'a été accepté par le grand public qu'au milieu des années 90. Malheureusement, cela a coïncidé avec l'essor du Web en tant que plate-forme et une grande poussée marketing derrière Java. Java a saisi la plupart des parts de l'esprit dans la dernière partie des années 1990, ce qui rend Smalltalk un peu plus également.Ruby et Python fonctionnent dans une chaîne d'outils plus conventionnelle et ne sont pas étroitement couplés à un environnement de développement spécifique. Alors que les IDE Smalltalk que j'ai utilisés sont assez agréables, j'utilise PythonWin pour Python développement en grande partie parce qu'il a un éditeur Nice avec mise en évidence de la syntaxe et ne se dérobe pas.
Cependant, Smalltalk a été conçu pour être utilisé avec un IDE (en fait, Smalltalk était l'IDE graphique original) et possède toujours quelques fonctionnalités Nice non répliquées par d'autres systèmes. le code avec surlignage et "Show it" est toujours une fonctionnalité très agréable que je n'ai jamais vue dans un IDE Python, bien que je ne puisse pas parler pour Ruby.Smalltalk était un peu en retard à la fête des applications Web. Les premiers efforts tels que VisualWave n'ont jamais été couronnés de succès et ce n'est que lors de la sortie de Seaside qu'un cadre Web décent a été accepté dans les cercles Smalltalk. En attendant Java EE a eu un cycle de vie d'acceptation complet commençant par des fanboys délirants en faisant la promotion et finalement s'ennuyant et passant à Ruby; -}
Ironiquement, Seaside commence à avoir un peu de partage d'esprit parmi les cognoscenti, nous pouvons donc constater que les balades Smalltalk qui reviennent en popularité.
Cela dit, Smalltalk est un système très agréable une fois que vous avez déterminé comment le conduire.
Lorsque je quitte ma maison le matin pour aller au travail, j'ai souvent du mal à prendre la décision de tourner à gauche ou à droite dans mon chemin (j'habite au milieu d'une rue). Dans les deux cas, je serai à destination. Une façon me mène à l'autoroute qui, en fonction de la circulation, m'amènera probablement au bureau le plus rapidement. Je conduis très vite pendant au moins une partie du chemin et j'ai de bonnes chances de voir une jolie fille ou deux sur le chemin du travail :-)
L'autre façon me permet de parcourir une route secondaire très enchanteresse et venteuse avec un couvert arboré complet. Ce chemin est assez agréable et des deux approches est certainement le plus amusant, bien que cela signifie que j'arriverai au bureau plus tard que je ne l'aurais fait si j'avais pris l'autoroute. Chaque voie a ses mérites. Les jours où je suis très pressé, je prends généralement l'autoroute bien que je puisse courir dans la circulation et j'augmente également mes chances de tomber dans un accident (si je ne fais pas attention à ma hâte). D'autres jours, je peux choisir le chemin boisé et conduire en profitant du paysage et en réalisant que je suis en retard. Je peux essayer d'accélérer, augmentant mes chances d'obtenir un billet ou de provoquer un accident moi-même.
Aucune des deux façons n'est meilleure que l'autre. Ils ont chacun leurs avantages et leurs risques, et chacun m'amènera à mon objectif.
Je pense que votre question manque quelque peu. Vous ne devez pas choisir, vous devez apprendre les deux!
Si vous êtes vraiment en mesure de choisir le prochain framework (vm, infrastructure), vous devez décider quoi utiliser et pouvez poser une question spécifique avec des avantages et des inconvénients du point de vue de ce que votre application est destinée à faire.
J'ai utilisé Smalltalk (j'adore) et Ruby (j'adore)).
À la maison ou pour un projet open source, je peux utiliser toutes les langues que j'aime, mais quand je fais du travail, je dois adopter.
J'ai commencé à utiliser Ruby (au travail) parce que nous avions besoin d'un langage de script qui se comportait plus ou moins également sous Solaris, Linux et Windows (98,2000, XP). Ruby était à l'époque inconnu de joe moyen et il n'existait pas de Rails. Mais c'était facile à vendre à toutes les personnes impliquées.
(Pourquoi pas python? La vérité? J'ai passé une fois par semaine à chercher un bug qui s'est produit lorsqu'un terminal a converti mon espace en onglet et que l'intention a été gâchée).
Les gens ont donc commencé à coder de plus en plus en Ruby parce que c'était tellement relaxant, agréable et pas un nuage dans le ciel.
Il est vrai, certainement, que la plupart des gens ne choisissent pas les langages de programmation simplement en fonction de leurs mérites. La plupart des programmeurs sont informés de la langue à utiliser par quelqu'un d'autre.
et
Pour être attrayant pour les pirates, une langue doit être bonne pour écrire les types de programmes qu'ils veulent écrire. Et cela signifie, peut-être de manière surprenante, que cela doit être bon pour écrire des programmes jetables.
Et quand étaient au LISP, essayez de remplacer LISP par Smalltalk
Les bibliothèques, la communauté et l'élan de Ruby sont bons
Donc, si LISP est toujours plus puissant que Ruby, pourquoi ne pas utiliser LISP? Les objections typiques à la programmation dans LISP sont:
- Il n'y a pas assez de bibliothèques.
- Nous ne pouvons pas embaucher de programmeurs LISP.
- LISP est allé nulle part au cours des 20 dernières années.
Ce ne sont pas des objections écrasantes, mais elles valent certainement la peine d'être examinées.
et
Maintenant, étant donné le choix entre une langue puissante et une langue populaire, il peut être judicieux de choisir la langue puissante. Mais si la différence de puissance est mineure, être populaire présente toutes sortes d'avantages niçois. En 2005, je réfléchirais longuement avant de choisir LISP plutôt que Ruby. Je ne le ferais probablement que si j'avais besoin d'un code optimisé ou de macros qui agissaient comme des compilateurs à part entière.
Je dirais le contraire: la syntaxe Smalltalk est l'une des syntaxes de langage de programmation les plus simples et les plus puissantes.
C'est vrai que les langues se ressemblent beaucoup. La façon superficielle d'interpréter cela est d'appeler Ruby un groupe de reprise Smalltalk. L'interprétation plus raisonnable est que le système fermé de Smalltalk l'a isolé, tandis que la participation de Ruby à l'écologie Unix et l'habitude de s'approprier des fonctionnalités de chaque le langage sous le soleil lui donne une courbe d'adoption infiniment plus douce et une intégration sans effort avec des outils kickass comme Git.
Devinez qui a dit ça? (la citation est proche, peut-être pas exacte): "J'ai toujours pensé que Smalltalk battrait Java. Je ne savais tout simplement pas si on l'appellerait" Ruby "quand il le ferait."
Roulement de tambour ....
...
La réponse est ... Kent Beck
qu'est-ce que Ruby a ce que Smalltalk n'a pas?
- Prise en charge massive et actuelle par les principales plateformes (IronRuby et jRuby) qui enrichissent l'ensemble des bibliothèques
- Des évangélistes comme Dave Thomas qui, depuis des années, font le tour du pays pour prêcher l'évangile de leur langue. J'ai vu Dave lors de conférences Java affirmant qu'il ne savait pas Java et qu'il préférait Ruby.
- Immobilier solide et actuel sur les étagères
- Le créateur de Ruby a dit qu'il pensait au programmeur: la syntaxe de Ruby semble avoir cet attrait zen. Elle est difficile à cerner, mais semble galvaniser les fans.
- Des présentations créatives et dynamiques comme Giles et celui-ci qui gagnent en esprit
Je pense que votre point est bien compris. Comme l'a dit un ami, Ruby pourrait être "du vieux vin dans une nouvelle bouteille" face à Smalltalk. Mais parfois, la nouvelle bouteille compte. Un vin doit être au bon endroit au bon moment.
Stephane Ducasse a d'excellents livres Smalltalk disponibles ici:
http://stephane.ducasse.free.fr/FreeBooks.html
donc bien que la communauté Smalltalk ne soit pas aussi prolifique que les communautés Ruby et Rails, il y a encore une grande aide là-bas).
Me bat. J'ai passé un an à vérifier Ruby et à faire quelques petits projets pour voir comment je l'ai aimé. Je suppose que je suis un bigot de Smalltalk parce que chaque fois que je m'asseyais pour travailler avec Ruby Je soupirais et je pensais "Je préfèrerais vraiment faire ça dans Smalltalk". Enfin, j'ai cédé et je suis retourné à Smalltalk. Maintenant, je suis plus heureux. Plus heureux est mieux.
Ce qui pose bien sûr la question "Pourquoi?". Dans aucun ordre particulier:
- Parce que le IDE souffle tout ce que j'ai déjà travaillé. Cela inclut un tas de plates-formes d'ISPF sur les mainframes IBM au Visual (. *) De Microsoft, incluez des choses comme Visual Basic 4- 6, Visual C++ (diverses incarnations), Turbo Pascal de Borland et ses descendants (par exemple Delphi), et des trucs sur les machines DEC en mode caractère et sous X-Windows.
- Parce que l'image est un bel endroit où vivre. Je peux y trouver ce que je veux. Si je n'arrive pas à comprendre comment faire quelque chose, je sais que quelque part dans l'image est un exemple de ce que j'essaie de faire - tout ce que j'ai à faire est de chasser jusqu'à ce que je le trouve. Et c'est auto-documenté - si vous voulez voir les détails du fonctionnement de quelque chose, ouvrez simplement un navigateur sur la classe qui vous intéresse, regardez la méthode, et c'est comme ça que ça marche. (OK, vous finirez par toucher quelque chose qui appelle une primitive, puis c'est "ici, il y a des dragons", mais c'est généralement compréhensible du contexte). Il est possible de faire des choses similaires dans Ruby/C++/C, mais ce n'est pas aussi facile. Facile, c'est mieux.
- Le langage est minimal et cohérent. Trois types de messages - unaire, binaire et mot-clé. Cela décrit également la priorité d'exécution - les messages unaires d'abord, puis les messages binaires, puis les messages de mots clés. Utilisez des parenthèses pour aider les choses. Dang peu de syntaxe, vraiment - tout est fait avec des envois de messages. (OK, l'affectation n'est pas un message envoyé, c'est un opérateur. Il en est de même pour l'opérateur de retour (^). Les blocs sont entourés de paires d'accolades carrées ([]). Il peut s'agir d'un ou deux autres bits "magiques", mais sacrément peu ...).
- Des blocs. Oui, je sais, ils sont là en Ruby (et autres), mais bon sang, vous ne pouvez littéralement pas programmer en Smalltalk sans les utiliser. Vous êtes forcé pour apprendre à les utiliser. Parfois, être forcé, c'est bien.
- Programmation orientée objet sans compromis - ou alternatives, d'ailleurs. Vous ne pouvez pas prétendre que vous "faites des objets" tout en faisant la même chose ancienne.
- Parce que cela va étirer votre cerveau. Les constructions confortables auxquelles nous sommes tous habitués (if-then-else, do-while, for (;;), etc.) ne sont plus là, vous devez donc apprendre quelque chose de nouveau. Il y a des équivalents à tout ce qui précède (et plus), mais vous allez devoir apprendre à penser différemment. C'est bien différent.
D'un autre côté, cela ne peut être que les divagations d'un gars qui programme depuis les jours où les ordinateurs centraux régnaient sur la terre, nous avons dû marcher cinq miles pour travailler à travers des tempêtes de neige aveuglantes, monter dans les deux sens et les ordinateurs utilisaient des beignets pour la mémoire. Je n'ai rien contre Ruby/Java/C/C++ /, ils sont tous utiles dans le contexte, mais donnez-moi Smalltalk ou donnez-moi ... eh bien, je devrais peut-être apprendre LISP ou Scheme ou ... :-)
Smalltalk: les gens transmettent ifTrue: [pensez] ifFalse: [ne réfléchissez pas]
Ruby: les gens pensent en avant à moins de penser en arrière
1) Le flux de contrôle de Smalltalk de type RPN par messages est comme LISP - il est régulier et cool mais bizarre.
2) Ruby permet aux gens d'écrire du code en utilisant la façon idiomatique dont les gens parlent - faites bla à moins que il y ait une raison de ne pas le faire.
mise à jour réécrit l'exemple Smalltalk pour en fait être un code plus légal.
Ruby est le langage buzz actuel. Il est plus facile de commercialiser un logiciel construit avec lui en ce moment qu'un langage développé dans les années 70.
Communauté! Ruby et surtout Rails a une telle communauté formidable. En jouant avec Smalltalk, il semblait qu'il n'y avait pas autant de captures d'écran, d'articles, de billets de blog, etc.) écrit sur Smalltalk.
Ruby (ou toute autre langue) est plus populaire que Smalltalk (ou toute autre langue) car nous vivons dans un univers chaotique. En être témoin:
- De Dave Thomas lui-même, "[après la] vidéo sur" Comment créer un blog en dix minutes "... Ruby est passé d'une jolie petite langue de niche à une" langue que vous a écrit Rails apps dans '"( Ruby Conference 2010 keynote ).
- Les premiers vendeurs Smalltalk facturés de manière prohibitive
- Smalltalk, parce qu'il a été inventé (en avance sur son temps) il y a 30 ans, apparaît à beaucoup comme une langue ancienne et "morte" (comme FORTRAN)
- les entreprises considèrent Smalltalk comme un avantage concurrentiel qui elles cachent son utilisation
Alors que les langues sont similaires dans les fonctionnalités de OO, Smalltalk killer est l'avantage de l'environnement ouvert et vivant (le plus mal compris) 'image'). Après avoir vérifié cet exemple de programmation en Smalltalk , le débat est terminé.
Vous avez répondu à la question dans votre première ligne: "Ruby devient populaire"
- Il y a beaucoup de modules, projets et autres intéressants autour de Ruby.
- Si vous avez du mal à faire quelque chose dans Ruby, il sera trivial de trouver de l'aide quelque part.
- Ruby est installé sur un lot d'ordinateurs maintenant (il est inclus par défaut sur OS X, de nombreuses distributions Linux et il existe de bons installateurs pour Windows) - Je n'ai vu Smalltalk installé par défaut sur aucune machine J'ai utilisé ..
Je dirais que oui ou non une langue est supérieure à une autre n'est pas pertinente. Par exemple, PHP n'est peut-être pas la "meilleure" langue de tous les temps, mais j'envisagerais toujours de l'utiliser sur Ruby sur Rails (un "meilleur" outil pour créer des sites Web) parce qu'il est très répandu.
Fondamentalement, les avantages et les inconvénients spécifiques d'une langue sont beaucoup moins importants que tout ce qui l'entoure - à savoir la communauté.
Pour moi, ce n'est pas tellement un cas de ce que Ruby a, mais ce que Ruby n'a pas. Et la chose qu'il n'a pas est le besoin pour un VM et environnement complet.
Smalltalk est génial - c'est là que j'ai appris les concepts OO, mais pour la facilité d'utilisation, je choisis Ruby. Je peux écrire Ruby code dans mon éditeur préféré et exécuter il forme la ligne de commande.
Donc, pour moi, c'est ce que je choisis Ruby sur Smalltalk.
Je pense que tous ceux qui ont travaillé avec Ruby pendant un certain temps reconnaissent sa profonde dette envers Smalltalk. En tant que l'une de ces personnes, qu'est-ce que j'aime dans Ruby over Smalltalk? Je pense que d'un point de vue strictement linguistique, c'est le sucre. Ruby est délibérément un langage très syntaxique, alors que Smalltalk est un langage très syntaxique minimal. Ruby est essentiellement le modèle objet Smalltalk avec le sucre de syntaxe Perlish. Il se trouve que j'aime le sucre et je trouve que cela rend la programmation plus amusante.
Vous pouvez trouver un travail assez facilement en faisant Ruby. Bien que j'aime vraiment Smalltalk, il est pratiquement impossible d'entrer dans le créneau Smalltalk. Il y a du travail, mais si vous n'y êtes pas allé quand il était populaire, c'est pratiquement impossible maintenant.
Toutes les autres raisons sont insignifiantes car vous devez passer beaucoup de temps, concentré sur un vrai travail pour apprendre correctement une langue. Si vous n'êtes pas riche indépendamment, la meilleure façon de le faire est de vous y exposer au travail.
Ruby est à Smalltalk comme les chiffres arabes sont aux chiffres romains. Même calcul, syntaxe plus simple.
Parce que les distributions Smalltalk étaient facturées en multiples de 1000 USD alors que Ruby est gratuit.
J'ai fait un petit Smalltalk - le IDE est une chose dont je me souviens - est-ce que Ruby a une bonne IDE support?)
Utilisez Ruby car il a peut-être des pattes commerciales, Smalltalk non.
Je peux vous dire par expérience personnelle. Toujours en utilisant Smalltalk, j'adore et j'ai utilisé quelques saveurs. Bien que Smalltalk soit un excellent langage et soit tout ce que vous avez mentionné, vous ne convaincrez probablement pas le CIO/CTO moyen d'utiliser Smalltalk sur un nouveau projet. Bien sûr, vous pourriez même avoir du mal à convaincre un CIO/CTO conservateur d'utiliser Ruby. En fin de compte, vous devez être très prudent si vous voulez un soutien commercial durable à long terme et la capacité de trouver des employés hors de la rue qui peuvent prendre en charge vos systèmes à l'avenir. À titre d'exemple, Smalltalk était une chose vraiment importante au début des années 90 et IBM y a beaucoup investi à la fin des années 90. Pour IBM Smalltalk allait être la prochaine langue pour toutes les applications d'entreprise. IBM a mis Smalltalk sur tout, y compris leurs systèmes mainframe. Java est devenu populaire, a repris le marché et Smalltalk est devenu un acteur de niche. Il y a plus d'un an, IBM a vidé le langage (leur terme est le coucher du soleil). Jetez également un œil à l'historique. ParkPlace et Digitalk, où les premiers grands acteurs commerciaux de l'arène Smalltalk, ont fusionné puis ont cessé leurs activités.
Point de vue intéressant de Robert Martin (de RailsConf 2009): "Ce qui a tué Smalltalk pourrait tuer Ruby, aussi"
Utilisez tout ce qui vous rend plus puissant et plus rapide pour relever votre défi.
Pour nous , un peu dans le cadre maison, nous avons construit en haut du bord de mer est vraiment notre superpuissance.
J'adore la communauté RoR, elle a la bonne attitude. C'est très très précieux. Mais en même temps, technologiquement, le bord de mer vous rend plus fort contre des problèmes plus compliqués.
Vous pouvez créer de superbes applications Web en bord de mer en utilisant des choses open-source.
dabbledb était un sartup basé sur le bord de mer et, hé! Avi l'a vendu à Twitter en juin de cette année!
Je dis que vous n'avez pas besoin d'attendre que les autres approuvent votre initiative.
Allez-y. Faites-le. Montrez-nous que cela fonctionne.
Tu n'es pas seul. Nous sommes sur le même bateau.
J'aime à la fois Smalltalk et Ruby - mais j'ai trouvé que Ruby est plus applicable à ce que je fais quotidiennement et plus proche de mon cœur (pratiquement parlant). Qu'est-ce que Ruby offre que Smalltalk ne propose pas?
- Scriptage basé sur du texte
- Exigences d'implémentation faibles (s'exécute dans plus d'endroits)
- Plus facile à apprendre et à justifier (Perl et Python auront des problèmes non
- Déplacement plus facile des programmes - fichiers texte!
- S'interface bien avec l'environnement natif
- Partout Java s'exécute, jRuby s'exécute ...
- Communauté plus grande et beaucoup plus active
Certains ont mentionné gst (GNU Smalltalk); les problèmes persistent.
Je pense qu'une partie du problème est le développement-environnement-est-le-runtime. Cela donne beaucoup de puissance, mais il présente également une courbe d'apprentissage plus grande.
Ici est un tutoriel bonjour le monde.
C'est très différent des autres langues où j'ai juste besoin de savoir comment ouvrir un éditeur de texte et copier et coller du texte, appuyer sur enregistrer et exécuter un compilateur. JE DOIS savoir utiliser l'environnement. Ce tutoriel ne me montre même pas comment créer un programme de base (ce qui est probablement plus une faute de ce tutoriel) que je peux exécuter.
Il y a certainement un coût plus élevé pour faire avancer les choses que la plupart des autres langues.
La plupart des langues ont du code accrocheur qu'elles peuvent montrer. Je n'ai pas vu ça avec Smalltalk. Je pense également qu'il y a une certaine stigmatisation à Smalltalk parce qu'il existe depuis si longtemps et qu'il est encore relativement obscur.
Je pense que la PLUS GRANDE différence est que Ruby est beaucoup plus similaire à Perl en termes d'UTILISATION. Smalltalk n'a jamais pris pied dans les langages de "scripting".
Le VM est vraiment cool et j'espère Ruby aura quelque chose de similaire pour que nous puissions tout traiter sur notre système d'exploitation qui est écrit en Ruby en tant qu'objet dans l'espace mémoire, mais jusque-là, j'apprécie simplement le bref, la syntaxe courte de Ruby, la possibilité d'écrire un petit script et de le réutiliser plus tard. Ruby a tous les avantages de Perl et le OOP est beaucoup plus similaire à Smalltalk que le OOP hack de Perl).
En tant que retardataire de la discussion, le principal problème avec Smalltalk et LISP est que vous ne pouvez pas les exécuter avec CGI ou FastCGI sur l'hébergement partagé.
Les masses non lavées ne les utiliseront jamais si elles ont besoin de VPS ou de serveurs dédiés pour les utiliser. IMHO Seaside est supérieur à presque tout, mais fonctionnera-t-il sur Dreamhost ou Webfaction?
J'irais plus loin que la réponse de Jonke, et je dirais qu'il existe maintenant un grand nombre de langues qui ont une communauté très forte, presque assez pour tous les goûts, et un sous-ensemble d'entre elles a une reconnaissance générale (c'est-à-dire que votre manager vous permettra de les utiliser à travailler aussi).
Il est facile d'apprendre les bases d'un langage, mais pour l'utiliser efficacement, vous devez investir suffisamment de temps pour apprendre la plate-forme et les outils, ainsi que la syntaxe et les idiomes. IIRC, McConnell affirme qu'il faut environ trois ans pour devenir vraiment compétent.
Compte tenu de ces choses, il est difficile de justifier de passer beaucoup de temps sur des langues comme LISP et Smalltalk, bien qu'elles soient intéressantes et peut-être éducatives à regarder.