Discuss Scratch
- Discussion Forums
- » 日本語
- » Scratch への提案
- ioqj
-
Scratcher
500+ posts
Scratch への提案
それは((0) と (0) のうち [ 大きい v] 方)のようなブロックがあるといいなと思いました
<[] < []>で代用できるのではないでしょうか。
- kiccha4636
-
Scratcher
16 posts
Scratch への提案
#6320
例えば、
例えば、
もし <(x座標) < [30]> ならといった仕組みを
x座標を (30) にする
end
x座標を ((x座標) と (30) のうち [ 大きい v]方) にするのようにできる場面がたくさんあります
- tsmcoder
-
Scratcher
500+ posts
Scratch への提案
汎用性がないと思います。不等号の真偽ブロックがあれば十分です。
(ちなみに、こんなこともできます。x座標と30が等しい時は成り立ちませんが)
(ちなみに、こんなこともできます。x座標と30が等しい時は成り立ちませんが)
x座標を (((x座標) * <(x座標) > [30]>) + ((30) * <[30] > (x座標)>)) にする // Trueだと1、Falseだと0が返される仕様を利用
Last edited by tsmcoder (Aug. 7, 2024 13:32:58)
- kiccha4636
-
Scratcher
16 posts
Scratch への提案
これは省略のみを目的としているブロックではなく、
汎用性は他のブロックと比較しても十分にあると思います
例えば変数や座標などに上限及び下限を設けるといった使い方があります
他にも多くの場面で可読性を高めることもできます
汎用性は他のブロックと比較しても十分にあると思います
例えば変数や座標などに上限及び下限を設けるといった使い方があります
他にも多くの場面で可読性を高めることもできます
Last edited by kiccha4636 (Aug. 7, 2024 13:58:14)
- abee
-
Scratcher
1000+ posts
Scratch への提案
そのような関数は多くの言語で min として用意されています。
Scratchの設計者がそれを知らなかったとは考えづらく、意図的に入れていないと解釈した方が自然だと思います。
また、min のアルゴリズムを考えることは、初心者向けの課題としてよく使われるものであり、Scratchの目的から見て、自分で考えて定義することを促していると捉えることもできると思います。
Scratchの設計者がそれを知らなかったとは考えづらく、意図的に入れていないと解釈した方が自然だと思います。
また、min のアルゴリズムを考えることは、初心者向けの課題としてよく使われるものであり、Scratchの目的から見て、自分で考えて定義することを促していると捉えることもできると思います。
- kiccha4636
-
Scratcher
16 posts
Scratch への提案
あなたはScratchの設計者なのですか?
初心者向けの課題として意図的に入れていない可能性があることは
わかりました。同時にそれはあくまで推測だとも感じました。
また、どういった根拠からそう考えるのが自然になりますか?
初心者向けの課題として意図的に入れていない可能性があることは
わかりました。同時にそれはあくまで推測だとも感じました。
また、どういった根拠からそう考えるのが自然になりますか?
Last edited by kiccha4636 (Aug. 7, 2024 14:27:12)
- abee
-
Scratcher
1000+ posts
Scratch への提案
私は、Scratchの開発初期から学会などを通じて開発者の方と交流がありました。Scratchに関する論文もいくつか読んでいます。そのようなこともあって、日本語の翻訳を担当することになりました。
推測の根拠は既に示しています。
推測の根拠は既に示しています。
Last edited by abee (Aug. 7, 2024 14:34:52)
- kiccha4636
-
Scratcher
16 posts
Scratch への提案
根拠というのは この関数が多くの言語で用意されている ということですか?
それともあなたが日本語の翻訳を担当しているから?
開発者と話したことがあるからですか?
設計者が意図的に入れていない根拠としては足りないと思います
それともあなたが日本語の翻訳を担当しているから?
開発者と話したことがあるからですか?
設計者が意図的に入れていない根拠としては足りないと思います
- kiccha4636
-
Scratcher
16 posts
Scratch への提案
#6328 にあるこの関数が多くの言語で用意されていることは
根拠として不十分です
#3983 にある
汎用的かはすでに示しています
使用頻度で見ても使用できる場面は十分にあります
また、
ブロックが増えることにより初心者が混乱しないか?
可能な限りシンプルにして下さい。
についても2つの値を比べて片方を返すだけなので
初心者が混乱するとは考えにくいですし、十分シンプルだと思います。
根拠として不十分です
#3983 にある
汎用的かはすでに示しています
使用頻度で見ても使用できる場面は十分にあります
また、
ブロックが増えることにより初心者が混乱しないか?
可能な限りシンプルにして下さい。
についても2つの値を比べて片方を返すだけなので
初心者が混乱するとは考えにくいですし、十分シンプルだと思います。
- inoking
-
Scratcher
1000+ posts
Scratch への提案
(国語の問題)
「この関数が多くの言語で用意されていること」が根拠ではありません。
#3982(後から削除された投稿により番号がずれている)では以下の下線部に該当します。
ブロックが増えることにより:Scratch チームはブロックが増えることに対しかなり慎重です。
ブロックが増えるということはシンプルさを阻害します。
「この関数が多くの言語で用意されていること」が根拠ではありません。
そのような関数は多くの言語で min として用意されています。
Scratchの設計者がそれを知らなかったとは考えづらく、意図的に入れていないと解釈した方が自然だと思います。
#3982(後から削除された投稿により番号がずれている)では以下の下線部に該当します。
ブロックを追加するには色々なことを考慮しなければなりません。例えば、使用頻度:他のブロックに比べると使用法が特化しすぎており、低いと思います。
・汎用的か?
・使用頻度は高いか?
特に「低い床」の観点から
・ブロックが増えることにより初心者が混乱しないか?
「可能な限りシンプルにして下さい。— 多分、いっそうシンプルかもしれません。」の観点から
・創造性を阻害しないか?
などです。
ブロックが増えることにより:Scratch チームはブロックが増えることに対しかなり慎重です。
ブロックが増えるということはシンプルさを阻害します。
Last edited by inoking (Aug. 7, 2024 23:42:25)
- kiccha4636
-
Scratcher
16 posts
Scratch への提案
そのような関数は多くの言語で min として用意されています。この部分は主張の理由であり、根拠とは言いません。
Scratchの設計者がそれを知らなかったとは考えづらく、意図的に入れていないと解釈した方が自然だと思います。
2つの値を比べて片方を返すブロックは
何かに特化したブロックではありませんし、
他の演算ブロックと比較しても使用できる場面は十分あると考えています。
Last edited by kiccha4636 (Aug. 8, 2024 00:17:14)
- TNTSuperMan
-
Scratcher
100+ posts
Scratch への提案
ブロックでこれがあった方がいいと思ってても、Scratch側としてはブロックの変更はしたがらないので
その動作を再現できるような方法があれば、ここには投稿しないように#1を修正した方がいいと思います。
その動作を再現できるような方法があれば、ここには投稿しないように#1を修正した方がいいと思います。
- tsmcoder
-
Scratcher
500+ posts
Scratch への提案
ブロックでこれがあった方がいいと思ってても、Scratch側としてはブロックの変更はしたがらないので「代用できる」というのはその提案に反対する立派な理由のひとつですが、「代用できるから却下」というのは違います。
その動作を再現できるような方法があれば、ここには投稿しないように#1を修正した方がいいと思います。
既存のブロックにも機能が重複している例はあります。
こちらの投稿より:
ブロックを追加するには色々なことを考慮しなければなりません。例えば、
・汎用的か?
・使用頻度は高いか?
特に「低い床」の観点から
・ブロックが増えることにより初心者が混乱しないか?
「可能な限りシンプルにして下さい。— 多分、いっそうシンプルかもしれません。」の観点から
・創造性を阻害しないか?
などです。
既存のブロックで機能が重複しているものは
上記のような観点で考えたとき、いずれもクリアしているはずです。
逆に、「代用できる」で済まされる提案は、大半が上記のような観点をクリアしていないはずです。
※もちろん例外もあるでしょうし線引きが難しいところもあります。
- Kiri-Kiri-
-
Scratcher
100+ posts
Scratch への提案
#6319
スクラッチチームの方の投稿では、「ブロックをなるべく少なくすること」がゴールだと言っています。
#6322でご自身が言っているように、
提案されたブロックと同じ意味のプログラムが、簡単に出来るものであれば追加するメリットはないですし、「ブロックをなるべく少なくすること」に反します。
スクラッチチームの方の投稿では、「ブロックをなるべく少なくすること」がゴールだと言っています。
#6322でご自身が言っているように、
もし <(x座標) > [n]> ならで十分代用できます。
x座標を (n) にする
end
提案されたブロックと同じ意味のプログラムが、簡単に出来るものであれば追加するメリットはないですし、「ブロックをなるべく少なくすること」に反します。
Last edited by Kiri-Kiri- (Aug. 8, 2024 02:09:48)