次世代言語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/21(水) 07:05:06.97

Linusがカーネル周りの人間って事を忘れてはいけない
その前提とシステムプログラムの観点からCが選択されたのであるし、更にその発言が結構前であることも意識しなきゃ

**デフォルトの名無しさん** · 2018/03/21(水) 07:14:44.19

KHTMLはIEと同じ表示ができたので気に入っていた。
それが今やEdgeがWebkit互換表示だもんな。

**デフォルトの名無しさん** · 2018/03/21(水) 07:16:02.63

ただなあ、Javascriptの邪悪さには誰も勝てないと思う。

**デフォルトの名無しさん** · 2018/03/21(水) 08:26:35.73

>>522もムーブセマンティクスが流行った時は飛びついたくせにー
古くはPascalのconst引数、新しくはswiftのinoutみたいにコピーと参照が曖昧なのもあるし
明確に区別したままでももっといい推論方法だってできるかもしれない

**デフォルトの名無しさん** · 2018/03/21(水) 09:47:49.88

早すぎる一般化は諸悪の根源なんやで
まずCで書き、そのあと他の言語に移植しなさい

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

早すぎる最適化や過剰な一般化ならともかく、一般化が早すぎて困ることなんてそうあるかねぇ？

**デフォルトの名無しさん** · 2018/03/21(水) 11:33:24.48

むしろ早すぎる具体化詳細化のほうが害悪だな。

**デフォルトの名無しさん** · 2018/03/21(水) 11:52:04.49

Linusは何も間違ってないし、むしろ高級言語使う側が「楽だから」と目を閉じてるのが問題だと思うけど。
ちゃんとどんな機械語になるか把握して、どれぐらいのオーバーヘッドがあって、それはこういう基準やメリットで許容してるから、俺はxxx言語を使う、って言い切れないのが問題じゃない？

**デフォルトの名無しさん** · 2018/03/21(水) 12:06:23.78

90年代まではそれで正解だったけど、今の時点で「コンパイラが吐く機械語が予測しやすい」のは欠点でしかないし、実際Cコンパイラもかなりの最適化をするわな。

**デフォルトの名無しさん** · 2018/03/21(水) 12:17:48.32

最適化は想定してコンパイルするだろ。Cなら特に。書き方にも関わるし、コンパイルオプションにもかかわるし。

予測しやすいか、しにくいかなんて問題にしてなくて、予測じゃなくて把握しろって思うんだって。
コンパイル結果みて考えても良いぐらい。

「とりあえず楽」じゃなくてさ。
そういう意味では、Goみたいに-gcflags -Sで簡単にアセンブリコード見れるのは良いと思うし、流行りの高級言語にもあって然るべきだと思うんだが。
要らない、全部コンパイラが楽させてくれる、って言うやつはRustをディスる事も、Cを称賛する事も中途半端だと思う。

**デフォルトの名無しさん** · 2018/03/21(水) 12:19:27.12

そろそろ人知を超えた最適化を行うAIコンパイラとか出てきても良さそうだけどね
抽象度の高い言語の方が最適化の余地が広くて有利になったりして

**デフォルトの名無しさん** · 2018/03/21(水) 13:16:11.38

別の方に着目したいから楽ちん高級言語を使っているのに
それを目を閉じると表現するのはいかがなものか

**デフォルトの名無しさん** · 2018/03/21(水) 13:25:57.59

>>535
いくらでもあるだろ。
めちゃくちゃデラックスなプリント文とかな。

**デフォルトの名無しさん** · 2018/03/21(水) 14:07:57.78

実はお前らが内心で求めてるのは次世代言語じゃなくて前世代言語じゃね？

**デフォルトの名無しさん** · 2018/03/21(水) 14:13:44.60

コピーと参照の違いは代入すればわかる
だから代入を禁止すればコピーと参照の違いを捨象できる
抽象化とはつまり具体的な何かを禁止することだ
禁止されている自覚がないなら、目を閉じていると批判されても仕方ない

**デフォルトの名無しさん** · 2018/03/21(水) 14:19:34.98

>>500
こんなのあったんか。まだ開発序盤か

**デフォルトの名無しさん** · 2018/03/21(水) 14:53:44.91

別の方を着目したからと言って「見ないことにしている」を「見なくていいから楽」と取るのは間違ってるだろ。

**デフォルトの名無しさん** · 2018/03/21(水) 15:05:39.36

ケースバイケースだろ
・全てのケースで間違ってる
・全てのケースで正しい
これ以外の選択肢が見えなくなるのがおかしい

**デフォルトの名無しさん** · 2018/03/21(水) 15:08:02.21

Cはどのように最適化されるかわかるからそれを想像しながら書くことで
美しいコードがかけるんだよな。

**デフォルトの名無しさん** · 2018/03/21(水) 15:15:52.41

最適化は別にどうでもいい
人知を超えた最適化してもいいぞ
ただし人知を超えた仕様変更とか人知を超えたデバッグは困る

**デフォルトの名無しさん** · 2018/03/21(水) 15:19:26.15

ネットサーフィンでホームページみると汚い糞みたいなコードしかないからな。
俺くらいのプロになると美しいコードを書くだけで勝手に正解になっている。
コツは対称性を意識すること。対称性を持った完全な美に矛盾は存在する訳ないからな。

**デフォルトの名無しさん** · 2018/03/21(水) 15:28:41.94

boostは新言語と言って良いのではないか。

**デフォルトの名無しさん** · 2018/03/21(水) 15:35:40.07

boostは便利なものもあるけれどほとんどがゴミだよね

**デフォルトの名無しさん** · 2018/03/21(水) 15:36:59.68

いつの時代のCコンパイラの話だよw

◆QZaw55cn4c · 2018/03/21(水) 15:39:31.62

>>549
＞人知を超えたデバッグ
………

**デフォルトの名無しさん** · 2018/03/21(水) 15:52:31.99

>>552
テンプレート大好きな感じを何とかしてもらいたいよな。

**デフォルトの名無しさん** · 2018/03/21(水) 16:26:40.62

ストリーム廃止運動が必要。

**デフォルトの名無しさん** · 2018/03/21(水) 18:32:27.05

boost もjavascriptのBrowserifyみたいなツールで必要なモジュール部分だけ取り出して
コンパイルを速くできる機能ってないのかね？
それとも依存が激しくて結局全部マルごとになっちまうってことなんかな。

**デフォルトの名無しさん** · 2018/03/21(水) 18:33:29.63

boostがC++標準委員会のケツ蹴飛ばしたおかげでだいぶ今のC++良くなったじゃん

**デフォルトの名無しさん** · 2018/03/21(水) 18:37:44.59

>>557
boostを・・・というより使う側で配慮すれば分割コンパイルの恩恵にあずかれる。

**デフォルトの名無しさん** · 2018/03/21(水) 19:30:11.24

>>557
なってるんだが…

**デフォルトの名無しさん** · 2018/03/21(水) 21:34:18.38

>>500
PLASMA言語っすか…これは初めて知ったわ
今パッと見ただけだけど、なんとなくHaskellに近い雰囲気を感じた
どこら辺が違うのが詳しく説明してくれない？

**デフォルトの名無しさん** · 2018/03/21(水) 22:01:31.33

すべてプラズマで説明できそう

**デフォルトの名無しさん** · 2018/03/21(水) 22:52:30.65

ではboostをプラズマで説明してもらおうか。

**デフォルトの名無しさん** · 2018/03/22(木) 00:28:48.05

>>560
いや、二、三個の関数使うだけであのビルド時間はおかしいぞ。

**デフォルトの名無しさん** · 2018/03/22(木) 01:22:53.45

使い方を知らんってことか。

**デフォルトの名無しさん** · 2018/03/23(金) 21:30:21.55

atCoder今日から始めてみたんだけどc++が圧倒的に多い。
GoとかRustは少数派みたい。c++いいんかそんなに。

**デフォルトの名無しさん** · 2018/03/23(金) 21:32:50.91

>>566
＞c++いいんかそんなに
>>495

**デフォルトの名無しさん** · 2018/03/23(金) 23:22:27.41

混とんとしたウェブの状況を見ればウェブ屋さんが薦める言語なんて使えない。
ウェブ屋さんは昔から頭がおかしい。
落ちまくるネットスケープを推奨してたような人たちだぞ。
IEと互換性があるからKHTMLはダメだとも言っていた。
ウェブ屋さんが一番ネットスケープに苦しめられていたというのに。
つまり彼らはマゾなのだ。

**デフォルトの名無しさん** · 2018/03/23(金) 23:30:09.64

本来ネットワーク上で流通するものはすべて決定性を持つアルゴリズムで解析できなければならないだろう。
言語でいえばJava、データ形式でいえばXMLがそういったものだ。
実はW3Cはそういった方向にウェブを進めようとしていた。
これに反対したのがグーグルやアップルだ。
この反対する姿勢は純粋に政治的なもので技術の上に成り立つものではない。
もしもム板で議論されたなら技術が勝利したであろう。
しかし議論の場はム板ではなかった。
世界中の優秀なウェブ屋さんが集まったとはいえウェブ屋さんはしょせんウェブ屋さんなのである。

**デフォルトの名無しさん** · 2018/03/23(金) 23:36:00.72

OWASPの資料を見てほしい。
なぜウェブが危険なのかわかるだろう。
つまりほとんどすべてウェブ屋さん自身が持ち込んだ危険である。

**デフォルトの名無しさん** · 2018/03/24(土) 06:31:03.15

混とんとしたカーネルの状況を見ればOS屋さんが薦める言語なんて使えない。
OS屋さんは昔から頭がおかしい。
落ちまくるBSDを推奨してたような人たちだぞ。
DOSと互換性があるからWindowsはダメだとも言っていた。
OS屋さんが一番MS系に苦しめられていたというのに。
つまり彼らはマゾなのだ。

**デフォルトの名無しさん** · 2018/03/24(土) 06:34:45.58

本来OS上で機能するものはすべてPOSIXに準拠しなければならないだろう。
言語でいえばC、データ転送でいえばファイルがそういったものだ。
実はPOSIXはそういった方向にOSを進めようとしていた。
これに反対したのがMSやアップルだ。
この反対する姿勢は純粋に政治的なもので技術の上に成り立つものではない。
もしもム板で議論されたなら技術が勝利したであろう。
しかし議論の場はム板ではなかった。
世界中の優秀なOS屋さんが集まったとはいえOS屋さんはしょせんOS屋さんなのである。

**デフォルトの名無しさん** · 2018/03/24(土) 07:42:28.38

>>572
決定性を持たなければならないのはsecurity reasonであって標準とは無関係だぞ。
ウェブ屋さんは昔の論文を読み漁るべきだろうな。
セキュリティに最も関心を持つべき職業なんだから。

**デフォルトの名無しさん** · 2018/03/24(土) 07:46:59.67

世界を再構成する、Re Designを提唱する。

**デフォルトの名無しさん** · 2018/03/24(土) 07:48:27.16

すべて文脈自由文法でなければならない
これに反対したのがPerl正規表現やCプリプロセッサだ
この反対する姿勢は純粋にGNU/Linux的なものでグーグル/アップルではない

**デフォルトの名無しさん** · 2018/03/24(土) 08:41:54.13

>>575
ハイ、ダウト。

**デフォルトの名無しさん** · 2018/03/24(土) 11:43:16.47

インターネットはウェブ屋さんだけのもんじゃないからね
素人が適当に作れるのは大事なんだよ
確かに苦労は絶えないけど

**デフォルトの名無しさん** · 2018/03/24(土) 11:45:42.94

>>577
HTML一つとっても素人が気軽に書ける時代じゃないだろう。
なぜそうなったかわかるかい？
本来別のレイヤーにあるべきものをHTMLは一つ人類みな友達とかわけわからないこと言って一緒くたにしたからだよ。

**デフォルトの名無しさん** · 2018/03/24(土) 11:54:04.10

html5-tidyでCustom elementのサポートについて議論があって、いろいろ考えさせられる。

**デフォルトの名無しさん** · 2018/03/24(土) 11:57:19.01

政治的というのは「人類みな友達」のことじゃないだろう
平気で嘘をついたり、間違いを絶対認めないことを政治的というんだ

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

OS/2 WARPの資料を見てほしい。
なぜpreemptive context switchingが危険なのかわかるだろう。
つまりほとんどすべてOS屋さん自身が持ち込んだ危険である。

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

まあセキュリティー商売なんてのは危険を煽らないと成り立たないからな。

**デフォルトの名無しさん** · 2018/03/24(土) 18:52:42.30

>>578
いやあ未だに適当に書いてるよ
プロだってほとんど適当だよ

**デフォルトの名無しさん** · 2018/03/24(土) 19:47:17.53

HTMLは俺もクソ適当に書いてるわ
あんなもん書捨てで動きゃいい
divじゃなくてarticleタグ使えだのcssのセレクタにdata属性使うのはやめろだのと
くだらない拘りでコードレビュー通さない意識高い系フロントエンダーはマジで害悪だわ
HTML/CSSにおけるデザインと論理構造の分離なるものが現実に何かの役に立ったのなんて見たことない

**デフォルトの名無しさん** · 2018/03/24(土) 19:58:25.59

HTMLはタグの数を極力減らして
XSLT使って独自タグを定義する方向に向かえば良かったと思う

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

>>585
向かってるだろ

**デフォルトの名無しさん** · 2018/03/24(土) 20:28:12.89

reactとか？
cssが未だによくわかんねえ。あれわかる人なんなので。

**デフォルトの名無しさん** · 2018/03/24(土) 20:58:55.04

ReactでSSR、サーバーサイドでレンダリングした結果をクライアントで引き継げて凄すぎ！
みたいなのは、努力の方向性が間違っているような気がする。
SSRの必要があるってことは、結局SPAである必要が無いような。

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

画面の大きさがPCとスマホで全然違うからデザインが違う
せめて論理構造だけは同じにするべきだが
まさかPCと同じ情報を見ることができない実質ガラケーのようなスマホはないよな

**デフォルトの名無しさん** · 2018/03/24(土) 21:34:42.30

>>584
HTMLとして見ればその通りなんだろうけど、XMLで作ったデータフォーマットからウェブも含めた何かを作ってるような人たちには許容できない部分なのかもしれん。
PageMakerで組版してる人たちとか。
同じブロック要素でも、naviとarticleは文字詰めの方法が違うとか、そういう部分で、何でもdiv+classにすんなと言うのは充分わかる。

**デフォルトの名無しさん** · 2018/03/24(土) 21:37:02.47

>>584
書き捨てで誰もメンテしないならそれでいいだろうな
そんなのレビューしなくていいと思うけど

**デフォルトの名無しさん** · 2018/03/24(土) 21:42:42.38

考えるのに紙は依然として役に立つけど、読むのには紙である必要がなくなってきたな。
高性能なタブレットが重すぎるのを何とか出来れば完全に紙を駆逐できるんじゃないか。

**デフォルトの名無しさん** · 2018/03/24(土) 21:42:47.26

PageMakerじゃないな。普通に名前間違えた。FrameMakerとか。

**デフォルトの名無しさん** · 2018/03/24(土) 21:45:34.89

Googleが出すOSSは尻切れトンボが多いな。

**デフォルトの名無しさん** · 2018/03/24(土) 21:49:22.28

>>592
電池が要らない、
濡れても乾かせば大丈夫、
乱雑に投げられる、車に轢かれても壊れない、
複写を他人にページ単位で簡単に渡せる、
そのへんの筆記具で好きに書き込みが出来る、
氷点下20度でも使える、
破れてもセロテープで取り急ぎ直る、
完全に読めなくなっても比較的安価に買い直せる

このあたりが紙の冊子が電子媒体で駆逐できない所だと思うよ。
特に取説とか。

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

太陽光発電でもつけておけ。

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

「QRコードを印刷する紙がないぞ」「あんなの飾りです」

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

Gumbo parserってどうなんだよ。

**デフォルトの名無しさん** · 2018/03/24(土) 23:58:13.59

手触りで大体のページを把握するってインターフェイスに慣れ過ぎてるから
それを超えるまではまだまだ電子ペーパーは人類には早い

**デフォルトの名無しさん** · 2018/03/25(日) 00:06:04.48

なんの話だよ
OCamlの話いいっすか？

**デフォルトの名無しさん** · 2018/03/25(日) 00:16:01.86

民主党→民進党のように名前をちょっと変えると爆発的に売れる場合もあるからな。

**デフォルトの名無しさん** · 2018/03/25(日) 00:18:17.39

>>591
保守性という観点で言えば、DRYさえ死守してれば後は些細な問題だと思うよ
HTMLに限った話じゃないけど

**デフォルトの名無しさん** · 2018/03/25(日) 00:30:12.26

htmlでdryを守とかそれが無理だっつーの

**デフォルトの名無しさん** · 2018/03/25(日) 00:41:53.53

OCamlに話すことあるか？

**デフォルトの名無しさん** · 2018/03/25(日) 00:55:24.67

>>594
収益に直結してないものはやりたい人がいなくなったらそれまでだからな

**デフォルトの名無しさん** · 2018/03/25(日) 01:20:58.23

>>602
全部グローバル変数で名前規則さえ死守してればいいとでも言うのか？

**デフォルトの名無しさん** · 2018/03/25(日) 07:18:41.27

>>604
Haskellと重複する部分についてDRYを死守する方法を話して

**デフォルトの名無しさん** · 2018/03/25(日) 08:01:39.02

http://www.stroustrup.com/JSF-AV-rules.pdf
ロッキード・マーティン F-35 Strike Fighter Air Vehicle 開発のためのC++コーディング・ガイドライン。
※URLでお分かりの通り禿が関わっています。

**デフォルトの名無しさん** · 2018/03/25(日) 14:46:57.32

>>601
立憲民主党と勘違いしてない？

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

関数があるのにDRYに苦労する状況が分からん

**デフォルトの名無しさん** · 2018/03/25(日) 19:01:20.02

政治の話はNGで

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

プログラム技術という観点では政治も経済も経営もNG

**デフォルトの名無しさん** · 2018/03/25(日) 22:55:03.56

政治では名前が長くなり始めると危険領域だよな。
○○民主主義自由独立解放戦線的な。
朝鮮民主主義人民共和国とか欲張りすぎな国もあるし。
予言しておくけど立憲民主党は時代とともに名前が長くなるぞ。

**デフォルトの名無しさん** · 2018/03/25(日) 22:56:11.12

日本も大日本帝国時代は危険領域だったんだろな。

**デフォルトの名無しさん** · 2018/03/25(日) 22:57:49.97

Googleのコーディングガイドラインは名前はいくら長くなっても良い、省略された名前はダメと述べているからな。
罠かもしれんな。

**デフォルトの名無しさん** · 2018/03/26(月) 00:02:29.61

悩ましいぞな

**デフォルトの名無しさん** · 2018/03/26(月) 00:05:05.18

つまりこう

for (int indexOfItemInArrayOfProxyInformation = 0; ; ++i) {
auto proxyInformation = arrayOfProxyInformation[indexOfItemInArrayOfProxyInfomation];
...

みたいな

**デフォルトの名無しさん** · 2018/03/26(月) 00:08:00.38

ofを使ったら負け

**デフォルトの名無しさん** · 2018/03/26(月) 00:10:58.12

でもインデックス複数あったら？

**デフォルトの名無しさん** · 2018/03/26(月) 00:23:51.81

ストアドよりインデックスのほうが早いよ。

**デフォルトの名無しさん** · 2018/03/26(月) 00:32:41.52

何でも極端に走っちゃいかん。
バランスは大事よ。

**デフォルトの名無しさん** · 2018/03/26(月) 00:35:46.73

getInfo なんてのは Android の api でも見かけるし
information を info と略するのはありなんだろうな
普通の会話でもしばしばそう略すし

他にもなにか例外があるかとAndroid ndk api リファレンス眺めたら
名前がどれもこれも長くて驚いたわ…特にenum

**デフォルトの名無しさん** · 2018/03/26(月) 01:21:09.02

理由がわからない命令に従うから暴走するんだな
長くする理由を知ってたら必要な長さ以上にはならないし
理解できないものは反対したり批判したりする習慣があれば暴走しない

**デフォルトの名無しさん** · 2018/03/26(月) 01:28:05.88

例えを出しただけなのに「理由がわからないなら反対しろ！」と言われましても…

**デフォルトの名無しさん** · 2018/03/26(月) 01:45:15.94

馬鹿らし過ぎる。。
関数切り出してスコープ切ればいいだけの話だろうに。
今時の言語ならネームスペースだって使えるだろうし、エイリアシングみたいなものも
ある。
てかそれもなければなんの略かのコメントでも付けてろよ。

**デフォルトの名無しさん** · 2018/03/26(月) 01:59:38.91

>>624
反対しろとは言ってないぞ
しかし単語の組み合わせを少し改竄するとそういう意味になる可能性はあるのか

だから短い単語を組み合わせるのをやめて長い固有名詞を一個だけ書くのか

**デフォルトの名無しさん** · 2018/03/26(月) 02:02:12.66

goだとどいつもこいつもクッソ短いんだけどな
google内でも派閥があると見える

**デフォルトの名無しさん** · 2018/03/26(月) 02:05:44.31

>>626
哲学とかも不要な誤解や意図した曲解を避けるために用語をどんどん定義していくよね

今回で言えば「合目的的」であれ、とかか。
でも非常に長い名前は必ずしも判りにくくは無いんだよねああして書いてみると。
見難いのが問題なだけであって。

**デフォルトの名無しさん** · 2018/03/26(月) 03:07:46.44

名前が無いものに分かりやすい名前を付けようとするとどうしてもそのまんまの名前になっちゃうんだよな
aにbを足してcをかけた数に「aにbを足してcをかけた数」という名前を付けたり