Pourquoi utiliser Ruby au lieu de Smalltalk ?

Question

Ruby devient populaire Le projet a été conçu en grande partie sous l'influence de Ruby on Rails, mais on a l'impression qu'il se débat actuellement dans son adolescence. Il y a beaucoup de similitudes entre Ruby et Smalltalk -- maglev en est la preuve. Malgré une syntaxe plus inhabituelle, Smalltalk possède toute (sinon plus) 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é
• Soutien commercial
• Contrôle distribué des sources (comprend la structure du code, pas seulement les différences de texte)
• Plusieurs mises en œuvre de la VM
• Support multiplateforme
• En cadre web du bord de mer en tant que une alternative forte à Rails

On dirait 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 que Smalltalk n'a pas ?

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

---

Edit : Je pense que la question de la facilité d'écriture des scripts a été traitée par GNU Smalltalk . Si j'ai bien compris, cela vous permet d'écrire de la smalltalk dans de bons vieux fichiers texte, et vous n'avez plus besoin d'être dans l'IDE Smalltalk. Vous pouvez alors exécutez vos scripts avec :

gst smalltalk_file

Answer 1

Je suis plus un Pythoniste qu'un utilisateur de Ruby, mais les mêmes choses s'appliquent à Ruby pour les mêmes raisons.

• L'architecture de Smalltalk est quelque peu isolée, alors que Python et Ruby ont été conçus dès le départ pour faciliter l'intégration. Smalltalk n'a jamais vraiment bénéficié d'un support d'applications hybrides comme l'ont fait Python et Ruby, de sorte que le concept de "smalltalk comme langage de script intégré" n'a jamais été adopté.

  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 en notoriété. L'argument de l'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 considérablement amélioré l'insularité.

• La bibliothèque de classes de la plupart des principales implémentations smalltalk (VisualWorks, VisualAge, etc.) était volumineuse et avait la réputation d'avoir 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 également un choc culturel pour quelqu'un qui n'y est pas familier, et la vue fragmentaire du programme présentée par le navigateur est assez différente de ce à quoi la plupart des gens sont habitués.

  L'effet global est que Smalltalk a acquis la réputation (quelque peu méritée) d'être difficile à apprendre ; il faut beaucoup de temps et d'efforts pour devenir un programmeur Smalltalk vraiment compétent. Ruby et Python sont beaucoup plus faciles à apprendre et à mettre à niveau pour les nouveaux programmeurs.

• Historiquement, les principales implémentations de Smalltalk étaient assez coûteuses et nécessitaient un matériel exotique pour fonctionner, comme on peut le voir. cet affichage net.lang.st80 de 1983 . Windows 3.1, NT et '95 et OS/2 ont été les premiers systèmes d'exploitation grand public sur du matériel courant capable de supporter une implémentation de Smalltalk avec une intégration décente du système natif. Auparavant, le matériel Mac ou les stations de travail étaient les plates-formes les moins chères capables d'exécuter Smalltalk efficacement. Certaines implémentations (notamment Digitalk) supportaient assez bien les systèmes d'exploitation PC et ont réussi à s'imposer.

  Cependant, OS/2 n'a jamais connu le succès escompté et Windows n'a pas été accepté par le grand public avant le milieu des années 1990. Malheureusement, cette période a coïncidé avec la montée en puissance du Web en tant que plate-forme et avec une importante campagne de marketing en faveur de Java. Java s'est emparé de l'essentiel de l'esprit à la fin des années 1990, faisant de Smalltalk une sorte de parent pauvre.

• Ruby et Python fonctionnent dans une chaîne d'outils plus conventionnelle et ne sont pas étroitement liés à un environnement de développement spécifique. Bien que les IDE Smalltalk que j'ai utilisés soient assez agréables, j'utilise PythonWin pour le développement Python, principalement parce qu'il dispose d'un éditeur agréable avec coloration syntaxique et qu'il ne se laisse pas marcher sur les pieds.

  Cependant, Smalltalk a été conçu pour être utilisé avec un IDE (en fait, Smalltalk était l'IDE graphique original) et possède encore quelques fonctionnalités intéressantes qui ne sont pas reproduites par d'autres systèmes. Tester du code en le surlignant et en le montrant est une fonctionnalité très agréable que je n'ai jamais vue dans un IDE Python, mais je ne peux pas parler pour Ruby.

• Smalltalk est arrivé un peu tard à 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 qu'avec la sortie de Seaside qu'un cadre web décent a été accepté dans les cercles Smalltalk. Entre-temps, Java EE a connu un cycle de vie complet d'acceptation, en commençant par des fanboys déchaînés qui en faisaient la promotion, pour finalement se lasser et passer à Ruby ;-}

  Ironiquement, Seaside commence à avoir une certaine notoriété auprès des spécialistes, et Smalltalk pourrait donc retrouver sa popularité.

Cela dit, Smalltalk est un système très agréable une fois que l'on a compris comment le piloter.

Answer 2

Lorsque je quitte ma maison le matin pour me rendre au travail, j'ai souvent du mal à prendre la décision de tourner à gauche ou à droite en sortant de mon allée (je vis au milieu d'une rue). L'une ou l'autre voie me mènera à ma destination. L'une d'elles me conduit à l'autoroute qui, en fonction du trafic, me conduira probablement au bureau le plus rapidement. Je peux conduire très vite pendant au moins une partie du trajet et j'ai de bonnes chances de voir une ou deux jolies filles sur le chemin du travail :-)

L'autre voie me permet d'emprunter une route de campagne enchanteresse, venteuse et entièrement couverte d'arbres. Ce chemin est très agréable et des deux approches, c'est certainement la plus amusante, même si cela signifie que j'arriverai au bureau plus tard que si j'avais pris l'autoroute. Chaque chemin a ses mérites. Les jours où je suis très pressé, je prends généralement l'autoroute, mais je risque de me heurter à la circulation et d'augmenter mes chances d'avoir un accident (si je ne suis pas prudent dans ma hâte). D'autres jours, je peux choisir le chemin boisé, rouler en profitant du paysage et me rendre compte que je suis en retard. Je peux essayer d'accélérer, augmentant ainsi mes chances de recevoir une contravention ou de provoquer moi-même un accident.

Aucune des deux voies n'est meilleure que l'autre. Elles ont toutes leurs avantages et leurs risques, et chacune me mènera à mon but.

Answer 3

Je pense que votre question passe un peu à côté de l'essentiel. Vous ne devrait pas choisir, vous devriez apprendre les deux !

Si vous êtes vraiment dans une position où vous pouvez choisir le prochain framework (vm, infrastructure), alors vous devez décider de ce que vous allez utiliser et vous pouvez poser une question spécifique avec les avantages et les inconvénients du point de vue de ce que votre application est censée faire.

J'ai utilisé smalltalk (je l'adore) et ruby (je l'adore).

À la maison ou pour un projet open source, je peux utiliser tous les langages que je veux, mais au travail, je dois adopter.

J'ai commencé à utiliser ruby (au travail) parce que nous avions besoin d'un langage de script qui se comportait de manière plus ou moins égale sous solaris, linux et Windows (98, 2000, xp). Ruby était à l'époque inconnu du commun des mortels et il n'existait pas de rails. Mais c'était facile à vendre à toutes les personnes concernées.

(Pourquoi pas python ? la vérité ? Une fois, j'ai passé une semaine à chercher un bogue qui s'est produit lorsqu'un terminal a converti mon espace en tabulation 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.

Paul Graham résume la situation

Il est vrai, certes, que la plupart des gens ne choisissent pas les langages de programmation simplement en fonction de leurs mérites. La plupart des programmeurs se font dire par quelqu'un d'autre quel langage utiliser.

y

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 à jeter.

Et quand nous sommes au pays de Lisp, nous essayons de remplacer LISP par smalltalk.

Les bibliothèques, la communauté et la dynamique de Ruby sont bonnes.

Donc, si LISP est toujours plus puissant que Ruby, pourquoi ne pas utiliser LISP ? L'approche typique objections à la programmation en LISP sont :

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

Ce ne sont pas des objections massives, mais elles valent certainement la peine à considérer.

y

Maintenant, si vous avez le choix entre un puissant et un langage populaire, il peut être un excellent sens de choisir le puissant. Mais si la différence de puissance est mineure, être populaire a toutes toutes sortes d'avantages. 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 agissent comme de véritables compilateurs à part entière.

Answer 4

Je dirais le contraire : La syntaxe Smalltalk est l'une des syntaxes les plus simples et les plus puissantes des langages de programmation.

Answer 5

C'est vrai que les langues se ressemblent beaucoup. La façon la plus superficielle d'interpréter cela est d'appeler Ruby un groupe de reprises de 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 son habitude de s'approprier des fonctionnalités de tous les langages sous le soleil lui confèrent une courbe d'adoption infiniment plus douce et une intégration sans effort avec des outils géniaux comme Git.

Giles Bowkett