「国語」、「英語」、「物理現象の」＋「観察」
この３つは必要です
まず「国語」「英語」について説明します
プログラミング言語は限定された表現方法で束縛された言語です
XQueryではFLWOR
For、Let、Where、OrderBy、Return
他の高級言語では
代入文、条件判定文、ループ
アセンブラのような低級言語で例えれば
Move、Comp、Jump系、Push、Pop（他にもブロック転送やらなにやらありますが）
どの言語でも束縛された表現方法しかありません
一般の方には想像できないでしょうが
この束縛された表現で、画面の項目をチェックしたり
条件によって別の処理を行ったりなどを行っています
これには論理的思考が必要なのですが
それには修飾子にたぶらかされない「国語力」や「英語力」が必要です
出来れば日本語と英語どちらでも同時に考えられるのがベストです
どちらも使えることでWEBでの検索の幅が広がりますし、
とくに日本語は修飾子などに騙されるので英語で言い換えることで一歩引いたものの考え方が出来るようになります
最近の日本語の悪い例だと
「丁寧に説明します」や「忖度したんです」程度で説明したことになりましたよね？
「では、説明してください」
「では、なぜ忖度する状況になったのでしょうか？」
ということが全く議論されないのには参りました
人工知能の方がまだマシな議論ができたことでしょう
多少脱線しましたが
議論をして要件をまとめたり
コーディングをする上でも
語学力が必要となるため「国語」「英語」が重要という事です。
つづいて「物理現象の」＋「観察」について説明します
もっと単純に「探求心」と言ってもよかったのですが
逆にそれだと「何」を探求するのかわからなくなるため、
より具体的に「物理現象の」＋「観察」と表現しました
これなら誰でも何をすればいいのか分かるはずです
例えば
料理を作る際に最善の方法を模索する
スポーツで守備位置を俯瞰する
プログラムで他人と自分のコードを見比べる
自分のコードを常に疑う
「見えないものを見る方法」を考える
日々このように「物理現象の」「観察」をする姿勢が
「想像力」「創造力」「柔軟な思考」「論理的思考」につながるということです
「想像力」「創造力」「柔軟な思考」「論理的思考」を身に着けろ
と言われても、「どうやって？」が無いため、困ったことはありませんでしたか？
「物理現象の」「観察」をすればいいんです
まだ、なぜ「物理現象の」＋「観察」なのか伝わっていないかもしれないので補足します
ただ「花」や「鳥」「地球」を「観察」してくださいと伝えても
大抵の方は、「観察」ではなく、
ただ「見ている」ことしかしません
それではダメです
これも例を出しますが
UFOかプラズマか
プラズマだとしましょう
なぜプラズマが音速を超えて観察されるのでしょうか？
なぜ何もないところにプラズマが発生するのでしょうか
普通の物理学者であれば、
「プラズマです」では済ませません
説明になっていない事にすぐ気が付くからです
「原理はわかりませんがUFOの飛行原理からプラズマが発生する可能性がある」と言われたらどうでしょうか
こちらの方が説明になっていますよね？
しかも、簡単にこれを否定はできません
否定は難しいので別の見方を示します
例えばオーロラのような状態を想像すれば
発光に適した範囲が広範囲なので光の帯が広範囲に降り注ぐように観察されます
もしかしたら
「UFOは、あたかも高速に光が移動したように見えるプラズマに関連した自然現象なのかもしれません（ただしその自然現象がどのように発生するのかは不明です）」
例えば
赤外線をプラスチックに当てて
その反射光からプラスチックの種別を行う機械を発想し創った人が居ます
オープンソースです
プラスチックの種別と言う「見えないものを見る方法」を見つけたわけです
これも日々光や電波などを観察し、考察し、発想が生まれたはずです
ここまで読んで頂いて恐縮ですが
これらの例では、プログラムに直接役に立っていないようにも感じると思いますので
この点も補足します
正解が一つと限らないプログラムには
柔らかな発想が必須です
先に述べた通り
柔らかな発想が元ではなく、日々観察する姿勢が元なのです
自分の書いたコードを何度も書き直してみること
これがプログラム上達に役立ちます
Pythonなどでは、誰が書いても似たコードになります
つまりある意味コーディングのゴールがあります
しかし、高級言語になればなるほど
また、フルスタックフレームワークであればなおのこと
様々な書き方が許される状況になります
これは非常にまずい事です
ゴールが見定められないのです
どんなにDDDを読んでも
出来上がったアプリはフロントでもバックでも妥当性チェックをして
全体でポリシーが無いスパゲティになりがちです
例えば
SpringならBindingResult使えよ・・・
フロントは条件によってエラー表示だけすればいいだろ
フロントでJavaScriptで妥当性チェックを書くなよ・・
などなど思う事は多々あります
例えば
フラグだらけでぐちゃぐちゃなXAMLは沢山あります
一体誰に習ったのでしょうか？
一体どう調べてそういうXAMLを作ったのでしょうか？
Windowsが元はイベントドリブンであることを知らないで
フラグで済まそうとするからそうなるのです
基礎知識をきちんと調べること
自分のコードに疑問を持つ事
頭を柔らかくすること
帳票システムが無くPDFが作れない？
ならばTeXを出力してPDF化したらいい
既存のDBが遅い？
最善となるDBが無いなら作ればいい
わたしが１０年以上前に廃れ誰からも忘れ去られたXMLDBを作ろうとしているのは
そういう理由からです
あれこれと遠回りしていますが
わたしも日々周囲を観察し調べまくって
柔らかな発想を養っているつもりです
（大事なことなので二度言いました）
（追記）
わたしがここに書いたことはSTEAM教育の一種のようです
STEAMがScience、Technology、Engineering、Art、Mathematicsであるのに対して
わたしは語学力も必要だと主張します
てか、Artってなんだよ
無理矢理すぎるだろ
頭湧いてるんか？
お花畑か？
一億総漫画家レベルの画力を持つ日本人にアートとか片腹痛い
外国人の発想は日本人には馴染まないことが多いと思います
（さらに追記）
しかし、最後にその外人の
ウォルトディズニーの言葉を書いておきましょう
「空想をするときにも、現実を見失ってはいけない」
わたしが「物理現象の」＋「観察」と表現したのは、わたしもアニメの原画、動画を描いていた経験があるからかも知れません
0 件のコメント:
コメントを投稿