nim

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

**デフォルトの名無しさん** · 2022/12/17(土) 19:18:25.81

>>317
https://nim-lang.org/docs/genasts.html
https://github.com/nim-lang/Nim/pull/17426
https://github.com/nim-lang/RFCs/issues/122

**デフォルトの名無しさん** · 2022/12/22(木) 07:38:06.92

最初のrelease candidate for Nim v2.0が公開されました。
https://nim-lang.org/blog/2022/12/21/version-20-rc.html

**デフォルトの名無しさん** · 2022/12/22(木) 10:51:20.76

ペース早いよなあ

**デフォルトの名無しさん** · 2022/12/22(木) 10:52:43.57

nim-2.0 RC1 がリリースされた
https://nim-lang.org/blog/2022/12/21/version-20-rc.html

来年1月か2月には正式2.0になるのかも

**デフォルトの名無しさん** · 2022/12/23(金) 02:05:06.61

もう2.0かよ(´・ω・`)公開してるライブラリ大丈夫かな

**デフォルトの名無しさん** · 2022/12/23(金) 20:17:33.78

バージョンが大きく変わって大丈夫と思う方が
無理がある

**デフォルトの名無しさん** · 2023/01/16(月) 16:24:59.02

あっという間に2月

**デフォルトの名無しさん** · 2023/01/23(月) 22:52:56.91

書き込みが1ヶ月に1回しかないスレ w

**デフォルトの名無しさん** · 2023/01/26(木) 03:28:17.45

Nim言語を使っていても特につまづくことがないから話題があんまりないんだよね。

**デフォルトの名無しさん** · 2023/01/26(木) 18:39:32.28

使用者の絶対数が少なすぎ

**デフォルトの名無しさん** · 2023/02/01(水) 01:23:34.72

てすと

【だん吉】 · 2023/03/01(水) 09:22:10.73

!omikuji

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

初心者はys3mとかrs3mで十分

Ziicubeでys3m出た
1割引き価格後の値段

679円マグネット
1151円 Maglev
1623円 Boall-Core

https://www.ziicube.com/Moyu-333-HuaMeng-YS3M

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

>>330
誤爆

**デフォルトの名無しさん** · 2023/03/05(日) 11:11:16.11

WinnyとNimってネーミングセンス似てるね

**デフォルトの名無しさん** · 2023/03/05(日) 19:55:40.66

>>332
Nimは元々Nimrodっていう名前だったんだけどその由来は
https://forum.nim-lang.org/t/9591#63054

**デフォルトの名無しさん** · 2023/03/06(月) 14:19:57.93

https://www.cosme.net/product/product_id/10190076/top

**デフォルトの名無しさん** · 2023/04/03(月) 17:59:13.21

この言語ってRustみたいにプログラマに押し付けるmutなんて使ってないのに、なんでいわゆるMove操作が勝手に出来るの？
説明しろください！

**デフォルトの名無しさん** · 2023/04/03(月) 18:32:57.47

>>335
こちらの資料には目をとおされましたか？
https://nim-lang.org/docs/destructors.html

**デフォルトの名無しさん** · 2023/04/09(日) 09:29:43.33

Nim良いよね
Rustは宣伝がうざいだけだが
Nimは判ってる人の間でまったり進化してくれ

**デフォルトの名無しさん** · 2023/05/04(木) 21:15:01.62

公式読めばだいたいのことはわかるから特にここでも議論は出ないよね
唯一日本語の書籍がもう一冊くらい欲しいなあくらい

**デフォルトの名無しさん** · 2023/05/06(土) 09:24:18.50

importとincludeの違いってなに？

**デフォルトの名無しさん** · 2023/05/07(日) 06:11:02.39

>>339
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#import-statement
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#include-statement

**デフォルトの名無しさん** · 2023/06/28(水) 19:11:48.73

Nim言語 1.6.14 リリｰス
https://nim-lang.org/blog/2023/06/27/version-1614-released.html

**デフォルトの名無しさん** · 2023/07/02(日) 18:18:52.72

夜遅くにすいません。
SyntaxHilighter用のNim Brushってどっかにありませんか？

**デフォルトの名無しさん** · 2023/07/02(日) 18:34:57.51

>>342
話の内容が全然理解できないけど。。。

**デフォルトの名無しさん** · 2023/07/02(日) 21:16:17.65

>>343
ごめんなさい。
SyntaxHighlighter でした。

**デフォルトの名無しさん** · 2023/07/02(日) 21:56:05.97

>>344
SyntaxHighlighter っていうのがよくわからないけど
VSCode拡張とかのこと?

**デフォルトの名無しさん** · 2023/07/03(月) 07:33:58.97

>>345
えぇｴ～それぐらいネットで調べ「てく」ださいよ～～。
伝えるのめんど「い」し、説明上手くないからネッ-トで調べた方が絶対%絶対%にわかると思うんですよね。
お願いしますよ～～

**デフォルトの名無しさん** · 2023/07/03(月) 10:05:16.82

>>346
うわぁ～
怖い

引っ込んでます

**デフォルトの名無しさん** · 2023/07/03(月) 12:35:43.48

>>347
恐がらせてごめん。

**デフォルトの名無しさん** · 2023/07/04(火) 04:16:26.79

Nim言語はコンパイル時にreadFileとwriteFileを使えるんだけどコンパイル時にファイルを読み書きできるプログラミング言語ってあまりないんじゃないか?
staticExecていうコンパイル時にコマンドを実行できるプロシージャもあるし。

**デフォルトの名無しさん** · 2023/07/07(金) 02:08:00.59

どっかで既出かもしれんけど、結局VSCの拡張は何入れれば安牌？

**デフォルトの名無しさん** · 2023/08/01(火) 18:27:12.50

https://github.com/nim-lang/Nim/releases/tag/v2.0.0

**デフォルトの名無しさん** · 2023/08/02(水) 00:52:58.78

Nim 2.0がリリースされました。
https://nim-lang.org/blog/2023/08/01/nim-v20-released.html

**デフォルトの名無しさん** · 2023/08/26(土) 23:20:45.36

初めてお邪魔します

下のスレッドでフィボナッチ数列(回帰関数)のベンチマークをやったのですが
Nim 2.0がダントツの速さでした

原因が分かる方、教えていただけますでしょうか、よろしくお願いいたします

Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/368-371
https://mevius.5ch.net/test/read.cgi/tech/1685235361/373-375

上記スレ、fibonacci(44)の計算、抜粋

Nim(44はコマンドライン引数)
https://wandbox.org/permlink/WoYP0STRKxaRBGCY
>Time= 0.240s Result=701408733

C/gcc(44はソース直書き)
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang(44はソース直書き)
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

**デフォルトの名無しさん** · 2023/08/27(日) 00:54:05.78

>>353
Nimでコンパイルするときに'--listcmd'オプションを与えるとNimがgccを呼び出すときにどんな引数を渡しているか表示されるようになります。
もしかすると凄く最適化されるようなオプションを渡しているのかもしれません。

**デフォルトの名無しさん** · 2023/08/27(日) 01:58:10.81

>>354
早速の回答ありがとうございます

wandboxのspeedだとO3が見られたので、nim.cfgに gcc.options.speed = "-O2" を追加してついでに-d:ltoも外しました

Nim 2.0.0 + gcc 12.2.0(-O2) --verbosity:2 --listcmd --passL:-s (strip symbols)
https://wandbox.org/permlink/RVJ4eHKKl5DARK3u

>CC: prog.nim: /opt/wandbox/gcc-12.2.0/bin/gcc -c -w -fmax-errors=3 -O2 -I...
>Hint: /opt/wandbox/gcc-12.2.0/bin/gcc ... -lm -lm -lrt -s -ldl [Link]
>Hint: mm: orc; opt: speed; options: -d:danger

>Time= 0.274s Result=701408733
>Time= 0.252s Result=701408733
>Time= 0.251s Result=701408733
>Time= 0.250s Result=701408733
>Time= 0.250s Result=701408733

今度は確実に LTO無し gcc -O2 になりましたが、実効速度はダントツに速いままでした
何か気が付く点がありましたらまた今度教えてください (私の方は今日は限界です...)

**デフォルトの名無しさん** · 2023/08/27(日) 17:22:00.42

>>355
Nim言語が高速なのはC言語コードを吐き出した時に
再帰処理をgotoループに置き換えている可能性があります
その場合C言語のオプションをいくら変更してもあまり意味はない
です

確認はコマンドライン引数に --nimcache:.cache を加えて
コンパイルして.cacheフォルダ内のC言語ファイルを確認すれば
わかるはず

nim c --nimcache:.cache -d:release ...

-d:relsese の部分は -d:danger で置き換え可能で
dangerのほうが高速です

詳細はここ
https://nim-lang.org/docs/nimc.html

コンパイル型言語のベンチを取る時は再帰処理コードは
避けた方が良いと思います

**デフォルトの名無しさん** · 2023/08/27(日) 17:25:13.06

>>356 追記
末尾再帰になっている可能性もありかな

**デフォルトの名無しさん** · 2023/08/27(日) 22:36:37.59

Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
gccは再帰関数をループに置き換えているかもしれないからその確認をしたかったら-S -masm=intelを付けてアセンブリコードを出力させて読んでみよう。

**デフォルトの名無しさん** · 2023/08/28(月) 06:30:35.88

>>356
変換キャッシュの見方、ありがとうございます

>再帰処理をgotoループに置き換えている可能性があります
確認したところ、置き換わっていませんでした

>コンパイル型言語のベンチを取る時は再帰処理コードは
>避けた方が良いと思います
↑ここ詳しくお願いします

>再帰処理をgotoループに置き換えている
↑こうなっていませんでしたが、これ前提での話だったのですか?

再帰fibonacciは個別の言語コンパイラ(更にバージョン)の
最適化ベンチマークには持って来いに見えますので

**デフォルトの名無しさん** · 2023/08/28(月) 06:40:36.37

>>358
>Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
その通りでした

確かめたところ二つの再帰関数コールがそのまま残っていて、
その他はNimのトランスパイル過程でのノイズがあるだけです

gccがノイズを消すために最適化を頑張った結果、Cより速くなったのですかね

**デフォルトの名無しさん** · 2023/08/28(月) 06:47:48.48

何気にNim + gcc HEADにしてみたら、更に速かったです

Nim 2.0.0 + gcc 12.2.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/RVJ4eHKKl5DARK3u
>Time= 0.250s Result=701408733

これ↑がこう↓

Nim 2.0.0 + gcc HEAD 14.0.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/cpYesJtnlRNJiu7Z
>Time= 0.197s Result=701408733

参考値再掲(>>353)
C/gcc -O2 (44はソース直書き)
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang -O2 (44はソース直書き)
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

gccの最適化が凄すぎて意味わからないですが、ありがたく享受する事にします

**デフォルトの名無しさん** · 2023/09/06(水) 06:10:42.54

レバテックωωω
Rust in
Nim out
ωωωωωω

**デフォルトの名無しさん** · 2023/11/15(水) 08:06:37.71

>>349
F#が、 F# Dataってライブラリで、コンパイル時に
ファイルの読み取りは、やってたけれど、あまり見かけないね。

**デフォルトの名無しさん** · 2023/11/28(火) 09:23:46.10

happyxってdjungoの上位互換なれねーかな
https://hapticx.github.io/happyx/#/

**デフォルトの名無しさん** · 2023/12/06(水) 09:31:30.20

>>363
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

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

Nim って python を強調し過ぎてるのはミスリードだと思うな
python と相性が良いってのは事実だけど Nim の特徴のほんの一部でしかない

**デフォルトの名無しさん** · 2023/12/08(金) 21:38:37.62

>>366
Python使える人が多いからNimを広めるためにNim言語はpythonと同じだという人は多い。
文法がpythonに近いだけで中身は静的型言語だからpythonよりC++とかRustに近いと思う。
pythonしか知らない人がNimのオーバーロードとかGenericsとかobjectとref objectの違いとかちゃんと理解して使えるのかどうか心配になる。

**デフォルトの名無しさん** · 2023/12/10(日) 11:41:19.18

「文法がpythonに近い」が事実じゃないんだよな
観た目が似てるだけであって文法が似てる訳じゃない
全然別物

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

そういう意味では構文で結構損してそう
オフサイドルールが気に入らない人にとってはそもそも検討に値しないし
Python好きな人ならそこは気にならないだろうけど、別に移行しやすくもない

**デフォルトの名無しさん** · 2023/12/11(月) 04:52:12.28

>>369
でも静的型言語でオフサイドルールの言語はNimとcrystal以外あまりないのでは。
オフサイドルールが好きで型システムがちゃんとしていて高速に動くプログラムを書きたい人にはぴったり。

**デフォルトの名無しさん** · 2023/12/11(月) 06:10:19.79

型で安全性を静的に担保したいと考える人が、同時にインデントで意味が変わってしまうオフサイドを好むってのはちぐはぐさを感じる

**デフォルトの名無しさん** · 2023/12/11(月) 06:46:36.74

HaskellとデフォルトF#もオフサイドルールありですね。どうせインデントするんだしって使ってやれってくらいの感じなのかね？

あとは、インデントに意味はないけれど、goが標準のフォーマッタでインデント入れてくるね。

**デフォルトの名無しさん** · 2023/12/11(月) 06:54:57.74

Python登場当時だと{}前後のどこで改行するか論争みたいなのがあったりして確かに括弧書くのが面倒な空気はあったんだよな
それがGo/Rustの世代だと言語標準のフォーマッタが勝手にやってくれるってなって
めんどくさくないっていうオフサイドのメリットはなくなってしまった
そうすると自動フォーマットしづらいとかコピペしづらいとかデメリットばかり目立つことになってしまう

**デフォルトの名無しさん** · 2023/12/12(火) 04:50:08.02

ブロック毎に'{}'や行末に';'があるとソースコードが少し汚く見えるし
無いとすっきりして読みやすいと思うけどね。

**デフォルトの名無しさん** · 2023/12/12(火) 05:58:22.17

そんなの単なる慣れ

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

まぁ人によるんじゃない
自分は{}がある方がブロックの識別性が良くて読みやすい
オフサイドは特にネストしたブロックの戻りが何段戻ったか見づらいんだよな

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

カッコありなら、lisp系が好き。
悩む事が減る。

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

>>374
セミコロンはオフサイドルールじゃなくてもRuby/Go/Kotlin/Swiftのように無しできるから関係ないよね

それにセミコロンをタイプするのは面倒だとは思うが慣れると読む時のノイズにはならない
自然言語の文章で句点やピリオド+改行がノイズにならないのと同じこと

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

CやC++を10年以上使っていたけど';'や'{}'が無いほうがすっくりして読みやすいと思うから慣れでどうにかなるものでは無いと思う。
こういうのは個人差があるのかもしれないが

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

ttps://github.com/jeetsukumaran/vim-indentwise
このVimのプラグインを使うと同じインデント間のカーソル移動、異なるインデント間のカーソル移動が簡単にできるからお勧めです。

**デフォルトの名無しさん** · 2023/12/12(火) 22:53:30.64

>>379
CやC++やっててそんなこと言うやつ初めて聞いたぞ
本当に日々コード書いてる？

**デフォルトの名無しさん** · 2023/12/12(火) 23:44:06.92

そりゃ仕事で使える言語でオフサイドルールなのってPythonくらいだし
ほんとはオフサイドがいいけどC/C++の仕事してるって人くらいいるでしょ

**デフォルトの名無しさん** · 2023/12/13(水) 00:18:56.36

>>382
{}や;がノイズになるかどうかと
オフサイドがいいかどうかの話は別だよ

**デフォルトの名無しさん** · 2023/12/13(水) 04:42:50.35

>>381
今はC/C++殆ど書いてないけど以前はほぼ毎日使ってたよ。
{}や;に慣れてもやっぱり余計な文字が少ない方がすっきりして読みやすいと思うのだが、そういう人は少数派なんかな?

**デフォルトの名無しさん** · 2023/12/13(水) 05:36:33.39

主観で読みやすいかどうか力説しても結論でるわけない
オフサイドは誤ってインデントずれても気付かないままになってしまうのが問題

**デフォルトの名無しさん** · 2023/12/13(水) 06:48:31.89

>>384
まぁ実際オフサイド採用の新規言語ってあまり出てこないし
少数派なんじゃないかな

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

f#みたいに、使う側が選択できれば、解決なんじゃない？

**デフォルトの名無しさん** · 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