次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/06/13(火) 08:54:07.99

いざ、語ろうぞ。

スレタイ超過のため、一部省略。
その他もウェルカム。

前スレ
次世代言語議論スレ[Go Rust Kotlin Scala]第4世代
http://mevius.2ch.net/test/read.cgi/tech/1492631007/

**デフォルトの名無しさん** · 2017/06/13(火) 09:00:09.39

よく話題にあがる言語
Go, Rust, Scala, Haskell, kotlin, Erlang

対象言語のどこがクソかでなく、どこが次世代かで語りましょう

🙅 Rustはコンパイルが通らないからクソ！
🙆 Goは学習コストが低い！

**デフォルトの名無しさん** · 2017/06/13(火) 09:31:03.24

標準的なライブラリは言語の持つ重要な文化の一つだ
Pythonが機械学習で天下を取った理由にはNumpyが大きく寄与している
データ構造としてNumpyを使えば他の大抵のライブラリと連携を取れる。例えば、TheanoやChainerで機械学習して、結果をそのままNumpyで加工してmatplotlibで出力できる。
だからPythonは機械学習分野で流行した。この裏にはNumpyのもつ大きな文化が存在する
言語の持つ文化と流行には密接な関係があるだろう

**デフォルトの名無しさん** · 2017/06/13(火) 09:38:21.87

最近4.1出たのにもはや誰も話題にしないF#くんかわいそう

**デフォルトの名無しさん** · 2017/06/13(火) 09:45:32.13

F#くん言語仕様は悪くないけど使い所がわからん

**デフォルトの名無しさん** · 2017/06/13(火) 10:05:00.47

>>4
俺は普通にプロダクションのコードでF#書いてるよ

あ · 2017/06/13(火) 10:29:07.84

おお、お疲れ様。
そこまでアンチってわけでも無いがな。
手当り次第中途半端に取り込んだc#がそこそこ実用言語になってんのに、何やってんのあいつらって感じだけど。
どーせ入ったし、逆に最近のHaskellの良さをもっと教えて欲しい。

**デフォルトの名無しさん** · 2017/06/13(火) 10:36:45.13

Pythonの標準的文化って
JavaとC#とaltjsとスマホを完璧に無視したからできたんだよな

**デフォルトの名無しさん** · 2017/06/13(火) 10:49:04.84

>>7
型の強力さと遅延評価のクソさを身をもって示したリファレンスって点は評価ポイントだと思う
あとは実用にはならんかったがdarcsというVCSを世に放ったこと

**デフォルトの名無しさん** · 2017/06/13(火) 10:50:40.06

個人的には、OS標準の開発言語が一番使いやすいって結論になった

**デフォルトの名無しさん** · 2017/06/13(火) 10:52:36.27

>>3
Juliaが生きるか死ぬかはNumPyとどう住み分けるかにかかってるだろうな

**デフォルトの名無しさん** · 2017/06/13(火) 11:34:29.62

>>10
OS標準の開発言語はOSと文化を共有しているからな
マルチプラットフォームを視野に入れないなら最良の言語だと思うわ

**デフォルトの名無しさん** · 2017/06/13(火) 11:41:51.61

OS標準てLinux=C, Windows=C++/C#, Mac/iOS=ObjC/Swift, Android=Java/Kotlin・・・こんな感じ？

**デフォルトの名無しさん** · 2017/06/13(火) 11:49:00.99

Cは基本的にいい言語だけどラムダとクロージャがない所だけはどうにもならん。でもそれ以外は本当にいい言語だと思う

**デフォルトの名無しさん** · 2017/06/13(火) 12:13:37.35

サードライブラリ管理が野良orOSのパッケージ管理依存の二択なとこも駄目というかここが致命的では

**デフォルトの名無しさん** · 2017/06/13(火) 12:26:01.51

Goが2.0とかでジェネリクス入ったら、決着しそうじゃない？

**デフォルトの名無しさん** · 2017/06/13(火) 13:00:17.07

Rustはトレイト境界の特殊化に束理論適用できるようになったら次世代っぽくなるか？
今はただの気難しい言語って感じで次世代感が薄い

**デフォルトの名無しさん** · 2017/06/13(火) 13:06:59.02

>>17
自分で言っといてなんだがないな
ボイラープレートコード増えすぎてJavaの二の舞だわ

**デフォルトの名無しさん** · 2017/06/13(火) 17:58:36.02

Goはいらん
ScalaとKotlinはどっちかだけでいいけどKotlinが後発だからKotlinでいい希ガス
TypeScriptは実用的だけど次世代化と言われると微妙
Rustは他の言語にない機能多いから次世代

**デフォルトの名無しさん** · 2017/06/13(火) 18:04:11.72

>>15
それってCのこと？ Cは一切隠蔽しない文化だから、パッケージ管理ソフトとかの隠蔽してしまうものは基本的に相性悪いと思う。Cを書く者はライブラリも自分でMake installするし、インストール場所も自分で指定するから全貌の把握を邪魔するものはないって感じ。
裏を返せば全貌を把握できないと何も出来ないという事も言えるけど。
そういう文化の言語としてはCって完成度高いと思うし、現状超えるものはないと思う。まあ、Cで応用寄りのプログラム書くのは嫌なんだけどさ

**デフォルトの名無しさん** · 2017/06/13(火) 18:22:10.72

>>19
KotlinとTypeScriptにはほとんど差はないだろ
どっちもC#フォロワーだから、機能的には既に十分メジャーであるという意味ではどちらも次世代とは言えない

**デフォルトの名無しさん** · 2017/06/13(火) 18:52:45.36

Kotlinはあまり興味がなかった他の言語と違う何かがあるなあ、自分にとっては

**デフォルトの名無しさん** · 2017/06/13(火) 19:06:12.09

俺の母ちゃんのあだ名コトリンなんだが

**デフォルトの名無しさん** · 2017/06/13(火) 19:35:55.51

>>20
何のためにdebやrpmに「foobar-dev(el)」ってパッケージがあると思ってる
言語自前のライブラリ管理システムがないからディストリビューションのパッケージ管理に乗っからないとやってけないからだろ

そういうものをCプログラミングと認めないなら好きにしろ

**デフォルトの名無しさん** · 2017/06/13(火) 19:41:20.40

そういや、まともな検証プロセスの無いままライブラリが提供される
言語独自のパッケージ管理システムは、OS全体の安全性を脅かしてるってDebianの中の人が嘆いてたな

**デフォルトの名無しさん** · 2017/06/13(火) 19:41:27.69

別に全手動を否定するつもりはないが、
debやrpmが積み上げてきたものを蹴飛ばして
全手動こそがCって言われると違和感があるって話な

**デフォルトの名無しさん** · 2017/06/13(火) 19:51:19.56

>>25
npm pip gem辺りはひどそうだ
goはシステムとは完全にパス分けてる
cargoはどうだっけ？

**デフォルトの名無しさん** · 2017/06/13(火) 19:53:36.19

ソースコードを読む人は時間の感覚が違うだろ
インストールに1日かかっても1日損したと思ってない
自分で書くより早いから得してるし
読むだけでも1日や2日では終わらない

**デフォルトの名無しさん** · 2017/06/13(火) 20:32:10.33

>>24
「ライブラリが野良orOS配布だから良くない」という意見に「それは別に良い」って言ってるだけやん。ちょっと言葉は過ぎたかもしらんけどそんな噛み付かんといてよ

**デフォルトの名無しさん** · 2017/06/13(火) 22:35:13.45

環境含めて考えれば
簡易な言語 + チェックツール
のが正解な気はする。
rust みたいに言語で縛るってのがそもそも間違いじゃねーの。

**デフォルトの名無しさん** · 2017/06/13(火) 22:41:55.07

>>30
より安全なC言語（チェッカーだったり、標準ライブラリの置換だったり）って今までたくさんあったけど、どれも普及しなかった
Microsoftも作ってたはず

なので、Rustは今度こそは！感がある

**デフォルトの名無しさん** · 2017/06/13(火) 22:52:41.30

>>29
言葉きつかったなすまん

あ · 2017/06/14(水) 13:01:02.27

>>24
何のためにって、そりゃ、ソースを検証せず、各配布元見てアーカイブのハッシュも見ず、
正しいとコミュニティが認めたものをコミュニティへの無限の信頼で横着して手に入れるためにじゃん。
現実的だけど。
>>30
チェックツールを実用レベルまで持ってくと、言語への縛りが結局キツくなるよ。
停止性問題みたいな話になってくる。

**デフォルトの名無しさん** · 2017/06/14(水) 14:06:06.69

Cの文化とPythonの文化は方向性が全然異なる
昨今の統計事情から察するに、応用を考えるにあたってはPythonの文化の方が優れているだろう
つまり、細かいことは言語作者やライブラリ作者に全部任せて、考えたいことに集中できる文化の方が発展が速い

**デフォルトの名無しさん** · 2017/06/14(水) 14:32:38.36

Cの中に全然異なる二択があると言われたのをもう忘れたか
忘れるの速すぎ

**デフォルトの名無しさん** · 2017/06/14(水) 14:35:24.56

>>35
二択って何？このスレで二択で調べても「野良orOSのパッケージ管理」しか出ないんだけど

**デフォルトの名無しさん** · 2017/06/14(水) 14:38:55.46

リテラシーゆとり教育orバイナリまとめサイト

**デフォルトの名無しさん** · 2017/06/14(水) 14:47:06.53

よくわからんしまあいいや
Pythonの例から考えるに、少なくとも応用分野では次世代に流行る言語は強力なライブラリを簡単に導入でき、すぐに目的コードが書けてしまうと言った特性を有しているでしょう

**デフォルトの名無しさん** · 2017/06/14(水) 14:59:43.37

FORTRANの駆逐に長い時間が掛かったのはライブラリ遺産のせいだって聞いたことがある。

**デフォルトの名無しさん** · 2017/06/14(水) 15:11:13.20

その通り。Fortran77はクソだけど、新しい言語を使おうとしても移植作業も新規に書き直す作業も面倒なので、そんならいいやとFortranを使い続けてきた
そこに持ってきてpip install scipyのワンコマンドでblas lapackの多くのサブルーチンの良質なラッパーをインストールし、よくわかってない学生でもfrom scipy.linalg import eig 出来てしまうPythonは本当に偉大であった

**デフォルトの名無しさん** · 2017/06/14(水) 20:07:23.71

まあ今ある blas より速いの作るなんて普通のプログラマには不可能だしな。。

**デフォルトの名無しさん** · 2017/06/14(水) 21:17:37.82

Haskell復活してるやん

**デフォルトの名無しさん** · 2017/06/15(木) 01:45:20.34

>>42
Kotlin引退で繰り上がり

**デフォルトの名無しさん** · 2017/06/15(木) 03:30:08.09

つまり実用できる状態になるとスレタイから外されるって事だよな
ここに残ってるのはいつまでも「次世代」言語

**デフォルトの名無しさん** · 2017/06/16(金) 00:53:52.07

現時点のKotlinレベルでいいならGo,Rust,Scalaは実使用されつくしてるような

**デフォルトの名無しさん** · 2017/06/16(金) 02:31:19.78

Go ScalaはともかくRustは絶対にねえよ

**デフォルトの名無しさん** · 2017/06/16(金) 08:26:01.05

実用できる次世代言語はkotrin typescript だよね
実用できない次世代言語がスレタイ

**デフォルトの名無しさん** · 2017/06/16(金) 09:11:14.72

mozilaの落ちぶれっぷりがやばい

**デフォルトの名無しさん** · 2017/06/16(金) 10:10:44.42

>>48
元からあいつらただのヤクザ
大義名分のメッキの裏がGoogleやAppleの経済活動で暴かれただけ

**デフォルトの名無しさん** · 2017/06/16(金) 10:22:55.63

個別スレある言語の話はそっちでヤレばいいじゃん
ここは個別スレ無いやつ専用にしろよ

**デフォルトの名無しさん** · 2017/06/16(金) 10:54:04.49

パッケージ管理システムとかガベコレの一般論専用かな
一般論の個別スレないよね

**デフォルトの名無しさん** · 2017/06/16(金) 11:04:24.01

日産自動車栃木工場
塗装課、車軸課の正社員の方々の要求はコピペ継続の保守

２ちゃんねる愛用の方々にお知らせ
栃木県上三川町3-5-2
日産自動車上三川寮
管理人は合鍵を使い従業員の部屋に無断で侵入
。
抜き打ちで従業員の私物を全て調べるブラックの中のブラック企業。
期間工が看護師を殺害する事件もあった危険企業。
離職票を発行するのに一月以上もかかるとの情報もあり期間工の生活事情はお構い無し。

このコピペによる日産の悪事の拡散は日産正社員の断固たる要望である。これには日産と無関係の第三者が便乗している可能性が高く自分は不自然に感じている。

0647 FROM名無しさan 2017/06/01 21:21:43
いいからこんなとこで油売ってないで早く100万コピペ達成してこいよｗｗｗ
ほら早よ行けやホラホラｗｗｗ
返信 ID:bEv8YiM0(7/7)

↑↑このように必死で日産の悪事を拡散しろと煽っている。俺は脳無しで馬鹿なので日産正社員が日産悪事を公表するように煽ってきた理由が分からない。不本意ながらコピペを続けている。

**デフォルトの名無しさん** · 2017/06/18(日) 01:50:03.42

個別スレない言語オンリーならRacket無双になるがよろしいか

**デフォルトの名無しさん** · 2017/06/18(日) 13:22:25.92

あとは歴史的変遷からみる次世代言語とか

**こんな？** · 2017/06/19(月) 16:27:30.01

今SunがJavaっての作ってるらしーぜ
どんな言語だろうな？

**デフォルトの名無しさん** · 2017/06/24(土) 15:20:30.76

Googleがヘルスバーグ（C#）級の人をスカウトしてきて
メインプロジェクトとして本気の新言語作ったとしたらどうなるか見てみたい
GoもDartも最初の言語設計がイマイチ感は否定できないんだよね

**デフォルトの名無しさん** · 2017/06/24(土) 16:06:03.03

静的型と動的型のハイブリッドはTypeScriptで早くも完成させちゃったから、
次にヘルスバーグが手がけるとしたら完全な型推論ベースの静的型言語をやってほしい

**デフォルトの名無しさん** · 2017/06/24(土) 16:23:53.98

ヘルスバーグすこ
Googleの作る言語はゴミばっかや

**デフォルトの名無しさん** · 2017/06/24(土) 16:28:25.84

ヘルスバーグだってMSが敵わなかったからライバルから引っこ抜いたんだろ

**デフォルトの名無しさん** · 2017/06/24(土) 16:51:36.76

なんだかんだ言ってもOS自体を書く言語は変わってないからな

**デフォルトの名無しさん** · 2017/06/24(土) 21:54:51.34

>>56
今ならSwift開発したクリス・ラトナーが絶賛求職中やで。

**デフォルトの名無しさん** · 2017/06/24(土) 23:50:07.30

Googleってゴスリンやゲイドも飼ってたことあるよな
一瞬で辞めたけど
会社の体質に問題があるんだろうね

**デフォルトの名無しさん** · 2017/06/25(日) 08:44:29.52

kotlinとswiftどっちが有望？

**デフォルトの名無しさん** · 2017/06/25(日) 08:59:11.73

どっちも有望だが、どこを比較してほしいんだ

**デフォルトの名無しさん** · 2017/06/25(日) 09:10:38.04

学ぶならどっちがいいのかなと思って

**デフォルトの名無しさん** · 2017/06/25(日) 10:07:31.69

Androidのアプリ作りたいのか、iOSのアプリ作りたいか
それだけの話なのに何で自分で決められないんだろ

**デフォルトの名無しさん** · 2017/06/25(日) 10:21:57.72

何のために学びたいんだ

**デフォルトの名無しさん** · 2017/06/25(日) 10:24:20.80

kotlinは既にJavaをマスターしててサンプルコードの雰囲気を見ただけでなんとなく書き始められるくらいの人が使うもんだぞ
勉強するもんじゃない

**デフォルトの名無しさん** · 2017/06/25(日) 12:21:22.67

今Haskellでよく使う処理をガンガン関数にしてライブラリ化してるけど、LLでもここまで短く書けないだろと言うか、
ここまでライブラリ化するには遅延評価じゃないとreverse使わないような処理でもメモリに溜め込むか、
遅延評価にする為にイテレータ作りまくりじゃないかと思った。

いあ、最上位の関数とかは短く書けるんだろうけど、ライブラリ内部の似たような処理を
ガンガン関数にして行くのは流石に難しいと思う。

**デフォルトの名無しさん** · 2017/06/25(日) 12:39:35.65

>>69
つづきはブログでおやり
具にもつかない報告を読まされる身にもなってみろ
お前のレスは今後一切いらんからなこのスレには

**デフォルトの名無しさん** · 2017/06/25(日) 12:53:31.73

linux のソース見る限りは c にまともなマクロが用意されればそれで十分。
まあまともなマクロを用意するってのは言うほど簡単じゃないだろうけど。

**デフォルトの名無しさん** · 2017/06/25(日) 13:33:53.23

>>70
じゃあLLでも何でもいいけど、手続き型言語でよく使う処理をガンガンライブラリ化してみてよ。
どっちがより汎用性と簡潔性を両立出来てるか競おうず。

**デフォルトの名無しさん** · 2017/06/25(日) 13:58:29.36

Haskelは実装変更のインパクトがでかくてカプセル化的な考え方で作るには向かないんだよな
実用言語としてガチ関数型を流行らせるには厳密性を維持しつつ現実の大規模開発でのモジュール化も考慮した仕組みを作らないと

**デフォルトの名無しさん** · 2017/06/25(日) 14:13:01.18

>>73
Cでcatコマンド自作しようとした時、複数ファイルから一番長い一行あたりのバイト数(文字コードによって違うので文字数ではダメ)調べるコマンド作った時、
lengthはByteStringモジュールを使いたいけど、mapは標準のを使いたい(ByteStringのmapはByteString -> Char特化)って時に細かくどれは読み込んで、どれは読み込まないってしたけど、
それじゃあかんの？

モジュール読み込みの設定だけ変えれば、main以下は全く同じコードがバイト数と文字数切り替えれるけど。

**デフォルトの名無しさん** · 2017/06/25(日) 14:24:06.30

>>74
すまん全く意味がわからない
73からいきなり抽象度が下がりすぎだろ
ハスケラならもうちょっと抽象的かつ厳密で明示的なレスを頼む

**デフォルトの名無しさん** · 2017/06/25(日) 15:21:38.85

>>72
なにが「じゃあ」なん？
脳みそ腐ってんの？
しょーもないレスでスレ汚すのやめてくれマジで

**デフォルトの名無しさん** · 2017/06/25(日) 16:41:08.55

>>75
抽象度が高い=フワッとして概念的って思ってたんだが違うんか。。。
import書く時、この関数だけ読み込まない。
この関数だけ読み込むって指示できるから、そこだけ弄ればそこ以下のコードは書き換え無しに
文字数数えるかバイト数数えるか動作を切り替えられる。

**デフォルトの名無しさん** · 2017/06/25(日) 16:53:53.40

>>76
うんうん。
分かるよ。
式と文が入り混じるから関数化する単位に限界あるもんね。
副作用と純粋部分の区分けが強制されないというか、遅延評価じゃないと強制されたらreverse使ってなくてもメモリに溜め込むコードになっちゃうし。
それを解消する為にイテレータ書きまくるのも面倒だもんね。
Cくらい速かったら、それを飲み込むのも我慢出来るのにね。

**デフォルトの名無しさん** · 2017/06/25(日) 17:24:16.31

この勘違いしたハスケラを黙らせるには、
ハスケラ自慢のライブラリを見せてもらって、
それより簡潔なコードを書くしかないと思う

**デフォルトの名無しさん** · 2017/06/25(日) 17:39:45.42

>>77
例えば、引数の値のみにより完全に決定される値を返す関数があったとして
ここに「ただし、前回と値が同じ場合は前回より1だけ大きい値を返す」という要件が増えたらどうする?

**デフォルトの名無しさん** · 2017/06/25(日) 17:56:09.21

>>80
Haskellも状態扱えない訳じゃないし、大量に状態保持す代名詞のGUIプログラミングが、HTMLやXAMLで書かれるのに一定の地位を確立した今となっては、そういうDSL、又はDBに状態保持させて、Haskellは同じ値が来たら外部に+1してってお願いすれば良いと思うけどね。

**デフォルトの名無しさん** · 2017/06/25(日) 17:59:09.81

>>81
つまりインパクトが大きいってことだね

**デフォルトの名無しさん** · 2017/06/25(日) 18:12:35.96

何言ってんのか分からんけど、Haskellでここまでよく使うパターンをライブラリ化出来るなら、もうLL要らんってなった。
速度が必要な時はCで書いて、速度求めないのはHaskellで良いや。
速度こそLLと変わらんけど、ここまで再利用し易いなら自分でよく使うパターンをライブラリにして行けば、すぐにLLより短くなる。

number.hsナンバリング
import System.Environment
import Myfunc

main = getArgs >>= mfput (fnumbering id)

revnumber.hsナンバリングと行の逆順
import System.Environment
import Myfunc

main = getArgs >>= mfput (fnumbering reverse)

mygrepn.hs検索文字列含まれる行（行番号付き）抽出。
import System.Environment
import Myfunc

main = getArgs >>= \(w:fs) ->
mfput ((replace w (redstr w)).(grep w).fnumbering id) fs

rp.hs（文字列置換）
import System.Environment
import Myfunc

main = getArgs >>= \(w:nw:fs) -> mfwrite (replace w nw) fs

**デフォルトの名無しさん** · 2017/06/25(日) 18:17:06.53

ライブラリ内部にも似た様なパターンを関数化して無駄に似た様な少し違うコードが少ない様にしてる。

Myfunc.hs自作ライブラリ
module Myfunc where

import Data.List
import Text.Printf

consnum::(Int,String) -> String
consnum (i,xs) = printf "%4d:%s" i xs

fline f = unlines.f.lines

fnumbering f = fline ((map consnum).(zip [1..]).f)

redstr::String -> String
redstr [] = []
redstr w = printf "\ESC[1m\ESC[31m%s\ESC[39m\ESC[0m" w

bluestr::String -> String
bluestr [] = []
bluestr w = printf "\ESC[34m%s\ESC[39m" w

grep w = fline (filter (isInfixOf w))

**デフォルトの名無しさん** · 2017/06/25(日) 18:17:18.21

replace _ _ [] = []
replace [] _ cs = cs
replace w nw cs | w == xs = nw ++ replace w nw ys
where
(xs,ys) = splitAt (length w) cs
replace w nw (c:cs) = c:replace w nw cs

putfc (f,c) = printf "%s\n%s" f c

writefc (f,c) = writeFile f c

mfptn fs f ofs output = mapM readFile fs >>=
return.(zip ofs).map f >>=
mapM_ output

mfput f fs = mfptn fs f (map bluestr fs) putfc

mfwrite f fs = let tfs = map (++ ".temp") fs in
mfptn fs f tfs writefc >>
mfptn tfs id fs writefc

**デフォルトの名無しさん** · 2017/06/25(日) 19:00:45.29

それライブラリ化する価値もなさそうな
汎用性の無いコードにしか見えんが、本気か...？

**デフォルトの名無しさん** · 2017/06/25(日) 19:04:10.51

>>79
ワザとウザい役したけど、実際問題再利用のし易さと速度はある程度トレードオフな関係だと思う。
それならHaskellとCで良いんじゃないかってなった。
個々人でバランス感覚違うから、他の言語を選択するものアリだけど。

**デフォルトの名無しさん** · 2017/06/25(日) 19:11:04.69

>>86
まだ育ててる最中だしね。
複数ファイル読み出し、複数ファイルそれぞれ出力なパターンはこれで行ける。
複数ファイルから一つの結果求めるパターンはこれから作るし、他の関数と共通パターンあったら、関数化して行く。

正気か？って言うけど、forとかメソッドチェーンな中身とか途中のメソッド入れ替えるとか、そう言うことしてる様な感じ。
こんな関数化の方法、オブジェクト指向言語では考えもしなかったぞ。

**デフォルトの名無しさん** · 2017/06/25(日) 20:27:51.46

Haskell使いのレベルの低さが知れるな
こうゆうのを繰り返すならやっぱり次はまたHaskellはずそう

**デフォルトの名無しさん** · 2017/06/25(日) 20:33:29.70

ていうかHaskell自体は全然次世代言語じゃないじゃん
Haskellの一部分を参考にした次世代言語はあるけど

**デフォルトの名無しさん** · 2017/06/25(日) 20:59:18.08

Idrisとか？

**デフォルトの名無しさん** · 2017/06/25(日) 21:00:59.61

ええ。。。
最近こそラムダ式とか入ったけど、オブジェクト指向って相変わらず手続き型言語で、コンストラクタって結局構造化プログラミングで言うinit関数でしょ？みたいな感じで処理の分け方が上中下って感じなんだもん。
おまけに肝心の中身はインターフェースでそれぞれのクラスに別々に書いてねとか。
似た様なコード何度も何度も書いてるなー。。。って感じだった。
LLにしても、書き捨て毎に似た様なコード書いてるなー。。。って。

Haskellだからここまで関数化しても遅延評価でメモリを一定以上消費しないんだと思うし、mfput関数一つ書けば中身の処理を考えるのに集中出来た。
(mygrepnとか見つかった文字列を強調赤字にするオマケ付き。
rpとかコマンド名が競合するから短い名前だけど、地味にコード書き換えに活躍してる)

実際に上のコードと同じライブラリ書いてみてよ。
パターンは共通って分かってても、文が邪魔したり、メモリに溜め込む処理になるから断念する場面が出てくると思う。

**デフォルトの名無しさん** · 2017/06/25(日) 21:18:47.33

>>89 >>76 >>70
まともに叩くことも出来ないレベルのクソ野郎は入ってくんなよ…
お前らみたいなのがいるから、変なのが増長するんだろ

**デフォルトの名無しさん** · 2017/06/25(日) 21:38:11.91

>>92
結局パイプ的に繋いでく話してるだけだな
はっきり言うが、Haskellでまともなプログラム組んでIO扱う途端にその手の使い方はできなくなるよ
その言ってる方法突き詰めたとして、リアクティブプログラミング的になるが、
遅延評価が仇になってサンク作りまくる場合はあるし、遅延評価だから空間計算効率が良いなんて話にもならない
Haskell自身もメモリの効率がいいわけでもない
女アクのGHCのランタイムがまずクッソでかいし

何よりリアクティブプログラミングじゃ、現代のGUIでまともなプログラム作れない
IOなGUIツールキットをリアクティブに対応させるコード書いてる暇あったらIOで書いた方がマシだ

**デフォルトの名無しさん** · 2017/06/25(日) 21:42:36.54

正確にはリアクティブプログラミングじゃなくてFunctional Reactive Programingだな
リアクティブだけなら、一つのシグナルストリームでなく分散メッセージでいいし難しくはない

**デフォルトの名無しさん** · 2017/06/25(日) 22:00:46.32

>>94
空間計算効率が良いなんて一言も言ってないが。。。
悪魔で再利用し易さの割にってだけ。
んでもLLと同程度ならほとんどの場合で問題にならないので、このままライブラリ化進めればLLよりチマチマしたの作るのに都合が良い言語になると言うか、既になってる。

半端にLLで空間計算効率考えるよりは、普段はHaskellで富豪的だけどLLより再利用し易いコード書いて、そう言うの重要な場面ではCで書けば良いやってなった。

今時のメモリ搭載量だと小説10冊分が1ファイルに入ってても問題にならんから、実用上ほとんど問題にならん。
それが問題になる時は処理速度的にもLLでも対処出来ない。

**デフォルトの名無しさん** · 2017/06/25(日) 22:10:00.00

>>96
お前さっきからメモリの話ばっかりしてるじゃん…
それに再利用については、途中からIO入れたら使えないよね？
っていうツッコミに全く反論できてないし
言ってる事めちゃくちゃだぞ

**デフォルトの名無しさん** · 2017/06/25(日) 22:16:17.15

>>97
「関数型で書いてもメモリを一定量以上使わない」を「空間計算効率が良い」と解釈するのはいくら何でも頭発達しすぎでしょ……

**デフォルトの名無しさん** · 2017/06/25(日) 22:20:20.12

ちなみにCで書こうがIOの問題は付随するので変わらない
そもそもパーサをTemplateHaskellとけ使って書いてるレベルならまだしも Haskellで型注釈も無しじゃコンパイル遅すぎだし、
リストを配列代わりにしたり、String使ってテキスト処理してるレベルじゃLLより遥かに動作遅いだろ
普段から使ってるとはとても思えない

**デフォルトの名無しさん** · 2017/06/25(日) 22:21:53.78

>>98
いつ帯どこに突っ込んでんだよ
メモリに溜め込む云々は明確にそういう話だろ

**デフォルトの名無しさん** · 2017/06/25(日) 22:22:12.23

変換ミス
一体どこに突っ込んでんだよ

**デフォルトの名無しさん** · 2017/06/25(日) 22:24:18.08

え、まさか本当にストリーム処理書けないとかそんな話？
いくらなんでも違うよね？

**デフォルトの名無しさん** · 2017/06/25(日) 22:27:27.12

>>97
途中からとはなんぞな？
CUIにしてもGUIにしても、HaskellだとIO部分と純粋部分は強制的に分けて書かざるを得ないから何を言ってるのか。。。
(mfwriteでは同名ファイルに書き込めないので一旦別名で保存して、別名で開く->元の名前で保存ってしてるけど、そう言うのはIOが途中で挟まるってのと違うのん？)

ある意味手続き型言語みたく(と言うか他の関数型もそう言う意味じゃ途中でIO挟まる？)、途中でIO挟まらないパイプみたいな処理にCUIでもGUIでも強制されるのがHaskellの一見不便で長所。
mfptnからmfputとmfwrite作ってる通り、関数に渡す出力先を差し替えるだけで良い。

**デフォルトの名無しさん** · 2017/06/25(日) 22:32:23.46

>>100
それはLLとは言え、手続き型言語がハードの仕組みに依存してるから、Haskellと同じ程度にライブラリ化進めると、普通に書くより遥かにメモリに負担かかるって意味。
Haskellがメモリ効率が良いって言ってるわけじゃ無い。

**デフォルトの名無しさん** · 2017/06/25(日) 22:33:19.85

>>103
既存の物を状態を扱うように変更するのにコスト大きい、と突っ込まれとるよね
あとGUIは純粋に分けることを強制される、なんて簡単に終わる話じゃないんだよね
新規に同規模の実装を強制されるわけで

**デフォルトの名無しさん** · 2017/06/25(日) 22:33:55.06

>>104
だから結局空間計算量の話ししてるじゃん…

**デフォルトの名無しさん** · 2017/06/25(日) 22:38:50.94

ちうか、出力先を変更する云々なんて別にHaskell関係なくないか？
どこがHaskellでしか出来ない処理と言ってるわけ？

**デフォルトの名無しさん** · 2017/06/25(日) 22:44:55.19

ヤバい、ほんまもんや（笑）

**デフォルトの名無しさん** · 2017/06/25(日) 22:56:39.77

>>99
うい。
ぶっちゃけ大きめのファイルだとLLより遅いの体感出来るw
んでも実用的な時間だし、上でパイプの例えあったけど言い得て妙で、
LLでforとかeachとかでループとして処理するのもメソッドチェーンみたいにファイル名のリスト受け取って、
中身のリスト受け取って。。。ってパイプ処理して行くから、LLより考え方が流れを辿る感じでシンプルなんだよね。
速さよりも書き易さ優先。
速さ気にしてたらそもそもHaskell選んでない。
速さが我慢出来なくなったらCで書くよ。

ネットでperlで1000万行のファイルの行を逆順にしたいっての見つけて、Cで書いたんだが、3.1GBにもなるファイル読み込ませて逆順表示はCでも待ったな。。。
(一旦全部上から読んで位置情報を配列に入れて、最後に記録した位置から逆に辿る手法だったけど、メモリは4GBメモリの0.6%しか消費してなかった)

Haskellでメモリに溜め込む書き方でも10万行くらいは我慢出来るレベル。
LLならCと同じ手法でメモリに負担かからない方法で書けるだろう。
実はHaskellにもhSeek関数あるから、多分メモリに負担かからない方法で書けると思う。

でも、もうそこまで行くんならCで気持ちよく書く。

**デフォルトの名無しさん** · 2017/06/25(日) 22:57:17.16

やっぱり本気でパイプのようなストリーム処理がLLで書けないと思ってるのかな
今時はラムダなどのストリーム処理なんてJavaですら標準でついてるってのに

>>108
何が「ほんまもん」なんですかね
もしかしてどっちもO(1)で一緒とか言いたいの？
空間計算量って、それ自体はO-notationでの表記のことじゃないぞ？

**デフォルトの名無しさん** · 2017/06/25(日) 23:05:34.61

「副作用で世界がどんどん変わって行くのを俺が全部コントロールして阻止しなければならない…
そうでなければこの世界はバラバラになってしまう…」

「どうしたんですか？先輩」(もぐもぐ
「おお後輩！…なんだそれ？」
「売店がパンじゃなくて弁当扱い出したんですよ
ゴミかさばるから売店とこで捨てろですって。
まぁ、どうせ僕が一括して持ってくんでしょうがw」
「後輩」
「はい？」
「カレーある？」
「たしか」
「じゃあ、それ一つ」
「はい」

**デフォルトの名無しさん** · 2017/06/25(日) 23:09:52.30

ヤバいこいつ論点分からず突っかかってる

**デフォルトの名無しさん** · 2017/06/25(日) 23:11:04.64

>>107
うーん。。。出力先もだけど、差し替え易さとか、処理対象の単位を行き来し易いとか。。。かな？
ループだとファイル単位、行単位、文字単位って決まっちゃうと、中々そこから抜け出せないけど、例えば複数ファイルの行で一番長い行を調べたいとする。
(実はCで上の逆順コード書く際のバッファの大きさを決めるために書いた)

最初、トーナメント形式に各ファイルで一番長い行出させて、そこからさらに一番を決めて出力してた。
んで、途中で全ファイルの行の長さ出た時点で一位決められるじゃん。と、数値のリストのリストを平坦化して一気に一位決めた。
そう言うループじゃ無くて、悪魔でリストのリストを受け取って～。。。って考えると簡単に行単位とかそう言う枠を超えられる。
LLでも出来るだろうけど、思いつき易い。

**デフォルトの名無しさん** · 2017/06/25(日) 23:12:43.68

>>110
いあ、書けるでしょうよ。
ただ柔軟性？こう、スタイルが決まっててあんま動かせない感じを受ける。

**デフォルトの名無しさん** · 2017/06/25(日) 23:15:11.08

>>109
言いたい事はわからんでもないけど、そんなにhaskell使いやすい？
自分もHaskellは複雑な構造の解析とか、何か本質的な部分の問題解くときにghci使う事あるけどさ、
実装はやっぱりpythonとかのが楽ってなったよ
Stackやcabalの設定編集も面倒だしコンパイル遅いし
mapM_あたり使うような物で純粋を目標にしてると、本末転倒になる事が多いし

**デフォルトの名無しさん** · 2017/06/25(日) 23:17:22.59

>>112
ああなるほどね
難癖つけてる奴の同類か

**デフォルトの名無しさん** · 2017/06/25(日) 23:27:50.72

>>114
ポイントフリースタイルとの組み合わせは確かにHaskell特有だけど、
個人的には実装はIOの文脈で、パイプ演算子とパターンマッチを使える
F#やLiveScript(altJS)のような言語方が楽だと思うぞ

**デフォルトの名無しさん** · 2017/06/25(日) 23:45:27.87

>>115
なんつーか、さすがにGUIとかはC#使うわってなるけど、確かにコンパイル遅くて微妙に感じもしたけど、上のライブラリみたくガンガン関数化すればPythonでループのシーケンスにargv[1:]ってしてー。。。
逆順だとReversed(list(sys.argv[1:]))でー。。。とか調べないとな場面が度々ね。
んで、毎回複数ファイルから読み込まるのにforって書いて、行毎だとまたfor。。。

Haskellもライブラリ作る前は似たり寄ったりだったけど、ライブラリ書いてからはmfputにファイル名のリストと、各ファイル向け(1ファイル向け)に処理させたい関数渡すだけで大体のツール作れる。
多少パターンが特殊でもmfptnで対応出来る。
ループ的なのを関数に押し込んで、開きたいファイルと処理させたい関数だけ気にしてれば良くなった。
(逆にサポート外のパターンには無力だが。関数化は使い方も規定しちゃうから仕方ない)

Pythonだとあんまここまでライブラリ化出来る気がしない。。。
PythonやRubyの書き捨てでも楽だって思ってたけど、多分もう戻れない。

**デフォルトの名無しさん** · 2017/06/25(日) 23:47:28.90

まずなー>>98に>>100をいっちゃう時点でなー
>>96で「空間計算効率が良いなんて一言も言ってない」って明言されてるにも関わらずこんなこと言ってる時点で読解力お察しだからなー

**デフォルトの名無しさん** · 2017/06/25(日) 23:54:14.28

相手の意図を組めないという点ではエンジニアガイジと同類っぽいなー

**デフォルトの名無しさん** · 2017/06/26(月) 00:09:44.62

そう。
空間計算効率の話自体はしてても、Haskellと同程度にライブラリ化したらLLが今までより空間計算効率が落ちる(もしくはイテレータ地獄になる)って言ってるだけで、Haskellの空間計算効率が良いなんて言ってない。

**デフォルトの名無しさん** · 2017/06/26(月) 00:15:26.29

初めてKotlinで書いてみたけど意外と悪くないな
驚きが非常に少なく無理がない
C#みたいな天才肌とは違ってとにかく無難でつまらない印象だけど、
Javaからの乗り換えという意味では最適なとても筋のいい言語だと思うわ

import java.io.File

fun Sequence<String>.grep(w: String) = this.filter { w in it }
fun redstr(w: String) = "赤(${w})"
fun counsnum(i: Int, xs: String) = "%4d:%s".format(i, xs)
fun numbering(lines: Sequence<String>) = lines.mapIndexed({ i, xs -> counsnum(i + 1, xs) })

fun main(args: Array<String>) {
　val (w, fs) = args
　val lines = File(fs). bufferedReader().lineSequence()
　numbering(lines).grep(w).map({ redstr(it) }) }.forEach({ println(it) })
}

**デフォルトの名無しさん** · 2017/06/26(月) 02:35:16.31

>>122
kotlinのコードこのスレで初めて見たし、他のスレでもここまでまともなの見なかった。
thanks.
わざわざ見つかった文字列を赤文字にする所まで再現してくれるとは。。。

もうHaskellに惚れちゃってるからメインにならんだろうけど、確かに筋は良さそう。
GUIなコード書くのには良いかもしれんね。

行単位で受け取って行単位で出力する辺り、やっぱ手続き型言語と感じるけど。
だからこそ効率が良くて、そこを意識するからこそ柔軟性の限界感じる。
HaskellはStringが遅いだけで、バッファ効率自体は多分良い。
行単位とかじゃ無くて目一杯バッファに入れてると思う。
ByteString慣れないと説得力無いんだろうけど。。。
面倒いなぁ。。。
そこまでしないと勝負にならないなら、あんたの勝ちでいいよって思うもん。
手早く書けて使える速度なら充分だし。

**デフォルトの名無しさん** · 2017/06/26(月) 04:34:26.65

>>119
明言してると言っても実際言ってるし
やっぱり難癖つけたいだけじゃん

**デフォルトの名無しさん** · 2017/06/26(月) 04:36:09.09

>>120
お前もうただ言い方に突っかかってるだけだろそれ

**デフォルトの名無しさん** · 2017/06/26(月) 07:49:16.94

>>118
引数の逆順でファイル読み込んで一つのイテレータにするだけなら、pythonならこれだけじゃね？
(x for f in argv[1:][::-1] for x in open(f))
これをイテレータを処理する関数の引数に渡せば、お前のやりたい事できてるよね？

**デフォルトの名無しさん** · 2017/06/26(月) 08:09:40.24

そうも書けるんだ。
でももうcatコマンドだったら

main = getArgs >>= mfput fs id

って書けば良いようにライブラリ作っちゃったし、もう良い。
mf = マルチファイル

**デフォルトの名無しさん** · 2017/06/26(月) 08:11:46.44

>>123
入出力関数が適切にバッファリングしてると思うけど？

**デフォルトの名無しさん** · 2017/06/26(月) 08:12:49.97

逆順だとunlines.reverse.linesしないと改行が変になるから

main = mfput fs (unlines.reverse.lines)

unlines.f.limesパターンも良く使うから

main = mfput fs (fline reverse)

って書けるようにしたし。

**デフォルトの名無しさん** · 2017/06/26(月) 08:15:23.64

あ、

main = getArgs >>= mfput fs (fline reverse)

だった。

**デフォルトの名無しさん** · 2017/06/26(月) 08:19:14.81

>>128
うい、行単位でね。
Haskellは基本ファイルの中身を丸ごと文字列で受け取って、文字列で返すから、行って考えはナンバリングしたいとか、行単位で処理したいって思った時に初めてunlines.f.linesパターンで行単位に分解する。
なので出力するHaskellランタイム側にも行単位って概念が無い。

**デフォルトの名無しさん** · 2017/06/26(月) 08:29:13.90

>>131
行単位じゃないぞ
単純に間違ってるから事実だけ書くけど

**デフォルトの名無しさん** · 2017/06/26(月) 08:29:22.47

まあ、そんな事してるからHaskellは遅いんだろうなってのはある。
文字単位でバッファ目一杯入出力するけど、加工過程で分解して戻してってしてるんだし。

**デフォルトの名無しさん** · 2017/06/26(月) 08:30:25.78

>>132
なるけど、見かけのコードは行単位でも、バッファリングはそれとは別に行を越えて処理すると。
これは失礼。

**デフォルトの名無しさん** · 2017/06/26(月) 08:37:10.13

>>130
さらに馬鹿だ。。。
寝惚けてる。
部分適用し易いようにfsが第二引数だから

main = getArgs >>= mfput (fline reverse)

これだけで良いんだった。

**デフォルトの名無しさん** · 2017/06/26(月) 08:44:37.68

KotlinはJava標準ライブラリに対する拡張も上手い
Javaに背を向けたScalaとは違って、Java標準ライブラリの良いところ駄目なところを深く理解して
最小限でツボを押さえた拡張を入れてる
Scalaが一瞬で要らない子になったのも納得

**デフォルトの名無しさん** · 2017/06/26(月) 08:51:02.56

>>126
ついでに言えばPythonのは逆順でもメモリに溜め込まないはずで、大きなファイルだとPython使った方がいいってことになる。
でも、今時のスペックで問題になる程溜め込む場面自体が無い。
小説100冊分が1ファイルに入ってやっとちょっと気になるレベルだから。

なら、より短く書ける方がいい。
コンパイル遅いつっても書き捨てレベルなら毎度毎度定型的にPythonで書いてる時間で終わってる。

自分でライブラリ作ってからは完全にLL的な使い方はHaskellで良いやってなった。
素のままだとPythonのが良いけどね。
自分でライブラリ作るかどうかが決め手だった。

**デフォルトの名無しさん** · 2017/06/26(月) 10:49:16.29

複数のファイルを順番に読んでいって、特定の文字列が見つかるまで入力をそのまま出力する
文字列が見つかったら即終了

ってプログラムを、その自慢のライブラリで書いてみてよ

**デフォルトの名無しさん** · 2017/06/26(月) 10:53:00.61

スレ違いの日記帳の相手してどうすんの

**デフォルトの名無しさん** · 2017/06/26(月) 11:35:20.04

行単位なのはダサいといいながら自分のライブラリはべったり行単位に依存してるのが笑いどころだな
結局行単位が便利だと思う人が多いからlineSequenceみたいなユーティリティが標準で用意されてるだけで、
やってることはunlines.f.linesと変わらんぞ

**デフォルトの名無しさん** · 2017/06/26(月) 12:07:26.65

>>138
import System.Environment
import Data.List
import Myfunc

main = getArgs >>= (w:fs) ->
mfput (unlines.lines.last.(takeWhile (not.isInfixOf w)).inits) fs

**デフォルトの名無しさん** · 2017/06/26(月) 12:56:36.59

import System.Environment
import Data.List
import Myfunc

main = getArgs >>= (w:fs) ->
mfput ((++ "\n").last.(takeWhile (not.isInfixOf w)).inits) fs

unlines.lines要らんかった。

直後って書いてたから最初の検索文字列全部表示される前に終了かと思って上のコードにしたけど、最初の検索文字列表示した時点で終了なら、takeWhileをdropWhileにして、lastをheadにすれば良い。

**デフォルトの名無しさん** · 2017/06/26(月) 14:59:05.87

>>122 >>136
メインプロジェクトとしていろいろ試して選んだって感じなのね
androidの主力開発言語を急に乗り換える必要が発生したから当然だけど

（な？うざいだろ？by 某M社）

**デフォルトの名無しさん** · 2017/06/28(水) 22:04:57.53

F#ってどうよ

**デフォルトの名無しさん** · 2017/06/29(木) 00:10:11.51

OCAMLを.netで記法（not構文）変えて作りましたって感じ＞F#
冗長記法だとOCAML互換性高いし

**デフォルトの名無しさん** · 2017/06/29(木) 17:11:41.82

***SLAMO***

}

000-"F","TAP","0","1M","L","E-07"/0B"[9BA%]"^"2*73B"="0"/"9GA"
001-"Do"[[[%9DE=HUF%%!%$0B1OTU"NE"]]]<\b>
002-<<%!!!HNDEL%!0DAI@$7[1B]!0#!@>>
3000-{{1\B%HUF!0$$\%6/0Q\%6/GA[[7BU]]%9TE!%$en$}}

---

[[[C%%]]]
}

000-"5802"/"α"="0.1888412376155482"%en{

**デフォルトの名無しさん** · 2017/06/30(金) 08:41:39.49

F# は関数型らしい抽象化機能※ を持っていないのが欠点
抽象化は .NET ( C# ) 互換の抽象クラスやインターフェースで実現することができる
でも型推論が効かなかったり null 安全でなかったりして辛い

※OCaml では構造的部分型やモジュール抽象化
Haskell では型クラスや型族のこと

**デフォルトの名無しさん** · 2017/06/30(金) 20:40:32.58

型だけを見ればC#とF#は同じだろ
Haskellだって型だけを見れば他の言語で同じものは作れる
型だけを見るのが王道

逆に型を無視してHaskellにしかないものを強調するのは邪道だから
惑わされるなよ

**デフォルトの名無しさん** · 2017/06/30(金) 20:44:45.42

次世代言語でHaskell並にちゃんとした型システムが入ってる言語ってある？

**デフォルトの名無しさん** · 2017/06/30(金) 21:24:26.03

Haskell並ならちゃんとしてるというのは本当か？
ちゃんとしてないから「Haskell並」や「Haskellよりマシ」と言い訳するんじゃないか

**デフォルトの名無しさん** · 2017/06/30(金) 21:27:48.40

構造的部分型が「ちゃんとしてる」かは大いに疑問
あんなもんドカタITで使ったら悪夢だろ

**デフォルトの名無しさん** · 2017/06/30(金) 21:57:41.84

>>151
Haskellの機能じゃないし、その上根拠もない

**デフォルトの名無しさん** · 2017/06/30(金) 22:00:33.62

>>150
静的型に限って言えばHaskellは上位でいいんじゃない？
強いて言うなら、TypeSynonymなクラスインスタンスぐらい言語標準で入れてほしいけど

**デフォルトの名無しさん** · 2017/07/01(土) 09:18:35.85

中途半端な奴だな
オレが一位だというならまだわかるが
Haskellが上位だという主張の何が嬉しいのか

**デフォルトの名無しさん** · 2017/07/01(土) 10:27:16.17

古い関数型言語関係の本だと、論理型言語が関数型言語の次の世代とか書いてて、まあ実際最近ワトソンやらペッパーやらAI関係で注目されてるのも論理型言語な訳で。
んじゃPrologはHaskellより使い易いんか？と勉強中。

早くもコレジャナイ感が。。。
もっと今時の論理型言語って無いんかな。

**デフォルトの名無しさん** · 2017/07/01(土) 10:52:05.29

Adaの型はどう？

**デフォルトの名無しさん** · 2017/07/01(土) 20:53:28.76

>>154
また話の流れ無視してケチつけてる
ちゃんとしてるって意味だよ

**デフォルトの名無しさん** · 2017/07/01(土) 22:05:29.59

ケチつけたいだけのガガガガイジの相手すんなよな

**デフォルトの名無しさん** · 2017/07/01(土) 22:57:47.40

競争に勝つためにケチをつける自由がある
負ける自由もある
好きな方を選べ

**デフォルトの名無しさん** · 2017/07/02(日) 00:11:43.12

あ、そう言うこと言っちゃう？
おいらのライブラリ(>>84-85)の肝はmfputとmfwriteだが、結局他の言語で同じ様な関数作ってない。
当然だ。
Haskellは手続き型言語のforにあたるmap系の関数もそのまんま関数だし、Haskellだと自然に出力系は最後尾に追いやられるから関数化しやすいんだよ。

普通の言語は処理しながら出力する。
確かに効率が良い。
だが、再利用し難い。

今時のPCなら効率より再利用性のが重要だと思うんだ。
異論は認める。

**デフォルトの名無しさん** · 2017/07/02(日) 01:00:22.98

大きなファイルを処理できないことで再利用性が大幅に低下するとは考えないのかな?
再利用の機会の多いものであれば少々手間をかけても効率を上げる価値があるケースもある

**デフォルトの名無しさん** · 2017/07/02(日) 01:20:46.16

LispとPrologの構文は汎用性があるからパーサーの再利用が重要だよ
文字列処理のような新しいパーサーを作る機能は重要じゃないよ

でも文字列の処理を書いてしまったらもう再利用を語る資格はないと思う

**デフォルトの名無しさん** · 2017/07/02(日) 07:23:22.14

>>161
何度も書いた気はするんだが、遅延評価でメモリに溜め込んで出力してる様に見える処理も、
実際に火必要に応じて出力しながら処理してるから、.実際に溜め込んじゃうreverse使う様な処理じゃなければ大きなファイルも扱えるし、その気になればreverseな処理もCのfseek相当の関数もあるから克服出来る。
ただ、そこまで大きなファイルなら、Cで書いた方が速いの分かってるし適材適所。

**デフォルトの名無しさん** · 2017/07/02(日) 08:20:48.27

>>163
それはちゃんと出力先があれば、の話なんだよな。
出力を怠るとメモリがお漏らししちゃうぞ。

**デフォルトの名無しさん** · 2017/07/02(日) 09:08:10.92

出力先がない状況って何ンゴ？

**デフォルトの名無しさん** · 2017/07/02(日) 09:28:31.60

>>160
mapに出来てforに出来ない事って何？

**デフォルトの名無しさん** · 2017/07/02(日) 09:46:22.26

明らかに>>122の方が可読性が高い件

**デフォルトの名無しさん** · 2017/07/02(日) 09:53:43.24

forに出来てgotoに出来ないことって何？

**デフォルトの名無しさん** · 2017/07/02(日) 09:54:28.82

もうjavascriptだけで良いよ

**デフォルトの名無しさん** · 2017/07/02(日) 09:55:33.26

>>168
ライブラリ化や可読性の意味でだよ

**デフォルトの名無しさん** · 2017/07/02(日) 09:58:49.45

ちなみにHaskellではforMとmapMは引数の順番が逆なだけ

**デフォルトの名無しさん** · 2017/07/02(日) 11:33:32.10

fmapと内包表記とdo記法は外見が違うだけ
javaとscalaとkotlinみたいなもん

**デフォルトの名無しさん** · 2017/07/02(日) 12:30:20.47

>>166
値を返せない。
関数合成出来ない。

**デフォルトの名無しさん** · 2017/07/02(日) 12:36:37.05

>>173
今時はyieldとかあるんやで

**デフォルトの名無しさん** · 2017/07/02(日) 12:39:37.96

値を返せないのは、getterを作るなというOOPの教義のせいでもある

**デフォルトの名無しさん** · 2017/07/02(日) 14:28:11.11

>>173
老害を自覚しましょうね

**デフォルトの名無しさん** · 2017/07/02(日) 15:37:42.58

pythonのyieldはStopIterationが気持ち悪い
ではnullを返せばいいかというとそれも気持ち悪い
値を返せない空気に逆らうのは楽じゃない

**パシュー** · 2017/07/02(日) 16:23:07.20

スレ違いであればすみません、どなたかわかる方いらっしゃればお願いします。

先日、営業電話があり、お宅のところはau光を利用してますよね？
→今まで、この手の電話で言った覚えが無い。ただ、au光は確かに利用・・・
何故、わかるのか問いただしたところ、相手からこちらの固定電話に電話するときや、
メールに送信するときの反応、時間、信号？跳ね返りの反応？でわかりますとの回答。
確かに先日、某サイトから携帯とセットでネット環境の見直しとして、
問い合わせはしましたが、果たして、相手からメールアドレスを
送信した時の反応や送信までの時間、
電話が繋がるまでの少しの時間での反応などで分かるものなのでしょうか？

ちなみに携帯の番号は教えてません。携帯であればドコモやauなどとあたりをつけることはわかるのですが…
どなたか教えて下さい！

**デフォルトの名無しさん** · 2017/07/02(日) 18:05:16.33

選択肢が少なけりゃあてずっぽでいいだろｗ

**デフォルトの名無しさん** · 2017/07/02(日) 18:06:59.55

>>178
スレ違いどころか板違いだが、結論だけ言うとわからない
単に名簿屋から買いましたって言いづらいから、素人騙しでそう言ってるだけ
続きはヤフー知恵袋でやれ

**デフォルトの名無しさん** · 2017/07/02(日) 21:50:57.08

>>174
yieldとか書く時点でダルい。
そんな速度変わらんのに、なんでそんな書かなあかんねん。

**デフォルトの名無しさん** · 2017/07/02(日) 22:22:57.06

>>176
まあ若いと言えない年になりつつあって20代の頃に比べりゃ覚えが悪くなってる自覚はある。
それでもC/C++、VB(.net含む)、Java、C#、Python、Ruby、smalltalk、Delphi含むPascal、もちHaskellは割と使えるぞ。
なんと無く分かっただけなのはLisp、Prolog、Erlang。
関数論理型言語Curryはもうチョイメジャーになったら本格的に覚えたい。

でもな。
学習と挫折繰り返した末に到達したのは覚えた言語の数じゃないって事だ。
知るべきはアルゴリズムや文法じゃ無い。(いあ、後々覚えなきゃだが)
作りたいアプリに対する周辺知識。(ファイル構造だったり、アプリにしたい事象に対する知識)

**デフォルトの名無しさん** · 2017/07/02(日) 22:26:25.12

あ、x86とARMのアセンブラもか。

**デフォルトの名無しさん** · 2017/07/02(日) 22:31:49.24

てか、Haskellのお陰でクイックソートがやマージソートがどう言う動きしてんのか理解出来たんだよ。
そう言う意味じゃCやJavaのアルゴリズム本みたいにコード示して終わりじゃ無くて、超初心者向けのどう言う動きですって動きだけ説明してる本のが有用だわ。
それ読んでコード書けない程度の抽象的な考えが出来ない(おいらみたいな)奴はプログラマの才能無い。

**デフォルトの名無しさん** · 2017/07/03(月) 00:03:55.72

Haskellのinplace quicksortって可読性低くて冗長じゃん
Haskellerはあんなのが読みやすいの？

それとも、全く実用にならないquicksortのコードみて簡潔だと思っちゃったタイプ？

**デフォルトの名無しさん** · 2017/07/03(月) 00:05:35.20

再帰のクイックソートは理解しやすいからな
実用性はともかく

**デフォルトの名無しさん** · 2017/07/03(月) 00:08:46.80

>>185
うい。
TDNクイックソートで簡潔だと思ったタイプ。
遅いって分かっててもね。
動作さえ分かれば他の言語で書けるんじゃよ。
そしたら実用的になる。
LL的な使い方なら速度必要無いから、これ以上簡潔なものはない。

**デフォルトの名無しさん** · 2017/07/03(月) 00:37:29.08

C のコードより haskell のクイックソートのが理解しやすいって
本気で言ってんの？

**デフォルトの名無しさん** · 2017/07/03(月) 00:46:37.45

妙なハードルつけてそれは本当の理解じゃないとかいうガイジ湧いてきたか？

**デフォルトの名無しさん** · 2017/07/03(月) 00:49:28.31

Cのクイックソートも悪くないよな
たった一個の配列を部分部分で触っていくだけ
範囲きめてピボットきめて交換、の繰り返し
メモリの使用に余計なところが無いからスカっとする

**デフォルトの名無しさん** · 2017/07/03(月) 08:07:49.86

>>189
空間計算量とか知らない低脳君はアルゴリズムの話しに入ってこないでね

**デフォルトの名無しさん** · 2017/07/03(月) 08:47:12.79

>>191
勝手に相手の理解度決めつけるガイジはレスしないでね

**デフォルトの名無しさん** · 2017/07/03(月) 08:49:31.61

まずこの話計算量関係ないからな
二重の意味でガイジやね

**デフォルトの名無しさん** · 2017/07/03(月) 08:57:49.58

>>193
いやいや関係あるからw
in-placeって文字も読めないのかよ
図らずも君の低脳度もより明らかになってしまったね

**デフォルトの名無しさん** · 2017/07/03(月) 08:59:51.73

>>194
in-placeの話してるのお前だけだから
自分の話したいことと人が話してることの区別もつかないとか凄いな

**デフォルトの名無しさん** · 2017/07/03(月) 09:05:27.81

>>195
だから低脳はアルゴリズムの話に入ってこなくて良いって
ドカタは用意された関数呼び出すだけなんだから

**デフォルトの名無しさん** · 2017/07/03(月) 09:07:05.32

でもO(n)とO(n log n)の区別もつかない低脳が次世代言語について語ってるって面白いな

**デフォルトの名無しさん** · 2017/07/03(月) 09:11:01.34

>>196
周り見ろよ。今そんな話してるのお前だけだぞ
話に入ってきたのはお前だ
あと2回目だけど勝手に人をin-placeのクイックソート理解してない扱いするのやめてね。流石に不快だから

**デフォルトの名無しさん** · 2017/07/03(月) 09:31:49.69

>>198
ああゴメンゴメン
>>189がin-placeを「妙なハードル」とかとんでもない事言ってるから、つい言葉がキツくなっちゃった
ハードルどころか基本中の基本だよねw

**デフォルトの名無しさん** · 2017/07/03(月) 09:49:48.18

>>199
ああそういうことね
ハードルはin-placeを指して言ったんではないんよ
ID:19kDKEGSはHaskellのコードで何をやってるか理解してから普通のクイックソート理解したみたいで、そこに>>188が来たから理解というものに妙なハードルというか拘りみたいなものを持っていると言いたかったんよ
たしかにハードルっていう表現はあんまり良くなかったな