次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
いざ、語ろうぞ。
スレタイ超過のため、一部省略。
その他もウェルカム。
前スレ
次世代言語議論スレ[Go Rust Kotlin Scala]第4世代
http://mevius.2ch.net/test/read.cgi/tech/1492631007/ >>826
テスト環境用意してくれるんだ。良い会社じゃん。
そっちのほうがいいね。エクセルでエビデンスとかしんどすぎるし
役に立つのそれって感じだし >>827
用意するし、ヤバイから台数増やして!ってあとから言われたら、貸出機出払ってても、少なくともうち来たらテストできるようにゲストカード用意するよ。
エクセルというか文書ファイルは必要悪と言うか、製造業は「いざとなったら手でできる」にこだわる側面もあるから、チェックシートで欲しいってのもある。
その辺汲んで、自動テストのテスト仕様と、自動テストで行うテストと結果を出してくれたら無理矢理でも俺通してきた。
東日本の震災でも、九州の震災とか豪雨でも、非常事態対応しながら開発したり、そもそも対応での不整合影響範囲推定とかせなならんかったし、あれは要る。 >>830
Pyplot と Gadfly と Winston どれがいい? Winston なんかあったのかよ
俺はGadfly使ってたけど特に理由はないなあ
Pyplotも悪くはないけどなんとなく使ってなかった テストとか仮想環境でしかしてないわ
本番も仮想環境ばかりだけど
モノにもよるか 震災が起きると動かなくなる自動テストって何だよ(驚愕) 彼はADHDだから問題の切り分けが苦手なんだろう
大目に見てあげなさい >>834
すでにディーゼル発電機回ってるような状況で、本番機の分しか電源取れないような時に、テスト環境まで起こしてられん。
>>835
切り分け得意だよ。あとバグ出し。
むしろ多動だからなのでは? >>830
どう見ても汎用言語じゃないんだが。。。
RとかMathematicaの分野の次世代言われてもな。。。 今fortranで量子化学のプログラムのボトルネック部分書いたんだけど、バグ取りしんどいわあ。
Juliaで書けって話だけど、Juliaコードは他言語からの呼び出し微妙なんだよな >>838
そういう用途ならFFIじゃなくてファイルだけ連携する伝統的なバッチでいいだろ
その方がリトライや並列化も簡単だし >>839
渡さないといけない波動関数情報が4GBとかになってディスク書き込みにえらい時間がかかるので、ハードディスク書き込みは最低限にしたいんだけど、なんか良い方法あるもんですか? >>840
RAMディスク作るとかRAIDやクラウド使うとか >>840
tee的なコマンド作るといいんでないの? >>841
あんまり詳しくないんだけど、/dev/shmにファイル作って書き込むみたいなもんです?
>>842
??? Cは呼びやすいっちゃ呼びやすいんだが
関数のプロトタイプもろもろがヘッダファイルで定義してあるから
ヘッダファイルの移植が面倒だなぁ
何かライブラリのインターフェースに関して
統一的なフォーマットが欲しいと思わなくもないけど
どっちにしたって関数の呼び出しに必要な構造体とかも
ヘッダファイルで定義してあるし、どうにもならないんだろうな
標準入出力でやりとりするのもタルいし
WindowsならCOMとかあるけど・・・ てか、それくらいプリミティブな仕組みだから呼びやすいわけだ。 >>844
中間ファイル作りながら、次工程進めれば良いのでは?って。
HDDに書き込むのはその端末自身である必要も無いだろうし、別の端末にやらせても良いかと。
teeコマンドは、標準入力からの入力を、ファイルなりなんなりと標準出力に出すコマンド シミュレーションなら入力の内容は全部まとめて読むだろうからパイプを使うのはあまりメリット無いでしょ
デッドロックの原因になるから作法的にも好ましくない
単純にファイル名を起動引数で渡した方がいい >>841が非常に適切なアドバイスをくれたから、俺の書き込みでも割と通じてるんだと思ったけど、
>>844、>>847には通じてなさそうな気がする
>>848には通じてる >>849
通じてるよ。ただファイルで渡しても良いけど、出来上がった暁には全部流したいだろうなと思ったんだが。 >>850
流す?よく分からんけど、FFIの代わりの話ししてるのになんで標準出力にもHDDにも出すことになってるんだ??????
>>851
double precisionで構成される配列を圧縮…… >>852
標準出力とは限らんよ。
だからtee「的」と言ってるんだが。 何この人。結局何を伝えようとしてくれてるのか全く分からなくて怖いんだけど 自分の頭が混乱してるのを
2chに書き込むことで整理しようとしているだけの人だからね つか素直にメモリ詰むかSSD買ってこいよ
それも駄目ならinplaceな方法にでも書き換えるしかない >>858
いや普通にFFI使うわ。なんかFFI微妙そうに言われたからFFIよりいい方法があるか聞いてただけだし。
>>841の後も長々やっちゃって申し訳ない そんなにFFIが面倒ならmmapとexecとか、端的なやりようあるよ
つか俺もストリーム処理にでもした方がいいんじゃねえかと思うが FFIは不安定になったりビルドが面倒になったりデバッグも開発も面倒だったりで極力やりたくないわ
ファイルやパイプはもちろん、RPCやMQを使う手もある 設定より規約ってのを実践すればFFIも面倒ではないだろう
パイプには型がないから型を宣言する設定ファイルもない ファイルベースだと分散処理とかクソ簡単
俺も学生時代シミュレーションやってたけどMakefileのjオプションで並列化してる人もいた え?分散処理するならファイルシステム使うとか悪手中の悪手でしょw ストリーム処理にできるかどうかって何やろうとしてるかによるでしょ
長大テキスト処理的なものかどうかはわからないのにパイプやストリームがいいって言っても意味なくない?
質問がどういうデータをどう処理するってのを専門外の人に書いてないのも返答が発散する原因の一つではあると思うけど >>865
バッチ処理なら普通に使うでしょ
Hadoopとかファイル使いまくりだよ >>866
シミュレーションで波動関数情報渡すって言ってるから、
普通に考えてストリーミング処理できるようなデータではなく全部一括して扱うもんだろう
複数件のジョブをまとめてバッチとして渡してるとかなら分ける余地はあるかもしれないけど 波動関数情報4GBをアップロードして、必要な分だけシーケンシャルかランダム・アクセスしたらいい 規格化されとるならtとx1でアクセスできる方が便利では?
確率密度で欲しいならちとめんどいが。
全然ジョブ別けれると思う。 >>870
早く発電する作業に戻らないとテストできなくなるぞ >>871
発電機回すのは俺のやる事じゃないよ。
主任技術者がやる事。 この人がまともに働けるってすごいことだと思う
周りの人が理解してサポートしてくれている恵まれた環境なんだろうな コミュ力と文章力はほとんど関係ない気がするので文章だけ見てもよくわからないな >>873
周り良い人だよ。俺含め変なやつ自体が多いけど。
人間、三十人ぐらい集まれば最終的に良い部分同士でキレイにまとまる。
>>874
文書として書くならちゃんと書くぞ。 >>868
趣味で超適当な流体シミュレーションぐらいしか作ったことないけど全部一括して扱うもんだろうという推測には同意する
たとえば画像処理でSIFTとかの特徴点抽出アルゴリズムを使いたい場合に、ストリーミングで実装することに可能性やメリットはあるのかなぁ。
なんでもかんでもストリーミングで実装して効率良くなるなら極端な話スパコンなんて要らないじゃんってことになると思うんだけど 直受けの50万 客:いつまでもうちにいていいよ
3次受けの50万(客は70万払ってる) 客:短期延長していい?
5次受けの50万(客は110万払ってる) 客:作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事 余り物の仕事を紹介してくる。40万円代でやってくれと
これならJIETから3次でいったほうがいいな
446非決定性名無しさん2017/08/02(水) 22:12:48.95
JIETに毎月5千円払えば3次から入場できるだろ?
高額をうたうフリーランスのサイトはだいたい5次から45万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした
473非決定性名無しさん2017/08/03(木) 15:21:30.71
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。
372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む >>876
そら富豪プログラミングが一番いいわ
ただリソース削ろうなんて貧乏性な考えしてるんだから他に方法ねえだろ >>878
そういう問題じゃない
ランダムアクセスされるデータをどうやってストリーミング処理するのか あと、>>876が言ってるスパコン云々は
データをストリーミング処理できるということはすなわちデータ件数に対して線形時間で処理できるということを意味する
全ての問題がそうだったら世の中に重い処理なんか存在しないからスパコンなんか要らないよね?ということだと思う >>879
意味不明
メモリ転送だけが問題なら転送だけストリームすりゃいい
もとの文脈無視してただ叩きたいってだけか? >>880
んな当たり前の事ドヤ顔で語る前に
前提と問題ぐらい読み解こうな >>876だけど元の質問してる人とは別人だよ。
ストリーミング処理って普通は大きなデータをストリームで流して一部だけ処理していくことで大きなデータを全部オンメモリにしなくても処理できるから嬉しいよねっていうことで
ストリームに対して処理する実装のことを指すと思うんだけど。
元々の話はFortranはデバッグがきついからJuliaで書きたいけどデータの受け渡しイマイチだし他にいい方法あるか?って話だと思うのでリソースを削ろうって話ではないと思う
ただ、データが4GBとデカいんでmemcpyとかディスク書き込みとかは明らかなメリットがなければしたくないっていうだけの話で
そもそもメモリ転送だけストリームっていうのは、ストリーム処理と言えるのかな?そして、本来はメモリ転送も無い方がいいに決まってるので。
スパコンの例はまさに>>880の言ってるとおり。物理現象の時間発展をシミュレーションすることが目的のプログラミングなんかは瞬間瞬間のデータ全部が相互に影響を与えあっているような
モデルを用いて実装されるだろうから、全部がオンメモリでランダムアクセス可能でなきゃそもそも実現が難しいと思うのよ。今見える範囲だけ処理するというストリーミングのやり方では原則的にはうまくいかないと思う。 文脈が違うから違う結論になっただけと言ってるのに、なぜくどくど説明したがるのか…
まず最初から素直にtmpfsでも高速なSSDでも使えばすぐ済む話
まさかそれすら最初から思いつかないってことはないだろう
でもグダグダ言ってるんだから、代わりにメモリや高速ストレージに金やリソース割くのが無理って事だろ
なら共有メモリにでもするか、処理単位を分けストリーム処理でもしろって話
で、ほしい処理主体がストリームじゃなかろうが割当は細く切り出しながら渡す必要あるから、どう言い繕ったってストリーム化だよ
いちいち言葉尻につっかかるあたりマウントしたいだけだろうが >>838は>>860じゃないかな
「FFIを使う」「FFIよりいい方法があるか聞いてみただけ」ということで話は終わっているような 話は変わるけどFFIやRPCなどのインターフェイスを抽象化して多言語で共通に使える仕組みがあればいいのに
ThriftやgRPCみたいなのはサービスとして動かさなきゃいけないし、
Javaや.NETみたいなのは理想だけど仮想マシンに縛られるし なんだかんだ言ってjs or TypeScriptが最強な気がする
機械学習すら手軽に始められる言語になり始めてるし
https://pair-code.github.io/deeplearnjs/
ここ最近のES2015以降言語仕様の進化はいい方向に進んでいるし
パターンマッチングとか入り始めたらマジでこれでいいってなりそう。 周辺のエコシステムがちっともエコじゃない
ボイラプレート使わないと、めんどくさすぎてまずスタートラインにすら立てないという
おにちく仕様
ちゅか、フロタイプかタイプスクリプトを標準にしろ
生JSはできない >>888
なんかすごい懐かしい言葉が色々浮かぶけど、どれも対して成功してないな。
逆にhttpがここまで伸びたのも凄いが。 ハイパーテキストじゃなくてもhttpプロトコルだしな。 >>885
「処理単位を分けられる処理」なのかは把握した上でストリーム化を勧めてるんだったらわかる。
質問者の望む処理がそういう処理だと思ったってことである程度どうやって分割するかも予想がついた上でストリーム処理にした方がいいって言ったってことだよね?
マウンティングとかじゃなくてさ、問題を的確に把握する前にアドバイスしたってしょうがないだろって思ってるだけだよ。 >>888
結局、各言語でメモリの取り扱いが異なるわけだから、.NET みたいなことする以外に
解決方法なんてないだろう。
メモリの取り扱いを抽象化するってのはどうしたって結局のところ性能的に無理が生じる。 847 あ[sage] 2017/08/18(金) 01:19:03.96 ID:WQb8VpS1
>>844
中間ファイル作りながら、次工程進めれば良いのでは?って。
HDDに書き込むのはその端末自身である必要も無いだろうし、別の端末にやらせても良いかと。
teeコマンドは、標準入力からの入力を、ファイルなりなんなりと標準出力に出すコマンド
849 デフォルトの名無しさん[sage] 2017/08/18(金) 09:59:20.00 ID:64r0PFl5
841が非常に適切なアドバイスをくれたから、俺の書き込みでも割と通じてるんだと思ったけど、
844、847には通じてなさそうな気がする
848には通じてる
850 あ[sage] 2017/08/18(金) 13:16:32.57 ID:WQb8VpS1
通じてるよ。ただファイルで渡しても良いけど、出来上がった暁には全部流したいだろうなと思ったんだが。
852 デフォルトの名無しさん[sage] 2017/08/18(金) 15:56:35.28 ID:64r0PFl5
流す?よく分からんけど、FFIの代わりの話ししてるのになんで標準出力にもHDDにも出すことになってるんだ??????
855 あ[sage] 2017/08/18(金) 21:59:17.07 ID:WQb8VpS1
標準出力とは限らんよ。
だからtee「的」と言ってるんだが。
856 デフォルトの名無しさん[sage] 2017/08/18(金) 22:15:46.41 ID:64r0PFl5
何この人。結局何を伝えようとしてくれてるのか全く分からなくて怖いんだけど
明らかに話が噛み合っていないのに「通じてるよ」とか、855の受け答えとか、話し通じないガイジ丸出しで大変面白い >>897
なんの会話もせず、レス拾って文句つけるだけとは随分面白くて有意義な書き込みだなぁ。 >>895
そちらの言い分は分かるが、俺の言いたい事は違うよ
分割の話はFFIを界面にしてる点を取っ掛かりに言ったに過ぎない
不明な仕様という点を踏まえて、より一般化したの代替の提案してるだけ
要するに言外の事に突っ込んだ話はしてません このスピードのスレで単発煽りとか、普段はID真っ赤のガイジですって自己紹介してるようなもんじゃん…… >>901
もしストリーム処理的なものを一度も考慮に入れたことがないんであれば、ストリーム処理で実装可能かどうか考えるのも一つの手かもね、
ぐらいの意味であったということかな?それなら納得します。 俺たちのスピードについてこれない香具師がいるようだね いつまでストリームのはなししてるの。
ストリームならRxだろjk 光のオーロラ身に纏い
君は闘う人になれ
傷つことを恐れたら
世界は悪の手に沈む
ネットバトラー爆誕である >>903
ニュアンスがやっぱり違うぞ
金もメモリも使わずかつ実装が簡単な代替えとなるとそうなるって話
HDDの速度考えれば都度転送のがまだマシだろ
本当はtmpfsが手っ取り早いけど 名古屋から山口組の6代目が出たんだし、SKEにも頑張ってほしい
◆AKBは近代ヤクザのシステムを導入しているとしか思えない◆
http://robo-mae.com/2017/06/20/
なんか本職のヤクザ?が書いてる裏事情ブログでおもろいから読んでるんだけど、
ぽいけどこの記事だけ的確過ぎて笑ってしまった。
この人は結構ヲタなんだろうけど、組内では内緒にしてるのかな? パイプとかRPCでやるなら、
プロセスAがデータ作り終わったら、
プロセスAがデータを一定量、プロセスBに送って、
プロセスBはそれを受けてバッファに置いて、
プロセスAは送った分、確実にメモリを開放して、
全部送り終わったらEOF送って、
プロセスBはEOFで走り出せばいいんじゃないの?
その送受信フックしといたら、プロセスBだけもう一回走らせるのも簡単だし、別の計算機でプロセスB動かすのも簡単だし、エビデンスにもなるのでは? 全部送り終わったら、のところ、全部送り終わってなければ、また「一定量送って」にループね。 >>910
>送った分、確実にメモリを開放
ってどうやるんだろ >>912
Fortranなら、allocatableで宣言して、allocateで適当な「一度の量」単位で確保して使って、送ったらdeallocateで開放すりゃいいんじゃないの?
pointerで宣言してるならちと考え方変えねばならんかもしれんが。
あと尻から送ったほうが良いかも。
GCある言語だったら開放待ち作らなきゃなんともならんな。 >>912
mallocじゃなくてシステムコール使う 久しぶりに覗いてみたらまだこの基〇外いたんだwww
俺が勉強している間も遊んでいる間も色々している間もずっと書き込んでいたんだねww 勉強したり遊んだり仕事したり2chに書き込んだりしてるだけだがなぁ。
一度に1つの事しか出来ないんだろうか。 賑やかしでいいんじゃないの?
黙ってたら進まんかHaskell信者が踊り狂うスレなんだし。キャットドア()の検証()するスレで良いの?
あと、そもそも盛り上がってたら静観してあんまり書かんぞ。 結局Haskell最強ってなるの。
正直あんまり仕事で使ってる感じしないけど。
なんか研究者が戯れに使う感じ。そもそも何に向いてる言語なのhaskellって エンジニアガイジ再訪。Part4より
905 :デフォルトの名無しさん:2017/05/31(水) 06:14:00.96 ID:wEozaoTa
>>879
では、具体的にGHCが実行時型情報を必要とするケースを挙げてみろよ。
言っておくが、パラメトリック多相は全てコンパイル時に解決されるし、
型クラスによるアドホック多相も、あれは関数オーバーロードの形式化だからな。
関数オーバーロードはコンパイル時に解決されるぞ。
さあ、具体的に挙げてみろよ。
908 :あ:2017/05/31(水) 09:15:21.09 ID:dc+IbjjD
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。 >>920
仕事で使ってるよ
ファイルのバリデートチェックとか
あとはネットワーク構成の論理矛盾がないか調べる内製ツールもHaskell >>920
結論は「〜言語最強」とか言ってる輩は馬鹿ってことかな。 >>924
まぁ向き不向きの問題ってことかね。
haskellはバリデーションチェック系が得意っていうのはやっぱりパターンマッチングで宣言的にかけるからってことなのかね。
パターンマッチングはrustとかelixirとかでもできるわけだから
haskellじゃなきゃダメってことはなさそう。 いやHaskellのが楽
RustなどにQuickTestのようなものはない レス数が900を超えています。1000を超えると表示できなくなるよ。