次世代言語12 Go Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2018/07/04(水) 09:38:15.76

スレタイ以外の言語もok

前スレ
次世代言語11[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1528037607/

**デフォルトの名無しさん** · 2018/07/31(火) 13:56:56.90

>>504
たしかに、そのとおりです

たとえば数学でいう直積(direct product あるいは cartesian product)の
プログラミング言語上の表現を、一般的には「タプル」と呼んでいる
もちろん ML や Haskell に代表される厳格な型システムを前提に設計された
言語の代数的データ型を持ち出すまでもなく、直積と直和の概念は
計算における数学上の概念の中で基本中の基本です

それにもかかわらず Python では、単なる不変(immutable)な配列に対して
公式文書でこともあろうか「タプル」と命名し、驚くなかれ「1要素のタプル」
といふ数学の概念を超越したリテラル構文を定義しちゃいました
世界的に普及している/していた言語は数多くありますが、こんな命名や
リテラル定義が存在するのは、後にも先にも Python だけ、唯一無二の存在です

まさに Python の設計哲学とは；
　　スクリプト言語にとって数学なんてクソ
といふことなんでしょうね

**デフォルトの名無しさん** · 2018/07/31(火) 14:34:58.99

直積集合がタプルじゃなくて直積集合の要素がタプルな
んでもってn個の集合の直積を考える場合普通n=1は除外しない

**デフォルトの名無しさん** · 2018/07/31(火) 15:00:19.27

>>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)))

**デフォルトの名無しさん** · 2018/07/31(火) 15:33:57.86

>>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：論理と計算のしくみ
　　https://www.amazon.co.jp/dp/4000061917/

**デフォルトの名無しさん** · 2018/07/31(火) 16:01:29.91

n=1もあるしn=0もある
n=0は直積の単位元いわゆるunit
直和の単位元はbottom

**デフォルトの名無しさん** · 2018/07/31(火) 16:12:57.41

>>520
>n=1もあるしn=0もある
>n=0は直積の単位元いわゆるunit

たしかに Python 村の中では、n=0 も除外しないのが「普通」ですね

で、静的型付け言語の ML/Haskell では単位型(unit)として定義され
タプル型とは明確に区別されていますし、動的型付け言語では
nil という特別なアトムで表現することが多く、これが世間の常識です
ちなみに「Python村の常識、世間の非常識」といふ格言、聞いたことありませぬか？

ところで、もちろん内包表記はご存知ですよね？
知らないと>>478氏に「無知晒してる」と嗤われちゃいますよ

**デフォルトの名無しさん** · 2018/07/31(火) 17:08:51.40

>>516
なんだか随分と力んでいるみたいだけれど

> それにもかかわらず Python では、単なる不変(immutable)な配列に対して
> 公式文書でこともあろうか「タプル」と命名し、驚くなかれ「1要素のタプル」
> といふ数学の概念を超越したリテラル構文を定義しちゃいました
> 世界的に普及している/していた言語は数多くありますが、こんな命名や
> リテラル定義が存在するのは、後にも先にも Python だけ、唯一無二の存在です

いや、そういうことを言い出せば同じ引数の値で呼び出しても返す値が同じになるとは限らないCなどの「関数」“function”は数学における関数の概念とは全く違う破廉恥極まりない命名だとなるよ
そもそも手続き型プログラミング言語やオブジェクト指向プログラミング言語での「変数」“variable”と呼ばれているものもも数学の変数とは全く異なる
（例えば、それらの言語で書かれたプログラムの検証を考えるとその問題があからさまになる）

つまりプログラミング言語での用語は数学の用語を借りて使ってはいるが数学でのその用語の表していた概念を尊重しているとは限らないということだ
そういう例、つまり数学用語を数学での概念を尊重しない形でプログラミング言語の世界で借用してしまっている例は探せばいくらでもあるだろう

**デフォルトの名無しさん** · 2018/07/31(火) 17:40:46.67

そもそも = が代入って時点で数学と違うんだから
いちいち「厳密な定義がー」いう方がどうかしてる。

**デフォルトの名無しさん** · 2018/07/31(火) 17:55:08.00

普通にWikipediaでタプルをしらべたら一要素のタプルの事をシングルというと
書いてあるのだがｗｗｗ

**デフォルトの名無しさん** · 2018/07/31(火) 18:08:24.59

>>522
数学の定義や数式を計算機上で実行するには、
必然的に「解釈」という(あるいは「評価」とも呼ばれる)プロセスを伴いますから、
数学の概念とプログラミング言語との間に乖離(かいり)が存在するのは一般論ですし、
その為に計算機工学という分野で研究成果が積み重ねられてきました

もちろんこうした乖離は一般論ですから、例を探せばいくらでも挙げられるでしょう
たとえば「n個の直積を考える」場合に数学では n=1 や n=0 を除外しないモデルを
構築することは可能ですが(>>517,521)、計算機工学の研究成果を元に設計された
言語だと「n個の集合の直積を考える、ここで n>=2」が暗黙のうちに認知されています
（なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為）

ところが、こうした計算機工学の成果である n>=2 を無視し、
そんなのどうでもいいとばかりに「単なる不変な配列をタプルと命名する(>>516)」といふ
深淵の淵へ自ら飛び込んだ稀有な例が Python といふ次世代言語なんですよ

もしも「他のあらゆる言語では計算機工学の常識に沿って設計しているのに、
ある特定の言語ではそれを無視している」という具体例があれば、ご教示願います
たとえば「Python におけるタプルの命名」は、他の言語には見られない唯一無二の例です

**デフォルトの名無しさん** · 2018/07/31(火) 18:21:46.76

A = { x | x <- A}
A × B = { <x, y> | x <- A, y <- B }
普通に定義できるがｗｗｗ

**デフォルトの名無しさん** · 2018/07/31(火) 18:36:17.24

>>478
>それはそれとしてPythonはもっと関数を横に繋げられるようにしてくれ
>Elixirのパイプ演算子みたいな感じでさあ

いや、新たにパイプ演算子みたいな構文を追加しなくても、
オブジェクト指向言語の Python であれば、メソッドチェーンで実現できるよ
だって、Python を除く今時のオブジェクト指向言語では実現できていますから
その具体例が >>430 のリンク先のブログ主様が書いた簡潔なライブラリです

問題は、「なぜこれをやろうとしないのか？」という点です
もちろんライブラリの後方互換性は失われますが、
python2 から python3 で致命的な「後方互換性の断絶」を断行したのが
Python ですから、一貫性のあるAPIを提供するライブラリへの刷新もできたはず

さらに根本原因にさかのぼれば、「なぜ最初から一貫性のあるAPIを設計しなかったのか」
といふ疑念に突き当たります
だって、Python を除く今時のオブジェクト指向言語では設計できていますから

最後に背景原因を考察すると、Python 作者のGuido氏が：
　　API の設計において一貫性などはクソ
と考えていたのか、それとも：
　　オブジェクト指向が流行っていたから行き当たりばったりに設計した、
　　今は後悔している
と考えているのか興味深い

**デフォルトの名無しさん** · 2018/07/31(火) 18:45:34.71

>>526
>A = { x | x <- A}

えぇとぉ、{ x | x <- A} というのは単に集合 A を内包的に定義してるだけですから、
それは「1個の集合Aから構成される直積」ではなく単に「単純集合A」を定義してるだけです

あぁそうか、フェイトニスタには内包表記うんぬん以前に、数学の教養が欠けているのですね
ついうっかりしておりまして、大変失礼をば致しますた

**デフォルトの名無しさん** · 2018/07/31(火) 19:00:43.13

うっかりミスを訂正：
　　>>525
　　X：>（なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為）
　　O：>（なぜなら n=1 または n=0 の直積は、一般的には形式的に定義できない為）

**デフォルトの名無しさん** · 2018/07/31(火) 19:04:21.79

定義するのに集合と同じ定義では同じでは駄目というルールはないから間違っては無いｗｗｗ
ちなみにｎ=０の直積は１元集合として定義できるとWikipediaにかいてあるｗｗｗ

**デフォルトの名無しさん** · 2018/07/31(火) 19:12:42.47

ウィキペに書いてあるとか言っちゃう人って・・・

**デフォルトの名無しさん** · 2018/07/31(火) 19:36:15.75

正式な定義だと、直積の要素はペアの中にペアがある構造じゃないと駄目ｗｗｗ
A × B × C = { <x, y, z> | x <- A, y <- B, z <- C }
↑の定義があってるのは日本のWikipediaだっけでしたｗｗｗｗ
これを使うにはn-fold Cartesian productという直積を拡張した奴じゃないとだめでした残念ｗｗｗ
とくにｎ＝１の時はそのままA＝Aとちゃんとした本に書いてあるｗｗｗｗ

**デフォルトの名無しさん** · 2018/07/31(火) 19:38:51.12

今までの流れをまとめるとpythonはクソ。
TypeScriptが最強。という理解でよいでふか？

**デフォルトの名無しさん** · 2018/07/31(火) 20:41:56.45

rustが最強
が正しい

**デフォルトの名無しさん** · 2018/07/31(火) 21:51:57.40

メソッドチェーンでもリスト内包でも異常なまでのテンポラリ変数嫌悪を感じるのだが、
無理にそんな書き方するくらいならテンポラリ変数使えや。

**デフォルトの名無しさん** · 2018/07/31(火) 22:05:54.62

メソッドチェーンは無理なく書けるでしょ
変数はバグの餌だから忌諱するのは当然

**デフォルトの名無しさん** · 2018/07/31(火) 22:09:04.65

変数があって嬉しいのはデバッガでステップイン実行するときだけだな
そろそろステップの概念を卒業した新発想のデバッガが必要な時期にきてると思う

**デフォルトの名無しさん** · 2018/07/31(火) 22:10:09.78

一時的な内部処理でまでステートを毛嫌いする純粋病の関数型信者と似ている

**デフォルトの名無しさん** · 2018/07/31(火) 22:14:45.36

お前らみたいなドカタなら兎も角、数学者がn=0やn=1に自然に拡張できる定義をn>=2に限定するわけないじゃん
ドカタここに極まれりだな

**デフォルトの名無しさん** · 2018/07/31(火) 22:17:04.70

メソッドチェーンってワンライナーと同類だろ

**デフォルトの名無しさん** · 2018/07/31(火) 22:23:11.93

プログラマならバグの素を毛嫌いするのは当たり前じゃん
あくまでリーダビリティを損ねない範疇でだけども

**デフォルトの名無しさん** · 2018/07/31(火) 22:24:35.12

>>540
途中でクラスが変わるようなメソッド呼び出しを10個も20個もチェインするヤツは知らんが
コレクションに対する操作を数個チェインするぐらいは別に普通じゃね

**デフォルトの名無しさん** · 2018/07/31(火) 22:27:24.42

>>539
ちゃうやろおっさん
型理論的にはn>=2に拡張するために持ち出すのがpair
なのでn=0,1にpairを持ち出す必要がない
別の言い方をすると型理論的にはAと<A>は同じ
そこを区別するのがアドホックにpairを導入した言語ということ
組み込みの土方より

**デフォルトの名無しさん** · 2018/07/31(火) 22:35:12.06

>>541
たとえばコレクションのフィルター関数を実装するようなときに
一時的にミュータブルなコレクション作ってループ回して最後にイミュータブルにして返せばいいようなものを
最初の要素が条件満たさなかったらそれを落とした新しい不変コレクション作って返す関数の再帰で書くようなゴミが純粋病

**デフォルトの名無しさん** · 2018/07/31(火) 22:37:48.27

>>541
バグの元の一番大きなものは可読性のなさだぞ。
測りにくいものを一切無視するのがこの手の輩のダメなとこだな。

**デフォルトの名無しさん** · 2018/07/31(火) 22:39:01.83

>>544
なにそれこわい
それってなんというテクニックなの？

**デフォルトの名無しさん** · 2018/07/31(火) 22:39:55.17

>>545
だから可読性を損ねてはならないって書いてるじゃん
俺のレスは可読性低かったか？

**デフォルトの名無しさん** · 2018/07/31(火) 22:43:24.72

>>542
コレクションの操作ってのが具体的にどういうのかしらんけど
(おもちゃのような例は勘弁)
初見のコードだと返り値が何なのか副作用のありなしもよくわかんないのが嫌い
組み込み屋なんでそういうのに神経質なんですわ

**デフォルトの名無しさん** · 2018/07/31(火) 22:46:40.79

>>543
お前みたいなドカタには同じに見えるんだろうけど
違うものだよ

**デフォルトの名無しさん** · 2018/07/31(火) 22:58:39.97

>>548
おもちゃのような例とやらがなんだか知らんが
「配列にフィルタかけてマップしてソート」みたいなのはメソッドチェインで書くのが普通だし
プロダクトコードで頻出するし
言語組み込みとか標準ライブラリの範囲なので仕様知らないのは知らないほうが悪いで終了

**デフォルトの名無しさん** · 2018/07/31(火) 23:33:40.73

組み込み屋だからコードが読めないって言い分が通用するのか

**デフォルトの名無しさん** · 2018/08/01(水) 03:26:51.13

b=a.filter(hoge).sort(piyo)はaが変化しないけど
b=a.sort(piyo).filter(hoge)はaが変化するJavaScriptとかもあるし
気持ちがわからんでもない

**デフォルトの名無しさん** · 2018/08/01(水) 04:53:24.11

メソチェ嫌い

**デフォルトの名無しさん** · 2018/08/01(水) 05:46:47.82

c=a
b=a.sort(piyo).filter(hoge)
a=c

**デフォルトの名無しさん** · 2018/08/01(水) 06:24:23.31

jsのsortはソート結果を戻り値でも返すからよくないんだよね
rustは関数が破壊的な操作をするか一目で分かってよいんだよね

**デフォルトの名無しさん** · 2018/08/01(水) 07:33:14.80

関数の副作用や純粋性が気になるなら
関数型の言語さわるのも良いぞ

F#は宗教論争に発展せず
現場でも実用十分的

**デフォルトの名無しさん** · 2018/08/01(水) 08:04:53.43

>>552
マジかー。副作用あるかないかわかるようにしてほしいわ

**デフォルトの名無しさん** · 2018/08/01(水) 08:39:51.67

JavaScriptはうんこだから仕方ない

**デフォルトの名無しさん** · 2018/08/01(水) 08:54:45.09

>>550
> 言語組み込みとか標準ライブラリの範囲なので仕様知らないのは知らないほうが悪いで終了

なんでそこで特定の言語前提になってんの？w
標準の範囲なら百歩譲ってありだけど標準だけのデザインという保証はないやろ普通
あといちいちAPIリファレンスで確認しないと使えないってのは言語の可読性低いとも言えるわ

**デフォルトの名無しさん** · 2018/08/01(水) 09:19:02.07

ドキュメント読まずにコード書くプログラマー降誕

**デフォルトの名無しさん** · 2018/08/01(水) 09:29:11.08

批評家が口だけで問題解決することを理想としているように
可読性は目だけで解決するのが理想的である

**デフォルトの名無しさん** · 2018/08/01(水) 10:27:41.74

そしてハンガリアン記法が産まれた

**デフォルトの名無しさん** · 2018/08/01(水) 10:54:20.08

>>559
土方は古代言語をメモ帳で書いてるのか……

写像や部分集合、ソートなんぞはほとんどの言語で標準で用意されてるし
IDEなりプラグイン入れたエディタならリファレンスはマウスオーバーするかショートカット叩くだけだよ

**デフォルトの名無しさん** · 2018/08/01(水) 11:14:28.61

やっぱりCOBOLなんだよなあ

**デフォルトの名無しさん** · 2018/08/01(水) 22:15:44.23

>>523
> そもそも = が代入って時点で数学と違うんだから

それは単なる記法上の問題であって本質じゃない

C一族みたいないい加減な言語でなくAlgolやPascalのなどの正統派Algol系言語のように代入を表す記号を “:=” で書く言語であっても変数の概念が数学のそれと全く違うという問題はCなどでの変数と同じ
見掛け上の記号の使い方がいい加減という問題と、ある用語で表される概念がいい加減（間違っている）という問題とはレベルが全く違う

**デフォルトの名無しさん** · 2018/08/01(水) 22:27:10.95

それが何レベルなのか知らんけどどうでもいいじゃん
数学とプログラミングは別物なんだし

**デフォルトの名無しさん** · 2018/08/01(水) 22:44:31.92

>>565
タプルがどうとかも十分同じレベルだろ。
そんなところで誤解して問題起こす奴なんて代入以上にいねーわ。
自分の理解の都合でイチャモンつけてるだけってことにそろそろ気づけや。

**デフォルトの名無しさん** · 2018/08/01(水) 23:08:34.73

>>554
c=aではオブジェクトは作られないので、そうやってもaは変化する

更に言うと
c=a
b=c.sort(piyo).filter(hoge)
でaが変化する

**デフォルトの名無しさん** · 2018/08/02(木) 00:36:50.69

こういう話を見ると言語としてイミュータブルな変数しかない言語が良い気がしてくる。

**デフォルトの名無しさん** · 2018/08/02(木) 03:06:06.93

「いふ」とか言っちゃうイタイ奴にろくなのはいないな

**デフォルトの名無しさん** · 2018/08/02(木) 03:23:08.65

>>518
いつ誰が「メソッドチェーン vs 内包表記」なんて下らん比較したんだよ

内包表記は内包表記で便利だっつっただけで、
メソッドチェーンつーかポイントフリースタイルが内包表記があれば不要なんて言った記憶は少なくとも俺にはないな

つーか>>478下段、まさにPythonにはポイントフリースタイル実現する記法が足りねえっつってんのが読み取れねえのか？

今時エセ歴史的仮名遣いで書き込むクルクルパーは国語の勉強しなおした方がいいぞ

**デフォルトの名無しさん** · 2018/08/02(木) 03:24:30.81

ずっと数学言ってるやついい加減うぜえわ
別スレ立ててそっちでやれやボケが

**デフォルトの名無しさん** · 2018/08/02(木) 06:18:26.62

JavaScriptのsortとreverseが破壊的なのがぱっと見わからないのも、
JavaScriptの命名規則がうんこなだけでメソッドチェーン自体の良し悪しとは関係ない

**デフォルトの名無しさん** · 2018/08/02(木) 06:58:50.64

関数合成大好きな関数型バカがメソッドチェーン腐すの、マジ笑えるww

**デフォルトの名無しさん** · 2018/08/02(木) 08:25:49.67

>>573
こればっかりはなぁ。後発の言語は、副作用有無が明示されるようになってほしい。命名規則とか人間が頑張るタイプはやめて

**デフォルトの名無しさん** · 2018/08/02(木) 09:00:45.23

やはりRustだな

**デフォルトの名無しさん** · 2018/08/02(木) 09:09:27.15

webサービス作るとき。というかrdbとの連携って静的言語より動的言語のほうが向いてる気がするんだけど、そんなことはない？

**デフォルトの名無しさん** · 2018/08/02(木) 13:33:10.21

そんなことなかっぺ

**デフォルトの名無しさん** · 2018/08/02(木) 21:52:10.29

TypeScriptは事実上死んだだろ

**デフォルトの名無しさん** · 2018/08/02(木) 21:54:23.55

>>579
>>513

**デフォルトの名無しさん** · 2018/08/02(木) 21:55:36.74

>>579
新しいのが出たんだが

**デフォルトの名無しさん** · 2018/08/02(木) 22:57:15.05

typescriptなしにjavascriptを書こうとは思わないからな

**デフォルトの名無しさん** · 2018/08/02(木) 23:26:38.99

頑なに副作用嫌ってる人意味分からん
java.awt.Graphics2Dとかにあるような
コンテクストオブジェクトをイジイジするのってめちゃ便利やんけ

**デフォルトの名無しさん** · 2018/08/02(木) 23:45:39.47

>>575
バカは引数のconst外してでも副作用入れてくるから言語で規制するって発想自体が無駄。

**デフォルトの名無しさん** · 2018/08/02(木) 23:58:42.08

1行に書かなきゃどんどん一時変数を増やさなきゃならない関数パイプラインはそれなりに意義が
あると思うけど、そうじゃないメソッドチェインはわざわざ見にくい1行の式にしなくても、と思う。

**デフォルトの名無しさん** · 2018/08/03(金) 01:33:05.65

とはいえtypescriptは型情報が嘘つくことあるのがしんどい。ないよりはマシなんだけど。
いまいち信用できない。
jsに、標準で型情報ついてくれないかなー。

**デフォルトの名無しさん** · 2018/08/03(金) 04:43:38.64

ESの付け焼き刃的実装に限界があるでしょ

**デフォルトの名無しさん** · 2018/08/03(金) 06:06:54.20

嘘つき「何も宣言しないよりはマシ」
付け焼刃「何もしないよりはマシ」
ギャンブル依存症「何も賭けないよりはマシ」

**デフォルトの名無しさん** · 2018/08/03(金) 10:32:16.64

所詮MSの作った詐欺言語だわな

**デフォルトの名無しさん** · 2018/08/03(金) 10:34:43.31

>>390
の徹底を求めます

**デフォルトの名無しさん** · 2018/08/03(金) 10:46:59.25

TypeScriptはもうデファクトスタンダードなのよね

**デフォルトの名無しさん** · 2018/08/03(金) 11:49:14.47

>>590
病的になんだか拗らせてるのかな

**デフォルトの名無しさん** · 2018/08/03(金) 14:13:45.54

なぜ病気とか健康とかなんですか
悪とか正義とかではだめなんですか

**デフォルトの名無しさん** · 2018/08/03(金) 14:37:25.10

Linus氏曰く「マイクロソフト嫌悪は『病気』」
https://srad.jp/story/09/07/28/0326208/

**デフォルトの名無しさん** · 2018/08/03(金) 15:01:39.29

病人は生産性がないなんて言ったらたぶん炎上するし
悪人は生産性がないと言う方が無難だと思うけどなあ

**デフォルトの名無しさん** · 2018/08/03(金) 21:26:18.77

生産性がないならまだいいが生産性がマイナスな輩というのがいる。
こういう輩を見るとベイシックインカムはいいんじゃないかと本気で思うよ。

**デフォルトの名無しさん** · 2018/08/03(金) 22:58:37.04

>>586
嘘って？

**デフォルトの名無しさん** · 2018/08/04(土) 10:28:43.19

やっぱ副作のないメソチェが最高やろ
リス内記は読つら

**デフォルトの名無しさん** · 2018/08/04(土) 10:30:16.07

>>597
それは愛だよ

**デフォルトの名無しさん** · 2018/08/04(土) 10:58:41.10

初心者用の言語は上級者の要求を満たすことが出来ないということだな。
上級者が初心者用の言語使うのが間違ってるな。
haskellを使えば副作用を分離出来るし、メソッドチェーンも出来るし、
直積のタプルも0次元からN次元まで使えるし（1次元は普通の集合）
解決だな。

**デフォルトの名無しさん** · 2018/08/04(土) 11:18:31.48

ハスルケはセパレイタとしての記号が少ないからリイダビリティが悪い
そして誰もいなくなっただろう

**デフォルトの名無しさん** · 2018/08/04(土) 12:29:28.79

Haskellはタプルを使わなくてもコンストラクタのアリティを2以上にできる
多変数コンストラクタの具体例のひとつにすぎないのがHaskellのタプル
1変数コンストラクタも無数にある
だから a と (a,) が同じ型にならないPythonを見ても違和感はない

**デフォルトの名無しさん** · 2018/08/04(土) 14:55:00.60

>>601
オレオレ略語とか変なカタカナ表記とか、お前さんのレスもreadability低いぞ

**デフォルトの名無しさん** · 2018/08/04(土) 16:06:26.17

>>603
これが通なんだよなあ

**デフォルトの名無しさん** · 2018/08/04(土) 18:12:45.89

ナウいハスルカー来たな

**デフォルトの名無しさん** · 2018/08/06(月) 14:41:08.25

>>598
だからなんでリスト内包vsメソッドチェーンの対立になってんだよ

**デフォルトの名無しさん** · 2018/08/06(月) 16:48:04.88

ハスケルはエコシステムが腐ってるという話を聞いたけど本当？
言語がいくらすごくても環境構築で、しんどい思いするなら用無しなんですが

**デフォルトの名無しさん** · 2018/08/06(月) 16:59:19.53

改善されたことになっているが正直クソ

**デフォルトの名無しさん** · 2018/08/06(月) 17:02:40.30

理論ばかりの頭でっかちの奴等ばっかりだからな。
実用性なんかどうでもいいんだろ。
だから実用されないんだよｗ

**デフォルトの名無しさん** · 2018/08/06(月) 19:32:00.71

>>607
パッケージ管理ツールのcabalもstackも依存把握がすぐぶっ壊れる。
あれは何が副作用がないからバグが少ないだって気分になるわ。

**デフォルトの名無しさん** · 2018/08/06(月) 21:10:23.18

1. 関数プログラミング自体が実は大したことない
2. 副作用禁止の強制が邪魔
3. 使ってるプログラマーのレベルが低い(偏屈しか使わない・ユーザー層が薄い)
4. まだ成熟していないだけ

どうだろう。4だと思いたいが…

**デフォルトの名無しさん** · 2018/08/06(月) 21:20:23.85

・Web系→モデルやロジックが単純なので関数型のメリットなし
・ゲーム系→常に時間変化を扱うので関数型のメリットなし
・業務系→PGの単価が上がって割に合わないので関数型のメリットなし

**デフォルトの名無しさん** · 2018/08/06(月) 21:28:53.61

関数型の定義が未だに分からない
2だけならどの言語でも原則として受け入れられているんじゃないの

**デフォルトの名無しさん** · 2018/08/06(月) 21:45:44.03

関数型はテストするまでもなく結果の明らかな極めて宣言性の高いコーディングができるというのが実用上最大の強みなわけだけど、
関数型マニアの関心は主に無限リストやら再帰やらモナドやら、自らその宣言性を捨てるテクニックにばかり向いていて、
結局関数型の何が嬉しいのかよくわからん状態になってしまってるのが現状

**デフォルトの名無しさん** · 2018/08/06(月) 21:58:21.43

具体的にはどんなコードになるの？
そんな単純なコードの断片だけを組み合わせるだけで実用に耐えうる可読性や性能を発揮できるもんなの？