00:43:26 | FromDiscord | <Elegantbeef> I agree who needs LLMs when you can read 😛 |
01:10:46 | FromDiscord | <Robyn [She/Her]> In reply to @nnsee "the problem is that": Codeium seems to do alright tbh |
01:11:34 | FromDiscord | <Robyn [She/Her]> only really used it to automate tedious code rather the writing all the logic |
01:18:37 | FromDiscord | <.throwstar> In reply to @Elegantbeef "I agree who needs": Who needs literacy when you have examples |
03:25:00 | * | rockcavera quit (Remote host closed the connection) |
03:45:32 | FromDiscord | <lainlaylie> LLMs being bad at Nim is a Nim feature, it means most Nim code out there is high quality... written by people who have read the documentation... and know what theyre doing... |
03:52:31 | * | SchweinDeBurg quit (Quit: WeeChat 4.6.0-dev) |
03:53:00 | * | SchweinDeBurg joined #nim |
03:54:11 | ehmry | some people are also publishing bad nim code just for llms to consume |
03:54:24 | FromDiscord | <Elegantbeef> I have a name |
04:20:15 | FromDiscord | <odexine> In reply to @sleeves "why use LSP and": what, you dont have the docs memorised and etched into your brain yet? |
05:42:13 | FromDiscord | <michael.lenz.> I unable to remember the docs anymore. The amount of the data needed to operate exceeds human abilities. Detailed reference/manual is a must in modern development. |
09:02:50 | * | beholders_eye joined #nim |
09:46:12 | * | beholders_eye quit (Ping timeout: 252 seconds) |
09:58:10 | * | beholders_eye joined #nim |
13:22:42 | * | alexdaguy joined #nim |
13:43:43 | FromDiscord | <Phil> 10 seems like weaksauce, I'll be honest |
13:58:04 | FromDiscord | <summarity> Is there a (unit) test framework for Nim that has output compatible with VSCode's Test Provider function, so failed tests are rendered correctly in the test panel? |
14:08:32 | * | alexdaguy quit (Quit: ded) |
14:37:50 | * | ntat joined #nim |
15:37:36 | * | Guest89 joined #nim |
15:38:51 | * | ntat quit (Quit: Leaving) |
16:15:03 | FromDiscord | <luteva> Codeium is quite cool. I do agree. Also Claude is much better than openai at least for Software Developers. (In my opinion!) |
16:20:14 | * | Guest89 quit (Quit: Client closed) |
16:37:52 | FromDiscord | <michael.lenz.> All these tools are good in text formatting, naming objects, but all these tools can ruin the code you want to achieve. The most dangerous thing is tht I believe people will stop learning, and most dangerous is to stop thinking |
16:38:51 | FromDiscord | <michael.lenz.> I have seen how one bruteforced gpt without any working result |
16:41:46 | FromDiscord | <michael.lenz.> I used gpt recently to have inline assembly with proper synthax that compiler understands. So it’s turned into repetitive answers from gpt with obvious errors it made |
16:43:40 | FromDiscord | <michael.lenz.> It typed alot of unnecessary instructions with wrong syntax. While real working code takes 4-5 lines of asm |
16:44:12 | FromDiscord | <fabric.input_output> don't ask it for complex ffmpeg commands |
16:45:23 | FromDiscord | <odexine> dont ask it anything more complex than some edits ngl.. |
16:47:34 | FromDiscord | <michael.lenz.> It wasn’t really complex task. I needed to read two 16 bit data from the bios function and store values to the variables |
16:49:53 | FromDiscord | <michael.lenz.> Sccz80 compiler sucks , along with their documentation. And asm is not something you do every day to remember how do it properly |
16:50:50 | FromDiscord | <michael.lenz.> (edit) "Sccz80 compiler sucks , along with their documentation. And asm is not something you do every day to remember how ... do" added "to" |
16:51:34 | * | ntat joined #nim |
18:27:20 | * | beholders_eye quit (Ping timeout: 244 seconds) |
18:36:37 | FromDiscord | <nervecenter> LLMs mess up math big time. Don't ask them anything about how to perform specific calculations (in my case frequency-domain post-FFT stuff). They'll get it wrong, and if you notice it, they'll correct...with more mistakes. |
18:37:10 | FromDiscord | <nervecenter> I didn't even ask to perform the calculations, just the formulas for how to do them given there was one step I was unsure about. |
18:45:36 | FromDiscord | <starkiller1493> o1 is pretty good at math, r1 too |
19:26:09 | FromDiscord | <threefour> But you can't rely on it. If you take the time to verify that what it gave you is correct, you may as well have just figured it out yourself. Same thing with using them for code. Sure, it _looks_ correct. But I wouldn't want to entrust it to a production environment without thorough testing and analysis, which would negate most of my time saving. |
19:28:14 | FromDiscord | <threefour> LLMs are good at approximations of correctness, but not things that require actual correctness. |
19:28:24 | FromDiscord | <threefour> (edit) "correctness." => "correctness, and certainly not reliably." |
19:38:32 | FromDiscord | <starkiller1493> True↵They are a great time saver for boiler plate and for one time use scripts though |
19:55:43 | * | ntat quit (Quit: Leaving) |
20:07:07 | FromDiscord | <aintea> Once proper structural pattern matching and sum types are implemented in Nim, would it be too crazy to rewrite the standard library to use Results instead of exceptions ? Same question for rewriting the standard library without a GC |
20:09:39 | FromDiscord | <muddmaker> Every project that tries to use result types to get away from exceptions eventually finds themselves re-creating exceptions with it |
20:16:45 | FromDiscord | <aintea> It just makes the language force you to handle all cases |
20:17:05 | FromDiscord | <aintea> results are basically errors as value, and the point is to enforce handling all cases |
20:17:49 | FromDiscord | <Elegantbeef> So does annotating `{.raises:[].}` 😄 |
20:20:00 | FromDiscord | <Elegantbeef> Araq has shown interest in replacing exceptions with a fixed enum error code akin to errono |
20:20:59 | FromDiscord | <fabric.input_output> hell nah |
20:21:06 | FromDiscord | <aintea> In reply to @Elegantbeef "So does annotating `{.raises:[].}`": Not in the main code |
20:21:09 | FromDiscord | <fabric.input_output> if that passes I'm abandoning nim |
20:21:28 | FromDiscord | <aintea> sent a code paste, see https://play.nim-lang.org/#pasty=cbAbCoXf |
20:21:52 | FromDiscord | <aintea> Since Result is an enum, enforcing handling all cases is already here in nim |
20:22:49 | FromDiscord | <fabric.input_output> damn will object variants be abandoned? |
20:23:03 | FromDiscord | <aintea> It won't |
20:23:06 | FromDiscord | <muddmaker> Right, but what if we don't want to handle all cases of an error in that specific place? |
20:23:20 | FromDiscord | <aintea> object variants are shittier enum variants |
20:23:39 | FromDiscord | <aintea> It will work the same, just better since you won't need a `kind` field |
20:23:51 | FromDiscord | <aintea> and you'll be able to name fields the same for a different variant |
20:23:53 | FromDiscord | <muddmaker> You end up making _sugar_ around your error enums to pass the error back up the stack. And now you have exceptions + function coloring |
20:23:57 | FromDiscord | <Elegantbeef> Well they're a different approach that enables different things |
20:24:07 | FromDiscord | <Elegantbeef> Both have their perks and downsides |
20:24:42 | FromDiscord | <aintea> Yes, I'm not saying Nim would be better, I am just saying this is my prefered way of doing things and since we're a lot to use Nim we'll just let the community and Araq decide |
20:24:45 | FromDiscord | <Elegantbeef> Object variants do not require repeating shared fields across branches and allow dot operators to reference fields of the same name without having distinct typing across branches |
20:25:39 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=zbTGuzXi |
20:26:23 | FromDiscord | <aintea> now that's something I didn't know |
20:26:27 | FromDiscord | <aintea> thanks for the tip |
20:26:27 | FromDiscord | <fabric.input_output> In reply to @aintea "object variants are shittier": I like them because shared fields |
20:26:50 | FromDiscord | <aintea> you'll be able to do it with enum variants too |
20:27:04 | FromDiscord | <aintea> however I'm not sure that enum variants being implemented means thatobject variants will disappear |
20:29:13 | FromDiscord | <Elegantbeef> I don't imagine you'll be able to do that with the enum variants as written as the payload is typed across branches |
20:29:14 | FromDiscord | <Elegantbeef> As a matter of fact the current suggest syntax has no room for it |
20:39:39 | * | arkanoid joined #nim |
21:09:58 | * | ntat joined #nim |
21:15:54 | * | arkanoid quit (Ping timeout: 252 seconds) |
21:23:07 | * | rockcavera joined #nim |
21:51:43 | FromDiscord | <ieltan> I think Nim exceptions are good, just that it lacks ergonomics for fine grained error handling |
22:06:38 | FromDiscord | <Robyn [She/Her]> GDExt looks p nice ngl... |
22:09:43 | * | ntat quit (Quit: Leaving) |
22:12:10 | FromDiscord | <michael.lenz.> Nim exceptions mag cause panic and crash |
22:12:23 | FromDiscord | <michael.lenz.> When no ram available |
22:13:06 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=vKXSdKKu |
22:13:06 | FromDiscord | <Robyn [She/Her]> Dam |
22:13:13 | FromDiscord | <Robyn [She/Her]> (edit) "https://play.nim-lang.org/#pasty=dqVmFoxG" => "https://play.nim-lang.org/#pasty=DRtEcdbg" |
22:16:26 | FromDiscord | <Elegantbeef> @michael.lenz. in low memory situations you can always preallocate the exception |
22:16:38 | FromDiscord | <Robyn [She/Her]> Looking at it more... I don't think I like it much rip |
22:17:55 | FromDiscord | <nnsee> In reply to @Elegantbeef "<@812260016890576936> in low memory": how does that work exactly? |
22:18:30 | FromDiscord | <Elegantbeef> You pre allocate an exception of the possible types you may raise in your library, then if you hit it you raise one of the preallocated ones |
22:18:36 | FromDiscord | <Robyn [She/Her]> https://github.com/Dheatly23/godot-wasm this looks cool tho |
22:19:35 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=HiQFyGgC |
22:19:47 | FromDiscord | <Elegantbeef> Whoops `= (ref ValueError)()` |
22:22:40 | FromDiscord | <michael.lenz.> In reply to @Elegantbeef "<@812260016890576936> in low memory": Yeah. That’s true. But who will remember this when that happens. Also in case of oom output of exception text may be lost |
22:22:57 | FromDiscord | <Elegantbeef> Well not if you use a static message 😛 |
22:23:45 | FromDiscord | <Elegantbeef> Yes this turns this into a sophisticated `setjmp` |
22:24:08 | FromDiscord | <michael.lenz.> In reply to @Elegantbeef "Well not if you": Sure, you’re right. Only what I mean, the enums may solve this problem |
22:24:43 | FromDiscord | <michael.lenz.> Enums also should be faster |
22:58:08 | FromDiscord | <zumi.dxy> In reply to @muddmaker "Every project that tries": can confirm |
22:58:21 | FromDiscord | <zumi.dxy> backtraces my beloved |