◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:次世代言語9[Haskell Rust Kotlin TypeScript Dart] YouTube動画>3本 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1520298555/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
スレタイ以外の言語もok
前スレ
次世代言語Part8[Haskell Rust Kotlin TypeScript]
http://2chb.net/r/tech/1512137301/ Googleは言語選択保守的すぎるだろ
関数型とは具体的に何のことやら
>>4 別にそんなとこで冒険しても生産性上がらんよねって感覚なんだろ。
>>6 enum・traitと関数型は関係ないだろ？どちらもHaskellの型システムをパクって来たってだけ
関数型言語の特徴として真っ先に思いつくのは関数を第一級オブジェクトとして扱えるか否かというところだろうな
ただその考え方だけだとC言語でさえ関数ポインタがあるから関数型言語に含まれてしまうことになる
そこからさらに副作用を出来る限り避ける文化があるか否かとかも判断基準になるのかな？
言語の文化とかふんわりした表現は具体性を伴わないから説得力に欠けるんだよな
改めて関数型を具体的に説明しろと言われると難しいな…
>>8 関数ポインタは確かにC/C++系独自だけれども（Javaにはなかった）第一級オブジェクトではない、とおもうよ
もう少しだけ動的に関数定義を変えて返したりできるのが関数型ぽい。
Cの関数は実行時に生成挟めないから第一級オブジェクトではないよ
c++ならクラスのメンバに情報持たせて、メソッド使うことでクロージャぽいものはできるけど。
C++ のラムダ式でYコンビネータを記述できるのですか？
>>15 2つの話題を勝手に混ぜるな
>>14 で
>>12 に安価付けなかったのは俺が悪いけどさ
実行時の環境を用いた関数定義の有無についてc++ならラムダ式を使おうという話をしているだけだ
しゃーねーだろ言語機能としてラムダ式って命名されてるんだから
関数型言語とはなんぞやという話題についてc++のラムダ式を例に挙げてc++は関数型だ!なんて言うつもりは毛頭ない
Yコンビネータに関しては確かできた気がするが
>>4 goって保守的かな？結構攻めてる言語だと思うが。
swiftのほうが断然保守的。
>>18 保守的にするという意味で攻めてる言語だな
諦めと開き直りを全面に押し出してくる言語だな、確かに。
goの攻めてるところ。
後は未使用ライブラリのimportをコンパイルエラーにするというのも、他の言語であんまり見ない気がする。
>>21 例外とか構造体はC時代に逆戻りしてるだけだし、静的ダックタイピングは他の言語にもあるし、githubのurl指定は結局色々な問題起きてるし(この間のgo-bindata騒動とか)、公開/非公開の大文字小文字も気軽に変えられなくて不便だし何のメリットがあるんだ？
>>22 他の言語はエラーにはしないけど警告出す
初期の開発中は未使用importエラーも邪魔なだけでしょ
>>23 むしろ、今まで当たり前にあった言語仕様を振り返って本当に必要かどうかを再検討して
削りに削った仕様だと思うけどな。
c++とか触ってたとき、クラスと、構造体って、本当に両方必要か？どっちか要らないだろって思ってたりしたから、
すごくしっくりきた。
>>24 IDE使ってると半自動だからあんまり面倒だと感じたことはない。警告を無視する開発者もいるから徹底したほうが良いんだろう。
linuxカーネルもコンパイルすると警告出てるし
>>25 構造体とクラスに関しては個人的に同意
ただ型パラメーターとか例外がないのはありえない
エラー処理は長すぎる。if分岐でチェックとかいつの時代だよ
型パラメーターないせいでDRY原則を破るか型安全を破るかしないといけない
>>23 go-bindata騒動はgo固有の問題でもない。nodeだって似たようなことあっただろ。
>>27 例外いるかな？
tryで包まなきゃいけないメソッドや、関数ってドキュメント読むか、実際に実行するまでわかんなくないか？
言語によっては例外が飛ぶ可能性がある関数かどうかわかるんだっけ？
jsはわかんないから不便。
>>27 結局interface{}使うのかよ的なね。わかる。
俺はコード生成に可能性を見出してる。
goはコード生成フレンドリーな言語仕様だし標準ライブラリに、AST系が揃ってるから
>>28 nodeもあったけどnodeの場合はnpmの仕様変えれば解決出来るやん
でもGoはgithubに依存してるから解決不可能じゃん
>>29 それならEither型作ってメソッドチェーンで書けるようにして欲しい
Goのエラー処理は関数呼び出し毎にしないといけないからだるすぎ
>>30 型パラメーターが複雑だから、コンパイル速度に影響出るからって入れなかったのにコード生成しろって矛盾してない？
どっちが複雑だよ。どっちがコンパイル速度に影響出るよ？
>>31 コード生成はプリプロセスとしてコンパイルの度に毎回動かすわけじゃない。stringerとか使ったことない？
inportに関しては、
nodeがnpmの仕様を変えたら解決するならgoもそうすればいいのでは？
現状でも、vendor/もコミット対象にしてしまえば、依存ライブラリを管理対象にできるから
サードパーティライブラリに頼る以上はライブラリ作者の影響をどの言語だって受ける。
Yコンビネータ forall a. (a -> a) -> a のように
maybe/eitherが無い言語はあまり触りたくないな
goってなんだかよく使われてる以外の理由で使う理由がないよ
Goはマイクロスレッド得意なのはありがたいな。
>>35 WEBサーバ: go,php,ruby,java,Elixir
IOSアプリ:swift,dart
Androidアプリ:java,kotlin,dart
WEBクライアント:JavaScript,elm,TypeScript
cliツール:go
どこにrustが入る？
Rustは生ポインタが使えるし、C ffiが比較的容易に可能、そのうえwebassemblyにまで対応してる
>>37 以外にも組み込み、OS、ドライバ、デスクトップアプリ等どこにでも入ろうと思えば入れる
C++の後継を目指してるだけあってかなり万能な言語ではあるんだが
問題は普及するかどうか…
>>32 goはgithubに依存してるからgithubの仕様変えないと駄目じゃん
具体的にはリポジトリやユーザーの削除禁止。でもそれは無理だろ？
>>32 毎回動かすわけじゃないけど、変更あったら動かすだろ？
しかもそれは他の言語でも差分コンパイルで出来る
>>39 githubが便利だからgithub使ってるけど、別にgithub以外でも公開出来るし、依存してると言うより多くの人間がgithub使ってるだけでは？
プログラマの労力よりコンパイル速度を優先してるのが謎
コンパイル速度が短いとデバッグしやすいからじゃね？
>>38 Rust嫌いじゃないけど普及しないと思う
今年のロードマップもwasmとCLIとNetwork頑張る、っておとなしすぎだろ
いろいろできるならもっとぶっ込んで来いやｺﾞﾙｱ ってね
Googleが採用しなかったDartよりはMozillaが採用したRustの方が将来性はあると思う
>>37 ウエッブサーバ: rust
他のサーバ: rust
ウエッブクライアント: rust
CLI: rust
>>41-42 その辺の話は
https://talks.golang.org/2012/splash.article に書いているけど、
Google社内の巨大なソースのコンパイル時間が45分とかかかるようになっちゃって
なんとかしないとという流れで始まったって書いてる。
つまりGoogle以外で恩恵を得る可能性は低いな。
>>46 一応マジメに返しておくと現状webクライアントはrustだけじゃダメだよ
現状ではまだwebassemblyでDOM操作はできないし他にも出来ないことは沢山ある
webクライアントにはRust+JSの組み合わせが必須になる
ただし、Rustのマクロ使ってRustの中にJS書いてビルド時にwasmとJSを両方吐きだして
無理やりRust onlyを実現してるstdwebとかいう先進的？なフレームワークも存在する
あのクレート発見したときは「こいつ天才かよ？」って思った
Rustは気になるけど、さわるモチベーションとなるキッカケがないんだよな。
人気が下降しプログラマの求人も少ないプログラミング言語ワースト10は？ 一方で仕事の多い言語は？ CodementorXとCoding Dojoの調査結果
http://www.publickey1.jp/blog/18/5_codementorxcoding_dojo.html jsのファミコンエミュを苦労してrust(→webassembly)に書き直してもぜんぜん速くならないという悲しい現実。
>>51 憶測でしがないが、それはRustやwasmが遅いというわけではなくて
ファミコン程度の演算ならJSだろうがwasmだろうがパフォーマンス的には大差なくて
それよりもwasmとJSでデータをやり取りする際のコピーのコストが高くついてるんじゃない？
3Dゲームの演算とかもっと重い処理じゃない限りwasmのメリットが活きてこないんじゃ…
もしくは、将来的にwasmから直接DOM操作ができるようになれば…
GoとRustはバランスが悪いんだよな
RustにもARCはあるんだろ
>>55 RustにARCがあるってのは誤解を招く恐れがあるので補足
RustではARCは標準ライブラリとして用意されてる
SwiftみたいにARCでメモリ管理してるわけじゃないよ
Rustなんてmozillaに金掴まされた奴しか見向きもしてない何にも使えない言語が
実際誰がどこで使ってるのか教えてくれ
googleがxi-editor作ってたり、
dartを知らない人間がdartに触る例。
VIDEO エンジニアのプログラミング実況動画面白いかも。これのrust版ってある？
>>59 1.0出て何年も経ってるのに
その体たらくって時点でお察し
>>59 ゲーム分野もUnityやUnrealでニーズ満たしてるし、それ以外のものは今さら流行らんでしょ
>>41 コンパイル速度が早ければスループットが上がるんだから、労力の定義次第だろ。
>>59 こいつ反応楽しみたいだけの荒らしだから触れるな
>>53 本当これだよな
両方バランスが悪い
ネイティブでバランスの良いKotlinみたいな言語欲しい
Kotlin Nativeはどうなんだろうね
>>53 ラムダ式とジェネリクスはGCとはあまり関係ない機能だと思うが…
特にジェネリクスとGCには全く何の関係も無いような…
https://taiyaq.com/contents/VXd2aV04Gr1mLC8e3AbEg4XKly Dartの言語ツアーみてるけど、結構言語仕様が辛い。
変数宣言がC由来の「型 変数名」なのがつらい。
GoとかTypeScriptみたいに変数宣言は「変数名 型」にして欲しいわ
あと内部コードがutf16というのが気になる。jsより後発なのにjsと同じ仕様って。
Flutterは良さげなのになぁ。
RustがC++の代替って枠だと先にも出てる大規模ゲームなんだが、個人やインディーズなら大手エンジンでいいし社内独自エンジンだとこれまでの資産的にツールもゲーム本体も言語変える必要なくない?みたいな所がなぁ
>>68 rustってc++に絶対勝てないのかね？
メモリ管理を静的に解決できるって不思議なんだけど、もしかしてメモリ節約プログラミングが得意だったらスマホとかIOTでワンチャンあるかもしれん。
今rustで書いてるよ、勿論mozilla全く関係無い
rustは理論好きで実際はコードほとんど書かないような連中に人気あるだけだろ。
>>70 ヒープ周りは言う程魔法みたいな事をしてる訳ではないよ
どこまでいってもコンパイル時の制限をカッツカツにして開放を保証するって話だし
iotもスマホも(もちろんゲームも)クロスプラットフォームしたくて大変なのにそれぞれc++向けに書かれてるsdkラップする?っていう
オープン規格やらそういうsdkがrust向けを公式で出すようになれば採用も出てくるとは思うけどね
メモリ解放のタイミングが分からなくなるっつーのは基本的に
わたすもrustで書いてるよ
実行時に参照カウントを増減するのは、実行しないとわからない場合だけにしろ
>>1 Dartとかいう完全死産のゴミ言語をスレタイに入れるな
おまえほんっとセンスねーなバーカ
Dart2で再始動って言ってるからDart4くらいで良くなるんじゃねｗ
>>47 これでコード書く時間が逆に増えたらウケるな
>>79 死んでしまったAngularちゃんの悪口はやめろ
>>79 内部文字コードがutf16とか変数宣言がいまいちとか結構辛い。
flutterとdartを分離してTypeScriptから使えるようにしてくんないかな
>>72 あーわかる超わかる
トイプログラムだけ書いて満足する奴のための言語みたいな
>>83 個人が趣味でやってるプログラムなんてどんな言語だろうが大体そういうものだろ
別にRustで書いてる奴に限った話じゃない
本格的なものを作ろうとすれば企業が関わらざるを得なくて現状ではどの企業もまだ様子見状態ってだけ
>>86 残念ながらxi-editorは20%ルールの産物で完全に個人のトイプログラムなんですよね
そもそもGoogle社内の公認言語にRustなどという腐ったものは存在しない
そだよ
まじで。Go自体が20%ルールの産物なのは知らんかったわ
ドワンゴや渋みたいな画質最悪回線ptptのプラットフォームの技術（）なんて参考にならん
アンチのいない言語ってあるんかな？
Goが嫌われるのは、意識高い系の人間が欲しがる機能をオミットしたからだろ。
機能をオミットする方向を示しただけでもgoは価値あるよ。
採用例提示しろって言われたから東証一部上場企業の採用例をいったらいったでまた難癖つけるね
FacebookのMononokeとかも除外なのかな
>>96 オミット大事だよね。バージョンを重ねていくと機能追加しかできないから
最初の機能は絞ったほうがいい。
Goにはきっと既存にはない独自発想のジェネリクス的な物が搭載されるであろう。
賛否両論なやつが。
>>100 「例外を無くした。あれは大域ジャンプだ。行き先の見えないgotoだ。
フローが無茶苦茶になる、複数の戻り値返すから各自チェックするように。
複数の戻り値返せるからマジックナンバーとか返すなよ」
なんて、割り切りというより考え抜いたであろう仕様も、結構叩く人は叩くしな。
ジェネリクス的なものはどうなるんだろう。
正直型でのswitchでだいたい事足りてるし。
>>101 関数の引数にinterface{}型が入るのは良くない。これだけは是非とも改善したい
>>102 何で？
コンパイルする時に誤りに気づかないとかそういう話？
void*が渡せるよりも、interface{}は実際には型持ってるからよほどマシな気が。
ジェネリクスしたらすごい数の関数が作られうるし、使い方の問題な気がするけどな。
そもそも継承という概念が希薄だから、ジェネリクスにしても幸せになれないと言うか、明示的に何らかのinterfaceを渡す方がマシだと思う。
Writer受ける関数みたいに。
>>103 実行時に解決するのは極力避けたい。
防衛的プログラミングをしたい。
AST系ライブラリを使いこなせるようになってコード生成でもいいけど。
例えば今、任意のオブジェクトを格納できるコンテナ
つか自分で言ってて思ったがこれinterface{}が悪いとかじゃなくて
>>105 それもあるけどライブラリを提供するときに引数がinterface{}だとドキュメントに説明がいるでしょ。そういうのが嫌。
コンパイルが遅くなるので人間が出来る事は人間がやってください
>>108 どっちにしろ実行時に起こる現象は説明が必要だろ。
確かに動的だったりテンプレートみたいなもんだと読むのきついなと思うことがあるけど
型で述べられる記述力なんてコード量の割にそんなに豊かなもんでもない。
俺は優良なドキュメトとテストコードのが上回ると思ってる。
goのinterfaceと比べて継承の方が入力の範囲を特定する能力は高まるけど、
同時に型情報をどっさりコンパイラと人間に読ませることになるわけだ。
割にあってると思わない。
>>110 Scalaとか見てると気持ちはすごくわかる
しかしせめてコンテナ型くらいは型制約欲しいという気持ちもわかってくれ
>>106 型に階層があるという事が前提になってる時点で、goに向いてないんじゃない？
"is a" の機能をomitして "has a" とかmixinとかtraitを使う方向
>>110 ちょっと具体例が浮かばなくて適当な説明になるけど
ある引数に io.Reader もしくは io.Writer だけが来て欲しいって場合に
interface{}で一旦受け入れてどっちかじゃなかったらエラーって書くのがしんどいの。
引数にio.Reader | io.Writerって書けるようになれば
どっちかしか来ないことが保証されるからエラーハンドリングのコードが減る。
別に型システムがほしいとかじゃなくて
なんでも受け入れるinterface{}にしてしまう状況を避けたい。
R | W より Or<R, W> が良い
その場合 `Or<A, Or<B, C>>` と `Or<Or<A, B>, C>` の等価性どうする?って話しになるけどね
>>115 そんな気持ち悪い関数嫌だな…。
分けられないの？
>>114 それはもう、今の定義されたinterfaceで充分だとなってしまうのでは？
せめてパターンマッチくらいは入らんかなあ
>>118 まぁ例えばだから。もっとぴったり来る例を示せればよかったんだけどね。
関数のオーバーロードも合わせて欲しいな。関数名考えるのがしんどい
>>110 ドキュメントが常に最新の状態であることを静的に
保証する方法がない限りは静的型付けの型情報の方が信頼できる
腐ったドキュメントほど有害なものはない
腐らせるヤツが悪いとか言われそうだが
腐らせるのは自分ではなく同じチーム内の誰かだ
他人よりコンパイラの方が信頼できる
interface{}を他の言語のobjectみたいなほんとに雑な受け方と一緒にしないでくれよ…。
実際に書いたら、結構使う場面が限られて来ることもわかるだろ…。
>>121 オーバーロードの禁止ははまあ必要悪だと思う。
型同士に階層が無いので、2種類のinterfaceを受ける関数があったとき、その2つともを実装している型に対して関数が定まらんのでは？
>>125 してねえよ
コンパイル時の型制約を足したいって話で、機能的にinterface{}への switch t.(type) で十分なのは承知の上
ifが並ぶっていってる奴はたぶんswitchで型判定できるの知らない気がする
仮にGoにジェネリクスを実装するとしたらどこまで必要になるんだろ
>>127 そんな難しいのはいらねーから宣言的に書かせろ
>>125 object型と同じだと思ってたわ。具体的な違いとメリットを頼む。_φ(･_･
>>129 渡されたものをどう解釈するかの余地が他の言語と結構違う
たとえば、
type xxx struct {}
func (x xxx) foo(){}
func (x xxx) bar(){}
type Ixxx interface {
foo()
}
func (ix Ixxx) bar(){}
があったときに、interface{}で受けたものをアサーションでxxxとすると、xxxのbarが、
アサーションでIxxxとすると、Ixxxのbarが呼ばれる。
あくまで、すべての構造体はinterface{}を満たしているだけで、実際には型を持ってるし、
interface{}とIxxx{}も満たす範囲が違うだけで上位下位ではないし、構造体の型とも違うのでレシーバは別になる。
interface{}から派生したものではないって感じ。
もしかしてswitchに型チェック機能追加したやつが戦犯かな
型チェックでswitchとジェネリクスは全く関係ない。
Goにオーバーロード無いの批判される事あるけど
>>124 ドキュメントよりコンパイラのが信用できるかも知れんが
それ以上にテストコードの実際の動作のが信用できるよ。
c++まともに開発に使ってた奴ならどれほどコンパイラだよりが危ういかわかると思うけどね。
コンパイラが頼れないからC++から離脱したがってるわかで……
>>133 むしろオーバーロードと型推論を共存させたいというのが型クラスの最初の動機だったのでは
>>135 そりゃテストコードが全てのコードに対して書かれていたらの話で
実際にはテストカバレッジ100%なんてあまり現実的な数値じゃない
GUIの場合はテストを書くこと自体がなかなか難しいし、他にも仕様が変わりやすいような
部分は変わるたびにテストも書き直すんじゃ、コストが割に合わないこともある
それらを考慮して、あえてテストを書かないという選択をすることも充分あり得る
静的型付けならテストが書かれていない部分でも型情報からある程度ならチェックが出来る
動的型付けはテストがなければ何もチェックできない
テストを書かない奴はバカみたいな言い分はあまり好きじゃない
テストカバレッジ100%を目指す奴のほうがよっぽどバカだと思う
C++の型安全とHaskellの型安全って随分違うでしょ
>>130 残念ながら他言語のobject型とinterface{}の違いがこの説明ではよくわからん。
あんさんは他の言語のobject型を雑な受け方と評したんだぜ。具体的にこの説明では、
なるほど他の言語のobject型で値を受け取るのは雑な受け方だった。って納得しない。
どのへんが雑じゃなくなってるわけ？
>>138 qiitaの記事でだいたいカバレッジが85%位が理想値でそれを超えるとしんどくなるだけで意味ないってのは見たな。
>>135 C++のコンパイラに頼るのは危ないってのはテンプレートがダックタイピングだからじゃないの？
だとしたら、それは単にC++のテンプレートの仕様がクソってだけの話で
C++のコンパイラがクソって言うのは筋違いだと思うんだけど…
それとも他に理由があるの？
書いた後で思ったけど、
たぶん135は、コンパイラがバグってて出力される機械語が怪しいという話をしてる
>>140 うーん。なんにでもなれるスーパークラスで受けてるんじゃなくて、何もかもを満たすインターフェイスで受けてる。
クラスというか構造体同士に階層も無いし、
インターフェイス同士にも無いから。
だから、他の言語でObjectからキャストし直すときに、キャスト先の階層構造を考えなくてもいいし、
むしろどうキャストするか(何がほしいか)で、それに合わせたレシーバを呼んだりできる。
>>139 なのになぜライブラリのバグがちょいちょい発覚するの？
普通は型の階層を利用したキャストの方が丁寧で
動的型は丁寧なコードも雑なコードも書けるよ
型の階層ってのからまず脱却した方が良いところだと思うけどね。
>>145 >だから、他の言語でObjectからキャストし直すときに、キャスト先の階層構造を考えなくてもいいし、
どういうこと？Object型は大抵すべてのインスタンスの親のはずでは？
一度Object型の変数に突っ込んだなら、それってもう実質、動的言語的扱いになるから人間側が元の型を意識しなきゃいけない。
これはGoでもおんなじでしょ？
あと以下は正直どうでもいい話なんだけど敢えて突っ込む。
Goのインターフェースは階層構造を持たないって言ってるけど
も結局用語の違いってだけで実質階層構造みたいなのはあるでしょ。
Io.ReadWriter は io.Writerを内包している
io.Writerはからインターフェースを内包している
Io.ReadWriter => io.Writer => interface{}
他の言語は階層構造を明示しているけどGoの場合はそれがコンパイラによって自動化されているってだけでは?
もちろん自動化されているってのはありがたいけどね。
>>143 静的ダックタイピングって言われてる
本質は変わらない
>>148 動的型のキャストと静的型のキャストに違いがあるとは思えないけどなぁ。
俺の考え方はこう。
動的型: 人間側で型の追跡を頑張る
静的型: コンバイラ側に型の追跡を任せる。ただしobject型とかに渡すことで人間側で頑張ることもできる。
動的型は基本雑なコードだらけ。人間側が型を決め打ちしてメソッドを実行しないとやってられない。
だって毎回instanceof とかで型をチェックしてからメソッドの実行とかしてないでしょ？
>>152 説明されてわかるような奴が
>>148 を書くと思うか？
なんでもできる c++ で書くなら
ダックタイピングとnominalな階層型の違いを言葉を変えて繰り返しているだけで
>>138 別に全部のコードにテスト書けとは思わんが
それでもそこまで引数の型がどうなのか気になるインターフェイスなら
テストコード書けよ。
てかそこまで作業が圧迫してるなら型をガッチガチにやる言語のが
調整する手間考えた場合割に合わんだろ。
>>157 どの程度なら「気になる」のかってところに認識の違いがありそうだな
静的型派の人間は全てコードの型情報が気になっちゃうんじゃない？
少なくとも俺は全ての引数の型が気になってしまうタイプの人間だよ
>>152 動的型のコードは二種類に分けられる
静的型で丁寧に書いてから型を省略したようなコードと
静的型で雑に書いてから型を省略したようなコードだ
「階層を持つから安全にキャストできる」と「安全にキャストできるから階層を持つ」がごっちゃになってる人がいる
>>158 まあ極論すれば感覚的な話だしね。
感覚として型を気にして助かることなんて 5 % くらいじゃないかと思ってる。
対してテストがある場合は 40~50%くらい助かる。
準備するコストとして型が 10~20 としたらテストは 30~40 といった印象。
なんで個人的にはそこまで型を整備するよりかはテストに時間使った方がいいと考えてる。
まあ抽象論一発で済めば嬉しいって気持ちはわかるんだが
実際そうはならんからね。。
>>156 端的に言えば、スーパークラス(と言う概念もないが)にキャストしてして渡してない、as-isで渡してると言うところが違うし大きい。
良いとも言ってないぞ。
違うし混同するなと言ってる。
Objectに相当するものが無いので、良いも何も比較対象ではない。
スーパークラスにキャストねえ。
暗黙的にでも、ね。
as-isで渡るは確かに語弊があったな。
>>162 >>125 でobjectを雑と評したからには当然interface{}の方が良いという主張と思ってたんだが
実際の詳細は別にしてあなたの説明では聞けば聞くほど同じとしか思えない
俺じゃないが
>>155 なんかCOM的な構造で代替可能という理解をしてるし
とはいえ言いたいことはわかる
as-is型に実装を合わせるテンプレート
>>166 同じではないでしょ。
COM的な構造で代替可能ってのは、
>>166 自身は理解してるの？理解してたらそのレスにはならんと思うけど。
そもそもが思い込みで人の発言に「良い」を勝手に補完してなんでそんなにしつこく食いついてくるかわからん。
理解が足りなくて同じだとしか思えないなら開き直らないでほしいわ。
>>154 だから階層構造がないのはわかってるつーの。実際的な違いがないっていってるの。
実質Object型 とinterface{} はおんなじ扱いにしかならない。
Object型にはtoStringがあるけどinterface{}にはない？ 別にそんなのはどうでもいい話。
interface{} に値を突っ込むと人間側が型を意識する必要がある。
動的言語的な扱いになっちゃう。
この点においてObject側と一緒だよね。
ここが最大の肝であり、「Object型でうけるのは雑」っていってるのはこの部分に差があると期待して質問したのに、
そこに関しては違いを見出していない。
なら雑な理由って何よ。
今気が付いたが
>>145 の言ってることは根本的に間違ってる
>>130 みたいなインターフェイスのレシーバはそもそもコンパイル通らない
つまりどの型にキャストしても同じレシーバが呼ばれることが保証されてる
そこがGoの型は階層を持たないという根拠になってたはず
エアプは黙ってろ
>>169 IUnknownが便利に使われてるのと
QueryInterfaceの実装次第でメンバーに飛ばすこともできるのが似てるって話だろ
COMは実装側が応答する型(GUID)を決めないといけなくてダックタイピングにはならんから
俺は必ずしも似てるとは言わんけど、あなたの説明はそう思われてもしょうがないってことだ
classの多重継承ができる言語ならinterfaceはclassの構文糖ということにできた
>>171 これは例が悪かったか。
スマホで書いたからすまん。
ある型にアサーションした場合、アサーション先の型のレシーバが呼ばれるよ。
もとのレシーバではない。
>>170 おんなじ扱いをすれば同じになるだろうな。
扱い方の余地の問題なんだが。
人間側が型を意識する必要がある、この点に於いてObjectと同じと言うのは雑すぎる。
動的言語的扱い方と言うか、jsonのUnmarshalなんか見た方が多分わかりやすいと思う。俺が言ってることは。
interface{}で受ける関数を呼ぶときは、
しかし、また「エアプ」かw
キャストは雑
>>175 それって結局reflectバッケージを見ろってこと？
>>177 型キャストが雑ってこと？
型アサーションだと型が合わないとerrorを返すから雑じゃないってこと？
雑なほうがいいんだよ。that's rightって言うだろ？
>>180 アサーションが丁寧というのは語弊があるが、インターフェイスからのアサーションはそもそも本来の型自体も持ってるのでキャストしているわけではなく、assert、言明し直してるだけで、別の型として一度も扱わない。
>>174 アサーションでもレシーバが変わることはない
自分で試したことないから分からないんだろ
>>177 のキャスト無しで渡してるってのも間違いで実際はキャストされてる
キャスト無しで渡してたらそれはジェネリクスだ
たぶん
>>177 はポインタや参照を理解してなくてキャストの意味をはき違えてる
objectにキャストしたら静的オブジェクトが動的オブジェクトに変換されると思い込んでるようにしか見えない
>>183 あることあるから、レシーバが変わる事知ってるんだよ。
そうじゃない。履き違えてないよ。
ジェネリクスはもっとちがう。コンパイル時に関数自体が型ごとに分かれるのが俺が言うジェネリクスとオーバーロード。
オブジェクト指向脳でわけわからん事言わないで。
>>184 が、言いたいことを整理すると
Go言語のinterface{}は他言語のObject型とは違う。
なぜならGo言語のinterface{}型は内部的には型情報を保持しており
reflectバッケージを使うことでいつでも元の型情報を取得できるから
ってことでOK?
これって逆に言うと他言語のObject型は内部的に元の型情報を保持しないの？
本来のデータポインタはそのままで実行時型情報をペアにしてinterface{}(fat pointer)にしているのを
>>185 いや保持してるよ
RTTIってやつだね
エアプ呼ばわりされて過剰反応するのが真のエアプ
>>185 内部的に持ってるが、クラス構造が階層型であるが故にObject型という型で扱われた上で、サブクラスにダウンキャストするじゃん？で、またアップキャストするかもしれん。
だからジェネリクスやオーバーロードだと共変なのか反変なのか、あるいは非変なのかが問題になるし、Javaなんかはジェネリクスは非変だけど、配列は共変みたいな事になってるし、c#なんかだと最近変性注釈できるようになったり、まだゴタゴタしてる。
ちなみに、interfaceへのアサーションはreflectとは違って、interface自体が型を持ってるので、reflectで型を判定したりメソッド呼ぶのとは結構な差がある。
古いけどこのへんか。
https://research.swtch.com/interfaces エアプなんか使ったって、レッテル貼るだけで議論ができないようにしか見えないんだからやめときなって
それが楽しいんだろ、いつもその言葉使うところ見たら。
例えば
結局Objectの方がinterface{}より保証されてるものが多いから、雑なのはinterface{}の方じゃーん
>>105 これ最高に型無しクソペチパー指向的レス
>>197 保証されてるものが多いんじゃないよ。
保証されるべきでない関連性を持ってないものも、関連性を持っているかのごとく扱われるんだよ。
自分が知らないものをたったひとつソースから「言い間違えなのか？」と言うのはどうかしてると思うわ。
>>195 ToStringなんて関数をinterface{}で受けて中で適当に処理するってこと自体だと思う。
そんな事するぐらいなら、使いたいintとfloatを名前つけてちゃんと型定義して、Stringer実装するほうがまともでは？
ライブラリならまだわかるが、ユーザコードでinterface{}を使うのはもっと「interface{}でなければいけない時」であって、基本的にはなんでも受け取りたいから使うための型ではない。
普通のオブジェクト指向言語でもそうだろ。
後半のコード例に至ってはコンパイル時に検出したいだけだろ。
オーバーロードさせろってんならまだわかるが。
コンパイル後に消えるようなもの書いて喜ぶ事こそ馬鹿らしいわ。
>>201 >後半のコード例に至ってはコンパイル時に検出したいだけだろ。
それこそキモだろ。静的言語を使う理由って。
これが嫌なら動的言語使ってなよPHPとか
>>201 >ユーザコードでinterface{}を使うのはもっと「interface{}でなければいけない時」
現状のGoでそういう理由でinterface{}を使ってる状況ってどんだけあるんだよ。
それじゃすまないからジェネリクスを欲しがってるんでしょうが。
>>202 ホントだな。これは俺が少数派らしい。
高飛車に言ってすまん。
>>203 キモではないよね。
それは単なる横着のコンパイラへの責任転嫁であって。
void*みたいな無茶苦茶な型があるのも静的言語だが、別に型チェックしてほしくてコンパイルしてるわけじゃないぞ。
>>204 結構あると思うけど。
それで済むから、頑なに「未だ早い」と本家が言い続けてるんでしょ。
済まないならもっと早く導入されてるわ。
そんなに変化ねえじゃんと思いがちだが、ホントに要るなって機能はちゃんと入ってきてるよ。ライブラリの出力しかり、ベンダリングしかり、次はモジュール予定されてたり。
早くPHP歴4000年秘伝のソースにウンコを継ぎ足す作業に戻れよ
このスレ見てたら俺はC++とPythonでいいやって思えてくる
こんなスレに影響されんなよ……
非変、はScalaあたりから来てるのかな。記憶が曖昧。
CとPythonの二刀流ずるい
>>207 あとCみたいな旧世代な言語を静的言語代表にされても。
あと横着はプログラマの美徳だよ。
>>208 現在進行形で議論中だよ。安易に入れたくないだけで必要性は明らかだろ。
https://github.com/golang/go/issues/15292 というか他のジェネリクスがある言語を使ってるとわかると思うんだけどな。このイライラ感。
まぁ関数のインターフェースにinterface{}型があっても気にしない人間もいるという事実があることは勉強になったわ。
そういう人間もいるんだ。
>>199 は自爆というかむしろダックタイピングの方だよね？
反変共変とかすぐに数学用語を取り込んで違う意味にする
>>214 を斜め読みしたけど、既存のinterface{}なやつと互換を取るためJavaのgenerics同様にするか
それとは別に問題を捨て去るためD言語やMLみたいな名前空間単位のやつを入れるかで議論してるな
genericsなんて大物は後から入れてもJavaのようにしかならんとは思っていたが
(失礼ながら)goのような保守的な言語に今までのスタイルを捨てさせるような変更を入れられるのかは気になった
>>217 GoBlogでGo2はGo1と下位互換性を保つと宣言してるから破壊的変更をせずに導入するだろうね。
どうやるか全く想像がつかない
>>161 やっぱり認識の違いが激しいな。これじゃ話が合わんわけだわ
おれの感覚を書くと型情報を書くことで助かることは10~20%くらい
対してテストがある場合は50~60%(約3.5倍)くらい
準備するコストとして型が10~20ならテストは60~70(約4.25倍)の印象
さらに、後からコードを読むときの理解するまでにかかる時間が
静的型が10~20なら動的型は30~40(約2.25倍)の印象。
そして、俺の場合はコードは書くことより読むことの方が多いと思っているので
読むときにかかるコストの違いに良し悪しの重点を置く傾向がある。
というわけで、俺の感覚ではもちろん静的型に軍配が上がる
これ以上は感覚のズレをお互いに調整しないと話が進まないだろうな
会社でkotlinの勢力が拡大して飲み込まれるのは目前
javaが積極的に言語に手を入れるようになったから
Goに他の言語の機能を追加したいって声はよく聞くけど
var導入するのにval導入しないJavaのおじいさんたちはゲェジなのかな？
COM「反射性、推移性、対称性」
AppGameKit Mobile Released on Android!
https://www.thegamecreators.com/post/appgamekit-mobile-released https://play.google.com/store/apps/details?id=com.tgc.agk.mobile 金曜日､2018年3月2日にTGC NewsのAppGameKit News､
今日､Androidプラットフォーム上のAppGameKit Mobileがリリースされました｡
今では､AppGameKit Mobileでどこでもどこでもアプリ､デモ､ゲームを作成して､｢外出先で｣コーディングすることができます｡
この完全に無料のAppGameKitのバージョンでは､通常のAppGameKitスクリプト言語を使用してコードを作成してから､プロ
ジェクトをコンパイルしてデバイス上で直接実行することができます｡このアプリにはデモとサンプルが付属しているため､新
規ユーザーはプログラミング言語の使いやすさを知ることができます｡
カットダウンしたIDE内でアプリケーションをコーディングしてから､超高速コンパイラを使用して､プロジェクトをほぼ即座に実
行することができます｡クラウドを追加して保存すると､あなたのプロジェクトをTheGameCreatorsのウェブサイトにアップロー
ドして､プロジェクトを安全に保護したり､Windows､Mac､Linux版のAppGameKitでコーディングを続けることができます｡
AppGameKit Mobileは､デスクトップ版の多くのコマンドへのアクセスを提供します｡最も重要なのは､ゲーム作成のためのす
べての主要なコマンドです｡
･3Dグラフィックスと3D物理
･2Dグラフィックスと2D物理
･レンダリングコントロール
･サウンド＆ミュージック
･ユーザー入力
･ファイルI / O
･センサー
カメラと写真のアクセスでは､あなたのデバイスから画像メディアをインポートしてから､これらの画像をアプリケーションのス
プライトまたはテクスチャとして使用できます。
今すぐ無料でダウンロード！
>>222 サーバーサイドだとC#/.NET Coreも浮上してきたしな
言語の筋が良かったから期待したけど、結局一過性の流行で終わりそう
Kotlinは要するにBabelだろ
>>219 違いがあるのはいいが
コードの読みやすさで静的動的で比較もいいけど、
テストコードあるかないかで比較したものも載せて欲しい。
型があった方が読みやすいコードもたくさんあるのは事実だけど。
コードリーディングという意味では型情報はありがたい。でも引数に何を入れればいいかLAPACKくらいしっかり書いてあるとなお良い
>>234 比較って言ってもこれは独断と偏見に満ちた個人的な印象値だぞ…
参考にして欲しくて書いたわけじゃなくて認識の違いを明らかにするために書いたものだし…
あと、静的動的どちらでもテストは書くんだからテストがない場合と比較することに何の意味が…？
なるほど話が噛み合わないわけだ。
状況が変わったのにまだ気付いてないんだな
嘘うんぬん以前にガイジなせいでウンコードまみれなペチPoorさんはどうすればいいの？
嘘ねえ……そういえば昔知りもしない言語の嘘八百ばらまいてた人いたなあ
>>240 phpディスってる人も多いけど、タイプアノテーションついてだいぶ改善されつつあるんじゃないの。結局仕事にはphpも多いからlinterとか環境整備して開発しやすい状況は作っておきたい
タイプアノテーションだのlinterだの、PHPerがいらねーって騒いでたものばっかりやん
>>237 いまいち話が掴めないんだが、テストを書くのが面倒だからイヤって奴はクソって言いわけ？
俺はできればテストは書きたくないよ。面倒だし。でも書かないわけにはいかない
だったら、テストは書くがテストを書く量を減らしたい
動的型より静的型のほうがテストを書く量を減らせそう…と考えている。
実際に減らせるかどうかはデータを取ってみないと何とも言えないけど
少なくとも動的より静的のほうが減らせるという意見はあってもその逆はない
最低限のテストさえも書こうとしない奴は論外なのでそっちの話はしたくない
静的型派の奴はテストは書きたくないって意見は俺以外にもいると思うけど
>>250 動的型の連中の大半は現実にはテストなんか書いてないよw
常識的に考えて、たかが型書く程度のことを面倒臭がる奴がテストなんか書くと思うか？
全くもって机上の空論よ
フォローしとくと、そもそも動的型で書かれるシステムって簡単なCRUDだけで構成される単純なものが多いので、いちいちテスト書くのは大袈裟
型すら理解できないやつが、インプット・アウトプット理解してテスト書けるわけないだろ
>>249 誤字訂正
訂正前＞テストを書くのが面倒だからイヤって奴はクソって言いわけ？
訂正後＞テストを書くのが面倒だからイヤって奴はクソって言いたいわけ？
ペチバカの話は他でやれ
Qt使った時、単体テストが簡単にかけたので書いてたんだけど、まあ確かにテストは良いものだよね。
Javascriptも少し勉強してみたんだけど、あれはとても難しいものだな。
>>255 COBOLの開発ってかなり厳密にテストするぞ
PGの頭の品質はともかく、開発プロセスまで含めた品質はPHPと比較するようなものではない
PHP案件って負の遺産・ゴミ扱いで、下請けに押しつけられてるイメージしかない
PHPがゴミだとは思いませんね。
次世代言語について話すのであれば、C++2aは欠かせないでしょう。
Boostの逆襲もすでに始まっていると思いますね私は。
Networking TSがいま人類に必要なもの。
phpで書かれたサーバサイト置き換えるとしたらなに使うの？
いまはPHPの代わりはないだろな。
Javaはあらぬ方向に向かっているからいずれ消えるだろう。
C++があるのにDやGoを使う意義が見いだせない。
日本は国家戦略としてC++に取り組むべきではないだろうか。
俺の感じでは、C++はネットでこそ強みを発揮できるのではないだろうか。
俺もそれが言いたかった。
>>250 >最低限のテストさえも書こうとしない奴は論外なのでそっちの話はしたくない
まあ残念ながらこういう輩が普通に静的、動的がどうのといってるから故の
主張なんだけどね。
型について明示することに関して個人的には別に面倒ともなんとも思ってない。
コードが増えてきて型を分類、整理するのが大変なだけで。
主に c/c++ でアルゴリズムや数値計算の仕事だからかも知れんが、
際どい数値例のテストコードなんかのが百倍くらい役立つわけよ。
>テストを書くのが面倒だからイヤって奴はクソって言いわけ？
まあ端的にいうとこうなる。
プログラマは怠惰なのは悪くないとかバカみたいな格言を持ち出してでも
言い訳してしないからね。
それくらいテスト嫌いってのは根深いと思う。
動的言語でテスト書いてもあまり役に立たないんじゃないか。
c++でサーバサイドを書くのってかなり特殊例だよな。どうゆう用途で使ってんの？
たまたま書いてみたら異常に早く安定してるので、これはもしかして？←イマココ。
BoostにHTTPやWebSocketが入ったんだよな。
C++でサーバーサイドを書く時代がやってきたのは間違いない。
今あるものをC++に変える必要は全くないが、今から新しい世界を切り開いていくものは、C++で始めたほうが効率よいだろう。
テンプレートエンジンはDOMが遅いから必要になるもので、もしもDOMが早ければ必要性は減るのかもしれない。
C++はとにかく早くて省メモリーなので、使わない手はない。
conceptもimportも言い出してからずっと仕様に入らない言語が何だって？
>>296 実装したことのない馬鹿が言い出したことはスルーするのが吉
サーバーサイドC++を始めるなら今です！チュドーン。
小資本が大資本と戦う武器としてC++は良い選択になりえる。
C++が速いのではなく早いならこのスレでは時期尚早でもう話すこと無いな
オレもNGするか…さようならC++、信者に恵まれなかった言語よ
Webサービス開発に絞った話な。
危険性を理解したうえで使ってるのかと思ったらそうでもないんだな。
私が思うに、決定性を持つアルゴリズムで解析ができないものはすべて危険であり、ネットワークでは避けたほうが良い。
一方で、決定性を持つアルゴリズムは様々な理由をつけてネットワークから排除されてきた。
現状でウェブ上のすべてのものが危険であり、容易にハックされ得る。
まぁ、nodeオンリーだと確かに辛いところは出てくるな。
>>313 QRコード画像を作る処理ですら重いんかnode.js。
まあ、技術者にありがちな典型的な「やりたかっただけ」だろうな
node_modulesの中を見るとゲロを吐きたくなる
>>314 重くはないが、シングルスレッドなので詰まる。
cluster使ったところで、ワーカー数使い切る。
npmにモジュールあったから、へぇと思いながら使ったらこうなった感じ。
やりたかったからと言うより要件だったから、かな。
>>316 クライアントは台数凄いけど基本IE8のエンタープライズモードという悲しいイントラネットなのよ。
ブラウザは無力と思わないとどうにもならん。
そいつらがリアルタイム更新したいとかで、万台のlongpollをどう捌こうと言うところで白羽の矢がたった感じ。
それ自体は良かったよ。
node_modulesはせめて圧縮できないかねえと思ってしまう。
>>318 ワーカー数使い切るってどういう事？
基本cpu数で回していくもんじゃないの？
>>319 cpu数立てても、全部同じように同じタイトなループがあるハンドラで詰まって、結果フリーな子が居なくなるって意味のつもりだったよ。
外部へのioだったり、外部プロセスだったりと非同期で帰ってくるものを使わないと当たり前だけど意味無かった。
clusterも結局プロセス立ってるけど、そいつら自体はシングルスレッドだし。
>>320 それってつまり実装の問題ってことか。
現在はasync-awaitを使えるから非同期処理もだいぶ書きやすくなったし、結果は変わってきそう。
>>316 IE8でもbabelとか使えばクライアントサイドで行けたんじゃないのかな
babelは嫌いなのと、そもそも保証がしにくいのと、ポリフィルまみれになってパフォーマンスがゴミレベルになる。
しかしグーグルさんもkotrinに肩入れしたりdart2出したり、どうしたいのかね？
Googleに開発環境や言語のセンスが絶望的に無くて常に迷走してるのは今に始まったことじゃないでしょ
PythonのライブラリはC言語とOSのセンスを踏襲することが多い
googleの社員は皆思い思いに、プロジェクトを進めてる感じ。
>>331 まだCより良さそうなんて判断は無理だろ。マクロ周りが全貌も見えてないし。
C2は機能は悪くないんだがCの記法を引きずってるのが足かせになりそう
>>328 １つの言語でいいのになんでおもいおもいに勝手に言語作るの？
まあ99.9%の仕事じゃ既存の言語使った方が効率いいわな。
同じものを作り続けるならそうだろうけど、普通要件に因るでしょう
C2？
勝手にc2とか名乗って問題にならないのかな
フォーラムちょっと読んでみたけどまだまだ全然まともなものとは思えんで
オフサイドルールなんて嫌
>>340 ML系シンタクスってオフサイドルールとは違うと思うけど？
見た目は波括弧だが意味は中括弧か大括弧
C2を名乗るなら既存のヘッダファイルとモジュールの両立を真っ先に考えないと
緊急速報
（＋）【IT】AMD製CPUに「致命的」欠陥 悪用でPC乗っ取りも
http://2chb.net/r/newsplus/1520989318/ （BIZ+）【CPU】AMD製CPUに「致命的」欠陥 悪用でPC乗っ取りも
http://2chb.net/r/bizplus/1520995986/ （ゲハ）【PS4/XONE】AMDのCPUに致命的な欠陥【Ryzen】
http://2chb.net/r/ghard/1520998474/ コンパイルはできるがリンクができないのが現代
C2使ってみようと思ったらこれCのコードに変換してるだけだった
Cのプリプロセスのマクロとかが遅いからとか書いてなかったか？
>>353 コンパイル時間を大幅に遅くするヘッダファイルの使用が問題ってそういうことじゃないの？
Include先がまた別のファイルincludeする大連鎖include地獄のことを言ってるんじゃない？
ポリモーフィズムはともかく継承もインターフェイスも仮想関数も型クラス・トレイトも無いように見えるがこれをクラスと呼ぶのか……？
Nim,Crystal あたりと合わせて altC って感じやな
3つ眺めてみたけどnimに惹かれる。
ここのスレに顔出しててNim知らないのか…
NimはQiitaとかでたまに話題に上がるから
変な奴に好かれて評価を落とした言語という印象が付いてしまった感がある
知らんかったから調べたけどこれはいいや…俺は惹かれなかった。しかし検索性悪いな
マクロとかメタプログラミング向けの機能以外はこれといった特徴無いように見えるね。
何よりCを凌駕するというとんでもないパフォーマンスを持つという記事の存在が大きい
バリアントレコード位しか c(++) より速くなる要素無いがな…
cより速いとか大抵特殊な条件下だったりの煽り記事だけどね。
煽り記事に煽られて有名になった言語
Cへのトランスパイラ言語は何やってるか判ってれば同等になるでしょ。
複雑なことっていうのは、Cにどう変換されるか負えないくらい複雑なことってことだよ
nim performance で検索してトップに出てくる
http://blog.johnnovak.net/2017/04/22/nim-performance-tuning-for-the-uninitiated/ ではレイトレースというごく単純な処理で出てくるコード見ながら色々やってるな
inline 指定したり
複雑な処理は c で書いても複雑(で恐らく遅いの)だから、
簡単な処理が速く書ければいいんじゃない？
上記ページによると Java と JS が数値計算案外速くて笑う
昔LuaJITはぇーって盛り上がった事あったなあ…
今年もrustが愛され言語No1に輝きましたな
Cより速いを名乗るには、C言語では吐けないアセンブリパターンを吐く必要があるはずだが
現行バージョンのメジャーなライブラリでもmalloc/free (new / delete) が結構遅いから
非標準のライブラリを使ってはいけないとかCが遅くなるルールを何個か追加すればいい
そう言われてみると他のスレッドからアクセスされないメモリ/オブジェクトは
*2が勝手に足し算に変わるとか、そういう最適化を勝手にやってくれてるな
>>385 前時代的の異物、死ね。
速度の必要な部分だけを切り出して、それだけをアセンブリコードにすればいいだけ。
>>385 >>374 のリンク先の記事はある程度参考になると思う
なんで死ねって言われたのか理解できない
Cに代わる次世代言語はアセンブラやC、C++で書かれた
普通に考えたら高速な実装を書ける言語がアセンブラやC、C++だとすれば
その普通に考えるってのが前時代的だな
>>392 ということは最近は「代わり」は置き換え可能な存在という意味ではなくなったんだね
それなら前時代的と言われても仕方がない
まあ最近でも低レイヤーの仕事としてGPUのアセンブラチューニングって話はあるけど、
プロが本気で書いたCに勝つのは無理だろ
なんで速さの勝負になるかよく分からんし
>>394 バグを正解に置き換えるならいいが、バグではないものをその1bit棒で叩くのは危ない
immutable云々はデバッグ目的で使えるからCを置き換える可能性はある
これまでどれだけの言語が
Nimの特徴はC並みの実行速度でCより手軽に書けることですか…
NimはどっちかというとOCamlに近い存在だろ
OCamlか…そういえばそんな言語あったなぁ
実行状況に応じて実行しながら最適化ができるから原理的にはVM言語のほうが速くなる
なんか知らんけどこのスレには熱心なOCamlアンチがいるよな
なんか知らんけどこのスレには熱心なRustアンチもいるよな
>>412 Cとかと比べたらね
「速い」ってほど速くはない
JVMよりちょっと速いレベルでしょ
そんな十分とか言い出すなら俺なんかPythonの速さでも十分だわｗ
>>407 「実行状態を調べて最適化」なる余分な仕事の分だけ遅くなる
最適化でそのオーバーヘッドを取り戻せるかどうかは自明ではない
#!/bin/sh
シェルスクリプトが次世代言語とは流石に分からんかったわ
サイコパスあるある
Cに変わる言語は遅い部分をCで書いて"代替"するのか…
速い遅いよりも矛盾をなんとかする方が重要だ
ソフトだからね
Cの良さは
先ずはそのよく分からん「変換される機械語との違いが滑らか」を定義するところからガンバレ
わからんのなら絡んでくんなよ。
言語を1個2個と数える時点で滑らかさが足りない
言語を1個2個と数える
>>434 サイコパスじみてきたな
お前みたいなのが次世代だよ
https://ziglang.org/ Dスレにあったzig
こっちのほうがCのヘッダーを直接使える分c2の名前にふさわしい
まあ、ドキュメントを読む限り未完成っぽいんだよなあ
Life Inside China's Total Surveillance State
新疆ウイグル自治区は中国国内の監視体制の巨大な実験場と化した。最先端テクノロジーで常時監視される人々の生活
VIDEO 中国企業の端末やアプリを使っていると日本人も中共に監視されているのと同じ
>>441 C++ の江添氏が新たに始めた、というくらいだから、水面下で脈々と支持層を広げていっているに違いない
>>444 絶望的に頭悪いな。
IT系の仕事は辞めた方がいい
>>444 遅くて不便な言語が流行る
→ C++で書き直す需要が生じて業界が繁栄
この流れ大切
頭良い人間の気持ちや陰謀を勝手に忖度して勝手に言語化してるように見える
>>447 その内容どれが当てはまるの？アンカーつけて
架空の頭良い人間の気持ち (
>>445 ) や陰謀 (
>>446 )
Haskellの誇大広告のおかげで関数型全般が胡散臭くなった。
ずっと前はてなブログやQiitaでHaskellを崇めてた人全員Haskellで特に何か作ることもなく他の言語に移って行った説
OCamlはなんで演算子は多重定義できないのか結局ようわからん
Stack Overflowが2018年の調査結果を発表。一番使われている言語はJavaScript、一番好きな言語はRustに
http://www.publickey1.jp/blog/18/stack_overflow2018javascriptrust.html 今回、Stack Overflowでは「好きな言語」の調査結果も発表しています。
トップとなったのはRust。2位がKotlinで、Python、TypeScript、Goと続きます。
1位がRustとなったのはその知名度からするとやや意外な気がしますし、
2位のKotlinは昨年2017年5月のGoogle I/O 2017でAndroidの正式な開発言語となったのがきっかけで注目され始めたと言ってもいいので、急速に人気が上昇していると言えるでしょう。
>>453 (+)は ’a -> ‘a -> ‘aじゃない
割に(=)は’a -> ‘a-> boolなんだよな
便利だからいいけど
演算子だけでなく定数にもアドホック多相がある
>>454 Rustの一位が意外って…
これ書いたヤツ去年と一昨年のランキング見てないのかな？
mozillaやgoogleを学閥か何かのように考えているのかね
じゃあPython Go Kotlinの3つが1つにまとまったら組織票？が約3倍になるのか
Swiftは死にそう？trySwiftとかは話題になってるけど
>>462 とびっきり最新世代の言語を一つお勧めいただけますか？
回答いただいてから一週間でマスターしてみせます
このスレに出てきた各種言語もいずれ404になるんだろうなあ。
>>463 このスレにある程度の頻度で登場した次世代？言語を新しい順で並べるとこうなる
Rust(2015.5)
Swift(2014.9)
TypeScript(2014.4)
Hack(2014.3)
Go(2012.3)
Kotlin(2012.2)
Dart(2011.10) -> Dart2(2018?)
D(2007)
Scala(2003?)
OCaml(1996?)
Haskell(1990)
ちなみに言語自体が発表された時期ではなくVer.1.0がリリースされた時期ね
?がついてるのはWikipediaには1.0リリース時期が明記されてなかった…
変なところがあれば訂正・追記してくれ
Nim, Elm, Juliaに関しては最新がVer.0.~でまだ1.0すらリリースされていない
とびきり最新が良いのならこの3つからお好きなのをどうぞって感じかな？
1.0リリース時期で見るとSwiftよりRustの方が新しいんだな…
D, Scala, OCaml, Haskell辺りは次世代言語と呼ぶにはちと古いかも？
次世代言語というのは時期だけで決まるものなのか？
>>468 次世代言語をどう捉えるかによるが少なくとも時期を１つの目安にすることは出来るだろ？
それとGoに関しては必要最低限の機能のみを残し
他をバッサリ切り捨てたという点で次世代感があると私は考える
Typescriptに関してはJSを完全に排除しようとするのではなく
JSとの共存を目指したいう点が新しいと考える事も出来る
次世代の定義なんて物の見方によっていくらでも変わり得る
よって、何をもって次世代と定義するかについて１つの結論に
まとめることは出来ないと考えるのでその話はあまりしたくないな
話題提供を目的に書いたので批判ではなく忌憚のない意見や感想を求む
個人的には広く利用されていないものは次世代とも前世代とも呼びたくない
バッサリ切り捨てた仕様というなら初期のJavaだってそうだし
>>471 何でプログラム以外のところまで抽象化したがるんだ？
初期のJavaの機能が少ないのは必要最低限の機能のみに絞りこんだのではなく
単にジェネリクスもラムダ式もアノテーションも当時はまだ技術が確立してなかったからで
Goのように技術が確立してるのにあえて必要ないと判断して削ったわけじゃない
初期のJavaとは機能が少ないという点で共通しているが機能を少なくした理由は全然違う
Typescriptに関しては共存という言葉を使ったのが誤解を招いたようで悪かったが
トランスパイルした結果のJSコードの可読性にまで気を配って作られているという点でCoffeeScriptとは違う
つまりトランスパイル後のコードの可読性にまで気を配っているという点が
今までのトランスパイル系の言語とは違う全く新しい部分だと言いたかった
行きすぎた抽象化は時に大事な情報までも削ってしまうということを頭の片隅に置いておくべきかと…
何言ってんだ。Javaの登場した1995年には貴方の表でも既にHaskellがあって
C++でももう<algorithm>があってbind1stとかやりまくってたぞ
トランスパイル後の可読性なんてそれこそ無数のプリプロセッサが気を遣ってきただろ
CoffeeScriptのことは知らんが、遠い過去にあった素晴らしい処理系のことは忘れて
近い過去にあった特定のゴミを超えていればいいという話なのか？違うでしょ
>>473 1995年に既にHaskellは存在していたが1995年当時のHaskellに今ほどの知名度はないよね
知名度のない言語の技術はまだ確立していない技術と同義だ
あと今さらだけど初期のJavaとGoって言うほど同じじゃないよね
Goは例外も継承も削ってるし、interfaceだってGoとJavaでは名前が同じだけで別物だし
あとC++のテンプレートとJavaのジェネリクスは似て非なるものだ
同じものとして扱われても困る
プリプロセッサーとトランスパイラーも別物だよね…
最後の一文だけは同意するが…その他はこちらとしても「なに言ってんだ？」状態なんですが…
追記
あ－、1995年だとC++は標準化前だからちょっと言い過ぎた
技術が実在したのは客観的事実だからなあ
>>474 個々の機能のことを言ってるんじゃなくて、当時の目新しいあれやこれをさっくりと無視して
絞り込んできたのが登場時点のJavaの立ち位置だったということ
時代が違うから絞りこまれた結果も違うが、コンセプトとしては似たようなもんだ
関数型ゴリゴリて感じのAlgebra of Programmingも1996年て見てビックリしたわ。
>>477 ,
>>478 技術が実在していたのと確立していたのは別物と考えている
ここから先は個人的な憶測も入るので賛否両論あるだろうということを前置きしておく
Javaはバージョンアップしても後方互換性を保つタイプの言語なので
C++のひし形継承問題みたいな仕様バグは絶対に避けたかっただろうと思われる
そうすると色々な言語で既に使われている枯れた技術じゃないと安心して採用できないだろう
JavaはGoのようにあえて採用しなかったのではなく、採用したくてもできなかったんだろうと考えている
実際のところどういう方針だったのかはJava言語の開発者に聞いてみるほかないが…
もしくはC#のように取り敢えずリリースして
Pythonなら一切型を書かない意図は明確だがGoは微妙
>>478 Javaは当時の目新しいあれやこれをさっくりと無視したのかもしれないけど
Goは継承や例外やジェネリクスなど現在当たり前なあれやこれやもさっくり無視してる
もっと言うとwhileやdo-whileまで無視している
クドイようだがやはり初期のJavaとGoはコンセプトから全然違うものと私は思う
ポインタを消したのがJava
ポインタは消えてない
「Javaにはポインタがない」という言説をそろそろ撲滅したいです。
https://web.archive.org/web/20071111061957/http ://java-house.jp/ml/archive/j-h-b/028505.html
>>486 二重ポインタはありませんので「Java にはポインタがある」とはいいきれないのではないでしょうか？
>>467 rust に決めました！
ジェネリクスの記法で考えると
プロセッサのインストラクションって暗黙に型を要求するよね。
C++には夢とロマンがいっぱい詰まってるような気がする。
>>494 C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
>>495 まあ正論だね。
夢も希望もない正論だけど。
Cは40年以上、C++は30年以上、一線で活躍する言語であり、これらの言語が無くならなかったのにはそれなりの理由があるはず。
GCはおそらくリークを増やすのではないか。
RAIIを徹底することによってリークを無くすことができる。
私はポインタを軽視する風潮に警鐘を鳴らそうと思います。
>>494 の「C++には夢とロマンがいっぱい詰まってる」の直後に
>>495 の「C++ではゲロゲロのゴミが生産される」で草
>>490 h
Rustを一週間でマスターするのはムリだと思うよ
あの言語の学習コストを他言語のそれと同じものと考えてると痛い目に合うよ
>>504 アドバイスありがとうございます、チュートリアル最初の数当てゲームが終わったところです
テストを用意すると自動的にコード生成するのが次世代言語じゃないかな？
>>504 WindowsのアプリケーションはほとんどがC++で書かれており、ゲロゲロのごみとはそういったもののことを言うんですよ。
例えばChromeとかね。
>>495 が偉いのはC++の代わりにJavaではなくCを選ぶところ
C++を使いたくなったらすぐ掌を返せる絶妙な位置
とはいえ、C++にはプログラミングの面白さ全てが詰まっている。
頭の良い若者にはぜひC++にチャレンジしていただきたいですね。
くっ…こいつ(ID:J0Id73NT)全然引かねぇなww
>>501 の「RAIIこそが本命だと感じました」に関してはある程度同意するが
RAIIならC++よりRustのほうが優れてると思うけどね。Dropトレイト便利だよ
次世代言語スレで次世代のRustではなく頑なにC++を推す理由は？
>>505 RustはHaskellと同じで実践で役に立つかはともかく学習しといて損はない言語だと思うので頑張って
言ってる自分もいまだに結構な頻度でコンパイラと格闘してるのだが…
とりあえず所有権・借用・ライフタイムの概念まで終わったら感想を聞かせてほしいかな…
c++ で所有権意識して書く方が、rustでunsafe周りを使うより楽で安全だから。
C++20でうるう年サポートだってよｗｗｗ
>>516 じゃあなんで次世代言語スレに居るんだ…( ﾟдﾟ)？
C++は置いといて、ライフタイムについては何年かしたら画期的な解決方法が開発されて
>>495 でもgccも今ではc++で開発されてるじゃん
>>495 これ、C++に限らず色々なクラスベースオブジェクト指向言語と信奉者に
多かれ少なれ、言えることじゃね？
>>519 コピーと参照のトレードオフは本質だよ。
どんな言語作ろうとそれは変わらん。
超える可能性があるとすれば量子効果のあるコンピュータとその言語か。
∧∧
注ぎ込めるリソースが少ない場合、C++を選択してください。
>>521 まあそうだけど C# や Java では既存の実用的なフレームワークが強い影響力を持ってるから
俺が考えた最強の～的なオブジェクト指向の設計はしないんじゃないか？
Windows アプリの場合 C++ でも mfc や wtl 使うから同様のことが言える
Linusは無料で奴隷をこき使える才能がある。
書き捨てのユーティリティとか書くときも map とか使いたいもんね
Linusは生粋の5ちゃねらだし、あいつのあおりを真に受けちゃいかんよ。
OOはウィンドウシステムと非常に相性が良いんだ。
Linusがカーネル周りの人間って事を忘れてはいけない
KHTMLはIEと同じ表示ができたので気に入っていた。
ただなあ、Javascriptの邪悪さには誰も勝てないと思う。
>>522 もムーブセマンティクスが流行った時は飛びついたくせにー
古くはPascalのconst引数、新しくはswiftのinoutみたいにコピーと参照が曖昧なのもあるし
明確に区別したままでももっといい推論方法だってできるかもしれない
早すぎる一般化は諸悪の根源なんやで
早すぎる最適化や過剰な一般化ならともかく、一般化が早すぎて困ることなんてそうあるかねぇ？
Linusは何も間違ってないし、むしろ高級言語使う側が「楽だから」と目を閉じてるのが問題だと思うけど。
90年代まではそれで正解だったけど、今の時点で「コンパイラが吐く機械語が予測しやすい」のは欠点でしかないし、実際Cコンパイラもかなりの最適化をするわな。
最適化は想定してコンパイルするだろ。Cなら特に。書き方にも関わるし、コンパイルオプションにもかかわるし。
そろそろ人知を超えた最適化を行うAIコンパイラとか出てきても良さそうだけどね
別の方に着目したいから楽ちん高級言語を使っているのに
>>535 いくらでもあるだろ。
めちゃくちゃデラックスなプリント文とかな。
実はお前らが内心で求めてるのは次世代言語じゃなくて前世代言語じゃね？
コピーと参照の違いは代入すればわかる
別の方を着目したからと言って「見ないことにしている」を「見なくていいから楽」と取るのは間違ってるだろ。
ケースバイケースだろ
Cはどのように最適化されるかわかるからそれを想像しながら書くことで
最適化は別にどうでもいい
ネットサーフィンでホームページみると汚い糞みたいなコードしかないからな。
boostは便利なものもあるけれどほとんどがゴミだよね
>>552 テンプレート大好きな感じを何とかしてもらいたいよな。
boost もjavascriptのBrowserifyみたいなツールで必要なモジュール部分だけ取り出して
boostがC++標準委員会のケツ蹴飛ばしたおかげでだいぶ今のC++良くなったじゃん
>>557 boostを・・・というより使う側で配慮すれば分割コンパイルの恩恵にあずかれる。
>>500 PLASMA言語っすか…これは初めて知ったわ
今パッと見ただけだけど、なんとなくHaskellに近い雰囲気を感じた
どこら辺が違うのが詳しく説明してくれない？
>>560 いや、二、三個の関数使うだけであのビルド時間はおかしいぞ。
atCoder今日から始めてみたんだけどc++が圧倒的に多い。
混とんとしたウェブの状況を見ればウェブ屋さんが薦める言語なんて使えない。
本来ネットワーク上で流通するものはすべて決定性を持つアルゴリズムで解析できなければならないだろう。
OWASPの資料を見てほしい。
混とんとしたカーネルの状況を見ればOS屋さんが薦める言語なんて使えない。
本来OS上で機能するものはすべてPOSIXに準拠しなければならないだろう。
>>572 決定性を持たなければならないのはsecurity reasonであって標準とは無関係だぞ。
ウェブ屋さんは昔の論文を読み漁るべきだろうな。
セキュリティに最も関心を持つべき職業なんだから。
すべて文脈自由文法でなければならない
インターネットはウェブ屋さんだけのもんじゃないからね
>>577 HTML一つとっても素人が気軽に書ける時代じゃないだろう。
なぜそうなったかわかるかい？
本来別のレイヤーにあるべきものをHTMLは一つ人類みな友達とかわけわからないこと言って一緒くたにしたからだよ。
html5-tidyでCustom elementのサポートについて議論があって、いろいろ考えさせられる。
政治的というのは「人類みな友達」のことじゃないだろう
OS/2 WARPの資料を見てほしい。
まあセキュリティー商売なんてのは危険を煽らないと成り立たないからな。
>>578 いやあ未だに適当に書いてるよ
プロだってほとんど適当だよ
HTMLは俺もクソ適当に書いてるわ
HTMLはタグの数を極力減らして
reactとか？
ReactでSSR、サーバーサイドでレンダリングした結果をクライアントで引き継げて凄すぎ！
画面の大きさがPCとスマホで全然違うからデザインが違う
>>584 HTMLとして見ればその通りなんだろうけど、XMLで作ったデータフォーマットからウェブも含めた何かを作ってるような人たちには許容できない部分なのかもしれん。
PageMakerで組版してる人たちとか。
同じブロック要素でも、naviとarticleは文字詰めの方法が違うとか、そういう部分で、何でもdiv+classにすんなと言うのは充分わかる。
>>584 書き捨てで誰もメンテしないならそれでいいだろうな
そんなのレビューしなくていいと思うけど
考えるのに紙は依然として役に立つけど、読むのには紙である必要がなくなってきたな。
PageMakerじゃないな。普通に名前間違えた。FrameMakerとか。
>>592 電池が要らない、
濡れても乾かせば大丈夫、
乱雑に投げられる、車に轢かれても壊れない、
複写を他人にページ単位で簡単に渡せる、
そのへんの筆記具で好きに書き込みが出来る、
氷点下20度でも使える、
破れてもセロテープで取り急ぎ直る、
完全に読めなくなっても比較的安価に買い直せる
このあたりが紙の冊子が電子媒体で駆逐できない所だと思うよ。
特に取説とか。
「QRコードを印刷する紙がないぞ」「あんなの飾りです」
手触りで大体のページを把握するってインターフェイスに慣れ過ぎてるから
民主党→民進党のように名前をちょっと変えると爆発的に売れる場合もあるからな。
>>591 保守性という観点で言えば、DRYさえ死守してれば後は些細な問題だと思うよ
HTMLに限った話じゃないけど
>>594 収益に直結してないものはやりたい人がいなくなったらそれまでだからな
>>602 全部グローバル変数で名前規則さえ死守してればいいとでも言うのか？
>>604 Haskellと重複する部分についてDRYを死守する方法を話して
http://www.stroustrup.com/JSF-AV-rules.pdf ロッキード・マーティン F-35 Strike Fighter Air Vehicle 開発のためのC++コーディング・ガイドライン。
※URLでお分かりの通り禿が関わっています。
プログラム技術という観点では政治も経済も経営もNG
政治では名前が長くなり始めると危険領域だよな。
Googleのコーディングガイドラインは名前はいくら長くなっても良い、省略された名前はダメと述べているからな。
つまりこう
getInfo なんてのは Android の api でも見かけるし
理由がわからない命令に従うから暴走するんだな
例えを出しただけなのに「理由がわからないなら反対しろ！」と言われましても…
馬鹿らし過ぎる。。
>>624 反対しろとは言ってないぞ
しかし単語の組み合わせを少し改竄するとそういう意味になる可能性はあるのか
だから短い単語を組み合わせるのをやめて長い固有名詞を一個だけ書くのか
goだとどいつもこいつもクッソ短いんだけどな
>>626 哲学とかも不要な誤解や意図した曲解を避けるために用語をどんどん定義していくよね
今回で言えば「合目的的」であれ、とかか。
でも非常に長い名前は必ずしも判りにくくは無いんだよねああして書いてみると。
見難いのが問題なだけであって。
名前が無いものに分かりやすい名前を付けようとするとどうしてもそのまんまの名前になっちゃうんだよな
C++11から日本語の識別子も使えるようになったんだよな。
最近気が付いたのは、MSは情報を収集するためにちょっと踏み込んだことをしてるな。
もちろん、一括変換がうまく機能しないからこそユーザーは変換範囲を狭めて変換するのだし、誤変換情報が欲しいのは、変換が上手くいかないことがわかっているからだろう。
でもたしかにコードが中国語なら、短い変数名で意味が通るからコードはすっきりしそう
C 風の文法なら名前が空白区切りで並ぶ必要あまり無いし、
>>636 今の中国の字（簡体字）はよくわかりません
>>637 勘弁して。こんな発想はエアプだけだろ。少なくともエディターとの連携がしづらいし。
そもそもどっからどこまでが予約語で変数かどうやって判断するの？
当然の帰着として変数名に予約語を含めることは絶対禁止ってことになるだろ。
想像しただけで死にたくなってきた。
予約語は大文字だけ、変数名は小文字だけで書くとか…
お前ら頭悪いなｗｗｗ
>>646 読みにくいしこうしたらどうだろう？(名案)
var index_of_proxy := 0;
バカなことを思いつくことは誰にでもあるが
いわゆる全角スペース使うとか、とにかくコンパイラにスペースと思われない文字だが見た目がスペースのやつを使えばいいのでは？
DDDとかだとDSLを作るって言うけど
最近の言語って識別子に日本語使えるの増えたよな。まあ日本語っていうかUnicodeなんだけど。
>>657 たしかにそうなんですが…APLの方は記号を読みやすくするために用いているように思えなかったので…
ピタッとはまれば驚愕の短さで書けますけどね
例： Conway's Game Of Life in APL
VIDEO >>654 むしろ文字使用禁止な言語
（コーディングルールじゃなく言語仕様でemojiと記号を強制）
次世代言語感がいっぱいｗ
そういう次世代感か…
チューリング完全になろう系じゃないか
テンプレ(異世界転生or転移、チート、ハーレムあり)小説が量産されるみたいなノリで
Fortranのサブルーチンみたいな感じで副作用は全部intent(out)の引数にのみ許すことで実質純粋手続きみたいな言語って他にある？
COBOLとかPLIとか汎用機時代の主役はだいたいそうでしょ
グローバル変数を使うのはパソコンのbasicの時代ではないか
以前の俺含め今時は一時ファイルなんかダサいAPIやメッセージキューにしろなどと抜かす人が多いけど、汎用機を経験するとみんなバッチ信者になるよ
ダサいというのは建前で、JITコンパイラ言語でそれをやりたくないのが本音ではないか
>>669 モックライブラリがこんなに発達してるのに何言ってんだ
>>672 バッチならファイル作って放り込むだけやぞ
結合状態でのリグレッションテストとかもdiff取るだけだし
バッチ処理で何してんの？
>>673 モックならインスタンス作って放り込むだけやぞ
結合状態でのリグレッションテストとかも状態比較するだけだし
>>675 結果が意図しないものになってるときにどうやって途中経過を調べるの？
バッチならファイル見れば一発だけど、全サービスクラスにログ出力入れるの？
>>676 ログ出力も何もオブジェクトのスナップショットとって状態比較するだけ
てか、結合テストで途中結果見てる時点で、それモジュールテストだろっていう
結合テストでは通常おのおののモジュールが期待した結果を出力することを前提に振る舞いテストのみを行うだろ？
てか
>>674 も書いてるけど、バッチ処理なんて前提条件厳しすぎるし、障害対応もめちゃくちゃ大変だろ
今どき、そんなシステムどんな業種で開発するんだ
>>666 純粋手続きってのがわからん。
引数にin outだったらadaも付けれるぞ。
>>680 Fortranのpure subroutineのことや。まんま訳して純粋手続きって書いたけど、分かりにくいなら以後pure subroutineって書くわ
>>680 Fortran等の昔の言語には、サブルーチンと関数の区別があって
サブルーチンは副作用あり、関数は副作用なしって使い分けがあったんだよ
(その区別はAdaにもあったんだが、2012年の改定で関数もoutパラメータを持てるようになってしまった)
>>682 intent(out)さえつけといたらsubroutineにもpure修飾子をつけれることを俺は
>>666 で言ったの
>>683 あーすまん、話の流れを追いきれてなかった
言ったのと言いつつ言ったつもりになってただけだわ。謝られるとこっちが申し訳ない
元々の問いに対する答えは持ってないけど、そもそも
そういう、単に複数の値を返したい(outパラメータを使いたい)からというだけで
>>688 そうそうそれそれ。汲み取ってくれてありがとう
タプルで返すのもいいんだけど、大きなベクトルとか行列とかは返り値として返そうとすると確保やらコピーやらのコストがかかっちゃうから、サブルーチンって結構いいと思うんだよね
でかい配列を返すとして、オブジェクトを複製せずポインター返しておしまいという言語も多いし
それのオーバーヘッドがどの程度のものなのかよく分からんで不気味に感じるんだよな。俺が勉強不足なだけかな
ベンチマークとれ
毎回毎回 (N)RVO が効くかなと頭使ったりプロファイル計測したりするより
なるほど。
c++ の場合 RVO (return value optimization) が最高に効けば
C++ならplacement newを使う手もありそうだが実際に使いこなせる気がしない
どうでもいいな。
そんな細かいことで速くなるような状況ならインライン展開されるだろ
マルチスレッドを考えるとスタックはスレッドローカルなので速度だけの問題ではない
>>699 >>直接的なやり方
それがintent(out)なわけだが
あすまん
>>699 は
>>697 へのレスか。それ分からずに変なこと書いた
>>697 その「可能性がある」ってのやっかいだわ
そもそも返り値使いすぎなんだよな
その言語の推奨されるスタイルに合わせるべきじゃね？
C++ならちょっとしたことで
>>697 のどっちがいいか変わるとかには目をつぶって
返り値使うべき
Fortranならoutパラメータを活用すればいいだろ(タプル無いし)
そこから外れるのは実際に速度が必要になってからでいい
そう。その推奨されるスタイルとしてintent(out)を採用している言語って少ないよなあーと思うんよ
このスレ的にあれどけどc言語がそうだ
C言語はスタイルとしてはそうだけど、言語機能としてポインタ渡しとoutは区別されてないな
まあ直感的には引数はインプットで返り値がアウトプットってのは自然だとは思う。
Cはintent指定出来ないことに目を瞑ればかなり良いんだけど、配列の範囲外アクセスチェック周りとかが原始的すぎてデバッグしんどいなあ
そもそもpure宣言相当が無い、つまりどんな関数も副作用が有りうると想定する
「副作用が無いDSL」のインタプリタをCで作るか
libC関数もヘッダに情報が入って、pure から pure じゃない関数を呼んだらコンパイルエラーになるくらいになったら意味があると思うけど。
画面に出力するのは副作用？Thunderbolt3で接続したGPUボックスをGPGPUとして使った計算は？
その辺はHaskell的なアプローチでいいんじゃない？
Cって
Nimって疎結合にしても密結合なCくらいのパフォーマンス出るんだろうか？
ライバルたり得たPascalが
疎結合の意味はよくわからんがdllやsoの中身はほぼ全部Cの関数だろ
高級言語からCの方向で見てるからの感想だろ。
ドライバのようにインタフェースを関数ポインタで定義して実装を分離するみたいなのが疎結合のC？
>>726 それはコロンブスの卵だから無意識に選択肢から外してしまうんだよな
任意の言語でできることをやっても特定の言語の手柄にならないから
作者のwirth先生はPascalを教育用、ModulaをOSも書けるように作ったのに
つか、スレタイから次世代言語をはずした方がいいんじゃね。
>>730 次世代を語るためには旧世代を知っておかねばならんのだ（ｷﾘｯ
>>729 C++のポジションを狙う言語には「なんなんだよこの仕様＝うっとうしい」もついてくるからｗ
>>733 C++のポジションを狙うRustには「なんなんだよこのアンチ=うっとうしい」もついてくるからw
ネタにしてるが、マジで旧世代言語知らずに次世代なんて語れんだろう。
そもそも次世代言語ってまだない言語を夢想して話せってこと？無茶いうな
あのアンチはRustに職を奪われたからね、しょうがないね
なんでこんなrust普及の妨げにしかならんこと言いだすんだろう。
UE4やHoudini使ってると次世代言語はビジュアルプログラミングでいい気がしてきた
Rustは次世代言語だがC++知ってた人と今から勉強始める人の格差はリセットされないな
>>739 MSは何故GUIエディタを放棄してXAMLなんぞ作ったんだろうか……
補完ありのテキストエディタならいくらでもいそうな気がするが。
>>739 じゃあdiff取ってみろ。
テキストを超える記述方法は無いよね。
>>739 同意
テキストよりビジュアルの方が人間の頭脳に優しい
Cはグローバル変数の使い方やOOPのやり方みたいなローカルルールないと無理っぽい
>>752 まじでー。普通のcrudなweb案件とかもあるならやってみたい
小学校でプログラミングを教えろ、ただし中学レベルの数学を教えるな
どこかの評論家に否定される前に、自分で考えて肯定すればいいのに
>>759 は自分で考えてなんの問題もないと肯定したレスだろう
>>758 まあGoogleの中の人は例外すら理解できなくてGoに盛り込まなかったくらいだからな
Googleのプログラマは小学生レベル
>>762 例外なんて機能を欲しがるとか正気か？
タプルかタグ付きユニオンのある言語には例外なんて必要ない
むしろ、無いほうがよほど筋が良い。よりによって例外かよ…
Go言語の問題はもっと他にあるよね
ジェネリクスとかNil安全とかラムダ式とかイミュータビリティとか
>>764 100得ナイフを欲しがっても無理だぜ。
お前さんは、刺身包丁では肉を斬りにくいと文句いう人なの？
ここでのクソみたいな議論に時間を使うことが一番コスト高ってことを
>>764 例外ってか戻値無視してたらコンパイルエラーにする構文がほしい。(すでにgoにあったらスマヌ)
ライブラリやミドルウェア作るとき、ここでエラーならそれ以上処理進めんなってことあるので、アプリ側のエラーハンドリングを強制させたい。
それができないからやむを得ず例外で終了させてる。
>>769 例外とコンパイルエラーを同じものと考える神経がわからん。
実行時にまずい処理が来たらgoのプログラムを強制終了させたいならpanicがあるが。
つーかgoが気に入らない理由に例外を上げるけど、例外ってそんなに良いもんかね？
>>766 問題って書いたのが誤解を招いてしまったかな…
別に上記の全てが無いとダメって言ってるわけじゃないよ。あったら嬉しいなくらいにしか思ってない
けど、例外なんて邪魔にしかならん機能を欲しがるくらいなら他に欲しいものがいくらでもあるだろと思って…
あと、揚げ足取って悪いけど、100徳ナイフを欲しがってるなら例外も欲しがってるはずだろ…
例外と継承を捨てたのはGoの英断
>>772 いやお前は悪くない。相手が意味ワカラン奴なだけだ
>>771 >例えばこの関数は例外を上げる可能性があるからtryブロック内に書かないとコンパイルエラーになる言語ってある？
Javaの検査例外とSwiftの例外はtry必須だよ。
けど、try必須だと書くのが面倒なんだよね。実際、Javaでは非検査例外のほうが主に使われてるし…
検査例外と非検査例外を場合によって書き分けるのがJavaの理想なんだろうけど、現実はそうじゃない…
Swiftの例外はtryの書き方が何種類かあるからJavaより使い易くはなってるんだけど
Rustと同じでタグ付きユニオン(enum型)あるから別に必要なくない？ってなる
Rustはエラー処理にenumのResult型を使うけど、Swiftでは例外を使うのがマナーなのかな？
>>775 swiftはそうだったな。
たしか例外周りはswift2で追加実装されてウゲーってなった覚えがあるような。
swiftの言語仕様の変更は凄まじいものがあるよな。もうswift4だっけか？
正直swift信奉者≒apple信者じゃないと説明がつかない。
言語仕様をミニマムに抑えて熟考するgoを見習ってほしいわ。
>>775 つまり結局goのエラーハンドリングの面倒くささと一緒になるってことだよな？
goのエラーはただの値だから
構造体のメンバ変数に格納先を用意してやれば、
後で纏めてチェックしたり、
一回でもエラーが発生したら処理を中断する
みたいな書き方は全然できる。
そのへんはgo blogに記事があった。
>>771 goの例外不在についてはerrorの握りつぶしが書きやすい上に気づきにくいのが不満
握りつぶしに比べたら先送りのほうがまだ良い
>>769 が戻値無視してたらコンパイルエラーって言ってるのはそこが理由でしょ
>>778 あー。なるほどと思ったけど例外処理は先送りしたあげく、結局とこでも処理せず終わるパターンあるよね。
握りつぶしが簡単にできるのはどっちも一緒では？
>>779 ハンドルされない例外は処理の中断になるけど、
握りつぶしは処理の続行になる
中断のほうが良い、と思う
>>780 例外の一番の問題は予想外の場所で例外が不必要にキャッチされて、その上で
握りつぶされてしまった場合、握りつぶされた場所を特定するのがかなり面倒臭いこと。
そんなコード書くヤツが悪いと言いたいが実際にいるんだからしょうがない…
どこで握りつぶされるか分からんリスクを背負うくらいならその場で握りつぶされた方がまだいい
因みに、エラーハンドリングに関してはRustのResult型が最も筋が良いと思ってる
Result型なら故意に握りつぶそうとでもしない限りは簡単には握りつぶせない
>>781 goのほうが握りつぶしが書きやすいからこそ、どこで握りつぶされるか分からんリスクはgoのほうが大きい、と思うんだよなあ
>>781 トラブルシューティングの為に、キャッチした時点でロギングしないの？
Cのprintfの戻り値を毎回欠かさずチェックしてる人だけが例外に石を投げなさい
戻り値の握り潰しは局所的・静的に判断できるけど例外はそうじゃないからなぁ。
例外は継続的な改良に対応しやすいのがメリットなんだよな
最初はexit
>>758 1から10までの整数を足すのに
ループで順番に足す方法を教える様なのが
今の日本のプログラミング学習(教育)だからな
そんなんじゃだめ
このスレも例外が理解できない幼稚園児ばっかかよ
自分で選んだ言語がそれだったらそれでもいいよ
このスレの議論はほんとレベルが低いな
>>782 なんか会話が噛み合わないなと思ってたがやっと理由が分かった気がする。
>>782 の言う"どこ"はGoのエラー(戻り値)は握りつぶしがしやすいから
誰が"どこ"でエラーを握りつぶすコードを書くか分からないって意味の"どこ"だよね。
俺の言う"どこ"は例外がスローされた場所に対して
キャッチされる場所が"どこ"か分からないって意味の"どこ"なんだよ。
キャッチされる場所が分からないとデバッグ時に探すのが面倒なんだよ。
Goみたいに戻り値としてエラーが返されるとエラーの発生場所と
握り潰した場所は必ず一致するからデバッグしやすい。
結局、従来の例外はgoto文と同じでフローが飛ぶから気持ち悪いってのが俺の意見。
従来の言語にはexitがあるから例外がない
>>791 でも、次世代言語って間違った使い方(プログラマによるミス)をさせないように
制限をかける意味合いが強くない？Null安全とかその典型だと思うんだけど。
オレは絶対に使い方を間違えないって言うんならC++, C#とかを使ってろよってなるし…
>>792 戻り値のエラーを握りつぶされると、不適切な状態で動き続けるから、デバッグが困難になると思うんだが。
例外の握りつぶしでも同じ事だけど、構文としては、例外の握りつぶしの方が見つけやすいと思うけどね。catchブロックでしか細工できないから。
goだと正常な返り値の隣に,_つけるだけで握りつぶせちゃうから、見つけづらいんじゃないかな。
間違えを考慮しないシステムの恐ろしさを全くわかってない奴はそもそも話にならん。
>>795 すまん。よく考えると確かにデバッグはどっちも面倒なことに変わりないわ。
ただ、個人的にはtry-catchも,_もどっちも見つけづらさは大して変わらないと思ってる。
デバッグ時じゃなくて、普通にコードを読むときに戻り値でやったほうがフローを把握しやすいってことが言いたかった。
返り値でエラーを判別するコードだと、本来やりたいことの次にほぼ必ず、エラー判定処理が入るから、可読性が低いんだよね。
後、最近のIDE使ってると、todoをコメントに入れとけば、あとでそれを、まとめて見直せるから、取り敢えず、try-catchして、catchのところはtodoにしといて、まず正常系を一通り買いてから、あとで異常系に対処するっていうワークフローにできるのが、例外の利点かなと思う。
>>792 デバッグ時に、どこかでエラーが握りつぶされてるかもしれない、というパターンを考えないといけない、という意味で「どこ」
しかもそういう状況は
>>795 の言うように不適切な状況で動き続けるから
握りつぶした箇所と不具合の発生箇所がかけ離れることも多い
だから、goに限ったことではないが、エラーや例外の握りつぶしはデバッグしづらい
例外がどこでcatchされてるか探すのは、握りつぶし探しに比べたらまだ簡単
>>799 タグ付きユニオンがある言語ならそれが一番だと思う。
前にも言ったけど、エラーハンドリングに関してはRustのResult型が一番筋がいいと思ってる
でも、Goにはタグ付きユニオンがないからなあ…
goは本格的には使ったことないけど、無視はできないんで、いろんなコードを見てるんだけど、今のところの感想としては、goって、書き手の思考を遮らないというところに重きを置いてる印象。
副作用禁止ならexitも例外も禁止だからEitherがある
握りつぶしてるところでスタックトレース出力するんだよ！
maybe, eitherがある言語やった後に無い言語はしんどい
Maybe, Eitherは強い。ほぼ必須な体になってしまった
Eitherは初見だとそれがエラー処理用によく使うっていうことが
>>803 書きやすさと読みやすさは同一だと思ったが。特にdeferとか大体close処理では？
open直後はdeferにclose処理書いてあったほうが読みやすくないかな？
defer はスコープの終わりで暗黙的に動くクラスのデストラクタより
>>792 > Goみたいに戻り値としてエラーが返されるとエラーの発生場所と
> 握り潰した場所は必ず一致するからデバッグしやすい。
俺もそれには同意で、更に一歩すすんでc++17の nodiscard属性みたいな指定ができるてほしいんだよ。デフォルトはコンパイルエラーで。
Fortran のIO関係のエラー処理は優れてると思うわ。
goのdeferは、その中で起こったエラーを外に通知する(簡単な)方法がないってんで
>>818 一番簡単な方法は名前つきreturn変数を使うことだから簡単ちゃ簡単
だが正直名前つきreturn変数がそもそもクソ構文
>>817 異常終了してはならないUIもある
UIが言語に影響を与える
>>819 はー、名前付きreturn変数なんてあったんだ
しかし本来の流れによるerrがある場合は握りつぶさないようにしないといけないし、真面目にやると分岐が入り組みそうだな
>>820 いやそのためにerr引数があるのよ……
>>816 MSはかなり昔からそういうの力を入れていて独自仕様で実現してるな。(SAL注釈)
SDKのヘッダなんかで見かける _Check_return_ とかとかいうやつ。VSの「コード分析」でチェックしてくれる。
理想はエラーハンドリングを書いてなかったらコンパイルエラー。
コンパイルエラーは、そこまで強烈にエラー対応必須にしたらスクリプトみたいな「まずはとりあえず動くコードを書いて様子を見る」っていう使い方は出来なくなるな
Goの名前付きreturn使うとアセンブリまで落としたとき、コードが少しきれいになるぞ。
>>828 返値の最適化だけが目的なら初めからresult変数方式のやつ使えば
Pascal、Eiffel、あとFortranもそうだぞ
デバッグは自分との戦い
>>829 だけが目的と言うか、優劣をつけたりGoを使う理由にはあんまりしてないが。
例外は俺も好きじゃないな。
ただのちょっと見た目のきれいなgotoであって、フローとしては全然きれいじゃないし、
finallyで複数のリソースの開放しようとしたらどこまで進んだか管理するしかなくなるし、
各エラーで細かい処理が必要だったら結局スコープの狭いtry-catch書くことになるし、
毎行errチェックしたり、いっそ無視したりするのとレベルが変わらん。
deferは、実際に使えた直後に開放を予約できるから価値がある。
良くできてると思うけどな。
>>825 そこは、エラー戻値無視するな構文を用意してれば良い
>>829 え、すまん。よく知らないんだけど、Fortran って関数で配列を返してもサブルーチン的ないい感じに最適化してくれるの？
>>833 されるよ。全部の実装でそうとは断言できないけど
要するに
>>697 のretvalが直接返り値用の変数として見えるってだけ
何でここの人たちエラーをその場で処理するのが当然だと思ってるの？
>>835 その「上」の関数ではどうすんの？また上に投げるの？
なんで2ちゃんでこういう議論をすると最期は必ずアホアホ展開になるの？
>>835 俺は、その上側でのエラーハンドリングを必須にすることができて欲しいという意見。c++17の nodiscardみたいなの。
rustのResult型や他言語のEither勉強不足でわからない。スマヌ
>>835 マルチスレッドが普通になったから
上に投げるよりスレッドの外に投げる
rustのResultは検査しないとコンパイラにワーンされるよ
>>835 上に投げるとしても、戻り値で明示的に戻せば良いだろう。
とりあえず手に負えないからだれか呼んだ人処理して、って言って、だれの手にも負えない可能性がある、ってのは良くないと思うよ。
普通とか言い始めると誰の普通かはっきりしないから、それはおいといて。
goでも、ホントに戻り値なしで呼ぶとき以外(何かしらの値とともにエラーが帰ってくる時)は、_で明示的に握りつぶさない限り受けた変数に触らないとコンパイル通らないし。
何一つ受けずに呼び出したり、触った結果握りつぶしたらコンパイルは通っちゃうけど。
例外安全を徹底してればどこでキャッチしようが手に負えない例外なんか無いだろ
>>844 徹底する、というルールベースな時点で「手に負えない例外は存在しない」という事を言い切るのは不可能でしょ。
メインロジックではアプリケーションの総合ハンドラでメッセージ出してリトライさせれば手に負えるはずの例外だったが、
なんの因果かそいつがバッチプログラムに使われる事になった時とかなんて、前提条件や処理フロー自体が変わる典型だと思うが。
最初からエラーとして返しとけば、なんの問題もなく流用できるでしょ。
常に呼び出す親が(さらに親へ丸投げするかの選択も含め)処理することが義務付けられてるほうが明示的だよねって言ってるんだが。
>>845 戻り値なら流用しやすいという根拠は？
なんとなく手抜きっぽい、で批判する典型的な日本人的思考だね
あと、例外機構を持つ言語には例外安全を維持するための仕組みが組み込まれているのが普通だから、
>>846 書いてるだろ。
明示的に処理するからだよ。
すっぽぬけて何処か別の定義されている「はず」のハンドラに任せない所。
全関数にtry-catchを書いてて、親にもtry-catchが漏れなくあって、明示的に再throwしてたり、異常な場合はちゃんと死ぬ事が保証できてるなら、それでもいいけど。
この関数では呼び出し先がthrowすることもあるけど、親にハンドラがあるから大丈夫、が一箇所でもあったら認めないが。
何か、戻り値でエラーを返せる言語使ったことある？
パターンマッチングでエラーか結果か判定できたり、複数結果を返せたり、引数でエラーをどう処理するから指定できる言語。
使ったらわかると思うけど。
>>848 ダブルスタンダードでもないよ。
維持するための仕組みがあったって、維持していると保証がない限り維持は出来てないのと同じでしょ。
recoverがあるから、catchできるのと同じだからエラーハンドラここに書くって言う奴と同類に見える。
暗黙的に握りつぶす/無視する、か、明示的に握りつぶす/無視する、だけの違いなんだが。
>>849 そんなことはプログラミングのメインストリームがとっくの昔に通った道なんだよ
Javaの失敗をトレースしてるようにしか見えない
Javaの検査例外がなぜ失敗したかを調べてみたら？
>>852 「そもそも例外があるから、こういう失敗するんだ」を「例外無くして明示的にやろう」
と言語仕様で厳しくやってるだけで、
トレースしているどころか、トレースしないように別ルート取ってるだろ。
どこがトレースしてるの？
>>853 まさか検査例外を知らないのか？
あれは戻り値によるエラー処理を強制してるのと等価だよ
まずは勉強しよう
日本人的だとか、ロジカルでない事をグダグダ言う前に、いろんな言語の言語仕様みてくりゃいいのに。
>>854 知ってるよ。
非検査例外と検査例外のどちらも発生させうるメソッドはどうハンドリングするの？運用のルール？
結局全部検査例外なら良いって話になっちゃうし、throws書いたらガバガバになるだけじゃん。
jsでasync await使おうとするとエラー系は例外扱いになるから辛い。
>>855 Fortranを話題に出してるのは俺で、俺はFortranユーザーだ。なんか用か？
>>858 いやいや、そういう意味じゃない、誤解させてすまん。
引数でerrの取り扱いしたり、名前付き引数があったり、そういう言語を触ったことがあるのか？
皆はそれぞれ使ってて、メリットを分かって話してるが、自分(ID:2gnvm26g)は戻り値でそういう処理をする言語は触った事があるのか？
話題についてこれてるか？Javaかなんかの狭い世界の話ししてるんじゃないのか？
って事を言いたかったんよ。
>>861 ああそういうことか。誤解してたわすまん
>>861 俺は普通に使ったことあるし、戻り値をエラーに使うことを否定したつもりはないぞ？
ただ、あんたの主張はJavaの検査例外が失敗した理由を解決していない、と言ってるんだよ
>>862 いやいや、俺の方こそすまん。
慌てて説明したから名前付き戻り値を名前付き引数とか言ってるし。
重ね重ね面目ない。
例外設計に関してはrustが現状ベストだと思うけどな
>>857 unhandled promiss rejection出た時の絶望感半端ない
>>863 解決していないんじゃなくて、結果として検査例外の書き方がまずかった、検査例外以外の存在も実は「これ検査例外にすべきじゃないの？」とか色々物言いもつく、
そもそも論として全部明示的にハンドリングする事をデフォルトにして、検査例外どころか例外を無くそう、って話なんだが。
失敗したも何も、クソめんどくさかったりして、throwsを全部につければ問題無いとか変なルールで回避するからややこしくなるだけなって、収拾がつかなくなったんでしょ。
ジェネリクスがない頃からJavaは触ってるし、歴史を知らんわけでもない。
問題を整理し直して解決したんじゃなくて、捨てたんだよ。柔軟さを。
ID:2gnvm26gの主張って、エラー関係に文句言ってる奴に「別にthrow-catchでもそんなに困らなくね？」って言ってるの？
俺には二人ともが「Javaの検査例外は失敗だった」と主張しているように読める……
>>868 その上で例外廃止を是とするか、「ちゃんとしてれば「手に負えない例外」なんてない」って夢物語を語ってるかが違うと思う。
なんとなく手抜きっぽいからじゃなくて、本気で手抜きだと思ってんだよなぁ。
なんかどっちでも大して変わらんというか、
まあthrows Exceptionやるような奴なら、戻り値によるエラー処理を強制したとしても
丁寧に作ると、大域ジャンプなんかそうそう使わん。
>>872 それでも、どこか遙か上でcatchしてることを期待してthrowされるより、直上がエラーを見てる事が保証できてるほうがマシかと。
握りつぶすのは論外として。
Javaは継承はあるがジェネリクスがない時代の遺物
Javaの検査例外が失敗したのは
ところで検査例外って「失敗」したの？たしかにJava以降採用する言語はないけどさ。
検査例外は多態との相性が最悪なんだよ
>>877 この関数は引数として渡されたクロージャと同じ種類の例外を投げますよ記法があれば良さそうに思うけどな
やることは多相型の推論と同じだろう
あー、Javaの場合はクロージャを独立したinterfaceとして型を付けないといけないんで無理だな
例外をGenericsパラメータにして大体同じような事は出来る。
動的型は平和でいいよな
>>872 明示的に無視するように書いてる場合は議論から除いたほうがよくない？
>>883 世間一般ではあれをキモカワイイと呼ぶ……はずだ…
>>882 複数で開発してる時とか、誰かがやっちまってて、頭抱えることになったりするから、無視しやすいのはギルティだと思うけどね。
>>886 Roslyn「あたしより？(ﾉД`)」
>>887 言語が用意した安全機構を無理矢理回避して握りつぶすことまでは言語側の責任ではないだろうとは思う
とはいえ、安全機構が不十分であるのならそれは言語側の責任だろうと思う
そしてgoの安全機構は不十分だと思う
ねぇ、まだ例外の話するの？そろそろ飽きたんですけど…
>>887 無視しやすいとは書いてねーだろ。
無視しずらくしてるのを明示的に無視するコード書くケースは議論から外すべきといってるだけ。
盲目的にエラーを無視するコード書く人間のことまで議論に含めたらきりないじゃん。
コトリンなんか使ってる間抜けはandroid屋さんくらいかね
>>896 どういう感性してんだおめえクロマニョン人か？
コトリンなんか使ってる間抜けはandroid屋さんと君くらいかね
googleもなんでkotlinとdartってかぶってることやってるの？
googleは別にことりんは作っておらんで。
こういうスレで、特定の言語をディスるやつは、その言語を使えない（理解できないとか、組織の都合とかいろいろあるだろうけど）やつの呪詛だと思うことにしている。
呪詛に反対するならポリコレを推進すればいい
こういうスレで、特定の言語をマンセーやつは、その他の言語を使えない（理解できないとか、組織の都合とかいろいろあるだろうけど）やつの呪詛だと思うことにしている。
一つの言語しか使えないやつは、こんなスレにこないと思うけどな。
>>904 取り敢えず、お前が悔しいと感じていることは理解した。
ある程度の文法が分かる言語はいくつもあるがエコシステムを十分に使いこなせる言語は少ない
例えばMalbolgeは言語として破綻してるけど、これをdisったら「使えない奴の妬み」になるのか？違うだろ？
ポリコレの人なら差別感情が原因だというし
なんでも性欲に還元しちゃうのはフロイト先生じゃなかったっけ
元型論とか実用主義とか構造主義とかはプログラミング言語の批評や比較にも丸っと適用できるな…
>>910 普通にレスに参加してると味方も現れたり、割と建設的な会話になるんだが、
名前欄に「あ」と入れるだけで俺が悪くなる不思議な現象もあるんだし、
誰が言ったかもかなり大事だろうね。いろんな意味で。
いま適当に調べたらニーチェとフロイトは大陸哲学の先駆者とされる
【悲報】自己顕示欲の塊「あ」さん、こんな会話でも自分の話に持ち込んでしまう
だいぶ長いこと普通に会話してたからな。
大陸哲学もプログラミングに関係あると思うけどなあ
クイックソートの各言語での実装はクイックソートのイデアの写像なのだ (プラトン主義)
プログラム言語での英米系と大陸系
繰り返している記憶を思い出せないゆえに歴史は繰り返す
>>926 まあ結局なんでこんなにたくさんの言語があるのかってのが答えだと思うな
で、どっちが優れてるかってのはどちらがより後世まで生き残るかで決めるしかないんじゃないかな
まあ時代、時代で必要な技術ってのは変わるからそれで一応の結論が出せるって話でしかないけど
いまどき「語り」に罪悪感を覚える人間がどこにいるんだよ
先月Dart2が出たと思ったらもう死んだのか・・・
Laravelの伸び方がやばい件
これPHP復権するんじゃね？
https://trends.google.co.jp/trends/explore?date=all& ;q=Ruby%20on%20Rails,Laravel,Rails
Dartほど誰にも望まれてない不憫な子も珍しい
ゴリ押すどころかGoogleが真っ先に見捨ててるだろ
>>939 こっちでどうぞ
【PHP】Laravel【フレームワーク】 [無断転載禁止]
http://2chb.net/r/php/1503683914/ 今さらゲリクソプェチピィでフルスタックとかガイジにもほどが
>>939 laravelってそんなに良いかな？
丁度railsのチュートリアルと合わせてlaravelも触ってるけど
railsの劣化コピー感があるんだけど。
この辺の感覚はここに書くには長すぎるからqiitaにでも書くけどさ
どの辺がどう良いか言えない時点で頭お察しのペチパーだろ
Rails自体を手放しで賞賛する訳じゃないが、
JavaScriptはブラウザを変えても動く
phpは知らん。rubyは発狂しそうになった。pythonやjavaもトラブったことある。
jsもサーバで動かそうとするとRubyやPythonの比じゃないくらい頭おかしくなるけどな
>>950 でかいと言ってもrubyなんかのライブラリ含んだ環境と比べてもでかいもんなのかなぁ？よくわからんけど。
nodeのほうがRubyやPythonよりまだマシだったぜ。こいつらの場合システムプリインストール版と戦わなくちゃならんもん。
nodeだってそのうちきっとsystemdあたりが使い出して
railsが最強なのはrailsチュートリアルという無料コンテンツが存在する点。
>>954 node は素人が普通に使っても衝突しにくいと思う
>>950 デカイのはstaticリンクされてるから。
びっくりするような「ただOSとしてlinuxが起動してるだけ、なんのライブラリも入れてない、コマンドもない、むしろシェルすらない」みたいな環境でも起動するんだから必要悪だと思うわ。
>>955 何も知らない素人を、なんとなく組めるけど考え方の骨子も知らずパフォーマンスなんか気にしない「Rails書き」に仕上げる、の間違いだろ。
Railsからruby始めたやつで、唸るようなコード見たこと無いぞ。
ruby大好きな人が書くコードは好きじゃないけど唸ることはある。
>>951 そんなこと言ってたら極論シェルすら使えなくなるだろ
GoのシングルバイナリのメリットはDockerがいらないという点だろ
唸るようなコードなんて見たくない。
唸るってのは難しくて唸るんじゃねえよ。
何でバカのお勉強に付き合わなきゃならんのだ。成りすましruby厨は巣に帰れ。美しいコードとやらでシコシコやってろ。
>>958 数週間前までプログラムを書いたことのない人のコードだぞ。許してやれよ。
スタートアップのコードは大体クソだと聞く。金を生むようになってからリファクタリングするためにあんたを雇ってくれるんだから雇い主になるんだぞ。もっと敬えw
>>958 つーかパフォーマンスが必要ならそもそもrailsつかうなや。
elixir使え
最強の無料コンテンツがあるのにどうやって金を生むのか不思議
>>963 rubyがそーいう書き方を是とするのが好かん。
なにがなりすましなんだよw
>>964 プログラマ気分で口開かなければ無視するよ。
往々にして、プログラマ気分で口開くようになるけど。
>>965 ところがrailsしかできない奴は無理矢理rails使うんだよなぁ。
PHPerよりもレベルが低いのに、マシだと思い込んでるバカばっかり。
Rails が基本になる理由は、
>>969 多分俺が10年で学んだこと。って言いたいことじゃないか？
大体紆余曲折を経て正解にたどり着く。
それぞれの年代によって開発トレンドも変わっていきその都度ふりまわされることもあり。
そうしてたどり着いた正解を
一冊のチュートリアルにまとめました。
>>969 俺もこれに感動した。他のフレームワークでwebアプリ書いてるやつもrailsチュートリアルを読んでほしい。
というか、railsチュートリアルパクって作れ。
言いたいことは色々あると思うがNGして我慢しましょう
>>972 他のフレームワークもrailsチュートリアルをベースにチュートリアルを作るべき。と言いたかった
総合力とやらしか無い開発者ってのは居て、そして、それで良いと思ってる。ここまでは許そう。
Linux 資格のLPIC とか、環境構築・シェルスクリプトとか、
>>975 過去の言語って何？
そもそも次世代言語の指すものも明確になってないんだから、ぶっちゃけただの井戸端会議でしかない。したがって資格の有無もない。
仮に次世代言語があるとするならそれは初期状態からLSPを揃えた言語であるべきだろうな。最初からIDE連携がしっかり取れてリファクタリングも容易。これは必須事項だろう。
>>978 LSPって何？
「リスコフの置換原則」のこと？
>>979 language server protocol
>>980 ああ、MSのアレね。どうも
>>978 そういう機能も重要だとは思うけど、もちろん一番重要なのは言語設計でしょ？
IDEの機能がいくら優秀だったとしても言語設計がクソなら意味はない。
逆に言語設計さえ良ければそういう機能は自然と後からついてくるのでは？
>>976 情報系の大学に行けば在学中の4年で全て出来る
俺は卒業前にはLPICレベル2も応用情報も持っていたし、Webならインフラから開発まで全て出来た
>>977 過去の言語って何？ってのは、適宜引用するときにその特徴含め、何と何を比較してるかを述べれば充分でしょ。
井戸端会議する為のベースラインが無いなら、井戸端のおかーさんにひっついてきてる子供みたいなもんだ。
資格の有無は言ってない。意味が無いと言ってる。
「○○」は素晴らしかった、だから「○○」を「□□」で焼き直せ、って論調に
「ならやっとけ。と言うよりそれしか理解できねえから○○がベストだと思ってて、
何でも○○で解決しようとして、新しいパラダイムなんか理解する気ねえだろ」
って言ってるだけ。
>>976 濃いし、人によっては時間がかかるのも事実かもしれんが、
しょーもない、と言い切るのもおかしいし、ただの勉強でもない。
Railsしか知らないから、Railsは実際に動かせるから楽しいとかぬかすんだろ。
ほとんどRails弁みたいなruby使ってタノシーって覚えて、Rails訛りのrubyしか使えない奴になるのが関の山。
よほど変なハードを要求するものでもなけりゃ、何でも実際に動かせるわw
何もCで書けとまで言ってる訳でなく、perlで生socket使ってhttpサーバ書いた方がよほど応用が効く知識つくんじゃねえの？って話。
今時perlは極端だけどな。
は？おまえのかいたコード唸らねえの？
デバッグは自分との戦い
しかし、ホントにたとえ自分の嫌いな言語でも関わらないと仕方ない事とか、
ソースコードの読み方にはコツがある
インストールできないとか実行したくないとか
>>985 後半の話はperlよりもgoがおすすめ。
>>995 俺がGo推しだから、あまりに恣意的過ぎると思って。
俺もそう思う。
タノシーって覚えることのなにがいけないのかわからん
>>992 データ構造を把握するのが第一だな
その次に大まかな流れを観る
詳細は最後
このスレへの固定リンク： http://5chb.net/r/tech/1520298555/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「次世代言語9[Haskell Rust Kotlin TypeScript Dart] YouTube動画>3本 ->画像>1枚 」 を見た人も見ています：・次世代言語29 TypeScript Swift Go Kotlin Rust Nim 次世代言語10[Rust Swift TypeScript Dart] 次世代言語議論スレ[Go Rust Scala Haskell]第5世代 次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 [無断転載禁止] 【AI】DeepL、「次世代言語モデル」を実装--翻訳品質で「GPT-4」上回る [すらいむ★] 自称次世代言語議論スレ[PHP PHP PHP] Polygon「PS5の次世代機用アップデートは面倒すぎる。XboxのSmart Deliveryは超優秀」 Apple m1で盛り上がってるところ悪いがArm終了、Risc-vが次世代の覇権になること決定 【WhiskeyLake】次世代ﾓﾊﾞｲﾙCPU雑談ｽﾚ13【IceLake】 Sony Mobile 次世代Xperia 総合191 Sony Mobile 次世代Xperia 総合176 Sony Mobile 次世代Xperia 総合218 Sony Mobile 次世代Xperia 総合180 Sony Mobile 次世代Xperia 総合210 Sony Mobile 次世代Xperia 総合185 12月30日「AYAKARNIVAL2019」(パシフィコ横浜国立大ホール)にSKE48次世代ユニット「カミングフレーバー」が出演決定！ Sony Mobile 次世代Xperia 総合256 Sony Mobile 次世代Xperia 総合258 【Type-C】USBの次世代仕様「USB4」が発表。Thunderbolt 3ベースで最大転送速度は40Gbpsに 【Nexusから】次世代Google端末を語るスレ Part15【Pixelへ】 OpenAIがついに人類を終わらせるGPT-4の次世代を木曜日にリリース！、、「博士号級の知能」とのこと。。。通称プロジェクト🍓 PS5独占「Astro's Playroom」驚異の次世代グラフィックを僅かロード10秒で実 Part2 【速報】次世代Xbox「Scarlett」はZen2、Navi、GDDR7、カスタムSSDで最高品質の次世代ゲーム機に★3 【速報】次世代Xbox「Scarlett」はZen2、Navi、GDDR6、カスタムSSDで最高品質の次世代ゲーム機に★5 【速報】次世代Xbox「Scarlett」はZen2、Navi、GDDR7、カスタムSSDで最高品質の次世代ゲーム機に★2 【ゲーム】Microsoft，次世代ゲーム機「Project Scarlett」を2020年のホリデーシーズンにリリース 【悲報】TS抜き終了のお知らせ。次世代4K地デジ規格がARIBで承認、改良型A-CAS採用へ。NHKには悲報だがスクランブルにもついに対応 【PS5Pro(Trinity)】次世代機予想スレ 106世代目 【PS6】 次世代の女性研究者を支援する「Sony Women in Technology Award with Nature」 最終候補者7名決定 [すらいむ★] 次世代iPhone Part265 次世代iPhone Part269 次世代iPhone Part271 次世代iPhone Part267 次世代iPhone Part262 次世代iPhone Part264 Intelの次世代技術について語ろう 96 Intelの次世代技術について語ろう 93 Intelの次世代技術について語ろう 86 Intelの次世代技術について語ろう 94 Intelの次世代技術について語ろう 97 AMDの次世代プロセッサを応援しよう part3 【悲報】 次世代のMacはARMチップを採用か 【鉄道】宇都宮ＬＲＴ（次世代型路面電車）の車両デザインが決定 "雷の光"を表現 【IT】スカパー、LINE、伊藤忠 次世代型テレビ商用化へ 【企業】韓国サムスン、次世代有機ELに1.2兆円投資 【ガラホ】次世代フィーチャーフォン総合 Part18 【ガラホ】次世代フィーチャーフォン総合 Part16 【独占公開】次世代機PlayStation5のグラフィックを予想！ 次世代セレクトショップ STUDIOUS ステュディオス10 【速報】Huaweiの次世代スマホ｢Mate 20 Lite｣画像ｷﾀ━━━━(ﾟ∀ﾟ)━━━━！！ 【ガラホ】次世代フィーチャーフォン総合 Part15 【ガラホ】次世代フィーチャーフォン総合 Part13 【燕の次世代エース】原樹理 part8【目指せハーラートップ】 【車】ホンダ、AIを持つ次世代スポーツEV「Sports EV Concept」東京モーターショー2017で世界初公開 任天堂の次世代ゲーム機 Nintendo Smart、「すでに量産開始されている」とWSJが報道 有機ELさえ置き去りにする次世代液晶 パナソニックがメガコントラスト液晶の詳細を発表 天然歯の生理機能を有する『次世代型口腔インプラント治療』の実証に成功 Part3 関数型プログラミング言語Haskell Part31 Dart これ以上変な言語を増やすんじゃねえ！ Kotlin 【IT】攻守最強のプログラミング言語って「TypeScript」で良いのか？ 次世代iPhone Part230 次世代iPhone Part244 次世代iPhone Part203 次世代iPhone Part239 次世代iPhone Part231 【SKE若手メンの叫び】「SKEも次世代コンサートしたい😵😵！」
03:11:58 up 63 days, 4:10, 0 users, load average: 8.14, 8.64, 9.13
in 1.8695781230927 sec
@1.8695781230927@0b7 on 061916
ブックマークへ