プログラミングを科学として取り組んでる人たちも居るんですね。
科学的なアプローチの結果「プログラムレス」って発想が生まれてくる。
中身はおそらくJAVAで書かれてるんでしょう。これがビジネス分野。
科学者も生活費は稼がないといけませんから。
根っこにはソフトウエア工学なる分野がある。
プロセスフローを（書かせてた）。私は書かなかった。
そこは社内システムだからサボれた。ゆとりある時代。
手続き型言語にはGOTO文がある。目的の場所に飛べて便利。
手付き型だから仕方ないんだけどね。だからフローチャートが重要になる。
機械命令にジャンプはあるから、忠実に実装したんでしょう。
pythonは処理の流れにラベルを付けれないからジャンプ命令が無い。
そういう意味では構造型、関数型言語。処理は階層化され上から下に流れる。
階層の中で処理は徐々に収束してすべて終われば次の階層。
人間の思考に近い。たぶん人間の脳にはジャンプ命令は無い。
プログラムを書くにあたってはデータの流れをまず決める。
入力ー＞処理ー＞出力これが決まり。入力、出力には空が許される。
これが何段も積み上がってる。
処理はデータに付属してるって見方をすればデータはオブジェクトの一種。
データの流れに沿って処理内容を記述していけばいいわけです。
pythonの場合データ型にリスト、タブル、辞書、集合があります。
なので様々なデータに対して直感的に処理が書ける。
pythonの構造で特に重要なポイントがあります。
構造化プログラムで多く使われるのが反復、pythonではfor 文。
こいつがかなりいい味出してるんですね。大抵のデータは配列ですから。
配列を読み込んで処理して新たな配列を吐く。
｛
{
｛
for
｝
｛
for
｝
}
{
｛
for
｝
｛
for
｝
}
｝
これを真面目に考えるとちょっと困った問題が起きます。
データベースから読み込んだデータをリスト型で蓄えて処理する場合。
まずlist1に読む。それから選別してlist2を作る、更に選別してlist3を。
データが多い場合メモリーが足りなくなるかもしれません。
SQLでは一度に読み込むリミットを設定できます。
処理的にはこっちのほうが高速でリストが作成されます。
pythonのfor文には裏技があるのです。
リストから１行ずつ読んで処理する見た目にはなってますが、
リストと思われてるところが実はリストでは無い。
大量のデータを返す処理には一行ずつ返す処理も内蔵されてます。
doc=データベースから読み込む処理（bongodbの場合）
この時のdocはリストではなくいわゆるオブジェクト(mongodbの一部)
オブジェクト指向と動的型付けの極意。
mongodb側はリストを返す事も出来る。
何が返ってくるかその場で決まる。例えば１００件以下だったらリストで返すとか。
for文は対象がリストなのかオブジェクトなのかを判断して処理を行う。
この臨機応変さがなかなか魅力的。この辺は性格にもよるでしょうね。
こういうのが嫌いって性格の方は静的型付けで四苦八苦してください。
for文と合わせて使う時にデータを一行ずつ返す処理になります。
内包したif文によってもデータが選別でき、目的とするリストが出来上がる。
実に科学的に考えられてます。
C++やらJAVA使いでもこの程度はできるでしょうが、プログラミング初心者が多次元配列を触るのは難易度が高い。
このへんはpythonの優位性でしょう。メモリを無駄にしないような工夫もされてます。いろんなデータを多面的に解析、分析する技法は今後は需要が増します。
代表的なのが各種の自動運転ですね。大企業が金かけてやらなくても、
優れた科学者なら一人ででも出来る。そのへんが科学者の夢でしょう。
分岐が無い。デシジョンテーブルでIF文を減らせる。
プログラミングを科学する。これはなかなか面白いゲームですよ。
ゲームとしてpythonでゲーム作ってもいいかもですね。
私的にはpythonの次世代に来る言語ってのが気になるかな。
マシン語ー＞インタプリター（人類の言語）＞AIの言語（AIのマシン語）。
工学的に考えてpythonの方向はかなり良いと思います。同族のruby同レベルかもしれません。昔なら途方もない行数が必要だった処理が今では数百行で済む時代。
生産性は格段に上がりました。コードが短ければ保守性も上がります。
脳内で考えたアルゴリズもをそのままコード化出来るのはかなりの快感。
ゲーム性が癖になります。