次世代言語13 Go Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2018/08/20(月) 21:55:53.03

スレタイ以外の言語もok

前スレ
次世代言語12 Go Rust Swift Kotlin TypeScript
http://mevius.5ch.net/test/read.cgi/tech/1530664695/

**デフォルトの名無しさん** · 2018/08/30(木) 11:59:46.41

perlには '0 but true' という、数値として 0 と比較すると一致するが if でそのまま使うと true 扱いになる特殊な値があったりする。

**デフォルトの名無しさん** · 2018/08/30(木) 12:14:56.63

次世代を担うに相応しい真偽評価戦略を語るべし

**デフォルトの名無しさん** · 2018/08/30(木) 13:15:05.68

次世代はif文が消えjsのthen的なものになります

**デフォルトの名無しさん** · 2018/08/30(木) 13:47:18.38

うえー

**デフォルトの名無しさん** · 2018/08/30(木) 13:49:00.74

数値の偽は0
文字列の偽は "" "0"
オブジェクトの偽は null "" "0" その他
階層が深いほど偽が多い法則

**デフォルトの名無しさん** · 2018/08/30(木) 13:57:19.48

次世代言語にはifもforもない

**デフォルトの名無しさん** · 2018/08/30(木) 14:29:05.96

アスペはこういうところに拘ってしまって先に進めないんだよね

**デフォルトの名無しさん** · 2018/08/30(木) 14:47:28.76

飯炊き三年握り八年

**デフォルトの名無しさん** · 2018/08/30(木) 18:20:12.51

ちゃんと読んでないけど
boolなら
if checked / if !checked
でいいやん

**デフォルトの名無しさん** · 2018/08/30(木) 18:57:30.25

数値なりリストなりを暗黙に真偽値比較せずに
明確にすればいいだけじゃないの？

**デフォルトの名無しさん** · 2018/08/30(木) 19:30:44.87

直和な幽霊型でCheck|Uncheckを型に持たせて管理すればいいよ

**デフォルトの名無しさん** · 2018/08/30(木) 21:15:21.94

if で boolean 型以外を許さず、更に boolen 型の値の比較も許さない言語を作れば解決。

**デフォルトの名無しさん** · 2018/08/30(木) 21:51:23.27

というかそれが普通なんだけどな。
型がないB言語の特徴を受け継いだCがなまじヒットしてしまったせいで
後続の言語もその悪習を真似るようになってしまった。

**デフォルトの名無しさん** · 2018/08/30(木) 22:07:01.18

こんなしょうもないことに時間使ってもバグは減らないっていう事実にそろそろ気付こうよ。

**デフォルトの名無しさん** · 2018/08/30(木) 22:21:35.61

低学歴知恵遅れが書いたなぜﾀﾞﾒかを読んでない？
まず読む必要がない
頭悪すぎてお話にならないからな

適切にﾀﾞﾒなｹｰｽを書いてるのはｵﾚしかいないからな
当然、低学歴知恵遅れのﾚｽなんかどうでもいいことになる

**デフォルトの名無しさん** · 2018/08/30(木) 22:48:08.67

まず読む必要がない事を書いてくれてありがとうな

**デフォルトの名無しさん** · 2018/08/30(木) 23:10:41.48

些細なヘイトスピーチもきっちりデバッグしてる欧米の文化の方がITの才能がある

**デフォルトの名無しさん** · 2018/08/31(金) 02:17:18.78

>>233
ワナビーの法則
って何？
ググってもこのスレしか出てこないんだが
https://i.imgur.com/PzUYieo.jpg

**デフォルトの名無しさん** · 2018/08/31(金) 05:21:39.77

>>248
ホントこれ

**デフォルトの名無しさん** · 2018/08/31(金) 11:41:15.33

無益なものを批判する暇があったら
有害なものを批判しろよ

**デフォルトの名無しさん** · 2018/08/31(金) 19:26:31.62

右の睾丸を触られたら左の睾丸を触りなさい

**デフォルトの名無しさん** · 2018/08/31(金) 19:58:49.98

刑を執行してはいけないが、裁判と有罪確定まではやっていい

**デフォルトの名無しさん** · 2018/08/31(金) 21:20:12.74

ｷﾞﾙﾃｨ
死刑！

**デフォルトの名無しさん** · 2018/08/31(金) 23:12:29.91

>>243
それが常人のイディオム
bool型の変数に説明的な変数名をつけるだけで
ifの可読性が増すなんてことは
自分で思いつくか
人のを見て気付くか
人に教わって知るか
いずれかの方法で自分のものにするはず

たぶんアホは変数名をflagなどにしてて
「フラグがTRUEのとき」などという覚え方をしてるからこそ
if flag_foo == true　などという書き方になるんやろな、知らんけど

**デフォルトの名無しさん** · 2018/08/31(金) 23:21:27.80

いつまで初心者な話題ばっかやってんの
つまりはそういうことなの？

**デフォルトの名無しさん** · 2018/09/01(土) 02:13:15.43

a < b < c　みたいな連続比較（演算子の連結？）って、なんで流行らないの？

**デフォルトの名無しさん** · 2018/09/01(土) 02:24:21.20

Python、Julia、Mathematica辺りはできるね
意外にMatlabはできない

**デフォルトの名無しさん** · 2018/09/01(土) 07:28:39.38

>>260
大して簡素化しない割には、ANDしか対応できないからじゃね？

**デフォルトの名無しさん** · 2018/09/01(土) 07:59:09.68

rangeにinかなにかでよさげ

**デフォルトの名無しさん** · 2018/09/01(土) 08:01:36.87

>>260
文法が複雑になるし、等値比較の扱いをどうするかが難しい
a = f
これC系の優先順位に倣うと (a = f) が自然だろうけど、たぶんこの式を書いた人の期待していた結果ではないだろう

**デフォルトの名無しさん** · 2018/09/01(土) 10:17:17.34

数学では a = f はガイジが書いたとしか思えない

**デフォルトの名無しさん** · 2018/09/01(土) 10:18:25.01

でも個人開発じゃなかったらガイジも書くから

**デフォルトの名無しさん** · 2018/09/01(土) 10:31:17.38

>>265
そんなに出てこなかろうが書けなきゃ一貫性に欠ける
a < b <= c の形に限るんなら a in (b..c] の方が美しいわ

**デフォルトの名無しさん** · 2018/09/01(土) 10:56:33.83

>>267
あんまり出てこないって言っただけで、>>265の二つめは出来た方が良いと思うよ。三つめガイジだけど
で、>>261に挙げられた言語は出来ないの？出来るんじゃね？

**267** · 2018/09/01(土) 11:13:45.36

>>268
その上で、範囲チェックにしか使えないんなら範囲チェックに特化した表記の方が望ましいという意見なんだけど、言ってる意味わかる？
表記上は一般的に広く使えそうに見えて実は特定の限定的なパターンしか認めないってのは典型的なダメ言語だよ

**デフォルトの名無しさん** · 2018/09/01(土) 11:16:35.64

「数学では～」っていう言い方見ると悲しくなる
高校数学やそれに毛の生えたようなとこしか触ってないのに
それをもって「数学では～」などと笑止千万

これは>>265にあてつけたんじゃなくて
昔からずーっと思ってたこと

**デフォルトの名無しさん** · 2018/09/01(土) 11:19:23.27

まさかMaybeが出来ない初心者なんていませんよね

foo p x y = if p y x then Just x else Nothing
bar m p = maybe False p m

(a <= b && b < c && c == d)
== ((Just a >>= foo (<=) b >>= foo (<) c) `bar` (==d))

**デフォルトの名無しさん** · 2018/09/01(土) 11:19:31.04

>>269
いや、だからキモいしガイジしか書かないけど、書けた方が良いって言ってんじゃん
で？>>261の言語は書けるんじゃないの？

**デフォルトの名無しさん** · 2018/09/01(土) 11:27:25.51

数学でも a c みたいな書き方はしないし
許してる言語もないだろ

**デフォルトの名無しさん** · 2018/09/01(土) 11:37:23.08

>>273
それが文法上許されないことを説明する一貫性のある理由がない
<と<=を特別扱いみたいな一貫性の欠片もないガイジ仕様にするくらいなら要らない、という設計判断は十分にありうる

**デフォルトの名無しさん** · 2018/09/01(土) 11:47:25.54

必要か不要かを判断するコストは実際にはものすごく高い
簡単に作れるかどうかで判断してたくさん自由に作ってどれかひとつ成功すればいい

**デフォルトの名無しさん** · 2018/09/01(土) 11:52:13.22

Juliaだと a c は合法だった
多分 a c を計算してるっぽい
しかし文法的に一貫性があるのはわかるのだが
これが書けてしまうのはやはり気持ち悪いな

この手のでRangeで書きにくいやつだと、
行列の上三角成分だけ舐めるときに
1 <= i < j <= n
とか書けるとちょっとだけ嬉しい

**デフォルトの名無しさん** · 2018/09/01(土) 12:00:11.31

a < f(b) < c
fは何回呼ばれるべきか

**デフォルトの名無しさん** · 2018/09/01(土) 12:11:13.69

理想的にfが純粋関数でbの値がconstで1回だけ評価が素直だと思うが

**デフォルトの名無しさん** · 2018/09/01(土) 12:11:17.71

pythonの場合、 a < b という式の型がboolなのに (a < b) < c ができてしまうというのが
非常に分かりにくいね。なんというか、むりやり捻じ込んだ感。

**デフォルトの名無しさん** · 2018/09/01(土) 12:14:38.95

a a and b < c

どっちがわかりやすいか？

**デフォルトの名無しさん** · 2018/09/01(土) 12:36:45.65

なんで
a < b and b < c
じゃないの？

**デフォルトの名無しさん** · 2018/09/01(土) 12:53:55.22

センス

**デフォルトの名無しさん** · 2018/09/01(土) 13:05:45.26

>>280
1=1<2だったらどうすんの？

**デフォルトの名無しさん** · 2018/09/01(土) 13:19:35.77

>>280
コンパイラは大抵
b > a and b < c
のがわかりやすいと判断している。

**デフォルトの名無しさん** · 2018/09/01(土) 18:37:02.95

だれかがいってるように
ﾏｼﾞで頭悪い。。。

aho = a < b ← 結果はﾌﾞｰﾘｱﾝ
baka = aho < c ← ﾌﾞｰﾘｱﾝを大きさで比較してる
< は普通2項演算子で予約されてるからな

3項演算子みたいに使ってない記号を組み合わせるならまだ理解できる

**デフォルトの名無しさん** · 2018/09/01(土) 18:51:27.82

>>281
その書き方だと　0 < x < 100 が
0 < x and x<100になるからセンス悪いと思った

x > 0 and x <100

xが0より大きく100より小さいにマッチするような記法がない

**デフォルトの名無しさん** · 2018/09/01(土) 19:03:39.36

ワロた

**デフォルトの名無しさん** · 2018/09/01(土) 19:34:08.16

半角の人はいい加減に自分が馬鹿なことを認めてほしい。

**デフォルトの名無しさん** · 2018/09/01(土) 19:34:46.46

>>285
ineqop ::= ('<' | '<=' | '>' | '>=')
ineqexpr ::= shiftexpr { ineqop shiftexpr }
みたいに定義すりゃいいだけだろ

**デフォルトの名無しさん** · 2018/09/01(土) 19:47:34.46

なにも解決してない
構文規則と演算の規則は
なんの関係もないからな

知恵遅れは構文規則でかければ
自動的に演算規則ができて

なんでも演算できると思ってるらしい
構文規則と解釈が分離できてない

ｺﾚが低学歴知恵遅れの限界
ﾎﾝﾄな気の毒なぐらい頭悪い

**デフォルトの名無しさん** · 2018/09/01(土) 19:51:19.20

>>290
任意個数のオペランドを持ったノードとして左から順に評価すればいいだけだぞ
CやJSのカンマ演算子なんかと一緒

**デフォルトの名無しさん** · 2018/09/01(土) 19:52:39.70

a < bは
普通にﾌﾞｰﾘｱﾝ返す演算子だからな
普通にﾌﾞｰﾘｱﾝ返すのが正しい演算だ

**デフォルトの名無しさん** · 2018/09/01(土) 19:53:45.56

aho ? baka1 : baka2
全然違う

**デフォルトの名無しさん** · 2018/09/01(土) 19:56:29.75

a < b の値は最初はintだったのをboolに変えたんなら次はMaybeに変えてもいいぞ

**291** · 2018/09/01(土) 19:56:58.30

カンマ演算子と一緒は間違いだな、撤回する
例えば配列リテラル式と一緒だと考えればいい
あれは任意個数のオペランドを引数にとって全体として配列型を返す演算子であると解釈できる

**デフォルトの名無しさん** · 2018/09/01(土) 19:57:48.29

非ｾﾞﾛを非ｾﾞﾛでないかを
真偽にしても別に問題はない

**デフォルトの名無しさん** · 2018/09/01(土) 20:00:11.15

真偽値をどういう値にするかどうかなんか関係ないからな
式の評価で真偽判定を行わないという解釈の問題になるからな

**デフォルトの名無しさん** · 2018/09/01(土) 20:01:12.82

とりあえず低学歴知恵遅れは
とてつもなくｵﾂﾑに問題があるのが
このｽﾚみててもよく分かる

適切な問題の分離のしかたが分かってない

**デフォルトの名無しさん** · 2018/09/01(土) 20:03:28.96

アホだなあ
演算記号が単独で式を構成しなければならないなんて決まりはない
全体で式を構成すると考えれば何の問題もない

**デフォルトの名無しさん** · 2018/09/01(土) 20:06:47.42

a < b < c
まず a < b を評価して
その評価結果を
(a < b) < c
で評価するという決まりだからな
ｺﾚが正しい解釈になる

それ以外は不適切な解釈

**デフォルトの名無しさん** · 2018/09/01(土) 20:07:36.43

Iconという言語だとこれが、a < b という式は成功した場合の値がbになるから a < b < c が
自然に実現できるんだよな。

**デフォルトの名無しさん** · 2018/09/01(土) 20:13:43.79

>>300
じゃあ関数呼び出し式 (f)(a, b) はどう解釈する?
君のいう正しい解釈のように ((f)(a))(b) と解釈する言語も実際に存在するけど、あまり一般的ではないよね

**デフォルトの名無しさん** · 2018/09/01(土) 20:22:54.83

>>300
この辺レガシーな言語なら最初の比較で出るのはbool型になるからcと比較してまともな結果になるはずがないんだよね

**デフォルトの名無しさん** · 2018/09/01(土) 20:25:39.05

>>302
二項演算子 a < b と三項演算子 a < b < c が同時に存在するというイメージなんだろうか。
a < b がコンテキストによってboolを返すかbを返すか変化するという方がまだ無理がないな。

**デフォルトの名無しさん** · 2018/09/01(土) 20:32:20.02

if(対象 == オブジェクト)
if(事象)
対象コンテキストと事象コンテキスト
すべてがオブジェクトといったな、あれは嘘だ

**デフォルトの名無しさん** · 2018/09/01(土) 20:50:05.62

関数呼出規約なんかこの話となんの関係もない
まともなｵﾂﾑしてたら関数呼出で順序の副作用がおきるような書き方なんかしないからな

昔のMCSのｺﾝﾊﾟｲﾗでも例えば、cdeclとpascal呼出規約があった
cdeclとpascal呼出規約をかえると、結果が変わるような知恵遅れなｺｰﾄﾞ書くﾔﾂなんか
このｽﾚにいるような低学歴知恵遅れしかいない

わかった？

**デフォルトの名無しさん** · 2018/09/01(土) 20:56:58.84

>>304
C言語的な演算子の概念に拘るなら、比較式はn項演算だと考えれば理解しやすいかな
実際scalaやF#のmatchとかRubyのifとかはn項演算の例だし、そんなに珍しいもんじゃないよ

**デフォルトの名無しさん** · 2018/09/01(土) 21:36:47.04

>>307
構文解析の難易度の話なんだけど、matchなどといった開始語を欠いているうえに
<=や>など他の演算子との混在も考慮しなければならないとなったら、かなり
困難なものになる思うが。

**デフォルトの名無しさん** · 2018/09/01(土) 21:39:24.86

それは可変引数をもった特定の関数呼び出しと意味的同じだからな
低学歴知恵遅れにそんなこといってもしょうがない

**デフォルトの名無しさん** · 2018/09/01(土) 21:49:16.31

学校で教えるのはプログラムではなく物理とか微分とかなので
学歴重視はハードウェア重視や機械学習重視になりがち

**デフォルトの名無しさん** · 2018/09/01(土) 21:57:05.44

>>308
>>289で終わりじゃね

**デフォルトの名無しさん** · 2018/09/01(土) 22:17:22.89

知恵遅れに理解はﾑﾘ
知恵遅れの自覚がまったくいない

**デフォルトの名無しさん** · 2018/09/01(土) 22:26:51.47

>>289はshiftexprの定義がないんで厳密なところがわからんけど、後者のshiftexprは
ineqexprじゃないの？

**デフォルトの名無しさん** · 2018/09/01(土) 22:39:41.95

>>313
合ってるよ
これでわかるか？
比較式 ::= 低優先順位の式 {比較演算子低優先順位の式}
{}はEBNFで一回以上の繰り返し

**デフォルトの名無しさん** · 2018/09/01(土) 22:40:56.19

失礼
低優先順位じゃなくて高優先順位の式の間違いだな

**デフォルトの名無しさん** · 2018/09/01(土) 22:41:42.09

>>300でｵﾜﾘ
それ以外は知恵遅れの寝言だからな

**デフォルトの名無しさん** · 2018/09/01(土) 22:45:20.98

構文解析できればなんでもできると思い込んでるからな
低学歴知恵遅れには、その先の解釈のﾚﾍﾞﾙまでおとしこむ知能がない

**デフォルトの名無しさん** · 2018/09/01(土) 22:56:42.31

オペランドを順に評価しながらandで繋ぐだけだろ？
半角クンにとっては難しいのかな

**デフォルトの名無しさん** · 2018/09/01(土) 22:58:45.07

そういう問題じゃないからな
やはり知能の問題

**デフォルトの名無しさん** · 2018/09/01(土) 23:23:52.10

小学校でプログラミング教育ってチューリングマシンとか
ラムダ計算とかするわけでしょ
すごいよね

**デフォルトの名無しさん** · 2018/09/01(土) 23:34:33.99

ブーリアンヴォーイズは、いい加減パーキンソンの凡俗法則でググろうな

**デフォルトの名無しさん** · 2018/09/01(土) 23:44:33.13

流れ本体とは関係ないが
>>286のレスが意味不明
とくに
> 0 < x and x<100になるからセンス悪いと思った
この部分

>>281へのレスとしては
最後の一行もさっぱり意味分からんが

**デフォルトの名無しさん** · 2018/09/01(土) 23:59:16.46

>>280
a < b and b < c

**デフォルトの名無しさん** · 2018/09/02(日) 00:22:13.35

上座と下座みたいなセンスかな
OOPでは引数の中で一番偉いやつを左に書くよな

**デフォルトの名無しさん** · 2018/09/02(日) 00:30:30.37

a c が合法になるぐらいなら a < b && b < c でいい

**デフォルトの名無しさん** · 2018/09/02(日) 00:33:32.41

>>322
比較するときにつねに左に変数がないと気持ち悪いタイプなんだろう
個人的にはそれはそれで分からなくはない
俺はこの場合は数直線順のほうが読みやすいと思うが

**デフォルトの名無しさん** · 2018/09/02(日) 00:40:47.30

> 比較するときにつねに左に変数がないと

プログラミングエアプか？
変数と変数を比較するケースを>>286以外のみんなは当然想定したわけで

**デフォルトの名無しさん** · 2018/09/02(日) 01:37:29.19

不等号をカリー化しようや

**デフォルトの名無しさん** · 2018/09/02(日) 02:01:29.06

a < b < c
Pythonが採用して、Rubyが採用しなかった
そう言うことだと思う

**デフォルトの名無しさん** · 2018/09/02(日) 05:30:33.71

>>288
愚か者はその愚かさ故に自分が愚かであることがわからず思い上がって傲慢になる。
賢い者はその賢さ故に自分が愚かであることがわかり遜って謙虚になる。

**デフォルトの名無しさん** · 2018/09/02(日) 06:00:58.71

常にってわけじゃないけど
RangeやRectなどで繋がりのある組を明示すると意図を読みやすいと思う
シンプルなケースは a < b で良いけど、複雑になる程inとかも使わず普通にメソッドで

if (a ..< c).contains( b ) {
　　print("含まれる")
}

if (a ..< c).contains( a ..< b ) {
　　print("含まれる")
}

if (10 ..< 30).overlaps( 20 ..< 40 ) {
　　print("重なっている")
}

if Rect(x:10, y:20, w:100, h:100).contains( Point(x:50, y:50) ) {
　　print("含まれる")
}

**デフォルトの名無しさん** · 2018/09/02(日) 06:48:37.78

以下の2つの書き方がある

左に、小さく方を書く
0 < x and x < 100

左に定数を書く。
定数には代入できないため、すぐにエラーが発見できる
0 < x and 100 > X

**デフォルトの名無しさん** · 2018/09/02(日) 07:13:44.39

スレチかもしれないけど
人工知能が今後発展していくにつれて、CとかJavaとかRubyみたいな言語って廃れていって、人工知能に関連しない分野のプログラミングスキルは無価値になって、人工知能に特化したPython一強みたいな感じになるの？
プログラミング始めたばかりなんだけどふと疑問に思った（同じくらい初心者であるはずの知人がこれからは人工知能に関わる言語だけやっていればいい、それ以外じゃ食っていけない、みたいなこと言ってたから）
こういう話題は何度も出ていてうんざりしてたらごめん

**デフォルトの名無しさん** · 2018/09/02(日) 08:18:58.41

>>332
下はヨーダ記法って言ってな
時代遅れなんだよ池沼