次世代言語9[Haskell Rust Kotlin TypeScript Dart]

**デフォルトの名無しさん** · 2018/03/06(火) 10:09:15.60

スレタイ以外の言語もok

前スレ
次世代言語Part8[Haskell Rust Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1512137301/

**デフォルトの名無しさん** · 2018/03/10(土) 12:13:23.90

>>148
動的型のキャストと静的型のキャストに違いがあるとは思えないけどなぁ。
俺の考え方はこう。
動的型: 人間側で型の追跡を頑張る
静的型: コンバイラ側に型の追跡を任せる。ただしobject型とかに渡すことで人間側で頑張ることもできる。

動的型は基本雑なコードだらけ。人間側が型を決め打ちしてメソッドを実行しないとやってられない。
だって毎回instanceof とかで型をチェックしてからメソッドの実行とかしてないでしょ？

**デフォルトの名無しさん** · 2018/03/10(土) 12:16:33.64

>>152
説明されてわかるような奴が>>148を書くと思うか？

**デフォルトの名無しさん** · 2018/03/10(土) 12:24:33.09

>>150
そんなことないよ。例えばtoStringみたいな、親から生えてるメソッドは、objectのまま呼べて、しかもインスタンスのメソッドが呼べるでしょ。
goはそうはなってないの。インターフェイスをレシーバとする関数が呼ばれる。

内包してないよ。
ReaderはReadを
WriterはWriteを
ReaderWriterはReadとWriteを実装しているインターフェイスなだけ。別のインターフェイス。そこに上位下位は無い。

階層構造が暗黙に決まってるんではなくて、そもそも階層構造を持ってない。

**デフォルトの名無しさん** · 2018/03/10(土) 12:35:41.84

なんでもできる c++ で書くなら
なんのメンバーも持たない class interface の直接の
派生型として色んなインタフェースがあるようなもんか

COM に似てるな、というか COM のインタフェースの概念の焼き直しか。

**デフォルトの名無しさん** · 2018/03/10(土) 12:36:05.42

ダックタイピングとnominalな階層型の違いを言葉を変えて繰り返しているだけで
問題のinterface{}がobjectより良いという説明にはなってないな

**デフォルトの名無しさん** · 2018/03/10(土) 12:42:10.90

>>138
別に全部のコードにテスト書けとは思わんが
それでもそこまで引数の型がどうなのか気になるインターフェイスなら
テストコード書けよ。

てかそこまで作業が圧迫してるなら型をガッチガチにやる言語のが
調整する手間考えた場合割に合わんだろ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:01:42.42

>>157
どの程度なら「気になる」のかってところに認識の違いがありそうだな
静的型派の人間は全てコードの型情報が気になっちゃうんじゃない？
少なくとも俺は全ての引数の型が気になってしまうタイプの人間だよ

**デフォルトの名無しさん** · 2018/03/10(土) 13:02:25.28

>>152
動的型のコードは二種類に分けられる
静的型で丁寧に書いてから型を省略したようなコードと
静的型で雑に書いてから型を省略したようなコードだ

**デフォルトの名無しさん** · 2018/03/10(土) 13:10:46.65

「階層を持つから安全にキャストできる」と「安全にキャストできるから階層を持つ」がごっちゃになってる人がいる

**デフォルトの名無しさん** · 2018/03/10(土) 13:12:51.16

>>158
まあ極論すれば感覚的な話だしね。
感覚として型を気にして助かることなんて 5 % くらいじゃないかと思ってる。
対してテストがある場合は 40~50%くらい助かる。
準備するコストとして型が 10~20 としたらテストは 30~40 といった印象。

なんで個人的にはそこまで型を整備するよりかはテストに時間使った方がいいと考えてる。
まあ抽象論一発で済めば嬉しいって気持ちはわかるんだが
実際そうはならんからね。。

**デフォルトの名無しさん** · 2018/03/10(土) 13:17:24.66

>>156
端的に言えば、スーパークラス(と言う概念もないが)にキャストしてして渡してない、as-isで渡してると言うところが違うし大きい。
良いとも言ってないぞ。
違うし混同するなと言ってる。
Objectに相当するものが無いので、良いも何も比較対象ではない。

**デフォルトの名無しさん** · 2018/03/10(土) 13:21:00.62

スーパークラスにキャストねえ。
どの言語でもその場合は as-is で渡るだろう

**デフォルトの名無しさん** · 2018/03/10(土) 13:23:17.42

暗黙的にでも、ね。
Objectで受ける、Ienumerableで受けるを含めて。

**デフォルトの名無しさん** · 2018/03/10(土) 13:24:20.18

as-isで渡るは確かに語弊があったな。
別の型のオブジェクトやインターフェイスとして渡されてるんじゃなくて、って感じ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:27:51.68

>>162
>>125でobjectを雑と評したからには当然interface{}の方が良いという主張と思ってたんだが
実際の詳細は別にしてあなたの説明では聞けば聞くほど同じとしか思えない
俺じゃないが>>155なんかCOM的な構造で代替可能という理解をしてるし

**デフォルトの名無しさん** · 2018/03/10(土) 13:31:43.54

とはいえ言いたいことはわかる
オブジェクトに似ているがオブジェクトを渡しているわけではない、
オブジェクトとそれの持つインタフェースは1対多

COM のインタフェースや多重継承を用いた場合のC++に似ている
特に前者とはほぼ完全に同じものだ
インタフェース抽象って奴だね

この場合実行モデルとしてはインタフェースに階層関係は要らなくなる
複数のインタフェースを持つことから(派生による差分宣言、差分実装ではなく)
ミックスインが基本となるから。

**デフォルトの名無しさん** · 2018/03/10(土) 13:31:58.31

as-is型に実装を合わせるテンプレート
as-is実装に型を合わせるキャスト
これが次世代の争い
動的型は次世代ではないから政治的中立

**デフォルトの名無しさん** · 2018/03/10(土) 13:52:58.58

>>166
同じではないでしょ。
COM的な構造で代替可能ってのは、>>166自身は理解してるの？理解してたらそのレスにはならんと思うけど。
そもそもが思い込みで人の発言に「良い」を勝手に補完してなんでそんなにしつこく食いついてくるかわからん。
理解が足りなくて同じだとしか思えないなら開き直らないでほしいわ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:54:45.25

>>154
だから階層構造がないのはわかってるつーの。実際的な違いがないっていってるの。
実質Object型とinterface{} はおんなじ扱いにしかならない。
Object型にはtoStringがあるけどinterface{}にはない？別にそんなのはどうでもいい話。

interface{} に値を突っ込むと人間側が型を意識する必要がある。
動的言語的な扱いになっちゃう。

この点においてObject側と一緒だよね。

ここが最大の肝であり、「Object型でうけるのは雑」っていってるのはこの部分に差があると期待して質問したのに、
そこに関しては違いを見出していない。
なら雑な理由って何よ。

**デフォルトの名無しさん** · 2018/03/10(土) 13:55:30.73

今気が付いたが>>145の言ってることは根本的に間違ってる
>>130みたいなインターフェイスのレシーバはそもそもコンパイル通らない
つまりどの型にキャストしても同じレシーバが呼ばれることが保証されてる
そこがGoの型は階層を持たないという根拠になってたはず
エアプは黙ってろ

**デフォルトの名無しさん** · 2018/03/10(土) 13:57:07.23

>>169
IUnknownが便利に使われてるのと
QueryInterfaceの実装次第でメンバーに飛ばすこともできるのが似てるって話だろ
COMは実装側が応答する型(GUID)を決めないといけなくてダックタイピングにはならんから
俺は必ずしも似てるとは言わんけど、あなたの説明はそう思われてもしょうがないってことだ

**デフォルトの名無しさん** · 2018/03/10(土) 14:21:55.45

classの多重継承ができる言語ならinterfaceはclassの構文糖ということにできた
多重継承を制限したことでinterfaceとclassの互換性が非自明になった

**デフォルトの名無しさん** · 2018/03/10(土) 14:23:37.99

>>171
これは例が悪かったか。
スマホで書いたからすまん。

ある型にアサーションした場合、アサーション先の型のレシーバが呼ばれるよ。
もとのレシーバではない。

**デフォルトの名無しさん** · 2018/03/10(土) 14:26:15.83

>>170
おんなじ扱いをすれば同じになるだろうな。
扱い方の余地の問題なんだが。

人間側が型を意識する必要がある、この点に於いてObjectと同じと言うのは雑すぎる。
動的言語的扱い方と言うか、jsonのUnmarshalなんか見た方が多分わかりやすいと思う。俺が言ってることは。

**デフォルトの名無しさん** · 2018/03/10(土) 14:26:53.39

>>172
説明が悪いのは申し訳ない。

**デフォルトの名無しさん** · 2018/03/10(土) 14:31:49.68

interface{}で受ける関数を呼ぶときは、
とりあえず、スーパークラスのObjectに(暗黙的に)キャストして渡してるのではなくて、あるインターフェイスを実装している型として渡してる。
全クラスがIfooをimplementsしている状態で、Ifooを受けているだけ。
そこにキャストは発生してないし、だから、キャストではなくアサーションで型を判定するだけで(キャスト無しで)中身の型が分かる。
その時に、もとの構造体ではなく、あるインターフェイスとしてアサーションする事ももちろんできる。

そこだけでも伝わってほしい。

**デフォルトの名無しさん** · 2018/03/10(土) 14:33:10.73

しかし、また「エアプ」かw
好きなんだな、その言葉。

**デフォルトの名無しさん** · 2018/03/10(土) 14:47:03.22

キャストは雑
アサーションは丁寧
という説が伝わってきた

**デフォルトの名無しさん** · 2018/03/10(土) 14:56:06.20

>>175
それって結局reflectバッケージを見ろってこと？
>>177
型キャストが雑ってこと？
型アサーションだと型が合わないとerrorを返すから雑じゃないってこと？

**デフォルトの名無しさん** · 2018/03/10(土) 15:25:20.56

雑なほうがいいんだよ。that's rightって言うだろ？

**デフォルトの名無しさん** · 2018/03/10(土) 15:26:15.03

>>180
アサーションが丁寧というのは語弊があるが、インターフェイスからのアサーションはそもそも本来の型自体も持ってるのでキャストしているわけではなく、assert、言明し直してるだけで、別の型として一度も扱わない。

**デフォルトの名無しさん** · 2018/03/10(土) 15:28:33.49

>>174
アサーションでもレシーバが変わることはない
自分で試したことないから分からないんだろ
>>177のキャスト無しで渡してるってのも間違いで実際はキャストされてる
キャスト無しで渡してたらそれはジェネリクスだ
たぶん>>177はポインタや参照を理解してなくてキャストの意味をはき違えてる
objectにキャストしたら静的オブジェクトが動的オブジェクトに変換されると思い込んでるようにしか見えない

**デフォルトの名無しさん** · 2018/03/10(土) 15:39:34.50

>>183
あることあるから、レシーバが変わる事知ってるんだよ。
そうじゃない。履き違えてないよ。
ジェネリクスはもっとちがう。コンパイル時に関数自体が型ごとに分かれるのが俺が言うジェネリクスとオーバーロード。
オブジェクト指向脳でわけわからん事言わないで。

**デフォルトの名無しさん** · 2018/03/10(土) 15:56:33.06

>>184
が、言いたいことを整理すると
Go言語のinterface{}は他言語のObject型とは違う。
なぜならGo言語のinterface{}型は内部的には型情報を保持しており
reflectバッケージを使うことでいつでも元の型情報を取得できるから
ってことでOK?

これって逆に言うと他言語のObject型は内部的に元の型情報を保持しないの？

**デフォルトの名無しさん** · 2018/03/10(土) 16:04:38.45

本来のデータポインタはそのままで実行時型情報をペアにしてinterface{}(fat pointer)にしているのを
キャストしているしていない言い張ってるだけかな。まあ言葉はどっちでもいいが

ちなJavaタイプのnominalなinterfaceや多重継承はデータポインタに特定のオフセットを加減算する(ポインタの値が変わる)
場合がほとんどだが、fat pointer方式の実装も無いわけではない

**デフォルトの名無しさん** · 2018/03/10(土) 17:15:29.87

>>185
いや保持してるよ
RTTIってやつだね

**デフォルトの名無しさん** · 2018/03/10(土) 17:37:00.44

エアプ呼ばわりされて過剰反応するのが真のエアプ
エアプでないことを示すのが普通の人

**デフォルトの名無しさん** · 2018/03/10(土) 17:37:33.50

>>185
内部的に持ってるが、クラス構造が階層型であるが故にObject型という型で扱われた上で、サブクラスにダウンキャストするじゃん？で、またアップキャストするかもしれん。
だからジェネリクスやオーバーロードだと共変なのか反変なのか、あるいは非変なのかが問題になるし、Javaなんかはジェネリクスは非変だけど、配列は共変みたいな事になってるし、c#なんかだと最近変性注釈できるようになったり、まだゴタゴタしてる。

ちなみに、interfaceへのアサーションはreflectとは違って、interface自体が型を持ってるので、reflectで型を判定したりメソッド呼ぶのとは結構な差がある。
古いけどこのへんか。
https://research.swtch.com/interfaces

**デフォルトの名無しさん** · 2018/03/10(土) 17:38:52.17

>>188
エアプのプロは言うことが違うな。

**デフォルトの名無しさん** · 2018/03/10(土) 17:47:29.26

エアプなんか使ったって、レッテル貼るだけで議論ができないようにしか見えないんだからやめときなって

**デフォルトの名無しさん** · 2018/03/10(土) 17:49:06.20

それが楽しいんだろ、いつもその言葉使うところ見たら。

**デフォルトの名無しさん** · 2018/03/10(土) 17:59:38.11

>>189
>共変なのか反変
急に分かんない用語が出てきて混乱したが
http://www.thekingsmuseum.info/entry/2016/02/07/235454
が参考になった。非変って用語がないが不変の言い間違い？

**デフォルトの名無しさん** · 2018/03/10(土) 17:59:39.44

いや全く楽しくねーわ。

**デフォルトの名無しさん** · 2018/03/10(土) 18:20:49.51

例えば
func ToString(any interface{}) string {
if v, ok := any.(Stringer); ok {
return v.String()
}
switch v := any.(type) {
case int:
return strconv.Itoa(v)
case float:
return strconv.Ftoa(v, 'g', -1)
}
return "???"
}

上記コードはこうできるようにして欲しい

func ToString(any (Stringer | int | float)) string {
if v, ok := any.(Stringer); ok {
return v.String()
}
switch v := any.(type) {
case int:
return strconv.Itoa(v)
case float:
return strconv.Ftoa(v, 'g', -1)
}
}

引数にinterface{} があるのはやっぱりJavaとかで引数にObject型が来るのと同義だと思うわ。

**デフォルトの名無しさん** · 2018/03/10(土) 18:22:28.94

>>193
こっちのページの下のほうに書いてあるじゃん
http://www.thekingsmuseum.info/entry/2016/02/11/111718

**デフォルトの名無しさん** · 2018/03/10(土) 19:46:35.03

結局Objectの方がinterface{}より保証されてるものが多いから、雑なのはinterface{}の方じゃーん

**デフォルトの名無しさん** · 2018/03/10(土) 21:09:45.80

>>105
これ最高に型無しクソペチパー指向的レス

**デフォルトの名無しさん** · 2018/03/10(土) 22:06:56.73

>>197
保証されてるものが多いんじゃないよ。
保証されるべきでない関連性を持ってないものも、関連性を持っているかのごとく扱われるんだよ。

**デフォルトの名無しさん** · 2018/03/10(土) 22:10:01.27

自分が知らないものをたったひとつソースから「言い間違えなのか？」と言うのはどうかしてると思うわ。

**デフォルトの名無しさん** · 2018/03/10(土) 22:20:22.04

>>195
ToStringなんて関数をinterface{}で受けて中で適当に処理するってこと自体だと思う。
そんな事するぐらいなら、使いたいintとfloatを名前つけてちゃんと型定義して、Stringer実装するほうがまともでは？
ライブラリならまだわかるが、ユーザコードでinterface{}を使うのはもっと「interface{}でなければいけない時」であって、基本的にはなんでも受け取りたいから使うための型ではない。
普通のオブジェクト指向言語でもそうだろ。

後半のコード例に至ってはコンパイル時に検出したいだけだろ。
オーバーロードさせろってんならまだわかるが。
コンパイル後に消えるようなもの書いて喜ぶ事こそ馬鹿らしいわ。

**デフォルトの名無しさん** · 2018/03/10(土) 22:32:59.68

>>200
どっちかというとこれを見て思ったんだが
https://ja.wikipedia.org/wiki/%E5%85%B1%E5%A4%89%E6%80%A7%E3%81%A8%E5%8F%8D%E5%A4%89%E6%80%A7_(%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6)

**デフォルトの名無しさん** · 2018/03/10(土) 22:36:50.46

>>201
>後半のコード例に至ってはコンパイル時に検出したいだけだろ。
それこそキモだろ。静的言語を使う理由って。
これが嫌なら動的言語使ってなよPHPとか

**デフォルトの名無しさん** · 2018/03/10(土) 22:40:31.66

>>201
>ユーザコードでinterface{}を使うのはもっと「interface{}でなければいけない時」
現状のGoでそういう理由でinterface{}を使ってる状況ってどんだけあるんだよ。
それじゃすまないからジェネリクスを欲しがってるんでしょうが。

**デフォルトの名無しさん** · 2018/03/10(土) 23:44:31.64

>>202
ホントだな。これは俺が少数派らしい。
高飛車に言ってすまん。

**デフォルトの名無しさん** · 2018/03/10(土) 23:45:51.56

こいつ例のヤベェ奴か

**デフォルトの名無しさん** · 2018/03/10(土) 23:47:15.74

>>203
キモではないよね。
それは単なる横着のコンパイラへの責任転嫁であって。
void*みたいな無茶苦茶な型があるのも静的言語だが、別に型チェックしてほしくてコンパイルしてるわけじゃないぞ。

**デフォルトの名無しさん** · 2018/03/10(土) 23:49:44.45

>>204
結構あると思うけど。
それで済むから、頑なに「未だ早い」と本家が言い続けてるんでしょ。
済まないならもっと早く導入されてるわ。
そんなに変化ねえじゃんと思いがちだが、ホントに要るなって機能はちゃんと入ってきてるよ。ライブラリの出力しかり、ベンダリングしかり、次はモジュール予定されてたり。

**デフォルトの名無しさん** · 2018/03/10(土) 23:50:33.63

早くPHP歴4000年秘伝のソースにウンコを継ぎ足す作業に戻れよ
工数の無駄だぞ

**デフォルトの名無しさん** · 2018/03/10(土) 23:53:30.10

このスレ見てたら俺はC++とPythonでいいやって思えてくる

**デフォルトの名無しさん** · 2018/03/10(土) 23:57:26.44

こんなスレに影響されんなよ……
因みに俺はCとPythonとFortranとMathematicaでいいと思う

**デフォルトの名無しさん** · 2018/03/11(日) 00:04:08.68

非変、はScalaあたりから来てるのかな。記憶が曖昧。

**デフォルトの名無しさん** · 2018/03/11(日) 00:44:51.07

CとPythonの二刀流ずるい
C++むずい
だからJavaとかGoとかの支持率は下がらない

**デフォルトの名無しさん** · 2018/03/11(日) 00:52:28.92

>>207
あとCみたいな旧世代な言語を静的言語代表にされても。
あと横着はプログラマの美徳だよ。

>>208
現在進行形で議論中だよ。安易に入れたくないだけで必要性は明らかだろ。
https://github.com/golang/go/issues/15292
というか他のジェネリクスがある言語を使ってるとわかると思うんだけどな。このイライラ感。
まぁ関数のインターフェースにinterface{}型があっても気にしない人間もいるという事実があることは勉強になったわ。
そういう人間もいるんだ。

**デフォルトの名無しさん** · 2018/03/11(日) 00:57:35.32

>>199は自爆というかむしろダックタイピングの方だよね？

**デフォルトの名無しさん** · 2018/03/11(日) 01:05:04.16

反変共変とかすぐに数学用語を取り込んで違う意味にする

**デフォルトの名無しさん** · 2018/03/11(日) 01:18:09.18

>>214を斜め読みしたけど、既存のinterface{}なやつと互換を取るためJavaのgenerics同様にするか
それとは別に問題を捨て去るためD言語やMLみたいな名前空間単位のやつを入れるかで議論してるな
genericsなんて大物は後から入れてもJavaのようにしかならんとは思っていたが
(失礼ながら)goのような保守的な言語に今までのスタイルを捨てさせるような変更を入れられるのかは気になった

**デフォルトの名無しさん** · 2018/03/11(日) 01:37:42.02

>>217
GoBlogでGo2はGo1と下位互換性を保つと宣言してるから破壊的変更をせずに導入するだろうね。
どうやるか全く想像がつかない

**デフォルトの名無しさん** · 2018/03/11(日) 01:53:41.48

>>161
やっぱり認識の違いが激しいな。これじゃ話が合わんわけだわ
おれの感覚を書くと型情報を書くことで助かることは10~20%くらい
対してテストがある場合は50~60%(約3.5倍)くらい
準備するコストとして型が10~20ならテストは60~70(約4.25倍)の印象
さらに、後からコードを読むときの理解するまでにかかる時間が
静的型が10~20なら動的型は30~40(約2.25倍)の印象。

そして、俺の場合はコードは書くことより読むことの方が多いと思っているので
読むときにかかるコストの違いに良し悪しの重点を置く傾向がある。
というわけで、俺の感覚ではもちろん静的型に軍配が上がる

**デフォルトの名無しさん** · 2018/03/11(日) 01:54:27.55

これ以上は感覚のズレをお互いに調整しないと話が進まないだろうな
そして、その感覚のズレを調整をするつもりは俺にはないし
そっちも多分ないだろうからやはりこれ以上の話は無駄になるだろうな
認識の違いがこれだけもあるということが分かっただけでも良しとしておこう

**デフォルトの名無しさん** · 2018/03/11(日) 06:14:26.94

会社でkotlinの勢力が拡大して飲み込まれるのは目前
やだよぉやだよぉ

**デフォルトの名無しさん** · 2018/03/11(日) 07:33:15.20

javaが積極的に言語に手を入れるようになったから
kotlinがcoffeescriptと同じ運命を辿るんじゃ無いかと不安を感じる
androidから放り出されない限り生きていられるとは思うが……

**デフォルトの名無しさん** · 2018/03/11(日) 09:19:38.49

型システム入門では非変と訳されてるな

**デフォルトの名無しさん** · 2018/03/11(日) 09:44:46.83

Goに他の言語の機能を追加したいって声はよく聞くけど
逆に他の言語にGoの機能を追加したいって声はあまり聞かないよね

**デフォルトの名無しさん** · 2018/03/11(日) 10:05:15.85

var導入するのにval導入しないJavaのおじいさんたちはゲェジなのかな？

**デフォルトの名無しさん** · 2018/03/11(日) 10:21:31.83

COM「反射性、推移性、対称性」
次世代「恒等射、合成、共変、反変」

型アサーションと型変換の宗教論争の原因はこれか

**デフォルトの名無しさん** · 2018/03/11(日) 10:24:53.59

ｾｲｯ! ﾍｲｯ!

**デフォルトの名無しさん** · 2018/03/11(日) 10:31:59.14

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
･センサー

カメラと写真のアクセスでは､あなたのデバイスから画像メディアをインポートしてから､これらの画像をアプリケーションのス
プライトまたはテクスチャとして使用できます。

今すぐ無料でダウンロード！

**デフォルトの名無しさん** · 2018/03/11(日) 10:36:02.25

>>222
サーバーサイドだとC#/.NET Coreも浮上してきたしな
言語の筋が良かったから期待したけど、結局一過性の流行で終わりそう

**デフォルトの名無しさん** · 2018/03/11(日) 10:54:05.51

Kotlinは要するにBabelだろ
JavaがKotlin相当に進化する頃にはJava 1000くらいになってるだろ
それを実行できるAndroidはバージョン100000くらい
じゃあJava 6までダウンコンパイルできるKotlinだよねって話
でもReact Nativeに殺されるんだぜ、嘘みたいだろ？

**デフォルトの名無しさん** · 2018/03/11(日) 10:56:21.30

わかるか？バカども

**デフォルトの名無しさん** · 2018/03/11(日) 12:14:58.84

関数型が流行るようなことにはならない

**デフォルトの名無しさん** · 2018/03/11(日) 12:57:58.24

関数型言語Mathematica

**デフォルトの名無しさん** · 2018/03/11(日) 13:02:55.03

>>219
違いがあるのはいいが
コードの読みやすさで静的動的で比較もいいけど、
テストコードあるかないかで比較したものも載せて欲しい。
型があった方が読みやすいコードもたくさんあるのは事実だけど。

**デフォルトの名無しさん** · 2018/03/11(日) 13:13:29.16

コードリーディングという意味では型情報はありがたい。でも引数に何を入れればいいかLAPACKくらいしっかり書いてあるとなお良い
しかし関数名の直後にドキュメントが長々と書いてあってどこからコードなのかよくわからん奴は嫌い

**デフォルトの名無しさん** · 2018/03/11(日) 13:23:51.64

>>234
比較って言ってもこれは独断と偏見に満ちた個人的な印象値だぞ…
参考にして欲しくて書いたわけじゃなくて認識の違いを明らかにするために書いたものだし…
あと、静的動的どちらでもテストは書くんだからテストがない場合と比較することに何の意味が…？

**デフォルトの名無しさん** · 2018/03/11(日) 13:36:14.47

なるほど話が噛み合わないわけだ。
俺としては別に動的
本当にテスト書いてんのかなってとこのが重要だと思ってたわけだが、
動的か静的ってとこにそんなに興味があったんだね。

その部分に対してはどっちでもいいわ。
逆にテストするのしないのって話から話題をそらすための抗弁になりやすい印象が強いので
あんまり関わりたい議論ではない。

**デフォルトの名無しさん** · 2018/03/11(日) 13:42:53.78

状況が変わったのにまだ気付いてないんだな
だれも嘘をつかない性善説を前提に読みやすいとか読みにくいとか言う時代は終わった
今は嘘を教える人間を回避することが最重要
正直でありさえすれば読みやすさは不問

**デフォルトの名無しさん** · 2018/03/11(日) 13:58:30.20

最強の関数型言語Mathematica を崇めよ

**デフォルトの名無しさん** · 2018/03/11(日) 14:32:32.97

嘘うんぬん以前にガイジなせいでウンコードまみれなペチPoorさんはどうすればいいの？

**デフォルトの名無しさん** · 2018/03/11(日) 14:43:30.00

ここがphpスレですか

**デフォルトの名無しさん** · 2018/03/11(日) 15:03:28.52

https://github.com/collections/programming-languages

Crystalが落ちてる　Redおもしろそう

**デフォルトの名無しさん** · 2018/03/11(日) 15:04:09.58

嘘ねえ……そういえば昔知りもしない言語の嘘八百ばらまいてた人いたなあ

**デフォルトの名無しさん** · 2018/03/11(日) 15:05:01.09

Nuとか息してんの？

**デフォルトの名無しさん** · 2018/03/11(日) 15:09:53.59

>>242
クロスコンパイル楽すぎワロタｗｗｗｗ

**デフォルトの名無しさん** · 2018/03/11(日) 16:27:48.12

今も居るんだけどなw

**デフォルトの名無しさん** · 2018/03/11(日) 16:28:13.49

>>240
phpディスってる人も多いけど、タイプアノテーションついてだいぶ改善されつつあるんじゃないの。結局仕事にはphpも多いからlinterとか環境整備して開発しやすい状況は作っておきたい

**デフォルトの名無しさん** · 2018/03/11(日) 16:48:52.27

タイプアノテーションだのlinterだの、PHPerがいらねーって騒いでたものばっかりやん

**デフォルトの名無しさん** · 2018/03/11(日) 16:53:21.57

>>237
いまいち話が掴めないんだが、テストを書くのが面倒だからイヤって奴はクソって言いわけ？
俺はできればテストは書きたくないよ。面倒だし。でも書かないわけにはいかない
だったら、テストは書くがテストを書く量を減らしたい
動的型より静的型のほうがテストを書く量を減らせそう…と考えている。
実際に減らせるかどうかはデータを取ってみないと何とも言えないけど
少なくとも動的より静的のほうが減らせるという意見はあってもその逆はない
最低限のテストさえも書こうとしない奴は論外なのでそっちの話はしたくない

**デフォルトの名無しさん** · 2018/03/11(日) 16:54:04.68

静的型派の奴はテストは書きたくないって意見は俺以外にもいると思うけど
動的型派はテスト書くのは面倒だとは思わないの？
それを言うと、静的型派の連中は型を書くのは面倒だとは思わないのか？とか言われそうだが、
静的型派の奴らは型安全は保障してほしいとは思いつつ型を書くのが面倒だとも思ってるよ
だから型推論なんかを導入して型を書かずに済む方法を模索している

**デフォルトの名無しさん** · 2018/03/11(日) 16:58:13.27

>>250
動的型の連中の大半は現実にはテストなんか書いてないよw
常識的に考えて、たかが型書く程度のことを面倒臭がる奴がテストなんか書くと思うか？
全くもって机上の空論よ