Mega-Celebi wrote:

Moi j'aimerais proposer des quelques éléments de programmation que l'on retrouve dans tous les langages classiques et qui me manquent un peu quand j'arrive sur Scratch.

Je m'excuse à l'avance si je propose des trucs qui ont déjà étés proposés, j'avoue ne pas avoir lu les 83 pages ^^'

Pour moi le plus gros manque c'est l'instruction return que l'on retrouve partout (java,c,python… vraiment partout). Ca permet de faire en sorte qu'un bloc personnalisé renvoie le résultat d'un calcul, et que ce bloc personnalisé soit utilisable comme un bloc rond vous savez, tout ce qu'on met dans des cases qui attendent des valeurs (comme

dire []

par exemple). Je pense qu'un exemple sera plus utile :

définir fonctionQuiAdditionneDeuxNombres(a)(b)
return ((a) + (b))

Ca s'utiliserait comme suit :

mettre [ma variable] à ([fonctionQuiAdditionneDeuxNombres]  (1)(17)

Après cette opération la variable “ma variable” aura pour valeur 18.

Bien évidemment là le calcul est tellement simple que mon exemple en devient inutile. Voici un exemple peut-être un peu plus concret (et un peu plus difficile) : la fonction factorielle. (Exemple souvent cité dans les cours d'informatique)
J'explique rapidement ce que c'est, la factorielle d'un entier naturel (donc positif ou nul) n est le produit des nombres entiers strictement positifs inférieurs ou égaux à n. (Ca c'était la méchante définition mathématique, voilà deux exemples pour comprendre plus facilement) :
Factorielle(5) = 5*4*3*2*1
Factorielle(9) = 9*8*7*6*5*4*3*2*1

Donc une telle fonction s'implémenterait facilement avec une instruction return :

définir factorielle(x)
si <(x) = [0]> alors
return (1)
sinon
return ([factorielle]((x) - (1)) * (x))
end

Une telle fonction est vraiment, vraiment beaucoup plus compliquée à programmer en Scratch sans le return. L'instruction return est vraiment fondamentale dans tous les langages, c'est une des choses que l'on apprend en tout tout tout premier en programmation, et je trouve que ça manque vraiment à Scratch.

Toutes mes propositions suivantes sont beaucoup moins importantes à mes yeux.

Un petit détail pour commencer, un opérateur

<[] ≥ []> 

(Supérieur ou égal) serait plus pratique qu'un

<non <[] < []>>

ou qu'un

<<[] = []> ou <[] > []>>

Il en est de même pour le ≤. (Inférieur ou égal)

Troisièmement, j'aimerais voir des variables booléennes en Scratch. Les variables booléennes sont des variables ne pouvant avoir que deux valeurs, Vrai ou Faux. Les instruction aux bords triangulaires comme

<touche [ v] pressée?>

ou

<souris pressée?>

en sont. (Soit la souris est pressée, soit elle ne l'est pas, donc Vrai, ou Faux). J'aimerais pouvoir créer mes propres variables vraies ou fausses comme ça :

mettre [maVariableBooléenne] à <Vrai>

On pourrait donc utiliser des variables seules dans les instructions de contrôle :

si <maVariableBooléenne> alors

end

ou

répéter jusqu’à <maVariableBooléenne>

end

Mais on peut faire l'équivalent en Scratch en choisissant deux valeurs pour Vrai et Faux, par exemple 1 et 0, et faire comme suit :

mettre [maVariablePasVraimentBooléenne] à [1]

// On a choisi 1 = Vrai

si <(maVariablePasVraimentBooléenne) = [1]> alors

end

//Equivalent à si <maVariableBooléenne>.

Mais voilà, là c'est différent du cas du return, ce n'est pas vraiment nécessaire pour l'instant. (Alors que return si, c'est nécessaire !)


Dernier point et après c'est fini, promis ^^

J'aimerais bien pouvoir faire des blocs personnalisés prenant en paramètre une liste (impossible pour l'instant !). On peut passer en paramètres des entiers, des chaînes de caractères et des booléens (Vrai ou Faux, comme dit plus haut), mais pas des listes, ce serait pourtant pratique !!

Voilà, mon pavé est terminé. Merci d'avoir lu jusqu'au bout
Hésitez pas à me demander des précisions ou explications sur mes propositions.

-Mega-Celebi

Mega-Celebi wrote:

Moi j'aimerais proposer des quelques éléments de programmation que l'on retrouve dans tous les langages classiques et qui me manquent un peu quand j'arrive sur Scratch.

Je m'excuse à l'avance si je propose des trucs qui ont déjà étés proposés, j'avoue ne pas avoir lu les 83 pages ^^'

Pour moi le plus gros manque c'est l'instruction return que l'on retrouve partout (java,c,python… vraiment partout). Ca permet de faire en sorte qu'un bloc personnalisé renvoie le résultat d'un calcul, et que ce bloc personnalisé soit utilisable comme un bloc rond vous savez, tout ce qu'on met dans des cases qui attendent des valeurs (comme

dire []

par exemple). Je pense qu'un exemple sera plus utile :

définir fonctionQuiAdditionneDeuxNombres(a)(b)
return ((a) + (b))

Ca s'utiliserait comme suit :

mettre [ma variable] à ([fonctionQuiAdditionneDeuxNombres]  (1)(17)

Après cette opération la variable “ma variable” aura pour valeur 18.

Bien évidemment là le calcul est tellement simple que mon exemple en devient inutile. Voici un exemple peut-être un peu plus concret (et un peu plus difficile) : la fonction factorielle. (Exemple souvent cité dans les cours d'informatique)
J'explique rapidement ce que c'est, la factorielle d'un entier naturel (donc positif ou nul) n est le produit des nombres entiers strictement positifs inférieurs ou égaux à n. (Ca c'était la méchante définition mathématique, voilà deux exemples pour comprendre plus facilement) :
Factorielle(5) = 5*4*3*2*1
Factorielle(9) = 9*8*7*6*5*4*3*2*1

Donc une telle fonction s'implémenterait facilement avec une instruction return :

définir factorielle(x)
si <(x) = [0]> alors
return (1)
sinon
return ([factorielle]((x) - (1)) * (x))
end

Une telle fonction est vraiment, vraiment beaucoup plus compliquée à programmer en Scratch sans le return. L'instruction return est vraiment fondamentale dans tous les langages, c'est une des choses que l'on apprend en tout tout tout premier en programmation, et je trouve que ça manque vraiment à Scratch.

Toutes mes propositions suivantes sont beaucoup moins importantes à mes yeux.

Un petit détail pour commencer, un opérateur

<[] ≥ []> 

(Supérieur ou égal) serait plus pratique qu'un

<non <[] < []>>

ou qu'un

<<[] = []> ou <[] > []>>

Il en est de même pour le ≤. (Inférieur ou égal)

Troisièmement, j'aimerais voir des variables booléennes en Scratch. Les variables booléennes sont des variables ne pouvant avoir que deux valeurs, Vrai ou Faux. Les instruction aux bords triangulaires comme

<touche [ v] pressée?>

ou

<souris pressée?>

en sont. (Soit la souris est pressée, soit elle ne l'est pas, donc Vrai, ou Faux). J'aimerais pouvoir créer mes propres variables vraies ou fausses comme ça :

mettre [maVariableBooléenne] à <Vrai>

On pourrait donc utiliser des variables seules dans les instructions de contrôle :

si <maVariableBooléenne> alors

end

ou

répéter jusqu’à <maVariableBooléenne>

end

Mais on peut faire l'équivalent en Scratch en choisissant deux valeurs pour Vrai et Faux, par exemple 1 et 0, et faire comme suit :

mettre [maVariablePasVraimentBooléenne] à [1]

// On a choisi 1 = Vrai

si <(maVariablePasVraimentBooléenne) = [1]> alors

end

//Equivalent à si <maVariableBooléenne>.

Mais voilà, là c'est différent du cas du return, ce n'est pas vraiment nécessaire pour l'instant. (Alors que return si, c'est nécessaire !)


Dernier point et après c'est fini, promis ^^

J'aimerais bien pouvoir faire des blocs personnalisés prenant en paramètre une liste (impossible pour l'instant !). On peut passer en paramètres des entiers, des chaînes de caractères et des booléens (Vrai ou Faux, comme dit plus haut), mais pas des listes, ce serait pourtant pratique !!

Voilà, mon pavé est terminé. Merci d'avoir lu jusqu'au bout
Hésitez pas à me demander des précisions ou explications sur mes propositions.

-Mega-Celebi

Mega-Celebi wrote:

Tu peux pas juste dire “ce sera jamais accepté” x) faudrait développer un peu

-CocaBleuAAA- wrote:

Mega-Celebi wrote:

Tu peux pas juste dire “ce sera jamais accepté” x) faudrait développer un peu

Pourtant ça suffit très bien, ça paraissait logique qu'elle soit rejetée.

Leo42460 wrote:

Tout cela me semble une bonne idée, mais il y a des contournements beaucoup plus simple à comprendre et de plus, c’est pour les enfants qui ne savent pas ce que c’est la programmation exactement : en gros, Scratch est fait pour apprendre la programmation simplement et de manière compréhensible à tous. Sans vouloir te vexer.

Vu que tu t’y connais en programmation (on dirait), tu pourrais m’aider avec la création d’expérience sur Roblox (réponds-moi sur mon profil Scratch)

Leo42460 wrote:

Comme vous l’avez remarqué, les studios sont passés en 3.0 : une bonne évolution pour le design, mais je vais faire un coup de gueule sur le système d’invitation : pourquoi doit-on taper le nom d’utilisateur pour inviter? C’est quoi ça ? Qui a proposé cette idée de taper les noms d’utilisateur uniquement pour inviter ? Pourquoi la ST a-t-elle accepté si il y a quelqu’un qui a proposé cette idée ? C’est bien de faire en sorte d’éviter le spam, mais là, c’est trop extrémiste ! Mathématiquement, il va falloir jusqu’à 100 fois plus de temps pour inviter. Ma suggestion est la suivante : remettre le système d’invitation de la 2.0.

(Là, j’ai tout dit et j’en ai moins dit quand j’ai envoyé un commentaire à @achouse)

Plus que le gestionnaire de projets et la page de profil à passer en 3.0…

Leo42460 wrote:

Comme vous l’avez remarqué, les studios sont passés en 3.0 : une bonne évolution pour le design, mais je vais faire un coup de gueule sur le système d’invitation : pourquoi doit-on taper le nom d’utilisateur pour inviter? C’est quoi ça ? Qui a proposé cette idée de taper les noms d’utilisateur uniquement pour inviter ? Pourquoi la ST a-t-elle accepté si il y a quelqu’un qui a proposé cette idée ? C’est bien de faire en sorte d’éviter le spam, mais là, c’est trop extrémiste ! Mathématiquement, il va falloir jusqu’à 100 fois plus de temps pour inviter. Ma suggestion est la suivante : remettre le système d’invitation de la 2.0.

(Là, j’ai tout dit et j’en ai moins dit quand j’ai envoyé un commentaire à @achouse)

Plus que le gestionnaire de projets et la page de profil à passer en 3.0…

Arqwa wrote:

Leo42460 wrote:

Comme vous l’avez remarqué, les studios sont passés en 3.0 : une bonne évolution pour le design, mais je vais faire un coup de gueule sur le système d’invitation : pourquoi doit-on taper le nom d’utilisateur pour inviter? C’est quoi ça ? Qui a proposé cette idée de taper les noms d’utilisateur uniquement pour inviter ? Pourquoi la ST a-t-elle accepté si il y a quelqu’un qui a proposé cette idée ? C’est bien de faire en sorte d’éviter le spam, mais là, c’est trop extrémiste ! Mathématiquement, il va falloir jusqu’à 100 fois plus de temps pour inviter. Ma suggestion est la suivante : remettre le système d’invitation de la 2.0.

(Là, j’ai tout dit et j’en ai moins dit quand j’ai envoyé un commentaire à @achouse)

Plus que le gestionnaire de projets et la page de profil à passer en 3.0…

Moi je trouve que ce changement n'est pas si mal pensé, cela évite beaucoup de spam qui est fait en invitant tous les followers et c'est bien sûr pour freiner la tendance de “invite everyone” qui n'est pas très *créative* et qui peut entraîner des dérives dans certains studios. Maintenant, il va falloir oui, taper manuellement le nom d'utilisateur, au moins, nous allons avoir uniquement le courage d'inviter les personnes intéressées ou qui pourraient l'être.

lA-maker wrote:

Arqwa wrote:

Leo42460 wrote:

Comme vous l’avez remarqué, les studios sont passés en 3.0 : une bonne évolution pour le design, mais je vais faire un coup de gueule sur le système d’invitation : pourquoi doit-on taper le nom d’utilisateur pour inviter? C’est quoi ça ? Qui a proposé cette idée de taper les noms d’utilisateur uniquement pour inviter ? Pourquoi la ST a-t-elle accepté si il y a quelqu’un qui a proposé cette idée ? C’est bien de faire en sorte d’éviter le spam, mais là, c’est trop extrémiste ! Mathématiquement, il va falloir jusqu’à 100 fois plus de temps pour inviter. Ma suggestion est la suivante : remettre le système d’invitation de la 2.0.

(Là, j’ai tout dit et j’en ai moins dit quand j’ai envoyé un commentaire à @achouse)

Plus que le gestionnaire de projets et la page de profil à passer en 3.0…

Moi je trouve que ce changement n'est pas si mal pensé, cela évite beaucoup de spam qui est fait en invitant tous les followers et c'est bien sûr pour freiner la tendance de “invite everyone” qui n'est pas très *créative* et qui peut entraîner des dérives dans certains studios. Maintenant, il va falloir oui, taper manuellement le nom d'utilisateur, au moins, nous allons avoir uniquement le courage d'inviter les personnes intéressées ou qui pourraient l'être.

Et ç ava faire disparaitre les studios de pub

Loquax wrote:

Bonjour à tous,
Suite à une longue discussion avec Paddle2See, ce forum est né !

Vous pouvez y poster vos idées pour le futur de Scratch, car pour toute chose, il est important d’avoir un retour de ses utilisateurs !

Les règles sur ce topic, sont les mêmes que pour le reste du forum.

Pour une raison de praticité pour les développeurs de la Scratch Team, les suggestions seront rapatriées sur le topic général.
Je recherche actuellement un Scratcher pouvant faire l’échange entre ces deux topic. Il doit donc avoir un bon niveau d’anglais et de français.

Merci d’avance pour vos idées !


Avant de proposer une suggestion, veuillez vérifier qu'elle n'a pas déjà été rejetée par l'équipe scratch. (une liste des suggestions rejetées est disponible ici)

Arqwa wrote:

Leo42460 wrote:

Comme vous l’avez remarqué, les studios sont passés en 3.0 : une bonne évolution pour le design, mais je vais faire un coup de gueule sur le système d’invitation : pourquoi doit-on taper le nom d’utilisateur pour inviter? C’est quoi ça ? Qui a proposé cette idée de taper les noms d’utilisateur uniquement pour inviter ? Pourquoi la ST a-t-elle accepté si il y a quelqu’un qui a proposé cette idée ? C’est bien de faire en sorte d’éviter le spam, mais là, c’est trop extrémiste ! Mathématiquement, il va falloir jusqu’à 100 fois plus de temps pour inviter. Ma suggestion est la suivante : remettre le système d’invitation de la 2.0.

(Là, j’ai tout dit et j’en ai moins dit quand j’ai envoyé un commentaire à @achouse)

Plus que le gestionnaire de projets et la page de profil à passer en 3.0…

Moi je trouve que ce changement n'est pas si mal pensé, cela évite beaucoup de spam qui est fait en invitant tous les followers et c'est bien sûr pour freiner la tendance de “invite everyone” qui n'est pas très *créative* et qui peut entraîner des dérives dans certains studios. Maintenant, il va falloir oui, taper manuellement le nom d'utilisateur, au moins, nous allons avoir uniquement le courage d'inviter les personnes intéressées ou qui pourraient l'être.

timeo4422 wrote:

se serais bien pour les débutant un acompagnateur (pas une vidéo) il te propose des projets tu clique sur le projet que tu veut crée (projet siple : pong ect ….) il te montre quelle blok prendre et ou les disposer ect

-CocaBleuAAA- wrote:

timeo4422 wrote:

se serais bien pour les débutant un acompagnateur (pas une vidéo) il te propose des projets tu clique sur le projet que tu veut crée (projet siple : pong ect ….) il te montre quelle bloc prendre et ou les disposer ect

https://scratch.mit.edu/projects/editor/?tutorial=all

bidulule wrote:

Je sais pas si ça déjà été demandé ou pas mais

C'est vraiment trop demander de pouvoir faire apparaître un script sorti du sac à dos à l'endroit où on l'a déposé plutôt qu'à UN VIEUX ENDROIT RANDOM PERDU AU MILIEU DES AUTRES SCRIPTS ?

Jte jures scratch joue avec mon mental des fois x)

bidulule wrote:

Je sais pas si ça déjà été demandé ou pas mais

C'est vraiment trop demander de pouvoir faire apparaître un script sorti du sac à dos à l'endroit où on l'a déposé plutôt qu'à UN VIEUX ENDROIT RANDOM PERDU AU MILIEU DES AUTRES SCRIPTS ?

Jte jures scratch joue avec mon mental des fois x)