◎正当な理由による書き込みの削除について:      生島英之とみられる方へ:

nim ->画像>1枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/tech/1519896738/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1デフォルトの名無しさん
2018/03/01(木) 18:32:18.16ID:vh/yy2VS
https://nim-lang.org/
2デフォルトの名無しさん
2018/03/01(木) 20:11:33.86ID:waYC8XnL
3デフォルトの名無しさん
2018/03/01(木) 22:14:19.93ID:73H1EZrd
nimは確かにいいものだけど
どこかのバックアップがないと廃れる
4デフォルトの名無しさん
2018/03/03(土) 13:00:41.35ID:hv+J7voV
Nim は未だに 1.0 にもならないからな。
5デフォルトの名無しさん
2018/03/04(日) 00:13:26.42ID:dfYa5r5g
rustよりこっちは流行ってほしい
6デフォルトの名無しさん
2018/03/12(月) 11:04:45.99ID:7HjR7SCF
https://nim-by-example.github.io/variables/result/
resultの説明こんだけじゃよくわかんないな
なんで0なの
7デフォルトの名無しさん
2018/03/12(月) 11:26:51.87ID:34p9aq3f
var でresult上書きしちゃったから本来のresultは初期値のままなんじゃない?
8デフォルトの名無しさん
2018/03/27(火) 01:06:06.14ID:z3LtWtNM
0.18の次は1.0?
9デフォルトの名無しさん
2018/03/29(木) 18:55:17.89ID:xuG7sIN3
Rustは使い道が全然違うのでは
競合相手を挙げるとすればDとKotlinかな?
10デフォルトの名無しさん
2018/03/29(木) 20:05:34.60ID:mREgEFij
Dは死んでるし、KotlinはJVMだからちょっと違う
うん。安泰だな
11デフォルトの名無しさん
2018/03/30(金) 15:03:59.86ID:husdvr0W
にむにむ
12デフォルトの名無しさん
2018/03/30(金) 17:20:25.17ID:LkNluKW0
にむにむ
13デフォルトの名無しさん
2018/04/13(金) 11:18:25.98ID:1FEv2TtX
windowsはなぜかmingwじゃなくてVCベースがデフォルトになってるんだよな
mingwのほうがつぶし効きそうなのに
14デフォルトの名無しさん
2018/04/22(日) 21:27:36.51ID:guTpWN67
nim 	->画像>1枚
15デフォルトの名無しさん
2018/05/23(水) 19:59:41.53ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

D0A0C
16デフォルトの名無しさん
2018/06/22(金) 00:41:37.96ID:YRNyKvjT
Nintendo switch support
https://github.com/nim-lang/Nim/pull/8069

devkitproとかなつい
17デフォルトの名無しさん
2018/06/22(金) 07:50:35.79ID:B4dYVWwz
tcc 使えないからやめた。
18デフォルトの名無しさん
2018/06/22(金) 16:26:06.96ID:1kLq6NEC
tcc使ってビルドしてもたいして最適化されないから使えない
PC用途ならビルドが速いのが唯一のメリットだな
19デフォルトの名無しさん
2018/06/22(金) 19:01:13.51ID:ypfKNoQc
nimに追い風来た?
20デフォルトの名無しさん
2018/06/22(金) 20:19:33.22ID:pFncXrHB
【王様きどり、〝財界″】 マイトLーヤ『人々はもう特定の主義を認めない、政治的教化は通用しない』
http://2chb.net/r/liveplus/1529634259/l50


共産でも、資本でもない、分ち合い経済が、登場します!
21デフォルトの名無しさん
2018/06/24(日) 16:08:44.05ID:UA2S6a/y
単なるCトランスパイラ。
糞スレ終了。
22デフォルトの名無しさん
2018/06/24(日) 16:30:04.61ID:qqy2wX7I
そのCトランスパイラでnim作ればいいんじゃね?
23デフォルトの名無しさん
2018/06/24(日) 23:45:55.72ID:5Eh2Uv5P
LLVM に対応しないのかね?
わざわざCを介すとか面倒くさい。
24デフォルトの名無しさん
2018/06/25(月) 00:12:53.47ID:fFB+k9lh
LLVMに対応しても使う側の手間は変わらない
25デフォルトの名無しさん
2018/06/25(月) 01:50:01.01ID:vYusjqJa
IDE何使っておられますかみなさん
26デフォルトの名無しさん
2018/06/25(月) 07:53:35.56ID:TJ656l8P
>>24
そうかね?
まあ、ネイティブコンパイルしてくれればいいことだけど。
別に速度は求めないからインタプリタでもいい。
27デフォルトの名無しさん
2018/06/30(土) 22:10:29.30ID:6gscpOJh
>>23
https://github.com/arnetheduck/nlvm
28デフォルトの名無しさん
2018/07/04(水) 22:00:55.44ID:gFgZc5FG
ED5
29デフォルトの名無しさん
2018/07/05(木) 07:27:55.02ID:2S42hYSo
vim使ってるよ
30デフォルトの名無しさん
2018/08/21(火) 15:32:54.75ID:EBgi8cvd
1.0、juliaに先越されたな
31デフォルトの名無しさん
2018/09/23(日) 12:32:55.25ID:x0iYh9VU
見た目だけはpythonとrubyの愛の子っぽいけど
気持ち悪いな

慣れると気持ち良くイケるのかな
32デフォルトの名無しさん
2018/09/23(日) 12:36:43.12ID:Su1i+ANF
>>21
どっちかというと tcl/tk
33デフォルトの名無しさん
2018/09/28(金) 00:10:24.24ID:sUTKRE9a
>>30
AV女優?
34デフォルトの名無しさん
2018/09/28(金) 07:58:16.83ID:d9qseECH
>>33
わかってていってんだろ
35デフォルトの名無しさん
2018/09/28(金) 12:33:53.60ID:mIB0sZTe
Version 0.19.0がリリースされました。
https://nim-lang.org/blog/2018/09/26/version-0190-released.html
36デフォルトの名無しさん
2018/09/28(金) 15:46:07.59ID:O5kQkBkV
GUI は何がおすすめ?
37デフォルトの名無しさん
2018/09/30(日) 18:50:57.10ID:qKTW85vs
math モジュールの round バグってんな
こんなのもバグってるとか使い物にならないだろw
38デフォルトの名無しさん
2018/10/01(月) 07:05:34.25ID:tIZ5XrDW
roundに関してはNimのgithubのissueにもあるんだけど、floatの精度のせいでroundした値がfloatで正確に表せられない場合があるんだよ。
https://github.com/nim-lang/Nim/issues/9082
詳しく知りたかったら、現代の殆どのPCで浮動小数点数を扱うのに使われているieee754という標準規格について調べてね
39デフォルトの名無しさん
2018/10/06(土) 22:16:11.18ID:M6XEBHaV
echo(convert("こんにちは、", "Shift_JIS", "UTF-8"))
Windowsだとこうしないと日本語が表示されない
40デフォルトの名無しさん
2018/10/06(土) 22:34:07.06ID:Dokqbc8P
ソースと端末表示をUTF-8にすればいいだけじゃ
41デフォルトの名無しさん
2018/10/07(日) 00:51:21.65ID:o9Iuox3H
windowsでシステムロケールUTF-8にしたい
chcp65001は禁止で
42デフォルトの名無しさん
2018/10/09(火) 21:51:59.30ID:017c3dVj
readline(stdin)が多バイト文字を受け付けない
43デフォルトの名無しさん
2019/04/17(水) 04:51:18.35ID:X6FO3pO6
つんつん
44デフォルトの名無しさん
2019/04/17(水) 13:09:18.13ID:q/9NxBQE
nim終了のお知らせ

Bosque Programming Language
https://www.microsoft.com/en-us/research/project/bosque-programming-language/

> The Bosque programming language is designed for writing code that simple, obvious, and easy to reason about for both humans and machines.

https://github.com/Microsoft/BosqueLanguage
45デフォルトの名無しさん
2019/04/17(水) 18:38:09.52ID:TZqApRQS
なんやわからんけど波括弧書くのいやや~
46あめ ◆P0jSlC5fJs
2019/04/17(水) 18:54:10.48ID:FVq2Eq3K
>>44
研究用、ゴミ
ドザによる荒らし
47デフォルトの名無しさん
2019/04/17(水) 21:27:04.52ID:4b8gWp/i
うるせーよ雑魚コテハン
48デフォルトの名無しさん
2019/04/17(水) 21:27:30.51ID:TZqApRQS
雑魚コテハンは死ねや
49 ◆P0jSlC5fJs
2019/06/08(土) 18:55:31.57ID:TM/rrlxa
0.20.0 リリース
https://nim-lang.org/blog/2019/06/06/version-0200-released.html
50デフォルトの名無しさん
2019/06/17(月) 03:05:34.50ID:7cCtTFkx
開発が止まっているLuaJITの代わりにこれを使いたい
51デフォルトの名無しさん
2019/06/18(火) 05:06:07.86ID:DNE6sIuH
じゃ使えばいいじゃん。
52デフォルトの名無しさん
2019/06/18(火) 11:00:03.52ID:6YVmUs6+
nimがCにトランスパイルできるとしても
nimを通してクラス設計とかしたらその分のオーバーヘッドは残りますよね?
53デフォルトの名無しさん
2019/06/18(火) 12:35:30.19ID:1CtlGReK
そもそもそういう用途じゃない
54デフォルトの名無しさん
2019/06/18(火) 12:45:57.35ID:6YVmUs6+
どういうことですか?
C並の性能を出すためにあるものではないと?

Nimでカーネルを書くとか無理なのかなーと思ってたんですが
実際やるわけじゃないけど、いまのところ
55デフォルトの名無しさん
2019/06/18(火) 12:48:21.44ID:1CtlGReK
C++でカーネル書いたひとはいるね
56デフォルトの名無しさん
2019/06/18(火) 14:22:47.46ID:6YVmUs6+
実際Linuxカーネルのコードは疑似OOPだみたいな説明を見かけたので
NimやC++で書いても良いのかもしれない。
個人的にCへのトランスパイラとしてのNimにひじょーに興味がある
57デフォルトの名無しさん
2019/06/18(火) 14:25:52.94ID:6YVmUs6+
https://forum.nim-lang.org/t/2261
>So let's say that implementing your game in Nim instead of C++ means 20% larger binary sizes, 20% more RAM usage, and 20% more CPU/GPU usage.

NimよりC++の方が速いって言ってる。
ベンチだと真逆なのに
58デフォルトの名無しさん
2019/06/18(火) 14:44:50.57ID:6YVmUs6+
続き読んだら他の人が否定してた
59デフォルトの名無しさん
2019/06/19(水) 01:56:19.31ID:8qBvJS/J
nimはgcを使っている。でもCへのトランスパイルができる。
gcということはメモリ解放が暗黙的ということだろう。
Cでは明示的に解放する必要がある。

どうやって解放タイミングを調べてるんだ?
GC言語から非GC言語へのトランスパイルがなぜ可能なのか?
60デフォルトの名無しさん
2019/06/19(水) 02:09:28.92ID:8qBvJS/J
var name: string = readLine(stdin)

なんでvarと書きつつstringと型指定するのか
変な言語仕様だな
string name =
でいいだろ
61デフォルトの名無しさん
2019/06/19(水) 02:10:39.50ID:8qBvJS/J
var name = readLine(stdin)

型推論だっていってるけどこれ可読性低下してる
string name = readLine(stdin)
これがベスト
62デフォルトの名無しさん
2019/06/19(水) 02:52:19.54ID:8qBvJS/J
nimでデバドラ作ったりできるんだろうか
63デフォルトの名無しさん
2019/06/19(水) 02:57:44.38ID:8qBvJS/J
https://forum.nim-lang.org/t/2541
Nim also can produce a program that will be put in an embedded system. In such environment, usually there is no OS or only primitive OS, and Nim produced program have higher chances to access hardware directly.

できそうだ
Nimは流行りそうな気がする
なんで組み込みでC++なんか使ってるんだ
64デフォルトの名無しさん
2019/06/19(水) 04:14:19.61ID:8qBvJS/J
https://forum.nim-lang.org/t/3223
>Basically, 10 OS for 10 CPUs would contain 100 sets of C source code, that get bundled up over in csources.git

どうやらNimが適切なCソースコードを作成するには
ターゲットのCPUとOSを指定する必要があり、
その組み合わせ全てに何かファイルを用意する必要がある。

これじゃダメだな・・・
65デフォルトの名無しさん
2019/06/19(水) 04:24:41.25ID:8qBvJS/J
勘違いした。ダメってことはないか
Nimコード自体は環境非依存、Cコードにするとき環境依存、ということか
66デフォルトの名無しさん
2019/06/19(水) 14:31:42.44ID:Yoy0IPRe
LLVMω
67デフォルトの名無しさん
2019/06/21(金) 05:13:28.08ID:gJOJvtBY
Nimってめちゃすごなんじゃないかなあ
細かい言語仕様で嫌いなところがあるけど
68デフォルトの名無しさん
2019/06/21(金) 14:29:00.17ID:HK0kbqVP
漏れも D がすごいと思ってた時期があるよ
69デフォルトの名無しさん
2019/06/21(金) 14:55:07.18ID:GHyPzIJc
>>61
name : string := readLine(stdin)
のほうがいい。
70デフォルトの名無しさん
2019/06/22(土) 05:26:38.53ID:ecTKxvDL
https://nim-lang.org/
The Nim compiler and the generated executables support all major platforms like Windows, Linux, BSD and Mac OS X.

executablesは機械語?Cコード?
いずれにせよ環境依存してると思うけど、大抵のプラットフォームをサポートしてます、ってどういうこと?
大抵のプラットフォームに向けてトランスパイルできますってこと?
71デフォルトの名無しさん
2019/06/22(土) 09:58:00.49ID:fiI8bn9U
You Nim で Tensorflow が使えるアプリ造っchina YO
72デフォルトの名無しさん
2019/06/24(月) 09:23:40.70ID:4pk2usGN
>>69
var name : string = readLine(stdin)
#nameは変更可能
let name : string = readLine(stdin)
#nameは初期化後は変更不可
というletとvarに違いがある。
型推論使ったほうがコード読みやすい、書きやすいという人もいるんだよ。
readLineの戻り値の型はstringに決まってるんだから毎回型を書く必要ないと思うけど
73デフォルトの名無しさん
2019/06/24(月) 09:43:12.98ID:4pk2usGN
>>70
NimはC言語に変換してからgcc等のCコンパイラを呼んで実行ファイルを作るんだよ。
C言語は大抵のプラットフォームで使える言語だからマルチプラットフォーム化しやすい。
なので一度書いたNimコードをそれぞれのプラットフォーム上でコンパイルするかクロスコンパイルするだけでだいたいは動く。
けどNimから出力されるCコードは特定のCコンパイラ、OS、CPU向けに書かれているので、それだけでマルチプラットフォームな実行ファイルは作れないらしい。
Nimの標準ライブラリのソースコードを読むとOS、CPUによる違いを吸収するためのコードがときどきあるよ。
74デフォルトの名無しさん
2019/06/24(月) 09:53:12.36ID:4pk2usGN
Nimのソースコードのcompiler/extccomp.nimにNimが対応しているC/C++コンパイラの情報がまとまっていて、compiler/platform.nimにはOSとCPUの情報がまとまってる。
75デフォルトの名無しさん
2019/06/24(月) 11:40:11.26ID:eHWTfFeZ
https://github.com/nim-lang/Nim/blob/devel/compiler/extccomp.nim
https://github.com/nim-lang/Nim/blob/devel/compiler/platform.nim
https://github.com/nim-lang/Nim/wiki/Consts-defined-by-the-compiler
76デフォルトの名無しさん
2019/06/24(月) 15:58:18.33ID:4pk2usGN
>>59
NimのGCについてはここに情報がある。
メモリ確保時にいらなくなったメモリを走査して解放しているらしい。
https://nim-lang.org/docs/gc.html

NimでGCを使わずにメモリ管理する話もある。
https://github.com/nim-lang/Nim/wiki/Destructors,-2nd-edition

>>71
Nimで実装されたTensorflowに相当するらしいlibrary
https://github.com/mratsim/Arraymancer
77デフォルトの名無しさん
2019/08/11(日) 11:51:35.55ID:coNgBae3
2次元配列って、
var a: array[10,array[10,int]] とか書くしかないの?
78デフォルトの名無しさん
2019/09/24(火) 21:02:48.66ID:WLUvX9Jg
nim1.0でた~~
79デフォルトの名無しさん
2019/09/25(水) 05:43:15.78ID:rQhNlpv9
Version 1.0 released
23 September 2019 The Nim Team
https://nim-lang.org/blog/2019/09/23/version-100-released.html

Nim Programming Language Hits Stable Milestone With v1.0 Release
https://www.phoronix.com/scan.php?page=news_item&;px=Nim-1.0-Programming-Language
80デフォルトの名無しさん
2019/09/25(水) 06:16:02.11ID:vl5hNqVG
ついでにwandboxのnim
https://wandbox.org/permlink/npG9hbKwZyKQTXgI?source=post_page-----5d0f58d21e7e----------------------
81デフォルトの名無しさん
2019/09/25(水) 10:58:52.25ID:U8qLrE8v
GJ
82デフォルトの名無しさん
2019/09/26(木) 04:03:18.19ID:9xzqPVF9
1.0おめでとう!
ちなみに

echo NimVersion
echo(NimVersion)
NimVersion.echo

は同じ意味のコードだよ。Uniform Function Call Syntaxってやつだ
83デフォルトの名無しさん
2019/10/27(日) 16:17:57.05ID:IkTaChA0
windows 10
Nim 1.0.2 入れてみた
tdmgcc は前から使ってて gcc は既に path 通してあったので

nim 側はファイル展開しただけで何もしなくても良かった
(nim.cfg の書き換え(書き足し)も不要だった)
path 通さなくても
C:\nim\bin\nim c hogehoge
で動いた
84デフォルトの名無しさん
2019/10/27(日) 16:18:39.88ID:IkTaChA0
あと
日本語の参考書籍ってなんか出てる?

Nim in Action とかはどうだった?
85デフォルトの名無しさん
2019/10/30(水) 20:48:12.27ID:obI8HGMc
>>83
最近のは勝手に gcc 入れてくれるよ。
86デフォルトの名無しさん
2019/11/06(水) 15:17:56.57ID:o3tEvZiY
HANDLEもこっそりtypedefに_PTR変えたんだっけ
87デフォルトの名無しさん
2019/11/06(水) 15:20:05.05ID:o3tEvZiY
誤爆った
88デフォルトの名無しさん
2019/11/09(土) 00:06:35.30ID:LGMQokS+
Nim playground
https://play.nim-lang.org/
次スレから>>1に入れといてよ

しかしver1到達したのに全然盛り上がらんのなお前ら
89デフォルトの名無しさん
2019/11/09(土) 03:28:50.22ID:fORTWFTH
https://wandbox.org/
こちらでもNim使えますよ。
90デフォルトの名無しさん
2019/11/10(日) 11:17:11.92ID:ddnKE8WS
>>85
distフォルダにmingwの7z玉入れておけば、オフラインでのインストールもできるね。
91デフォルトの名無しさん
2019/11/10(日) 11:25:43.54ID:ddnKE8WS
>>84
日本語の書籍はないが、原著のドキュメントは割とわかりやすい。docs/tut1.htmlから読み始めるといいかもしれない。
NIAは評判が良いらしいのと、製本版を買うと電子書籍版が無料で付いてくるらしい。

国内でのNimの翻訳は有志が約二名ほど作業しているが、まだ始まったばかり。時間かかりそうだね。
92デフォルトの名無しさん
2019/11/18(月) 09:38:29.23ID:ahZzeXy3
DLLのCの関数を呼ぶ方法はいくつかあるようですが
なぜいくつもあるのでしょうか?
どれが一番効率が良いのかとか新しいのかとか判りにくい
93デフォルトの名無しさん
2019/11/18(月) 15:24:43.91ID:g/bdYEbz
単純にdll内の関数を呼びたいならdynlibプラグマを使うのが一番楽。
少し低レベルな機能が必要ならdynlibモジュウルにあるプロシイジャアを使えばいいんじゃなかろうか
94デフォルトの名無しさん
2019/11/18(月) 17:09:32.08ID:wQWkNxVm
成る程。
95デフォルトの名無しさん
2019/12/10(火) 23:17:13.67ID:DeryhXpR
nimに対応したソースコード可視化ツールってある?
96デフォルトの名無しさん
2019/12/12(木) 17:09:11.38ID:Lo+C9eAO
nimってあまりかっこよくないね
97デフォルトの名無しさん
2019/12/13(金) 23:01:47.25ID:sYt6sihU
Cにコンパイルしてからコード解析ツールに。
98デフォルトの名無しさん
2020/03/25(水) 04:10:40.05ID:k6zngd1F
nimコードはトランスパイルする前ならクロスプラットフォームなんだろうか?
99デフォルトの名無しさん
2020/03/27(金) 15:59:22.92ID:6mKroLAz
こんないい言語なのに結局欠点はCに依存してる点
100デフォルトの名無しさん
2020/03/27(金) 16:10:13.08ID:9RtDMjhb
あんまり本出ないね
むしろチャンスか
101デフォルトの名無しさん
2020/03/27(金) 22:55:09.53ID:2CmTFgv1
あの糞マクロ以外大して面白みのない言語だしなぁ
102デフォルトの名無しさん
2020/04/07(火) 05:01:02.90ID:FPXvnSDp
逆にマクロの完成度高い言語ってなに?
103デフォルトの名無しさん
2020/04/07(火) 07:46:31.57ID:CJzGmfMl
common LISP
104デフォルトの名無しさん
2020/04/07(火) 14:00:10.17ID:izX7gbjy
Schemeは?
105デフォルトの名無しさん
2020/04/07(火) 19:47:26.61ID:fJ0U2d01
nimのマクロは完成度高いと思う。でも完成度高いマクロという存在自体が糞。
106デフォルトの名無しさん
2020/04/08(水) 12:06:55.28ID:lWfV0IAd
MACRO-80
107デフォルトの名無しさん
2020/04/10(金) 23:13:42.18ID:mN42vwgW
>>102
糞マクロを褒めてるのであって
逆じゃないと思うんだが
108デフォルトの名無しさん
2020/04/10(金) 23:14:33.21ID:mN42vwgW
>>101>>105が同じってことだろ
common lispなんてはるかに糞になるし
109デフォルトの名無しさん
2020/04/10(金) 23:15:34.44ID:mN42vwgW
マクロならrustのが定評あると思うが
110デフォルトの名無しさん
2020/09/19(土) 22:27:13.04ID:9NR8PjVh
小数の配列作りたいんだけどやり方教えてください。
[0.0, 0.1, .. 0.9, 1.0] みたいな。

Python なら hoge = [i/10 for i in range(11)] かな。気持ち悪いけど。
111デフォルトの名無しさん
2020/09/22(火) 12:29:56.17ID:w8JrpHTT
lc[i*0.1 | i<-0..10 ]
112デフォルトの名無しさん
2021/01/10(日) 21:59:51.09ID:HIznKotv
>>69
var name = readLine stdin
var name = stdin.readLine
で完結してるよ、型推論で>>72にも言った通り型を何回も書く意味がない。付け加えれば()カッコも
要らない。第一引数クロージャーのラムダ式で言えばカッコが必要ないのに書く意味が無い。そして
varとletとは不変性だが、rustやVの様にたかがGCを搭載したく無いだけで、どこでもmut mutして
プログラマに負担を強いるより良い(あくまで個人の感想です)
さらに、procとfuncも、片方が純関数なのはキーワードとして明示できる統一性としてありだね。
まあpragmaが多すぎる気もするけど、if likely(true)/unlikely(false)の様にCPUキャッシュ分岐予測に
直接関与出来る高級言語としては、他に類を見ない。GCが嫌ならOFFに出来るし、そして重い
Stop the Worldが嫌ならそれをしないGCに変えることが出来る、言語としては機能が多くて
Goの様に究極なシンプル(なのに統一性が微妙)じゃ無いけど、こりゃ良いわ
var name = stdin.read LineEnum
113デフォルトの名無しさん
2021/01/10(日) 22:14:35.92ID:HIznKotv
付け加えるとHaskellみたいなproc() = の宣言が微妙キモいけどfunc(): T =があるから、まあ妥当だね
rubyの様なreturnを書かないのは良い。result=xは便利だけど微妙....でそこまでやるならOptionと
Future、そして例外を統一して欲しかったな。
普通にtry: except: finally:があるのも点数が高い。Araqが言う様に例外と(Label)goto based exceptは
ほとんど同じ何だから、今どきの言語が例外が無いのはおかしい。まあ他を悪く言う気はないけど
Goの様に意味合い的に同じでfinallyに対応するdeferがあるのも良いよね
114デフォルトの名無しさん
2021/01/12(火) 15:33:30.76ID:LUlB/OIG
超時空ロングパス
115デフォルトの名無しさん
2021/01/12(火) 15:57:17.72ID:kyPiY518
この言語がJsと比較で優れてる点ってあるの?
116デフォルトの名無しさん
2021/01/13(水) 08:29:44.80ID:oKh8381v
JavaScript?であれば、JavaScriptはECMAScriptのバージョンとともに型無しのダックタイプから
クラス定義で見られるように型を導入して大規模コードを書く際に静的な安全性を求めてきた、
言語的な特徴でもあった動的なメソッド上書きやapply/callは悪とみなされつつ、改良が進む。
TypeScriptもその特徴であろう、altJSあるいはJSX派生と呼ばれる一種の方言が多量に誕生した
一方でJavaScriptの遅さや1言語依存からwasmが考え出されて多くのコンパイラでwasm開発が
できるようになった。Nimも例に漏れずJSバックエンド及びwasmコンパイルが可能である。
Rustもwasm開発はそうだがJSバックエンドは無い、Goもwasmは出来るがサイズが大きい
NimはGoに比べても型チェックが厳しい、Rustはそれに借用いわゆるボローチェックがそれに
加わるRustもそうだが型安全性はばつぐんだ
117デフォルトの名無しさん
2021/01/14(木) 18:15:15.39ID:ZgCcmsal
jsって割と底辺だと思うから
Nimはそれより上だろ
118デフォルトの名無しさん
2021/02/25(木) 19:45:58.25ID:twDFYCAL
1.4.4 age
119デフォルトの名無しさん
2021/04/17(土) 20:22:19.25ID:f1G9K9An
1.4.6 age
120デフォルトの名無しさん
2021/04/30(金) 20:42:36.52ID:+hB3gYz3
Windows defenderでウイルス判定される
121デフォルトの名無しさん
2021/05/01(土) 12:24:15.54ID:afQILYPs
それはどうしようもない
https://forum.nim-lang.org/t/7830
122デフォルトの名無しさん
2021/05/10(月) 13:57:34.01ID:FH4+0Y9S
頼むからもう少し流行ってください。Dropトレイト、Rcトレイトと戯れてあいつのコードを直したくない
123デフォルトの名無しさん
2021/05/10(月) 15:07:45.08ID:lCZGOQhN
明日に向かって吠えろ
124デフォルトの名無しさん
2021/05/13(木) 14:29:40.54ID:pHijDXLB
Software Design に記事持ち込め
125デフォルトの名無しさん
2021/05/15(土) 12:35:34.04ID:eYtIld1h
https://www.akiradeveloper.com/post/give-up-nim/
126デフォルトの名無しさん
2021/05/19(水) 07:49:19.67ID:mvJC2+U+
2015年2月なんて大昔だろ…Version 0.11頃の話、貼る奴w
127デフォルトの名無しさん
2021/05/19(水) 07:53:15.04ID:mvJC2+U+
間違えた。
2月だから0.11さえ出てないわ、0.10.2…
128デフォルトの名無しさん
2021/05/26(水) 22:06:31.04ID:5a/xy4zx
>>120-122
バージョン1.4.8がリリースされました
2021年5月25日ニムチーム

Nimチームは、Nim1.4の4番目のパッチリリースであるバージョン1.4.8を発表できることを
嬉しく思います。バージョン1.4.8は、1か月のハードワークの結果であり、23のコミットが
含まれており、最も重要なバグが修正され、ORCメモリ管理がさらに改善されています。
すべてのユーザーにバージョン1.4.8をアップグレードして使用することをお勧めします。

リリースのハイライト
develブランチと同様に、v1.4.8はcsources_v1を使用して構築されています。つまり、
AppleM1チップで使用できます。
バージョン1.4.6は、いくつかのウイルス対策ソフトウェアでいくつかの誤検知を引き
起こしました。私たちのテストによると、これはv1.4.8では発生しないはずです。
129デフォルトの名無しさん
2021/06/24(木) 16:12:27.31ID:IeJQfUil
なんか結局流行らなかったな
2019ごろはちょっと来そうな雰囲気出してたのに
130デフォルトの名無しさん
2021/06/24(木) 16:13:02.76ID:IeJQfUil
今でも一番書いてて気持ちいい言語ではあるけど
131デフォルトの名無しさん
2021/06/24(木) 17:25:26.02ID:70oiT5zZ
Luaといい勝負?
132デフォルトの名無しさん
2021/06/27(日) 14:10:40.69ID:YLAmOs9U
Luaの理念は、簡素、高効率、高移植性(simple, efficient, extensible)、現在はpowerfulとかに変えた。
JITもあるが型の概念が希薄で基本はNativeではない。GCあり、プロトタイプベースのOOPSもC/C++の
相互運用も図られているが、主な用途は本体のプログラムを拡張するスクリプト、ゲームの拡張や
3Dモデリングソフトなどの拡張。

一方、Nimは「Efficient, expressive, elegant」(効率的、表現力豊か、エレガント)であり、型は厳格。
関数、あるいはプロシージャ呼び出しも厳密。Goにあるinterface{}のようなものは無く、Cというか
リンケージ指定、オブジェクトコピー方法、インライン展開など明示するような言語と一体化されたプラグマ。
言語と一体化されたマクロ・テンプレート。状況で選べるGC、例外try-catchとdeferを全否定をしない。
RustのようにGCを排除したためプログラマに押し付けた借用チェックは無い。
Goよりも小さくて速いGC、それによる速度低下は最小限、Rustは学ぶ価値が確かにあるが非常に高い敷居。
Nimは非常に低い敷居(Goほどではないが)、表現力はC/C++そのもの、限りなく抑え込まれたタイプ量。
133デフォルトの名無しさん
2021/06/27(日) 20:05:41.95ID:ytkGpeVG
そんなにヒドいかな?
134デフォルトの名無しさん
2021/08/21(土) 08:23:43.68ID:7GAoG1Iq
Nimにガベージコレクション(GC)有りは事実なのですが、
NimはオプションでGC無しにできるので、
Nimバージョン:1.5.1でRustのボローチェッカー
に似た「View types」が実装されれば
GC無しで、View types参照の有効性を検証する
ことによってメモリ安全性を保証しつつ高速化して
C/C++/Rustの代替に出来ますか?
135デフォルトの名無しさん
2021/08/21(土) 08:47:50.25ID:7GAoG1Iq
Nimの実験的特徴
著者: アンドレアス・ルンプ
バージョン: 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
136デフォルトの名無しさん
2021/08/21(土) 22:20:40.33ID:7GAoG1Iq
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


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

「怠け者とはこうあるべきだ!」と言うとても大事な事を Nim は我々に教えてくれます
137デフォルトの名無しさん
2021/08/22(日) 08:04:08.99ID:0Cz6ueFz
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

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

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

138デフォルトの名無しさん
2021/10/02(土) 12:07:48.96ID:nsqRCPBa
いつの間にかJetBrainsのプラグインが出てたね。今更気がついたよ
これもかなり良いんじゃない?
https://plugins.jetbrains.com/plugin/15128-nim
139デフォルトの名無しさん
2021/10/27(水) 21:47:06.11ID:6tzLPjk/
const str = [0, 1, 2, 3, 4]
for i in 0||str.high: echo str[i]
# nim --passC:"-fopenmp" --passL:"-fopenmp" c main.nim
140デフォルトの名無しさん
2021/10/28(木) 12:20:10.25ID:hM84Yf/1
>>92
Cの関数だけでもいろいろなコンパイラーにより規約が違うから、ダイナミックなリンケージを非常に素直に
書ける言語はこれくらいだと思う。rustもFFIで呼べるけど
https://ja.wikipedia.org/wiki/呼出規約
141デフォルトの名無しさん
2021/10/29(金) 07:15:01.84ID:pQzUwhXN
Nim言語の開発者が$100k相当のBitcoinの寄付を受け取ったことが話題になっています。
www.reddit.com/r/programming/comments/qg2srd/nim_receives_100k_in_bitcoin_donations/
142デフォルトの名無しさん
2021/11/11(木) 20:14:42.95ID:sY0aXUs3
>>99
公式での処理系は基本的にはC/C++のトランスコンパラですがJSのトランスコンパラとしても動作します。
言語的には依存している分けではなく、gccやclangの最適化の恩恵を受けるためにあえてそのようにして
いるようです。
また直接バイナリを吐き出す別のコンパイラarnetheduck/nlvmもあります。CrystalやRust、Swiftなどの
LLVMバックエンドと同じです。コンパイル時間を短縮しllvmバイナリとして僅かに小さくなります。
143デフォルトの名無しさん
2021/11/22(月) 17:33:11.29
RustよりC++より速いんですか? 始めてみようかな
144デフォルトの名無しさん
2021/11/22(月) 20:36:44.15ID:Jhs76KRN
いろんな意味で早いと思う
145デフォルトの名無しさん
2021/12/17(金) 19:10:05.51ID:XHqHc5Ln
Version 1.6.2 released
https://nim-lang.org/blog/2021/12/17/version-162-released.html
146デフォルトの名無しさん
2022/02/10(木) 01:19:39.92ID:OVWQX5q0
Version 1.6.4 released
https://nim-lang.org/blog/2022/02/08/version-164-released.html
147デフォルトの名無しさん
2022/03/29(火) 04:55:27.78ID:cbyFlglW
1.6.x系だけDLしようとするとマルウェア警告出るんだけどこれ大丈夫なんかね
148デフォルトの名無しさん
2022/03/29(火) 14:58:47.55ID:mXbypgy+
Nimの公式サイトから入手したものなら大丈夫なはず。
Nimに含まれている実行ファイルやNimでコンパイルしたプログラムがアンチウィルスソフトウェアに誤検出される問題は多くの人々から報告されている。
Nim言語でマルウェアを書いてる人がいるせいで誤検出さるようになったらしい。
アンチウィルスソフトウェアは悪いことしないプログラムでもマルウェアと似たようなビットパターンを見つけるとマルウェアとみなすっぽい。
149デフォルトの名無しさん
2022/03/29(火) 15:37:13.13ID:j1iUrhcV
>>148
なるほどね?
サンキュー😉👍🎶
150デフォルトの名無しさん
2022/03/29(火) 20:54:07.21ID:/9JyHlX1
マルウェアと誤検知されたくなければnimで開発しない方が無難か。
151デフォルトの名無しさん
2022/03/31(木) 21:33:49.63ID:3qPlBVYz
多くの人が使っているプログラムでない限り誤検出される可能性はある。
C++使ってたころにビルドが完了してすぐに誤検出されことがあったし。
152デフォルトの名無しさん
2022/03/31(木) 21:54:44.97ID:EY1WgKK4
そういうどっちもどっち論じゃないだろ。>>148は有意に誤検知が多いと言っているように見えるが。
153デフォルトの名無しさん
2022/04/01(金) 11:47:01.52ID:3pastURm
Nimコンパイラ自体がマルウェア扱いだからな。
154デフォルトの名無しさん
2022/04/03(日) 00:58:55.13ID:29whmEYr
Nimを書き初めて1ヶ月...procの第一引数に設定したオブジェクトにprocがバインドされる謎構文にはたまげたけど書き味がいいし気に入ったなあ
155デフォルトの名無しさん
2022/04/03(日) 10:37:31.39ID:Ng2sRKnM
>>154
ちょっと誤解しているようだけど、a.foo()って書いたら自動的にfoo(a)に変換されるだけだよ。
第一引数の型にそのprocがバインドされるわけじゃないよ。
X.nim:
type
 Foo* = object
  x: int
proc foo*(f: Foo) = echo f

Y.nim:
import X
proc bar*(): Foo = Foo()

Z.nim:
import Y
#X.nimをインポートしてないとfoo()は呼べないよ
bar().foo()
156デフォルトの名無しさん
2022/04/03(日) 10:53:58.62ID:Ng2sRKnM
Nimではプロシージャの呼び出し方が何通りかある。
echo("Hello")
# Command invocation syntax
echo "Hello"
# Method call syntax
"Hello".echo
"Hello".echo()
# Generalized raw string literals
# 引数が文字列リテラル一個のときのみ
echo"Hello"
157デフォルトの名無しさん
2022/04/03(日) 20:20:01.30ID:29whmEYr
>>155
なるほど👀
それでも変わった感じですよねえ
158デフォルトの名無しさん
2022/04/09(土) 11:44:54.12ID:P+77Yson
>156
Method call syntax はスマートだから他言語でも流行ってほしいところ。
特にPythonは真っ先に採用して欲しいわ。
159デフォルトの名無しさん
2022/04/22(金) 04:37:03.66ID:Ov5wmYZH
あまり何通りもあるのはperlみたいになりそうでよろしくないな。
160デフォルトの名無しさん
2022/05/05(木) 20:58:23.76ID:Ofa1pfuz
Version 1.6.6 released
https://nim-lang.org/blog/2022/05/05/version-166-released.html
161デフォルトの名無しさん
2022/05/06(金) 17:32:07.42ID:+sslkA2r
>>160
急にコンパイルできなくなって困ってたら
vccexe,exeがトロイ認定受けて削除されてた…
MSはnimをトロイだとみなしてるのか
162デフォルトの名無しさん
2022/05/08(日) 11:28:42.79ID:ttLKa+gZ
>>161
前に一回同じ現象出たわ
コンパイル失敗するしWindows Defenderはうるさいしで何かやらかしたかと思った
163デフォルトの名無しさん
2022/05/18(水) 23:08:10.33ID:7sDXJn10
ニンニン
164デフォルトの名無しさん
2022/06/14(火) 14:49:13.90
二ムってドイツ製?
165デフォルトの名無しさん
2022/06/22(水) 00:08:54.72ID:mbXzyoju
Araqってたしか国籍は南米じゃなかったか
166デフォルトの名無しさん
2022/06/22(水) 00:28:49.96ID:mbXzyoju
>>164
すまんドイツ人だったわ
顔面からずっと南米の人だと思ってた
167デフォルトの名無しさん
2022/07/26(火) 18:12:34.65ID:MxJrqhMY
ニンニン
168デフォルトの名無しさん
2022/07/26(火) 18:15:36.24ID:gc9s0ohk
浣腸
169デフォルトの名無しさん
2022/07/27(水) 03:59:11.24ID:0dTQJF2a
Aliasing restrictions in parameter passingかview typesが実装されればNimもRust並にメモリ安全になると思うんだけど。
みんなはどう思う?
https://nim-lang.org/docs/manual_experimental.html#aliasing-restrictions-in-parameter-passing
https://nim-lang.org/docs/manual_experimental.html#view-types
170デフォルトの名無しさん
2022/07/28(木) 11:23:58.38ID:oB626eDW
>>169
むしろ--mm:orcならRustよりNimのほうが循環もGCするだけメモリ安全だし、リリースビルドでオーバーフローチェックが意味不明にoffになり、言語仕様としてループindexにunsignedを使うRustのどこが安全なのかと小一時間。
まあNimでのdangerコンパイルと似てるし、構文上まだ危険な超絶ハック表現が出来てしまうので素人にはオススメ出来ない諸刃の剣。だけどsqlパッケージの文字列前提を絶対変えてほしい
171デフォルトの名無しさん
2022/07/28(木) 14:19:26.27ID:1GWFUzAq
RustのBorrow Checkerはメモリリークを防ぐものではないからね
172デフォルトの名無しさん
2022/07/29(金) 02:16:03.41ID:jt8KW6vh
nimの言語的とか技術的な弱点や欠点って何?
173デフォルトの名無しさん
2022/07/29(金) 03:05:46.34ID:4AXwbrcj
templateまたはmacroの第一引数がuntypedだとmethod call syntaxが使えない。
method call syntaxでgenerics parameterを指定するときにfoo.myproc[:int]()みたいな感じで[]の中の初めに':'を付けないといけない。method call syntaxを使わないときは':'は不要。
という感じでmethod call syntaxにちょっとした罠がある。
174デフォルトの名無しさん
2022/07/29(金) 12:18:00.08ID:sEOGgaoM
macroが全く別言語になってる錆やその他諸々よりも、ちゃんと言語の最小サブセットになってるからまだマシ
175デフォルトの名無しさん
2022/07/29(金) 13:08:45.89ID:jt8KW6vh
なるほど
176デフォルトの名無しさん
2022/09/10(土) 16:11:58.36ID:VwPQQEZG
win10 x64 nim-1.6.6 x64 です
(A)
var hoge = newSeq[uint16](16)
# hoge[...] に wchar_t の文字列 L'\x0' 終端がある (サロゲートとか無い状態で 4文字分)
echo convert(cast[string](hoge[0..3]), "utf-8", "utf-16")
(B)
var fuga = newSeq[char](16)
# fuga[...] に char の文字列 '\x0' 終端がある 4文字分
echo cast[string](fuga[0..3])

(B)の方は期待通り 4文字分出力されるのですが
(A)の方はなぜか 2文字くらいで切れてしまいます
echo convert(cast[string](hoge[0..7]), "utf-8", "utf-16")
と修正すると 4文字出ましたが何か腑に落ちません
177デフォルトの名無しさん
2022/09/11(日) 06:48:19.18ID:u4B58VWk
>>176
そもそも何をしたいの?
windowsで日本語を表示したいだけならutf8を使ってればOk
デフォルトでNimのコマンドラインプログラムを実行するとchcp 65001コマンドを実行したときのようにコードページをutf8に変更される。
chcp 65001を実行してもちゃんと日本語が表示されるようにターミナルを設定しよう。

utf16なテキストをutf8に変換して表示したい場合はできるだけcast使わないようにコードを書こう。
castは危険なのでできるだけ使わないようにしよう。
(castはビットパターンが同じまま別の型と見なす変換なので実装詳細を知らずに使ってるとうまく動かない)
最初からstringに文字列を格納するようにするとか、ループで一文字づつstringにコピーすればcastは避けられると思う。
178デフォルトの名無しさん
2022/09/11(日) 15:33:59.58ID:o5WJ0zmX
上の例とは若干違いますが
var u16 = newSeq[uint16](8)
for n in 0..7: u16[n] = cast[uint16](65 + n)
u16[7] = 0
echo u16 # -> @[65, 66, 67, 68, 69, 70, 71, 0]
echo convert(cast[string](u16), "utf-8", "utf-16") # -> ABCD
let u8 = cast[ptr UncheckedArray[array[16, uint8]]](u16[0].addr)[0]
echo u8 # -> [65, 0, 66, 0, 67, 0, 68, 0, 69, 0, 70, 0, 71, 0, 0, 0]

ABCD のところが ABCDEFG にならないのがなんでかなーというのも
同様の現象が原因だろうと思います
179デフォルトの名無しさん
2022/09/11(日) 15:42:19.33ID:o5WJ0zmX
echo convert("\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x00\x00", "utf-8", "utf-16")
これは
ABCDEFG
と出力されます
180デフォルトの名無しさん
2022/09/11(日) 15:48:12.92ID:o5WJ0zmX
>>178 の例で
var u16 = newSeq[uint16](16)
と定義しておくと(他は変更無し)(後半は0で埋まってる)
ABCDEFG
と表示されます
181デフォルトの名無しさん
2022/09/11(日) 15:48:57.35ID:o5WJ0zmX
まあ cast に何を期待してるんだと言われればそれまでなんだと思いますが腑に落ちませんでした
182デフォルトの名無しさん
2022/09/11(日) 19:01:47.42ID:EVjHVTpm
nimってIDEやデバッガは近いうちに計画されてるの?
vscodeでもいいんだけど、ちゃんとしたデバッガは欲しいな
条件付きブレークポイントやコンテナの中身が見れる程度でいいんだが
183デフォルトの名無しさん
2022/09/11(日) 19:50:17.68ID:6Wt0j/hc
>>182

vscodeのプラグイン
nimsaem.nimvscode + webfreak.debug ではだめか?
184デフォルトの名無しさん
2022/09/11(日) 22:55:03.70ID:EVjHVTpm
やっぱりその組み合わせか
どうにも使いづらいんだよねぇ
言語仕様は理想に近いんでもっと流行ってほしいんだが、これまでの情勢からあまり期待できなさそうだな
185デフォルトの名無しさん
2022/09/12(月) 01:44:56.16ID:I2SXXYSG
>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcast
186デフォルトの名無しさん
2022/09/12(月) 01:47:29.58ID:I2SXXYSG
>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcastしてるの?
そうでないならcast使うのはやめたほうがいいよ。
187デフォルトの名無しさん
2022/09/12(月) 02:10:20.86ID:I2SXXYSG
>>181
seqやstringのデータ構造を理解しcastが何をしているか理解すれば納得できると思うよ
https://github.com/nim-lang/Nim/blob/devel/lib/system/seqs_v2.nim
https://github.com/nim-lang/Nim/blob/devel/lib/system/strs_v2.nim
そもそもseq[uint16]からstringへcastしてる時点でもうデタラメなんだよ。
188デフォルトの名無しさん
2022/09/12(月) 02:17:45.60ID:I2SXXYSG
>>182
NimにGDBでデバッグできるようにするプラグインが付属していて
gdbでブレークポイントをおいたり変数の中身を表示したりできます。
https://internet-of-tomohiro.netlify.app/nim/gdb.ja.html
189デフォルトの名無しさん
2022/09/12(月) 20:00:29.06ID:YXdRRv20
>>178 >>180
var u16 = newString(16)
for n in 0..7: u16[n * 2] = cast[char](65 + n); u16[n * 2 + 1] = '\0'
u16[14] = '\0'
echo u16 # -> A B C D E F G
echo convert(u16, "utf-8", "utf-16") # -> ABCDEFG
190デフォルトの名無しさん
2022/09/12(月) 22:26:15.30ID:I2SXXYSG
>>189
castは極力使わないほうがいいのでビット演算使ってu16の値をcharに変換したほうがいいよ。
お手本コードを投稿しようとしたらcloudflareが悪意あるコードと勘違いしてブロックされた
191デフォルトの名無しさん
2022/09/12(月) 22:30:11.19ID:I2SXXYSG
こんな感じです
let c=65u16 + n
u16[n * 2] = char(c and 0xff'u16)
u16[n * 2 + 1] = char(c shr 8)
192デフォルトの名無しさん
2022/09/13(火) 11:55:15.89ID:gs7UQvs1
>>176
これ観ろ
https://khchen.github.io/winim/winstr.html
193デフォルトの名無しさん
2022/09/13(火) 12:06:13.19ID:0kBS+x4w
言語仕様としてはモダンな言語の中で1番わかりやすいし
Rustで書くほどでもない軽いスクリプトとかならNimで良いんだけど流行らんなあ
やはり個人開発者の言語が流行ることはもうないのか
194デフォルトの名無しさん
2022/09/13(火) 15:06:32.01ID:EXK746Ox
>>189 >>192
ありがとうございました
195デフォルトの名無しさん
2022/09/13(火) 16:00:02.06ID:EXK746Ox
アク禁?
196デフォルトの名無しさん
2022/09/13(火) 16:03:11.36ID:EXK746Ox
var ws = newWideCString(8) # ws.len == 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
# ws.len == 8
ws[7] = Utf16Char(0) # ws.len == 7
echo ws # ABCDEFG
と比べて
197デフォルトの名無しさん
2022/09/13(火) 16:05:36.05ID:EXK746Ox
なぜ拒否られる?
198デフォルトの名無しさん
2022/09/13(火) 16:06:26.54ID:EXK746Ox
驚き最小の法則ですね
var s = newString(8) # s.len == 8
for n in 0..7: s[n] = char(65 + n)
# s.len == 8
s[7] = '\0' # s.len == 8
echo s # ABCDEFG
199デフォルトの名無しさん
2022/09/13(火) 16:07:15.32ID:EXK746Ox
判った char だけダメなんね
200デフォルトの名無しさん
2022/09/13(火) 16:09:20.44ID:EXK746Ox
驚き最小の法則
var ws = newWideCString(8)
echo ws.len # -> 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
echo ws.len # -> 8
ws[7] = Utf16Char(0)
echo ws.len # -> 7
echo ws # ABCDEFG
と比べて
var s = newString(8)
echo s.len # -> 8
for n in 0..7: s[n] = char(65 + n)
echo s.len # -> 8
s[7] = '\0'
echo s.len # -> 8
echo s # ABCDEFG
201デフォルトの名無しさん
2022/09/13(火) 16:11:32.87ID:EXK746Ox
インド人もびっくり
202デフォルトの名無しさん
2022/09/13(火) 19:05:39.59ID:ketgm+4i
Win土人
Nim土人
203デフォルトの名無しさん
2022/09/16(金) 10:37:25.88ID:8/QLgRNp
proc testfunc(x: cint): cint {.exportc, cdecl, dynlib.} =
return x
と描かれたソースを
nim c --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されて
import ctypes
ctypes.cdll.LoadLibrary('./hoge.dll').testfunc(123)
と実行出来たのですが
nim cpp --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されているはずなのに
LoadLibrary のところで
FileNotFoundError: Could not find module '(fullpath)\hoge.dll' (or one of its dependencies).
Try using the full path with constructor syntax.
と言われてしまいます
多分 or one of its dependencies が引っ掛かっているのではないかと思うのですが
何が足りないのでしょう? stdc++ の shared library ?
204デフォルトの名無しさん
2022/09/16(金) 10:57:11.84ID:8/QLgRNp
libstdc++-6.dll
をコピーしてみましたがだめでした
205デフォルトの名無しさん
2022/09/16(金) 11:30:30.18ID:lbCTEBn9
nimpy
nimodule
206デフォルトの名無しさん
2022/09/16(金) 13:53:03.44ID:kdRP0PjD
>>203
objdumpっていうプログラムを使えばどのdllを使っているか見れるよ。
使い方忘れたからググってね。
Nimをインストールしたときにgccもインストールしてればそのときにobjdumpも一緒にインストールされる。
他にも依存しているdllを見れるツールは色々あるけど
207デフォルトの名無しさん
2022/09/16(金) 16:11:50.14ID:fQY5NM7R
>>206
windows用にもobjdumpあんの?
208デフォルトの名無しさん
2022/09/16(金) 16:24:53.42ID:8/QLgRNp
windows で nim 入れるときに一緒に入った mingw64 の中に objdump がありました
209デフォルトの名無しさん
2022/09/16(金) 16:34:58.81ID:8/QLgRNp
>>206
objdump -p hoge.dll | findstr "dll"
で出て来たのが
libgcc_s_seh-1.dll
libstdc++-6.dll
kernel32.dll
msvcrt.dll
でした
libstdc++-6.dll
だけではなく
libgcc_s_seh-1.dll
も必要でした
無事動作しましたありがとう
210デフォルトの名無しさん
2022/09/18(日) 09:51:11.78ID:KpBP36NG
>>200
https://github.com/tauplus/nim_doc_ja/blob/master/nim-meory_ja.md#%E6%96%87%E5%AD%97%E5%88%97%E3%81%A8%E3%82%B7%E3%83%BC%E3%82%B1%E3%83%B3%E3%82%B9Strings-and-seqs
211デフォルトの名無しさん
2022/09/22(木) 10:36:47.71ID:u9/ouAZs
import nimpy
import nimpy/py_lib as lib
initPyLibIfNeeded()
let wx = pyImport("wx")
let app = wx.App()
let frm = wx.Frame(nil, -1, "Hello, work!")
discard frm.Show()
discard app.MainLoop()

簡単杉感嘆
212デフォルトの名無しさん
2022/09/22(木) 15:46:35.23ID:zq3yyQIu
こんなのや
https://github.com/khchen/wNim
こんなのも
https://github.com/simonkrauter/NiGui
213デフォルトの名無しさん
2022/09/23(金) 15:49:32.66ID:9eaiNZZz
セルフホスティングくらいでけるのか?
214デフォルトの名無しさん
2022/09/23(金) 16:54:42.46ID:COcKyTVz
>>213
セルフホストってどういう意味で言ってるかは知らないけど
Nim forum自体がNimで実装されてるよ。
https://github.com/nim-lang/nimforum
215デフォルトの名無しさん
2022/09/23(金) 20:37:31.28ID:vOu7CdIL
プログラミング言語でセルフホスティングっていったらコンパイラが自身の言語で実装できることだろうよ
しかしできたとしてトランスパイラをセルフホスティングと呼んでいいのか
216デフォルトの名無しさん
2022/09/23(金) 22:00:58.25ID:U9mPo3hK
出力がC言語か機械語かの違いぐらいだしトランスパイラだとしても普通にセルフホスティングって呼ぶよ
217デフォルトの名無しさん
2022/09/23(金) 22:27:48.78ID:COcKyTVz
https://github.com/nim-lang/Nim
ここにNim言語のコンパイラがあるけどソースコードはNim言語で書かれている。
gccなどのCコンパイラとgitがあればソースコードからビルドできる。
ソースコードからビルドするときはまず古いバージョンのNimコンパイラをC言語に変換したものをダウンロードしてCコンパイラでビルドする。
それでビルドしたNimコンパイラで最新のNimコンパイラをビルドする。
218デフォルトの名無しさん
2022/09/24(土) 20:13:52.60ID:7pBAspe1
わりとどうでもいいな
219デフォルトの名無しさん
2022/09/25(日) 02:56:32.67ID:z6wPsTgH
Cコンパイラは一般的にC言語で実装されているが、どうやってCコンパイラをビルドするのか
あらかじめビルド済みのCコンパイラを持ってきてビルドする
ではそのビルド済みのCコンパイラはどうやってビルドされたというのか
220デフォルトの名無しさん
2022/09/25(日) 08:27:58.95ID:bk7Mey46
たぶん世界で最初のC言語はアセンブリかB言語かフォートランか何か別の言語で書かれていたんじゃないの?
221デフォルトの名無しさん
2022/09/26(月) 14:35:28.98ID:heiSJ5NK
BigBangは未だ仮説だ
222デフォルトの名無しさん
2022/09/28(水) 12:46:44.72ID:bM9/UxvQ
toSeq(0..360|24).map(rad)
と描くと
Error: type mismatch: got <SteppedSlice>
と言われて怒られたので
toSeq(0..360).filter(x => x mod 24 == 0).map(rad)
で描き治したら一応動く訳だが
0..360|24
観たいに描く方法は?
223デフォルトの名無しさん
2022/09/28(水) 13:40:07.41ID:tqdPdMIm
iterator `|`(x: HSlice; y: int): int =
みたいな演算子のイテレータを定義すればいいじゃん。
224デフォルトの名無しさん
2022/09/28(水) 17:12:46.81ID:XnHyDYU1
nim 1.6.8 出た
225デフォルトの名無しさん
2022/09/29(木) 21:45:04.30ID:9HIV6ABQ
ウィ
226デフォルトの名無しさん
2022/10/02(日) 11:50:55.49ID:tLgfuLpM
>>223
iterator items(s: SteppedSlice): int =
var c = s.a
while c <= s.b:
yield c
c += s.step

を定義したらイケました
有賀豚
227デフォルトの名無しさん
2022/10/16(日) 04:20:39.65ID:ccy9anmS
ニンニン
228デフォルトの名無しさん
2022/10/22(土) 14:42:48.48ID:Q+2x5vm1
本日のNimConf2022期待age
229デフォルトの名無しさん
2022/11/02(水) 12:51:11.01ID:VT3BATxp
1,2ヶ月くらい前に
Nim言語のマニュアル日本語訳がOSDNのページにアップされていて
これで5年後には結構人気が出るかもと喜んでいたら
突然ページが消滅してショックだった

キャッシュを探したけど発見できないので
コピー持ってる人がいたらどこかにアップしてもらえらばありがたいです
(ライセンス上問題が無ければですが)
230デフォルトの名無しさん
2022/11/02(水) 22:26:34.03ID:AEY2Eek1
古いキャッシュならInternet Archiveにあった
https://web.archive.org/web/20201128232605/http://nim-lang-081.osdn.jp/
https://web.archive.org/web/20200928154858/http://nim-lang-081.osdn.jp/docs/manual.html

まあキャッシュ古すぎて更新追いついてないけど
231デフォルトの名無しさん
2022/11/02(水) 22:33:40.08ID:AEY2Eek1
https://ja.osdn.net/users/megumi_engines/projects/
このひとがオーナーになってるプロジェクトの1つみたいだけど、Twitterのアカウントも消えちゃってるね
プライベートが忙しくなったのかな
232デフォルトの名無しさん
2022/11/03(木) 15:08:48.38ID:lETVCa2o
Last Update: 2022-09-21 01:12
Nim プログラミング言語 - 非公式日本語版 (翻訳活動終了)に関する活動はすべて終了しました。リポジトリの再公開予定はありません。

理由はよう判らん
githubにfork無かったかな
233デフォルトの名無しさん
2022/11/04(金) 07:27:29.10ID:7DKhUjkg
日本語訳マニュアルの代わりになるかどうかはわからんけど
amazonで日本語のNim言語の書籍が売られてるよ。
234デフォルトの名無しさん
2022/11/05(土) 00:35:21.38ID:mvfmSa9B
当時高校生の描いたやつか
CやC++との連携について
一行しか描かれてなかったな
235デフォルトの名無しさん
2022/11/06(日) 13:47:02.47ID:4CeLTSQg
c2nim にがっかり感なんだけど
こんなもん?
それとも使い方間違ってる?
期待し過ぎ?
236デフォルトの名無しさん
2022/11/06(日) 16:29:46.57ID:zKDylNc8
単純化した具体例がないとなんとも
237デフォルトの名無しさん
2022/11/06(日) 16:42:07.10ID:06z0Icrt
わかっているのかもしれないけど、c2nimはどんなC言語のコードもNim言語に変換するものではない。C言語ライブラリをNim言語から使うためのバインディングをCのヘッダーファイルから生成するツールみたいなものだ。
c2nimに似たことができるこんなツールもあるよ。
https://github.com/PMunch/futhark
238デフォルトの名無しさん
2022/11/07(月) 12:40:52.04ID:1sAmX+SP
>>230
全く使えないキャッシュだな
239デフォルトの名無しさん
2022/11/07(月) 12:44:41.58ID:1sAmX+SP
>>229
3年前の nim 1.4.0だけど Nim日本語マニュアル
https://github.com/tauplus/nim_doc_ja
240デフォルトの名無しさん
2022/11/07(月) 13:21:56.37ID:V8od12Ai
ダメだこりゃ
みんなでzigに移動しよう
241デフォルトの名無しさん
2022/11/07(月) 14:15:04.63ID:xn4jxoWB
いーんだよ グリーンだよ
242デフォルトの名無しさん
2022/11/08(火) 12:57:20.87ID:CnIxTlte
template hoge(fuga: string): string =
fmt"{fuga}"

観たいなときに fuga が undeclared になるんだけどなんで?
243デフォルトの名無しさん
2022/11/08(火) 13:05:00.14ID:CnIxTlte
>>237
なるほど良さげ

Sounds great, what's the catch?
Futhark is currently in an alpha state.
It currently doesn't support C++, and it doesn't understand things like function-style macros.
It might also mess up on definition types I haven't seen yet in the small handful of libraries I've tested it against.
All of these things are things I hope to get fixed up.
244デフォルトの名無しさん
2022/11/08(火) 13:15:11.71ID:CnIxTlte
>>242 自己レス
出来ました本当にありがとうございました
template hoge(fuga: string): string =
block:
let injectedfuga {.inject.} = fuga
fmt"{injected_fuga}"
https://qiita.com/momeemt/items/000d1f6c384f4f00e103
245デフォルトの名無しさん
2022/11/08(火) 18:53:20.46ID:nCLZIP1Q
>>244
それは公式ドキュメントのここに書いてあるじゃないですか。
https://nim-lang.org/docs/strformat.html#limitations
246デフォルトの名無しさん
2022/11/08(火) 19:07:14.22ID:2BJbmpY0
Pythonスレでテンプレになってる内容をNim用に変更したので
次スレからはテンプレにしてください

-----ここから

Nimの★ソースコードをそのまま5ちゃんに貼るとインデントが崩れてチヌ★
【【【複数の連続半角スペースはなにもなかったことにされる&タブは普通には入れられない】】】掲示板の仕様なので、
プログラム文は↓等の、いわゆるコードうp用サイトに貼ってこいください。
https://glot.io/new/nim    結構使える。
https://play.nim-lang.org/   本家。
http://ideone.com/      デフォ設定はC用のため、言語選択ボタン押下がピコ手間かも。
http://pastebin.com/     まずまずシンプル。

-----ここまで
247デフォルトの名無しさん
2022/11/09(水) 22:27:24.03ID:5vHWfdFN
判り初めた my Revolution
248デフォルトの名無しさん
2022/11/10(木) 13:14:50.85ID:JZ2iIpp8
試してみた
本家 https://play.nim-lang.org/#ix=4ftO
スッキリ https://glot.io/snippets/gf9x33imvc
ダメぽよ(実行時エラー?) https://ideone.com/9BYjHA (たまに死ぬよねこのサイト)
貼るだけ? https://pastebin.com/07h9Zjrx

ideoneがダメなのはバージョンの問題?
249デフォルトの名無しさん
2022/11/10(木) 13:25:08.92ID:JZ2iIpp8
これで逝けました
https://ideone.com/HBEKZu
pragmaのNimNodeを指定出来なかったらしい
ideone の Nim は (nim 0.19.4)
250デフォルトの名無しさん
2022/11/10(木) 14:16:57.58ID:JDmtuJFO
https://wandbox.org/
251デフォルトの名無しさん
2022/11/10(木) 15:04:27.30ID:JDmtuJFO
↑のWandboxでも最新の安定版Nimを使えるしコードを共有できる。
252デフォルトの名無しさん
2022/11/10(木) 15:55:36.21ID:hnXF7Xx/
ここまでのまとめ
https://glot.io/new/nim    結構使える
https://wandbox.org/ 最新のNim使える
https://play.nim-lang.org/  本家
http://pastebin.com/      ソース貼り付けのみ
253デフォルトの名無しさん
2022/11/10(木) 16:23:45.65ID:j+QMfGd1
やっぱオフサイドスタイルはクソかよ。
254デフォルトの名無しさん
2022/11/10(木) 16:52:41.86ID:JZ2iIpp8
>>250
wandboxだと(っていうかそれ以外でもかもだけど)
実行ボタンの上に
$ nim c ./prog.nim
って表示されてて c を cpp に変更したくても出来ない
左上の「コンパイルオプション」らしい枠に cpp を入れると
$ nim c ./prog.nim cpp
になったわ
255デフォルトの名無しさん
2022/11/10(木) 20:00:36.53ID:JDmtuJFO
>>254
確かにwandboxだとnim cppでコンパイルできないっぽいね
もしかしたらgithubのwandboxリポジトリに要望を出せば対応してくれるかもしれない。もしくは自分で機能を実装してpull requestを出すか
256デフォルトの名無しさん
2022/11/11(金) 10:16:18.33ID:8dOB0zbX
ここは未完成なのかな
日本語マニュアルっぽいけど
https://2vg.github.io/Nim-World/
257デフォルトの名無しさん
2022/11/12(土) 14:40:51.16ID:OIoQvXCU
自分で育てる感覚楽しいですね
258デフォルトの名無しさん
2022/11/15(火) 13:26:12.68ID:QGmQMBHU
type
Hoge* = object
fuga*: int
としないで
type
HogeObj* = object
fuga*: int
Hoge* = ref HogeObj
とするのは必須?習慣?
前者のデメリットは DeepCopy だというのは判るのですが
毎回後者を使った方が良い?
259デフォルトの名無しさん
2022/11/16(水) 09:07:52.80ID:qCq9+PtI
{.byref.} じゃね?
260sage
2022/11/16(水) 13:30:51.35ID:4BSq9VuL
横からだが
>>259 のbyrefと >>258 は完全に等価?
261デフォルトの名無しさん
2022/11/16(水) 15:57:06.50ID:z+sJwdsY
proc 読んだとき ref のフリをする fake が 259
262デフォルトの名無しさん
2022/11/16(水) 18:16:18.08ID:kOxph/zs
ref objectは一つのオブジェクトを複数のオブジェクトから参照したいときや継承使ってオブジェクト指向なコードを書くときに必要となる。
それ以外の場合はrefのついていないobjectのほうが速くなることが多い。
ref型は常にヒープに確保されポインタ経由でアクセスされるけどobjectだとスタックに確保できるしポインタで間接的に参照する必要もない。
object型のseqだとメモリ上に連続して確保されるけどref object型のseqにするとメモリ上に連続して確保されるとは限らないからキャッシュミスが起きやすくなる。
ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるからコピーのコストが問題になることがあんまりないと思うよ。
C++で言えばobjectはstructをそのまま使っている感じでref objectはstructをstd::shared_ptrごしに使っている感じ。
263デフォルトの名無しさん
2022/11/17(木) 09:41:27.60ID:V4QZv0Fq
proc incx(i: int): int =
let j = i
{.emit: "++j;".}
result = j

echo incx(5)

https://glot.io/snippets/gfgq0p65a6
let で定義された変数も書き換え可能なんですね素敵ですね
264デフォルトの名無しさん
2022/11/17(木) 09:41:55.68ID:V4QZv0Fq
>>259-260
全く別物
265デフォルトの名無しさん
2022/11/17(木) 09:45:16.34ID:V4QZv0Fq
>それ以外の場合はrefのついていないobjectのほうが速くなることが多い。

これはどうかなぁ
遅くなることの方が多いと思うが
266デフォルトの名無しさん
2022/11/17(木) 10:53:32.89ID:hYmfXxMP
>>265
どうしてrefのついてないobjectのほうが遅くなる場合が多いの?
267デフォルトの名無しさん
2022/11/17(木) 14:28:18.19ID:hYmfXxMP
>>263
emit pragma使っているんだからNimの安全性は無効になる。
rustでunsafeを使うようなもの。
268デフォルトの名無しさん
2022/11/17(木) 15:18:49.83ID:fBlcqeZM
>>262
>ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるから

ってことは {.byref.} 描く必要無い?
269デフォルトの名無しさん
2022/11/17(木) 17:33:28.89ID:7oSKGzG8
>>268
自動でやるのは関数の引数にオブジェとを渡した時だから
それ以外にコピーが頻繁に発生しないなら
byrefいらないんじゃね?
270デフォルトの名無しさん
2022/11/17(木) 18:51:38.00ID:hYmfXxMP
>>268
https://nim-lang.org/docs/manual.html#procedures-var-parameters

var parameters are never necessary for efficient parameter passing. Since non-var parameters cannot be modified the compiler is always free to pass arguments by reference if it considers it can speed up execution.
って書いてあります。
271デフォルトの名無しさん
2022/11/17(木) 19:03:15.70ID:hYmfXxMP
>>268
https://nim-lang.org/docs/manual.html#foreign-function-interface-byref-pragma

Nim manualではbyref pragmaがForeign function interfaceの章の下にある。
つまりbyref pragmaはC/C++の関数に引数をポインタ渡ししなきゃいけないときに使うもの。
それ以外のときに使う必要性はほぼ無いってこと。
272デフォルトの名無しさん
2022/11/17(木) 21:39:23.14ID:ArWNCDPA
>>265
そんな速度差気付くことある?
273デフォルトの名無しさん
2022/11/18(金) 05:58:57.10ID:AmxJEdx7
君らスタックの消費は気にならんのけ?
274デフォルトの名無しさん
2022/11/18(金) 06:16:37.43ID:IYaGyAsl
>>273
10kバイト以上のでかいobjectをたくさん使うとかならスタックを使わないようにref objectにしてヒープに確保してもいいと思う。
けどそんなにでかいobject型のローカル変数をたくさん使うことってあんまりないきがするけど。
275デフォルトの名無しさん
2022/11/18(金) 09:39:59.23ID:IJuokuF8
たとえば
https://qiita.com/dumblepy/items/8d13592d6760d0155d89
>オブジェクトの宣言にはref objectを使います。
>Nimでは関数の引数に入れられた変数の容量に応じてコンパイラが自動で値渡し/参照渡しを調節しますが、
>これは挙動の予測が付かずバグの原因になりえます。
>ref objectでオブジェクトを宣言していれば必ず参照渡しになるので、
>アプリケーション開発ではこちらに統一しましょう。

みたいなことが
276デフォルトの名無しさん
2022/11/18(金) 10:17:44.40ID:IJuokuF8
問題無い訳ではないとも
https://flat-leon.はてぶろ.com/entry/nim_arg_pass
バージョンや記事の年代に気を付けないといかんのかね
277デフォルトの名無しさん
2022/11/18(金) 11:42:20.25ID:IJuokuF8
古いけどここの議論は判り易い
https://forum.nim-lang.org/t/1207
278デフォルトの名無しさん
2022/11/18(金) 11:48:22.19ID:ygRIcUIa
>>270
それは var の説明であって ref の説明ではないですね
279デフォルトの名無しさん
2022/11/18(金) 12:02:19.50ID:IYaGyAsl
>>275
>>278
refのついた型またはvar引数は常に引数を参照渡し(ポインタのコピー)する。
refやvarがついてない場合は引数のサイズにあわせてコピー渡しか参照渡しになるが、どちらにせよプロシージャ内で引数を変更するのは禁止
280デフォルトの名無しさん
2022/11/18(金) 12:10:00.28ID:IYaGyAsl
だからデフォルトの引数の渡し方でそれがコピー渡しになろうが参照渡しになろうがそれで挙動が変わったりバグの温床になることはない。
ただしaddrとかemit, Assembler statementなどのNimが安全性を保証してない機能を使う場合は例外だ。
281デフォルトの名無しさん
2022/11/18(金) 12:24:09.04ID:IJuokuF8
参照とか reference とか同じ名前だから混同してるのかも知れないが
Nim の参照型と C++ の参照型は全く別物
C++ の引数で使う参照型 & は Nim では var の方が近い
Nim の ref は C++ ではポインタ * と思った方が良い
Nim では
GC で管理されるポインタが ref
GC で管理されないポインタが ptr
282デフォルトの名無しさん
2022/11/18(金) 17:46:16.11ID:PNsYUFFf
これ使うか使わないかでも全然違うのよね --gc:arc
283デフォルトの名無しさん
2022/11/18(金) 18:35:09.65ID:yVVkBIHa
最近は --mm:arc
284デフォルトの名無しさん
2022/11/19(土) 16:28:59.40ID:F8GIHVyH
--mm:orc 推奨
285デフォルトの名無しさん
2022/11/19(土) 17:55:05.22ID:lavOlnrp
Nim2では--mm:orcがデフォルトになるらしいぞ。
みんな知ってると思うけど--mm:arcだともし循環参照があったときにメモリリークするぞ。
286デフォルトの名無しさん
2022/11/19(土) 19:05:39.54ID:7QNjN12J
Nim2なんて10年以上先
287デフォルトの名無しさん
2022/11/20(日) 10:26:07.81ID:MUgzJmMj
>>275 のリンク先なんか
「Nimでアプリケーション開発をするための設計のベストプラクティス」
みたいにイキってるけど
信用していいの?
288デフォルトの名無しさん
2022/11/20(日) 11:36:46.79ID:h2bm0L4T
object type 全部 ref 付けろ教のひと
たまにいるよね
迷惑
289デフォルトの名無しさん
2022/11/21(月) 13:35:10.22ID:LzW8OiBh
割と実用になるわね
https://pastebin.com/Ry2wTRHi
290デフォルトの名無しさん
2022/11/22(火) 09:38:49.09ID:E0zMoWY7
理由を示さないお作法は無視していい
291デフォルトの名無しさん
2022/11/24(木) 09:24:22.39ID:qRYWlPaY
なんでもかんでもref付けろと
しつこく強要してる人は
あたまおかしい
大抵は{.byref.}で用足りる
292デフォルトの名無しさん
2022/11/24(木) 15:02:15.10ID:7i9tpoXw
{.byref.}はnimからC/C++の関数を使うときに引数をポインタで渡しているときに使うもの。
それ以外では使う意味はないよ。
Nimはちゃんと最適な方法で引数を渡すから必要でもないのに{.byref.}とかvarとかつける必要はない。
293デフォルトの名無しさん
2022/11/24(木) 18:37:53.45ID:m+x+kPsJ
var も ref も byref も全部別物だと何度言えば判るんだ?
294デフォルトの名無しさん
2022/11/24(木) 18:42:50.52ID:RL/H9YUN
>>293
みんなが必ず遭遇する問題なので
短くまとめて次スレからテンプレにするのが良い
以下 >>293 のテンプレが続く
295デフォルトの名無しさん
2022/11/25(金) 09:06:20.12ID:PV2ZG9bu
{.byref.}をrefと間違うのは判らんでもないし同情するが
{.byref.}をvarと間違う香具師は初めて観た
296デフォルトの名無しさん
2022/11/25(金) 16:53:59.56ID:s0hi6gQd
nim 1.6.10 出た

1.6.98 まで行くのかw
297デフォルトの名無しさん
2022/11/27(日) 12:26:56.31ID:IMKjsn3J
regexどれ使えば良いの?
298デフォルトの名無しさん
2022/11/27(日) 16:05:43.13ID:/+GS7DyS
>>297
好きなのでいいんじゃ ?
299デフォルトの名無しさん
2022/11/27(日) 17:37:23.28ID:1IfwvG7/
>>297
Nimでは正規表現よりPEGのほうがおすすめらしい。
https://nim-lang.org/docs/pegs.html

PEG (Parsing expression grammar) is a simple deterministic grammar, that can be directly used for parsing. The current implementation has been designed as a more powerful replacement for regular expressions. UTF-8 is supported.
300デフォルトの名無しさん
2022/11/28(月) 05:25:04.28ID:T/4+TPza
300
301デフォルトの名無しさん
2022/11/29(火) 12:04:17.71ID:+WMggzr1
pythonのStringIOとかBytesIOみたいなのは無い?
302デフォルトの名無しさん
2022/11/29(火) 14:03:26.53ID:lz77OQ93
>>301
FileStreamとStringStream かも
https://nim-lang.org/docs/streams.html
303デフォルトの名無しさん
2022/12/02(金) 09:32:24.76ID:ef8lBYgh
https://nim-lang.org/docs/streams.html を観ると
FileStream = ref FileStreamObj ← 判る
FileStreamObj = object of Stream ← 判らん
StringStream = ref StringStreamObj ← 判る
StringStreamObj = object of StreamObj ← 判る
Stream = ref StreamObj ← 判る
StreamObj = object of RootObj ← 判る

なんで
FileStreamObj = object of StreamObj
になっていないのでしょう?
意図を知りたいです
304デフォルトの名無しさん
2022/12/02(金) 09:38:11.16ID:ef8lBYgh
https://github.com/nim-lang/Nim
lib/pure/streams.nim の type を観ても
FileStream のだけ
FileStream* = ref FileStreamObj
FileStreamObj* = object of Stream
でした
305デフォルトの名無しさん
2022/12/02(金) 17:15:15.76ID:Ojlf0I9F
命名の推測で「WHY?」という話なら、ofキーワードの後に来るのが、必ずxxxObjという規約ではないから。

目的としてxxxObjでないのは、それを扱いやすくするためでStringStreamやStreamはそのまま宣言したり
引数に渡したり、戻り値の型として記述して使用するのに対してxxxObjは普通にライブラリの使用者は
めったに直接的に使用しない。(ライブラリの設計者・実装者は普通に使う)
例を言えば、MemMapFileStream、ReadSocketStreamなども利用者は直接的に使用するが、いずれも
ストリーム系だがobject of の後にくるものは違う。

例えば、利用者はプロセスの出力をStreamで使用するなら、このようなprocを使う
proc outputStream*(p: Process): Stream

これを、クライアントプログラムの実装者が受け取る変数の定義でStreamObjと書いていたらおかしい。
APIドキュメントには、「最も使用される一般名称にはそのままの名前を付ける」としか書いてないが
Nimに限らず一般的に、1つか少数の抽象名と数多くの具象名は一般名称でプレ・サフィックスは付けない
https://nim-lang.org/docs/nep1.html
When naming types that come in value, pointer, and reference varieties, use a regular name for the variety that is to be used the most, and add a "Obj", "Ref", or "Ptr" suffix for the other varieties. If there is no single variety that will be used the most, add the suffixes to the pointer variants only. The same applies to C/C++ wrappers.

似た話にxxxRefがあるがこちらはref objectに単に付けるが、型名をあまり使用しない場合で、なおかつ
ref objectであることを強調する場合が多い。
StringTabeRef* = ref StringTabeObj
var tbl = newStringTable(...)
306デフォルトの名無しさん
2022/12/02(金) 18:20:09.03ID:hfqW6J8Y
https://play.nim-lang.org/#ix=4hrl
継承するときに基の型についてるrefは無視されるようなので
objectかref objectのどちらから継承しているかは重要ではないようだ。
307デフォルトの名無しさん
2022/12/03(土) 14:54:39.83ID:H3EtATlx
>>306
なるほど!
308デフォルトの名無しさん
2022/12/08(木) 15:32:48.39ID:0CftMozc
template とか macro とか使うと
流れる様にさらさら描けて気持ち良いわコレ
309デフォルトの名無しさん
2022/12/12(月) 07:08:32.93ID:pbYUfvW7
templateとmacroを上手くに使えるようになりてえなあ☹
310デフォルトの名無しさん
2022/12/13(火) 09:48:40.02ID:xx5dSLzS
こんな感じのmacroを書いていろんなコードを与えてみよう。
コンパイル時にecho x.treeReprの出力が表示される。
それを読めばNimのコードはAST(抽象構文木)になることが理解できると思う。
これがNimのmacroを理解する第一歩だと思う。

import std/macros

macro test(x: untyped): untyped =
 echo x.treeRepr

test:
 echo "test"

後はこれを読めばok
https://nim-lang.org/docs/manual.html#macros
https://nim-lang.org/docs/macros.html
311デフォルトの名無しさん
2022/12/14(水) 10:22:41.84ID:LLXuibjV
macro は AST 知ってると有利だね
あと head と body を受け取るタイプのと
node を受け取るのと
static type を受け取るのとか
区別して理解しないと
自分が何やってるのか判らなくなる
312デフォルトの名無しさん
2022/12/14(水) 15:44:32.71ID:SCwOJhsV
へぇ、それはクソ仕様だね
313デフォルトの名無しさん
2022/12/14(水) 21:28:27.69ID:XhtdH9iq
node造る関数も直交性が無いな
314デフォルトの名無しさん
2022/12/17(土) 10:10:45.75ID:a3CJqZUP
直交性という言葉を知ってるオジサン・・・
C/C++言語の#def, #include→別言語(直交性100%)、錆びのprintln!→実は別言語(直交性100%)
むしろこれは言語が習得で異なる仕様の言語を2つ覚えないといけない、敷居を高くする欠点
315デフォルトの名無しさん
2022/12/17(土) 10:46:30.65ID:2DPGsS1m
NimNodeはseqに近い方法で扱えるようにmacrosモジュールにプロシージャが定義されているのはいいことでは。
316デフォルトの名無しさん
2022/12/17(土) 12:04:27.61ID:OfpYIbSc
untyped は obsoleted
317デフォルトの名無しさん
2022/12/17(土) 18:07:52.62ID:GzYo/1Xm
今はNimNodeじゃなく、quote do:で書くのが良いよな。どうしてもNimNodeじゃなきゃ書けないマクロもあるだろうけどね
318デフォルトの名無しさん
2022/12/17(土) 19:18:25.81ID:2DPGsS1m
>>317
https://nim-lang.org/docs/genasts.html
https://github.com/nim-lang/Nim/pull/17426
https://github.com/nim-lang/RFCs/issues/122
319デフォルトの名無しさん
2022/12/22(木) 07:38:06.92ID:Fm5nn8iV
最初のrelease candidate for Nim v2.0が公開されました。
https://nim-lang.org/blog/2022/12/21/version-20-rc.html
320デフォルトの名無しさん
2022/12/22(木) 10:51:20.76ID:Y6cO6Ymu
ペース早いよなあ
321デフォルトの名無しさん
2022/12/22(木) 10:52:43.57ID:N8bfJDIh
nim-2.0 RC1 がリリースされた
https://nim-lang.org/blog/2022/12/21/version-20-rc.html

来年1月か2月には正式2.0になるのかも
322デフォルトの名無しさん
2022/12/23(金) 02:05:06.61ID:PNJSSvHF
もう2.0かよ(´・ω・`)公開してるライブラリ大丈夫かな
323デフォルトの名無しさん
2022/12/23(金) 20:17:33.78ID:244A80LW
バージョンが大きく変わって大丈夫と思う方が
無理がある
324デフォルトの名無しさん
2023/01/16(月) 16:24:59.02ID:MsfEWWA2
あっという間に2月
325デフォルトの名無しさん
2023/01/23(月) 22:52:56.91ID:NHwV5soq
書き込みが1ヶ月に1回しかないスレ w
326デフォルトの名無しさん
2023/01/26(木) 03:28:17.45ID:To7TXanK
Nim言語を使っていても特につまづくことがないから話題があんまりないんだよね。
327デフォルトの名無しさん
2023/01/26(木) 18:39:32.28ID:MzjwjnoQ
使用者の絶対数が少なすぎ
328デフォルトの名無しさん
2023/02/01(水) 01:23:34.72ID:p1uaZW7X
てすと
329 【だん吉】
2023/03/01(水) 09:22:10.73ID:68s28u+f
!omikuji
330デフォルトの名無しさん
2023/03/01(水) 12:20:14.81ID:q8rzgPd8
初心者はys3mとかrs3mで十分

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

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

https://www.ziicube.com/Moyu-333-HuaMeng-YS3M
331デフォルトの名無しさん
2023/03/01(水) 12:20:39.02ID:q8rzgPd8
>>330
誤爆
332デフォルトの名無しさん
2023/03/05(日) 11:11:16.11ID:/Qd0pRlS
WinnyとNimってネーミングセンス似てるね
333デフォルトの名無しさん
2023/03/05(日) 19:55:40.66ID:gl/xkADq
>>332
Nimは元々Nimrodっていう名前だったんだけどその由来は
https://forum.nim-lang.org/t/9591#63054
334デフォルトの名無しさん
2023/03/06(月) 14:19:57.93ID:diWxUEyJ
https://www.cosme.net/product/product_id/10190076/top
335デフォルトの名無しさん
2023/04/03(月) 17:59:13.21ID:dNC7VYHk
この言語ってRustみたいにプログラマに押し付けるmutなんて使ってないのに、なんでいわゆるMove操作が勝手に出来るの?
説明しろください!
336デフォルトの名無しさん
2023/04/03(月) 18:32:57.47ID:3grB/pQG
>>335
こちらの資料には目をとおされましたか?
https://nim-lang.org/docs/destructors.html
337デフォルトの名無しさん
2023/04/09(日) 09:29:43.33ID:Dm0aM9sg
Nim良いよね
Rustは宣伝がうざいだけだが
Nimは判ってる人の間でまったり進化してくれ
338デフォルトの名無しさん
2023/05/04(木) 21:15:01.62ID:wwnsNcS0
公式読めばだいたいのことはわかるから特にここでも議論は出ないよね
唯一日本語の書籍がもう一冊くらい欲しいなあくらい
339デフォルトの名無しさん
2023/05/06(土) 09:24:18.50ID:u7gslL5e
importとincludeの違いってなに?
340デフォルトの名無しさん
2023/05/07(日) 06:11:02.39ID:uVIPnqNg
>>339
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#import-statement
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#include-statement
341デフォルトの名無しさん
2023/06/28(水) 19:11:48.73ID:cQY5DEV3
Nim言語 1.6.14 リリース
https://nim-lang.org/blog/2023/06/27/version-1614-released.html
342デフォルトの名無しさん
2023/07/02(日) 18:18:52.72ID:4yDce2PB
夜遅くにすいません。
SyntaxHilighter用のNim Brushってどっかにありませんか?
343デフォルトの名無しさん
2023/07/02(日) 18:34:57.51ID:DcMb4mOQ
>>342
話の内容が全然理解できないけど。。。
344デフォルトの名無しさん
2023/07/02(日) 21:16:17.65ID:w86HyNV3
>>343
ごめんなさい。
SyntaxHighlighter でした。
345デフォルトの名無しさん
2023/07/02(日) 21:56:05.97ID:DcMb4mOQ
>>344
SyntaxHighlighter っていうのがよくわからないけど
VSCode拡張とかのこと?
346デフォルトの名無しさん
2023/07/03(月) 07:33:58.97ID:VgAxDpje
>>345
えぇエ~それぐらいネットで調べ「てく」ださいよ~~。
伝えるのめんど「い」し、説明上手くないからネッ-トで調べた方が絶対%絶対%にわかると思うんですよね。
お願いしますよ~~
347デフォルトの名無しさん
2023/07/03(月) 10:05:16.82ID:erf1sDFe
>>346
うわぁ~
怖い

引っ込んでます
348デフォルトの名無しさん
2023/07/03(月) 12:35:43.48ID:VgAxDpje
>>347
恐がらせてごめん。
349デフォルトの名無しさん
2023/07/04(火) 04:16:26.79ID:YbUZ4vjn
Nim言語はコンパイル時にreadFileとwriteFileを使えるんだけどコンパイル時にファイルを読み書きできるプログラミング言語ってあまりないんじゃないか?
staticExecていうコンパイル時にコマンドを実行できるプロシージャもあるし。
350デフォルトの名無しさん
2023/07/07(金) 02:08:00.59ID:B1cwSpdy
どっかで既出かもしれんけど、結局VSCの拡張は何入れれば安牌?
351デフォルトの名無しさん
2023/08/01(火) 18:27:12.50ID:JtUN40O9
https://github.com/nim-lang/Nim/releases/tag/v2.0.0
352デフォルトの名無しさん
2023/08/02(水) 00:52:58.78ID:4aCNkU8+
Nim 2.0がリリースされました。
https://nim-lang.org/blog/2023/08/01/nim-v20-released.html
353デフォルトの名無しさん
2023/08/26(土) 23:20:45.36ID:6K2VICrE
初めてお邪魔します

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

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

Qiita 3 - キータぞ、来たぞ、キータだぞー
http://2chb.net/r/tech/1685235361/368-371
http://2chb.net/r/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
354デフォルトの名無しさん
2023/08/27(日) 00:54:05.78ID:M561FwxM
>>353
Nimでコンパイルするときに'--listcmd'オプションを与えるとNimがgccを呼び出すときにどんな引数を渡しているか表示されるようになります。
もしかすると凄く最適化されるようなオプションを渡しているのかもしれません。
355デフォルトの名無しさん
2023/08/27(日) 01:58:10.81ID:CxwZcjGE
>>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 になりましたが、実効速度はダントツに速いままでした
何か気が付く点がありましたらまた今度教えてください (私の方は今日は限界です...)
356デフォルトの名無しさん
2023/08/27(日) 17:22:00.42ID:P6KX7G/o
>>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

コンパイル型言語のベンチを取る時は再帰処理コードは
避けた方が良いと思います
357デフォルトの名無しさん
2023/08/27(日) 17:25:13.06ID:P6KX7G/o
>>356 追記
末尾再帰になっている可能性もありかな
358デフォルトの名無しさん
2023/08/27(日) 22:36:37.59ID:M561FwxM
Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
gccは再帰関数をループに置き換えているかもしれないからその確認をしたかったら-S -masm=intelを付けてアセンブリコードを出力させて読んでみよう。
359デフォルトの名無しさん
2023/08/28(月) 06:30:35.88ID:eKgmQu1D
>>356
変換キャッシュの見方、ありがとうございます

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

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

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

再帰fibonacciは個別の言語コンパイラ(更にバージョン)の
最適化ベンチマークには持って来いに見えますので
360デフォルトの名無しさん
2023/08/28(月) 06:40:36.37ID:eKgmQu1D
>>358
>Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
その通りでした

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

gccがノイズを消すために最適化を頑張った結果、Cより速くなったのですかね
361デフォルトの名無しさん
2023/08/28(月) 06:47:48.48ID:eKgmQu1D
何気に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の最適化が凄すぎて意味わからないですが、ありがたく享受する事にします
362デフォルトの名無しさん
2023/09/06(水) 06:10:42.54ID:8VjD58re
レバテックωωω
Rust in
Nim out
ωωωωωω
363デフォルトの名無しさん
2023/11/15(水) 08:06:37.71ID:6Kiw7POr
>>349
F#が、 F# Dataってライブラリで、コンパイル時に
ファイルの読み取りは、やってたけれど、あまり見かけないね。
364デフォルトの名無しさん
2023/11/28(火) 09:23:46.10ID:XbNpNPYt
happyxってdjungoの上位互換なれねーかな
https://hapticx.github.io/happyx/#/
365デフォルトの名無しさん
2023/12/06(水) 09:31:30.20ID:oM0gjrfW
>>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 は我々に教えてくれます
366デフォルトの名無しさん
2023/12/06(水) 20:32:47.84ID:7Cu2FhSW
Nim って python を強調し過ぎてるのはミスリードだと思うな
python と相性が良いってのは事実だけど Nim の特徴のほんの一部でしかない
367デフォルトの名無しさん
2023/12/08(金) 21:38:37.62ID:xBCOoZoU
>>366
Python使える人が多いからNimを広めるためにNim言語はpythonと同じだという人は多い。
文法がpythonに近いだけで中身は静的型言語だからpythonよりC++とかRustに近いと思う。
pythonしか知らない人がNimのオーバーロードとかGenericsとかobjectとref objectの違いとかちゃんと理解して使えるのかどうか心配になる。
368デフォルトの名無しさん
2023/12/10(日) 11:41:19.18ID:1MxEINjf
「文法がpythonに近い」が事実じゃないんだよな
観た目が似てるだけであって文法が似てる訳じゃない
全然別物
369デフォルトの名無しさん
2023/12/10(日) 17:02:37.56ID:S5Hrhavn
そういう意味では構文で結構損してそう
オフサイドルールが気に入らない人にとってはそもそも検討に値しないし
Python好きな人ならそこは気にならないだろうけど、別に移行しやすくもない
370デフォルトの名無しさん
2023/12/11(月) 04:52:12.28ID:E9pPgJ3z
>>369
でも静的型言語でオフサイドルールの言語はNimとcrystal以外あまりないのでは。
オフサイドルールが好きで型システムがちゃんとしていて高速に動くプログラムを書きたい人にはぴったり。
371デフォルトの名無しさん
2023/12/11(月) 06:10:19.79ID:dU0p99Eo
型で安全性を静的に担保したいと考える人が、同時にインデントで意味が変わってしまうオフサイドを好むってのはちぐはぐさを感じる
372デフォルトの名無しさん
2023/12/11(月) 06:46:36.74ID:Oijs0Efp
HaskellとデフォルトF#もオフサイドルールありですね。どうせインデントするんだしって使ってやれってくらいの感じなのかね?

あとは、インデントに意味はないけれど、goが標準のフォーマッタでインデント入れてくるね。
373デフォルトの名無しさん
2023/12/11(月) 06:54:57.74ID:n3cFiyWX
Python登場当時だと{}前後のどこで改行するか論争みたいなのがあったりして確かに括弧書くのが面倒な空気はあったんだよな
それがGo/Rustの世代だと言語標準のフォーマッタが勝手にやってくれるってなって
めんどくさくないっていうオフサイドのメリットはなくなってしまった
そうすると自動フォーマットしづらいとかコピペしづらいとかデメリットばかり目立つことになってしまう
374デフォルトの名無しさん
2023/12/12(火) 04:50:08.02ID:X9wYEqIf
ブロック毎に'{}'や行末に';'があるとソースコードが少し汚く見えるし
無いとすっきりして読みやすいと思うけどね。
375デフォルトの名無しさん
2023/12/12(火) 05:58:22.17ID:6YpoyKxr
そんなの単なる慣れ
376デフォルトの名無しさん
2023/12/12(火) 08:04:30.17ID:BxX9TTWN
まぁ人によるんじゃない
自分は{}がある方がブロックの識別性が良くて読みやすい
オフサイドは特にネストしたブロックの戻りが何段戻ったか見づらいんだよな
377デフォルトの名無しさん
2023/12/12(火) 08:08:33.42ID:BYtUbVYs
カッコありなら、lisp系が好き。
悩む事が減る。
378デフォルトの名無しさん
2023/12/12(火) 13:00:45.46ID:GxOznL1S
>>374
セミコロンはオフサイドルールじゃなくてもRuby/Go/Kotlin/Swiftのように無しできるから関係ないよね

それにセミコロンをタイプするのは面倒だとは思うが慣れると読む時のノイズにはならない
自然言語の文章で句点やピリオド+改行がノイズにならないのと同じこと
379デフォルトの名無しさん
2023/12/12(火) 19:48:14.86ID:X9wYEqIf
CやC++を10年以上使っていたけど';'や'{}'が無いほうがすっくりして読みやすいと思うから慣れでどうにかなるものでは無いと思う。
こういうのは個人差があるのかもしれないが
380デフォルトの名無しさん
2023/12/12(火) 19:54:02.65ID:X9wYEqIf
https://github.com/jeetsukumaran/vim-indentwise
このVimのプラグインを使うと同じインデント間のカーソル移動、異なるインデント間のカーソル移動が簡単にできるからお勧めです。
381デフォルトの名無しさん
2023/12/12(火) 22:53:30.64ID:wCEkJKJx
>>379
CやC++やっててそんなこと言うやつ初めて聞いたぞ
本当に日々コード書いてる?
382デフォルトの名無しさん
2023/12/12(火) 23:44:06.92ID:CyOM3fCk
そりゃ仕事で使える言語でオフサイドルールなのってPythonくらいだし
ほんとはオフサイドがいいけどC/C++の仕事してるって人くらいいるでしょ
383デフォルトの名無しさん
2023/12/13(水) 00:18:56.36ID:YitMt0Fm
>>382
{}や;がノイズになるかどうかと
オフサイドがいいかどうかの話は別だよ
384デフォルトの名無しさん
2023/12/13(水) 04:42:50.35ID:/pcasGi0
>>381
今はC/C++殆ど書いてないけど以前はほぼ毎日使ってたよ。
{}や;に慣れてもやっぱり余計な文字が少ない方がすっきりして読みやすいと思うのだが、そういう人は少数派なんかな?
385デフォルトの名無しさん
2023/12/13(水) 05:36:33.39ID:R3z2LBuJ
主観で読みやすいかどうか力説しても結論でるわけない
オフサイドは誤ってインデントずれても気付かないままになってしまうのが問題
386デフォルトの名無しさん
2023/12/13(水) 06:48:31.89ID:RhfHz66O
>>384
まぁ実際オフサイド採用の新規言語ってあまり出てこないし
少数派なんじゃないかな
387デフォルトの名無しさん
2023/12/13(水) 07:21:31.19ID:vQeZuGNk
f#みたいに、使う側が選択できれば、解決なんじゃない?
388デフォルトの名無しさん
2023/12/13(水) 07:35:42.19ID:q/L8o2wk
やれやれお前らCOBOLを知らんのか
389デフォルトの名無しさん
2023/12/13(水) 11:38:44.64ID:rzHxkjlX
>>384
どちらの方がすっきりして読みやすいかと
{}や;が思考ノイズになるかどうかは別だよ

前者はそれなりにいる
後者はツチノコレベルで稀有
390デフォルトの名無しさん
2023/12/14(木) 19:26:43.32ID:xAMEKx/6
エディタの色設定で{};を薄い色にすればいいだけやん
391デフォルトの名無しさん
2023/12/15(金) 03:05:56.17ID:/ClHmJDY
{}がノイズになるようなら:や=はもちろんのことblock:なんて発狂ものだろうからNimは無理やろな
392デフォルトの名無しさん
2023/12/15(金) 05:55:25.21ID:12rLPAnL
思考ノイズって
エロい事連想してるって意味だよな?
393デフォルトの名無しさん
2023/12/15(金) 06:50:06.26ID:4QMbv0z8
Nimってオフサイドルール以外の所は目立った欠点の無い言語なんかな。
それに実際にオフサイドルールでコードを書いていて困ったことないし。
インデントがずれても困るという人はインデントの幅をスペース4個とか広めにすればいいのでは
394デフォルトの名無しさん
2023/12/15(金) 17:55:10.13ID:BxRUp1+8
オフサイドルールは欠点だらけ

Pythonを例にすると
- カットペーストは命がけ
- ネット等で共有しにくい
- テキストエディタやIDEの支援が激弱
- dedentは手動タイピング必須
- 改行のために追加の()や\が結局必要
- インデントだけでは可読性が低いから余計な:が必要
- 空行の数まで厳密に意識する必要もある
- lambdaのone expression縛りのように言語の成長を阻害しやすい
- “explicit is better than implicit”と言いながらブロックはimplicit
395デフォルトの名無しさん
2023/12/15(金) 18:18:19.69ID:b3hxnew5
次は、良い点を挙げてみて!
396デフォルトの名無しさん
2023/12/15(金) 18:24:50.43ID:pkr2dCwK
>>395
プログラミング初心者を釣れる
以上
397デフォルトの名無しさん
2023/12/15(金) 20:46:34.27ID:4QMbv0z8
Vim使ってるけどコピペは問題無くできるしインデントの深さもブロックごと'>'で調整できる。
vim-indentwiseでブロック毎カーソル移動可能。
スペース一個分だけでインデントするとかしない限りブロックの開始、終わりは前後の行のインデントの位置の違いでわかる。
vim-indentwiseでカーソル移動すればブロックの範囲も簡単にわかる。
以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。
Nim書いていて改行のために追加の()や\が必要になることはほぼ無い
空行の数を厳密に意識する必要もない。
Nimを実際に書いたことあるの?
398デフォルトの名無しさん
2023/12/15(金) 21:02:40.08ID:4QMbv0z8
https://wandbox.org/permlink/Nfe6exUFmtWPdWZj
NimのAnonymous proceduresでは複数行書けるし
こうしてコードを共有できてる。
399デフォルトの名無しさん
2023/12/15(金) 22:17:03.24ID:kBMLRaUx
>>398
でもアロー関数にすると()を追加するなどしないと1行しか書けなくなる
これもオフサイドルールのせい
しかもこんな明らかなバグでも修正しようともしない
言語の成長を阻害するとはこういうこと
400デフォルトの名無しさん
2023/12/15(金) 22:29:33.41ID:kBMLRaUx
>>397
論点理解せずにvim使いなら誰でも知ってる基本を必死に解説されても困るわ

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

ついでに言うとセミコロン無い方が書きやすいのは当たり前のこと
だから新しい言語の多くがセミコロンレスを採用してる(オフサイドは採用しないけど)
401デフォルトの名無しさん
2023/12/15(金) 23:45:28.85ID:4QMbv0z8
>>399
アロー関数ってNimのsugarモジュールにある`=>`マクロのこと?
あくまでこの=>は二項演算子だから両辺は式になっていないといけない。
オフサイドルールに関係無く二項演算子の両辺に文を直接書けず式を置かないといけないのは殆どのプログラミング言語で同じじゃない?
複数文を書きたければanonymous procedureで書けばよいし。
オフサイドルールじゃない言語で無名関数に複数文を書くときは必ず{}で囲む必要があるし。
どうしてこれが言語の成長を阻害していることになるの?
明らかなバグなのに修正しようとしないって言うけどGithubのNimのリポジトリにそういうissueある?
無名関数を書くときはdo notationというのもあるよ。
https://nim-lang.org/docs/manual.html#procedures-do-notation
402デフォルトの名無しさん
2023/12/16(土) 08:47:38.44ID:yzC0WAGQ
「vimを使えばいい」とか「無名関数を使えばいい」などと列挙されても
他の言語はそんな特別なケアなしに使えるわけでな…
このあたりがいまいち広まらない原因なんじゃない?
403デフォルトの名無しさん
2023/12/16(土) 08:53:10.18ID:mPzLcjX0
以前インデントの代わりに{}を使える機能があったようだ。
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
404デフォルトの名無しさん
2023/12/16(土) 09:38:42.94ID:mPzLcjX0
>>402
現代では高機能なテキストエディタやIDEが使えるから
それを使うことを前提にプログラミング言語をデザインしたらいいんじゃね?
って話は聞いたことがある。

sugarの`=>`マクロはNim言語のanonymous procedureを特定の条件下で簡単に書けるよう作られたもので完全にanonymous procedureを置き換えられるものでない。
sugarモジュール自体がシンタックスシュガーのようなものを提供するマクロなどを集めたものだし。
制限とか気にせずにanonymous procedureを書きたかったら=>を使わずに書くしかない。
405デフォルトの名無しさん
2023/12/16(土) 09:56:43.39ID:yzC0WAGQ
>>404
そのへんがまさに省略記法の悪い点が出てる感じするな
省略するってことはソースコードの情報量は減っていて、それはタダではない
「OOのときにはXXを使う」みたいな規則がたくさん発生するというコストがあるんだよね
これはセミコロンレスもそうで、時々変なエッジケースが発生したりする
406デフォルトの名無しさん
2023/12/16(土) 16:45:38.17ID:kvk3r8Lt
オフサイドルールと違ってセミコロンレス(optional semicolon)は多くの言語で妥当なトレードオフ
オフサイドルールが妥当なトレードオフとして成立してるのはHaskell系の言語くらい
407デフォルトの名無しさん
2023/12/16(土) 20:00:00.36ID:USjLXMUH
なんかどうでもいいことをいつまでも
うじうじと

気に入らないなら使わなきゃいいだけ
気に入ったら使えばいいだけ
408デフォルトの名無しさん
2023/12/17(日) 07:10:31.29ID:clYlz397
>>407
気に入っていても:
  ある日突然:
    気に入らなくなる事ってあるよね?
気に入らなくても:
  ちょっとしたきっかけで:
    すごく気に入ってしまうことも
    あるよね?

そういう時はどうすればいいの?
409デフォルトの名無しさん
2023/12/17(日) 12:19:34.98ID:WUPd6f5k
>>408
>    すごく気に入ってしまうことも
>    あるよね?
Error: invalid indentation
410デフォルトの名無しさん
2023/12/17(日) 18:41:59.56ID:F9NekDqG
Nimはよく考えずに機能追加して既にC++並みに複雑化してる
目新しさだけで飛びつくと後悔するぞ
411デフォルトの名無しさん
2023/12/18(月) 02:13:02.65ID:DdCrjTir
そうなの? じゃあもうC++でいいじゃん
412デフォルトの名無しさん
2023/12/18(月) 08:55:26.31ID:DG+uqCiP
例えば最近実装している変更についてもちゃんとここに理由とか書いてあるよ。
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++のほうがはるかに複雑だよ。
413デフォルトの名無しさん
2023/12/18(月) 20:40:29.88ID:DG+uqCiP
Nim言語がどのような考えで設計されたか知りたい人はNimのblogを読むといいよ。
https://nim-lang.org/araq/
https://nim-lang.org/blog.html
414デフォルトの名無しさん
2023/12/18(月) 20:49:37.54ID:CbnA3O4k
Nimの現状を知りたい人はこれを読むといい
https://forum.nim-lang.org/t/9145
415デフォルトの名無しさん
2023/12/19(火) 00:16:35.74ID:mrSFrPG8
議論をよく読めば何やらちゃんと考えて実装しているらしいのはC++も同じなんだよなあ
416デフォルトの名無しさん
2023/12/19(火) 08:00:58.06ID:w9OEXcqM
>>415
単純に >>410 への反論なだけじゃない?
417デフォルトの名無しさん
2023/12/20(水) 12:37:14.01ID:Cvw2c2UZ
バグ修正版のNim 2.0.2と1.6.18がリリースされました。
https://nim-lang.org/blog/2023/12/19/versions-1618-202-released.html
418デフォルトの名無しさん
2023/12/23(土) 09:16:16.92ID:VfEmk1mn
寂しいスポンサーページだな😢
https://nim-lang.org/sponsors.html
こりゃnimが普及しないのも当然か
rustとは大違い
https://foundation.rust-lang.org/members/
419デフォルトの名無しさん
2023/12/23(土) 10:35:51.40ID:M8dtHAyN
でもRustは誰も使ってないじゃん
420デフォルトの名無しさん
2023/12/23(土) 11:58:51.47ID:BXldyzev
Rust言語はトヨタ自動車が採用してると
どこかで読んだ
421デフォルトの名無しさん
2023/12/23(土) 13:41:38.19ID:fLdoaHTJ
>>419
誰も使ってないは草
422デフォルトの名無しさん
2023/12/23(土) 13:46:35.58ID:6J3b/0Sr
Nimと書き間違えたんだと思うが
423デフォルトの名無しさん
2023/12/23(土) 18:13:17.30ID:A6gu1Hml
Nimを使っている組織のリスト
https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim
424デフォルトの名無しさん
2023/12/27(水) 19:41:58.29ID:g/RhhP+m
プログラムをビルドするためにC++だったらCMake、Rustだったらcargo.tomlにTOMLを使う。
Nimだったらconfig.nimsも.nimbleファイルもNim言語で書ける。
一つの言語でコンパイル言語としてもスクリプト言語としても使えて便利。
Nimはマクロやconstなどをコンパイル時に実行するためにVM使ってるんだけど、そのVMを使ってNimをスクリプト言語のように実行できるらしい。
425デフォルトの名無しさん
2023/12/27(水) 19:50:00.04ID:J2C6aYvl
rustも複雑なことをしようと思ったらbuild.rsに書けるけど、それはそうとして依存関係をプログラム言語で書きたいかと言われると
426デフォルトの名無しさん
2023/12/27(水) 20:16:43.40ID:E4kPlntL
あれもこれもできて便利!みたいなのはぱっと見良さそうでも
大規模・多人数・長期開発になると負債になりがちではある
427デフォルトの名無しさん
2023/12/27(水) 20:24:29.72ID:qErwbOrg
happyxが起爆剤にならないかなぁ、、🙏
428デフォルトの名無しさん
2023/12/27(水) 23:05:07.37ID:LUGQIuRd
zigなら全部zigで書ける(便乗)
429デフォルトの名無しさん
2023/12/27(水) 23:27:30.38ID:7WiLoZ1Z
一体なにがエレガントなんだろうなこの言語って
430デフォルトの名無しさん
2023/12/27(水) 23:34:47.36ID:qmMlPacq
まあアイコンはエレガントなんじゃない?王冠だし
431デフォルトの名無しさん
2023/12/27(水) 23:51:57.04ID:Ra91RrOg
procとmethodとfuncを使い分けつつ{.global.}や{.async.}なとの{.pragma.}とmacroでぐちゃぐちゃにかき混ぜられるのが超エレガントw
他の言語では類を見ない
432デフォルトの名無しさん
2023/12/28(木) 22:46:05.11ID:u+MANgUc
エレガントすぎてついていけないわ
433デフォルトの名無しさん
2023/12/28(木) 23:18:44.60ID:u+MANgUc
エレガントすぎてついていけないわ
434デフォルトの名無しさん
2024/02/20(火) 19:40:26.76ID:iQdtjO/s
新年の記念 保守
435デフォルトの名無しさん
2024/06/17(月) 22:36:28.67ID:y0rZbngO
https://nim-lang.org/blog/2024/06/17/version-206-released.html
Nim version 2.0.6がリリースされました。
436デフォルトの名無しさん
2024/10/04(金) 21:03:40.29ID:jm0g8/rX
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計測値を基準にしてください
437デフォルトの名無しさん
2024/10/04(金) 21:11:00.73ID:jm0g8/rX
特にデータ構造で
Nim seq[bool]
Rust Vec<bool>
は遅いので直ぐに取り換えてください
C++のvector<bool>は最適化がされていますが、最終的に別のものにしました
438デフォルトの名無しさん
2024/10/04(金) 21:12:20.19ID:jm0g8/rX
>>436は取り換えた後の計測値です
439デフォルトの名無しさん
2024/12/31(火) 13:29:53.82ID:dvbSbmj1
ねんまつ記念 保守
440デフォルトの名無しさん
2025/02/18(火) 12:43:21.45ID:HbHlBTpR
C++のVectorは最悪
441デフォルトの名無しさん
2025/03/30(日) 03:12:16.26ID:oBGwoxyW
最近元気ないな

lud20250419220234
このスレへの固定リンク: http://5chb.net/r/tech/1519896738/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「nim ->画像>1枚 」を見た人も見ています:
軽mini
NSOMIA
minus8
DENIMS
WANIMA
Diamond
Exanima
MilkMan
mi band
mi band
im ramen
NeeSOMIA
BOBOMIND
GANMA!3
NAVITIME
GANMA!4
Linuxmint
neovim-jp
ONE MEDIA
i'm penis
仁王/Nioh
naturismv
LINE Music
Mad Island
Koushinism
New Game!
NAOMIの部屋
NEW GAME!
Xmas Eileen
仁香 Nica 6
BAND-MAID 3
mugen wifi
minecraft川柳
pop'n music
pop'n music
mizuno swim
SSSS.GRIDMAN
貴洋元年ナリ
BAND-MAID 25
KingMowの逆襲
BLACKDIAMOND
Instagram #9
Mr.FULLSWING
Instagram 懸賞
Maurice Ohana
GIRLS MEETING
否定と肯定 Denial
martin kinoo
SSSS.GRIDMAN
Instagram懸賞
振り袖Himechan
ID:XLmLS5En0
minitoto実況
miyabi-night
Instagram #8
I am iron man
ハンJMGTOW部
Instagram #13
SAKANAMON 二品目
Instagram #12
Mr.Children1880
NIPSって知ってる?
JCB PLATINUM 1
MixChannelLIVE
HITMAN part 36
10:58:38 up 51 days, 11:57, 0 users, load average: 6.64, 6.70, 6.96

in 2.2901649475098 sec @2.2901649475098@0b7 on 060723