次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
いざ、語ろうぞ。
スレタイ超過のため、一部省略。
その他もウェルカム。
前スレ
次世代言語議論スレ[Go Rust Kotlin Scala]第4世代
http://mevius.2ch.net/test/read.cgi/tech/1492631007/ 書いても書かなくてもよいというのが客観的事実だから
理系なら話はそれで終わり
それ以上踏み込むのは文系の仕事 >>609
なら最初からそう書けよ
> ScalaでもHaakellでも書くのが当たり前だぞ
エアプガイジ Ocaml自体は良い言語なの?
あんまり使ってるって人は聞かないけど >>613
よく知らないけど金融で使ってる人がいるらしいのと、最近機械学習で使ってる輩がいるらしい >>612
またお前か
ガイジガイジうるさいだけでなくただの知ったかぶりか ocaml, haskell の比較
ttp://d.hatena.ne.jp/camlspotter/20101212/1292165692
まあ極論抜きにして普通に考えればこういうことだろうなという印象。 >>618
この人は良く分かってるなあ
純粋言いながらunsafePerformIO使うって件はまさにその通り
結局このIO書くときの面倒さがあるから、ScalaやOCamlのが使いやすい印象になってしまう 割り切れば楽なのにと思ったりもするw
純粋とは副作用有りと無しを分けて書くことで
try-catchで正常処理とエラー処理を分けて書くようなものだ >>620
ちょっと脇道にそれるけど
try-catchって言うほど正常処理とエラー処理をきれいに分けられる?
goのようにその構文を捨ててる言語があるとこも考えると
いうほど価値あるのかなって思う。
あと関数型だとEither型とかもあるよね。 >>621
返り値が一つしかない言語では有能機能だった。多値返却が当たり前になりつつある今はもう…… >>622
まぁ。それでもリストなりタプルで返せば一緒だけどね。
前の会社の上司がphpの関数の返却値を必ず配列で返してたの思い出した。
言語としての基本方針がそうなっているかどうかだよなー。
結局誰かがそういう実装にしてもメンテする過程で混在しちゃったら地獄と化す elixirの言語仕様の中に、結構何これかっこいいって仕様がたくさんあった気がする。
例えばパイプ演算子とか、
バイト配列に対するパターンマッチとか。 OCamlでは常備薬だったよ>パイプ演算子
haskellの$や.より読みやすくて好きなんだけど、関数型も取り入れててオブジェクト指向もサポートしている言語だと、
メソッドチェーンでええやん勢がいるのが難点
自由度はパイプの方が高い気がするんだがな お前らだれもF#話題にしないからマイクロソフトP#作っちゃったじゃん へー、FORTRANの次はPascalの.NET版か。 MSっていったいいくつ言語作ったんだ
そしてパクリでない言語はあるのか >>628
すべての言語はすべからくパクりパクられの関係であるといえる。
一番言語を上手く作れている会社だと思うけど >MS
と言うか開発環境セットでいい感じ。
vscodeの完成度は高い。TypeScript大好き。
ただTypeScriptはあくまでESの型拡張に限定してるからES側に機能追加がないと
言語として成長できないという問題はある。
ドッチかというとFacebookが言語開発イマイチ感
Hackとかflowとか >>629
BASICっぽくないのにVisualBASICとか名前をパクってるってこと
他の言語は移行者を配慮してだが、MSは騙す努力ばかりに見える
開発環境とセットというのがまたダメだ
プログラマによる変革が生まれにくい
単なる作業者ならいいが >>630
俺もちょい前まではMS気に食わなかったし
vscodeが最初登場したときは、なにこれatomパクって車輪の再発明?
みたいな感じだったが使ってみてハマった。
別に開発環境で囲い込もうってわけでもないと思う。
一緒にlangage server protoolというのも定義して公開した。
IDEと言語サーバ間のプロトコルを共通化し対応するEditorならなんでも使えるようにする。
gccがサポートしてるってニュース見たよこないだ。
ということで最近のMSはオープンソースとの関係がよい。気がする。 >>629
FBだけじゃなくてGoogleもイマイチ
DartやGo >>632
Googleも結局VSCodeメインで使ってるしな >>631
その先に3E戦略が見えるから乗っかれない Electronベースのエディタとしては後発なのに他を追い抜いたのが凄いわ>vscode
vscodeはatomやbracketと同じElectronベースなのにどうしてあんなに軽いのかね >>635
MSは長い間VS作ってるしエディタとかIDEのノウハウが凄いのでは 構造化BASICの正統進化なんだけど
ついでに8bit機にのってたようなのは当時既にストリートBASICって言われてた
(漏れもwikipediaで知ったんだけどさw) >>629
すべからくの使い方を間違えてる日本語が気持ち悪い 最大級の戦犯はペチプ〜やペェ〜ルとかいう真性糞ゴミを作った屑 一歩の作者が悪いんや…
すべからく…べし、の形すら守ってないと俺はそれ以降の文章はスキップする
読む価値がない >>637
MSのQuickBASIC好きだったなぁ >>636
内部的にtypescript使ってるのは関係ないかな? vscode はむしろマイクロソフト内の若手が爺どもにぶちぎれて
まったく別路線のものをつくったという印象 >>630
いわゆるMS BASICからQUICKBASIC→Visual Basic→VB.netと辿っていけばわかるけど、普通にMicrosoft系のBASICだと思うけど。
どの辺がBASICっぽくない? >>643
typescriptもjsに変換されるから無関係
V8エンジンが速いという条件ならatomも同じだぢ >>646
それは言われなくても分かる。
素のES2015よりメンテナンス性や安定性が向上しないかな。
例えばnull安全なコードがかけるからnilチェック漏れとかを潰せるし。
プラグインもtypescriptでかくから少しましになる? >>648
それはそうだけど、>>635から始まったvscodeのパフォーマンスの話してるからtypescriptであるかは関係ない >>622
勘違いしてるぞ
EitherはMaybeの上位互換だ >>650
多値返却に関してはgoのことやね
Eitherに関しては取り敢えず無視してたわ エラーをバケツリレーするより
エクセションで飛ばした方が簡単でしょ 簡単そうに見えても結局それぞれの場所でオブジェクト開放を
うまくやらなきゃならんことを考えれば大して楽になるわけでもない。 VSCodeでインテリセンス技術をオープンソースにしたのは地味に画期的なことだと思う
IDE分野でのMSの強さを支えるコア技術だよね Goはパターンマッチないのに例外を戻り値で返すからあんな面倒な事になってるんだろ その言い方だと例外投げられればいいのかパターンマッチが導入すればいいのか
わからんが。
どっちかもしくは両方あれば楽になったとでも?
プログラム書く上でまったく本質的な制約だと思わんな。 あと複数の戻り値じゃなくてタプル+単一戻り値の方が扱いやすい +演算子をorの意味で使ってるのか?
それだとタプルを返した時は単一ということになるか
単一の意味も違うのかもしれない 形式的にだけど、返り値はタプル一つになっていて、それを分配束縛してることになってなかったっけ?
違ったかも んで結局、>>659はどういうのが扱いやすいと言っていたわけなの タプルとEitherはC言語のstructとunionに戻るようなものだからな
次世代の面子が潰れる goの戻り値がタプルのほうが嬉しいという気持ちはわかる。
自作の型に自由にメソッド生やせるのに、メソッドチェーンしようとした場合に、多値を返されると無理。 >>666
golangは本当メソッドチェーンが出来ないよな まぁそういう弱点ありつつもgoは嫌いじゃないんだけどね。
エコシステムの部分とか。
import文にgithubのurl?を書けたり。
標準ライブラリのコードが自然に見にいけるから書いている最中も勉強になるし、標準ライブラリが教科書的な役割をはたしてくれたり。
コードフォーマットが標準装備で言語仕様的に制約が強いから構文規約は一つしかないところとか。
と言いつつも他の言語を見て羨ましくもあり。もっと関数型チックになってほしいけど無理かな。 メソッドチェーンが遺物だと気づけw
Goは意図的にメソッドチェーン出来ないようにしてるんだ パイプライン演算子の便利さを考えるとメソッドチェーンもそこまで悪くない気もするが、使い方次第かねえ パイプラインの方が柔軟性高くていいよね
do_something foo |> lambda x => x + other_fun bar |> ...
みたいな前の戻り値のメソッドに限定しない書き方ができる
これをもっと楽にするような記法、例えばパイプラインの式中のアンダースコアは前の値とする、みたいなのがあると嬉しい
上のやつと等価だったらdo_something foo |> _ + other_fun bar |> ... みたいな Juliaでそのアンダースコア議論されてて、結局実装されなかったんだよなたしか 2番目の引数を先に埋めてアンダースコアは一番目にしたいパターンがあるので、どちらかと言うとカリー化は好きじゃないなあ。設計が悪いと言われたらそれまでだけど
Juliaの場合は多重ディスパッチを採用している関係でカリー化は諦めたっていうのもあったな >>665
いやだからEitherモナドはMaybeみたいに正常系だけ書いていけるし単値だしで全然違うって
なんで皆使ったことも無いのにそんな事言うの… 単純にノイズが増えるだろう
現実にはほとんどの関数がエラーを返す可能性を持ってるんだから、言語に織り込んでデフォルトを Error | Result とするのは悪いアイデアではない >>676
これ実際Haskell書いてないと分からない感覚かもな (Elixirは?動的型付け言語に人権はありますか) ほとんどの動的型言語ってそれが動的型であるメリットは特に無くて
単なる処理系実装者の怠慢でしかない
動的型言語を推すならまずはそれが動的型でなければならない理由を示すこと lisp とか仕様をシンプルにできることかな。
あほみたいに仕様が膨らんで意味の分からんキャストをがばがばおこなわなきゃならん
みたいな不自然なことで生じるバグは減る。 >>680
怠慢に寛容になると嘘をつく人間が減るから
自分はなにもしないくせに他人の嘘をデバッグするのだけはうまい奴がいる
そういう奴がいても許されるから嘘が減る
怠慢を許さない環境では忙しくて嘘を見抜く暇もないから嘘が蔓延する そもそも型が必要な理由が分からん。
数学なら「整数型のxが・・・」なんて言わないしな。
「ここでxは整数とする」はあるけど、条件に過ぎないし。
リストやタプルも分ける必要ある? 372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているサイトだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子が求人をだしてる。名刺も渡せる。ユー子に名刺を渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト >>683
型はその条件をいろいろ細かく定義したものだろ。
値域や定義域だって型。 動的型の問題って関数のインターフェースがガバガバなところでしょ?
elixirはパターンマッチで結構制約できるから動的だからって卑下する必要ないのよ >>680
動的型でなければならない理由?
それは、おまえがバカだからだろう。 >>685
少なくともunsigned は要らなくない?
1bit ケチれるだけだし。
中途半端な単精度浮動小数点とかも。 申し訳ないが未だに使っているGPUの多い単精度小数点DisはNG >>686
まだコードを書いてないのに問題でしょとか言われても
言う時期が早すぎるし言う内容に具体性がないよ
まるで数学も英語もまだ知らない小学生にプログラミングを教えているようだ TypeScript触ってるとjsに型がある方が幸せだってわかる。
jsonにスキーマ設定無しで
reduxでstate管理するのとか絶望する。
あと、学習面でも明らかに型があったほうが幸せ。書いてる端から指摘してくれるからすごく幸せ。
TypeScriptはvscodeとセットで幸せー >>688
今言ってる片野必要性は容量のためじゃないだろ
全ての引数をテストするとすると1bit減ることでテストの数が半数になる実装もその1bitに対して考える必要がなくなる
例えばルートを計算する関数を実装するのに引数が正の整数と限定されてれば簡単だが、負だったり小数した場合は複雑になる。文字列や画像だった場合は例外が発生したりアボートしたり誤作動するかも知れない。
型はビジネスロジックに集中するためのルール、制約だ
静的は言語レベルで強制、チェックしてて、動的ではユーザ、実行時に任せてる 関数の引数なんかはやっぱ型があった方が読みやすいなと思う。
でも内部のテンポラリ変数なんかは別にいらんかもね。
というかテンポラリ変数の型情報がないと読めないようなコードは
そもそもコードが長すぎるとか、他の根本的な部分に問題がある気がする。 >>682
>>690
内容がフワフワしてて何言ってるのか理解できない
もっと具体的かつ簡潔に言え
Twitterによくいるプログラミングできないのにプログラム語ってるクソ野郎みたいだぞ >>688
unsignedはオーバーフローしても下から戻るから楽
つか実装型まで否定するって、じゃあ任意精度にしろってか?
計算量制御できなくなるぞ? 世界で最も使われている西京言語JavaScriptをディスってんのかメーン >>694
プログラミングできるできないではなくタイミングの問題
目の前のことを言えば具体的かつ簡潔になる
遠い将来のことを語るとフワフワする 次世代言語を語りたければ、今流行ってる言語の分析をしないと
Java、C#、C/C++が人気だけど WindowsとLinuxのAPIが人気
Javaは大規模開発が云々で人気 Java系は一貫した技術の枠内で一通り完結するのがメリット
アプリケーションロジックの開発に集中できる マクロはズルってのと同じで枠の外にあるものはズルなんだな しかし結局欲しいのはマクロでしょ?ってなることは結構ある。 >>700
Java…型推論ない、論外
C/C++…メモリ安全じゃないので面倒
C#…まあ使える。ただT aだったりT b()だったりで書き方がちょっと古い C#は良い言語だと思うよ
パターンマッチが追加されたりifが式になったりで便利になってきてるし 事実上Windowsでしか動かねーやん
話にならんわ ■ このスレッドは過去ログ倉庫に格納されています