nim
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 新年の記念 保守
439 :デフォルトの名無しさん :2024/06/17(月) 22:36:28.67 ID:y0rZbngO.net https://nim-lang.org/blog/2024/06/17/version-206-released.html Nim version 2.0.6がリリースされました。
111 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200
本文 スレッドタイトル 投稿者