ぶっちゃけ始めるのにいい言語て何 part3

[1 デフォルトの名無しさん 2020/09/03(木) 14:23:33.06 ID:Iw25SRBH]

前スレ
ぶっちゃけ始めるのにいい言語て何　part2
http://mevius.5ch.net/test/read.cgi/tech/1594883518/

[218 デフォルトの名無しさん 2020/10/14(水) 18:12:02.36 ID:Azmo5ss/]

Why Python is not the programming language of the future
Pythonが将来のプログラミング言語ではない理由
https://towardsdatascience.com/why-python-is-not-the-programming-language-of-the-future-30ddc5339b66

Python is Slowly Losing its Charm
Pythonはゆっくりとその魅力を失っています
https://towardsdatascience.com/python-is-slowly-losing-its-charm-9ca652726492

What are the main weaknesses of Python as a programming language?
プログラミング言語としてのPythonの主な弱点は何ですか？
https://www.quora.com/What-are-the-main-weaknesses-of-Python-as-a-programming-language

[219 デフォルトの名無しさん 2020/10/14(水) 18:27:02.26 ID:Azmo5ss/]

・Pythonには永続的なスコープの混乱があります。
私の知る限り、これはvan Rossumが最初は字句スコープを理解していなかったため、間違っていたためです。（これはPythonに固有の問題ではありません。初期バージョンのスクリプト言語ではかなり一般的なようです。）
元々、Pythonは動的にスコープされていましたが、RMS以外の誰もが間違っていることに同意します。
その後、動的スコープを廃止しましたが、内部スコープが外部スコープからの変数を認識できないようにしました。
これは、おそらくブロック構造化言語では奇妙なことです。
これで、内部スコープは外部スコープを見ることができますが、それらを変更することはできません。
これは、おそらくオブジェクト指向言語では奇妙なことです。
これは機能であると主張する人もいるかもしれませんが、それは実装の偶然です。
彼がそれを修正するとき、彼は何か他のものを壊すだろうと私は確信しています。

・David Parnasは、30年以上前に情報隠蔽を発明しましたが、それは「非Pythonic」であるため、PythonはおそらくFORTRAN2以降のプログラミングにおける最大の進歩を欠いています。

・eval アルファ等価性を破ります—つまり、変数の名前を任意に変更することはできません。
これは、一部の変数の出現が文字列に隠れて、Pythonのバインディング構造が決定不能になる可能性があるためです。

・Pythonは型指定されていません。
つまり、事前に簡単に検出できる大量のエラーは、発生するまでPythonでは検出されません。
一部の人々はそのやり方を好み—そして多くの労力を注ぎますが—
しかし、それが特定のアプリケーションにとって誤った機能であるかどうかを常に検討する価値があります。

[220 デフォルトの名無しさん 2020/10/14(水) 18:28:10.15 ID:Azmo5ss/]

・構文上の空白は便利ですが、コード生成が必要以上に難しくなります。
これは解決するのが難しい問題ではありません。
Haskellでは、構文上の空白、または中括弧とセミコロンを含む同等の構文を使用できます。
1つは人に、もう1つはメタプログラミングに適していますが、両方をサポートしない理由はありません。
人々がこれを要求したとき、Pythonの実装者がそれについて本当に気が狂っていたのは助けにはなりません。
（from __future__ import braces を試してみてください）

・lambdaの本体をステートメントではなく式に制限することは恣意的で面倒です。
変数の宣言と割り当てが式ではなくステートメントであるということは、恣意的で煩わしいことです。
ステートメント/式の区別は恣意的で煩わしいものです。

・「[ハッシュテーブル]は完全なデータ構造です。」
Pythonは、他のテーブルベースの言語と同様に、積和（代数的）データ型がより適切である多くのことに「マッピング」を使用することを勧めています。
これは非効率的ですが、さらに重要なことに、エラーが発生しやすくなります。
冒頭のPerlisの引用を続けると、「プログラマーは、彼らの創意工夫と論理によってではなく、彼らの事例分析の完全性によって評価されるべきです。」
Pythonが適切なデータ構造をサポートしていないため、ケース分析を隠すプログラム構造が促進されます。
訂正：Andrew Cookeは、名前付きタプル（http://docs.python.org/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields）がこの問題の一部に対処していると指摘しています。

そうは言っても、私はまだPHPよりもPythonを使用したいと思っています。
しかし、それは私がマクドナルドよりもジャック・イン・ザ・ボックスを食べたいと言っているようなものです。
少し味が良いかもしれませんが、それでもかなり悪いです。