[過去ﾛｸﾞ] 次世代言語12 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
518(1): 2018/07/31(火)15:00 ID:zoworXJJ(2/8) AAS
>>478
あのぅメソッドチェーンとは異なり、内包表記というのは
決して万能な道具ではないんですけど、ご存知ですか？
内包表記というのは、高階関数 map/filter とジェネレータという
三つの要素を簡潔に表現できる構文糖でしかありませんから、
内包表記では表現できない課題も数多く存在します
ですからたとえば Haskell では内包表記を提供する一方で、
ポイントフリーといふ関数を繋ぐ流れるようなスタイルでも書けます
つまり「メソッドチェーン vs. 内包表記」という対決の図式は成り立ちません
これでもまだ「リスト内包がわからんってわめき散らすの無知晒してるだけ」と
騒ぎたいなら、以下のお題(>>430-431)を内包表記だけで書いてみてください
'-'.join(map(lambda x: str(x), reversed(sorted(a))))
>>478氏が無知でなければ、内包表記でサラッとエレガントなコードを書けますよね？
ちなみに以下のような三重にカッコが入れ子になった醜いコードは勘弁してくださいね
'-'.join(str(x) for x in reveresed(sorted(a)))
519: 2018/07/31(火)15:33 ID:zoworXJJ(3/8) AAS
>>517
>n個の集合の直積を考える場合普通n=1は除外しない
ええ、それが Python 村の中では「普通」で常識なんですよね
でも Python 村から一歩外に出れば：
n個の集合の直積を考える、ここで n>=2
が「普通」なんですけど、ご存知でしたか？
たとえば手元の教科書(*1)だと、直積は以下のように定義されています
・２つの集合の直積 A × B = { <x, y> | x <- A, y <- B }
・３つの集合の直積 A × B × C = { <x, y, z> | x <- A, y <- B, z <- C }
・４つの集合の直積も同様に定義される
この本では n=1 は定義されていないし、個人としても定義のしようがないと考えます
で、ML/Haskell/Erlang/Prolog といったタプルというデータ構造が存在する言語でも、
「普通」n=1の直積を除外しており、これが世間の常識です
ちなみに「Python村の常識、世間の非常識」といふ格言、聞いたことありませぬか？
ところで、もちろん内包表記はご存知ですよね？
知らないと>>478氏に「無知晒してる」と嗤われちゃいますよ
*1：論理と計算のしくみ
外部ﾘﾝｸ:www.amazon.co.jp
520(1): 2018/07/31(火)16:01 ID:6M1+k6px(2/2) AAS
n=1もあるしn=0もある
n=0は直積の単位元いわゆるunit
直和の単位元はbottom
521(1): 2018/07/31(火)16:12 ID:zoworXJJ(4/8) AAS
>>520
>n=1もあるしn=0もある
>n=0は直積の単位元いわゆるunit
たしかに Python 村の中では、n=0 も除外しないのが「普通」ですね
で、静的型付け言語の ML/Haskell では単位型(unit)として定義され
タプル型とは明確に区別されていますし、動的型付け言語では
nil という特別なアトムで表現することが多く、これが世間の常識です
ちなみに「Python村の常識、世間の非常識」といふ格言、聞いたことありませぬか？
ところで、もちろん内包表記はご存知ですよね？
知らないと>>478氏に「無知晒してる」と嗤われちゃいますよ
522(1): 2018/07/31(火)17:08 ID:LX5aJa12(1) AAS
>>516
なんだか随分と力んでいるみたいだけれど
> それにもかかわらず Python では、単なる不変(immutable)な配列に対して
> 公式文書でこともあろうか「タプル」と命名し、驚くなかれ「1要素のタプル」
> といふ数学の概念を超越したリテラル構文を定義しちゃいました
> 世界的に普及している/していた言語は数多くありますが、こんな命名や
> リテラル定義が存在するのは、後にも先にも Python だけ、唯一無二の存在です
いや、そういうことを言い出せば同じ引数の値で呼び出しても返す値が同じになるとは限らないCなどの「関数」“function”は数学における関数の概念とは全く違う破廉恥極まりない命名だとなるよ
そもそも手続き型プログラミング言語やオブジェクト指向プログラミング言語での「変数」“variable”と呼ばれているものもも数学の変数とは全く異なる
（例えば、それらの言語で書かれたプログラムの検証を考えるとその問題があからさまになる）
つまりプログラミング言語での用語は数学の用語を借りて使ってはいるが数学でのその用語の表していた概念を尊重しているとは限らないということだ
そういう例、つまり数学用語を数学での概念を尊重しない形でプログラミング言語の世界で借用してしまっている例は探せばいくらでもあるだろう
523(1): 2018/07/31(火)17:40 ID:vAluDZRs(1) AAS
そもそも = が代入って時点で数学と違うんだから
いちいち「厳密な定義がー」いう方がどうかしてる。
524: 2018/07/31(火)17:55 ID:zfxDeDFf(1/4) AAS
普通にWikipediaでタプルをしらべたら一要素のタプルの事をシングルというと
書いてあるのだがｗｗｗ
525(1): 2018/07/31(火)18:08 ID:zoworXJJ(5/8) AAS
>>522
数学の定義や数式を計算機上で実行するには、
必然的に「解釈」という(あるいは「評価」とも呼ばれる)プロセスを伴いますから、
数学の概念とプログラミング言語との間に乖離(かいり)が存在するのは一般論ですし、
その為に計算機工学という分野で研究成果が積み重ねられてきました
もちろんこうした乖離は一般論ですから、例を探せばいくらでも挙げられるでしょう
たとえば「n個の直積を考える」場合に数学では n=1 や n=0 を除外しないモデルを
構築することは可能ですが(>>517,521)、計算機工学の研究成果を元に設計された
言語だと「n個の集合の直積を考える、ここで n>=2」が暗黙のうちに認知されています
（なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為）
ところが、こうした計算機工学の成果である n>=2 を無視し、
そんなのどうでもいいとばかりに「単なる不変な配列をタプルと命名する(>>516)」といふ
深淵の淵へ自ら飛び込んだ稀有な例が Python といふ次世代言語なんですよ
もしも「他のあらゆる言語では計算機工学の常識に沿って設計しているのに、
ある特定の言語ではそれを無視している」という具体例があれば、ご教示願います
たとえば「Python におけるタプルの命名」は、他の言語には見られない唯一無二の例です
526(1): 2018/07/31(火)18:21 ID:zfxDeDFf(2/4) AAS
A = { x | x <- A}
A × B = { <x, y> | x <- A, y <- B }
普通に定義できるがｗｗｗ
527: 2018/07/31(火)18:36 ID:zoworXJJ(6/8) AAS
>>478
>それはそれとしてPythonはもっと関数を横に繋げられるようにしてくれ
>Elixirのパイプ演算子みたいな感じでさあ
いや、新たにパイプ演算子みたいな構文を追加しなくても、
オブジェクト指向言語の Python であれば、メソッドチェーンで実現できるよ
だって、Python を除く今時のオブジェクト指向言語では実現できていますから
その具体例が >>430 のリンク先のブログ主様が書いた簡潔なライブラリです
問題は、「なぜこれをやろうとしないのか？」という点です
もちろんライブラリの後方互換性は失われますが、
python2 から python3 で致命的な「後方互換性の断絶」を断行したのが
Python ですから、一貫性のあるAPIを提供するライブラリへの刷新もできたはず
さらに根本原因にさかのぼれば、「なぜ最初から一貫性のあるAPIを設計しなかったのか」
といふ疑念に突き当たります
だって、Python を除く今時のオブジェクト指向言語では設計できていますから
最後に背景原因を考察すると、Python 作者のGuido氏が：
API の設計において一貫性などはクソ
と考えていたのか、それとも：
オブジェクト指向が流行っていたから行き当たりばったりに設計した、
今は後悔している
と考えているのか興味深い
528: 2018/07/31(火)18:45 ID:zoworXJJ(7/8) AAS
>>526
>A = { x | x <- A}
えぇとぉ、{ x | x <- A} というのは単に集合 A を内包的に定義してるだけですから、
それは「1個の集合Aから構成される直積」ではなく単に「単純集合A」を定義してるだけです
あぁそうか、フェイトニスタには内包表記うんぬん以前に、数学の教養が欠けているのですね
ついうっかりしておりまして、大変失礼をば致しますた
529: 2018/07/31(火)19:00 ID:zoworXJJ(8/8) AAS
うっかりミスを訂正：
>>525
X：>（なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為）
O：>（なぜなら n=1 または n=0 の直積は、一般的には形式的に定義できない為）
530: 2018/07/31(火)19:04 ID:zfxDeDFf(3/4) AAS
定義するのに集合と同じ定義では同じでは駄目というルールはないから間違っては無いｗｗｗ
ちなみにｎ=０の直積は１元集合として定義できるとWikipediaにかいてあるｗｗｗ
531: 2018/07/31(火)19:12 ID:x816LWzK(1) AAS
ウィキペに書いてあるとか言っちゃう人って・・・
532: 2018/07/31(火)19:36 ID:zfxDeDFf(4/4) AAS
正式な定義だと、直積の要素はペアの中にペアがある構造じゃないと駄目ｗｗｗ
A × B × C = { <x, y, z> | x <- A, y <- B, z <- C }
↑の定義があってるのは日本のWikipediaだっけでしたｗｗｗｗ
これを使うにはn-fold Cartesian productという直積を拡張した奴じゃないとだめでした残念ｗｗｗ
とくにｎ＝１の時はそのままA＝Aとちゃんとした本に書いてあるｗｗｗｗ
533: 2018/07/31(火)19:38 ID:xC1/ia91(1) AAS
今までの流れをまとめるとpythonはクソ。
TypeScriptが最強。という理解でよいでふか？
534: 2018/07/31(火)20:41 ID:CfkG900T(1/6) AAS
rustが最強
が正しい
535: 2018/07/31(火)21:51 ID:vpErkqT1(1/2) AAS
メソッドチェーンでもリスト内包でも異常なまでのテンポラリ変数嫌悪を感じるのだが、
無理にそんな書き方するくらいならテンポラリ変数使えや。
536: 2018/07/31(火)22:05 ID:CfkG900T(2/6) AAS
メソッドチェーンは無理なく書けるでしょ
変数はバグの餌だから忌諱するのは当然
537: 2018/07/31(火)22:09 ID:4i5flEMB(1) AAS
変数があって嬉しいのはデバッガでステップイン実行するときだけだな
そろそろステップの概念を卒業した新発想のデバッガが必要な時期にきてると思う
538: 2018/07/31(火)22:10 ID:/w6/tE8P(1) AAS
一時的な内部処理でまでステートを毛嫌いする純粋病の関数型信者と似ている
539(1): 2018/07/31(火)22:14 ID:hpcufxDD(1/2) AAS
お前らみたいなドカタなら兎も角、数学者がn=0やn=1に自然に拡張できる定義をn>=2に限定するわけないじゃん
ドカタここに極まれりだな
540(1): 2018/07/31(火)22:17 ID:10MH4XIN(1/3) AAS
メソッドチェーンってワンライナーと同類だろ
541(2): 2018/07/31(火)22:23 ID:CfkG900T(3/6) AAS
プログラマならバグの素を毛嫌いするのは当たり前じゃん
あくまでリーダビリティを損ねない範疇でだけども
542(1): 2018/07/31(火)22:24 ID:omk/SwPI(1/3) AAS
>>540
途中でクラスが変わるようなメソッド呼び出しを10個も20個もチェインするヤツは知らんが
コレクションに対する操作を数個チェインするぐらいは別に普通じゃね
543(1): 2018/07/31(火)22:27 ID:10MH4XIN(2/3) AAS
>>539
ちゃうやろおっさん
型理論的にはn>=2に拡張するために持ち出すのがpair
なのでn=0,1にpairを持ち出す必要がない
別の言い方をすると型理論的にはAと<A>は同じ
そこを区別するのがアドホックにpairを導入した言語ということ
組み込みの土方より
544(1): 2018/07/31(火)22:35 ID:omk/SwPI(2/3) AAS
>>541
たとえばコレクションのフィルター関数を実装するようなときに
一時的にミュータブルなコレクション作ってループ回して最後にイミュータブルにして返せばいいようなものを
最初の要素が条件満たさなかったらそれを落とした新しい不変コレクション作って返す関数の再帰で書くようなゴミが純粋病
545(1): 2018/07/31(火)22:37 ID:vpErkqT1(2/2) AAS
>>541
バグの元の一番大きなものは可読性のなさだぞ。
測りにくいものを一切無視するのがこの手の輩のダメなとこだな。
546: 2018/07/31(火)22:39 ID:CfkG900T(4/6) AAS
>>544
なにそれこわい
それってなんというテクニックなの？
547: 2018/07/31(火)22:39 ID:CfkG900T(5/6) AAS
>>545
だから可読性を損ねてはならないって書いてるじゃん
俺のレスは可読性低かったか？
上下前次1-新書関写板覧索設栞歴
あと 455 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.015s