Ruby: Plus de flexibilité que Java / C #?

Question

Est-ce que je suis un débutant en train d'apprendre Ruby ou a-t-il vraiment plus de moyens d'écrire (les mêmes) choses que Java / C #? De plus, s’il est plus flexible que Java, existe-t-il des fonctionnalités linguistiques de Ruby généralement non utilisées pour éviter toute confusion?

Les exemples peuvent être l’affectation parallèle et les différentes façons d’écrire des chaînes, peut-être?

Remarque: je ne demande pas de comparaison avec Java / C #, mais pour cette question de langage, s'il vous plaît ...

Modifier: Je comprends que C #, Java et Ruby sont fortement typés et que seul Ruby (comme Python et d'autres) est typé de manière dynamique (alors que Java / C # est typé de manière statique). Certaines réponses disent que les langages à typage dynamique sont plus flexibles. Est-ce nécessairement vrai et comment cela affecte-t-il la syntaxe? Je ne pose que des questions sur la flexibilité syntaxique.

(PHP est aussi typé dynamiquement et ne semble pas plus flexible que Java / C #, pour autant que je sache. Encore une fois, je parle de syntaxe et non de déploiement. ni aucun autre aspect ...)

Answer 1

Je ne connais pas Java ou C #, mais je laisse le fait que vous puissiez redéfinir le fonctionnement de + sur les chiffres.

Answer 2

Pour moi, les fonctionnalités les plus utilisées dans Ruby et manquantes en Java sont les blocs de code / lambdas / fermetures.

Une autre fonctionnalité intéressante (mais peut-être dangereuse) est les classes ouvertes - vous pouvez modifier celle qui vous intéresse - ajouter une nouvelle méthode, changer une ancienne, etc. Vous pouvez même ajouter une méthode à un objet spécifique, pas à la classe entière:).

Answer 3

Un autre langage dynamique assez similaire à Ruby est Python. Cependant, dans le Zen de Python , l'une des règles indique que " "il devrait y avoir un, et un seul, moyen de faire quelque chose". C’est à l’opposé de Ruby, qui autorise tellement de méta-programmation qu’il existe un nombre infini de façons de faire la même chose.

Cela dit, il est quelque peu ironique de constater que, jusqu’à Python 3.0 (alias: 3000), les valeurs de chaîne et les valeurs Unicode étaient de types différents. Bien que cela ait du sens, les gens rencontrent parfois des problèmes où ils effectuent souvent des conversions entre les deux pour effectuer des opérations de texte.

Si vous avez le choix, je vous recommanderais presque d'utiliser Python comme introduction aux langages dynamiques. Ruby n’a rien d’inconvénient, mais vous risquez de rencontrer moins de situations où le message "correct" façon de faire quelque chose n'est pas totalement évident.

En réponse à la saisie dynamique de PHP:

Le système de types de PHP est flexible, permettant la conversion automatique des types en fonction du contexte dans lequel ils sont utilisés. Toutefois, cela ne crée pas de véritables types dynamiques. Le langage lui-même est essentiellement statique et ne vous permettra pas d'ajouter des attributs aux objets lors de l'exécution, par exemple (du moins, la dernière fois que j'ai vérifié).

Python, et peut-être Ruby, sont en fait fortement typés, ce qui signifie que vous pouvez faire des comparaisons de types en toute confiance et que vous ne pouvez pas utiliser les astuces PHP comme ajouter des chaînes numériques pour obtenir un nombre. Les vrais langages dynamiques permettent également souvent la méta-classification où vous pouvez ajuster le type d'une instance ou d'une classe, ou ajouter des attributs à l'un ou l'autre, le tout à l'exécution.

Answer 4

Ruby est un langage dynamique. C # et Java sont tous les deux des langages statiques à typage fort. C # in v4.0 ajoutera des fonctionnalités dynamiques, mais jusqu'à présent, Java et C # avaient un paradigme complètement différent et plus strict que les langages dynamiques tels que Ruby et Python.

Answer 5

J'ai commenté la réponse de rkj ci-dessus concernant celle de lambda. Ce code illustre l'exemple que vous avez demandé;

def abs(n); (n < 0) ? -n : n; end
def square(n); n * n; end
def average(x, y); (x + y) / 2; end

def fixed_point(x, point, process, test)
  return point if test.call(x, point)
  fixed_point(x, process.call(x, point), process, test)
end

def sqrt(n)
  process = lambda {|n,g| average g, (n/g) }
  test = lambda {|n,g| abs(square(g) - n) < 0.001} 
  fixed_point(n, 1.0, process, test)
end

Le premier point à noter est que la méthode fixed_point gère l'idée générale d'appliquer progressivement un processus à certaines données jusqu'à ce qu'il passe un certain test. La fonction sqrt définit le processus de recherche d'une racine carrée et le test permettant de déterminer quand nous devons être satisfaits. Ces "procédures" sont ensuite transmises comme n'importe quelle autre forme de données afin que fixed_point puisse fonctionner de manière magique.

Au lieu de stocker temporairement le processus et de le tester, le tout pourrait être anonyme. Nous pourrions réécrire sqrt comme;

def sqrt(n)
  fixed_point( n, 1.0, 
      lambda {|n,g| average g, (n/g)},
      lambda {|n,g| abs(square(g) - n) < 0.001} )
end

Sans cette possibilité, je devrais définir à la fois le processus et le test en tant que fonctions individuelles et créer une fonction spéciale sqrt_fixed_point pour les appeler. Autant que je sache, Java peut faire quelque chose de similaire en utilisant Functors mais je ne sais pas assez pour commenter. Le consensus que j'ai vu dans les blogs ou similaires est que Java rend cela tellement horriblement compliqué que vous aurez un saignement de nez rien que de l'essayer.

Bien sûr, une autre option proposée par Ruby est la métaprogrammation. Je pourrais réécrire sqrt pour qu'il réécrit (à la volée) fixed_point en utilisant le processus et le test corrects, mais ceci constitue probablement un abus de la fonctionnalité: -)

ps. Le lien JoelOnSoftware est affiché mérite d'être répété; http://www.joelonsoftware.com/items/2006/08/01. html

Answer 6

Tous les langages à typage dynamique (comme Ruby) sont généralement plus flexibles que ceux à typage statique (comme Java). Vous n'avez pas à vous battre avec le système de types, ce que vous finissez souvent par utiliser dans des langages statiques.