Pourquoi utiliser Ruby au lieu de Smalltalk? [fermé]

Ruby est en train de devenir populaire , en grande partie grâce à l'influence de Ruby on Rails, mais on a l'impression de lutter actuellement pendant son adolescence. Il y a beaucoup de similitudes entre Ruby et Smalltalk - maglev en est un témoignage. Malgré une syntaxe plus inhabituelle, Smalltalk a tout (sinon plus) de la beauté orientée objet de Ruby.

D'après ce que j'ai lu, Smalltalk semble avoir battu Ruby:

• Maturité (développé dans les années 1970)
• Stabilité
• Support commercial
• Contrôle de source distribué (comprend la structure du code, pas seulement le texte qui diffère)
• Plusieurs implémentations de la VM
• Prise en charge multiplateforme
• Le framework web balnéaire comme une alternative forte aux Rails

Il semble que Ruby ne fait que réinventer la roue. Alors, pourquoi les développeurs Ruby n'utilisent-ils pas SmallTalk? Qu'est-ce que Ruby a le Smalltalk n'a pas?

Pour mémoire: je suis un gars Ruby avec peu ou pas d'expérience en Smalltalk, mais je commence à me demander pourquoi.

Edit: Je pense que le problème de la 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'EDI Smalltalk. Vous pouvez ensuite exécuter vos scripts avec:

gst smalltalk_file

Je suis plus un utilisateur de Pythonista qu'un utilisateur de Ruby, mais les mêmes choses valent pour Ruby pour 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'applications hybrides comme Python et Ruby, de sorte que le concept de «smalltalk en tant que langage de script intégré» n'a jamais été adopté.
  
  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 en partage d'esprit. OMI, l'argument d'interfaçage est significatif - 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é. En outre, les versions ultérieures de Smalltalk ont ​​largement abordé l'insularité.

• La bibliothèque de classes de la plupart des principales implémentations de Smalltalk (VisualWorks, VisualAge, etc.) était grande et avait la réputation d'une courbe d'apprentissage assez raide. La plupart des fonctionnalités clés de Smalltalk sont cachées quelque part dans la bibliothèque de classes, même les éléments de base comme les flux et les collections. Le paradigme du langage est aussi un choc culturel pour quelqu'un qui ne le connaît pas, et la vue fragmentaire du programme présentée par le navigateur est assez différente de ce à quoi la plupart des gens étaient habitués.
  
  L'effet global est que Smalltalk a obtenu une réputation (quelque peu méritée) d'être difficile à apprendre; il faut un peu de temps et d'efforts pour devenir un programmeur Smalltalk vraiment compétent. Ruby et Python sont beaucoup plus faciles à apprendre et à mettre au courant des nouveaux programmeurs.

• Historiquement, les implémentations traditionnelles de Smalltalk étaient assez chères et nécessitaient du matériel exotique pour fonctionner, comme on peut le voir dans cette publication de net.lang.st80 de 1983 . 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 système native décente. Auparavant, le matériel Mac ou poste de travail était les plates-formes les moins chères capables d'exécuter Smalltalk efficacement. Certaines implémentations (en particulier Digitalk) supportaient assez bien les systèmes d'exploitation PC et ont réussi à gagner du terrain.
  
  Cependant, OS / 2 n'a jamais été aussi réussi et Windows n'a été accepté par le grand public qu'au milieu des années 1990. 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 attrapé la majeure partie de l'esprit dans la dernière partie des années 1990, rendant Smalltalk un peu aussi couru.

• Ruby et Python fonctionnent dans une chaîne d'outils plus conventionnelle et ne sont pas étroitement associés à un environnement de développement spécifique. Bien que les IDE Smalltalk que j'ai utilisés soient assez sympas, j'utilise PythonWin pour le développement Python en grande partie parce qu'il a un bel éditeur avec une coloration syntaxique et ne se met pas sous les pieds.
  
  Cependant, Smalltalk a été conçu pour être utilisé avec un IDE (en fait, Smalltalk était l'EDI graphique d'origine) et possède encore quelques fonctionnalités intéressantes non répliquées par d'autres systèmes. Tester le code avec surlignage et «Afficher» est toujours une fonctionnalité très intéressante que je n'ai jamais vue dans un IDE Python, bien que je ne puisse pas parler pour Ruby.

• Smalltalk est arrivé un peu en retard à la fête des applications Web. Les premiers efforts tels que VisualWave n'ont jamais eu beaucoup de succès et ce n'est que lorsque Seaside est sorti qu'un cadre Web décent a été accepté dans les cercles Smalltalk. Entre-temps, Java EE a eu un cycle de vie d'acceptation complet commençant par des fanboys délirants qui en font la promotion et qui s'ennuient enfin et passent à Ruby; -}
  
  Ironiquement, Seaside commence à avoir un peu de partage d'esprit parmi les cognoscenti afin que nous puissions constater que Smalltalk roule qui revenir à la popularité.

Cela dit, Smalltalk est un très bon système une fois que vous avez compris comment le piloter.

Lorsque je quitte ma maison le matin pour aller travailler, j'ai souvent du mal à prendre la décision de tourner à gauche ou à droite de mon chemin (je vis au milieu d'une rue). Dans les deux cas, je parviendrai à ma destination. Un chemin me mène à l'autoroute qui, selon la circulation, me conduira probablement le plus rapidement au bureau. Je conduis très vite pendant au moins une partie du trajet et j'ai de bonnes chances de voir une jolie fille ou deux sur le chemin du travail :-)

L'autre moyen me permet de parcourir une route arrière très enchanteresse et venteuse avec un couvert arboré complet. Ce chemin est assez agréable et des deux approches est certainement la plus amusante, même si cela signifie que j'arriverai au bureau plus tard que je n'aurais pris l'autoroute. Chaque voie a ses mérites. Les jours où je suis très pressé, je prendrai généralement l'autoroute même si je risque de rencontrer du trafic et j'augmente également mes chances d'avoir un accident (si je ne fais pas attention à ma hâte). D'autres jours, je peux choisir le sentier boisé et conduire, profiter du paysage et me rendre compte que je suis en retard. Je peux essayer d'accélérer, augmenter mes chances d'obtenir un billet ou de provoquer moi-même un accident.

Aucune des deux méthodes 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 passe quelque peu à côté. Vous ne devriez pas choisir, vous devriez les apprendre tous les deux!

Si vous êtes vraiment en mesure de choisir le prochain framework (vm, infrastructure), vous devez alors décider quoi utiliser et poser une question spécifique avec des avantages et des inconvénients du point de vue de ce que votre application est censé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 lorsque je travaille, 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 à cette époque inconnue de Average-Joe et il n'existait aucun rail. Mais c'était facile de vendre à toutes les personnes impliquées.

(Pourquoi pas python? La vérité? J'ai passé une semaine à chercher un bogue 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 rubis parce que c'était tellement relaxant, amusant et pas un nuage sur le ciel.

Paul Graham le résume

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 savent quelle langue utiliser par quelqu'un d'autre.

et

Pour être attrayant pour les pirates, un langage doit être bon pour écrire les types de programmes qu'ils veulent écrire. Et cela signifie, peut-être étonnamment, qu'il doit être bon pour écrire des programmes jetables.

Et quand étaient au pays de Lisp, essayez de remplacer LISP par smalltalk

Les bibliothèques, la communauté et l'élan de Ruby sont bons

Alors si LISP est toujours plus puissant que Ruby, pourquoi ne pas utiliser LISP? Les objections typiques à la programmation dans LISP sont:

1. Il n'y a pas assez de bibliothèques.
2. Nous ne pouvons pas embaucher de programmeurs LISP.
3. LISP n'est allé nulle part au cours des 20 dernières années.

Ce ne sont pas des objections écrasantes, mais elles méritent certainement d'être prises en considération.

et

Maintenant, étant donné le choix entre une langue puissante et une langue populaire, il peut être très judicieux de choisir la langue puissante. Mais si la différence de pouvoir est mineure, être populaire présente toutes sortes d'avantages. En 2005, je réfléchissais longuement avant de choisir LISP plutôt que Ruby. Je ne le ferais probablement que si j'avais besoin de 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.

Il est vrai que les langues se ressemblent beaucoup. La manière superficielle d'interpréter cela est d'appeler Ruby un groupe de reprises Smalltalk. L'interprétation la 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 les fonctionnalités de chaque langue sous le soleil lui donne une courbe d'adoption infiniment plus douce et une intégration sans effort avec des outils kickass comme Git.

Giles Bowkett

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 s'il s'appellerait 'Ruby' quand il le ferait."

Roulement de tambour ....

...

La réponse est ... Kent Beck

Stephane Ducasse a quelques bons 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 toujours une grande aide là-bas.

qu'est-ce que Ruby a que Smalltalk n'a pas?

• Prise en charge massive et actuelle par les principales plates-formes (IronRuby et jRuby) qui enrichissent l'ensemble des bibliothèques
• Des évangélistes comme Dave Thomas qui, depuis des années, tournent à travers le pays pour prêcher l'évangile de leur langue. J'ai vu Dave à des conférences Java dire qu'il ne connaissait pas Java et qu'il préférait Ruby.
• Des biens immobiliers forts et actuels 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. C'est difficile à cerner, mais semble galvaniser les fans.
• Des présentations créatives et dynamiques comme Giles et celle-ci qui gagnent en notoriété

Je pense que votre argument est bien fondé. 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.

Me bat. J'ai passé un an à vérifier Ruby et à faire de petits projets pour voir à quel point j'aimais ça. Je suppose que je suis un fanatique de Smalltalk parce que chaque fois que je m'asseyais pour travailler avec Ruby, je soupirais et je pensais "Je préfère vraiment faire ça dans Smalltalk". Finalement j'ai cédé et je suis retourné à Smalltalk. Maintenant je suis plus heureux. Plus heureux est mieux.

Ce qui soulève bien sûr la question "Pourquoi?". Dans aucun ordre particulier:

1. Parce que l'EDI souffle tout ce avec quoi j'ai travaillé. Cela inclut un tas de plates-formes de ISPF sur les mainframes IBM à Visual de Microsoft (. *), Y compris des éléments tels que Visual Basic 4-6, Visual C ++ (diverses incarnations), Turbo Pascal de Borland et ses descendants (par exemple Delphi), et des éléments sur DEC machines en mode caractère et sous X-Windows.
2. Parce que l'image est un bel endroit à vivre. Je peux trouver ce que je veux là-dedans. Si je ne peux 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 de la façon dont quelque chose fonctionne, il vous suffit d'ouvrir un navigateur sur la classe qui vous intéresse, de regarder la méthode, et c'est ainsi que cela fonctionne. (OK, vous finirez par frapper quelque chose qui appelle une primitive, puis c'est "ici, il y a des dragons", mais c'est généralement compréhensible à partir du contexte). Il est possible de faire des choses similaires dans Ruby / C ++ / C, mais ce n'est pas aussi simple. Facile c'est mieux.
3. 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 les envois de messages. (OK, l'affectation n'est pas un message envoyé, c'est un opérateur. Il en va de même pour l'opérateur 'return' (^). Les blocs sont entourés par des paires d'accolades ([]). Il peut y avoir un ou deux autres bits 'magiques', mais sacrément peu ...).
4. Les blocs. Ouais, je sais, ils sont là dans Ruby (et autres), mais bon, vous ne pouvez littéralement pas programmer en Smalltalk sans les utiliser. Vous êtes obligé d'apprendre à les utiliser. Parfois, être forcé est bon.
5. Programmation orientée objet sans compromis - ni alternatives, d'ailleurs. Vous ne pouvez pas prétendre que vous «faites des objets» tout en faisant toujours la même chose.
6. Parce que cela va étirer votre cerveau. Les constructions confortables auxquelles nous 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. Différemment c'est bon.

D'un autre côté, ce n'est peut-être que les divagations d'un gars qui programme depuis l'époque où les ordinateurs centraux régnaient sur la terre, nous devions marcher cinq miles pour travailler à travers des tempêtes de neige aveuglantes, 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 en contexte, mais donnez-moi Smalltalk ou donnez-moi ... eh bien, je devrais peut-être apprendre Lisp ou Scheme ou ... :-)

Smalltalk: les gens transfèrent ifTrue: [think] ifFalse: [not thinking]

Ruby: les gens pensent en avant à moins de penser en arrière

1) Le flux de contrôle de type RPN de Smalltalk par messages est comme Lisp - c'est régulier et cool mais ça fait bizarre les gens.

2) Ruby permet aux gens d'écrire du code en utilisant la façon idiomatique dont les gens parlent - faites bla à moins qu'il y ait une raison de ne pas le faire.

update a réécrit l'exemple Smalltalk pour en faire un code plus légal.

Ruby est le langage courant du buzz. Il est aujourd'hui plus facile de commercialiser un logiciel construit avec lui qu'un langage développé dans les années 70.

Communauté! Ruby et surtout Rails ont une si grande communauté. Lorsque l'on déconnait avec Smalltalk, il semblait qu'il n'y avait pas autant de projections d'écran, d'articles, de billets de blog, etc. écrits sur Smalltalk.

Vous avez répondu à la question de votre première ligne: "Ruby devient populaire"

• Il y a beaucoup de modules intéressants, de projets et autres basés sur Ruby.
• Si vous avez du mal à faire quelque chose dans Ruby, il sera trivial de trouver de l'aide quelque part.
• Ruby est maintenant installé sur beaucoup d'ordinateurs (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 que j'ai utilisée.

Je dirais qu'un langage est supérieur ou non à un autre n'est pas pertinent. Par exemple, PHP n'est peut-être pas le "meilleur" langage de tous les temps, mais j'envisagerais quand même de l'utiliser sur Ruby on Rails (un "meilleur" outil pour créer sites Web) parce qu'il est si 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é.

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'un joli petit langage de niche à" un langage dans lequel vous avez écrit des applications Rails "" ( Ruby Conference Keynote 2010 ).
• 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 un vieux langage "mort" (comme FORTRAN)
• les entreprises considèrent Smalltalk comme un tel avantage concurrentiel qu'elles cachent son utilisation

Alors que les langages sont similaires dans les fonctionnalités OO, l' avantage tueur de Smalltalk est l'environnement ouvert en direct (l '«image» très mal comprise). Après avoir consulté cet exemple de programmation dans Smalltalk , le débat est terminé.

Pour moi, ce n'est pas tant un cas de ce que Ruby a, mais ce que Ruby n'a pas. Et ce qu'il n'a pas, c'est le besoin d'une VM et d'un 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 du code Ruby dans mon éditeur préféré et l'exécuter depuis la ligne de commande.

Donc, pour moi, c'est ce que j'ai choisi Ruby plutôt que Smalltalk.

Je pense que tous ceux qui travaillent avec Ruby depuis un certain temps reconnaissent sa profonde dette envers Smalltalk. En tant que l'une de ces personnes, qu'est-ce que j'aime chez Ruby sur Smalltalk? Je pense que du 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. Ruby est essentiellement le modèle d'objet Smalltalk avec le sucre de syntaxe Perlish. Il se trouve que j'aime le sucre et 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 autour de lui, mais si vous n'êtes pas entré quand il était populaire, c'est pratiquement impossible maintenant.

Toutes les autres raisons sont insignifiantes car il faut passer beaucoup de temps, concentré sur un vrai travail pour apprendre correctement une langue. Si vous n'êtes pas indépendamment riche, la meilleure façon d'y parvenir est de vous y exposer au travail.

Parce que les distributions Smalltalk étaient tarifées par multiples de 1000 USD alors que Ruby est gratuit.

Ruby est à Smalltalk comme les chiffres arabes sont aux chiffres romains. Même maths, syntaxe plus simple.

J'ai fait un petit Smalltalk - l'IDE est une chose dont je me souviens - Ruby a-t-il un bon support IDE?

Utilisez Ruby car il a peut-être des jambes commerciales, ce n'est pas le cas de Smalltalk.

Je peux vous dire par expérience personnelle. J'utilise toujours Smalltalk, j'adore ça 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 soutenu à long terme et la capacité de trouver des employés hors de la rue qui peuvent prendre en charge vos systèmes à l'avenir. Par exemple, Smalltalk était une très grande chose au début des années 90 et IBM y a beaucoup investi à la fin des années 90. Pour IBM, Smalltalk allait être le prochain langage pour toutes les applications métier. 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'histoire. ParkPlace et Digitalk étaient les premiers acteurs commerciaux majeurs dans l'arène Smalltalk, ils ont fusionné puis ont cessé leurs activités.

J'aime à la fois Smalltalk et Ruby - mais j'ai trouvé que Ruby est plus applicable à ce que je fais quotidiennement et est plus proche de mon cœur (pratiquement parlant). Qu'est-ce que Ruby propose que Smalltalk n'offre pas?

• Script basé sur du texte
• Faible exigences de mise en œuvre (s'exécute dans plus d'endroits)
• Plus facile à apprendre et à justifier (les programmeurs Perl et Python n'auront aucun problème
• Plus facile à déplacer des programmes - des fichiers texte!
• S'interface bien avec l'environnement natif
• Partout où 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.

Utilisez tout ce qui vous rend plus puissant et plus rapide pour relever votre défi.

Pour nous , un peu en cadre maison, nous construisons en haut de bord de mer c'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 complexes.

Vous pouvez créer de superbes applications Web en bord de mer en utilisant des éléments 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.

Point de vue intéressant de Robert Martin (de RailsConf 2009): "What Killed Smalltalk could Kill Ruby, Too"

Je pense qu'une partie du problème est le développement-environnement-est-le-runtime. Cela donne beaucoup de puissance, mais cela présente également une courbe d'apprentissage plus large.

Voici un tutoriel Hello World.

C'est très différent des autres langages 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 langages ont un bon code accrocheur qu'ils peuvent montrer. Je n'ai pas vu ça avec Smalltalk. Je pense aussi que Smalltalk est stigmatisé 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".

La VM est vraiment cool et j'espère que ruby ​​aura quelque chose de similaire afin que nous puissions traiter tout sur notre système d'exploitation qui est écrit en ruby ​​comme un objet dans l'espace mémoire, mais jusque-là, j'apprécie simplement la syntaxe courte et concise de Ruby, la capacité de simplement écrivez un petit script et réutilisez-le plus tard. Ruby a tous les avantages de perl et la POO ressemble beaucoup plus à smalltalk qu'au hack POO de perl.

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 suffisante pour tous les goûts, et un sous-ensemble de celles-ci ont une reconnaissance générale (c'est-à-dire que votre responsable vous permettra de les utiliser à fonctionnent 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 langages comme LISP et Smalltalk, bien qu'ils soient intéressants et peut-être éducatifs à regarder.

En retard dans la discussion, le principal problème avec Smalltalk et Lisp est que vous ne pouvez pas les exécuter avec CGI ou FastCGI sur un 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?