359.Python滅ぼす協会には入会しませんが・・・
初回:2024/04/10
この間『Python普及しろ協会に入会したい』という記事を見つけました、なにやら『Python滅ぼす協会に入会したい』という記事に対する反論的な話で、面白かったので取り上げてみたいと思います。
P子「あなたは普及派か滅ぼす派かどちら?」※1
どちらでもありません。
Pythonについては、遊びや趣味でプログラミングするのは非常に楽しいのですが、業務システムとして使うのは勘弁して頂きたいという立ち位置です。つまり、滅ぼされても困りますが、普及されても困ります。と言っても、メインの利用言語 1位やプログラミング言語の人気ランキングでも1位など、すでに十分普及していますので、今更という感じです。
P子「最近のAIブームでいうと、人気度は高くて当然よね」
1.Python普及しろ協会に入会したい
まずは、元ネタと、元ネタの元ネタをご紹介しておきます。
《参考資料1》
https://zenn.dev/nagataaaas/articles/b75f685ab30de6
Python普及しろ協会に入会したい
2024/04/03に公開
《参考資料2》
https://dev.thanaism.com/2023/05/python-sucks/
Python滅ぼす協会に入会したい
22 MAY 2023• 3 MIN READ
滅ぼす協会 に対する反論が、普及しろ協会なので、さらに、その反論という形で、話を進めたいと思います。
P子「やんかややこしいわね。要するに普及しろ協会への反論という事ね」
まあ、反論と言ってしまうと否定しているように聞こえますがそんなことはありません。どちらかというと『普及しろ協会』が世間一般の意見でしょう。ただし『滅ぼす協会』の意見は少数派なので、だいぶ過激に言っているだけなので、標準語に翻訳すれば同意する箇所も多くあるという感じです。
例えば『普及しろ協会』に書かれている追記の『本記事は「Pythonはこれだけ優れた言語だからみんな使おう!」というものではなく「言うほど酷くないと思うよ」程度のものです。』という話や、追記2の『言語には向いている用途とそうじゃない用途があります』には共感します。
逆に、追記2の『リテラシーが低めのエンジニアが居るような複数人開発ではPythonを選定することは多少チャレンジングだと考えています。』については、多少チャレンジングではなく、無謀だと思っています。
2.動的型付け言語も進化している
まず言語論争の中で、肯定派と否定派が分かれる一番の箇所が、この動的型付け言語か、静的型付け言語かの違いではないかと思っています。
個人の感覚で言うと、動的型付け言語でいいんじゃないという人達と、動的型付け言語は許容できないと考えている人達との違いだと思います。
これを例えると、多少の遅刻を許せる人達と、遅刻は1秒たりとも許せない人たちの違いだと思います。
P子「それって、動的型付け言語肯定派の人達が、時間にルーズって言ってるような物よ」
少し違います。
例えば、動的型付け言語肯定派の人達は、遅刻しなければいいんでしょという主張をされます。動的型付け言語否定派の人達は、中には遅刻する人がいるのでルールを必ず守らせる仕掛けが必要でしょという主張です。
『普及しろ協会』で主張されている『「十分に型を記述して型チェックも入れたPythonコードをmypyでチェックして実行する」こと』ではなく『「型も記述しないで適当に作ったPythonコードを実行する」こと』と『型の記述は必須で最低限、コンパイルを通したコードを実行すること』との間には、とてつもなく大きな差が存在しているというのが、私の意見です。
ちなみに、
《参考資料3》
https://logmi.jp/tech/articles/330373
「自分の未来予測を信じてちょっと意地を張ってみる」
まつもとゆきひろ氏がRubyに型宣言を入れない理由
#17 動的型付け言語と大規模開発
2022年10月04日に開催
この中で、動的型付け言語には未来があるという事ですが、『でも10年、15年、20年先の未来で十分にテクノロジーが進歩した暁には、十分にコンパイラが賢くなって、型宣言がなくても幸せな開発ができる未来が来るんじゃないかなというふうに思っていて、そのためには、今のRubyに型宣言を入れるのは賢い選択ではないんじゃないかなと思っているんですね。』という主張を見るとわかる通り、今後、10年、15年は、静的型付け言語ほどの幸せな開発は出来ないという事でしょう。
3.シンタックスがキモいらしい
まあ、慣れとか最初に学習した言語とかに引っ張られるので、個人の感想と言わざるを得ませんが、私もへんてこりんだと思っています。
例えば、3項演算子
Python 1 if x else 0
Java x ? 1 : 0
P子「どこが嫌なの?」
通常のif文はif then else で、これはPythonもJavaも同じですが、3項演算子を作るために、if を変形するという発想がへんてこりんです。特に嫌なのが、Trueの場合の値と、Falseの場合の値が、離れているところです。
『普及しろ協会』では、『PythonはそのSyntaxを英語に寄せており、可読性を重視している』との主張ですが、(人間が使う)言語というあいまいな概念ではなく数学とか記号化とかの曖昧な所を排除する方が可読性は断然上がります。
あと、辞書で、some_dict.some_key ではなく some_dict["some_key"] という箇所も、『Pythonでこれに等価なものはdictではなく、classのインスタンスである』との主張ですが、私個人としてもそんなことどうでもよく、some_dict.some_key でアクセスしたいと思っているだけです。
また、some_dict["some_key"] とsome_dict.get("some_key") と2種類のアクセス方法があったり、しかもsome_dict["some_key"] でキーがなければエラーになったり、get があるなら、set があってもよさそうだったり、some_dict["some_key"] = 'X' で登録できたりと、同じような書き方で、複数の使い方が存在するというのが、嫌です。
『定数が定義できない』 ことと、private変数が定義できない事、変数定義が自動的に行われるので、global宣言とか後付けでやりくりしているようで、正直気持ち悪いです。もっと言うと、import とか、from とかの扱いも判りにくいと感じています。
P子「それはあなたが素人だからでしょ」
初心者にわかりやすいと言いながら、なんとなく統一感がない気がします。こんなんじゃ初心者が作るプログラムは怖くて業務に使えないんです。
ちなみに、プロが作ればPythonだろうが、Javaだろうが問題ないかも知れませんが、多くの訳の分からない人たちが参加する大規模業務システムには、Pythonを使う気にはなれないというのが、正直な気持ちです。
4.教育現場でPythonが選択されているのは不幸なのか
教育という観点から言えば、PythonよりもJavaの方が向いていると思っています。とはいっても最近のJavaの文法はへんてこりんになりつつあるので、候補としてはどっこいどっこいなのかもしれません。これは、教育の目的が何なのかという事でしょう。
『普及しろ協会』では、『小学1年生に『人間失格』を読ませるのか。』という主張ですが、ではなく、小学1年生でも理解できる良い小説を読ませましょうというべきでしょう。Javaの基本機能だけを教えるのであれば、Pythonを教えるよりはるかに良いと思います。
特に、オブジェクト指向を教えるのであれば、Pythonではダメです。
『実はプログラミング教育の目的はプログラミング言語の習得それ自体ではなく、IT時代を生き抜くためにロジカルな思考を身につけ、活用する術・態度を育むことである(筆者は以前文部科学省のPython教材に関する記事を書いたことがあり、教材・資料を読み漁った)。』と言っていますが、『ロジカルな思考を身につける』のが目的なら、算数の授業で計算問題を数多く解かすよりも、数学的な考え方を学習した方が良いと思っています。プログラミング言語を使用しているのですから、ロジカルな思考を身に着けるだけではなく、やはりプログラミングとはこういうものであるという事も学習してもらいたいと思います。
であれば、Pythonでは、各種モジュール(numpyやopenCvや、その他多数の有用なモジュール群)を内容も良くわからないまま使う事が多いので、プログラミング学習の教材としてはあまりよくないと私は思っています。
5.まとめ
少し熱くなってしまいました。
Pythonは楽しい言語ですが、私は業務で使いたくはありません。きちんとしている優秀な人なら、PythonであろうとJavaであろうと同じようにきちんとしたプログラムが書けると思いますが、そうでない人が開発した場合、Pythonでは実行時エラーや意味不明のバグの解析に時間がかかったりしますが、Javaなら、嫌でも型宣言しないとコンパイルすら通りません。
そういう意味では、Python で大規模な業務システムを構築するなんて、怖くで出来ないというのが私の考えです。
P子「また、反論があるんじゃない?」
それは、そういう素人が多数集まって開発したプロジェクトに参加したことがない、周りに優秀なプログラマしかいないような幸せな環境で育った人なんでしょう。
ほな、さいなら
======= <<注釈>>=======
※1 P子「あなたは普及派か滅ぼす派かどちら?」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。
コメント
user-key.
そういや昔、シャープに爆弾を仕掛ける会が在ったが置いといて。
そんなにコンパイル時にチェックを必要とするのならRUSTで良いやん。
組み込み系では最近増えているし。
私の(変電所でヘルメットしてうろうろしたり、数百~数千万円の測定機と戯れる)業務では、python(と言うかSciPyやpyVISA等)が必須です。
ちゃとらん
user-key. さん、コメントありがとうございます。
そうですね。『業務システム』と『業務で使うシステム』をきちんと分けないとダメでした。
私も(主としてラズパイで)numpy やopenCv などをPythonから使っていますが、これらを『業務で使うシステム』としても利用しています。
もう一方で、ERP(生産管理システム)とか、経理、手配、在庫管理などの『業務システム』では使っていません。
> python(と言うかSciPyやpyVISA等)が必須です。
も、たぶん、量産型ではなく特化型(手作りで何年も熟成させて使うシステム)なんではないかと推測します。
user-key.
生産管理と呼べるレベルかどうかは置いといて、管理系はRoR+JAVAで作っています。
作った当時、PDF生成はJasperReportsを使うのが手っ取り早かったのとexcelのデータの読み書きはPOIしかなかったからなので。まるで「イノウーの憂鬱 (36) エゴイスト」のpythonをRoRにしてもらえばそのままやんと。
RoRのORMとtest環境が優秀すぎて思った以上に楽できました。
しかし、「コンパイル時にチェックを!」というのなら、なぜRustでしないの?
又テストファーストで作れば、動的静的も関係ないやんと思いますが。
ちゃとらん
user-key さん、コメントありがとうございます。
> 「コンパイル時にチェックを!」というのなら、なぜRustでしないの?
一言で言えば、すでにJavaで、開発環境が整ってしまっているから…としか言えません。
では、Rust を選ぶか? と言われると、ちょっと判りません。というのは、システム開発の分野って、優秀な人もいれば、どうなの? という人もいます。導入後のカスタマイズや保守もあります。なので、誰でも知ってて、開発者の人員確保も簡単な言語のほうが、都合が良いケースがあります。
逆に言えば、きちんと学習してもらって、後は仕組みで何とかするという考え方は、正しいアプローチだと思うので、アリと言えばアリかもしれません。
user-key.
まるで、昔のCOBOL屋さんの様だ。。。
という私はその昔、COBOL屋さん。
(今は強電屋さん)