nim
1 :デフォルトの名無しさん :2018/03/01(木) 18:32:18.16 ID:vh/yy2VS.net https://nim-lang.org/
2 :デフォルトの名無しさん :2018/03/01(木) 20:11:33.86 ID:waYC8XnL.net 乙
3 :デフォルトの名無しさん :2018/03/01(木) 22:14:19.93 ID:73H1EZrd.net nimは確かにいいものだけど どこかのバックアップがないと廃れる
4 :デフォルトの名無しさん :2018/03/03(土) 13:00:41.35 ID:hv+J7voV.net Nim は未だに 1.0 にもならないからな。
5 :デフォルトの名無しさん :2018/03/04(日) 00:13:26.42 ID:dfYa5r5g.net rustよりこっちは流行ってほしい
6 :デフォルトの名無しさん :2018/03/12(月) 11:04:45.99 ID:7HjR7SCF.net https://nim-by-example.github.io/variables/result/ resultの説明こんだけじゃよくわかんないな なんで0なの
7 :デフォルトの名無しさん :2018/03/12(月) 11:26:51.87 ID:34p9aq3f.net var でresult上書きしちゃったから本来のresultは初期値のままなんじゃない?
8 :デフォルトの名無しさん :2018/03/27(火) 01:06:06.14 ID:z3LtWtNM.net 0.18の次は1.0?
9 :デフォルトの名無しさん :2018/03/29(木) 18:55:17.89 ID:xuG7sIN3.net Rustは使い道が全然違うのでは 競合相手を挙げるとすればDとKotlinかな?
10 :デフォルトの名無しさん :2018/03/29(木) 20:05:34.60 ID:mREgEFij.net Dは死んでるし、KotlinはJVMだからちょっと違う うん。安泰だな
11 :デフォルトの名無しさん :2018/03/30(金) 15:03:59.86 ID:husdvr0W.net にむにむ
12 :デフォルトの名無しさん :2018/03/30(金) 17:20:25.17 ID:LkNluKW0.net にむにむ
13 :デフォルトの名無しさん :2018/04/13(金) 11:18:25.98 ID:1FEv2TtX.net windowsはなぜかmingwじゃなくてVCベースがデフォルトになってるんだよな mingwのほうがつぶし効きそうなのに
14 :デフォルトの名無しさん :2018/04/22(日) 21:27:36.51 ID:guTpWN67.net http://imgs.link/xxGzMN.gif
15 :デフォルトの名無しさん :2018/05/23(水) 19:59:41.53 ID:Au5e7VGg.net 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 D0A0C
16 :デフォルトの名無しさん :2018/06/22(金) 00:41:37.96 ID:YRNyKvjT.net Nintendo switch support https://github.com/nim-lang/Nim/pull/8069 devkitproとかなつい
17 :デフォルトの名無しさん :2018/06/22(金) 07:50:35.79 ID:B4dYVWwz.net tcc 使えないからやめた。
18 :デフォルトの名無しさん :2018/06/22(金) 16:26:06.96 ID:1kLq6NEC.net tcc使ってビルドしてもたいして最適化されないから使えない PC用途ならビルドが速いのが唯一のメリットだな
19 :デフォルトの名無しさん :2018/06/22(金) 19:01:13.51 ID:ypfKNoQc.net nimに追い風来た?
20 :デフォルトの名無しさん :2018/06/22(金) 20:19:33.22 ID:pFncXrHB.net 【王様きどり、財界″】 マイトLーヤ『人々はもう特定の主義を認めない、政治的教化は通用しない』 http://rosie.5ch.net/test/read.cgi/liveplus/1529634259/l50 共産でも、資本でもない、分ち合い経済が、登場します!
21 :デフォルトの名無しさん :2018/06/24(日) 16:08:44.05 ID:UA2S6a/y.net 単なるCトランスパイラ。 糞スレ終了。
22 :デフォルトの名無しさん :2018/06/24(日) 16:30:04.61 ID:qqy2wX7I.net そのCトランスパイラでnim作ればいいんじゃね?
23 :デフォルトの名無しさん :2018/06/24(日) 23:45:55.72 ID:5Eh2Uv5P.net LLVM に対応しないのかね? わざわざCを介すとか面倒くさい。
24 :デフォルトの名無しさん :2018/06/25(月) 00:12:53.47 ID:fFB+k9lh.net LLVMに対応しても使う側の手間は変わらない
25 :デフォルトの名無しさん :2018/06/25(月) 01:50:01.01 ID:vYusjqJa.net IDE何使っておられますかみなさん
26 :デフォルトの名無しさん :2018/06/25(月) 07:53:35.56 ID:TJ656l8P.net >>24 そうかね? まあ、ネイティブコンパイルしてくれればいいことだけど。 別に速度は求めないからインタプリタでもいい。
27 :デフォルトの名無しさん :2018/06/30(土) 22:10:29.30 ID:6gscpOJh.net >>23 https://github.com/arnetheduck/nlvm
28 :デフォルトの名無しさん :2018/07/04(水) 22:00:55.44 ID:gFgZc5FG.net ED5
29 :デフォルトの名無しさん :2018/07/05(木) 07:27:55.02 ID:2S42hYSo.net vim使ってるよ
30 :デフォルトの名無しさん :2018/08/21(火) 15:32:54.75 ID:EBgi8cvd.net 1.0、juliaに先越されたな
31 :デフォルトの名無しさん :2018/09/23(日) 12:32:55.25 ID:x0iYh9VU.net 見た目だけはpythonとrubyの愛の子っぽいけど 気持ち悪いな 慣れると気持ち良くイケるのかな
32 :デフォルトの名無しさん :2018/09/23(日) 12:36:43.12 ID:Su1i+ANF.net >>21 どっちかというと tcl/tk
33 :デフォルトの名無しさん :2018/09/28(金) 00:10:24.24 ID:sUTKRE9a.net >>30 AV女優?
34 :デフォルトの名無しさん :2018/09/28(金) 07:58:16.83 ID:d9qseECH.net >>33 わかってていってんだろ
35 :デフォルトの名無しさん :2018/09/28(金) 12:33:53.60 ID:mIB0sZTe.net Version 0.19.0がリリースされました。 https://nim-lang.org/blog/2018/09/26/version-0190-released.html
36 :デフォルトの名無しさん :2018/09/28(金) 15:46:07.59 ID:O5kQkBkV.net GUI は何がおすすめ?
37 :デフォルトの名無しさん :2018/09/30(日) 18:50:57.10 ID:qKTW85vs.net math モジュールの round バグってんな こんなのもバグってるとか使い物にならないだろw
38 :デフォルトの名無しさん :2018/10/01(月) 07:05:34.25 ID:tIZ5XrDW.net roundに関してはNimのgithubのissueにもあるんだけど、floatの精度のせいでroundした値がfloatで正確に表せられない場合があるんだよ。 https://github.com/nim-lang/Nim/issues/9082 詳しく知りたかったら、現代の殆どのPCで浮動小数点数を扱うのに使われているieee754という標準規格について調べてね
39 :デフォルトの名無しさん :2018/10/06(土) 22:16:11.18 ID:M6XEBHaV.net echo(convert("こんにちは、", "Shift_JIS", "UTF-8")) Windowsだとこうしないと日本語が表示されない
40 :デフォルトの名無しさん :2018/10/06(土) 22:34:07.06 ID:Dokqbc8P.net ソースと端末表示をUTF-8にすればいいだけじゃ
41 :デフォルトの名無しさん :2018/10/07(日) 00:51:21.65 ID:o9Iuox3H.net windowsでシステムロケールUTF-8にしたい chcp65001は禁止で
42 :デフォルトの名無しさん :2018/10/09(火) 21:51:59.30 ID:017c3dVj.net readline(stdin)が多バイト文字を受け付けない
43 :デフォルトの名無しさん :2019/04/17(水) 04:51:18.35 ID:X6FO3pO6.net つんつん
44 :デフォルトの名無しさん :2019/04/17(水) 13:09:18.13 ID:q/9NxBQE.net 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.52 ID:TZqApRQS.net なんやわからんけど波括弧書くのいやや〜
46 :あめ :2019/04/17(水) 18:54:10.48 ID:FVq2Eq3K.net >>44 研究用、ゴミ ドザによる荒らし
47 :デフォルトの名無しさん :2019/04/17(水) 21:27:04.52 ID:4b8gWp/i.net うるせーよ雑魚コテハン
48 :デフォルトの名無しさん :2019/04/17(水) 21:27:30.51 ID:TZqApRQS.net 雑魚コテハンは死ねや
49 : :2019/06/08(土) 18:55:31.57 ID:TM/rrlxa.net 0.20.0 リリース https://nim-lang.org/blog/2019/06/06/version-0200-released.html
50 :デフォルトの名無しさん :2019/06/17(月) 03:05:34.50 ID:7cCtTFkx.net 開発が止まっているLuaJITの代わりにこれを使いたい
51 :デフォルトの名無しさん :2019/06/18(火) 05:06:07.86 ID:DNE6sIuH.net じゃ使えばいいじゃん。
52 :デフォルトの名無しさん :2019/06/18(火) 11:00:03.52 ID:6YVmUs6+.net nimがCにトランスパイルできるとしても nimを通してクラス設計とかしたらその分のオーバーヘッドは残りますよね?
53 :デフォルトの名無しさん :2019/06/18(火) 12:35:30.19 ID:1CtlGReK.net そもそもそういう用途じゃない
54 :デフォルトの名無しさん :2019/06/18(火) 12:45:57.35 ID:6YVmUs6+.net どういうことですか? C並の性能を出すためにあるものではないと? Nimでカーネルを書くとか無理なのかなーと思ってたんですが 実際やるわけじゃないけど、いまのところ
55 :デフォルトの名無しさん :2019/06/18(火) 12:48:21.44 ID:1CtlGReK.net C++でカーネル書いたひとはいるね
56 :デフォルトの名無しさん :2019/06/18(火) 14:22:47.46 ID:6YVmUs6+.net 実際Linuxカーネルのコードは疑似OOPだみたいな説明を見かけたので NimやC++で書いても良いのかもしれない。 個人的にCへのトランスパイラとしてのNimにひじょーに興味がある
57 :デフォルトの名無しさん :2019/06/18(火) 14:25:52.94 ID:6YVmUs6+.net 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.57 ID:6YVmUs6+.net 続き読んだら他の人が否定してた
59 :デフォルトの名無しさん :2019/06/19(水) 01:56:19.31 ID:8qBvJS/J.net nimはgcを使っている。でもCへのトランスパイルができる。 gcということはメモリ解放が暗黙的ということだろう。 Cでは明示的に解放する必要がある。 どうやって解放タイミングを調べてるんだ? GC言語から非GC言語へのトランスパイルがなぜ可能なのか?
60 :デフォルトの名無しさん :2019/06/19(水) 02:09:28.92 ID:8qBvJS/J.net var name: string = readLine(stdin) なんでvarと書きつつstringと型指定するのか 変な言語仕様だな string name = でいいだろ
61 :デフォルトの名無しさん :2019/06/19(水) 02:10:39.50 ID:8qBvJS/J.net var name = readLine(stdin) 型推論だっていってるけどこれ可読性低下してる string name = readLine(stdin) これがベスト
62 :デフォルトの名無しさん :2019/06/19(水) 02:52:19.54 ID:8qBvJS/J.net nimでデバドラ作ったりできるんだろうか
63 :デフォルトの名無しさん :2019/06/19(水) 02:57:44.38 ID:8qBvJS/J.net 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.61 ID:8qBvJS/J.net 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.25 ID:8qBvJS/J.net 勘違いした。ダメってことはないか Nimコード自体は環境非依存、Cコードにするとき環境依存、ということか
66 :デフォルトの名無しさん :2019/06/19(水) 14:31:42.44 ID:Yoy0IPRe.net LLVMω
67 :デフォルトの名無しさん :2019/06/21(金) 05:13:28.08 ID:gJOJvtBY.net Nimってめちゃすごなんじゃないかなあ 細かい言語仕様で嫌いなところがあるけど
68 :デフォルトの名無しさん :2019/06/21(金) 14:29:00.17 ID:HK0kbqVP.net 漏れも D がすごいと思ってた時期があるよ
69 :デフォルトの名無しさん :2019/06/21(金) 14:55:07.18 ID:GHyPzIJc.net >>61 name : string := readLine(stdin) のほうがいい。
70 :デフォルトの名無しさん :2019/06/22(土) 05:26:38.53 ID:ecTKxvDL.net 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.49 ID:fiI8bn9U.net You Nim で Tensorflow が使えるアプリ造っchina YO
72 :デフォルトの名無しさん :2019/06/24(月) 09:23:40.70 ID:4pk2usGN.net >>69 var name : string = readLine(stdin) #nameは変更可能 let name : string = readLine(stdin) #nameは初期化後は変更不可 というletとvarに違いがある。 型推論使ったほうがコード読みやすい、書きやすいという人もいるんだよ。 readLineの戻り値の型はstringに決まってるんだから毎回型を書く必要ないと思うけど
73 :デフォルトの名無しさん :2019/06/24(月) 09:43:12.98 ID:4pk2usGN.net >>70 NimはC言語に変換してからgcc等のCコンパイラを呼んで実行ファイルを作るんだよ。 C言語は大抵のプラットフォームで使える言語だからマルチプラットフォーム化しやすい。 なので一度書いたNimコードをそれぞれのプラットフォーム上でコンパイルするかクロスコンパイルするだけでだいたいは動く。 けどNimから出力されるCコードは特定のCコンパイラ、OS、CPU向けに書かれているので、それだけでマルチプラットフォームな実行ファイルは作れないらしい。 Nimの標準ライブラリのソースコードを読むとOS、CPUによる違いを吸収するためのコードがときどきあるよ。
74 :デフォルトの名無しさん :2019/06/24(月) 09:53:12.36 ID:4pk2usGN.net Nimのソースコードのcompiler/extccomp.nimにNimが対応しているC/C++コンパイラの情報がまとまっていて、compiler/platform.nimにはOSとCPUの情報がまとまってる。
75 :デフォルトの名無しさん :2019/06/24(月) 11:40:11.26 ID:eHWTfFeZ.net 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.33 ID:4pk2usGN.net >>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.55 ID:coNgBae3.net 2次元配列って、 var a: array[10,array[10,int]] とか書くしかないの?
78 :デフォルトの名無しさん :2019/09/24(火) 21:02:48.66 ID:WLUvX9Jg.net nim1.0でた〜〜
79 :デフォルトの名無しさん :2019/09/25(水) 05:43:15.78 ID:rQhNlpv9.net 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.11 ID:vl5hNqVG.net ついでにwandboxのnim ttps://wandbox.org/permlink/npG9hbKwZyKQTXgI?source=post_page-----5d0f58d21e7e----------------------
81 :デフォルトの名無しさん :2019/09/25(水) 10:58:52.25 ID:U8qLrE8v.net GJ
82 :デフォルトの名無しさん :2019/09/26(木) 04:03:18.19 ID:9xzqPVF9.net 1.0おめでとう! ちなみに echo NimVersion echo(NimVersion) NimVersion.echo は同じ意味のコードだよ。Uniform Function Call Syntaxってやつだ
83 :デフォルトの名無しさん :2019/10/27(日) 16:17:57.05 ID:IkTaChA0.net 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.88 ID:IkTaChA0.net あと 日本語の参考書籍ってなんか出てる? Nim in Action とかはどうだった?
85 :デフォルトの名無しさん :2019/10/30(水) 20:48:12.27 ID:obI8HGMc.net >>83 最近のは勝手に gcc 入れてくれるよ。
86 :デフォルトの名無しさん :2019/11/06(水) 15:17:56.57 ID:o3tEvZiY.net HANDLEもこっそりtypedefに_PTR変えたんだっけ
87 :デフォルトの名無しさん :2019/11/06(水) 15:20:05.05 ID:o3tEvZiY.net 誤爆った
88 :デフォルトの名無しさん :2019/11/09(土) 00:06:35.30 ID:LGMQokS+.net Nim playground https://play.nim-lang.org/ 次スレから>>1 に入れといてよ しかしver1到達したのに全然盛り上がらんのなお前ら
89 :デフォルトの名無しさん :2019/11/09(土) 03:28:50.22 ID:fORTWFTH.net https://wandbox.org/ こちらでもNim使えますよ。
90 :デフォルトの名無しさん :2019/11/10(日) 11:17:11.92 ID:ddnKE8WS.net >>85 distフォルダにmingwの7z玉入れておけば、オフラインでのインストールもできるね。
91 :デフォルトの名無しさん :2019/11/10(日) 11:25:43.54 ID:ddnKE8WS.net >>84 日本語の書籍はないが、原著のドキュメントは割とわかりやすい。docs/tut1.htmlから読み始めるといいかもしれない。 NIAは評判が良いらしいのと、製本版を買うと電子書籍版が無料で付いてくるらしい。 国内でのNimの翻訳は有志が約二名ほど作業しているが、まだ始まったばかり。時間かかりそうだね。
92 :デフォルトの名無しさん :2019/11/18(月) 09:38:29.23 ID:ahZzeXy3.net DLLのCの関数を呼ぶ方法はいくつかあるようですが なぜいくつもあるのでしょうか? どれが一番効率が良いのかとか新しいのかとか判りにくい
93 :デフォルトの名無しさん :2019/11/18(月) 15:24:43.91 ID:g/bdYEbz.net 単純にdll内の関数を呼びたいならdynlibプラグマを使うのが一番楽。 少し低レベルな機能が必要ならdynlibモジュウルにあるプロシイジャアを使えばいいんじゃなかろうか
94 :デフォルトの名無しさん :2019/11/18(月) 17:09:32.08 ID:wQWkNxVm.net 成る程。
95 :デフォルトの名無しさん :2019/12/10(火) 23:17:13.67 ID:DeryhXpR.net nimに対応したソースコード可視化ツールってある?
96 :デフォルトの名無しさん :2019/12/12(木) 17:09:11.38 ID:Lo+C9eAO.net nimってあまりかっこよくないね
97 :デフォルトの名無しさん :2019/12/13(金) 23:01:47.25 ID:sYt6sihU.net Cにコンパイルしてからコード解析ツールに。
98 :デフォルトの名無しさん :2020/03/25(水) 04:10:40.05 ID:k6zngd1F.net nimコードはトランスパイルする前ならクロスプラットフォームなんだろうか?
99 :デフォルトの名無しさん :2020/03/27(金) 15:59:22 ID:6mKroLAz.net こんないい言語なのに結局欠点はCに依存してる点
100 :デフォルトの名無しさん :2020/03/27(金) 16:10:13.08 ID:9RtDMjhb.net あんまり本出ないね むしろチャンスか
101 :デフォルトの名無しさん :2020/03/27(金) 22:55:09 ID:2CmTFgv1.net あの糞マクロ以外大して面白みのない言語だしなぁ
102 :デフォルトの名無しさん :2020/04/07(火) 05:01:02 ID:FPXvnSDp.net 逆にマクロの完成度高い言語ってなに?
103 :デフォルトの名無しさん :2020/04/07(火) 07:46:31.57 ID:CJzGmfMl.net common LISP
104 :デフォルトの名無しさん :2020/04/07(火) 14:00:10 ID:izX7gbjy.net Schemeは?
105 :デフォルトの名無しさん :2020/04/07(火) 19:47:26 ID:fJ0U2d01.net nimのマクロは完成度高いと思う。でも完成度高いマクロという存在自体が糞。
106 :デフォルトの名無しさん :2020/04/08(水) 12:06:55 ID:lWfV0IAd.net MACRO-80
107 :デフォルトの名無しさん :2020/04/10(金) 23:13:42 ID:mN42vwgW.net >>102 糞マクロを褒めてるのであって 逆じゃないと思うんだが
108 :デフォルトの名無しさん :2020/04/10(金) 23:14:33 ID:mN42vwgW.net >>101 >>105 が同じってことだろ common lispなんてはるかに糞になるし
109 :デフォルトの名無しさん :2020/04/10(金) 23:15:34 ID:mN42vwgW.net マクロならrustのが定評あると思うが
110 :デフォルトの名無しさん :2020/08/07(金) 22:39:20.68 ID:r3mpGCFQ6 https://marimay.jp ここで麻雀作ってる
111 :デフォルトの名無しさん :2020/09/19(土) 22:27:13.04 ID:9NR8PjVh.net 小数の配列作りたいんだけどやり方教えてください。 [0.0, 0.1, .. 0.9, 1.0] みたいな。 Python なら hoge = [i/10 for i in range(11)] かな。気持ち悪いけど。
112 :デフォルトの名無しさん :2020/09/22(火) 12:29:56.17 ID:w8JrpHTT.net lc[i*0.1 | i<-0..10 ]
113 :デフォルトの名無しさん :2021/01/10(日) 21:59:51.09 ID:HIznKotv.net >>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
114 :デフォルトの名無しさん :2021/01/10(日) 22:14:35.92 ID:HIznKotv.net 付け加えるとHaskellみたいなproc() = の宣言が微妙キモいけどfunc(): T =があるから、まあ妥当だね rubyの様なreturnを書かないのは良い。result=xは便利だけど微妙....でそこまでやるならOptionと Future、そして例外を統一して欲しかったな。 普通にtry: except: finally:があるのも点数が高い。Araqが言う様に例外と(Label)goto based exceptは ほとんど同じ何だから、今どきの言語が例外が無いのはおかしい。まあ他を悪く言う気はないけど Goの様に意味合い的に同じでfinallyに対応するdeferがあるのも良いよね
115 :デフォルトの名無しさん :2021/01/12(火) 15:33:30.76 ID:LUlB/OIG.net 超時空ロングパス
116 :デフォルトの名無しさん :2021/01/12(火) 15:57:17.72 ID:kyPiY518.net この言語がJsと比較で優れてる点ってあるの?
117 :デフォルトの名無しさん :2021/01/13(水) 08:29:44.80 ID:oKh8381v.net JavaScript?であれば、JavaScriptはECMAScriptのバージョンとともに型無しのダックタイプから クラス定義で見られるように型を導入して大規模コードを書く際に静的な安全性を求めてきた、 言語的な特徴でもあった動的なメソッド上書きやapply/callは悪とみなされつつ、改良が進む。 TypeScriptもその特徴であろう、altJSあるいはJSX派生と呼ばれる一種の方言が多量に誕生した 一方でJavaScriptの遅さや1言語依存からwasmが考え出されて多くのコンパイラでwasm開発が できるようになった。Nimも例に漏れずJSバックエンド及びwasmコンパイルが可能である。 Rustもwasm開発はそうだがJSバックエンドは無い、Goもwasmは出来るがサイズが大きい NimはGoに比べても型チェックが厳しい、Rustはそれに借用いわゆるボローチェックがそれに 加わるRustもそうだが型安全性はばつぐんだ
118 :デフォルトの名無しさん :2021/01/14(木) 18:15:15.39 ID:ZgCcmsal.net jsって割と底辺だと思うから Nimはそれより上だろ
119 :デフォルトの名無しさん :2021/02/25(木) 19:45:58.25 ID:twDFYCAL.net 1.4.4 age
120 :デフォルトの名無しさん :2021/04/17(土) 20:22:19.25 ID:f1G9K9An.net 1.4.6 age
121 :デフォルトの名無しさん :2021/04/30(金) 20:42:36.52 ID:+hB3gYz3.net Windows defenderでウイルス判定される
122 :デフォルトの名無しさん :2021/05/01(土) 12:24:15.54 ID:afQILYPs.net それはどうしようもない https://forum.nim-lang.org/t/7830
123 :デフォルトの名無しさん :2021/05/10(月) 13:57:34.01 ID:FH4+0Y9S.net 頼むからもう少し流行ってください。Dropトレイト、Rcトレイトと戯れてあいつのコードを直したくない
124 :デフォルトの名無しさん :2021/05/10(月) 15:07:45.08 ID:lCZGOQhN.net 明日に向かって吠えろ
125 :デフォルトの名無しさん :2021/05/13(木) 14:29:40.54 ID:pHijDXLB.net Software Design に記事持ち込め
126 :デフォルトの名無しさん :2021/05/15(土) 12:35:34.04 ID:eYtIld1h.net https://www.akiradeveloper.com/post/give-up-nim/
127 :デフォルトの名無しさん :2021/05/19(水) 07:49:19.67 ID:mvJC2+U+.net 2015年2月なんて大昔だろ…Version 0.11頃の話、貼る奴w
128 :デフォルトの名無しさん :2021/05/19(水) 07:53:15.04 ID:mvJC2+U+.net 間違えた。 2月だから0.11さえ出てないわ、0.10.2…
129 :デフォルトの名無しさん :2021/05/26(水) 22:06:31.04 ID:5a/xy4zx.net >>121-123 バージョン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では発生しないはずです。
130 :デフォルトの名無しさん :2021/06/24(木) 16:12:27.31 ID:IeJQfUil.net なんか結局流行らなかったな 2019ごろはちょっと来そうな雰囲気出してたのに
131 :デフォルトの名無しさん :2021/06/24(木) 16:13:02.76 ID:IeJQfUil.net 今でも一番書いてて気持ちいい言語ではあるけど
132 :デフォルトの名無しさん :2021/06/24(木) 17:25:26.02 ID:70oiT5zZ.net Luaといい勝負?
133 :デフォルトの名無しさん :2021/06/27(日) 14:10:40.69 ID:YLAmOs9U.net 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++そのもの、限りなく抑え込まれたタイプ量。
134 :デフォルトの名無しさん :2021/06/27(日) 20:05:41.95 ID:ytkGpeVG.net そんなにヒドいかな?
135 :デフォルトの名無しさん :2021/08/21(土) 08:23:43.68 ID:7GAoG1Iq.net Nimにガベージコレクション(GC)有りは事実なのですが、 NimはオプションでGC無しにできるので、 Nimバージョン:1.5.1でRustのボローチェッカー に似た「View types」が実装されれば GC無しで、View types参照の有効性を検証する ことによってメモリ安全性を保証しつつ高速化して C/C++/Rustの代替に出来ますか?
136 :デフォルトの名無しさん :2021/08/21(土) 08:47:50.25 ID:7GAoG1Iq.net Nimの実験的特徴 著者: アンドレアス・ルンプ バージョン: 1.5.1 http://nim-lang.github.io/Nim/manual_experimental.html
137 :デフォルトの名無しさん :2021/08/21(土) 22:20:40.33 ID:7GAoG1Iq.net 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 は我々に教えてくれます
138 :デフォルトの名無しさん :2021/08/22(日) 08:04:08.99 ID:0Cz6ueFz.net 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 は我々に教えてくれます
139 :デフォルトの名無しさん :2021/10/02(土) 12:07:48.96 ID:nsqRCPBa.net いつの間にかJetBrainsのプラグインが出てたね。今更気がついたよ これもかなり良いんじゃない? https://plugins.jetbrains.com/plugin/15128-nim
140 :デフォルトの名無しさん :2021/10/27(水) 21:47:06.11 ID:6tzLPjk/.net const str = [0, 1, 2, 3, 4] for i in 0||str.high: echo str[i] # nim --passC:"-fopenmp" --passL:"-fopenmp" c main.nim
141 :デフォルトの名無しさん :2021/10/28(木) 12:20:10.25 ID:hM84Yf/1.net >>92 Cの関数だけでもいろいろなコンパイラーにより規約が違うから、ダイナミックなリンケージを非常に素直に 書ける言語はこれくらいだと思う。rustもFFIで呼べるけど https://ja.wikipedia.org/wiki/ 呼出規約
142 :デフォルトの名無しさん :2021/10/29(金) 07:15:01.84 ID:pQzUwhXN.net Nim言語の開発者が$100k相当のBitcoinの寄付を受け取ったことが話題になっています。 www.reddit.com/r/programming/comments/qg2srd/nim_receives_100k_in_bitcoin_donations/
143 :デフォルトの名無しさん :2021/11/11(木) 20:14:42.95 ID:sY0aXUs3.net >>99 公式での処理系は基本的にはC/C++のトランスコンパラですがJSのトランスコンパラとしても動作します。 言語的には依存している分けではなく、gccやclangの最適化の恩恵を受けるためにあえてそのようにして いるようです。 また直接バイナリを吐き出す別のコンパイラarnetheduck/nlvmもあります。CrystalやRust、Swiftなどの LLVMバックエンドと同じです。コンパイル時間を短縮しllvmバイナリとして僅かに小さくなります。
144 :デフォルトの名無しさん :2021/11/22(月) 17:33:11.29 .net RustよりC++より速いんですか? 始めてみようかな
145 :デフォルトの名無しさん :2021/11/22(月) 20:36:44.15 ID:Jhs76KRN.net いろんな意味で早いと思う
146 :デフォルトの名無しさん :2021/12/17(金) 19:10:05.51 ID:XHqHc5Ln.net Version 1.6.2 released https://nim-lang.org/blog/2021/12/17/version-162-released.html
147 :デフォルトの名無しさん :2022/02/10(木) 01:19:39.92 ID:OVWQX5q0.net Version 1.6.4 released https://nim-lang.org/blog/2022/02/08/version-164-released.html
148 :デフォルトの名無しさん :2022/03/29(火) 04:55:27.78 ID:cbyFlglW.net 1.6.x系だけDLしようとするとマルウェア警告出るんだけどこれ大丈夫なんかね
149 :デフォルトの名無しさん :2022/03/29(火) 14:58:47.55 ID:mXbypgy+.net Nimの公式サイトから入手したものなら大丈夫なはず。 Nimに含まれている実行ファイルやNimでコンパイルしたプログラムがアンチウィルスソフトウェアに誤検出される問題は多くの人々から報告されている。 Nim言語でマルウェアを書いてる人がいるせいで誤検出さるようになったらしい。 アンチウィルスソフトウェアは悪いことしないプログラムでもマルウェアと似たようなビットパターンを見つけるとマルウェアとみなすっぽい。
150 :デフォルトの名無しさん :2022/03/29(火) 15:37:13.13 ID:j1iUrhcV.net >>149 なるほどね? サンキュー😉👍🎶
151 :デフォルトの名無しさん :2022/03/29(火) 20:54:07.21 ID:/9JyHlX1.net マルウェアと誤検知されたくなければnimで開発しない方が無難か。
152 :デフォルトの名無しさん :2022/03/31(木) 21:33:49.63 ID:3qPlBVYz.net 多くの人が使っているプログラムでない限り誤検出される可能性はある。 C++使ってたころにビルドが完了してすぐに誤検出されことがあったし。
153 :デフォルトの名無しさん :2022/03/31(木) 21:54:44.97 ID:EY1WgKK4.net そういうどっちもどっち論じゃないだろ。>>149 は有意に誤検知が多いと言っているように見えるが。
154 :デフォルトの名無しさん :2022/04/01(金) 11:47:01.52 ID:3pastURm.net Nimコンパイラ自体がマルウェア扱いだからな。
155 :デフォルトの名無しさん :2022/04/03(日) 00:58:55.13 ID:29whmEYr.net Nimを書き初めて1ヶ月...procの第一引数に設定したオブジェクトにprocがバインドされる謎構文にはたまげたけど書き味がいいし気に入ったなあ
156 :デフォルトの名無しさん :2022/04/03(日) 10:37:31.39 ID:Ng2sRKnM.net >>155 ちょっと誤解しているようだけど、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()
157 :デフォルトの名無しさん :2022/04/03(日) 10:53:58.62 ID:Ng2sRKnM.net Nimではプロシージャの呼び出し方が何通りかある。 echo("Hello") # Command invocation syntax echo "Hello" # Method call syntax "Hello".echo "Hello".echo() # Generalized raw string literals # 引数が文字列リテラル一個のときのみ echo"Hello"
158 :デフォルトの名無しさん :2022/04/03(日) 20:20:01.30 ID:29whmEYr.net >>156 なるほど👀 それでも変わった感じですよねえ
159 :デフォルトの名無しさん :2022/04/09(土) 11:44:54.12 ID:P+77Yson.net >157 Method call syntax はスマートだから他言語でも流行ってほしいところ。 特にPythonは真っ先に採用して欲しいわ。
160 :デフォルトの名無しさん :2022/04/22(金) 04:37:03.66 ID:Ov5wmYZH.net あまり何通りもあるのはperlみたいになりそうでよろしくないな。
161 :デフォルトの名無しさん :2022/05/05(木) 20:58:23.76 ID:Ofa1pfuz.net Version 1.6.6 released https://nim-lang.org/blog/2022/05/05/version-166-released.html
162 :デフォルトの名無しさん :2022/05/06(金) 17:32:07.42 ID:+sslkA2r.net >>161 急にコンパイルできなくなって困ってたら vccexe,exeがトロイ認定受けて削除されてた… MSはnimをトロイだとみなしてるのか
163 :デフォルトの名無しさん :2022/05/08(日) 11:28:42.79 ID:ttLKa+gZ.net >>162 前に一回同じ現象出たわ コンパイル失敗するしWindows Defenderはうるさいしで何かやらかしたかと思った
164 :デフォルトの名無しさん :2022/05/18(水) 23:08:10.33 ID:7sDXJn10.net ニンニン
165 :デフォルトの名無しさん :2022/05/26(木) 17:01:15.95 ID:DJotMe7OG Nim完全マーク説
166 :デフォルトの名無しさん :2022/06/01(水) 08:37:47.90 ID:DGVHmNlJx Nimをまともに使うならVersion 1.5.8 あたりまでしか入らん
167 :デフォルトの名無しさん :2022/06/14(火) 14:49:13.90 .net 二ムってドイツ製?
168 :デフォルトの名無しさん :2022/06/22(水) 00:08:54.72 ID:mbXzyoju.net Araqってたしか国籍は南米じゃなかったか
169 :デフォルトの名無しさん :2022/06/22(水) 00:28:49.96 ID:mbXzyoju.net >>167 すまんドイツ人だったわ 顔面からずっと南米の人だと思ってた
170 :デフォルトの名無しさん :2022/07/26(火) 18:12:34.65 ID:MxJrqhMY.net ニンニン
171 :デフォルトの名無しさん :2022/07/26(火) 18:15:36.24 ID:gc9s0ohk.net 浣腸
172 :デフォルトの名無しさん :2022/07/27(水) 03:59:11 ID:0dTQJF2a.net 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
173 :デフォルトの名無しさん :2022/07/28(木) 11:23:58.38 ID:oB626eDW.net >>172 むしろ--mm:orcならRustよりNimのほうが循環もGCするだけメモリ安全だし、リリースビルドでオーバーフローチェックが意味不明にoffになり、言語仕様としてループindexにunsignedを使うRustのどこが安全なのかと小一時間。 まあNimでのdangerコンパイルと似てるし、構文上まだ危険な超絶ハック表現が出来てしまうので素人にはオススメ出来ない諸刃の剣。だけどsqlパッケージの文字列前提を絶対変えてほしい
174 :デフォルトの名無しさん :2022/07/28(木) 14:19:26.27 ID:1GWFUzAq.net RustのBorrow Checkerはメモリリークを防ぐものではないからね
175 :デフォルトの名無しさん :2022/07/29(金) 02:16:03.41 ID:jt8KW6vh.net nimの言語的とか技術的な弱点や欠点って何?
176 :デフォルトの名無しさん :2022/07/29(金) 03:05:46.34 ID:4AXwbrcj.net templateまたはmacroの第一引数がuntypedだとmethod call syntaxが使えない。 method call syntaxでgenerics parameterを指定するときにfoo.myproc[:int]()みたいな感じで[]の中の初めに':'を付けないといけない。method call syntaxを使わないときは':'は不要。 という感じでmethod call syntaxにちょっとした罠がある。
177 :デフォルトの名無しさん :2022/07/29(金) 12:18:00.08 ID:sEOGgaoM.net macroが全く別言語になってる錆やその他諸々よりも、ちゃんと言語の最小サブセットになってるからまだマシ
178 :デフォルトの名無しさん :2022/07/29(金) 13:08:45.89 ID:jt8KW6vh.net なるほど
179 :デフォルトの名無しさん :[ここ壊れてます] .net 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文字出ましたが何か腑に落ちません
180 :デフォルトの名無しさん :2022/09/11(日) 06:48:19.18 ID:u4B58VWk.net >>179 そもそも何をしたいの? windowsで日本語を表示したいだけならutf8を使ってればOk デフォルトでNimのコマンドラインプログラムを実行するとchcp 65001コマンドを実行したときのようにコードページをutf8に変更される。 chcp 65001を実行してもちゃんと日本語が表示されるようにターミナルを設定しよう。 utf16なテキストをutf8に変換して表示したい場合はできるだけcast使わないようにコードを書こう。 castは危険なのでできるだけ使わないようにしよう。 (castはビットパターンが同じまま別の型と見なす変換なので実装詳細を知らずに使ってるとうまく動かない) 最初からstringに文字列を格納するようにするとか、ループで一文字づつstringにコピーすればcastは避けられると思う。
181 :デフォルトの名無しさん :2022/09/11(日) 15:33:59.58 ID:o5WJ0zmX.net 上の例とは若干違いますが 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 にならないのがなんでかなーというのも 同様の現象が原因だろうと思います
182 :デフォルトの名無しさん :2022/09/11(日) 15:42:19.33 ID:o5WJ0zmX.net echo convert("\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x00\x00", "utf-8", "utf-16") これは ABCDEFG と出力されます
183 :デフォルトの名無しさん :2022/09/11(日) 15:48:12.92 ID:o5WJ0zmX.net >>181 の例で var u16 = newSeq[uint16](16) と定義しておくと(他は変更無し)(後半は0で埋まってる) ABCDEFG と表示されます
184 :デフォルトの名無しさん :2022/09/11(日) 15:48:57.35 ID:o5WJ0zmX.net まあ cast に何を期待してるんだと言われればそれまでなんだと思いますが腑に落ちませんでした
185 :デフォルトの名無しさん :[ここ壊れてます] .net nimってIDEやデバッガは近いうちに計画されてるの? vscodeでもいいんだけど、ちゃんとしたデバッガは欲しいな 条件付きブレークポイントやコンテナの中身が見れる程度でいいんだが
186 :デフォルトの名無しさん :2022/09/11(日) 19:50:17.68 ID:6Wt0j/hc.net >>185 vscodeのプラグイン nimsaem.nimvscode + webfreak.debug ではだめか?
187 :デフォルトの名無しさん :2022/09/11(日) 22:55:03.70 ID:EVjHVTpm.net やっぱりその組み合わせか どうにも使いづらいんだよねぇ 言語仕様は理想に近いんでもっと流行ってほしいんだが、これまでの情勢からあまり期待できなさそうだな
188 :デフォルトの名無しさん :2022/09/12(月) 01:44:56.16 ID:I2SXXYSG.net >>184 seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcast
189 :デフォルトの名無しさん :2022/09/12(月) 01:47:29.58 ID:I2SXXYSG.net >>184 seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcastしてるの? そうでないならcast使うのはやめたほうがいいよ。
190 :デフォルトの名無しさん :2022/09/12(月) 02:10:20.86 ID:I2SXXYSG.net >>184 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してる時点でもうデタラメなんだよ。
191 :デフォルトの名無しさん :2022/09/12(月) 02:17:45.60 ID:I2SXXYSG.net >>185 NimにGDBでデバッグできるようにするプラグインが付属していて gdbでブレークポイントをおいたり変数の中身を表示したりできます。 https://internet-of-tomohiro.netlify.app/nim/gdb.ja.html
192 :デフォルトの名無しさん :2022/09/12(月) 20:00:29.06 ID:YXdRRv20.net >>181 >>183 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
193 :デフォルトの名無しさん :2022/09/12(月) 22:26:15.30 ID:I2SXXYSG.net >>192 castは極力使わないほうがいいのでビット演算使ってu16の値をcharに変換したほうがいいよ。 お手本コードを投稿しようとしたらcloudflareが悪意あるコードと勘違いしてブロックされた
194 :デフォルトの名無しさん :2022/09/12(月) 22:30:11.19 ID:I2SXXYSG.net こんな感じです let c=65u16 + n u16[n * 2] = char(c and 0xff'u16) u16[n * 2 + 1] = char(c shr 8)
195 :デフォルトの名無しさん :2022/09/13(火) 11:55:15.89 ID:gs7UQvs1.net >>179 これ観ろ https://khchen.github.io/winim/winstr.html
196 :デフォルトの名無しさん :2022/09/13(火) 12:06:13.19 ID:0kBS+x4w.net 言語仕様としてはモダンな言語の中で1番わかりやすいし Rustで書くほどでもない軽いスクリプトとかならNimで良いんだけど流行らんなあ やはり個人開発者の言語が流行ることはもうないのか
197 :デフォルトの名無しさん :2022/09/13(火) 15:06:32.01 ID:EXK746Ox.net >>192 >>195 ありがとうございました
198 :デフォルトの名無しさん :2022/09/13(火) 16:00:02.06 ID:EXK746Ox.net アク禁?
199 :デフォルトの名無しさん :2022/09/13(火) 16:03:11.36 ID:EXK746Ox.net 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 と比べて
200 :デフォルトの名無しさん :2022/09/13(火) 16:05:36.05 ID:EXK746Ox.net なぜ拒否られる?
201 :デフォルトの名無しさん :2022/09/13(火) 16:06:26.54 ID:EXK746Ox.net 驚き最小の法則ですね 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
202 :デフォルトの名無しさん :2022/09/13(火) 16:07:15.32 ID:EXK746Ox.net 判った char だけダメなんね
203 :デフォルトの名無しさん :2022/09/13(火) 16:09:20.44 ID:EXK746Ox.net 驚き最小の法則 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
204 :デフォルトの名無しさん :2022/09/13(火) 16:11:32.87 ID:EXK746Ox.net インド人もびっくり
205 :デフォルトの名無しさん :2022/09/13(火) 19:05:39.59 ID:ketgm+4i.net Win土人 Nim土人
206 :デフォルトの名無しさん :2022/09/16(金) 10:37:25.88 ID:8/QLgRNp.net 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 ?
207 :デフォルトの名無しさん :2022/09/16(金) 10:57:11.84 ID:8/QLgRNp.net libstdc++-6.dll をコピーしてみましたがだめでした
208 :デフォルトの名無しさん :2022/09/16(金) 11:30:30.18 ID:lbCTEBn9.net nimpy nimodule
209 :デフォルトの名無しさん :2022/09/16(金) 13:53:03.44 ID:kdRP0PjD.net >>206 objdumpっていうプログラムを使えばどのdllを使っているか見れるよ。 使い方忘れたからググってね。 Nimをインストールしたときにgccもインストールしてればそのときにobjdumpも一緒にインストールされる。 他にも依存しているdllを見れるツールは色々あるけど
210 :デフォルトの名無しさん :[ここ壊れてます] .net >>209 windows用にもobjdumpあんの?
211 :デフォルトの名無しさん :2022/09/16(金) 16:24:53.42 ID:8/QLgRNp.net windows で nim 入れるときに一緒に入った mingw64 の中に objdump がありました
212 :デフォルトの名無しさん :2022/09/16(金) 16:34:58.81 ID:8/QLgRNp.net >>209 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 も必要でした 無事動作しましたありがとう
213 :デフォルトの名無しさん :2022/09/18(日) 09:51:11.78 ID:KpBP36NG.net >>203 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
214 :デフォルトの名無しさん :2022/09/22(木) 10:36:47.71 ID:u9/ouAZs.net 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() 簡単杉感嘆
215 :デフォルトの名無しさん :2022/09/22(木) 15:46:35.23 ID:zq3yyQIu.net こんなのや https://github.com/khchen/wNim こんなのも https://github.com/simonkrauter/NiGui
216 :デフォルトの名無しさん :2022/09/23(金) 15:49:32.66 ID:9eaiNZZz.net セルフホスティングくらいでけるのか?
217 :デフォルトの名無しさん :2022/09/23(金) 16:54:42.46 ID:COcKyTVz.net >>216 セルフホストってどういう意味で言ってるかは知らないけど Nim forum自体がNimで実装されてるよ。 https://github.com/nim-lang/nimforum
218 :デフォルトの名無しさん :2022/09/23(金) 20:37:31.28 ID:vOu7CdIL.net プログラミング言語でセルフホスティングっていったらコンパイラが自身の言語で実装できることだろうよ しかしできたとしてトランスパイラをセルフホスティングと呼んでいいのか
219 :デフォルトの名無しさん :2022/09/23(金) 22:00:58.25 ID:U9mPo3hK.net 出力がC言語か機械語かの違いぐらいだしトランスパイラだとしても普通にセルフホスティングって呼ぶよ
220 :デフォルトの名無しさん :2022/09/23(金) 22:27:48.78 ID:COcKyTVz.net https://github.com/nim-lang/Nim ここにNim言語のコンパイラがあるけどソースコードはNim言語で書かれている。 gccなどのCコンパイラとgitがあればソースコードからビルドできる。 ソースコードからビルドするときはまず古いバージョンのNimコンパイラをC言語に変換したものをダウンロードしてCコンパイラでビルドする。 それでビルドしたNimコンパイラで最新のNimコンパイラをビルドする。
221 :デフォルトの名無しさん :2022/09/24(土) 20:13:52.60 ID:7pBAspe1.net わりとどうでもいいな
222 :デフォルトの名無しさん :2022/09/25(日) 02:56:32.67 ID:z6wPsTgH.net Cコンパイラは一般的にC言語で実装されているが、どうやってCコンパイラをビルドするのか あらかじめビルド済みのCコンパイラを持ってきてビルドする ではそのビルド済みのCコンパイラはどうやってビルドされたというのか
223 :デフォルトの名無しさん :2022/09/25(日) 08:27:58.95 ID:bk7Mey46.net たぶん世界で最初のC言語はアセンブリかB言語かフォートランか何か別の言語で書かれていたんじゃないの?
224 :デフォルトの名無しさん :2022/09/26(月) 14:35:28.98 ID:heiSJ5NK.net BigBangは未だ仮説だ
225 :デフォルトの名無しさん :2022/09/28(水) 12:46:44.72 ID:bM9/UxvQ.net 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 観たいに描く方法は?
226 :デフォルトの名無しさん :2022/09/28(水) 13:40:07.41 ID:tqdPdMIm.net iterator `|`(x: HSlice; y: int): int = みたいな演算子のイテレータを定義すればいいじゃん。
227 :デフォルトの名無しさん :2022/09/28(水) 17:12:46.81 ID:XnHyDYU1.net nim 1.6.8 出た
228 :デフォルトの名無しさん :2022/09/29(木) 21:45:04.30 ID:9HIV6ABQ.net ウィ
229 :デフォルトの名無しさん :[ここ壊れてます] .net >>226 iterator items(s: SteppedSlice): int = var c = s.a while c <= s.b: yield c c += s.step を定義したらイケました 有賀豚
230 :デフォルトの名無しさん :[ここ壊れてます] .net ニンニン
231 :デフォルトの名無しさん :2022/10/22(土) 14:42:48.48 ID:Q+2x5vm1.net 本日のNimConf2022期待age
232 :デフォルトの名無しさん :2022/11/02(水) 12:51:11.01 ID:VT3BATxp.net 1,2ヶ月くらい前に Nim言語のマニュアル日本語訳がOSDNのページにアップされていて これで5年後には結構人気が出るかもと喜んでいたら 突然ページが消滅してショックだった キャッシュを探したけど発見できないので コピー持ってる人がいたらどこかにアップしてもらえらばありがたいです (ライセンス上問題が無ければですが)
233 :デフォルトの名無しさん :2022/11/02(水) 22:26:34.03 ID:AEY2Eek1.net 古いキャッシュなら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 まあキャッシュ古すぎて更新追いついてないけど
234 :デフォルトの名無しさん :2022/11/02(水) 22:33:40.08 ID:AEY2Eek1.net https://ja.osdn.net/users/megumi_engines/projects/ このひとがオーナーになってるプロジェクトの1つみたいだけど、Twitterのアカウントも消えちゃってるね プライベートが忙しくなったのかな
235 :デフォルトの名無しさん :2022/11/03(木) 15:08:48.38 ID:lETVCa2o.net Last Update: 2022-09-21 01:12 Nim プログラミング言語 - 非公式日本語版 (翻訳活動終了)に関する活動はすべて終了しました。リポジトリの再公開予定はありません。 理由はよう判らん githubにfork無かったかな
236 :デフォルトの名無しさん :2022/11/04(金) 07:27:29.10 ID:7DKhUjkg.net 日本語訳マニュアルの代わりになるかどうかはわからんけど amazonで日本語のNim言語の書籍が売られてるよ。
237 :デフォルトの名無しさん :2022/11/05(土) 00:35:21.38 ID:mvfmSa9B.net 当時高校生の描いたやつか CやC++との連携について 一行しか描かれてなかったな
238 :デフォルトの名無しさん :2022/11/06(日) 13:47:02.47 ID:4CeLTSQg.net c2nim にがっかり感なんだけど こんなもん? それとも使い方間違ってる? 期待し過ぎ?
239 :デフォルトの名無しさん :2022/11/06(日) 16:29:46.57 ID:zKDylNc8.net 単純化した具体例がないとなんとも
240 :デフォルトの名無しさん :2022/11/06(日) 16:42:07.10 ID:06z0Icrt.net わかっているのかもしれないけど、c2nimはどんなC言語のコードもNim言語に変換するものではない。C言語ライブラリをNim言語から使うためのバインディングをCのヘッダーファイルから生成するツールみたいなものだ。 c2nimに似たことができるこんなツールもあるよ。 https://github.com/PMunch/futhark
241 :デフォルトの名無しさん :2022/11/07(月) 12:40:52.04 ID:1sAmX+SP.net >>233 全く使えないキャッシュだな
242 :デフォルトの名無しさん :2022/11/07(月) 12:44:41.58 ID:1sAmX+SP.net >>232 3年前の nim 1.4.0だけど Nim日本語マニュアル https://github.com/tauplus/nim_doc_ja
243 :デフォルトの名無しさん :2022/11/07(月) 13:21:56.37 ID:V8od12Ai.net ダメだこりゃ みんなでzigに移動しよう
244 :デフォルトの名無しさん :2022/11/07(月) 14:15:04.63 ID:xn4jxoWB.net いーんだよ グリーンだよ
245 :デフォルトの名無しさん :2022/11/08(火) 12:57:20.87 ID:CnIxTlte.net template hoge(fuga: string): string = fmt"{fuga}" 観たいなときに fuga が undeclared になるんだけどなんで?
246 :デフォルトの名無しさん :2022/11/08(火) 13:05:00.14 ID:CnIxTlte.net >>240 なるほど良さげ 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.
247 :デフォルトの名無しさん :2022/11/08(火) 13:15:11.71 ID:CnIxTlte.net >>245 自己レス 出来ました本当にありがとうございました template hoge(fuga: string): string = block: let injectedfuga {.inject.} = fuga fmt"{injected_fuga}" https://qiita.com/momeemt/items/000d1f6c384f4f00e103
248 :デフォルトの名無しさん :2022/11/08(火) 18:53:20.46 ID:nCLZIP1Q.net >>247 それは公式ドキュメントのここに書いてあるじゃないですか。 https://nim-lang.org/docs/strformat.html#limitations
249 :デフォルトの名無しさん :2022/11/08(火) 19:07:14.22 ID:2BJbmpY0.net Pythonスレでテンプレになってる内容をNim用に変更したので 次スレからはテンプレにしてください -----ここから Nimの★ソースコードをそのまま5ちゃんに貼るとインデントが崩れてチヌ★ 【【【複数の連続半角スペースはなにもなかったことにされる&タブは普通には入れられない】】】掲示板の仕様なので、 プログラム文は↓等の、いわゆるコードうp用サイトに貼ってこいください。 ttps://glot.io/new/nim 結構使える。 ttps://play.nim-lang.org/ 本家。 ttp://ideone.com/ デフォ設定はC用のため、言語選択ボタン押下がピコ手間かも。 ttp://pastebin.com/ まずまずシンプル。 -----ここまで
250 :デフォルトの名無しさん :2022/11/09(水) 22:27:24.03 ID:5vHWfdFN.net 判り初めた my Revolution
251 :デフォルトの名無しさん :2022/11/10(木) 13:14:50.85 ID:JZ2iIpp8.net 試してみた 本家 https://play.nim-lang.org/#ix=4ftO スッキリ https://glot.io/snippets/gf9x33imvc ダメぽよ(実行時エラー?) https://ideone.com/9BYjHA (たまに死ぬよねこのサイト) 貼るだけ? https://pastebin.com/07h9Zjrx ideoneがダメなのはバージョンの問題?
252 :デフォルトの名無しさん :2022/11/10(木) 13:25:08.92 ID:JZ2iIpp8.net これで逝けました https://ideone.com/HBEKZu pragmaのNimNodeを指定出来なかったらしい ideone の Nim は (nim 0.19.4)
253 :デフォルトの名無しさん :2022/11/10(木) 14:16:57.58 ID:JDmtuJFO.net https://wandbox.org/
254 :デフォルトの名無しさん :2022/11/10(木) 15:04:27.30 ID:JDmtuJFO.net ↑のWandboxでも最新の安定版Nimを使えるしコードを共有できる。
255 :デフォルトの名無しさん :2022/11/10(木) 15:55:36.21 ID:hnXF7Xx/.net ここまでのまとめ ttps://glot.io/new/nim 結構使える ttps://wandbox.org/ 最新のNim使える ttps://play.nim-lang.org/ 本家 ttp://pastebin.com/ ソース貼り付けのみ
256 :デフォルトの名無しさん :2022/11/10(木) 16:23:45.65 ID:j+QMfGd1.net やっぱオフサイドスタイルはクソかよ。
257 :デフォルトの名無しさん :2022/11/10(木) 16:52:41.86 ID:JZ2iIpp8.net >>253 wandboxだと(っていうかそれ以外でもかもだけど) 実行ボタンの上に $ nim c ./prog.nim って表示されてて c を cpp に変更したくても出来ない 左上の「コンパイルオプション」らしい枠に cpp を入れると $ nim c ./prog.nim cpp になったわ
258 :デフォルトの名無しさん :2022/11/10(木) 20:00:36.53 ID:JDmtuJFO.net >>257 確かにwandboxだとnim cppでコンパイルできないっぽいね もしかしたらgithubのwandboxリポジトリに要望を出せば対応してくれるかもしれない。もしくは自分で機能を実装してpull requestを出すか
259 :デフォルトの名無しさん :2022/11/11(金) 10:16:18.33 ID:8dOB0zbX.net ここは未完成なのかな 日本語マニュアルっぽいけど https://2vg.github.io/Nim-World/
260 :デフォルトの名無しさん :2022/11/12(土) 14:40:51.16 ID:OIoQvXCU.net 自分で育てる感覚楽しいですね
261 :デフォルトの名無しさん :2022/11/15(火) 13:26:12.68 ID:QGmQMBHU.net type Hoge* = object fuga*: int としないで type HogeObj* = object fuga*: int Hoge* = ref HogeObj とするのは必須?習慣? 前者のデメリットは DeepCopy だというのは判るのですが 毎回後者を使った方が良い?
262 :デフォルトの名無しさん :2022/11/16(水) 09:07:52.80 ID:qCq9+PtI.net {.byref.} じゃね?
263 :sage :2022/11/16(水) 13:30:51.35 ID:4BSq9VuL.net 横からだが >>262 のbyrefと >>261 は完全に等価?
264 :デフォルトの名無しさん :2022/11/16(水) 15:57:06.50 ID:z+sJwdsY.net proc 読んだとき ref のフリをする fake が 259
265 :デフォルトの名無しさん :2022/11/16(水) 18:16:18.08 ID:kOxph/zs.net ref objectは一つのオブジェクトを複数のオブジェクトから参照したいときや継承使ってオブジェクト指向なコードを書くときに必要となる。 それ以外の場合はrefのついていないobjectのほうが速くなることが多い。 ref型は常にヒープに確保されポインタ経由でアクセスされるけどobjectだとスタックに確保できるしポインタで間接的に参照する必要もない。 object型のseqだとメモリ上に連続して確保されるけどref object型のseqにするとメモリ上に連続して確保されるとは限らないからキャッシュミスが起きやすくなる。 ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるからコピーのコストが問題になることがあんまりないと思うよ。 C++で言えばobjectはstructをそのまま使っている感じでref objectはstructをstd::shared_ptrごしに使っている感じ。
266 :デフォルトの名無しさん :2022/11/17(木) 09:41:27.60 ID:V4QZv0Fq.net proc incx(i: int): int = let j = i {.emit: "++j;".} result = j echo incx(5) https://glot.io/snippets/gfgq0p65a6 let で定義された変数も書き換え可能なんですね素敵ですね
267 :デフォルトの名無しさん :2022/11/17(木) 09:41:55.68 ID:V4QZv0Fq.net >>262-263 全く別物
268 :デフォルトの名無しさん :2022/11/17(木) 09:45:16.34 ID:V4QZv0Fq.net >それ以外の場合はrefのついていないobjectのほうが速くなることが多い。 これはどうかなぁ 遅くなることの方が多いと思うが
269 :デフォルトの名無しさん :2022/11/17(木) 10:53:32.89 ID:hYmfXxMP.net >>268 どうしてrefのついてないobjectのほうが遅くなる場合が多いの?
270 :デフォルトの名無しさん :2022/11/17(木) 14:28:18.19 ID:hYmfXxMP.net >>266 emit pragma使っているんだからNimの安全性は無効になる。 rustでunsafeを使うようなもの。
271 :デフォルトの名無しさん :2022/11/17(木) 15:18:49.83 ID:fBlcqeZM.net >>265 >ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるから ってことは {.byref.} 描く必要無い?
272 :デフォルトの名無しさん :2022/11/17(木) 17:33:28.89 ID:7oSKGzG8.net >>271 自動でやるのは関数の引数にオブジェとを渡した時だから それ以外にコピーが頻繁に発生しないなら byrefいらないんじゃね?
273 :デフォルトの名無しさん :2022/11/17(木) 18:51:38.00 ID:hYmfXxMP.net >>271 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. って書いてあります。
274 :デフォルトの名無しさん :2022/11/17(木) 19:03:15.70 ID:hYmfXxMP.net >>271 https://nim-lang.org/docs/manual.html#foreign-function-interface-byref-pragma Nim manualではbyref pragmaがForeign function interfaceの章の下にある。 つまりbyref pragmaはC/C++の関数に引数をポインタ渡ししなきゃいけないときに使うもの。 それ以外のときに使う必要性はほぼ無いってこと。
275 :デフォルトの名無しさん :2022/11/17(木) 21:39:23.14 ID:ArWNCDPA.net >>268 そんな速度差気付くことある?
276 :デフォルトの名無しさん :2022/11/18(金) 05:58:57.10 ID:AmxJEdx7.net 君らスタックの消費は気にならんのけ?
277 :デフォルトの名無しさん :2022/11/18(金) 06:16:37.43 ID:IYaGyAsl.net >>276 10kバイト以上のでかいobjectをたくさん使うとかならスタックを使わないようにref objectにしてヒープに確保してもいいと思う。 けどそんなにでかいobject型のローカル変数をたくさん使うことってあんまりないきがするけど。
278 :デフォルトの名無しさん :2022/11/18(金) 09:39:59.23 ID:IJuokuF8.net たとえば https://qiita.com/dumblepy/items/8d13592d6760d0155d89 >オブジェクトの宣言にはref objectを使います。 >Nimでは関数の引数に入れられた変数の容量に応じてコンパイラが自動で値渡し/参照渡しを調節しますが、 >これは挙動の予測が付かずバグの原因になりえます。 >ref objectでオブジェクトを宣言していれば必ず参照渡しになるので、 >アプリケーション開発ではこちらに統一しましょう。 みたいなことが
279 :デフォルトの名無しさん :2022/11/18(金) 10:17:44.40 ID:IJuokuF8.net 問題無い訳ではないとも https://flat-leon. はてぶろ.com/entry/nim_arg_pass バージョンや記事の年代に気を付けないといかんのかね
280 :デフォルトの名無しさん :2022/11/18(金) 11:42:20.25 ID:IJuokuF8.net 古いけどここの議論は判り易い https://forum.nim-lang.org/t/1207
281 :デフォルトの名無しさん :2022/11/18(金) 11:48:22.19 ID:ygRIcUIa.net >>273 それは var の説明であって ref の説明ではないですね
282 :デフォルトの名無しさん :2022/11/18(金) 12:02:19.50 ID:IYaGyAsl.net >>278 >>281 refのついた型またはvar引数は常に引数を参照渡し(ポインタのコピー)する。 refやvarがついてない場合は引数のサイズにあわせてコピー渡しか参照渡しになるが、どちらにせよプロシージャ内で引数を変更するのは禁止
283 :デフォルトの名無しさん :2022/11/18(金) 12:10:00.28 ID:IYaGyAsl.net だからデフォルトの引数の渡し方でそれがコピー渡しになろうが参照渡しになろうがそれで挙動が変わったりバグの温床になることはない。 ただしaddrとかemit, Assembler statementなどのNimが安全性を保証してない機能を使う場合は例外だ。
284 :デフォルトの名無しさん :2022/11/18(金) 12:24:09.04 ID:IJuokuF8.net 参照とか reference とか同じ名前だから混同してるのかも知れないが Nim の参照型と C++ の参照型は全く別物 C++ の引数で使う参照型 & は Nim では var の方が近い Nim の ref は C++ ではポインタ * と思った方が良い Nim では GC で管理されるポインタが ref GC で管理されないポインタが ptr
285 :デフォルトの名無しさん :2022/11/18(金) 17:46:16.11 ID:PNsYUFFf.net これ使うか使わないかでも全然違うのよね --gc:arc
286 :デフォルトの名無しさん :2022/11/18(金) 18:35:09.65 ID:yVVkBIHa.net 最近は --mm:arc
287 :デフォルトの名無しさん :2022/11/19(土) 16:28:59.40 ID:F8GIHVyH.net --mm:orc 推奨
288 :デフォルトの名無しさん :2022/11/19(土) 17:55:05.22 ID:lavOlnrp.net Nim2では--mm:orcがデフォルトになるらしいぞ。 みんな知ってると思うけど--mm:arcだともし循環参照があったときにメモリリークするぞ。
289 :デフォルトの名無しさん :2022/11/19(土) 19:05:39.54 ID:7QNjN12J.net Nim2なんて10年以上先
290 :デフォルトの名無しさん :2022/11/20(日) 10:26:07.81 ID:MUgzJmMj.net >>278 のリンク先なんか 「Nimでアプリケーション開発をするための設計のベストプラクティス」 みたいにイキってるけど 信用していいの?
291 :デフォルトの名無しさん :2022/11/20(日) 11:36:46.79 ID:h2bm0L4T.net object type 全部 ref 付けろ教のひと たまにいるよね 迷惑
292 :デフォルトの名無しさん :2022/11/21(月) 13:35:10.22 ID:LzW8OiBh.net 割と実用になるわね https://pastebin.com/Ry2wTRHi
293 :デフォルトの名無しさん :2022/11/22(火) 09:38:49.09 ID:E0zMoWY7.net 理由を示さないお作法は無視していい
294 :デフォルトの名無しさん :2022/11/24(木) 09:24:22.39 ID:qRYWlPaY.net なんでもかんでもref付けろと しつこく強要してる人は あたまおかしい 大抵は{.byref.}で用足りる
295 :デフォルトの名無しさん :2022/11/24(木) 15:02:15.10 ID:7i9tpoXw.net {.byref.}はnimからC/C++の関数を使うときに引数をポインタで渡しているときに使うもの。 それ以外では使う意味はないよ。 Nimはちゃんと最適な方法で引数を渡すから必要でもないのに{.byref.}とかvarとかつける必要はない。
296 :デフォルトの名無しさん :2022/11/24(木) 18:37:53.45 ID:m+x+kPsJ.net var も ref も byref も全部別物だと何度言えば判るんだ?
297 :デフォルトの名無しさん :2022/11/24(木) 18:42:50.52 ID:RL/H9YUN.net >>296 みんなが必ず遭遇する問題なので 短くまとめて次スレからテンプレにするのが良い 以下 >>296 のテンプレが続く
298 :デフォルトの名無しさん :2022/11/25(金) 09:06:20.12 ID:PV2ZG9bu.net {.byref.}をrefと間違うのは判らんでもないし同情するが {.byref.}をvarと間違う香具師は初めて観た
299 :デフォルトの名無しさん :2022/11/25(金) 16:53:59.56 ID:s0hi6gQd.net nim 1.6.10 出た 1.6.98 まで行くのかw
300 :デフォルトの名無しさん :2022/11/27(日) 12:26:56.31 ID:IMKjsn3J.net regexどれ使えば良いの?
301 :デフォルトの名無しさん :2022/11/27(日) 16:05:43.13 ID:/+GS7DyS.net >>300 好きなのでいいんじゃ ?
302 :デフォルトの名無しさん :2022/11/27(日) 17:37:23.28 ID:1IfwvG7/.net >>300 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.
303 :デフォルトの名無しさん :2022/11/28(月) 05:25:04.28 ID:T/4+TPza.net 300
304 :デフォルトの名無しさん :2022/11/29(火) 12:04:17.71 ID:+WMggzr1.net pythonのStringIOとかBytesIOみたいなのは無い?
305 :デフォルトの名無しさん :2022/11/29(火) 14:03:26.53 ID:lz77OQ93.net >>304 FileStreamとStringStream かも https://nim-lang.org/docs/streams.html
306 :デフォルトの名無しさん :2022/12/02(金) 09:32:24.76 ID:ef8lBYgh.net 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 になっていないのでしょう? 意図を知りたいです
307 :デフォルトの名無しさん :2022/12/02(金) 09:38:11.16 ID:ef8lBYgh.net https://github.com/nim-lang/Nim で lib/pure/streams.nim の type を観ても FileStream のだけ FileStream* = ref FileStreamObj FileStreamObj* = object of Stream でした
308 :デフォルトの名無しさん :2022/12/02(金) 17:15:15.76 ID:Ojlf0I9F.net 命名の推測で「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(...)
309 :デフォルトの名無しさん :2022/12/02(金) 18:20:09.03 ID:hfqW6J8Y.net https://play.nim-lang.org/#ix=4hrl 継承するときに基の型についてるrefは無視されるようなので objectかref objectのどちらから継承しているかは重要ではないようだ。
310 :デフォルトの名無しさん :2022/12/03(土) 14:54:39.83 ID:H3EtATlx.net >>309 なるほど!
311 :デフォルトの名無しさん :2022/12/08(木) 15:32:48.39 ID:0CftMozc.net template とか macro とか使うと 流れる様にさらさら描けて気持ち良いわコレ
312 :デフォルトの名無しさん :2022/12/12(月) 07:08:32.93 ID:pbYUfvW7.net templateとmacroを上手くに使えるようになりてえなあ☹
313 :デフォルトの名無しさん :2022/12/13(火) 09:48:40.02 ID:xx5dSLzS.net こんな感じの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
314 :デフォルトの名無しさん :2022/12/14(水) 10:22:41.84 ID:LLXuibjV.net macro は AST 知ってると有利だね あと head と body を受け取るタイプのと node を受け取るのと static type を受け取るのとか 区別して理解しないと 自分が何やってるのか判らなくなる
315 :デフォルトの名無しさん :2022/12/14(水) 15:44:32.71 ID:SCwOJhsV.net へぇ、それはクソ仕様だね
316 :デフォルトの名無しさん :2022/12/14(水) 21:28:27.69 ID:XhtdH9iq.net node造る関数も直交性が無いな
317 :デフォルトの名無しさん :2022/12/17(土) 10:10:45.75 ID:a3CJqZUP.net 直交性という言葉を知ってるオジサン・・・ C/C++言語の#def, #include→別言語(直交性100%)、錆びのprintln!→実は別言語(直交性100%) むしろこれは言語が習得で異なる仕様の言語を2つ覚えないといけない、敷居を高くする欠点
318 :デフォルトの名無しさん :2022/12/17(土) 10:46:30.65 ID:2DPGsS1m.net NimNodeはseqに近い方法で扱えるようにmacrosモジュールにプロシージャが定義されているのはいいことでは。
319 :デフォルトの名無しさん :2022/12/17(土) 12:04:27.61 ID:OfpYIbSc.net untyped は obsoleted
320 :デフォルトの名無しさん :2022/12/17(土) 18:07:52.62 ID:GzYo/1Xm.net 今はNimNodeじゃなく、quote do:で書くのが良いよな。どうしてもNimNodeじゃなきゃ書けないマクロもあるだろうけどね
321 :デフォルトの名無しさん :2022/12/17(土) 19:18:25.81 ID:2DPGsS1m.net >>320 https://nim-lang.org/docs/genasts.html https://github.com/nim-lang/Nim/pull/17426 https://github.com/nim-lang/RFCs/issues/122
322 :デフォルトの名無しさん :2022/12/22(木) 07:38:06.92 ID:Fm5nn8iV.net 最初のrelease candidate for Nim v2.0が公開されました。 https://nim-lang.org/blog/2022/12/21/version-20-rc.html
323 :デフォルトの名無しさん :2022/12/22(木) 10:51:20.76 ID:Y6cO6Ymu.net ペース早いよなあ
324 :デフォルトの名無しさん :2022/12/22(木) 10:52:43.57 ID:N8bfJDIh.net nim-2.0 RC1 がリリースされた https://nim-lang.org/blog/2022/12/21/version-20-rc.html 来年1月か2月には正式2.0になるのかも
325 :デフォルトの名無しさん :2022/12/23(金) 02:05:06.61 ID:PNJSSvHF.net もう2.0かよ(´・ω・`)公開してるライブラリ大丈夫かな
326 :デフォルトの名無しさん :2022/12/23(金) 20:17:33.78 ID:244A80LW.net バージョンが大きく変わって大丈夫と思う方が 無理がある
327 :デフォルトの名無しさん :2023/01/04(水) 23:27:44.60 ID:ADP0p8ohV だいぶマニアックなスレですね
328 :デフォルトの名無しさん :2023/01/16(月) 16:24:59.02 ID:MsfEWWA2.net あっという間に2月
329 :デフォルトの名無しさん :2023/01/23(月) 22:52:56.91 ID:NHwV5soq.net 書き込みが1ヶ月に1回しかないスレ w
330 :デフォルトの名無しさん :2023/01/26(木) 03:28:17.45 ID:To7TXanK.net Nim言語を使っていても特につまづくことがないから話題があんまりないんだよね。
331 :デフォルトの名無しさん :2023/01/26(木) 18:39:32.28 ID:MzjwjnoQ.net 使用者の絶対数が少なすぎ
332 :デフォルトの名無しさん :2023/02/01(水) 01:23:34.72 ID:p1uaZW7X.net てすと
333 : :2023/03/01(水) 09:22:10.73 ID:68s28u+f.net !omikuji
334 :デフォルトの名無しさん :2023/03/01(水) 12:20:14.81 ID:q8rzgPd8.net 初心者はys3mとかrs3mで十分 Ziicubeでys3m出た 1割引き価格後の値段 679円 マグネット 1151円 Maglev 1623円 Boall-Core https://www.ziicube.com/Moyu-333-HuaMeng-YS3M
335 :デフォルトの名無しさん :2023/03/01(水) 12:20:39.02 ID:q8rzgPd8.net >>334 誤爆
336 :デフォルトの名無しさん :2023/03/05(日) 11:11:16.11 ID:/Qd0pRlS.net WinnyとNimってネーミングセンス似てるね
337 :デフォルトの名無しさん :2023/03/05(日) 19:55:40.66 ID:gl/xkADq.net >>336 Nimは元々Nimrodっていう名前だったんだけどその由来は https://forum.nim-lang.org/t/9591#63054
338 :デフォルトの名無しさん :2023/03/06(月) 14:19:57.93 ID:diWxUEyJ.net https://www.cosme.net/product/product_id/10190076/top
339 :デフォルトの名無しさん :2023/04/03(月) 17:59:13.21 ID:dNC7VYHk.net この言語ってRustみたいにプログラマに押し付けるmutなんて使ってないのに、なんでいわゆるMove操作が勝手に出来るの? 説明しろください!
340 :デフォルトの名無しさん :2023/04/03(月) 18:32:57.47 ID:3grB/pQG.net >>339 こちらの資料には目をとおされましたか? https://nim-lang.org/docs/destructors.html
341 :デフォルトの名無しさん :2023/04/09(日) 09:29:43.33 ID:Dm0aM9sg.net Nim良いよね Rustは宣伝がうざいだけだが Nimは判ってる人の間でまったり進化してくれ
342 :デフォルトの名無しさん :2023/05/04(木) 21:15:01.62 ID:wwnsNcS0.net 公式読めばだいたいのことはわかるから特にここでも議論は出ないよね 唯一日本語の書籍がもう一冊くらい欲しいなあくらい
343 :デフォルトの名無しさん :2023/05/06(土) 09:24:18.50 ID:u7gslL5e.net importとincludeの違いってなに?
344 :デフォルトの名無しさん :2023/05/07(日) 06:11:02.39 ID:uVIPnqNg.net >>343 https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#import-statement https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#include-statement
345 :デフォルトの名無しさん :2023/06/28(水) 19:11:48.73 ID:cQY5DEV3.net Nim言語 1.6.14 リリース https://nim-lang.org/blog/2023/06/27/version-1614-released.html
346 :デフォルトの名無しさん :2023/07/02(日) 18:18:52.72 ID:4yDce2PB.net 夜遅くにすいません。 SyntaxHilighter用のNim Brushってどっかにありませんか?
347 :デフォルトの名無しさん :2023/07/02(日) 18:34:57.51 ID:DcMb4mOQ.net >>346 話の内容が全然理解できないけど。。。
348 :デフォルトの名無しさん :2023/07/02(日) 21:16:17.65 ID:w86HyNV3.net >>347 ごめんなさい。 SyntaxHighlighter でした。
349 :デフォルトの名無しさん :2023/07/02(日) 21:56:05.97 ID:DcMb4mOQ.net >>348 SyntaxHighlighter っていうのがよくわからないけど VSCode拡張とかのこと?
350 :デフォルトの名無しさん :2023/07/03(月) 07:33:58.97 ID:VgAxDpje.net >>349 えぇエ~それぐらいネットで調べ「てく」ださいよ~~。 伝えるのめんど「い」し、説明上手くないからネッ-トで調べた方が絶対%絶対%にわかると思うんですよね。 お願いしますよ~~
351 :デフォルトの名無しさん :2023/07/03(月) 10:05:16.82 ID:erf1sDFe.net >>350 うわぁ~ 怖い 引っ込んでます
352 :デフォルトの名無しさん :2023/07/03(月) 12:35:43.48 ID:VgAxDpje.net >>351 恐がらせてごめん。
353 :デフォルトの名無しさん :2023/07/04(火) 04:16:26.79 ID:YbUZ4vjn.net Nim言語はコンパイル時にreadFileとwriteFileを使えるんだけどコンパイル時にファイルを読み書きできるプログラミング言語ってあまりないんじゃないか? staticExecていうコンパイル時にコマンドを実行できるプロシージャもあるし。
354 :デフォルトの名無しさん :2023/07/07(金) 02:08:00.59 ID:B1cwSpdy.net どっかで既出かもしれんけど、結局VSCの拡張は何入れれば安牌?
355 :デフォルトの名無しさん :2023/08/01(火) 18:27:12.50 ID:JtUN40O9.net https://github.com/nim-lang/Nim/releases/tag/v2.0.0
356 :デフォルトの名無しさん :2023/08/02(水) 00:52:58.78 ID:4aCNkU8+.net Nim 2.0がリリースされました。 https://nim-lang.org/blog/2023/08/01/nim-v20-released.html
357 :デフォルトの名無しさん :2023/08/26(土) 23:20:45.36 ID:6K2VICrE.net 初めてお邪魔します 下のスレッドでフィボナッチ数列(回帰関数)のベンチマークをやったのですが 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
358 :デフォルトの名無しさん :2023/08/27(日) 00:54:05.78 ID:M561FwxM.net >>357 Nimでコンパイルするときに'--listcmd'オプションを与えるとNimがgccを呼び出すときにどんな引数を渡しているか表示されるようになります。 もしかすると凄く最適化されるようなオプションを渡しているのかもしれません。
359 :デフォルトの名無しさん :2023/08/27(日) 01:58:10.81 ID:CxwZcjGE.net >>358 早速の回答ありがとうございます 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 になりましたが、実効速度はダントツに速いままでした 何か気が付く点がありましたらまた今度教えてください (私の方は今日は限界です...)
360 :デフォルトの名無しさん :2023/08/27(日) 17:22:00.42 ID:P6KX7G/o.net >>359 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 コンパイル型言語のベンチを取る時は再帰処理コードは 避けた方が良いと思います
361 :デフォルトの名無しさん :2023/08/27(日) 17:25:13.06 ID:P6KX7G/o.net >>360 追記 末尾再帰になっている可能性もありかな
362 :デフォルトの名無しさん :2023/08/27(日) 22:36:37.59 ID:M561FwxM.net Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。 gccは再帰関数をループに置き換えているかもしれないからその確認をしたかったら-S -masm=intelを付けてアセンブリコードを出力させて読んでみよう。
363 :デフォルトの名無しさん :2023/08/28(月) 06:30:35.88 ID:eKgmQu1D.net >>360 変換キャッシュの見方、ありがとうございます >再帰処理をgotoループに置き換えている可能性があります 確認したところ、置き換わっていませんでした >コンパイル型言語のベンチを取る時は再帰処理コードは >避けた方が良いと思います ↑ここ詳しくお願いします >再帰処理をgotoループに置き換えている ↑こうなっていませんでしたが、これ前提での話だったのですか? 再帰fibonacciは個別の言語コンパイラ(更にバージョン)の 最適化ベンチマークには持って来いに見えますので
364 :デフォルトの名無しさん :2023/08/28(月) 06:40:36.37 ID:eKgmQu1D.net >>362 >Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。 その通りでした 確かめたところ二つの再帰関数コールがそのまま残っていて、 その他はNimのトランスパイル過程でのノイズがあるだけです gccがノイズを消すために最適化を頑張った結果、Cより速くなったのですかね
365 :デフォルトの名無しさん :2023/08/28(月) 06:47:48.48 ID:eKgmQu1D.net 何気に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 参考値再掲(>>357 ) 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の最適化が凄すぎて意味わからないですが、ありがたく享受する事にします
366 :デフォルトの名無しさん :2023/09/06(水) 06:10:42.54 ID:8VjD58re.net レバテックωωω Rust in Nim out ωωωωωω
367 :デフォルトの名無しさん :2023/11/15(水) 08:06:37.71 ID:6Kiw7POr.net >>353 F#が、 F# Dataってライブラリで、コンパイル時に ファイルの読み取りは、やってたけれど、あまり見かけないね。
368 :デフォルトの名無しさん :2023/11/28(火) 09:23:46.10 ID:XbNpNPYt.net happyxってdjungoの上位互換なれねーかな https://hapticx.github.io/happyx/#/
369 :デフォルトの名無しさん :2023/12/06(水) 09:31:30.20 ID:oM0gjrfW.net >>367 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 は我々に教えてくれます
370 :デフォルトの名無しさん :2023/12/06(水) 20:32:47.84 ID:7Cu2FhSW.net Nim って python を強調し過ぎてるのはミスリードだと思うな python と相性が良いってのは事実だけど Nim の特徴のほんの一部でしかない
371 :デフォルトの名無しさん :2023/12/08(金) 21:38:37.62 ID:xBCOoZoU.net >>370 Python使える人が多いからNimを広めるためにNim言語はpythonと同じだという人は多い。 文法がpythonに近いだけで中身は静的型言語だからpythonよりC++とかRustに近いと思う。 pythonしか知らない人がNimのオーバーロードとかGenericsとかobjectとref objectの違いとかちゃんと理解して使えるのかどうか心配になる。
372 :デフォルトの名無しさん :2023/12/10(日) 11:41:19.18 ID:1MxEINjf.net 「文法がpythonに近い」が事実じゃないんだよな 観た目が似てるだけであって文法が似てる訳じゃない 全然別物
373 :デフォルトの名無しさん :2023/12/10(日) 17:02:37.56 ID:S5Hrhavn.net そういう意味では構文で結構損してそう オフサイドルールが気に入らない人にとってはそもそも検討に値しないし Python好きな人ならそこは気にならないだろうけど、別に移行しやすくもない
374 :デフォルトの名無しさん :2023/12/11(月) 04:52:12.28 ID:E9pPgJ3z.net >>373 でも静的型言語でオフサイドルールの言語はNimとcrystal以外あまりないのでは。 オフサイドルールが好きで型システムがちゃんとしていて高速に動くプログラムを書きたい人にはぴったり。
375 :デフォルトの名無しさん :2023/12/11(月) 06:10:19.79 ID:dU0p99Eo.net 型で安全性を静的に担保したいと考える人が、同時にインデントで意味が変わってしまうオフサイドを好むってのはちぐはぐさを感じる
376 :デフォルトの名無しさん :2023/12/11(月) 06:46:36.74 ID:Oijs0Efp.net HaskellとデフォルトF#もオフサイドルールありですね。どうせインデントするんだしって使ってやれってくらいの感じなのかね? あとは、インデントに意味はないけれど、goが標準のフォーマッタでインデント入れてくるね。
377 :デフォルトの名無しさん :2023/12/11(月) 06:54:57.74 ID:n3cFiyWX.net Python登場当時だと{}前後のどこで改行するか論争みたいなのがあったりして確かに括弧書くのが面倒な空気はあったんだよな それがGo/Rustの世代だと言語標準のフォーマッタが勝手にやってくれるってなって めんどくさくないっていうオフサイドのメリットはなくなってしまった そうすると自動フォーマットしづらいとかコピペしづらいとかデメリットばかり目立つことになってしまう
378 :デフォルトの名無しさん :2023/12/12(火) 04:50:08.02 ID:X9wYEqIf.net ブロック毎に'{}'や行末に';'があるとソースコードが少し汚く見えるし 無いとすっきりして読みやすいと思うけどね。
379 :デフォルトの名無しさん :2023/12/12(火) 05:58:22.17 ID:6YpoyKxr.net そんなの単なる慣れ
380 :デフォルトの名無しさん :2023/12/12(火) 08:04:30.17 ID:BxX9TTWN.net まぁ人によるんじゃない 自分は{}がある方がブロックの識別性が良くて読みやすい オフサイドは特にネストしたブロックの戻りが何段戻ったか見づらいんだよな
381 :デフォルトの名無しさん :2023/12/12(火) 08:08:33.42 ID:BYtUbVYs.net カッコありなら、lisp系が好き。 悩む事が減る。
382 :デフォルトの名無しさん :2023/12/12(火) 13:00:45.46 ID:GxOznL1S.net >>378 セミコロンはオフサイドルールじゃなくてもRuby/Go/Kotlin/Swiftのように無しできるから関係ないよね それにセミコロンをタイプするのは面倒だとは思うが慣れると読む時のノイズにはならない 自然言語の文章で句点やピリオド+改行がノイズにならないのと同じこと
383 :デフォルトの名無しさん :2023/12/12(火) 19:48:14.86 ID:X9wYEqIf.net CやC++を10年以上使っていたけど';'や'{}'が無いほうがすっくりして読みやすいと思うから慣れでどうにかなるものでは無いと思う。 こういうのは個人差があるのかもしれないが
384 :デフォルトの名無しさん :2023/12/12(火) 19:54:02.65 ID:X9wYEqIf.net ttps://github.com/jeetsukumaran/vim-indentwise このVimのプラグインを使うと同じインデント間のカーソル移動、異なるインデント間のカーソル移動が簡単にできるからお勧めです。
385 :デフォルトの名無しさん :2023/12/12(火) 22:53:30.64 ID:wCEkJKJx.net >>383 CやC++やっててそんなこと言うやつ初めて聞いたぞ 本当に日々コード書いてる?
386 :デフォルトの名無しさん :2023/12/12(火) 23:44:06.92 ID:CyOM3fCk.net そりゃ仕事で使える言語でオフサイドルールなのってPythonくらいだし ほんとはオフサイドがいいけどC/C++の仕事してるって人くらいいるでしょ
387 :デフォルトの名無しさん :2023/12/13(水) 00:18:56.36 ID:YitMt0Fm.net >>386 {}や;がノイズになるかどうかと オフサイドがいいかどうかの話は別だよ
388 :デフォルトの名無しさん :2023/12/13(水) 04:42:50.35 ID:/pcasGi0.net >>385 今はC/C++殆ど書いてないけど以前はほぼ毎日使ってたよ。 {}や;に慣れてもやっぱり余計な文字が少ない方がすっきりして読みやすいと思うのだが、そういう人は少数派なんかな?
389 :デフォルトの名無しさん :2023/12/13(水) 05:36:33.39 ID:R3z2LBuJ.net 主観で読みやすいかどうか力説しても結論でるわけない オフサイドは誤ってインデントずれても気付かないままになってしまうのが問題
390 :デフォルトの名無しさん :2023/12/13(水) 06:48:31.89 ID:RhfHz66O.net >>388 まぁ実際オフサイド採用の新規言語ってあまり出てこないし 少数派なんじゃないかな
391 :デフォルトの名無しさん :2023/12/13(水) 07:21:31.19 ID:vQeZuGNk.net f#みたいに、使う側が選択できれば、解決なんじゃない?
392 :デフォルトの名無しさん :2023/12/13(水) 07:35:42.19 ID:q/L8o2wk.net やれやれお前らCOBOLを知らんのか
393 :デフォルトの名無しさん :2023/12/13(水) 11:38:44.64 ID:rzHxkjlX.net >>388 どちらの方がすっきりして読みやすいかと {}や;が思考ノイズになるかどうかは別だよ 前者はそれなりにいる 後者はツチノコレベルで稀有
394 :デフォルトの名無しさん :2023/12/14(木) 19:26:43.32 ID:xAMEKx/6.net エディタの色設定で{};を薄い色にすればいいだけやん
395 :デフォルトの名無しさん :2023/12/15(金) 03:05:56.17 ID:/ClHmJDY.net {}がノイズになるようなら:や=はもちろんのことblock:なんて発狂ものだろうからNimは無理やろな
396 :デフォルトの名無しさん :2023/12/15(金) 05:55:25.21 ID:12rLPAnL.net 思考ノイズって エロい事連想してるって意味だよな?
397 :デフォルトの名無しさん :2023/12/15(金) 06:50:06.26 ID:4QMbv0z8.net Nimってオフサイドルール以外の所は目立った欠点の無い言語なんかな。 それに実際にオフサイドルールでコードを書いていて困ったことないし。 インデントがずれても困るという人はインデントの幅をスペース4個とか広めにすればいいのでは
398 :デフォルトの名無しさん :2023/12/15(金) 17:55:10.13 ID:BxRUp1+8.net オフサイドルールは欠点だらけ Pythonを例にすると - カットペーストは命がけ - ネット等で共有しにくい - テキストエディタやIDEの支援が激弱 - dedentは手動タイピング必須 - 改行のために追加の()や\が結局必要 - インデントだけでは可読性が低いから余計な:が必要 - 空行の数まで厳密に意識する必要もある - lambdaのone expression縛りのように言語の成長を阻害しやすい - “explicit is better than implicit”と言いながらブロックはimplicit
399 :デフォルトの名無しさん :2023/12/15(金) 18:18:19.69 ID:b3hxnew5.net 次は、良い点を挙げてみて!
400 :デフォルトの名無しさん :2023/12/15(金) 18:24:50.43 ID:pkr2dCwK.net >>399 プログラミング初心者を釣れる 以上
401 :デフォルトの名無しさん :2023/12/15(金) 20:46:34.27 ID:4QMbv0z8.net Vim使ってるけどコピペは問題無くできるしインデントの深さもブロックごと'>'で調整できる。 vim-indentwiseでブロック毎カーソル移動可能。 スペース一個分だけでインデントするとかしない限りブロックの開始、終わりは前後の行のインデントの位置の違いでわかる。 vim-indentwiseでカーソル移動すればブロックの範囲も簡単にわかる。 以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。 Nim書いていて改行のために追加の()や\が必要になることはほぼ無い 空行の数を厳密に意識する必要もない。 Nimを実際に書いたことあるの?
402 :デフォルトの名無しさん :2023/12/15(金) 21:02:40.08 ID:4QMbv0z8.net https://wandbox.org/permlink/Nfe6exUFmtWPdWZj NimのAnonymous proceduresでは複数行書けるし こうしてコードを共有できてる。
403 :デフォルトの名無しさん :2023/12/15(金) 22:17:03.24 ID:kBMLRaUx.net >>402 でもアロー関数にすると()を追加するなどしないと1行しか書けなくなる これもオフサイドルールのせい しかもこんな明らかなバグでも修正しようともしない 言語の成長を阻害するとはこういうこと
404 :デフォルトの名無しさん :2023/12/15(金) 22:29:33.41 ID:kBMLRaUx.net >>401 論点理解せずにvim使いなら誰でも知ってる基本を必死に解説されても困るわ >以前はC/C++を書いてたけど{}や;が無くて読みづらいとか書きづらいとか思ったことは無いよ。 {}や;が無くて読みづらいとか書きづらいとか誰もそんなこと言ってないだろ? 勝手に脳内変換するなや ついでに言うとセミコロン無い方が書きやすいのは当たり前のこと だから新しい言語の多くがセミコロンレスを採用してる(オフサイドは採用しないけど)
405 :デフォルトの名無しさん :2023/12/15(金) 23:45:28.85 ID:4QMbv0z8.net >>403 アロー関数ってNimのsugarモジュールにある`=>`マクロのこと? あくまでこの=>は二項演算子だから両辺は式になっていないといけない。 オフサイドルールに関係無く二項演算子の両辺に文を直接書けず式を置かないといけないのは殆どのプログラミング言語で同じじゃない? 複数文を書きたければanonymous procedureで書けばよいし。 オフサイドルールじゃない言語で無名関数に複数文を書くときは必ず{}で囲む必要があるし。 どうしてこれが言語の成長を阻害していることになるの? 明らかなバグなのに修正しようとしないって言うけどGithubのNimのリポジトリにそういうissueある? 無名関数を書くときはdo notationというのもあるよ。 https://nim-lang.org/docs/manual.html#procedures-do-notation
406 :デフォルトの名無しさん :2023/12/16(土) 08:47:38.44 ID:yzC0WAGQ.net 「vimを使えばいい」とか「無名関数を使えばいい」などと列挙されても 他の言語はそんな特別なケアなしに使えるわけでな… このあたりがいまいち広まらない原因なんじゃない?
407 :デフォルトの名無しさん :2023/12/16(土) 08:53:10.18 ID:mPzLcjX0.net 以前インデントの代わりに{}を使える機能があったようだ。 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
408 :デフォルトの名無しさん :2023/12/16(土) 09:38:42.94 ID:mPzLcjX0.net >>406 現代では高機能なテキストエディタやIDEが使えるから それを使うことを前提にプログラミング言語をデザインしたらいいんじゃね? って話は聞いたことがある。 sugarの`=>`マクロはNim言語のanonymous procedureを特定の条件下で簡単に書けるよう作られたもので完全にanonymous procedureを置き換えられるものでない。 sugarモジュール自体がシンタックスシュガーのようなものを提供するマクロなどを集めたものだし。 制限とか気にせずにanonymous procedureを書きたかったら=>を使わずに書くしかない。
409 :デフォルトの名無しさん :2023/12/16(土) 09:56:43.39 ID:yzC0WAGQ.net >>408 そのへんがまさに省略記法の悪い点が出てる感じするな 省略するってことはソースコードの情報量は減っていて、それはタダではない 「OOのときにはXXを使う」みたいな規則がたくさん発生するというコストがあるんだよね これはセミコロンレスもそうで、時々変なエッジケースが発生したりする
410 :デフォルトの名無しさん :2023/12/16(土) 16:45:38.17 ID:kvk3r8Lt.net オフサイドルールと違ってセミコロンレス(optional semicolon)は多くの言語で妥当なトレードオフ オフサイドルールが妥当なトレードオフとして成立してるのはHaskell系の言語くらい
411 :デフォルトの名無しさん :2023/12/16(土) 20:00:00.36 ID:USjLXMUH.net なんかどうでもいいことをいつまでも うじうじと 気に入らないなら使わなきゃいいだけ 気に入ったら使えばいいだけ
412 :デフォルトの名無しさん :2023/12/17(日) 07:10:31.29 ID:clYlz397.net >>411 気に入っていても: ある日突然: 気に入らなくなる事ってあるよね? 気に入らなくても: ちょっとしたきっかけで: すごく気に入ってしまうことも あるよね? そういう時はどうすればいいの?
413 :デフォルトの名無しさん :2023/12/17(日) 12:19:34.98 ID:WUPd6f5k.net >>412 > すごく気に入ってしまうことも > あるよね? Error: invalid indentation
414 :デフォルトの名無しさん :2023/12/17(日) 18:41:59.56 ID:F9NekDqG.net Nimはよく考えずに機能追加して既にC++並みに複雑化してる 目新しさだけで飛びつくと後悔するぞ
415 :デフォルトの名無しさん :2023/12/18(月) 02:13:02.65 ID:DdCrjTir.net そうなの? じゃあもうC++でいいじゃん
416 :デフォルトの名無しさん :2023/12/18(月) 08:55:26.31 ID:DG+uqCiP.net 例えば最近実装している変更についてもちゃんとここに理由とか書いてあるよ。 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++のほうがはるかに複雑だよ。
417 :デフォルトの名無しさん :2023/12/18(月) 20:40:29.88 ID:DG+uqCiP.net Nim言語がどのような考えで設計されたか知りたい人はNimのblogを読むといいよ。 https://nim-lang.org/araq/ https://nim-lang.org/blog.html
418 :デフォルトの名無しさん :2023/12/18(月) 20:49:37.54 ID:CbnA3O4k.net Nimの現状を知りたい人はこれを読むといい https://forum.nim-lang.org/t/9145
419 :デフォルトの名無しさん :2023/12/19(火) 00:16:35.74 ID:mrSFrPG8.net 議論をよく読めば何やらちゃんと考えて実装しているらしいのはC++も同じなんだよなあ
420 :デフォルトの名無しさん :2023/12/19(火) 08:00:58.06 ID:w9OEXcqM.net >>419 単純に >>414 への反論なだけじゃない?
421 :デフォルトの名無しさん :2023/12/20(水) 12:37:14.01 ID:Cvw2c2UZ.net バグ修正版のNim 2.0.2と1.6.18がリリースされました。 https://nim-lang.org/blog/2023/12/19/versions-1618-202-released.html
422 :デフォルトの名無しさん :2023/12/23(土) 09:16:16.92 ID:VfEmk1mn.net 寂しいスポンサーページだな😢 https://nim-lang.org/sponsors.html こりゃnimが普及しないのも当然か rustとは大違い https://foundation.rust-lang.org/members/
423 :デフォルトの名無しさん :2023/12/23(土) 10:35:51.40 ID:M8dtHAyN.net でもRustは誰も使ってないじゃん
424 :デフォルトの名無しさん :2023/12/23(土) 11:58:51.47 ID:BXldyzev.net Rust言語はトヨタ自動車が採用してると どこかで読んだ
425 :デフォルトの名無しさん :2023/12/23(土) 13:41:38.19 ID:fLdoaHTJ.net >>423 誰も使ってないは草
426 :デフォルトの名無しさん :2023/12/23(土) 13:46:35.58 ID:6J3b/0Sr.net Nimと書き間違えたんだと思うが
427 :デフォルトの名無しさん :2023/12/23(土) 18:13:17.30 ID:A6gu1Hml.net Nimを使っている組織のリスト https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim
428 :デフォルトの名無しさん :2023/12/27(水) 19:41:58.29 ID:g/RhhP+m.net プログラムをビルドするためにC++だったらCMake、Rustだったらcargo.tomlにTOMLを使う。 Nimだったらconfig.nimsも.nimbleファイルもNim言語で書ける。 一つの言語でコンパイル言語としてもスクリプト言語としても使えて便利。 Nimはマクロやconstなどをコンパイル時に実行するためにVM使ってるんだけど、そのVMを使ってNimをスクリプト言語のように実行できるらしい。
429 :デフォルトの名無しさん :2023/12/27(水) 19:50:00.04 ID:J2C6aYvl.net rustも複雑なことをしようと思ったらbuild.rsに書けるけど、それはそうとして依存関係をプログラム言語で書きたいかと言われると
430 :デフォルトの名無しさん :2023/12/27(水) 20:16:43.40 ID:E4kPlntL.net あれもこれもできて便利!みたいなのはぱっと見良さそうでも 大規模・多人数・長期開発になると負債になりがちではある
431 :デフォルトの名無しさん :2023/12/27(水) 20:24:29.72 ID:qErwbOrg.net happyxが起爆剤にならないかなぁ、、🙏
432 :デフォルトの名無しさん :2023/12/27(水) 23:05:07.37 ID:LUGQIuRd.net zigなら全部zigで書ける(便乗)
433 :デフォルトの名無しさん :2023/12/27(水) 23:27:30.38 ID:7WiLoZ1Z.net 一体なにがエレガントなんだろうなこの言語って
434 :デフォルトの名無しさん :2023/12/27(水) 23:34:47.36 ID:qmMlPacq.net まあアイコンはエレガントなんじゃない?王冠だし
435 :デフォルトの名無しさん :2023/12/27(水) 23:51:57.04 ID:Ra91RrOg.net procとmethodとfuncを使い分けつつ{.global.}や{.async.}なとの{.pragma.}とmacroでぐちゃぐちゃにかき混ぜられるのが超エレガントw 他の言語では類を見ない
436 :デフォルトの名無しさん :2023/12/28(木) 22:46:05.11 ID:u+MANgUc.net エレガントすぎてついていけないわ
437 :デフォルトの名無しさん :2023/12/28(木) 23:18:44.60 ID:u+MANgUc.net エレガントすぎてついていけないわ
438 :デフォルトの名無しさん :2024/02/20(火) 19:40:26.76 ID:iQdtjO/s.net 新年の記念 保守
111 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200
本文 スレッドタイトル 投稿者