見出し画像

Retro-gaming and so on

PythonはC言語から派生していない


C言語を覚えておけばPythonやRubyなどの様なC言語から派生した言語を覚えるのが容易です、またその逆も同じ

バカな事言ってんじゃねーよ。
PythonはC言語から派生なんかしていない。
どうしてこういうデタラメを書くのか。
思考回路が1990年代後半のそれである(当時、何でもかんでもC言語から派生した、って言えば良いような風潮があった・・・JavaやJavaScriptのせいである・笑)。
以前にもRubyがC言語系とか言ってる回答にツッコんだが、今度はPythonである。
はぁ・・・・・・。
ぶっちゃけ、Perl以降のRubyもPythonも「様々な言語の良いトコ取り」をある程度志向した設計になっている。C言語の影響も無いとは言わない。が殆どないだろう。むしろC言語の影響は僅かでしか無い。
計算機科学者のピーター・ノーヴィクはPythonに対して次のように言ってる

Python は Scheme の (よいライブラリをもった) 実用的なバージョンか、 ($@ や % がない) きれいなバージョンの Perl ととらえることができる。 

根底的な設計思想がどうあれ、この意見には個人的には賛成である。PythonがC言語の派生である、と言うようなトンデモ論よりゃよっぽどマシである。
いずれにせよ、イマドキそんなトンデモ論を打つ人間がいた事の方が驚きである。

まず、PythonがC言語の派生なんかでない最大の理由、つまり見た目から見てみようか。
Pythonはオフサイドルールを採用している。オフサイドルールとはインデントでブロック構造を記述する方式である。当然こんなのはC言語には存在しない。
ハッキリ言ってやろう。Pythonはどの言語の派生でもねぇが、一番影響を受けてるとすればマイナー言語であるABCの影響である。
ABCはオランダで開発されたプログラミング言語で、同じくオランダで開発された実験用OS、アメーバ上で駆動してたプログラミング言語だった。そして、それは同時にプログラミング言語教育を考慮した言語処理系であった。
ABCは開発上、プログラミング素人をサーヴェイしながら、だったわけだが、それにより一つの結果を得る。それはプログラミング初心者にはオフサイドルールが一番間違いを生じさせづらい、と言う事を。
そういう理由でABCはオフサイドルールを採用したわけだが、後にABCによるシステム開発にPythonの開発者であるグイド・ヴァン・ロッサムが合流する。そして、この期間でグイドはオフサイドルールの有効性を学び、「自身の休暇プロジェクト」として新言語設計を立ち上げた際に、オフサイドルールを採用するのである。そしてこれが後にPythonとなるのだ。

つまり、PythonはC言語の派生、なんつーとんでも無い話を出す以前に、まずはABCの存在を言及せねばならない。そしてABCを挙げる以上、C言語の出る隙なんざない。

じゃあ、PythonにとってC言語の影響は二番目に大きいのか、なんつーとそんな事もない。おそらく、二番目に影響が大きいのはLispである
Pythonの初期に大きく貢献した高階関数とラムダ式のコンビネーションはLispから借りてきたモノだ。

;; Scheme での例
> (map (lambda (n) (modulo n 2)) (iota 10 1))
'(1 0 1 0 1 0 1 0 1 0)
> (fold + 20 (iota 5 1))
35
> (fold * 20 (iota 5 1))
2400
> (filter (lambda (x) (> x 5)) '(7 4 2 10))
'(7 10)
>

# Python での例

>>> list(map(lambda n: n % 2, range(1, 11)))
[1, 0, 1, 0, 1, 0, 1, 0, 1, 0]
>>> from functools import reduce
>>> from operator import add, mul, sub
>>> reduce(add, range(1, 6), 20)
35
>>> reduce(mul, range(1, 6), 20)
2400
>>> list(filter(lambda x: x > 5, [7, 4, 2, 10]))
[7, 10]
>>>

いくつかの関数はPython3になってからイテラブルオブジェクトを返すようになったが、基本は同じである。と言うより、Lispの機能を借りてきていて、そしてこれらは単純にはC言語では真似出来ない。そしてそもそも、C言語では関数がファーストクラスオブジェクトではない。これを見てもPythonがC言語の派生だ、ってのはデタラメ以上に無理があるのである。

じゃあ、PythonにとってC言語の影響は三番目に大きいのか、なんつーとそんな事もない。おそらくPythonで三番目に影響が大きいのはHaskellである。みんな大好き、リスト内包表記と言う構文はHaskellから持ってきた機能である。これが便利すぎて、上で書かれたLisp由来の(reduce以外の)機能なんぞをout-of-datedにしてしまった。当然こんな強力な構文はC言語には存在しない

>>> [n % 2 for n in range(1, 11)]
[1, 0, 1, 0, 1, 0, 1, 0, 1, 0]
>>> [x for x in [7, 4, 2, 10] if x > 5]
[7, 10]
>>>

じゃあ、PythonにとってC言語の影響は四番目に大きいのか、なんつーとそんな事もない。おそらくPythonで四番目に影響が大きいのはIconと言うマイナー言語である。Pythonでの皆大好き、ジェネレータと言う機能はおそらくこの言語から借りてきている(Iconに関して言うと
Wikipediaに載ってるIconでのジェネレータの例としては次のようなコードが紹介されている。

procedure odd()
 x := 1
 repeat {
  suspend x
  x +:= 2
 }
end

これはPythonで書けば次のような感じである。

def odd():
 x = 1
  while True:
   yield x
         x += 2

パッと見はともかく構文的には殆ど同じだ、って事に気づくだろう。そう、PythonのジェネレータはIconのジェネレータの丸パクリ、って言って良い。
そしてWikipediaにも書かれてるように

for i in odd():
 print(i)

すれば永久に奇数を表示し続けるのだ

もう分かっただろう。Pythonの目玉機能を見てみればPythonはC言語の派生どころか、C言語の影響なんざ全く無い、って事を。そう、無いのだ。
辛うじてPython 2時代まではprintのフォーマット指示子がC言語の影響下にあった、って程度である。

>>> print "10進数では%d、16進数では%xです" % (30, 30)
10進数では30、16進数では1eです
>>>

しかしPython 3に入ってprintが関数化すると、この「C臭い書式設定」は推奨から外されてしまった。
今は次のように書いた方がイケてるのである。

>>> print("10進数では{0}、16進数では{1:x}です".format(30, 30))
10進数では30、16進数では1eです
>>

こうなると全然C言語の影響なんざ無くなった、って言って良い。
そもそも、Python2ではprintは構文であった。つまり、printfputsを関数として実装してるC言語より、文として実装してるPascalに近かったのである。
もうここまで来ると「PythonはC言語から派生」なんてのはジョークよりも悪質なデマとしか思えないだろ?
うん、そうなんだよ。
いずれにせよ、「PythonはC言語から派生した言語」なんつー質の悪いデタラメを信じないよーに。以上。

注: 「書式指定子」と呼ばれるブツ、つまり"%d"とか言うヤツは確かにC言語の影響が大きく、かなりの言語で見られる形式ではある。ただ、Python3はそこから離れようとしている。「皆が慣れている」形式ではあるが、ベストではないから、だ。Pythonはベストを模索していこうとしてるとは思う。
余談だが、"%d"とか"\n"とか言う形式が唯一と言うわけではない。例えばANSI Common Lispなんかでは

(format t "~A~%" 'hoge)

と言うように"~A"とか"~%"のように書式指定子を記述する。本来、言語によって形式が違うのだ。
ただ、同じLispでもSchemeなんかではC型の書式指定子を受け入れたりしてて、実際問題、「あるプログラミング言語の」と言うより主に使われているOSの影響が大きい、と言う言い方が出来る(性器正規表現との互換性等)。そしてSchemeはUNIX傘下としての受けてる影響が大きい言語なのだ。
と言うより、Schemeに限った話ではなく、プログラミング言語開発に於いては、WindowsよりUNIXと言う環境の影響が、現代ではものすごく大きいのである。
  • Xでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

最近の「プログラミング」カテゴリーもっと見る

最近の記事
バックナンバー
人気記事