次世代言語23 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

前スレ
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/

**デフォルトの名無しさん** · 2022/02/11(金) 18:27:07.40

>>191
そこはRust限定の話ではなく一般的な話だと思う
参照というのはあくまでも実体があってこそ生きていられる存在
だから実体を保有する変数がどこかに必ず存在していて
その実体が参照よりも長生きしていないとダングリングポインタになってしまう

(ここからはRustの話)
したがって実体の方を本体として無記号にし
それに依存している存在にすぎない参照の方を＆記号で示している

**デフォルトの名無しさん** · 2022/02/11(金) 23:20:00.56

>>189
すべての関数呼び出しが末尾再帰であれば、呼び出しにあたって現在のスタックフレームを保存する必要はないから、中途半端な
手続き言語で分かった風に語りだす人は、どこかおかしい。コンピューターサイエンスとか齧ったことは無さそう。Rustをやってる人の
こういう語りは言語の発展の邪魔でしかないね

**デフォルトの名無しさん** · 2022/02/11(金) 23:30:45.78

>>193
どうみてもその>>189はRustをわかっていない人がむしろ(デタラメにRustを)批判してるような

**デフォルトの名無しさん** · 2022/02/12(土) 01:31:10.49

Go言語の作者Rob Pike氏が2015年に発表した「Go言語が成功した理由は何なのか？」で
> mapやfilterのような機能は言語の表現力を高めるものであり、書いていて楽しい言語に繋がるわけだが、
> これはそのトレードオフとなるメンテナンス性が高く扱いやすい言語という点をを犠牲にするだけでなく、
> （極めて素晴らしい方法で実装しない限り）コンピューターリソースを非常に消費するものだ。
と述べていて当時はその通りに思われてGoでは毎回for文で書くことがシンプルで良いとされてきた
しかしその後Rustのイテレータ実装ではfor文とほぼ同様に速く動かせるようになり
for文で毎回ごちゃごちゃ書くよりメンテナンス性もよく扱いやすいとわかった

**デフォルトの名無しさん** · 2022/02/12(土) 02:24:04.92

Rust創造イテレータおじさん。。。

**デフォルトの名無しさん** · 2022/02/12(土) 02:36:04.74

どうみても言語の否定じゃなく、どうでも良いようなことを延々と語りだすそいつの思考の人格・性格的否定だろうに。
こんな読解力も何もない奴ばっかか・・・

**デフォルトの名無しさん** · 2022/02/12(土) 14:28:17.06

>>195
Rust開発者は天才だから仕方ない

**デフォルトの名無しさん** · 2022/02/12(土) 16:13:21.86

所有権という概念を生み出したrustの人（名前わすれた）は天才だよ
効率性と安全性を同時に実現してる
これを関数型言語の人が生み出せなかったのは謎すぎる

**デフォルトの名無しさん** · 2022/02/12(土) 16:49:53.94

Ruby にはLazy があるから、無限配列でも、iterate できる

実行順序を変える。
書いた通りに前から実行しない

**デフォルトの名無しさん** · 2022/02/12(土) 17:46:20.26

所有権というかRAIIパターンはC++の方が先でlifetimeの方が独創性あると思う

**デフォルトの名無しさん** · 2022/02/12(土) 18:09:28.52

ライフタイムによって本体だけでなくその参照の正当性まで保証できるようになったわけだ

>>200
Rustのイテレータは受動的に遅延生成だから無限生成もできるけど
勝手に実行順序を変えるようなことはなくプログラマーが書いた通り

**デフォルトの名無しさん** · 2022/02/12(土) 18:33:27.41

>>199
あいつら本当はラムダ計算をしたいのに実現出来なくて仕方なくチューリングマシン考えてる妥協の民だからそんな発想なさそうｗ

**デフォルトの名無しさん** · 2022/02/12(土) 18:34:57.60

>>199
関数型言語は同一データの共有が極めて多く発生するため、GCなしの実装は実用的ではない
参照透過な言語ならメモリの共有さえしなければいいわけでGCなしの実装は極めて容易だけど、無限のメモリを必要とする

**デフォルトの名無しさん** · 2022/02/12(土) 19:00:19.19

関数型はGCが問題になるような途中過程の実行タイミングのシビアな用途に使われないからってのも大きな理由だと思う
性能面で言えば、ガベージの数が命令形に比べて桁違いに多いからいちいち参照カウントとかやってたらクソ非効率だろうし

**デフォルトの名無しさん** · 2022/02/12(土) 19:37:20.77

Ruby で普通の繰り返しは、a が無限要素だと、aで止まる

a.b.c
つまり、aの要素数ループ、bの要素数ループ、cの要素数ループの順番

それが、Lazy では、実行順序が変わって、
aの1つ目の要素、bの1つ目の要素、cの1つ目の要素
aの2つ目の要素、bの2つ目の要素、cの2つ目の要素
となる

つまり、aが3要素とすると、a1a2a3・b1b2b3・c1c2c3 が、
a1b1c1・a2b2c2・a3b3c3 に変わる

**デフォルトの名無しさん** · 2022/02/12(土) 21:05:09.08

>>201
確かに所有権っぽいことならC++でもそれっぽく書けはする
ライフタイムは最初なんじゃこれって思ったけど
我慢して書いてみると見事に"missing piece"を埋めてくれた

**デフォルトの名無しさん** · 2022/02/12(土) 23:41:53.37

我慢して書いてみるって発想は
ルールを守るよりも抜け道を探してそうなハッカーの発想とは対照的だね

**デフォルトの名無しさん** · 2022/02/12(土) 23:51:27.76

>>206
当たり前のことを書いてるだけじゃん
Rubyではlazy導入で遅延処理となり必要最小限だけをようやく処理できるようになったけど
例えばRustでは最初からそのlazyになっている
だからイテレータを連鎖した時に途中に毎回の無駄な一時配列が生成されることもない
それゆえRustではガベージが途中で生じずスタック領域のみ使用で連鎖でき軽くて速い

**デフォルトの名無しさん** · 2022/02/13(日) 03:57:54.17

array::mapは複製が生じるだろ、普通はarr.map(...).map(...)は使わないにしてもlazyだから無駄な一時配列が
生成されることもないとか言い過ぎだ。ちゃんとドキュメント読んでんのか？そもそも一時的な集合要素が必要に
なるのはアルゴリズム次第であり、”理解してないのに”信じてしまう事は愚かすぎる

**デフォルトの名無しさん** · 2022/02/13(日) 04:07:23.70

>>210
array::mapはイテレータじゃないよ

**デフォルトの名無しさん** · 2022/02/13(日) 04:15:35.21

だから複製生じるでしょ

**デフォルトの名無しさん** · 2022/02/13(日) 04:24:59.24

array::mapで複製は生じるけどイテレータがlazyか否かの議論には何も関係ないよね
mapはOption::mapなどと同じでイテレータとは関係なくコレクションやコンテナの中身を写像する関数であって、イテレータにも同様の意味を持つ関数が用意されているというだけ

>>209 のイテレータだから無駄なものは作られないは言い過ぎで反例はありそうに自分も思うけど、イテレータじゃないものを持ち出すのは例として適切ではない

イテレータそのもののせいではないが borrow checker のせいで余計なアロケーションが必要になる場合はある
以下の記事の最後の方のコード例なんかが一例
https://fasterthanli.me/series/making-our-own-executable-packer/part-6

**デフォルトの名無しさん** · 2022/02/13(日) 04:25:50.19

>>210
array::mapはイテレーターではありません
配列から配列への単なる変換です
| pub fn map<F, U>(self, f: F) -> [U; N] where F: FnMut(T) -> U
arrayでのこの定義を見ればイテレーターではなく返り値の型が配列だとわかるはずです
ちゃんとドキュメントを読みましょう

イテレーターを使えば以下のような例において
Rustでは無駄な一時配列が生成されることはありません
[6, 4, 7, 3, 5, 9, 2, 1, 8]
.iter()
.map(|n| n * n * n)
.filter(|n| n > &300)
.for_each(|n| println!("{n}"))

**デフォルトの名無しさん** · 2022/02/13(日) 04:39:02.47

<[T ; N] as Iterator>::map() のドキュメントを参照してlazyなことの裏取りをしようとしたら array::map() にたどり着いちゃったのかな
だとしたら rustdoc が分かりづらいのが悪い

**デフォルトの名無しさん** · 2022/02/13(日) 04:44:32.73

<[T; N] as Iterator> なんて存在しなかった
正しくは
<<[T; N] as IntoIterator>::IntoIter as Iterator>::map
または
<std::slice::Iter as Iterator>::map
だった

こんなの初学者わかんないよね

**デフォルトの名無しさん** · 2022/02/13(日) 04:50:04.12

>>213
イテレーター連鎖の途中で「無駄な一時配列が生成されない」は常に正しいです
ただし「そのイテレーターの機能として必要不可欠な無駄ではない」一時配列(Vec)を利用するイテレーターは存在します
いずれにせよ無駄な一時配列が生成されることはありません

**デフォルトの名無しさん** · 2022/02/13(日) 05:06:50.08

>>213
そのリンク先の記事を読ませていただきましたが
借用ルール(single writer xor multiple readers)違反が原因でその回避のため途中collect()しているだけでした
具体的には&self.objectsで借用中なのに&mut selfと定義されているself.get_object()を呼び出しています
したがって今回の問題とは無関係ですね

**デフォルトの名無しさん** · 2022/02/13(日) 05:14:01.48

>>217
｢無駄な一時配列｣の意味するところがあまり腑に落ちてなかったのだけど、
例えばイテレーターアダプターを呼び出す場合に、全要素列挙して配列で返す方式ではなく、
必要に応じてイテレーターアダプターのIterator::nextが呼ばれて、
さらにその中から元となったIteratorのnext()が呼び出されて...
と、lazyに必要な分だけ呼び出される仕組みになっているということが言いたかったわけね

>>218
はい、イテレータというかborrowの制約なのでlazinessとは関係ない話ですね

**デフォルトの名無しさん** · 2022/02/13(日) 05:43:50.33

>>219
Rustの配列(array)はスタック上に置けるようコンパイル時サイズ固定なのはご存知ですよね
したがってイテレーターがもし一時配列を吐くもしくは使おうとすると必然的にサイズ可変のVec利用となりヒープを使うことになってしまいます
ところがRustの標準ライブラリのイテレーターは core::iter::Iterator すなわちcore::はヒープが無い環境でも動作可能を意味します
つまり『Rustの標準ライブラリのイテレーターは一時配列(Vec)を絶対に使わない』ように設計されているのです
一方で外部のライブラリにおいてはデータが全て完全に揃わないと動作できない機能を持つイテレーターの場合に「必要不可欠な無駄ではない一時配列(Vec)」を用いるケースがあります

**デフォルトの名無しさん** · 2022/02/13(日) 15:42:54.09

で、複製されますよね？

**デフォルトの名無しさん** · 2022/02/13(日) 15:59:57.41

上で出ていたこれなら配列は複製されない
Rustはそんな無駄なことはしない

>>214
> [6, 4, 7, 3, 5, 9, 2, 1, 8]
> .iter()
> .map(|n| n * n * n)
> .filter(|n| n > &300)
> .for_each(|n| println!("{n}"))

**デフォルトの名無しさん** · 2022/02/13(日) 16:43:01.35

そのように書くのはあなたであって"Rustだから"というのは明らかな間違いです。無駄な事をしているのはあなたであってRustではありません

**デフォルトの名無しさん** · 2022/02/14(月) 23:03:20.89

Rustのイテレータは他と機能も同じ以上なのにプログラミング言語最速
さらにヒープを使わずOSもないベアメタル環境でも動作可

**デフォルトの名無しさん** · 2022/02/15(火) 17:26:38.96

実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」
https://atmarkit.itmedia.co.jp/ait/articles/2002/10/news038.html

**デフォルトの名無しさん** · 2022/02/15(火) 18:02:19.14

>>225
次世代言語スレで2年も前のリンク持ってこられても、、、

**デフォルトの名無しさん** · 2022/02/15(火) 18:08:55.40

2020年の記事なんですけど
2020年が2年前な訳が無いんですけど

**デフォルトの名無しさん** · 2022/02/15(火) 18:42:09.32

えっ

**デフォルトの名無しさん** · 2022/02/15(火) 19:15:57.25

2022年だぜ？

**デフォルトの名無しさん** · 2022/02/15(火) 19:37:22.66

時の流れが加速している

**デフォルトの名無しさん** · 2022/02/15(火) 19:44:03.28

Rustは言語仕様が汚くライブラリもいまいちなので
同じような概念できれいな文法の言語が欲しい

**デフォルトの名無しさん** · 2022/02/15(火) 20:04:30.75

>>231
言語仕様が汚くない言語
ライブラリがいまいちじゃない言語

それぞれ例えば何？

**デフォルトの名無しさん** · 2022/02/15(火) 20:39:28.00

>>232
言語仕様が汚くない → C言語
ライブラリがいまいちじゃない .net

**デフォルトの名無しさん** · 2022/02/15(火) 21:08:36.63

レスサンクス
参考になりました(*´∀｀*)

**デフォルトの名無しさん** · 2022/02/15(火) 21:46:44.86

>>233
Cが好きならZigとか良さそうだけどどうなの？

**デフォルトの名無しさん** · 2022/02/15(火) 22:19:13.70

>>235
ありがとう
調べてみるよ

**デフォルトの名無しさん** · 2022/02/15(火) 22:22:48.94

>>231
Rustは言語仕様が洗練されていて綺麗なので気に入った
Option / Result に ? や
match / if let / while let あたり
諸悪の根源の null / nil / undefined などが無くなり清らかになった

**デフォルトの名無しさん** · 2022/02/15(火) 22:24:45.32

mutable を mutと書くのがダサく感じる

**デフォルトの名無しさん** · 2022/02/15(火) 22:46:47.98

>>225
それ昔話題になっただろ

**デフォルトの名無しさん** · 2022/02/15(火) 23:21:29.87

>>227
今年って西暦何年？

**デフォルトの名無しさん** · 2022/02/15(火) 23:21:53.24

>>238
英語でmutの語感覚ははラテン語mutare(変化する)から来ていて
mutable以外にもpermutationやtransmutationなど変化を感じさせる語源だから良いと思うけど

**デフォルトの名無しさん** · 2022/02/16(水) 13:58:05.68

>>237
ここのResult 型の説明で出てくるソースが理解しにくく非常に気持ち悪く汚く見えてしまいます
https://zenn.dev/mebiusbox/books/22d4c1ed9b0003/viewer/bba4b4

これを説明なしでソースだけでパッと流れがわかるなら優秀な人だと思います

**デフォルトの名無しさん** · 2022/02/16(水) 14:26:20.55

>>227
＞2020年の記事なんですけど
＞2020年が2年前な訳が無いんですけど

言ってることがわからないんだけど。
もしかして異世界からアクセスしてる人か？

**デフォルトの名無しさん** · 2022/02/16(水) 14:54:32.66

オッサンの時間の流れは早すぎて、もう2022年になったとは思えない
っていうジョークだろう

もうどうでもいいよ

**デフォルトの名無しさん** · 2022/02/16(水) 16:41:34.23

>>242
むしろResult型は美しく大元は数学の圏論のモナドから来ている
HaskellのMaybeモナド = ScalaのOption = RustのOption = 有か無かの二択
HaskellのEitherモナド = ScalaのEither = RustのResult = AかBかの二択
そしてRustではOptionもResultも値格納付きenum(＝タグ付きunion)で表現している

RustのResultもEitherと同じくAまたはBの二択にも使えるが
9割以上の使用方法では特に Aを正常値 Bを異常値(エラー値) として用いる
そのため enum型である Result<T,E> はタグOk(T) とタグErr(E) で構成されている
ここで Tは正常値の型T を示し Eはエラー値の型E を示している

つまり Result<T,E> は2つの型を合成して1つの新たな型として扱うことが出来る
これにより様々なエラー処理が非常に簡単となり各演算(and, or, 変換(map), default値)や
Resultを要素とするイテレータの各演算(map, filter, fold, collect)の各Result版を統一的に扱える

単純にエラー時に上位へエラーを伝播させる場合もRustでは単純となる
例えばGo言語では正常値valとエラー値errの多値で返し以下のようになる
　val, err := func()
　if err != nil {
　　return err
　}
Rustでは以下の「?」オペレータ1文字追加でよい
　let val = func()?;
ここでfunc()はResultを返しておりそれがエラー値Err(err)の時はその値で即return
そして正常値Ok(val)の時の処理のみに記述コードを専念できる

**デフォルトの名無しさん** · 2022/02/16(水) 18:27:24.16

>>245
そういうレベルの話じゃなくて単にパターンマッチの構文が見慣れないから読みづらいってだけだと思うよ
やってることはファイルをopenしてみて、失敗したらファイルを作成するってだけで何も難しいことはしていないので

**デフォルトの名無しさん** · 2022/02/16(水) 18:59:25.56

モダンな言語ならパターンマッチ構文とか当たり前だし、慣れるべきとしか思わんよな

**デフォルトの名無しさん** · 2022/02/16(水) 19:05:31.46

んなことはない
switchの中にswiｔｃｈ入れてる不気味なケースと同じで理解の妨げとバグの温床になっている

**デフォルトの名無しさん** · 2022/02/16(水) 19:06:54.11

そのうちmatchの中にmatch入れるな見たいなルールが出来て
それが当たり前になるｗ

**デフォルトの名無しさん** · 2022/02/16(水) 19:08:51.82

＞ Err(ref error) if error.kind() == ErrorKind::NotFound => {
ここが
Err(ref error.kind() == ErrorKind::NotFound) => {

こうなっていない時点でrustは汚い

**デフォルトの名無しさん** · 2022/02/16(水) 19:24:55.51

そもそもがさあ
他の言語のライブラリにあるファイルオープン時に指定したファイルがなければ作って開いてくれるようなオプションないのか？

**デフォルトの名無しさん** · 2022/02/16(水) 19:38:23.34

>>250
それこそクソ構文にしか見えないけど採用してる言語あるの？
Point(x, y) if 0 < x && x < 5 => {
みたいなガード条件書けなくない？

**デフォルトの名無しさん** · 2022/02/16(水) 19:40:31.24

C#とかだと複数のプロパティ値を使ったマッチングも当たり前にやっている

**デフォルトの名無しさん** · 2022/02/16(水) 20:09:46.22

>>250
Errはenum Resultのタグだからそれは理解が間違っている

>>251
無くても必要なら一瞬で書けるから困らない
例えば関数にするならこのようになる
fn open_or_create(path: impl AsRef<Path>) -> io::Result<File> {
File::open(&path)
.or_else(|err|
if err.kind() == ErrorKind::NotFound {
File::create(path)
} else {
Err(err)
}
)
}
このようにorを使う方が見やすく分かりやすい
matchでOk(x) => x, となったらorと覚えればよい

**デフォルトの名無しさん** · 2022/02/16(水) 20:25:14.55

なにかミスってない？

**デフォルトの名無しさん** · 2022/02/16(水) 20:58:53.96

C#はここ十年さわってないので分からんけど
> Err(ref error.kind() == ErrorKind::NotFound) => {
みたいに書けるってこと？
そもそもC#にパターンマッチなんかあったやろか？
switchがせいぜいあるだけでは？
あと型もletでdestructできるやつじゃなくて
せいぜい (変数 is 型) でシコシコ調べていくだけでは？

**デフォルトの名無しさん** · 2022/02/16(水) 21:00:56.89

>>250 のkind() は構造体のフィールドとのマッチじゃなくてメソッドの戻り値との比較だから
パターンとして取り扱えるようになるべきではないと思う
構造体のフィールドなら普通にパターンマッチできるよ

**デフォルトの名無しさん** · 2022/02/16(水) 21:07:22.97

>>251
File::options()
.write(true)
.create(true)
.open("hello.txt")
で済む話ではあるから例が微妙というのはあるかもね

**デフォルトの名無しさん** · 2022/02/16(水) 21:19:06.45

見返してみると
Err(ref error.kind() == ErrorKind::NotFound)ではなく

Err( ErrorKind::NotFound)
とかけたほうがいいなと

**デフォルトの名無しさん** · 2022/02/16(水) 21:25:48.26

上のソースは海外の有名なサイト？？？からほぼ丸パクリなんだな
そっちも突っ込みどころ満載のソースなんだけどパクったほうはさらにおかしくなってる

変なところだらけ
これとか
let f = File::open("hello.txt");
let f = match f {

それに引き続いたこれ
match File::create("hello.txt") {

そして
Err(e) => panic!("Tried to create file but there was a problem: {:?}", e),
と
これ
Err(error) => {
panic!("There was a problem opening the file: {:?}", error)
},

**デフォルトの名無しさん** · 2022/02/16(水) 21:30:10.73

>>256
ググればわかる
C#はもう全然別物になってるしこれからも変わる予定

誰得？と思うけど

**デフォルトの名無しさん** · 2022/02/16(水) 21:41:12.68

>>253
Rustでも複数マッチングは当然できる
例えばorの概念
let v = match (p, q) {
　(true, _) => "前者",
　(_, true) => "後者",
　(_, _) => "失敗",
};

>>255
matchをorで書き換えなら254で合ってる
目的達成だけならoptionsを使う258で合ってる

>>259
そういう単純なエラー型を自分で設計して使うならそれでOK
今回は std::io が返すエラーだから Err(struct io::Error { ...(フィールド非公開) }) となる
つまり Err(err) で受けて err.kind() で種別を取り出すことになる
なぜこうなっているのかは理由があるのでソース std/io/error.rs を読むべし

**デフォルトの名無しさん** · 2022/02/16(水) 21:51:01.16

>>260
その変数のシャドーイングも二段階のmatchもpanic!の使用もそれ自体は間違っていない
君は文句をつけることと間違った動かないコードを出すことしかできていない
こちらは改善案として二段のmatchではなくResultをorする>>254というシンプルで動くコードを示した

**デフォルトの名無しさん** · 2022/02/16(水) 23:07:11.77

視点がずれてる

変なところが多い=美しくないと言ってるんだけど
意味のあるシャドーイングならわかる
変数使って受けてるのに次ではmatchダイレクト

panicを一行で書いたりブロックをつけて書いたりちぐはぐ

書いた奴は馬鹿なんだろう

**デフォルトの名無しさん** · 2022/02/16(水) 23:09:17.43

クソど素人にこれだけ書かれるのは馬鹿なんだろうしそれも理解できないのはどうなんだ？

**デフォルトの名無しさん** · 2022/02/16(水) 23:12:09.22

批判だけならバカでもできる
具体的な代案を出せるかどうかが全て
これはどの世界でも同じ

**デフォルトの名無しさん** · 2022/02/16(水) 23:14:11.42

いやいや
何を例としてるか全然わかってなかったろ？

具体的に書かれて初めてわかったろ？
そういうところだよ
汚いソースすらわからないんだろ？

**デフォルトの名無しさん** · 2022/02/16(水) 23:18:14.63

rusｔ入門サイトにこんなクソみたいなコード乗せるな
Rustの品格が下がる

**デフォルトの名無しさん** · 2022/02/16(水) 23:18:35.44

>>267
こちらは具体的な代案を>>254に出した
君は文句をつけるだけで何も生み出せなかった
これが全てだ

**デフォルトの名無しさん** · 2022/02/17(木) 01:06:25.84

rustが汚いって話からサンプルコードが汚いって話にすり替わってるな

**デフォルトの名無しさん** · 2022/02/17(木) 08:14:31.32

>>257
>>250は単一化あたりを想定しているんだろ。
本来なら
Err(ref error),
error.kind() == ErrorKind::NotFound
か
Err(ref error) and
error.kind() == ErrorKind::NotFound
あたりだけど。

**デフォルトの名無しさん** · 2022/02/17(木) 08:14:54.96

もう十分だよ
初心者にありがちな「言語仕様が汚い発言」でしかないのがわかったからもういいよｗ

**デフォルトの名無しさん** · 2022/02/17(木) 23:22:49.91

彼は当初Rustの言語仕様が汚いと主張
それが無理筋だとわかると誰か個人が書いたサンプルコードが汚いと主張を変更
ところがそれも修正案すら示せず敗走か

**デフォルトの名無しさん** · 2022/02/18(金) 11:21:48.86

初心者にありがちな発言
「コンパイラのバグ」
「言語仕様が汚い」
「バリバリ書く」

**デフォルトの名無しさん** · 2022/02/18(金) 11:53:36.75

>>271
それ前者はパターンで後者は条件
だからRustのmatchの『パターン if 条件』がわかりやすい

**デフォルトの名無しさん** · 2022/02/18(金) 23:43:37.82

まだ富士山２合目な発言「美しい言語、感銘を受ける」「コンパイラが教師」「初心者にありがち」

**デフォルトの名無しさん** · 2022/02/19(土) 06:12:57.32

>>274
Objective-Cだけはマジ言語仕様汚ねーなって思った

**デフォルトの名無しさん** · 2022/02/19(土) 09:03:05.11

Objective-Cはちょっとしか触ったことないけどすこ
mac開発で使ってる人からすると欠点が見えてくるのかな？

**デフォルトの名無しさん** · 2022/02/19(土) 11:31:16.52

記号呪文のオンパレード

**デフォルトの名無しさん** · 2022/02/19(土) 12:43:55.20

Objective-Cは、あの突き抜けたキメラ感が好きかな。

**デフォルトの名無しさん** · 2022/02/19(土) 15:13:03.46

Obj-Cそんなに悪くないぞ
RubyのC拡張書いてる感覚に近い

**デフォルトの名無しさん** · 2022/02/19(土) 18:59:30.44

いつもの貼っておきますね

美しきObjectice-C
http://love-motif.com/article/art_13.shtml

**デフォルトの名無しさん** · 2022/02/19(土) 20:52:26.77

そういえばC#やってからJavaに触ると.NETフレームワークの設計が如何によく出来てるかを思い知る

**デフォルトの名無しさん** · 2022/02/19(土) 21:05:14.30

OSXが出てから一般向けの参考書が本屋に並ぶとか信じられないことになったが
昔は図書館の奥底まで潜らないと本が出てこなかったり
興味あるけどなんか手を出せる状況になかったなObjectice-Cは
linuxにgnustep入れてちょこちょこっとサンプル動かして満足してた
いやほんとAppleのおかげでだいぶ脚光当たったなマジで

**デフォルトの名無しさん** · 2022/02/19(土) 23:02:34.03

Obj-CはどうかしらんけどSwiftはまあ良いと思う
依存がでかいときのビルドはつらすぎだけど

**デフォルトの名無しさん** · 2022/02/20(日) 09:06:02.64

>>283
具体的にどういうところがでしょうか？
興味あります
1つか2つ例を挙げていただけると幸いです

**デフォルトの名無しさん** · 2022/02/20(日) 23:34:18.52

>>283
Javaの何と比較しての話？
標準ライブラリとか？

**デフォルトの名無しさん** · 2022/02/21(月) 03:36:10.49

そいつはC#おじさんだから触っちゃダメ、Goスレでも暴れてる

**デフォルトの名無しさん** · 2022/02/21(月) 15:07:07.57

波かっこによるブロックのため、
　　　　}
　　　}
　　}
　}
でディスプレイを無駄に占有されて可読性が減る事と
文末のセミコロン（C系）やコロン（Python等）強制で無駄にタイピング量が増えるのが嫌なのですが（強制でなければむしろ好き）、
あれらって、どんな魅力が有るのですか？
javascriptでデータ量を減らせて難読化できるメリットはわかりますが・・・・。
ちなみに自分は{}もpython.nimの様なインデントによるブロックで良いと思うし、
function()はfn()で良いし、println()はp()で良いし、arrayOf(1,2,3)は(1,2,3)で良いと思います。

**デフォルトの名無しさん** · 2022/02/21(月) 15:49:13.16

C言語の出始めは関数名とか省略していて可読性悪いとか言われてたなぁ。

**デフォルトの名無しさん** · 2022/02/21(月) 15:58:43.16

C言語が出る前からプログラミングしてたん？
すごい大先輩ですね