アカウント名:
パスワード:
コンパクトなプログラムを書くだけならそういった仕組みは不要ですね。"Hello World" と表示するだけのプログラムにとっては、#include とか main() とかはおまじないでしかありません。実際に入門書でも最初はおまじない扱いです。これらの仕組みは、プログラマーの自由度を縛ることにより品質や生産性を高める仕組みです。つまり、プログラマーにとっては、その必要性が理解できない限りは「余計なお世話」でしかありません。逆に言うと、一度そういったものが必要な状況に陥って苦労することでこれらの仕組みの必要性を肌で理解できるようになるでしょう。したがって、入門者には、そういったおまじないを取り払った環境で、プログラムが動くという楽しさを味わってもらい、いろいろやっているうちにプログラムが肥大化していくでしょうから、そのタイミングでこれらの仕組みを提示出来れば良いのではないかと思われます。
プログラマの技量に合わせてこれらの機能が有効にしていけるような仕組があればよいですね。最初は型すら定義出来ていなかったのが、習熟にともなって機能の封印を解除していくと、オブジェクト指向が導入されたり、ポインタが導入されたり、最終的にはガベージコレクタが無効にできたりすると、いつのまにやらC++プログラマーですね。
プログラムの経験値が上がると使える機能が増えることを特徴とするプログラミング環境
プログラミングとは何か?を教えるための最初の一時間ならばそれらは不要かも簡単にしすぎくらいじゃないと何をしているのかを分離して覚える事は難しいと思う
昔のMSX BASICから入りましたが、別に混乱はなかったですよ。あれは、型がなかった訳じゃなくて文字列型と数値型は命名則で区別できましたから。ちょっと覚えると、変数を整数型にすることを覚えたりしますしアセンブラを使うようになると、そもそも型なんて無い事にも気付きますし。
そしてスコープに至っては、サポートがなくて苦労しましたのでC言語でスコープの概念が出てきたときは凄く便利だ、と思った記憶があります。
習う順番はともかくいくつかの概念を知ることでそれらの差異に気付けますからあまり気にしなくていいのかな、と思います。
スコープや型は、初級者がステップアップしていく上で、素直に習得していける概念ではないかなと思います。変数という概念を知る。べんり!→汎用型では自由度が高すぎるという不便にぶつかる。→型で束縛する事の有効性を知る。
すべてグローバル変数で作る。かんたん!→プログラムが大きくなってくると困る事が多くなる。→スコープで縛ると管理しやすくなる。
というような。むしろ、最初からスコープや型の管理を要求されるとその必要性が理解できないかも。「学習用」の使い捨て言語と割り切れば、アリかなと思います。
一挙に教えようというのも、誤りではないかい?小学校1年の算数に、論理演算はともかく、引き算/かけ算/割り算を省いて教えても後で混乱するだけじゃないか?というのと、同じことで、まずは数字って?数って?足せるんだよ、これが計算の最初だよ..と教えないと無理だろうね。
あとで教えるべきは後で教えたらいいわけで、初学で教えるツールが満干全席であっても、どれから箸を付けたらよいか?初学のあとで他のツールに切り替えるのだから、それは意味がないよね、それより確実に足し算までを教える理解できる様にするツールって位置づけもあってよいし、そういう割り切りをしていない、中途半端に「あれもこれも」で初期教育以外も盛り込んで教えようとするのは、誤っていると思うけどね。
後で混乱というよりも。スコープないけど、サブルーチンはあるというのなら、ループ変数どうすりゃいいんだ……
# 慣習的に変数名が決まっていないものについては、スコープが広ければ、# 名前衝突防止のために長い名前つける習慣がついていいかと思うけど。
> スコープないけど、サブルーチンはあるというのなら、ループ変数どうすりゃいいんだ……当然グローバル変数ですよ。マイコン用BASICもそうだったでしょ。それでスコープの必要性を体で覚えさせてこそ学習用言語です。
BASICでは、次のことを覚えたらおしまい。
BASICにはデータ型はあるけど、全部大域変数だし、スコープなんてない。構造化BASICならば、中途半端なものはあるけど。
そもそも1つのプログラミング言語でいろいろ覚えようなんて幻想。手続き、関数、オブジェクト指向など様々なタイプがあるし、タイプが同じ言語でも、2つ以上触ってみないと、違いや本質は分からないよ。C++とSmalltalkが同じオブジェクト指向なんだし。
そのIF~THENで飛んだ先の処理が終わったところに無条件GOTOがないと困りませんか。
いずれにせよ、僕も単独gotoは無くていいと思っていた。
サブルーチンから戻る直前の共通処理なんかは、GoToで飛ばしたほうが分かりやすいでしょうね。今時はtry文のfinally節で実現することが多いですが。
ばかもやすみやすみいえ!
BAKA............BAKA............BAKA............BAKA............BAKA............BAKA............BAKA............BAKA
>おまじないやコンパイル等の手順が無いのは重要ですよね
シェルスクリプトやDOSのバッチファイルでよいかもしれない。ところでpeek pokeで自己書き換えはできるのかな?
>ところでpeek pokeで自己書き換えはできるのかな?
そして怒涛の機械語ダンプのData文ですかwそんなプログラムがBASICプログラムとして紹介されていた今は亡きマイコンベーシックマガジン。
#「BASICなんてただのローダーです。偉い人にはそれがわからんのです。」
>そして怒涛の機械語ダンプのData文ですかw
うん、Basicの特徴的な機能だと思っていたりする。出来ないとしたら、Basicの半端者という印象もある。
>「BASICなんてただのローダーです。偉い人にはそれがわからんのです。」
そういう使い方も出来るという面で、ある種の拡張性を備えていたと思う訳です。非常に野蛮で粗野な方法ですが...
Basicってなんですか?#図らずも小文字と大文字の区別が出来ないバカをあぶり出すことになったw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
簡単にし過ぎてない? (スコア:0)
Re:簡単にし過ぎてない? (スコア:3, 参考になる)
コンパクトなプログラムを書くだけならそういった仕組みは不要ですね。"Hello World" と表示するだけのプログラムにとっては、#include とか main() とかはおまじないでしかありません。実際に入門書でも最初はおまじない扱いです。これらの仕組みは、プログラマーの自由度を縛ることにより品質や生産性を高める仕組みです。つまり、プログラマーにとっては、その必要性が理解できない限りは「余計なお世話」でしかありません。逆に言うと、一度そういったものが必要な状況に陥って苦労することでこれらの仕組みの必要性を肌で理解できるようになるでしょう。したがって、入門者には、そういったおまじないを取り払った環境で、プログラムが動くという楽しさを味わってもらい、いろいろやっているうちにプログラムが肥大化していくでしょうから、そのタイミングでこれらの仕組みを提示出来れば良いのではないかと思われます。
プログラマの技量に合わせてこれらの機能が有効にしていけるような仕組があればよいですね。最初は型すら定義出来ていなかったのが、習熟にともなって機能の封印を解除していくと、オブジェクト指向が導入されたり、ポインタが導入されたり、最終的にはガベージコレクタが無効にできたりすると、いつのまにやらC++プログラマーですね。
Re: (スコア:0)
プログラムの経験値が上がると使える機能が増えることを特徴とするプログラミング環境
Re:簡単にし過ぎてない? (スコア:1, すばらしい洞察)
プログラミングとは何か?を教えるための最初の一時間ならばそれらは不要かも
簡単にしすぎくらいじゃないと何をしているのかを分離して覚える事は難しいと思う
Re:簡単にし過ぎてない? (スコア:1, 参考になる)
昔のMSX BASICから入りましたが、別に混乱はなかったですよ。
あれは、型がなかった訳じゃなくて文字列型と数値型は命名則で区別できましたから。
ちょっと覚えると、変数を整数型にすることを覚えたりしますし
アセンブラを使うようになると、そもそも型なんて無い事にも気付きますし。
そしてスコープに至っては、サポートがなくて苦労しましたので
C言語でスコープの概念が出てきたときは凄く便利だ、と思った記憶があります。
習う順番はともかくいくつかの概念を知ることでそれらの差異に気付けますから
あまり気にしなくていいのかな、と思います。
Re:簡単にし過ぎてない? (スコア:1, 興味深い)
スコープや型は、初級者がステップアップしていく上で、素直に習得していける概念ではないかなと思います。
変数という概念を知る。べんり!
→汎用型では自由度が高すぎるという不便にぶつかる。
→型で束縛する事の有効性を知る。
すべてグローバル変数で作る。かんたん!
→プログラムが大きくなってくると困る事が多くなる。
→スコープで縛ると管理しやすくなる。
というような。
むしろ、最初からスコープや型の管理を要求されるとその必要性が理解できないかも。
「学習用」の使い捨て言語と割り切れば、アリかなと思います。
Re:簡単にし過ぎてない? (スコア:1)
一挙に教えようというのも、誤りではないかい?
小学校1年の算数に、論理演算はともかく、引き算/かけ算/割り算を省いて教えても後で混乱するだけじゃないか?というのと、同じことで、まずは数字って?数って?足せるんだよ、これが計算の最初だよ..と教えないと無理だろうね。
あとで教えるべきは後で教えたらいいわけで、初学で教えるツールが満干全席であっても、どれから箸を付けたらよいか?初学のあとで他のツールに切り替えるのだから、それは意味がないよね、それより確実に足し算までを教える理解できる様にするツールって位置づけもあってよいし、そういう割り切りをしていない、中途半端に「あれもこれも」で初期教育以外も盛り込んで教えようとするのは、誤っていると思うけどね。
Re:簡単にし過ぎてない? (スコア:1)
後で混乱というよりも。
スコープないけど、サブルーチンはあるというのなら、ループ変数どうすりゃいいんだ……
# 慣習的に変数名が決まっていないものについては、スコープが広ければ、
# 名前衝突防止のために長い名前つける習慣がついていいかと思うけど。
1を聞いて0を知れ!
Re: (スコア:0)
> スコープないけど、サブルーチンはあるというのなら、ループ変数どうすりゃいいんだ……
当然グローバル変数ですよ。マイコン用BASICもそうだったでしょ。
それでスコープの必要性を体で覚えさせてこそ学習用言語です。
Re: (スコア:0)
BASICでは、次のことを覚えたらおしまい。
BASICにはデータ型はあるけど、全部大域変数だし、スコープなんてない。構造化BASICならば、中途半端なものはあるけど。
そもそも1つのプログラミング言語でいろいろ覚えようなんて幻想。
手続き、関数、オブジェクト指向など様々なタイプがあるし、
タイプが同じ言語でも、2つ以上触ってみないと、違いや本質は分からないよ。
C++とSmalltalkが同じオブジェクト指向なんだし。
Re: (スコア:0)
あと、古典的 BASIC で GOTO なしはきついんじゃないだべか。
Re: (スコア:0)
IF 条件式 THEN 行番号
で十分。ELSEもWHILE〜WENDもラベルもあれば、なおよし。
Re: (スコア:0)
そのIF~THENで飛んだ先の処理が終わったところに無条件GOTOがないと困りませんか。
Re: (スコア:0)
飛び先が終わった時に単独gotoが必要ならば、それはgosub returnにできる。
終わり方が複数ありgotoをつかうならば、それはif?? then行番号にできる。
いずれにせよ、僕も単独gotoは無くていいと思っていた。
Re: (スコア:0)
サブルーチンから戻る直前の共通処理なんかは、GoToで飛ばしたほうが分かりやすいでしょうね。
今時はtry文のfinally節で実現することが多いですが。
Re: (スコア:0)
ができないBASICなんて捨ててしまえ!
Re: (スコア:0)
感じるのは、今の言語はいきなり書くこと、覚えることが多い、ということ。
プログラムを作る上で何より重要なのは、自分で書いたものが「動く」のが見えることだと思う。
ほんの少しのタイプでちゃんと動くと効果的ではないかなと。
public static void main…単語が多すぎ。
その意味で、まずロジックに特化して学習できるのは良いと思う。
if文やfor文の考え方すら分からないうちは、スコープの意味と必要性の理解なんて夢のまた夢。
Re: (スコア:0)
を動かし
10 PRINT "BAKA"
20 GOTO 10
で喜ぶのはお約束
おまじないやコンパイル等の手順が無いのは重要ですよね
Re:簡単にし過ぎてない? (スコア:1)
懐かしきSTOPキー。
Re:簡単にし過ぎてない? (スコア:1)
ばかもやすみやすみいえ!
BAKA............BAKA............BAKA............BAKA............BAKA............BAKA............BAKA............BAKA
>おまじないやコンパイル等の手順が無いのは重要ですよね
シェルスクリプトやDOSのバッチファイルでよいかもしれない。
ところでpeek pokeで自己書き換えはできるのかな?
Re:簡単にし過ぎてない? (スコア:1)
>ところでpeek pokeで自己書き換えはできるのかな?
そして怒涛の機械語ダンプのData文ですかw
そんなプログラムがBASICプログラムとして紹介されていた今は亡きマイコンベーシックマガジン。
#「BASICなんてただのローダーです。偉い人にはそれがわからんのです。」
Re:簡単にし過ぎてない? (スコア:1)
>そして怒涛の機械語ダンプのData文ですかw
うん、Basicの特徴的な機能だと思っていたりする。
出来ないとしたら、Basicの半端者という印象もある。
>「BASICなんてただのローダーです。偉い人にはそれがわからんのです。」
そういう使い方も出来るという面で、ある種の拡張性を
備えていたと思う訳です。非常に野蛮で粗野な方法ですが...
Re: (スコア:0)
Basicってなんですか?
#図らずも小文字と大文字の区別が出来ないバカをあぶり出すことになったw
Re: (スコア:0)
Re: (スコア:0)
月刊マイコンがわからない貴様、さては素人だな(違
Re: (スコア:0)
Re: (スコア:0)
BASICならば、CLS:DEFINT A-Zくらい書かないと。
Re: (スコア:0)
子供の頃にBASICでプログラミングしていた頃の記憶を思い起こすと、変数のリストをノートに書いておいて、それを見ながら組んでいました。エディタがあったわけではなく、対話型のシェルのようなものを介しながらプログラミングなので、コードの中に型の宣言があったりするよりも、紙を見たほうが速かったんですね。
その紙に書いたものが、今で言うところのドキュメントの代わりをしていて、コード中に変数の意味を明確にするためのコメントを書いたり、説明的な変数名を使わなくても混乱しませんでした。
また、データと処理が分離していたので、オブジェクト指向プログラミングのように処理をどこに書くべきかという不毛なことで悩むことなく、処理に集中して書くことができました。
もちろん、プログラミング対象が複雑になるとそうはいかないのですが、プログラミング対象が単純な場合に限っては、スコープや型宣言がないほうがドキュメントの作成も並行してできて、良いプログラミング習慣だったように思います。