Une introduction à Ruby

a marqué ce sujet comme résolu.

Je sais que ça risque de passer pour une obsession, mais je trouve que ce serait bien qu'il y ait une partie (ou une annexe) qui explique comment est composée la documentation, comment s'en servir, afin d'être autonome à la fin du tutoriel, de savoir où et comment chercher, de pouvoir approfondir soi-même au besoin.

Je sais que ça risque de passer pour une obsession, mais je trouve que ce serait bien qu'il y ait une partie (ou une annexe) qui explique comment est composée la documentation, comment s'en servir, afin d'être autonome à la fin du tutoriel, de savoir où et comment chercher, de pouvoir approfondir soi-même au besoin.

Mysterri1

On connait le sujet de la prochaine annexe, merci à toi :)

Je vous ai envoyé quelques corrections en MP (très légères), j'espère ne pas vous avoir spammé :). Bonne continuation !

flool

J'ai tout corrigé dès que tu as envoyé les messages. Merci. Mais ce serait mieux d'envoyer des corrections pour la version qui est en bêta puisqu'il y a déjà des choses très différentes de la version en ligne.

+0 -0

Je vous ai envoyé quelques corrections en MP (très légères), j'espère ne pas vous avoir spammé :). Bonne continuation !

flool

J'ai tout corrigé dès que tu as envoyé les messages. Merci. Mais ce serait mieux d'envoyer des corrections pour la version qui est en bêta puisqu'il y a déjà des choses très différentes de la version en ligne.

Karnaj

Mince, je pensais être sur la bêta. Je suis nouveau ici, je pense m'être trompé, mais je ne vois pas comment accéder à la version dont tu parles (j'ai suivi le lien de "baptisteguil" : "Lien de la beta du tutoriel : Une introduction à Ruby").

Tu étais bien sur la bêta, c'est moi qui me suis trompé…

+0 -0

Les modifications :

  • modifications de la partie I presque finies, elle est plus complète
  • Lalla a commencé a rédigé sur la partie II
  • L'annexe a été modifiée

Je me demande s'il ne faut pas placer l'extrait Opérations du chapitre 2 à la fin du chapitre 1. Vous en pensez quoi ?

+0 -0

Ce pourrait être une bonne idée. En regardant rapidement la fin du chapitre 1 et le début du chapitre 2, on a une impression de répétition. Je pense que regrouper l'extrait Opérations à l'extrait Prise en main serait judicieux.

Emeric

C'est ce que je me disais aussi. Je vais attendre l'avis d'autres personnes mais je pense fermement qu'il a sa place à la fin du chapitre 1. Le but est d'enchaîner avec les variables dès le début du chapitre 2.

+0 -0

ça fait un moment que je n'étais pas venu sur le site. A ma grande surprise un tuto sur ruby est apparu :)

Alors évidemment, je me suis empressé de le lire, et plusieurs choses me chiffonnent.

EDIT : Oups, je n'ai pas lu le tuto en bêta, mais celui en page d'acceuil. Je m'empresse de lire la bêta. EDIT 2 : C'est fait, a présent je m'attaque à la partie 2 EDIT 3 : Finis !

Introduction

Dès l'introduction, on a le droit à "En Ruby, tout est objet". Le sens de cette phrase coule de source pour quelqu'un habitué à la notion d'objet. Un débutant sera alors, quant à lui, largué dès l'introduction. Je pense qu'en premier lieu, il est inutile d'aborder la notion d'objet. De toute façon, le tutoriel n'y fait jamais allusion (du moins, pour l'instant :D).

Nombres, arithmétique, variables et chaines de caractère

  • On pourrait ajouter l'opérateur ** (puissance) à la liste des opérateurs.
  • On pourrait parler des variables globales ($globale), ou encore globales et constantes ($GLOBALE)
  • Tant qu'à parler des string, je suis un fervent défenseur de l'interpolation des chaines. ON ne fait pas "Hello " + mot, mais "Hello #{mot}". En plus, c'est souvent plus efficace.
  • Une chaine s'écrit avec " ou '.
  • Ne pas oublier la méthode to_sym dans la partie conversion de variable
  • Pour un débutant, je ne pense pas que parler de \n soit judicieux. Autant dire Saut de ligne tout simplement. (EDIT : cependant, c'est très bien expliqué dans la bêta)
  • p est une autre façon de représenter les objets (Elle appelle la méthode inspect de l'objet)

Les conditions

Il faudrait préciser que tout a pour valeur de vérité vrai, SAUF false et nil.

Les boucles

Rien à dire

Mini TP

Rien à dire dessus.

Les tableaux

Rien à dire.

Les HashMap

Il manque cette partie ;) On pourrait aussi aborder les symboles dans celle ci, puisqu'ils sont souvent utilisés en tant que clef.

Les fonctions

Je n'ai jamais vu le terme "procédure" dans le langage Ruby. Une méthode renvoie TOUJOURS quelque chose. nil n'est rien d'autre que le NULL du C, le nullptr du C++ ou le null du Java. Et pourtant, dans ces mêmes langages, lorsqu'une fonction renvoie une valeur nulle, son type de retour n'est pas void. Autrement dit, nil n'est pas rien !

D'ailleurs, en parlant de nil, il n'a encore jamais été abordé dans le tutoriel, il doit être explicité avant.

Il faudrait préciser que return est facultatif

1
2
3
4
5
6
7
8
9
def add(x, y)
    return x + y
end

# Equivaut à 

def add(x, y)
    x + y
end

De même, il faudrait préciser que les parenthèses lors des appels de fonction sont facultatives.

Eventuellement, on pourrait parler des paramètres variadiques

1
2
3
4
def f(*args, **kwargs)
  # args est considéré comme un tableau
  # kwargs est considéré comme une hashmap
end

Mais ça me semble un peu avancé à ce stade.

Les classes

Utiliser la méthode class me semble indispensable dans ce chapitre.

Autres remarques

Les commentaires sont beaucoup utilisés dans les codes d'exemple, mais a aucun moment il n'est expliqué de quoi il s'agit.

Bon, je critique, je critique, mais je tiens tout de même à vous féliciter pour ce travail. J'ai déjà mis un temps fou à écrire ce commentaire, alors je n'imagine pas le temps que vous avez du mettre pour rédiger cette introduction.

Continuez comme ça ! Si jamais vous avez besoin d'un coup de main, faites le moi savoir ;)

+1 -0

Merci pour ton retour. :) Comme tu as pu le voir, la version en bêta est plus avancée que celle en ligne. Tes remarques seront bien sûr prises en comptes. Les Hash seront vus dans la deuxième partie comme second exemple de classes (après l'approfondissement des tableaux).

EDIT : Oups, je n'ai pas lu le tuto en bêta, mais celui en page d'accueil. Je m'empresse de lire la bêta. EDIT 2 : C'est fait, a présent je m'attaque à la partie 2 EDIT 3 : Finis !

Trois lectures ! Désolé du mal qu'on te donne. :p

Dès l'introduction, on a le droit à "En Ruby, tout est objet". Le sens de cette phrase coule de source pour quelqu'un habitué à la notion d'objet. Un débutant sera alors, quant à lui, largué dès l'introduction. Je pense qu'en premier lieu, il est inutile d'aborder la notion d'objet. De toute façon, le tutoriel n'y fait jamais allusion (du moins, pour l'instant :D).

Il faudra donc soit supprimer l'allusion, soit la préciser.

Nombres, arithmétique, variables et chaines de caractère

  • On pourrait ajouter l'opérateur ** (puissance) à la liste des opérateurs.

On en parle. Peut-être faudrait-il le rajouter dans le tableau ?

  • On pourrait parler des variables globales ($globale), ou encore globales et constantes ($GLOBALE)

Dès le début c'est pas trop utile, non ?

  • Tant qu'à parler des string, je suis un fervent défenseur de l'interpolation des chaines. ON ne fait pas "Hello " + mot, mais "Hello #{mot}". En plus, c'est souvent plus efficace.

Ok, à rajouter.

  • Une chaine s'écrit avec " ou '.

On en parle dans la version en bêta.

  • Ne pas oublier la méthode to_sym dans la partie conversion de variable

Il faudra en parler après avoir parlé des symboles.

Les conditions

Il faudrait préciser que tout a pour valeur de vérité vrai, SAUF false et nil.

Ce sera rajouté.

Les fonctions

Je n'ai jamais vu le terme "procédure" dans le langage Ruby. Une méthode renvoie TOUJOURS quelque chose. nil n'est rien d'autre que le NULL du C, le nullptr du C++ ou le null du Java. Et pourtant, dans ces mêmes langages, lorsqu'une fonction renvoie une valeur nulle, son type de retour n'est pas void. Autrement dit, nil n'est pas rien !

C'est vrai que c'est maladroit de dire que rien n'est renvoyé. Ce sera changé.

D'ailleurs, en parlant de nil, il n'a encore jamais été abordé dans le tutoriel, il doit être explicité avant.

Si on doit le parler, c'est dans le chapitre sur les variables.

Il faudrait préciser que return est facultatif

On le rajoutera.

De même, il faudrait préciser que les parenthèses lors des appels de fonction sont facultatives.

C'est précisé dans la version en bêta.

Autres remarques

Les commentaires sont beaucoup utilisés dans les codes d'exemple, mais a aucun moment il n'est expliqué de quoi il s'agit.

On parle des commentaires ici.

Bon, je critique, je critique, mais je tiens tout de même à vous féliciter pour ce travail. J'ai déjà mis un temps fou à écrire ce commentaire, alors je n'imagine pas le temps que vous avez du mettre pour rédiger cette introduction.

Merci. :)

Continuez comme ça ! Si jamais vous avez besoin d'un coup de main, faites le moi savoir ;)

GaaH

Ok, on s'en rappellera.

EDIT : et il faut aussi qu'on pense à donner les noms possibles pour une variable (enfin les noms impossible). Il faudra alors rajouter un tableau des mots-clés pour expliquer pour montrer les noms que l'on ne peut pas choisir.

+0 -0

Les modifications :

Introduction

  • modification de l'extrait Qu'est-ce que Ruby suite aux conseils de GaaH
  • l'extrait sur les opérations a été déplacé du chapitre deux à la fin du chapitre un dans l'extrait Prise en main
  • ajout d'un extrait Exercices pour que l'utilisateur s'habitue aux flottants et fasse ses premières erreurs.

Variables et chaines de caractères

  • changement du titre du chapitre :-°
  • ajout d'une sous-partie sur nil dans l'extrait Variables
  • ajout de l'interpolation de chaines

Bientôt ajout d'un extrait sur les noms de variables : mots réservés et convention snake_case

Les Conditions

Bientôt ajout de l'idée de GaaH (tout est vrai sauf nil et false dans le premier extrait

Les boucles

  • correction de fautes mineures

Les tableaux

  • Correction de fautes mineures

Les fonctions

  • ajout de détails sur la valeur de retour (en particulier sur nil mais c'est compliqué d'être clair donc ce n'est pas encore au point)
  • Corrections mineures

Bientôt ajout des corrections des deux exercices

Tout le tutoriel

  • Changement des concaténations en interpolations
  • Mise en page des codes avec irb

Voilà.

PS : Je suis en train de peaufiner la première partie. Pendant ce temps, Lalla travaille sur la deuxième partie. J'espère que la première sera bientôt assez mature pour qu'on puisse la renvoyer en validation et que les membres aient une première partie d'une très grande qualité. Alors, merci à tous pour vos retours. C'est grâce à vous si on peut le faire et si le tutoriel s'améliore. :)

EDIT : je viens de voir que la modification de l'extrait Qu'est-ce que Ruby n'est pas dans la bêta (j'ai envoyé en bêta avant de valider la modification je pense). Elle sera donc dans la prochaine bêta.

+0 -0

Comment comptez vous aborder la notion d'objet en Ruby ? En ce qui me concerne, je trouve la programmation objet en Ruby un peu "bâtarde" (tout comme en Python d'ailleurs), contrairement aux langages statiquement typés comme C++, Java ou C#.

Par exemple, en Ruby on perd complètement l’intérêt du polymorphisme, a cause du duck typing. Ce qui compte n'est plus la classe/type de base, mais plutôt les méthodes disponibles au sein de la classe (ça revient grosso modo a ce qu'on recherche avec le polymorphisme, mais la méthode est bien différente).

Du coup, l'héritage en Ruby n'est plus, du moins à mon sens, une notion objet fondamentale. On préfèrera faire de la composition plutôt que d'avoir une hiérarchie de classe complexe. Un bon exemple serait le module Enumerable. Contrairement a un langage comme C# ou les conteneurs héritent de l'interface ICollection (ou IEnumerable), en Ruby, on colle des fonctions en plus, et deux types conteneurs n'ont aucun rapport entre eux (Si ce n'est la classe de base Object).

De par sa nature dynamique, on peut modifier les classes déjà définies

1
2
3
4
5
class String
  def palyndrome?
    self == self.reverse
  end
end

Et pouf, on ajoute la méthode palyndrome a tout objet de type String.

On peut même carrément ajouter des méthodes pendant l’exécution à un objet donné. Je parle ici des singleton class

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
mon_objet = "objet"
puts mon_objet.class # Affiche string

class << mon_objet
  def nouvelle_fonction
    puts "nouvelle_fonction"
  end
end

mon_objet.nouvelle_fonction

# Ici, mon_objet est LE SEUL objet possédant la méthode nouvelle_fonction

C'est une notion assez complexe que je n'ai pas bien saisie, lisez Programming Ruby (ou the pickaxe book) pour plus d'info.

La ou je veux en venir, c'est au traitement d'un appel de méthode en Ruby. Puisque chaque instance est potentiellement différente, on ne peut pas, comme en C, juste exécuter une méthode à une adresse définie. L'interpréteur doit chercher dans le type actuelle de l'objet si la méthode appelé existe. Si non, l'interpréteur remonte la hiérarchie de classe. Si la méthode n'existe nul part, c'est la méthode Object#method_missing qui est appelée.

Bref, tout ça pour dire que l'objet en Ruby, c'est bien la merde, et qu'il y a des millions de choses à dire. J'espère ne pas avoir dit d'âneries, je n'ai pas d'interpréteur sous la main pour vérifier mes dires :S

PS : Désolé, je crois que j'ai un peu divergé par rapport à ce que je voulais dire initialement ^^

+1 -0

J'ai testé ton code. Il marche bien. Ces codes sont quand même des choses qu'on ne fait pas tous les jours, et si on doit l'aborder ce sera dans plusieurs chapitres. Ce n'est pas essentiel pour aborder l'objet.

Je ne sais pas encore comment nous allons aborder l'objet (Lalla s'en occuper pour le moment). Mais je sais qu'il faudra d'abord donner de bonnes bases en objet sans trop s'occuper des détails, donc traiter des classes en général, des différents types de variables et de méthodes, donner des exemples… C'est déjà un bon début qu'il faut déjà comprendre avant de s'attaquer aux subtilités du langage.

PS : Désolé, je crois que j'ai un peu divergé par rapport à ce que je voulais dire initialement ^^

Ben moi, ça m'a beaucoup intéressé, alors si tu peux encore diverger. :-°

+0 -0

Tout ce qu'a dit GaaH est vrai en ce qui concerne la puissance du duck typing. Cependant, ce n'est pas une faiblesse de l'objet en Ruby mais une force (qu'il hérite directement du Smalltalk) qui lui vient de sa capacité d'introspection qu'on ne retrouve dans un langage comme le C++. C'est effectivement un poil complexe, mais je compte bien aborder ces concepts dans le cours (et comme on dit, chaque chose en son temps).

Mais de manière générale, je pense d'abord attaquer l'objet de manière "académique" (avec les notions d'objet, classe, méthode, héritage) puis une fois que les bases "universelles" de l'objets sont acquises, on pourra attaquer des idiomes plus Rubyesques (comme notamment les méta-classes et la relation entre composition et héritage).

Je te fais quelques petits retours, je te laisse juger de leur pertinence.

Dans ton chapitre I, lorsque que tu expliques ce qu'est Ruby, je pense qu'utiliser une définition Wikipédia est une mauvaise idée. Vous feriez peut-être mieux de tout expliquer avec vos mots. Quelqu'un qui débute y verra certainement plus de confort et une facilité de compréhension accrue.

Ensuite, un autre inconvénient que présente l’utilisation de la définition de Wikipédia, vous devez parler des objets. Et si la personne qui vous lit est vraiment une débutante, elle se perd facilement. Ce serait dommage de perdre/démotiver des lecteurs dès le premier chapitre :) C'est une notion assez complexe à maitriser, vous pouvez juste y faire allusion.

Dans la partie installation,

Il va de soit

Ensuite, dans la conclusion :

Vous avez maintenant tous les outils pour vous lancer dans la programmation Ruby.

Tous les outils nécessaires ?

Dans le chapitre II, dans la partie conversion des variables. Vous y parlez des méthodes. Ma remarque est un peu la même que pour la notion d'objet. Pou un lecteur qui ne sait pas du tout ce que représentent les méthodes, il y a des risques qu'ils ne comprennent rien du tout.

Enfin, dans le chapitre III, dans l'intro, vous dîtes créer des boucles ? Je dirais plutôt mettre en place des branchements conditionnels, ou un truc du genre. Enfin, je chipote :)

Encore, une fois, je vous laisser juger de la pertinence de mes remarques. J'espère vous avoir aidée, afin de pouvoir proposer un tutoriel de la meilleure qualité possible !

Je te fais quelques petits retours, je te laisse juger de leur pertinence.

Merci de ton retour. :)

Dans ton chapitre I, lorsque que tu expliques ce qu'est Ruby, je pense qu'utiliser une définition Wikipédia est une mauvaise idée. Vous feriez peut-être mieux de tout expliquer avec vos mots. Quelqu'un qui débute y verra certainement plus de confort et une facilité de compréhension accrue.

Ensuite, un autre inconvénient que présente l’utilisation de la définition de Wikipédia, vous devez parler des objets. Et si la personne qui vous lit est vraiment une débutante, elle se perd facilement. Ce serait dommage de perdre/démotiver des lecteurs dès le premier chapitre :) C'est une notion assez complexe à maitriser, vous pouvez juste y faire allusion.

C'est vrai. Comme je l'ai dit précédemment, l'extrait Qu'est-ce que Ruby a été modifié mais ce n'est pas encore dans la bêta. Nous allons tenir compte de ta remarque et modifier le passage au mieux.

Dans la partie installation,

Il va de soit

Je ne comprends pas, il n'y a pas de t.

Ensuite, dans la conclusion :

Vous avez maintenant tous les outils pour vous lancer dans la programmation Ruby.

Tous les outils nécessaires ?

C'est vrai que c'est mieux avec nécessaires.

Dans le chapitre II, dans la partie conversion des variables. Vous y parlez des méthodes. Ma remarque est un peu la même que pour la notion d'objet. Pou un lecteur qui ne sait pas du tout ce que représentent les méthodes, il y a des risques qu'ils ne comprennent rien du tout.

C'est pour ça qu'on n'approfondit pas. À ce stade, il doit juste savoir qu'il faut mettre un point et écrire le nom de la méthode.

Enfin, dans le chapitre III, dans l'intro, vous dîtes créer des boucles ? Je dirais plutôt mettre en place des branchements conditionnels, ou un truc du genre. Enfin, je chipote :)

Ce sera modifié.

Encore, une fois, je vous laisser juger de la pertinence de mes remarques. J'espère vous avoir aidée, afin de pouvoir proposer un tutoriel de la meilleure qualité possible !

Emeric

Merci pour ton retour. :)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte