次世代言語11[Rust Swift TypeScript Dart]
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語10[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1524607347/ マイナーvsマイナーだと、設計そのものの良し悪しよりも
どれだけ労力をかけて作り込まれているかの方が影響でかいからなあ……
作ってる側が「いやそこの最適化は後回し」とか思ってるところを測ってもしょうがないし
(いやメジャーvsメジャーでもそういうとこあるけど) 「疑う」の反対は「割る」
割れば楽しいのはわかった上で敢えて疑う方を選ぶんだろう >>738
なんかSmalltalk風味があるな・・・ MSのやり方について講釈垂れる前に
ライセンス見ろよとしか(VSCode,vscode) >>742
陰謀論者は生きづらそうで大変ですね。
もしMSが手のひら返したら、forkするだけですけど? forkするだけ(藁)
強がっちゃってまあ
いいのか?フォフォフォカヌポォしますぞ!!!(憤怒)←草www forkするより製品版を単純にコピーするだけの方が早い
MSの影響で民度が下がる
MSと無関係でいる方が安全 数年前の意識高い系達が「Web開発のスピードにIDEなど邪魔(キリッ」とか言ってたのが嘘みたいだよな
結局のところ彼等は電気を知らない原始人だったのだ Vimは操作性や立ち上がりの速さが優れている
Guiのエディタはプラグイン導入の楽さが優れている
Emacsは間くらい >>742
つーか誰もツッコんでないんだけど、なんでこんな遅レスなんだっていう >>756
Gitlabは少なくとも信頼できる
Azureで動いてるとか言ってる奴いるけどもうやめるって話出てる
エディタはEmacsで十分だし、babelあればES2016でもまともに書けるからTSは不要 >>759
消したあとの対応は信頼できる
MSなら消しても揉み消してた >>760
MSそんな事したことあったっけ?
ただの妄想? 疑問を持つ人はいっぱいいるが疑問を解決する人は少ないのが現実で
すぐに解決すると思うのは非現実的 年食うと一度学んだ思考回路は変えられないんだろうな
多分死ぬまでMSは邪悪でEmacsは最高のエディタなんだろう あとSwiftでパターンマッチ使うときさ「case let」の「let」ってなんの意味有るの?
そもそも「case」自体いらないよね。
Rustみたいに簡潔な構文にしない意味がわからん。 簡潔って記号だらけにしろってこと?
perlでも使ってれば Scalaも構文ダメだけど、Dottyでかなり改善されてるみたいだね
http://dotty.epfl.ch/ >>768
>>769
冗長な構文にするなってこと。
```Rust
match number {
1 => "one",
2 => "two",
_ => "else",
}
```
```swift
switch number {
case 1: return "one"
case 2: return "two"
default: return "else"
}
``` msが嫌いならflow使っとけばいいよ。
俺はTypeScriptで行く >>771
rustをそんなに押すなら、
毎日ちょっとずつ使い方教えていけよ。
面白い内容ならそのまま覚えるから >>770
dottyは流石に見苦しいわ
今更互換性ブチ壊して誰がわざわざScalaなんか使い続けるんだよ
Lightbendは一度プラットフォーム主導者の味を覚えてしまってもう後に引けなくなってるんだろうな 元が冗長だと、機能追加したときの新構文(大抵元と区別のために冗長になる)が
あまり違和感なくなるというメリット?もある
C++とか酷いだろ。rustも多分20年ぐらいしたら酷くなる >>776
Rustが20年も残ってるとか信者かよ >>763
いつMSが邪悪じゃなくなったんだよ
エディタについてはVimとEmacs以上のものがいまだにないだけ >>778
ObjectPascalは30年経ってるが、元が冗長と言われまくってたPascalだったおかげで
魔改造されまくった今でもあんまり浮いた構文は無いぞ
初期Macで採用されてたのは別格としても、その後は大したプロダクトもないDelphiぐらいでしか残ってないのに
一応生き残ってるんだから、FirefoxのあるRustも同じぐらいは残るだろ多分 >>780
どっちかっていうと、若者がMSの暴虐の歴史を学んでないから
今現在進んでる暴虐が暴虐と分からないだけだぞ >>781
火狐に使われてるから残るとか
火狐の世界シェア見てから言おうぜ……
Rustごと自殺して消えるって自白したようなもん この爺さんはこのスレに何しにきとるんだ
特養じゃないっつの >>787が書いてくれたが
俺も、どっちも細々としたもんだがFirefoxのほうがDelphi(製アプリ)よりはまだマシだろう、というつもりだった
その上で20年後の変更されまくったrustはDelphiやswiftより汚くなってそう、という予想 >>785
varがあるのはわかるけど、そこでvarを使う場面てあるのかね?
https://ideone.com/vMGLEg
```swift
case let .B(n):
let t = n+1
return String(t)
```
だって変わらんし >>785
それにvarのときだけつければ良くないかね,Rustだと「mut」つけるだけだけど
https://play.rust-lang.org/?gist=f7bb032027fcdbc6db2f033c4874c27c&version=stable&mode=debug
```rust
AB::B(mut n) => {
n+=1;
n.to_string().into()
}
``` >>791
変数束縛にletとvarがある言語において、switchのときだけ変数束縛を特別扱いしてletやvarを省略できるのは一貫性が無いという考え方もある それに短ければ良いなら、rustのlet mulよりswiftのvarの方が短い
パターンマッチより変数宣言方が良く出て来るしね 20年後に汚くなるってのはみんなわりと納得するんじゃね?
C++もJavaも、時間経過とともにきっちり汚くなった
言語仕様こねくり回すのが仕事の人が存在するからしゃーないっちゃあしゃーない 難しい・易しいではなく汚い・美しいという見方をするのはなんでだろう
数学を諦めた感が漂ってる >>793
そういう見方もあるけどね
でも
```
case let .B(x): return String(n)
```
と
```
case .B(let x): return String(n)
```
の違いってなんなのかね、違いがないなら「let」省略できたほうがいいように思うが >>794
短いことがいいんじゃないよ、理由なく冗長な構文がだめなだけ。
Rustはわざと「var」とかじゃなく「let mut」にしている理由は、通常イミュータブルを使うようにするため。
ミュータブルの構文が長いことでプログラマがイミュータブルをより一般的に使うよう促す効果がある。 可読性の高い綺麗なPerlコードを書けるものだけが石を投げなさい >>799みたいなのは設計当初は綺麗なんだけど
後から、例えばD言語のconst/immutableみたいな選択肢を追加してしまうと罠に化けそうじゃない?(妄想だけど)
その点元が冗長ならある程度耐性がある、という話。後から省略可能にする方はできるしな >>801
Dは全然知らないけど、調べたらデフォルトがミュータブルで、immutableをつけるとイミュータブルになるのか。
```
int x = 3; // ミュータブル
immutable int x = 3; // イミュータブル
auto s = "hello"; // イミュータブル
```
これはひどいな >>802
そこはまあしょうがないとして、イミュータブルにも種類があるという点に注目してくれ コンパイル時に値がわかるのが定数
実行時に初期化するがその後は変更しないのがimmutableかな 加えて、現在のスコープからは変更不可能だが実体はミュータブルかもしれないのがconst
更にそれぞれに推移のON/OFFがある
何も書かないのがイミュータブルだとその内の1つを適当に使ってるということで
選択肢が増えたときにどれか1つが不自然に短く書けてたことになるし
現状を突き詰め直したときにコンテキスト毎に別のだったなんてことになると目も当てられない やっぱり言語仕様は頻繁に変えるべきということだな!w >>802
ゲェジかな
ワイの方がよっぽどいい設計できるわ
この作者はワイのケツ穴でも舐めてた方が幾分有益な人生になったんじゃないかw >>805
GCが必須ではない言語の場合、ミュータブルならばメモリ解放もできる
現在のスコープからは変更不可能だが実体はメモリ解放するかも
というのは非常にまずい
現在のスコープから変更不可能ならば実体も変更不可能にしたい >>808
それだとイミュータブルなオブジェクトを貰って何かする関数に
ミュータブルなオブジェクトを渡せなくならない?
そうすると print とか toString とか hash とか compare とかありとあらゆるものが
immutable / mutable 2種類必要になる
引数に2つオブジェクトがあると4種
3つなら8種 ただの再代入不可な変数をイミュータブルって言い始めたのって何の言語からなの >>795
pythonなんかも細かいところはど汚いわけだがあんまりそういう汚いところ
触らんでも仕事になるって違いはある。
てかシンタックスなんててきとうにチェックでもそんな問題にならんよ。
self書かされることなんて文法で規制されてるわけでもないが問題になることなんてない。 >>810
変更可、不可という概念は別に変数に限った話じゃない Pythonの型アノテーション試してるけど正直苦痛
TypeScriptを使ってるときには全く感じなかった無駄なもの書かされてる感がすごい
というかTypeScriptの統合が完璧すぎるんだな
型書くことはノイズになるどころかコードをむしろ美しくするとすら思えるもんな 少しでも欲を出せばそうなる
完璧な無欲か完璧な満足かの1bitしかない
HaskellやRustのようになるまで止まらないぞ >>814
Python 3.6の変数アノテーションはTypeScriptと大して変わらないのでは?
以前のコメント形式は糞だったけど >>814
全部の変数にアノテーション付けようとしてる?
基本、関数・メソッドの入出力だけでいいぞ
残りは大体推測してくれる >>817
ライブラリなどの既存メソッドの戻り値はほとんど型なしだから結局オレオレ型宣言を左辺の変数に付けて回ることになる >>818
あー、過渡期だからそれはあるかもね
対策としては、他モジュールを呼び出すところはなるべく集める、いきなり完璧を目指さないぐらいか そんなに型に気を使って消耗する位ならもう生js使おう
適当にラッパーかけとけラッパー >>820
TypeScriptユーザーがシコシコ型定義ファイル作ってるおかげで、vscodeでjsでも補完きくんやで。感謝せーや せめて同梱の標準ライブラリくらいは網羅しておいてほしいよね。 >>814
typeScriptみたく型定義ファイルの共有する仕組み無いの?
いちいち書くのはしんどいな。 >>823
しんどいのか
その作業がないということはライブラリの作者は楽をしている
だからライブラリが増やすのも楽
そういう仕組みなんだろう >>824
TypeScriptの場合は型定義を提供することでTypeScriptユーザーに使ってもらいやすくなり、
ユーザーの増加がライブラリ製作者にとって一手間かけるモチベーションになる
Pythonの場合は型アノテーションを付けたらPython3.5以上でしか使えなくなるのでユーザーは確実に減る
結果、誰も対応しない
根本的に破綻してるんだよ >>825
破綻してるのはお前のマウンティングだよ
マウントが酷いのはHaskellで、TypeScriptは無関係みたいなイメージが根本的に壊れた おれ的にはこのまま型定義ファイルがすべてのライブラリに標準装備されて緩やかにjsがts化していくことを希望したい。
最初から型定義がライブラリに入っていること多くなってきたよな、 このスレに来て初めてマウンティングって言葉を知ったわ。 >>823
あるよ。
typeshedてのがそれ
>>825
関数の引数、返値なら3.0から書けるし、コメント使うか別ファイルに書くやり方なら2.7にも対応可能ですが Haxe では型定義ファイルがあるから、型推論も入力補完もできる 通常ならライブラリ本体丸ごと読んで型を調べるべきだ
本体に型がないなら別ファイルに書く >>831
なんだあるんだ。なら型付言語として使われるのも時間の問題だな。
rubyにもあるみたいだし、
ライブラリのインターフェースだけでも型付き当たり前の世界が来そうだね まーたruby信者のそ、そんなのる、るびぃでもできるし!か。呆れ
なんでもかんでも深く考えず流行りをそうやって後付けで増築してって奇形極まってるよね。二度と使わないよ。 rubyの違法建築感は否定しない
が、なんかまとめ臭い書き方だなおい
5chエアプか? るびぃ信者、Proc.new、ラムダ、ブロックにおけるreturn、break、nextの挙動の違いをまとめようとした模様
https://qiita.com/jnchito/items/83410c0cda446efea582
結果、ややこしすぎるためコーディングを工夫してreturnやbreakの使用を避けましょうというなんじゃそりゃな結論www
何か理由があってわざわざ挙動を変えたんだろうが(まさか行き当たりばったりってことはないよね笑)ややこしすぎで使用自体を避けられてちゃ本末転倒だよなwww >>836
その人はrustがコンパイルできないおじさんだからほっときなさい >>834,836
とはいえ、ruby にまともに使える型チェックの実装があるのかには興味あるな。
まえ調べた感じだと、教祖の型チェック周りの発言はフワッフワだし、実装してみたい個人が互換性のない「オレオレ型チェック」を作っては破棄してる感じで、万人が使えるものは何一つないようなんだが。 どうせ
if type(...) != my_class:
とかのシュガーだろ。そんなもんに目くじら立てても意味あるのかね。 Rubyはオモチャだから型付けなんて要りません
それより散らかったオモチャを片付けなさい ■ このスレッドは過去ログ倉庫に格納されています