nim

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

https://nim-lang.org/

**デフォルトの名無しさん** · 2023/12/13(水) 07:35:42.19

やれやれお前らCOBOLを知らんのか

**デフォルトの名無しさん** · 2023/12/13(水) 11:38:44.64

>>384
どちらの方がすっきりして読みやすいかと
{}や;が思考ノイズになるかどうかは別だよ

前者はそれなりにいる
後者はツチノコレベルで稀有

**デフォルトの名無しさん** · 2023/12/14(木) 19:26:43.32

エディタの色設定で{};を薄い色にすればいいだけやん

**デフォルトの名無しさん** · 2023/12/15(金) 03:05:56.17

{}がノイズになるようなら:や=はもちろんのことblock:なんて発狂ものだろうからNimは無理やろな

**デフォルトの名無しさん** · 2023/12/15(金) 05:55:25.21

思考ノイズって
エロい事連想してるって意味だよな？

**デフォルトの名無しさん** · 2023/12/15(金) 06:50:06.26

Nimってオフサイドルール以外の所は目立った欠点の無い言語なんかな。
それに実際にオフサイドルールでコードを書いていて困ったことないし。
インデントがずれても困るという人はインデントの幅をスペース4個とか広めにすればいいのでは

**デフォルトの名無しさん** · 2023/12/15(金) 17:55:10.13

オフサイドルールは欠点だらけ

Pythonを例にすると
- カットペーストは命がけ
- ネット等で共有しにくい
- テキストエディタやIDEの支援が激弱
- dedentは手動タイピング必須
- 改行のために追加の()や\が結局必要
- インデントだけでは可読性が低いから余計な:が必要
- 空行の数まで厳密に意識する必要もある
- lambdaのone expression縛りのように言語の成長を阻害しやすい
- “explicit is better than implicit”と言いながらブロックはimplicit

**デフォルトの名無しさん** · 2023/12/15(金) 18:18:19.69

次は、良い点を挙げてみて！

**デフォルトの名無しさん** · 2023/12/15(金) 18:24:50.43

>>395
プログラミング初心者を釣れる
以上

**デフォルトの名無しさん** · 2023/12/15(金) 20:46:34.27

Vim使ってるけどコピペは問題無くできるしインデントの深さもブロックごと'>'で調整できる。
vim-indentwiseでブロック毎カーソル移動可能。
スペース一個分だけでインデントするとかしない限りブロックの開始、終わりは前後の行のインデントの位置の違いでわかる。
vim-indentwiseでカーソル移動すればブロックの範囲も簡単にわかる。
以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。
Nim書いていて改行のために追加の()や\が必要になることはほぼ無い
空行の数を厳密に意識する必要もない。
Nimを実際に書いたことあるの?

**デフォルトの名無しさん** · 2023/12/15(金) 21:02:40.08

https://wandbox.org/permlink/Nfe6exUFmtWPdWZj
NimのAnonymous proceduresでは複数行書けるし
こうしてコードを共有できてる。

**デフォルトの名無しさん** · 2023/12/15(金) 22:17:03.24

>>398
でもアロー関数にすると()を追加するなどしないと1行しか書けなくなる
これもオフサイドルールのせい
しかもこんな明らかなバグでも修正しようともしない
言語の成長を阻害するとはこういうこと

**デフォルトの名無しさん** · 2023/12/15(金) 22:29:33.41

>>397
論点理解せずにvim使いなら誰でも知ってる基本を必死に解説されても困るわ

>以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。
{}や;が無くて読みづらいとか書きづらいとか誰もそんなこと言ってないだろ？
勝手に脳内変換するなや

ついでに言うとセミコロン無い方が書きやすいのは当たり前のこと
だから新しい言語の多くがセミコロンレスを採用してる(オフサイドは採用しないけど)

**デフォルトの名無しさん** · 2023/12/15(金) 23:45:28.85

>>399
アロー関数ってNimのsugarモジュールにある`=>`マクロのこと?
あくまでこの=>は二項演算子だから両辺は式になっていないといけない。
オフサイドルールに関係無く二項演算子の両辺に文を直接書けず式を置かないといけないのは殆どのプログラミング言語で同じじゃない?
複数文を書きたければanonymous procedureで書けばよいし。
オフサイドルールじゃない言語で無名関数に複数文を書くときは必ず{}で囲む必要があるし。
どうしてこれが言語の成長を阻害していることになるの?
明らかなバグなのに修正しようとしないって言うけどGithubのNimのリポジトリにそういうissueある?
無名関数を書くときはdo notationというのもあるよ。
https://nim-lang.org/docs/manual.html#procedures-do-notation

**デフォルトの名無しさん** · 2023/12/16(土) 08:47:38.44

「vimを使えばいい」とか「無名関数を使えばいい」などと列挙されても
他の言語はそんな特別なケアなしに使えるわけでな…
このあたりがいまいち広まらない原因なんじゃない？

**デフォルトの名無しさん** · 2023/12/16(土) 08:53:10.18

以前インデントの代わりに{}を使える機能があったようだ。
https://github.com/nim-lang/Nim/commit/10bd488daafa79f52fec0d5e7ea76ec8d5902465
https://forum.nim-lang.org/t/10730#71570

けれども殆ど使われなかったのと、{}があるとgrammarとparserが発展するのが難しくなるので削除されたらしい。
https://forum.nim-lang.org/t/10349#68930

**デフォルトの名無しさん** · 2023/12/16(土) 09:38:42.94

>>402
現代では高機能なテキストエディタやIDEが使えるから
それを使うことを前提にプログラミング言語をデザインしたらいいんじゃね?
って話は聞いたことがある。

sugarの`=>`マクロはNim言語のanonymous procedureを特定の条件下で簡単に書けるよう作られたもので完全にanonymous procedureを置き換えられるものでない。
sugarモジュール自体がシンタックスシュガーのようなものを提供するマクロなどを集めたものだし。
制限とか気にせずにanonymous procedureを書きたかったら=>を使わずに書くしかない。

**デフォルトの名無しさん** · 2023/12/16(土) 09:56:43.39

>>404
そのへんがまさに省略記法の悪い点が出てる感じするな
省略するってことはソースコードの情報量は減っていて、それはタダではない
「OOのときにはXXを使う」みたいな規則がたくさん発生するというコストがあるんだよね
これはセミコロンレスもそうで、時々変なエッジケースが発生したりする

**デフォルトの名無しさん** · 2023/12/16(土) 16:45:38.17

オフサイドルールと違ってセミコロンレス(optional semicolon)は多くの言語で妥当なトレードオフ
オフサイドルールが妥当なトレードオフとして成立してるのはHaskell系の言語くらい

**デフォルトの名無しさん** · 2023/12/16(土) 20:00:00.36

なんかどうでもいいことをいつまでも
うじうじと

気に入らないなら使わなきゃいいだけ
気に入ったら使えばいいだけ

**デフォルトの名無しさん** · 2023/12/17(日) 07:10:31.29

>>407
気に入っていても：
　　ある日突然：
　　　　気に入らなくなる事ってあるよね？
気に入らなくても：
　　ちょっとしたきっかけで：
　　　　すごく気に入ってしまうことも
　　　　あるよね？

そういう時はどうすればいいの？

**デフォルトの名無しさん** · 2023/12/17(日) 12:19:34.98

>>408
>　　　　すごく気に入ってしまうことも
>　　　　あるよね？
Error: invalid indentation

**デフォルトの名無しさん** · 2023/12/17(日) 18:41:59.56

Nimはよく考えずに機能追加して既にC++並みに複雑化してる
目新しさだけで飛びつくと後悔するぞ

**デフォルトの名無しさん** · 2023/12/18(月) 02:13:02.65

そうなの？　じゃあもうC++でいいじゃん

**デフォルトの名無しさん** · 2023/12/18(月) 08:55:26.31

例えば最近実装している変更についてもちゃんとここに理由とか書いてあるよ。
https://github.com/nim-lang/RFCs/issues/516
このあたりをよく読めばちゃんと考えて機能を実装していることがわかるよ。
https://github.com/nim-lang/RFCs/issues
https://github.com/nim-lang/Nim/pulls
Discord/Nimのinternalチャンネルをときどき読んでるけど
開発者は論文読んだり他のプログラミング言語の機能を調査しているようだよ。
https://en.cppreference.com/w/cpp
と
https://nim-lang.org/docs/manual.html
を読み比べてみればわかると思うけどC++のほうがはるかに複雑だよ。

**デフォルトの名無しさん** · 2023/12/18(月) 20:40:29.88

Nim言語がどのような考えで設計されたか知りたい人はNimのblogを読むといいよ。
https://nim-lang.org/araq/
https://nim-lang.org/blog.html

**デフォルトの名無しさん** · 2023/12/18(月) 20:49:37.54

Nimの現状を知りたい人はこれを読むといい
https://forum.nim-lang.org/t/9145

**デフォルトの名無しさん** · 2023/12/19(火) 00:16:35.74

議論をよく読めば何やらちゃんと考えて実装しているらしいのはC++も同じなんだよなあ

**デフォルトの名無しさん** · 2023/12/19(火) 08:00:58.06

>>415
単純に >>410 への反論なだけじゃない？

**デフォルトの名無しさん** · 2023/12/20(水) 12:37:14.01

バグ修正版のNim 2.0.2と1.6.18がリリースされました。
https://nim-lang.org/blog/2023/12/19/versions-1618-202-released.html

**デフォルトの名無しさん** · 2023/12/23(土) 09:16:16.92

寂しいスポンサーページだな😢
https://nim-lang.org/sponsors.html
こりゃnimが普及しないのも当然か
rustとは大違い
https://foundation.rust-lang.org/members/

**デフォルトの名無しさん** · 2023/12/23(土) 10:35:51.40

でもRustは誰も使ってないじゃん

**デフォルトの名無しさん** · 2023/12/23(土) 11:58:51.47

Rust言語はトヨタ自動車が採用してると
どこかで読んだ

**デフォルトの名無しさん** · 2023/12/23(土) 13:41:38.19

>>419
誰も使ってないは草

**デフォルトの名無しさん** · 2023/12/23(土) 13:46:35.58

Nimと書き間違えたんだと思うが

**デフォルトの名無しさん** · 2023/12/23(土) 18:13:17.30

Nimを使っている組織のリスト
https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim

**デフォルトの名無しさん** · 2023/12/27(水) 19:41:58.29

プログラムをビルドするためにC++だったらCMake、Rustだったらcargo.tomlにTOMLを使う。
Nimだったらconfig.nimsも.nimbleファイルもNim言語で書ける。
一つの言語でコンパイル言語としてもスクリプト言語としても使えて便利。
Nimはマクロやconstなどをコンパイル時に実行するためにVM使ってるんだけど、そのVMを使ってNimをスクリプト言語のように実行できるらしい。

**デフォルトの名無しさん** · 2023/12/27(水) 19:50:00.04

rustも複雑なことをしようと思ったらbuild.rsに書けるけど、それはそうとして依存関係をプログラム言語で書きたいかと言われると

**デフォルトの名無しさん** · 2023/12/27(水) 20:16:43.40

あれもこれもできて便利！みたいなのはぱっと見良さそうでも
大規模・多人数・長期開発になると負債になりがちではある

**デフォルトの名無しさん** · 2023/12/27(水) 20:24:29.72

happyxが起爆剤にならないかなぁ、、🙏

**デフォルトの名無しさん** · 2023/12/27(水) 23:05:07.37

zigなら全部zigで書ける（便乗）

**デフォルトの名無しさん** · 2023/12/27(水) 23:27:30.38

一体なにがエレガントなんだろうなこの言語って

**デフォルトの名無しさん** · 2023/12/27(水) 23:34:47.36

まあアイコンはエレガントなんじゃない？王冠だし

**デフォルトの名無しさん** · 2023/12/27(水) 23:51:57.04

procとmethodとfuncを使い分けつつ{.global.}や{.async.}なとの{.pragma.}とmacroでぐちゃぐちゃにかき混ぜられるのが超エレガントw
他の言語では類を見ない

**デフォルトの名無しさん** · 2023/12/28(木) 22:46:05.11

エレガントすぎてついていけないわ

**デフォルトの名無しさん** · 2023/12/28(木) 23:18:44.60

エレガントすぎてついていけないわ

**デフォルトの名無しさん** · 2024/02/20(火) 19:40:26.76

新年の記念保守

**デフォルトの名無しさん** · 2024/06/17(月) 22:36:28.67

https://nim-lang.org/blog/2024/06/17/version-206-released.html
Nim version 2.0.6がリリースされました。

**デフォルトの名無しさん** · 2024/10/04(金) 21:03:40.29

https://github.com/kostya/benchmarks#primes
から派生させた、Atkin Sieveベンチマーク
計算本体だけの計測に改め、更に桁を増やし、途中計算がオーバーフローしないように関係変数はすべて64bit
UPPER_BOUND: 500_000_000

Zig 1912ms
g++ 1916ms
Nim 1920ms gcc
Nim 1969ms clang
clang++ 2151ms
Rust 2411ms overflow-checks = false
Rust 2430ms overflow-checks = true

Zigが速かったので他は色々と変更した
Zigの変更は最小限なので再現検証をする場合は各自のZig計測値を基準にしてください

**デフォルトの名無しさん** · 2024/10/04(金) 21:11:00.73

特にデータ構造で
Nim seq[bool]
Rust Vec<bool>
は遅いので直ぐに取り換えてください
C++のvector<bool>は最適化がされていますが、最終的に別のものにしました

**デフォルトの名無しさん** · 2024/10/04(金) 21:12:20.19

>>436は取り換えた後の計測値です