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
la source
Réponses:
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.
la source
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.
la source
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
et
Et quand étaient au pays de Lisp, essayez de remplacer LISP par smalltalk
et
la source
Je dirais le contraire: la syntaxe Smalltalk est l'une des syntaxes de langage de programmation les plus simples et les plus puissantes.
la source
Giles Bowkett
la source
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
la source
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.
la source
qu'est-ce que Ruby a que Smalltalk n'a pas?
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.
la source
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:
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 ... :-)
la source
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.
la source
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.
la source
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.
la source
Vous avez répondu à la question de votre première ligne: "Ruby devient populaire"
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é.
la source
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:
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é.
la source
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.
la source
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.
la source
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.
la source
Parce que les distributions Smalltalk étaient tarifées par multiples de 1000 USD alors que Ruby est gratuit.
la source
Ruby est à Smalltalk comme les chiffres arabes sont aux chiffres romains. Même maths, syntaxe plus simple.
la source
J'ai fait un petit Smalltalk - l'IDE est une chose dont je me souviens - Ruby a-t-il un bon support IDE?
la source
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.
la source
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?
Certains ont mentionné gst (GNU Smalltalk); les problèmes persistent.
la source
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.
la source
Point de vue intéressant de Robert Martin (de RailsConf 2009): "What Killed Smalltalk could Kill Ruby, Too"
la source
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.
la source
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.
la source
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.
la source
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?
la source