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

https://stackoverflow.com/questions/187380

06-07-2019
|

Question

Ruby devient populaire , en grande partie du Ruby on Rails, mais on dirait qu’il est actuellement en difficulté pendant son adolescence. Il existe de nombreuses similitudes entre Ruby et Smalltalk - maglev en est la preuve. 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ée dans les années 1970)
Stabilité
Assistance commerciale
Contrôle de code source distribué (comprend la structure du code, pas seulement la modification du texte)
Plusieurs implémentations de la machine virtuelle
Prise en charge multiplate-forme
Le infrastructure Web Seaside en tant que alternative forte aux rails

Il semble que Ruby réinvente la roue. Alors, pourquoi les développeurs Ruby n'utilisent-ils pas SmallTalk? Qu'est-ce que Ruby a pour le Smalltalk 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.

Modifier: Je pense que le Forum a été réglé. GNU Smalltalk . Si je comprends bien, cela vous permet d’écrire smalltalk dans de vieux fichiers texte normaux, et vous n’avez plus besoin d’être dans l’EDI Smalltalk. Vous pouvez ensuite exécuter vos scripts avec:

gst smalltalk_file

La solution

Je suis plus un utilisateur pythoniste qu'un utilisateur Ruby, mais les mêmes choses s'appliquent à 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 parallèle, Java n’était pas la chose la plus simple. pour interfacer avec d'autres bases de code (JNI est assez maladroit), mais cela ne l'a pas empêché de gagner de la notoriété. L’argument d’interfaçage de l’OMI est important - Python n’a pas fait mal à l’incorporation - mais cet argument n’a qu’un poids modéré, car toutes les applications n’exigent pas cette fonctionnalité. De plus, 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 volumineuse et réputée pour sa 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 tels que les flux et les collections. Le paradigme de la langue est aussi une sorte de choc culturel pour quelqu'un qui ne le connaît pas, et la vue fragmentée du programme présentée par le navigateur est assez différente de celle à laquelle la plupart des gens étaient habitués.

L'effet général est que Smalltalk a la réputation (un peu méritée) d'être difficile à apprendre; devenir un programmeur Smalltalk vraiment compétent nécessite beaucoup de temps et d’efforts. Ruby et Python sont beaucoup plus faciles à apprendre et à familiariser les nouveaux programmeurs.
Historiquement, les implémentations Smalltalk classiques étaient assez coûteuses et nécessitaient du matériel exotique, comme on peut le voir cette publication 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 grand public capable de prendre en charge une implémentation de Smalltalk avec une intégration système décente. Auparavant, le matériel Mac ou de station de travail était la plate-forme la moins chère capable d'exécuter efficacement Smalltalk. Certaines implémentations (en particulier Digitalk) supportaient assez bien les systèmes d’exploitation pour PC et réussissaient à gagner du terrain. Cependant, OS / 2 n’a jamais été aussi performant et Windows n’a pas été accepté par la majorité avant le milieu des années 90. Malheureusement, cela a coïncidé avec la montée en puissance du Web en tant que plate-forme et une poussée marketing importante derrière Java. Java a capturé l'essentiel de la répartition de l'esprit à la fin des années 1990, ce qui a rendu Smalltalk un peu à part.
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. 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 dispose d’un bon éditeur avec mise en surbrillance de la syntaxe et ne tombe pas sous le pied. 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 non répliquées par d’autres systèmes. Tester le code avec le surlignage et 'Show it' reste une très belle fonctionnalité que je n'ai jamais vue dans un environnement de développement Python, bien que je ne puisse pas parler pour Ruby.
Smalltalk était un peu en retard pour la partie applications Web. Les premiers efforts tels que VisualWave n’ont jamais été aussi fructueux et ce n’est que lorsque Seaside est sorti qu’un cadre Web décent a été accepté par les cercles Smalltalk. En attendant, Java EE a eu un cycle de vie d'acceptation complet commençant par des fans enthousiastes pour la promouvoir et s'ennuyer finalement pour Ruby; -}

Ironiquement, Seaside commence à avoir un peu de mentalité parmi les cognoscenti peut trouver que les manèges Smalltalk redeviennent populaires.

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

Autres conseils

Quand je sors de chez moi le matin pour aller au travail, j'ai souvent du mal à prendre la décision de tourner à gauche ou à droite de mon allée (je vis au milieu d'une rue). De toute façon, ça me mènera à ma destination. Un chemin me mène à l'autoroute qui, selon le trafic, m'emmènera probablement au bureau le plus rapidement. Je conduis très vite au moins une partie du trajet et j’ai de bonnes chances de voir une jolie fille ou deux se rendre au travail: -)

L’autre façon de faire me permet de parcourir une route très enchanteresse et venteuse avec une couverture forestière complète. Ce chemin est très agréable et des deux approches est certainement le plus amusant, bien que cela signifie que je vais arriver au bureau plus tard que je ne l'aurais eu sur l'autoroute. Chaque voie a ses mérites. Les jours où je suis très pressé, je vais généralement prendre l'autoroute, même si je risque de rencontrer des embouteillages et j'augmente également mes chances d'être victime d'un accident (si je ne fais pas attention à la 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, d’augmenter mes chances d’obtenir un billet ou de provoquer un accident moi-même.

Aucune voie n'est meilleure que l'autre. Ils ont chacun leurs avantages et leurs risques, et chacun me conduira à mon objectif.

Je pense que votre question manque quelque peu. Vous ne devez pas choisir, vous devez apprendre à la fois!

Si vous êtes vraiment en mesure de choisir le cadre suivant (vm, infrastructure), vous devez décider de ce qu'il faut utiliser et pouvoir poser une question précise présentant les avantages et les inconvénients du point de vue de l'objectif de votre application. faire.

J'ai utilisé smalltalk (love it) et ruby ??(love it).

À la maison ou pour un projet open source, je peux utiliser toutes les langues que j’aime mais je dois adopter le travail que je fais.

J'ai commencé à utiliser ruby ??(au travail) car nous avions besoin d'un langage de script plus ou moins homogène sous Solaris, Linux et Windows (98,2000, xp). Ruby était à l'époque inconnu de Average-Joe et il n'existait aucun rail. Mais il était facile de vendre à toutes les personnes impliquées.

(Pourquoi pas python? La vérité? J'ai déjà passé une semaine à la recherche d'un bogue qui se produisait lorsqu'un terminal convertissait mon espace en onglet et que l'intention était foirée).

Les gens ont donc commencé à coder de plus en plus en rubis parce que c'était tellement relaxant, agréable et pas un nuage dans le ciel.

Paul Graham résume sa situation

Il est vrai 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 du langage à utiliser par quelqu'un d'autre.

Pour attirer les hackers, un la langue doit être bonne pour écrire le types de programmes qu’ils veulent écrire. Et cela signifie, peut-être étonnamment, qu'il doit être bon pour l'écriture programmes jetables.

Et quand étaient au Lisp atterrissez pour remplacer LISP par smalltalk

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


Donc, si LISP est encore plus puissant que   Ruby, pourquoi ne pas utiliser LISP? Le typique   Les objections à la programmation dans LISP sont:


Il n’ya pas assez de bibliothèques.

Nous ne pouvons pas engager de programmeurs LISP.

LISP n’est allé nulle part au cours des 20 dernières années.


Ces objections ne sont pas accablantes,   mais ils valent certainement la peine   compte tenu.

Maintenant, étant donné le choix entre un puissant langue, et la langue populaire, il peut bon sens de choisir le un puissant. Mais si la différence de le pouvoir est mineur, être populaire a tout sortes de beaux avantages. En 2005, je ferais réfléchir longuement avant de choisir LISP sur Ruby. Je ferais probablement que si j'avais besoin d'un code optimisé, ou macros qui ont agi comme à part entière compilateurs.

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, les langues se ressemblent beaucoup. La façon superficielle d'interpréter cela consiste à appeler Ruby une bande de reprise Smalltalk. L’interprétation la plus raisonnable est que le système fermé de Smalltalk l’isole, tandis que la participation de Ruby à l’écologie Unix et l’habitude de s'approprier les fonctionnalités de toutes les langues parlées sous le soleil lui confèrent 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 pas si on l'appellerait 'Ruby' quand ce serait fait. "

Rouleau de tambour ....

...

La réponse est ... Kent Beck

Stéphane Ducasse a quelques excellents livres Smalltalk disponibles ici:

http://stephane.ducasse.free.fr/FreeBooks.html

Ainsi, bien que la communauté Smalltalk ne soit pas aussi prolifique que les communautés Ruby et Rails, il existe toujours une aide précieuse.

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

Prise en charge massive et actuelle des principales plates-formes (IronRuby et jRuby) enrichissant 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 aux conférences Java affirmant qu'il ne connaissait pas Java et qu'il préférait Ruby.
Des biens immobiliers solides et actuels sur les étagères
Le créateur de Ruby a déclaré qu'il pensait au programmeur: la syntaxe de Ruby semble avoir cet attrait zen. C'est difficile à cerner, mais cela semble galvaniser les fans.
Des présentations dynamiques et créatives telles que Giles et celui-ci qui gagne en partage d'esprit

Je pense que votre argument est bien compris. Comme un ami l’a déjà dit, Ruby pourrait être un "vieux vin dans une nouvelle bouteille". vis-à-vis de Smalltalk. Mais parfois, la nouvelle bouteille est importante. Un vin doit être au bon endroit au bon moment.

me bat. J'ai passé un an à consulter Ruby et à faire de petits projets pour voir si cela me plaisait. Je suppose que je suis un bigot de Smalltalk parce que chaque fois que je travaillais avec Ruby, je soupirais et pensais "je préférerais vraiment le faire en Smalltalk". Finalement, j'ai cédé et je suis retourné à Smalltalk. Maintenant je suis plus heureux. Plus c'est mieux, mieux.

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

Parce que l'IDE élimine tout ce avec quoi j'ai travaillé. Cela inclut un grand nombre de plates-formes allant d'ISPF sur des mainframes IBM au Visual (. *) De Microsoft, notamment Visual Basic 4-6, Visual C ++ (diverses incarnations), le Turbo Pascal de Borland et ses descendants (par exemple, Delphi), et d'autres choses sur le DEC. machines en mode caractère et sous X-Windows.
Parce que l'image est un bel endroit pour vivre. Je peux trouver ce que je veux là-dedans. Si je ne sais pas 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 je dois 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 de 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 la même chose en Ruby / C ++ / C, mais ce n’est pas aussi facile. Facile c'est mieux.
La langue est minimale et cohérente. 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 petite syntaxe, vraiment - tout est fait avec les envois de messages. (OK, l'affectation n'est pas un message envoyé, c'est un opérateur. C'est donc l'opérateur 'retour' (^). Les blocs sont entourés par des paires d'accolades carrées ([]). Peut-être un ou deux autres bits 'magiques', mais sacrément peu ...).
Blocs. Ouais, je sais, ils sont là en Ruby (et d'autres), mais bon sang, vous ne pouvez littéralement pas programmer en Smalltalk sans les utiliser. Vous êtes forcé à apprendre à les utiliser. Parfois, être forcé est bon.
Programmation orientée objet sans compromis ni alternative, d'ailleurs. Vous ne pouvez pas prétendre que vous "faites des objets". toujours en train de faire la même chose.
Parce que ça 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. Différemment est bon.

D’autre part, il s’agit peut-être des rumeurs d’un type programmant depuis l’époque où les ordinateurs centraux régnaient sur la Terre, nous avons dû parcourir cinq miles pour affronter des tempêtes de neige aveuglantes, des montées dans les deux sens et des ordinateurs qui utilisaient des beignets pour se souvenir . 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 avance si vrai: [pense] siFaux: [ne pense pas]

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

1) Le flux de contrôle RPN de type Smalltalk par messages ressemble à Lisp - il est normal et cool, mais il rend les gens étranges.

2) Ruby permet aux utilisateurs d’écrire du code de la manière idiomatique utilisée: bla sauf si il existe une raison de ne pas le faire.

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

Ruby est la langue de buzz actuelle. Il est plus facile de commercialiser un logiciel construit avec ce logiciel actuellement qu'un langage développé dans les années 70.

Communauté! Ruby et surtout Rails ont une telle communauté. Quand on s'amuse avec Smalltalk, il semble qu’il n’y ait pas autant d’écrans de projection, d’articles, de billets de blog, etc. écrits sur Smalltalk.

Vous avez répondu à la question à la première ligne: "Ruby est en train de devenir populaire"

Il y a beaucoup de modules, projets et autres intéressants basés sur Ruby.
Si vous avez du mal à faire quelque chose en Ruby, il sera facile de trouver de l'aide quelque part.
Ruby est installé sur un lot d'ordinateurs (inclus par défaut sous OS X, dans de nombreuses distributions Linux et il existe de bons programmes d'installation pour Windows). sur n'importe quelle machine que j'ai utilisée ..

Je dirais qu’une langue est supérieure ou non à une autre n’est pas pertinente. Par exemple, PHP peut ne pas être le "meilleur". langage, mais j’envisagerais toujours de l’utiliser par-dessus Ruby on Rails (un outil "de meilleure qualité" pour la création de sites Web) car il est si répandu.

En principe, 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. À savoir:

De Dave Thomas lui-même, "[après la] vidéo sur 'Comment construire un blog en Ten Minutes '... Ruby est passé d'être une belle petite langue de niche, à être 'une langue que vous avez écrite Rails applications dans '" ( Conférence Ruby 2010 discours ).
Les premiers vendeurs Smalltalk accusés de manière prohibitive
Smalltalk, parce qu’il a été inventé (en avance sur son temps) il y a 30 ans, est considéré par beaucoup comme un vieil homme "mort". langue (comme FORTRAN)
Les entreprises considèrent Smalltalk comme un avantage concurrentiel tel que ils cachent son utilisation

Bien que les fonctionnalités OO soient similaires dans les langues, l'avantage de killer de Smalltalk est son environnement ouvert et réel ("l'image" très mal comprise). Après avoir vérifié 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’elle n’a pas, c’est le besoin d’une machine virtuelle et d’un environnement complet.

Smalltalk est génial - c’est là où j’ai appris les concepts d’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 à partir de 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 moment reconnaissent sa profonde dette envers Smalltalk. En tant que l'une de ces personnes, qu'est-ce que j'aime chez Ruby par rapport à Smalltalk? Je pense que du point de vue strictement linguistique, c'est le sucre. Ruby est délibérément un langage très sujette à la syntaxe, alors que Smalltalk est un langage très syntaxique. Ruby est essentiellement le modèle d'objet Smalltalk avec le sucre de syntaxe Perlish. J'aime le sucre et je trouve que cela rend la programmation plus amusante.

Vous pouvez facilement trouver un travail chez Ruby. Bien que j'aime vraiment Smalltalk, il est pratiquement impossible d'entrer dans le créneau de Smalltalk. Il y a du travail dedans, mais si vous n'y arrivez pas quand c'était populaire, c'est pratiquement impossible maintenant.

Toutes les autres raisons sont insignifiantes, car vous devez passer beaucoup de temps et vous concentrer sur le vrai travail pour apprendre correctement une langue. Si vous n'êtes pas indépendamment fortuné, la meilleure façon de le faire est de vous exposer au travail.

Parce que les distributions Smalltalk étaient facturées par multiples de 1 000 USD alors que Ruby est libre.

Ruby est à Smalltalk comme les chiffres arabes sont à des chiffres romains. Mathématiques identiques, syntaxe plus simple.

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

Utilisez Ruby, car Smalltalk n’a peut-être pas une base économique.

Je peux vous dire par expérience personnelle. Toujours en utilisant Smalltalk, j'adore, et j'ai utilisé quelques saveurs. Bien que Smalltalk soit une excellente langue et reprenne tout ce que vous avez mentionné, vous ne convaincrez probablement pas le DSI / CTO moyen d’utiliser Smalltalk dans 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 faire très attention si vous souhaitez un support commercial durable à long terme et la possibilité de trouver des employés clandestins pouvant prendre en charge vos systèmes à l'avenir. Par exemple, Smalltalk était très important 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é la langue (leur terme est le coucher du soleil). Jetez également un coup d'œil à l'historique. ParkPlace et Digitalk, qui ont été les premiers acteurs commerciaux majeurs dans l’arène Smalltalk, ont fusionné puis ont cessé leurs activités.

J'aime à la fois Smalltalk et Ruby - mais j’ai constaté que Ruby s’appliquait mieux à ce que je fais tous les jours et qu’il me tenait plus à cœur (pratiquement, en réalité). Qu'est-ce que Ruby offre à Smalltalk?

Scripts basés sur du texte
Exigences d'implémentation faibles (s'exécute à plusieurs endroits)
Plus facile à apprendre et à justifier (les programmeurs Perl et Python n'auront pas de problèmes
Plus facile de déplacer les programmes - fichiers texte!
S'interface bien avec l'environnement natif
N'importe 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 tiennent toujours.

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

Pour nous , un cadre un peu interne, nous avons construit en haut de la côte est vraiment notre superpuissance.

J'aime la communauté RoR, elle a la bonne attitude. C'est très très précieux. Mais parallèlement, sur le plan technologique, la mer vous rend plus fort face à des problèmes plus complexes.

Vous pouvez créer d'excellentes applications Web balnéaires à l'aide de logiciels 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 faire. Montrez-nous que ça marche.

Vous n'êtes pas seul. Nous sommes sur le même bateau.

Point de vue intéressant de Robert Martin (d'après RailsConf 2009): & "Qu'est-ce qui a été tué? Smalltalk pourrait tuer Ruby, Trop & ;

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

Voici un didacticiel Hello World.

C’est très différent des autres langages dans lesquels je dois juste savoir comment ouvrir un éditeur de texte, copier et coller du texte, cliquer sur Enregistrer et exécuter un compilateur. Je dois savoir comment utiliser l'environnement. Ce tutoriel ne m’a même pas montré comment créer un programme de base que je peux exécuter (ce qui est probablement davantage une faute de ce tutoriel).

Il y a certainement un coût plus élevé de la simple mise en train que la plupart des autres langues.

La plupart des langues ont un code attrayant qu’elles peuvent montrer. Je n'ai pas vu ça avec Smalltalk. Je pense aussi que Smalltalk est quelque peu stigmatisé parce que cela fait si longtemps et que cela reste relativement obscur.

Je pense que la PLUS GRANDE différence est que Ruby ressemble beaucoup plus à perl en ce qui concerne USEAGE. Smalltalk n’a jamais pris pied dans le & script; scripting " langues.

La machine virtuelle est vraiment cool et j’espère que ruby ??aura quelque chose de similaire pour que nous puissions traiter tout ce qui est écrit sur notre système d’exploitation écrit en ruby ??en tant qu’objet dans l’espace mémoire. possibilité d'écrire un petit script et de le réutiliser plus tard. Ruby a tous les avantages de perl et la POO ressemble beaucoup plus à Smalltalk que le hack de Perl.

J'irais plus loin que la réponse de Jonke en disant 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 ces langues est reconnu par le grand public (c’est-à-dire que votre responsable vous laissera utilisez-les aussi au travail).

Il est facile d'apprendre les bases d'une langue, 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. McConnell affirme qu'il faut environ trois ans pour devenir véritablement compétent.

Compte tenu de ces éléments, il est difficile de justifier de consacrer beaucoup de temps aux langues telles que LISP et Smalltalk, bien qu'elles soient intéressantes et peut-être instructives à regarder.

En tant que retardataire à la discussion, le principal problème de Smalltalk et de 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. IMHO Seaside est supérieur à presque tout, mais fonctionnera-t-il sur Dreamhost ou Webfaction?

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow