次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
いざ、語ろうぞ。
スレタイ超過のため、一部省略。
その他もウェルカム。
前スレ
次世代言語議論スレ[Go Rust Kotlin Scala]第4世代
http://mevius.2ch.net/test/read.cgi/tech/1492631007/ >>96
お前さっきからメモリの話ばっかりしてるじゃん…
それに再利用については、途中からIO入れたら使えないよね?
っていうツッコミに全く反論できてないし
言ってる事めちゃくちゃだぞ >>97
「関数型で書いてもメモリを一定量以上使わない」を「空間計算効率が良い」と解釈するのはいくら何でも頭発達しすぎでしょ…… ちなみにCで書こうがIOの問題は付随するので変わらない
そもそもパーサをTemplateHaskellとけ使って書いてるレベルならまだしも Haskellで型注釈も無しじゃコンパイル遅すぎだし、
リストを配列代わりにしたり、String使ってテキスト処理してるレベルじゃLLより遥かに動作遅いだろ
普段から使ってるとはとても思えない >>98
いつ帯どこに突っ込んでんだよ
メモリに溜め込む云々は明確にそういう話だろ え、まさか本当にストリーム処理書けないとかそんな話?
いくらなんでも違うよね? >>97
途中からとはなんぞな?
CUIにしてもGUIにしても、HaskellだとIO部分と純粋部分は強制的に分けて書かざるを得ないから何を言ってるのか。。。
(mfwriteでは同名ファイルに書き込めないので一旦別名で保存して、別名で開く->元の名前で保存ってしてるけど、そう言うのはIOが途中で挟まるってのと違うのん?)
ある意味手続き型言語みたく(と言うか他の関数型もそう言う意味じゃ途中でIO挟まる?)、途中でIO挟まらないパイプみたいな処理にCUIでもGUIでも強制されるのがHaskellの一見不便で長所。
mfptnからmfputとmfwrite作ってる通り、関数に渡す出力先を差し替えるだけで良い。 >>100
それはLLとは言え、手続き型言語がハードの仕組みに依存してるから、Haskellと同じ程度にライブラリ化進めると、普通に書くより遥かにメモリに負担かかるって意味。
Haskellがメモリ効率が良いって言ってるわけじゃ無い。 >>103
既存の物を状態を扱うように変更するのにコスト大きい、と突っ込まれとるよね
あとGUIは純粋に分けることを強制される、なんて簡単に終わる話じゃないんだよね
新規に同規模の実装を強制されるわけで >>104
だから結局空間計算量の話ししてるじゃん… ちうか、出力先を変更する云々なんて別にHaskell関係なくないか?
どこがHaskellでしか出来ない処理と言ってるわけ? >>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で気持ちよく書く。 やっぱり本気でパイプのようなストリーム処理がLLで書けないと思ってるのかな
今時はラムダなどのストリーム処理なんてJavaですら標準でついてるってのに
>>108
何が「ほんまもん」なんですかね
もしかしてどっちもO(1)で一緒とか言いたいの?
空間計算量って、それ自体はO-notationでの表記のことじゃないぞ? 「副作用で世界がどんどん変わって行くのを俺が全部コントロールして阻止しなければならない…
そうでなければこの世界はバラバラになってしまう…」
「どうしたんですか?先輩」(もぐもぐ
「おお後輩!…なんだそれ?」
「売店がパンじゃなくて弁当扱い出したんですよ
ゴミかさばるから売店とこで捨てろですって。
まぁ、どうせ僕が一括して持ってくんでしょうがw」
「後輩」
「はい?」
「カレーある?」
「たしか」
「じゃあ、それ一つ」
「はい」 >>107
うーん。。。出力先もだけど、差し替え易さとか、処理対象の単位を行き来し易いとか。。。かな?
ループだとファイル単位、行単位、文字単位って決まっちゃうと、中々そこから抜け出せないけど、例えば複数ファイルの行で一番長い行を調べたいとする。
(実はCで上の逆順コード書く際のバッファの大きさを決めるために書いた)
最初、トーナメント形式に各ファイルで一番長い行出させて、そこからさらに一番を決めて出力してた。
んで、途中で全ファイルの行の長さ出た時点で一位決められるじゃん。と、数値のリストのリストを平坦化して一気に一位決めた。
そう言うループじゃ無くて、悪魔でリストのリストを受け取って〜。。。って考えると簡単に行単位とかそう言う枠を超えられる。
LLでも出来るだろうけど、思いつき易い。 >>110
いあ、書けるでしょうよ。
ただ柔軟性?こう、スタイルが決まっててあんま動かせない感じを受ける。 >>109
言いたい事はわからんでもないけど、そんなにhaskell使いやすい?
自分もHaskellは複雑な構造の解析とか、何か本質的な部分の問題解くときにghci使う事あるけどさ、
実装はやっぱりpythonとかのが楽ってなったよ
Stackやcabalの設定編集も面倒だしコンパイル遅いし
mapM_あたり使うような物で純粋を目標にしてると、本末転倒になる事が多いし >>112
ああなるほどね
難癖つけてる奴の同類か >>114
ポイントフリースタイルとの組み合わせは確かにHaskell特有だけど、
個人的には実装はIOの文脈で、パイプ演算子とパターンマッチを使える
F#やLiveScript(altJS)のような言語方が楽だと思うぞ >>115
なんつーか、さすがにGUIとかはC#使うわってなるけど、確かにコンパイル遅くて微妙に感じもしたけど、上のライブラリみたくガンガン関数化すればPythonでループのシーケンスにargv[1:]ってしてー。。。
逆順だとReversed(list(sys.argv[1:]))でー。。。とか調べないとな場面が度々ね。
んで、毎回複数ファイルから読み込まるのにforって書いて、行毎だとまたfor。。。
Haskellもライブラリ作る前は似たり寄ったりだったけど、ライブラリ書いてからはmfputにファイル名のリストと、各ファイル向け(1ファイル向け)に処理させたい関数渡すだけで大体のツール作れる。
多少パターンが特殊でもmfptnで対応出来る。
ループ的なのを関数に押し込んで、開きたいファイルと処理させたい関数だけ気にしてれば良くなった。
(逆にサポート外のパターンには無力だが。関数化は使い方も規定しちゃうから仕方ない)
Pythonだとあんまここまでライブラリ化出来る気がしない。。。
PythonやRubyの書き捨てでも楽だって思ってたけど、多分もう戻れない。 まずなー>>98に>>100をいっちゃう時点でなー
>>96で「空間計算効率が良いなんて一言も言ってない」って明言されてるにも関わらずこんなこと言ってる時点で読解力お察しだからなー 相手の意図を組めないという点ではエンジニアガイジと同類っぽいなー そう。
空間計算効率の話自体はしてても、Haskellと同程度にライブラリ化したらLLが今までより空間計算効率が落ちる(もしくはイテレータ地獄になる)って言ってるだけで、Haskellの空間計算効率が良いなんて言ってない。 初めて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) })
} >>122
kotlinのコードこのスレで初めて見たし、他のスレでもここまでまともなの見なかった。
thanks.
わざわざ見つかった文字列を赤文字にする所まで再現してくれるとは。。。
もうHaskellに惚れちゃってるからメインにならんだろうけど、確かに筋は良さそう。
GUIなコード書くのには良いかもしれんね。
行単位で受け取って行単位で出力する辺り、やっぱ手続き型言語と感じるけど。
だからこそ効率が良くて、そこを意識するからこそ柔軟性の限界感じる。
HaskellはStringが遅いだけで、バッファ効率自体は多分良い。
行単位とかじゃ無くて目一杯バッファに入れてると思う。
ByteString慣れないと説得力無いんだろうけど。。。
面倒いなぁ。。。
そこまでしないと勝負にならないなら、あんたの勝ちでいいよって思うもん。
手早く書けて使える速度なら充分だし。 >>119
明言してると言っても実際言ってるし
やっぱり難癖つけたいだけじゃん >>120
お前もうただ言い方に突っかかってるだけだろそれ >>118
引数の逆順でファイル読み込んで一つのイテレータにするだけなら、pythonならこれだけじゃね?
(x for f in argv[1:][::-1] for x in open(f))
これをイテレータを処理する関数の引数に渡せば、お前のやりたい事できてるよね? そうも書けるんだ。
でももうcatコマンドだったら
main = getArgs >>= mfput fs id
って書けば良いようにライブラリ作っちゃったし、もう良い。
mf = マルチファイル >>123
入出力関数が適切にバッファリングしてると思うけど? 逆順だとunlines.reverse.linesしないと改行が変になるから
main = mfput fs (unlines.reverse.lines)
unlines.f.limesパターンも良く使うから
main = mfput fs (fline reverse)
って書けるようにしたし。 あ、
main = getArgs >>= mfput fs (fline reverse)
だった。 >>128
うい、行単位でね。
Haskellは基本ファイルの中身を丸ごと文字列で受け取って、文字列で返すから、行って考えはナンバリングしたいとか、行単位で処理したいって思った時に初めてunlines.f.linesパターンで行単位に分解する。
なので出力するHaskellランタイム側にも行単位って概念が無い。 >>131
行単位じゃないぞ
単純に間違ってるから事実だけ書くけど まあ、そんな事してるからHaskellは遅いんだろうなってのはある。
文字単位でバッファ目一杯入出力するけど、加工過程で分解して戻してってしてるんだし。 >>132
なるけど、見かけのコードは行単位でも、バッファリングはそれとは別に行を越えて処理すると。
これは失礼。 >>130
さらに馬鹿だ。。。
寝惚けてる。
部分適用し易いようにfsが第二引数だから
main = getArgs >>= mfput (fline reverse)
これだけで良いんだった。 KotlinはJava標準ライブラリに対する拡張も上手い
Javaに背を向けたScalaとは違って、Java標準ライブラリの良いところ駄目なところを深く理解して
最小限でツボを押さえた拡張を入れてる
Scalaが一瞬で要らない子になったのも納得 >>126
ついでに言えばPythonのは逆順でもメモリに溜め込まないはずで、大きなファイルだとPython使った方がいいってことになる。
でも、今時のスペックで問題になる程溜め込む場面自体が無い。
小説100冊分が1ファイルに入ってやっとちょっと気になるレベルだから。
なら、より短く書ける方がいい。
コンパイル遅いつっても書き捨てレベルなら毎度毎度定型的にPythonで書いてる時間で終わってる。
自分でライブラリ作ってからは完全にLL的な使い方はHaskellで良いやってなった。
素のままだとPythonのが良いけどね。
自分でライブラリ作るかどうかが決め手だった。 複数のファイルを順番に読んでいって、特定の文字列が見つかるまで入力をそのまま出力する
文字列が見つかったら即終了
ってプログラムを、その自慢のライブラリで書いてみてよ 行単位なのはダサいといいながら自分のライブラリはべったり行単位に依存してるのが笑いどころだな
結局行単位が便利だと思う人が多いからlineSequenceみたいなユーティリティが標準で用意されてるだけで、
やってることはunlines.f.linesと変わらんぞ >>138
import System.Environment
import Data.List
import Myfunc
main = getArgs >>= (w:fs) ->
mfput (unlines.lines.last.(takeWhile (not.isInfixOf w)).inits) fs 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にすれば良い。 >>122 >>136
メインプロジェクトとしていろいろ試して選んだって感じなのね
androidの主力開発言語を急に乗り換える必要が発生したから当然だけど
(な?うざいだろ?by 某M社) OCAMLを.netで記法(not構文)変えて作りましたって感じ>F#
冗長記法だとOCAML互換性高いし ***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{ F# は 関数型らしい抽象化機能※ を持っていないのが欠点
抽象化は .NET ( C# ) 互換の抽象クラスやインターフェースで実現することができる
でも型推論が効かなかったり null 安全でなかったりして辛い
※OCaml では構造的部分型やモジュール抽象化
Haskell では型クラスや型族のこと 型だけを見ればC#とF#は同じだろ
Haskellだって型だけを見れば他の言語で同じものは作れる
型だけを見るのが王道
逆に型を無視してHaskellにしかないものを強調するのは邪道だから
惑わされるなよ 次世代言語でHaskell並にちゃんとした型システムが入ってる言語ってある? Haskell並ならちゃんとしてるというのは本当か?
ちゃんとしてないから「Haskell並」や「Haskellよりマシ」と言い訳するんじゃないか 構造的部分型が「ちゃんとしてる」かは大いに疑問
あんなもんドカタITで使ったら悪夢だろ >>151
Haskellの機能じゃないし、その上根拠もない >>150
静的型に限って言えばHaskellは上位でいいんじゃない?
強いて言うなら、TypeSynonymなクラスインスタンスぐらい言語標準で入れてほしいけど 中途半端な奴だな
オレが一位だというならまだわかるが
Haskellが上位だという主張の何が嬉しいのか 古い関数型言語関係の本だと、論理型言語が関数型言語の次の世代とか書いてて、まあ実際最近ワトソンやらペッパーやらAI関係で注目されてるのも論理型言語な訳で。
んじゃPrologはHaskellより使い易いんか?と勉強中。
早くもコレジャナイ感が。。。
もっと今時の論理型言語って無いんかな。 >>154
また話の流れ無視してケチつけてる
ちゃんとしてるって意味だよ 競争に勝つためにケチをつける自由がある
負ける自由もある
好きな方を選べ あ、そう言うこと言っちゃう?
おいらのライブラリ(>>84-85)の肝はmfputとmfwriteだが、結局他の言語で同じ様な関数作ってない。
当然だ。
Haskellは手続き型言語のforにあたるmap系の関数もそのまんま関数だし、Haskellだと自然に出力系は最後尾に追いやられるから関数化しやすいんだよ。
普通の言語は処理しながら出力する。
確かに効率が良い。
だが、再利用し難い。
今時のPCなら効率より再利用性のが重要だと思うんだ。
異論は認める。 大きなファイルを処理できないことで再利用性が大幅に低下するとは考えないのかな?
再利用の機会の多いものであれば少々手間をかけても効率を上げる価値があるケースもある LispとPrologの構文は汎用性があるからパーサーの再利用が重要だよ
文字列処理のような新しいパーサーを作る機能は重要じゃないよ
でも文字列の処理を書いてしまったらもう再利用を語る資格はないと思う >>161
何度も書いた気はするんだが、遅延評価でメモリに溜め込んで出力してる様に見える処理も、
実際に火必要に応じて出力しながら処理してるから、.実際に溜め込んじゃうreverse使う様な処理じゃなければ大きなファイルも扱えるし、その気になればreverseな処理もCのfseek相当の関数もあるから克服出来る。
ただ、そこまで大きなファイルなら、Cで書いた方が速いの分かってるし適材適所。 >>163
それはちゃんと出力先があれば、の話なんだよな。
出力を怠るとメモリがお漏らししちゃうぞ。 >>160
mapに出来てforに出来ない事って何? ちなみにHaskellではforMとmapMは引数の順番が逆なだけ fmapと内包表記とdo記法は外見が違うだけ
javaとscalaとkotlinみたいなもん 値を返せないのは、getterを作るなというOOPの教義のせいでもある pythonのyieldはStopIterationが気持ち悪い
ではnullを返せばいいかというとそれも気持ち悪い
値を返せない空気に逆らうのは楽じゃない スレ違いであればすみません、どなたかわかる方いらっしゃればお願いします。
先日、営業電話があり、お宅のところはau光を利用してますよね?
→今まで、この手の電話で言った覚えが無い。ただ、au光は確かに利用・・・
何故、わかるのか問いただしたところ、相手からこちらの固定電話に電話するときや、
メールに送信するときの反応、時間、信号?跳ね返りの反応? でわかりますとの回答。
確かに先日、某サイトから携帯とセットでネット環境の見直しとして、
問い合わせはしましたが、果たして、相手からメールアドレスを
送信した時の反応や送信までの時間、
電話が繋がるまでの少しの時間での反応などで分かるものなのでしょうか?
ちなみに携帯の番号は教えてません。携帯であればドコモやauなどとあたりをつけることはわかるのですが…
どなたか教えて下さい! >>178
スレ違いどころか板違いだが、結論だけ言うとわからない
単に名簿屋から買いましたって言いづらいから、素人騙しでそう言ってるだけ
続きはヤフー知恵袋でやれ >>174
yieldとか書く時点でダルい。
そんな速度変わらんのに、なんでそんな書かなあかんねん。 >>176
まあ若いと言えない年になりつつあって20代の頃に比べりゃ覚えが悪くなってる自覚はある。
それでもC/C++、VB(.net含む)、Java、C#、Python、Ruby、smalltalk、Delphi含むPascal、もちHaskellは割と使えるぞ。
なんと無く分かっただけなのはLisp、Prolog、Erlang。
関数論理型言語Curryはもうチョイメジャーになったら本格的に覚えたい。
でもな。
学習と挫折繰り返した末に到達したのは覚えた言語の数じゃないって事だ。
知るべきはアルゴリズムや文法じゃ無い。(いあ、後々覚えなきゃだが)
作りたいアプリに対する周辺知識。(ファイル構造だったり、アプリにしたい事象に対する知識) てか、Haskellのお陰でクイックソートがやマージソートがどう言う動きしてんのか理解出来たんだよ。
そう言う意味じゃCやJavaのアルゴリズム本みたいにコード示して終わりじゃ無くて、超初心者向けのどう言う動きですって動きだけ説明してる本のが有用だわ。
それ読んでコード書けない程度の抽象的な考えが出来ない(おいらみたいな)奴はプログラマの才能無い。 Haskellのinplace quicksortって可読性低くて冗長じゃん
Haskellerはあんなのが読みやすいの?
それとも、全く実用にならないquicksortのコードみて簡潔だと思っちゃったタイプ? 再帰のクイックソートは理解しやすいからな
実用性はともかく >>185
うい。
TDNクイックソートで簡潔だと思ったタイプ。
遅いって分かっててもね。
動作さえ分かれば他の言語で書けるんじゃよ。
そしたら実用的になる。
LL的な使い方なら速度必要無いから、これ以上簡潔なものはない。 C のコードより haskell のクイックソートのが理解しやすいって
本気で言ってんの? 妙なハードルつけてそれは本当の理解じゃないとかいうガイジ湧いてきたか? Cのクイックソートも悪くないよな
たった一個の配列を部分部分で触っていくだけ
範囲きめてピボットきめて交換、の繰り返し
メモリの使用に余計なところが無いからスカっとする >>189
空間計算量とか知らない低脳君はアルゴリズムの話しに入ってこないでね >>191
勝手に相手の理解度決めつけるガイジはレスしないでね まずこの話計算量関係ないからな
二重の意味でガイジやね >>193
いやいや関係あるからw
in-placeって文字も読めないのかよ
図らずも君の低脳度もより明らかになってしまったね >>194
in-placeの話してるのお前だけだから
自分の話したいことと人が話してることの区別もつかないとか凄いな >>195
だから低脳はアルゴリズムの話に入ってこなくて良いって
ドカタは用意された関数呼び出すだけなんだから ■ このスレッドは過去ログ倉庫に格納されています