umentuのブログ

趣味や自学でプログラミングをする上で思ったことを書いていきます。pythonのブログ: http://blog.umentu.work

このブログのこと

このブログをなぜ始めようかと思ったかというと、思っていることをそのまま話せない性格のため、なんとかして文章に書いてみたくなったからだ。 思っていることをそのまま言えないというのは、二つの意味で、だ。

一つ目は、思ったことを話すことの間に、意味のない考えるという作業が入ってしまい、口にだすことができなくなってしまう。 考えることは必要だ。 でも意味のない考える作業が入ってしまうのだ。 だから何が話したいのかが自分自身でもあやふやになってしまう。 このブログを初めて２つ目の記事がものすごいビュアー数になってしまったのだけど、２つ目のは今読み返しても思ったことが言えていない感がある。 いや、書いた時は思っていたことをそのままかけていたのかもしれない。なんともいえない。 でも、今ではもう少し付け足しで書けると思う。そのうち書いてみようと思う。 これは練習だ、練習。 練習に失敗はつきものだ。人に言われたからやるのではない。人の意見は人の意見だ。 人の意見で反省するのは少しの間、もしくはしばらくはしないようにしたい。 反省しすぎてどうしていいかわからなくなることもしばしばだからだ。

もう２つ目に行く。 ２つ目は、そもそも本心を言うのが恥ずかしいからだ。 本心を言い切れる人がどれほどいるのかはわからない。 少なくとも、自分は本心を言えない。致命的な問題だ。 今は、思ったことをただただ連ねてみているけど、これもブログを書くということが前提で思っていることかもしれない。 というか、人が文章を書くとき、いや何のときだってその前提で書いているのだ。 だから、本心というのが何を指しているのかと言われると、わからなくなってしまう。 少なくとも、口にだすときには常に本心を言えていない感じを持っている。 これが色々な弊害を生んでしまうし、生んでしまった。

この間のブログは、丁寧語で文章を書いてみた。 これは村上春樹の「職業としての小説家」を読んだからだ。 できるだけ、人に話しかけるように書いてみたつもりだけど、やはり記事にするような文章になってしまっていたかもしれない。 今後は練習してみるつもりだ。

これ、本当に公開するのだろうか。 下書きのままにしておこうか。 どうしよう。 見せたくない気持ちもあるし。

多分このブログで言いたかったことって、人の目を気にしないで人の意見に左右されないでプログラミングに触れてほしい、ということだ。 そういう意見を書いてしまっているのはどうかと思うんだけど。

周りを気にしないでプログラミングが出来る人は大勢いる。ただ、一人で抱え込んでしまって、勉強しようとしたけど、もしくはしたけどどうしていいかわからず、し始めたばかりのときのモチベーションだったり楽しさだったりを失ってしまった、ごく小数かもしれない人に向けて書きたかったからだ。 それ以外の人はあまり見てほしくない。

なぜプログラミングに固執しているのかはわからない。 それなりにコードが書けるからかもしれない。 でも基礎はないし、応用もできるとは思っていない。 基礎も応用も大事だ。 でも基礎も応用もなくてもプログラミングはできる。 基礎も応用もあってないようなものだと思っていい。 基礎がなくてはできないものでも、応用力がなくてできないものでもない。 思ったことを書く、それがプログラミングに必要なことなんだ。

ブログを書くのもコードを書くのもそんなに違わないことかもしれないな。 コードを書くのは、外国語でブログを書くようなものなんだな、きっと。 慣れないと書けないし、単語を知らないと書けない。 でも思ったことを思ったとおりに書けたら嬉しい。 その初めに　思う　という部分をどうにか手助けしたくて、このブログを始めたんだな、きっと。

今まで一瞬足りともタイプを止めずにブログを書いている。 思ったことを思ったとおりに書けている感じがする。 いい感じだ。 いいや、公開しちゃえ。

「プログラムを作る」スタートラインに立つために

入門者にとってのプログラミング

プログラミングの入門者の方たちと話すと、

「プログラミングでifとかforとかやったけど、何が作れるのかのイメージがわかない」
「入門本をやってるけど、どうやってプログラムができるかわからない」

という声を聞きます。もう一歩進むことができた方でも

「入門本を通読したけど、そのあとどうしたらいいかわからない」
「なぜクラスを使う必要があるのかわからない」

という声も聞いたことがあります。それらの質問に対して一つの便利な言葉で回答することができます。

「自由にプログラムを作ればいいんだよ」

この言葉で突き放された気持ちになったことのある人は多いのではないのでしょうか。 自由というのは、なんとも途方のない言葉です。

なぜ「自由に」プログラムを作れないか

入門してしばらくしても、
「入門本をやったのに」
「これをやったらプログラムが作れると聞いたのに」
と、自由にプログラムが作れないもどかしさを感じている方がいるはずです。

なぜプログラムが自由に作れないか。 それはプログラミングとプログラムを作ることにギャップがあるからであるように思います。

「プログラミング」と「プログラムを作ること」のギャップ

あなたが劇作家であることをイメージしてください。 プログラム というのは、とある劇のストーリーを意味します。 プログラミングというのは、その劇の台本を書く作業です。

物語の構成が決まっているのであれば、それに当てはまるセリフはある程度決まってきます。 「愛してる」というところを「このゴミが」ということは（ツンデレならありえますが）あまりないですね。

しかし、台本を書く作業から始めるとどうでしょう。 どのように物語が進行していくか「自由」に決められますが、物語の収集がつく気がしませんね。
（セリフ先行で考える作家さんも多くいらっしゃいますが）

ハッピーエンドにしろバッドエンドにしろ、プログラムを作る上では物語の結末ありきで考えたほうがよさそうです。

プログラムを作るイメージを脳内に作る

どういうプログラムが作れるのか、というイメージを考えるのはどういう物語を作るのか、という作業と似ているものだと思います。 なんとなく才能が必要そうな作業ですよね。でもプログラムは物語よりも目に見えるものなので、想像がつきやすいように思えます。

それでもはじめのうちは正直言って、難しいかと思います。

もし、やりたいことが決まっている場合は、*そのやりたいことを分解してみる ことをおすすめします。
ありきたりな答えですね。すみません。
twitterのツイートを集めて表示したい場合は、

「twitterからツイートを取得する」
「取得したツイートを保存する」
「保存したツイートを表示する」

というような分解をします。その後に、例えばツイートがデータベースに保存されている場合で「保存したツイートを表示する」を、

「データベースにアクセスする」
「データを取得する」
「HTMLに出力する」

などに分解するとプログラミングが書きやすくなります。その上で試行錯誤してみるといいと思います。

もし、やりたいことが今のところない場合は、まず プログラミングでなにができるかを改めて調べてみるのをおすすめします。 その中で 何を作ってみたいか を見つけてみてください。

もしかしたら自分が勉強しているプログラミング言語だと、「作りたい」と感じたプログラムが作りづらい事があるかもしれません。
そんな時は、意地でも自分の勉強しているプログラミング言語でつくってみるか、あっさりと勉強するプログラミング言語を変えてみるかのどちらかしかありません。 個人的には、プログラミング言語を変えてみる ことで使えるプログラミング言語を増やすきっかけになったと感じていますが、好みやプログラミング言語の理解度にもよります。こればっかりはなかなか基準が設けづらいです。コメントなりに残してもらえればお答え出来る範囲でお応えします。

もし、それで作りたいものが定まったら、上の「やりたいことが決まっている場合は」をやってみてください。

それでも「どうしていいかよくわからないけど、プログラミングをしてみたい」という人は・・・身近にいるプログラミングが出来る人に聞くといいと思います。 少なくとも、何をすればいいかのヒントはもらえるかと思います。
周りにいない場合は、コメントなりtwitterやskypeなりで自分に聞きに来てください。 できる限り力になります。
（即座に回答できないかもしれませんが、twitterやskypeだとよりご相談に乗れると思います。（id: umekichinano） ）

最後に

最終的には「人に聞け」というないようになってしまってしまいました。
しかし、ネット上の色々な有識者の人たちのqiitaなどを目にすると、「知っている人に聞くのが早い」と言っているのを目にしますし、これには大いに同意しています。

試行錯誤は絶対に必要です。ですが、「プログラミング習得はやっぱり目的であってはならない」でも書いたとおり、「プログラムを作る」最初の一歩は誰かの力を借りてもいいように思うのです。悩むのはその次からでも遅くはありません。

一筋縄にいかないこともでてきますが、「プログラムを作る」スタートラインに立つ上で大事だと思ったことを書いてみました。

いずれは一人でやることになる。それまでは。

自分でやらないと

「入門本や入門サイトをマスターしてからじゃないと、プログラムは作れない。」

「環境構築から全部マスターしないと、原理がわからない」

プログラミングを始めたばかりの頃、そんな風に考えていた。

無駄にレベルを釣り上げたネットの情報や、自分であえて選んだ分厚い入門本に書かれている言葉を信じて。

壁は高ければ高いほどいいと思っていた。（今でも思いがちだけど。）

（本当は最後に書くべきだが、最後まで読まずにお帰りになられる方のためにあえてはじめに言うと、もちろんそれらは全く間違いなどではないと思っている。）

でも、うまくいかない

実際に作業に取り組むと、入門本の真似をしても間違いに気付けずに同じように動かなかったり、サーバが必要と書いてあってLinuxをインストールしようとするも操作方法がわからずにプログラミングにたどり着くことができなかったり。

基礎的な部分ほど入り組んでいてわかりづらい。

偉い人達が作ったんだもの、当然。

基礎は簡単っていう意味ではない。

家を作るときに、基礎の地盤を固めることって果たして簡単なことだろうか。

そんなことはない。

そんなことわかってる。でも基礎は大事だ。

でもうまくいかない。

なぜうまくいかないんだろう。

調べてもよくわからない。

じゃあわからないところの基礎を調べてみよう。

なんかわからないけど、こうするのか。

あれ、でもうまくいかない。 なぜうまくいかないんだろう。調べてもよくわからない。じゃあわからないところを調べてみよう。なるほど、こうするのか。あれ、でもうまくいかない。なぜうまくいかないんだろう。。。

初心者でこんなループの3週目に入ることができたら、根気のある方だと自信を持ってい。

一人でやりきる必要のあることってはじめはほとんどない

勉強にかける時間はいくらかけてもいいと思うし、自分も時間に縛られることなくゆったりと勉強したいと思う方だ。

でも、どうしたって時間には制約がある。

であれば、できるだけ無駄な労力は排除したい。

プログラミングを始めたいなら、今であればメジャーなプログラミング言語なら実行できるクラウド環境（BaaSやDaaS）が用意されているはずだ。（ブログを見てskypeに質問を下さった方からmilkcocoaを紹介していただいた。感謝。）

そういったものを利用するに越したことはない。

今すぐプログラミングを実行したいなら、原理を知らなくても実行できるんだ。作りたいものだって、検索をすれば大抵のものはサンプルコードがどこかに落ちている。どう検索していいかわからなければ、Twitterなり2chなりskypeなりで聞けばいいのだ。誰かが答えてくれる。

最終的には一人でやらないといけないこともある

ある程度プログラムを作るまでは、他の方のサンプルコードをいじって作ってみることが多いかもしれない。入門本にも有益なサンプルコードが用意されていることも多い。

でも、どこかでオリジナリティを出したくなる。

そのとき、OSやプログラミング言語のバージョンを気にする必要が出てくるかもしれない。そこで初めて自分一人でやればいいんだと思う。

プログラミングにかける力よりも、プログラムを作る方に力を向けるべきだ。

いずれ、OSやプログラミング言語のバージョンなどを気にする必要が出てくる、その日まで。

プログラミングの基本に惑わされてはいけない

単なる言葉遊びになってしまいそうだけど、思うこと。

まずは基本から？

小学校の算数のドリルを思い出してみる。
（ドリルってことば、懐かしい）

で「まずはきほんから！」で15問くらい簡単な書いてあって、最後の5問くらい「おうようしてみよう！」と難しい問題が書いてある。

算数の苦手な子なら基本問題すらよくわからなくて、応用問題はノートに問題番号だけ書いてフリーズしているかもしれない。 算数の得意な子なら、基本問題はだるくて答えを書き写すようにスラスラ解いて、応用も考えながら解いていくとするだろう。

ではプログラミングの場合。 基本とはなんだろう。どこからが応用だろう。

基本って？

プログラミングの基本ってなんだろう。入門本に書かれていることだろうか？

それは一概には言えない。なぜかというと前にも書いてある通り、入門本によって内容が異なるからだ。（算数のドリルも出版社によってレベルが違うだろう）
いや、内容というよりも 著者が違うから といった方がいいかもしれない。

抑えておくべき基本 というのは 著者の考え方による からだ。

「プログラミングの基本」を書きたい著者であれば、「ifやforなどの構文を抑えておけばどの言語でも通じるから基本」と考えるかもしれないし、「紹介している言語の基本」を書きたい著者であれば「この言語のこの書き方は基本」と考えるかもしれない。

要するに 人や前提 によって基本は変わってしまうのだ。

応用って？

基本が 人や前提 によって変わるのだから、どこからが応用かも 人や前提 によって変わってしまう。言語特有の特別な記法が応用となるかもしれないし、いくつかのプログラムを合わせて一つのプログラムを作ることも応用になりうる。

ifもforも後回しでいい で書いたように、初心者にとってはifやforを使うことも応用になるかもしれない。

世の中の基本に惑わされないように

人によって基本や応用が変わってしまう。
本当にレベルの高い人達の中に突然入っていってもなかなか会話を理解することはできないだろう。
でも、基本のレベルを無理に引き上げようとしてしまう力が存在する。（主にネット上の匿名の人たち）

いくつかの入門本や入門サイトを読んで同じことが書かれていることがある種の入門に近いかもしれないが、
それらをすべて覚えていなかったからといってプログラムが作れないというものでもない。

自分の知っていることを「基本」としてみる。
「あれ、今までの知識だとこれができない」とか「こんなことをやってみたい」と思ったことを「応用」としてみる。
そんな考え方をしてみてもいいのではないだろうか。

これを読んで、少し気楽にプログラミングができるようになったらとても嬉しい。

ifもforも後回しでいい

タイトル負けする文章になることはさておき、言いたいことはタイトル通り。
今から勉強し始めたいと考えている人、もしくは前にやめてしまいもう一度始めたいと思っている人向け。

なぜ使うのかがわからない

プログラミング初心者の人と前に話した時に「なぜifやforが必要なのかわからない」という言葉を耳にしたことが何度もある。 　
もしかしたらプログラミングが出来る人にはわからない、多くの挫折した人たちが抱えていた問題なのかもしれない。

わかる人にとっては、「forは繰り返し、ifは条件」といえばわかる。
何故わかるかというと、「繰り返し」や「条件」の必要性がわかるからだと思う。

そもそもプログラムとは

    プログラム
        物事を行う手順のもくろみ。

プログラミングはコンピューターにやらせたい指示を一行一行書いていく作業で、
その指示をひとまとめにしたものをプログラムと呼ぶ。

for文(繰り返し文)は「自分が繰り返し何度も書かないといけないことを変わりにやってくれる」
と思えば、もしかしたら少しは利用価値を見出してもらえるかもしれない。

if文(条件文)は・・・まぁとりあえずパス。

わからなければ使わなくていいじゃん

ここまでなぜわかるかわからないかといっておいてどうかと思うが、わからなきゃ使わくていいと思う。
わからなければとりあえずすっ飛ばしてしまえばいい。
もし「1から10までを表示する」必要があったら、

print(1)
print(2)
print(3)
print(4)
print(5)
print(6)
print(7)
print(8)
print(9)
print(10)

これでいい。

あとで使う必要性を感じればいい

おそらくif文やfor文の必要性がわかるようになるまでは、そんなに時間がかからないはず。
特にif(条件文)は、10分後には必要だと感じているかもしれない。
必要と感じた時に初めて使ってみればいい。

これを繰り返す

「よくわからない」-> 「すっ飛ばす」 -> 「必要と感じる」 -> 「使ってみる」

を繰り返すことでプログラミングは少しずつ使えるようになるはずだ。

必要性を感じることが大事なのだと、思う。
わからないところで止まるよりもずっといい。

プログラミング習得はやっぱり目的であってはならない

タイトル通りのことを書く。

結論としては プログラミングはプログラムを作ることが目的という認識を忘れないでほしいということ。 初学者に陥りがちなことを例に書いていく。 仕事メインでプログラミングを使うというよりは、趣味であったりプログラミングがあった方が仕事が円滑に進むかも、という人向け。

初心者本がわからない

入門本を全部理解するのは中級者になってからと思ってもらって構わない。
もちろん入門本の中でもレベルに差があり、また
「すべてを網羅した本」
「本当に導入しか書いてない本」
「重要な部分のみをまとめた本」
「オマジナイ本」
「うまい具合に中身の無い本」
「本当に中身の無い本」
など様々ある。有名なところで言えばオライリーの本。本にもよるけど入門本でも十分に上級者向けに近い本もあり、初学者が読んでも数ページ読んで「やれやれ」ため息がでてしまう。
独習シリーズも昔からよく取り上げられるが、一冊やりきるのにはとても時間がかかる。

中身のない本に関しては・・・まぁここでは上げない。（上げる度胸がないだけですね、はい）

気合を入れるために厚い本や難しい本を買いたくなるのはわかるが、それではこの記事のタイトルの通り「プログラミングが習得が目的」となってしまう。 アマゾンのレビューで「良本です」というレビューでも、読んでいくとなんとなく「このレビューを書いた人は習得が目的になっているな」というのがわかる。

本を買うのはいい。難しい本を買ってもいい。ただ読み切ろうとしてはいけない。
目を向けるのはプログラムを作るために必要な部分はどこかということだ。

何をどう調べていいかわからない

初学者は知識が無いため、そもそも作るためにどのような知識があればいいかわからないことが多い。

「何の言語を使うべき？」
「その言語を使うためにはどうすればいいか」
「サーバ？なにそれ？」
「フレームワーク？？？枠仕事？」
「なんか英語のエラーががが」 「なんとか一つ調べ始めたらわからない単語が三つ四つ・・・」

出し始めたらキリがない。ここらへんで大体一度モチベーションが尽きる。ではそんな時はどうすればいいか。

分かる人に聞けばいい

ネットで質問すればいい。2ch、yahoo知恵袋、twitter・・・。どこでも質問はできる（答えてくれる保証はないが）。 でも質問する度胸がない。自分もそうだった。

ではどうしよう。そんなときはskypeをインストールしてユーザー名「umekichinano」と検索してフレンド申請し、質問を投げてみよう。 umekichinanoがわかればきっと答えが帰ってくるはずさ。ははは。 もしくはtwitterで@umekichinanoにでも投げるんだ。

モチベーションが上がらない

本を片手にひたすら書いていてもモチベーションが上がらずに手がつかなくなってしまうことがある。 そんな時はどうすればいいのか。

それを知っていたら教えて欲しいくらいだ。
今出せる答えは、一旦やめるだ。
初学者だろうが上級者だろうがモチベーションには波がある。コードが書けるときはがーっとかけるが、書けない時は書けなくなる。 なら一旦やめるといい。そのまま半年間触らなくてもいい。やりたくなったらやればいいだけ。

やめてる間に違う方向からプログラムを書く目的が現れるかもしれない。 友達と話していて「こういうサイトがあったらいいな」とか話をしたり、電車に乗っていて「こういうアプリは儲かるかも」とか妄想したり。 やめてる間にだってプログラミングの目的は生まれてくるかもしれない。

最後に

色々経験した上でまわりまわってプログラミング習得が目的でもいいという考えに至った時期もあった。 が更にまわってやっぱりプログラミング習得は目的ではいけないと考えるようになった。 主な理由は、プログラミング習得を目的にできるほど時代がゆっくり流れていない、ということだ。 一つの言語で何時間も書けなければならないものが、他の言語だと数分でできるといったことだってある。 周りを見渡す余裕を作るためにも、さくっとプログラムを作れるようになりたいものだ。

(プログラミングの)教え方、学び方概論

プログラミングを教えるときに何から教えればいいかという議論は、その瞬間で真剣に、もしくはなんとなく議論されている。

真剣に議論してもなんとなく議論しても、結論としてはそれまでの慣習に近い形でまとまっていく。 でも次の瞬間にはまたどこかで議論が始まるのだから答えではないのだろう。

まとまらない理由は、今書きながら思いついた限りでもいくつか思いつく。

・教わる側の対象が絞れていない ・教える側の対象が絞れていない ・何を教える(教わる)か定まっていない ・言語論争に走ってしまう

教わる側の対象が絞れていない

モチベーション

2chまとめなどで「プログラミングを教える」のような記事を見かけるが、大体が教わる側の対象を絞れていないことが多い。 まぁ教えたい側が教えたいように書いて、それを読んで理解できる人を教わる人としているのだろう。 教わる側に強いモチベーションがある場合は、それはとても効率的に働くことがある。

しかし、ある程度のモチベーションがあっても諦めてしまうか、どうモチベーションを作ればいいかわからない人が多い。 教わる側がどのくらいモチベーションがあるかどうかを計るは大事。

逆に教わる側は怖がらずにわからない単語を調べるだけでも、その後の興味の持ち方が段違い。 （個人的には調べてる暇があったらちょっとでも簡単なプログラムを書いてみて欲しいところ）

知識

知識量はあまり気にする必要がないように思える。 教わる側に知識があっても知識がなくても、教える内容は教える側に依存するところがあるからだ。 (教わる側の方が知識が有ることもしばしばあるし。)

ではここでいう知識が何かというと、 教わるまでに教わる相手がどのくらい知識をつけようとするか ということだ。（ブラックと思われそう） これは上でのモチベーションにも繋がるが、最終的には結局は自分で解決しないといけないというところに至る。 そこをみることで、どの程度教えればいいかも図ることもできる。 講義(ハンズオン)をやると決まった段階で、事前にどの程度の知識があって講義までにどの程度をつけたかをこっそり会話などで計っておくといいかもしれない。

一人？複数？

教わる人が一人の場合は事前に悩むことはないように思える。 せいぜい課題のレベルを対象に合わせるか、固定するかくらいだろう。

複数の場合は悩みどころが増える。 個人個人の力量がばらつかなければ、ものすごく力があっても逆に全く力がなくても、そんなに問題はない。 問題はばらつきがある場合だ。

講義の場合はどこまでレベルを下げるのか、もしくは上げるのかの落としどころは見えづらい。 ハンズオンの場合は、レベルの上げ下げに加え、一律のことをさせるのか、作業を分担させるのかなどの問題が膨らむ。 これは教わる側に依存することはもちろん、教える内容にも依存する。

教える側の対象が絞れていない

教える側のモチベーション

教える側が教えたいか教えたくないかにかかってくる。 情報発信が簡単になっている現状で、

ブログなどで情報発信している側にいる人は基本的には「教えたい人」 発信していない人は「（あまり）教えたくない人」

と考えてもいいのかもしれない。 教わる側の人はブログを書いている人などにコメントを残すと喜んでほいほい返信してくれると思う。

教える側の知識量

当たり前のようだけど、教わる側より教える側の知識量はかなり重要。 知識量というより知識の吸収力というべきだろうか。 最終的に教わる側に教えないといけないことは 自分で解決する能力 なのだから。

何を教える(教わる)かテーマが定まっていない

意外と具体的に何を作るか、ということを定められていないことって意外とあるように思う。 例えば「スマホアプリを作る」というセミナーがあったとする。 スマホ上にアプリを表示するだけのアプリならSDKのインストールなどの環境設定の方でお腹いっぱいになってしまう。 ではSDKなどをインストール済みのPCを渡せばいいのだろうか？ どこのディレクトリ（フォルダ）に何があるということを理解しないでエラーの内容が理解できるだろうか。 そもそもAndroid?iPhone?

まぁ実際にはこんなことを考えなくても、講師が話す内容で徐々に明らかになっていくようにはなっている。

しかしテーマは、「Java + cocos2dを使ってパズルゲームのAndroidアプリを作る」と言った形で できるだけ検索できるワード を使って絞ったほうが教わる側のモチベーションに直結するように思う。

言語論争に走ってしまう

「どの言語から始めればいいですか？」 「C言語からやらないと」「オブジェクト思考でJavaから」「HTML+Javascriptは簡単でいい」「いやいややっぱRubyでしょ」

だいたい日本だとこんな感じだ。 （私の好きなPythonはまだあまり日の目を見ていない）

「◯◯というプログラミング言語は今後も発展していく余地があり、必ず学習しておいて損はない」 と1980年ごろに書かれた文章を紹介しているが、その◯◯という言語は1990年以降みたことがない。

といった文章をどの本かは忘れてしまったが読んだことがある。

「プログラミングはひとつ覚えると他の言語も簡単に覚えられる」というのは2、30年くらい言われ続けている言葉ではないだろうか。 いま熱い！という言語から始める間違いではない。でも昔の言語から始めるのはもはや間違いであると思う。 今となっては、古いプログラミング言語を修得するほうがハイコストローリターンだからだ。

ということで言語はローコストハイリターンな言語を選べばいいと思う。 その上でどの言語を選択するかは 教える(教わる)かテーマ を定めれば自ずと定まってくるはず。 いずれ必要になったらC言語などの言語を習得すればいいと思う。

今回は概論。 思いついたら具体的なパターン方法を公開していく。