| 00:00:30 | EXetoC | well it's initialized to nil |
| 00:00:37 | dtscode | ah |
| 00:01:20 | EXetoC | with the absence of {.noinit.}. yay sensible semantics |
| 00:07:42 | joecodes2 | ah, I see EXetoC. I added result = @[] at the top of the function and it works now. I thought "result" was initialized automagically. |
| 00:08:05 | BlaXpirit | [:59:50] <EXetoC> well it's initialized to nil |
| 00:08:12 | * | VinceAddons quit (Ping timeout: 245 seconds) |
| 00:08:55 | * | VinceAddons joined #nim |
| 00:09:11 | * | Demon_Fox quit (Quit: Leaving) |
| 00:16:06 | * | superfunc joined #nim |
| 00:17:13 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 00:33:58 | dtscode | .eval type foo = class; bar: int;let baz = foo |
| 00:34:01 | Mimbus | dtscode: eval.nim(4, 6) Error: invalid indentation |
| 00:34:15 | dtscode | .eval type foo = class bar: int;let baz = foo |
| 00:34:18 | Mimbus | dtscode: eval.nim(3, 11) Error: undeclared identifier: 'class' |
| 00:51:51 | BlaXpirit | .eval type foo = class; bar: int;let baz = foo |
| 00:51:54 | Mimbus | BlaXpirit: eval.nim(4, 4) Error: invalid indentation |
| 00:57:29 | Araq | flaviu: any chance you fix the re bugs now that you obviously know how to fix them? |
| 00:59:19 | flaviu | Araq: And loose one of the advantages of my new module? :O |
| 01:00:36 | flaviu | Seriously though, I'd rather not. Backwards compatibility is a huge PITA and would prevent me from making real improvements. |
| 01:01:18 | BlaXpirit | these bugs are the kind that shouldn't show up unexpectedly |
| 01:01:28 | Araq | well I don't think anybody depends on the "infinite loop" behaviours |
| 01:01:37 | BlaXpirit | what i mean is, people have tested the regexes they use, and they know what will work and what won't |
| 01:01:48 | flaviu | That's not in re, that's in system or strutils |
| 01:01:56 | BlaXpirit | i dont think so really |
| 01:02:12 | BlaXpirit | Araq, the most important thing is increment the current index not just by last index + length of match, but at least by 1 |
| 01:02:20 | * | yonson quit (Quit: Leaving) |
| 01:02:44 | flaviu | BlaXpirit: But not always one - sometimes it needs to be 2, or 3, or 4! |
| 01:03:08 | BlaXpirit | huh |
| 01:03:12 | BlaXpirit | utf? |
| 01:03:20 | flaviu | and crlf |
| 01:03:21 | Araq | I mean these endless loops surely break somebody's workflow http://xkcd.com/1172/ but let's fix it anyway |
| 01:03:53 | flaviu | My code is MIT, you can probably just copypaste it in. |
| 01:04:08 | BlaXpirit | but it's different from the ground up |
| 01:04:15 | BlaXpirit | i imagine it's difficult to combine the codes |
| 01:05:22 | flaviu | Not really. I only use the bounds information in split(...) |
| 01:05:40 | flaviu | but my findIter is a lot more complicated: https://github.com/flaviut/nre/blob/master/src/nre.nim#L327-L366 |
| 01:06:01 | BlaXpirit | oh man |
| 01:06:04 | BlaXpirit | docopt is in danger |
| 01:06:21 | * | superfunc quit (Quit: Page closed) |
| 01:06:36 | BlaXpirit | i though unicode might be a problem, but now that find out that my approach to reinventing the wheel is also wrong |
| 01:08:38 | BlaXpirit | i reimplemented re.split with captures included on top of re functions. and used this "at least 1" thing :/ |
| 01:21:10 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 01:26:19 | * | VinceAddons quit (Read error: Connection reset by peer) |
| 01:34:54 | * | gsingh93 joined #nim |
| 01:51:03 | * | sampwing quit (Ping timeout: 252 seconds) |
| 02:05:01 | * | vezzy quit (Quit: No Ping reply in 180 seconds.) |
| 02:06:44 | * | quasinoxen joined #nim |
| 02:08:28 | * | saml_ joined #nim |
| 02:24:30 | * | vendethiel quit (Ping timeout: 276 seconds) |
| 02:35:28 | * | Demon_Fox joined #nim |
| 02:37:09 | * | Varriount|Laptop quit (Quit: Page closed) |
| 02:37:32 | * | Varriount|Laptop joined #nim |
| 02:39:37 | Varriount|Laptop | Anyone up? |
| 02:45:18 | * | vendethiel joined #nim |
| 02:46:28 | flaviu | Yep, not for long though. |
| 02:51:23 | * | johnsoft quit (Ping timeout: 240 seconds) |
| 02:52:16 | * | johnsoft joined #nim |
| 02:53:12 | * | sampwing joined #nim |
| 02:55:37 | Varriount|Laptop | Hello sampwing |
| 02:55:48 | sampwing | howdy |
| 02:55:56 | * | kapil__ joined #nim |
| 02:57:29 | * | Varriount joined #nim |
| 02:59:15 | * | Varriount|Laptop hi-fives his twin |
| 03:03:08 | * | brson quit (Quit: leaving) |
| 03:06:41 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 03:09:09 | * | sampwing quit (Ping timeout: 252 seconds) |
| 03:30:06 | ldlework | http://www.reddit.com/r/programming/comments/2scodb/a_quick_comparison_of_nim_vs_rust/cnpb791 |
| 03:38:19 | * | Varriount|Laptop quit (Ping timeout: 246 seconds) |
| 03:38:20 | * | Demon_Fox quit (Quit: Leaving) |
| 03:42:05 | ldlework | "Well if you come up with concrete simplifications I'm all ears, but usually when I strive for simplicity I only get the blame: forward declarations, no classes or interfaces in the core language, no nil-safety, no real algebraic datatypes, no Rust-like lifetime annotations, etc." |
| 03:42:16 | ldlework | Who is telling Araq not to add these features?! |
| 03:42:30 | ldlework | "Personally I would throw away multi-methods completely but now some projects use them extensively and they provide a smoother transition for people coming from classical OO based languages." |
| 03:42:37 | ldlework | Oh god, no one let Araq do this! |
| 03:42:38 | ldlework | ;) |
| 03:43:23 | * | EXetoC quit (Ping timeout: 244 seconds) |
| 03:44:15 | ldlework | proc sum(a, b): auto = a + b |
| 03:44:17 | ldlework | echo sum(5, 3) |
| 03:44:19 | jsudlow | +1 for forward declarations |
| 03:44:19 | ldlework | wow that's cool! |
| 03:56:20 | Triplefox | gosh, i like multi-methods though |
| 03:59:23 | * | nande quit (Ping timeout: 240 seconds) |
| 04:01:45 | * | saml_ quit (Quit: Leaving) |
| 04:09:46 | * | nande joined #nim |
| 04:16:13 | * | sampwing joined #nim |
| 04:40:27 | * | sampwing quit (Ping timeout: 252 seconds) |
| 04:53:28 | * | sampwing joined #nim |
| 04:59:09 | dtscode | if i write a variation of strutils.split can i get it added to the stdlib |
| 04:59:09 | dtscode | ? |
| 05:03:22 | fowl | dtscode, there is quite a bureaucratic process to change the stdlib, it could take months |
| 05:03:42 | dtscode | damn :/ |
| 05:04:30 | fowl | im kidding >_> |
| 05:04:47 | dtscode | oh... i didnt think it was that hard to change it lol |
| 05:05:57 | fowl | post it on the forums, its easier to follow a conversation there |
| 05:06:54 | dtscode | ok. do you know of anyway to get jester to run on a different port? |
| 05:10:53 | * | sampwing quit (Ping timeout: 252 seconds) |
| 05:16:07 | * | Demos quit (Read error: Connection reset by peer) |
| 05:24:26 | * | dtscode quit (Quit: (dtscode.io)) |
| 05:26:45 | * | dtscode joined #nim |
| 05:29:15 | joecodes2 | dtscode: var settings = newSettings(port = Port(1234)) # dom96 should put that on the faq. i just asked that myself the other day... |
| 05:30:31 | dtscode | joecodes2, thanks. i actually just moved what was operating on port 5000 |
| 05:40:43 | * | vendethiel joined #nim |
| 05:42:39 | * | kniteli quit (Ping timeout: 264 seconds) |
| 05:45:51 | * | We7W3ntyf0uR joined #nim |
| 05:51:07 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 05:52:06 | dtscode | nim has continue right? |
| 05:55:55 | joecodes2 | yes |
| 06:01:12 | joecodes2 | what this is, i have no idea, don't know what in my code triggers it: lib/system.nim(2986, 6) Error: cannot prove: i <= len(chunks) + -1 |
| 06:03:59 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 06:12:09 | * | vendethiel joined #nim |
| 06:33:12 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 06:42:30 | joecodes2 | how to parallelize processing a file? i have no idea.. here is my stab, hoping someone can make it work: http://forum.nim-lang.org/t/755/1#4398 |
| 06:54:43 | Triplefox | parallel baffles me, mostly because i tend to do things the prover doesn't like |
| 07:01:30 | * | vendethiel joined #nim |
| 07:11:57 | * | SplinterOfChaos quit (Ping timeout: 245 seconds) |
| 07:22:30 | * | vendethiel quit (Ping timeout: 246 seconds) |
| 07:28:37 | * | joecodes2 quit (Ping timeout: 246 seconds) |
| 07:30:02 | * | joecodes2 joined #nim |
| 07:31:44 | * | jefus__ joined #nim |
| 07:35:22 | * | jefus_ quit (Ping timeout: 240 seconds) |
| 07:44:29 | * | bjz joined #nim |
| 07:45:19 | * | bjz quit (Client Quit) |
| 07:52:33 | * | vendethiel joined #nim |
| 08:05:11 | * | gunn_ joined #nim |
| 08:07:05 | * | gunn quit (Ping timeout: 264 seconds) |
| 08:11:10 | * | keyle joined #nim |
| 08:13:37 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 08:34:42 | * | Sphax joined #nim |
| 08:40:23 | * | JinShil quit (Ping timeout: 245 seconds) |
| 08:42:14 | * | vendethiel joined #nim |
| 08:45:12 | * | JinShil joined #nim |
| 08:53:20 | * | Sphax quit (Quit: ZZZZZzzzzz) |
| 08:53:53 | * | Trustable joined #nim |
| 08:55:53 | * | Trustable1 joined #nim |
| 08:56:41 | * | Trustable quit (Read error: Connection reset by peer) |
| 08:56:51 | * | nande quit (Remote host closed the connection) |
| 09:00:28 | * | Sphax joined #nim |
| 09:03:02 | gokr | Morning! |
| 09:05:14 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 09:07:47 | * | kniteli joined #nim |
| 09:10:57 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
| 09:19:57 | * | bjz joined #nim |
| 09:20:24 | * | bjz quit (Client Quit) |
| 09:21:21 | * | NimBot joined #nim |
| 09:24:29 | * | vendethiel joined #nim |
| 09:33:42 | * | darkf quit (Quit: Leaving) |
| 09:44:44 | * | VinceAddons joined #nim |
| 09:46:23 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 09:46:41 | * | bjz joined #nim |
| 09:54:39 | * | BlaXpirit joined #nim |
| 09:55:27 | * | bjz quit (Max SendQ exceeded) |
| 10:05:21 | Araq | joecodes2: well I dunno what to do with the prover for version 1. maybe its error messages will become warnings |
| 10:05:46 | Araq | but then I don't get bug reports ... ;-) |
| 10:16:34 | * | gunn_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:20:13 | * | infrashortfoo joined #nim |
| 10:28:09 | * | bjz joined #nim |
| 10:28:12 | * | bjz quit (Client Quit) |
| 10:32:41 | * | girvo joined #nim |
| 10:32:51 | girvo | hi all :) |
| 10:38:22 | Araq | hey |
| 10:39:36 | * | MajorWork joined #nim |
| 10:41:21 | * | vendethiel joined #nim |
| 10:42:49 | * | MajorWork quit (Changing host) |
| 10:42:49 | * | MajorWork joined #nim |
| 10:48:50 | * | bjz joined #nim |
| 10:59:52 | * | girvo quit (Ping timeout: 245 seconds) |
| 11:16:58 | * | bjz quit (Max SendQ exceeded) |
| 11:17:38 | * | bjz joined #nim |
| 11:17:50 | * | iivvoo left #nim ("Leaving") |
| 11:26:20 | * | Sphax quit (Quit: ZZZZZzzzzz) |
| 11:30:11 | * | matkuki joined #nim |
| 11:34:56 | matkuki | Are forward declarations for procedures always needed if I want to call a procedure that is declared later in a file? |
| 11:37:05 | keyle | http://en.wikipedia.org/wiki/Forward_declaration |
| 11:37:11 | reactormonk | matkuki, pretty much |
| 11:38:39 | matkuki | Oh |
| 11:41:54 | matkuki | Was this a design choice? |
| 11:43:20 | flaviu | I can't answer that question, but macros really make automated forward declarations a lot more complicated. |
| 11:43:24 | * | yonson joined #nim |
| 11:51:11 | * | lyro quit (Quit: WeeChat 0.4.3) |
| 11:54:23 | Zuchto | do nim parse files in just one pass? |
| 11:57:09 | matkuki | Languages I've used like Oberon and D don't need forward declaractions. |
| 11:57:11 | matkuki | Is it possible to add this to Nim itself without the need for macros? |
| 12:00:08 | Zuchto | The usual reason I know for requiring forward declaration is to avoid having to do multiple processing of the source files |
| 12:04:02 | Araq | Zuchto: the compiler uses ~4 passes, so no, that's not the reason |
| 12:04:32 | Zuchto | Yeah, I suspected that was the case :) So I'm very curious what the reasoning behind it is |
| 12:04:49 | matkuki | Yes, me too. |
| 12:05:04 | Araq | Oberon 1 required forward declaration iirc |
| 12:05:25 | Araq | but as flaviu said the primary reason is the macro system |
| 12:06:28 | matkuki | OK, thanks. |
| 12:06:52 | Araq | and yes, we will weaken the requirements for them |
| 12:07:26 | * | keyle quit (Quit: Morbo: Chitchat achieved!) |
| 12:07:34 | Araq | but unlikely before version 1 is out and frankly, when I designed that system it didn't occur to me that people would be bothered too much |
| 12:08:13 | Araq | IMHO it makes perfect sense and makes you much better aware of your dependencies |
| 12:09:02 | Araq | it encodes the call graph quite nicely |
| 12:09:10 | Zuchto | I think it mostly bother us coming from dynamic languages. But there is also the whole DRY issue with declaring functions at multiple places in the code |
| 12:10:41 | Araq | DRY is only an issue for the few procs that actually require a forward decl due to mutual recurive dependencies |
| 12:11:00 | Araq | however, you have to move around procs quite a bit |
| 12:14:03 | Araq | btw it took a tremendous amount of work for D to get rid of them and I think there are still bugs left and this whole "the semantic analyser takes a weird path through the source code" has more disadvantages than advantages |
| 12:22:04 | matkuki | Araq: I have no problem with forward declarations. I've just been using langauges that don't need them like Zuchto said, once you come back to a language that needs them, you get a little confused. |
| 12:24:36 | matkuki | Araq: By the way, Nim feels gramatically so much like Python, I sometimes think Nim is Python and get confused. |
| 12:24:59 | Araq | ha, many disagree with that |
| 12:25:09 | Araq | and think it should be more python-like |
| 12:26:35 | BlaXpirit | is that why you used inclusive intervals? :p |
| 12:27:56 | Araq | I still see no convincing arguments *for* exclusive intervals :P |
| 12:28:21 | Araq | the number of numbers from a to b is b-a+1, every mathematician knows that |
| 12:29:33 | Araq | this whole exclusive upper bounds is ultimately caused by 0 based indexing |
| 12:30:03 | Araq | which is not "natural" either |
| 12:30:55 | matkuki | Araq: I can't tell you enough how much I love Nim's ability for statements like "var", "const" and "type" to be block statements accros multiple lines! |
| 12:31:02 | matkuki | It's so good for readability, brilliant design! Just thought I'd let you know. |
| 12:31:35 | Araq | uh thanks, I got complaints about that too :-) |
| 12:31:56 | matkuki | Many complaints? |
| 12:33:37 | Araq | not too many I think, many more about the export marker * |
| 12:34:51 | Araq | BlaXpirit: the C standard goes to great lengths so that &a[L] is a valid address you can compare against even though you must not deref such a pointer |
| 12:35:14 | Araq | this is just bad design. |
| 12:35:38 | BlaXpirit | uhh whatever |
| 12:59:24 | Zuchto | What is the current commonly complained about limitations of Nim btw? Does it have something like Golangs lack of generics or something? :P |
| 13:00:54 | def- | Zuchto: IDE integration and a REPL would be nice |
| 13:01:10 | def- | not really on the language level though |
| 13:01:26 | Zuchto | ah nice :) IDE and REPL are, in my eyes, non-issues :P |
| 13:02:12 | * | Sphax joined #nim |
| 13:02:15 | Zuchto | I can't seem to remember what it was that made me bail on Nim last time I tried it... It must have been like 1½-2 years ago |
| 13:02:44 | Araq | def-: you should really work on the idetools instead of the REPL. REPL is much harder and not as many people demand it |
| 13:03:02 | Araq | but hey, I'm not telling what to do ... ;-) :P |
| 13:03:05 | def- | Araq: alright, what's the state of idetools then? |
| 13:03:10 | Zuchto | The whole signed/unsigned math thing was one of the first things that set me in alert-mode... but I think it was something with the syntax that really put me off |
| 13:03:28 | def- | I thought you wanted to move idetools out of the compiler? |
| 13:03:46 | Zuchto | IMHO REPL only makes sense with purely intepreted languages |
| 13:04:07 | gokr | Why? |
| 13:04:09 | def- | Zuchto: i like haskell in a repl too. why would it not make sense? |
| 13:04:34 | Araq | I started with that, but didn't come far, def- |
| 13:04:50 | Araq | so it's safe to ignore that work |
| 13:05:03 | Zuchto | def-: true, I shouldn't say "only makes sense"... "significantly more sense" maybe |
| 13:05:54 | def- | Araq: so, what should I do? |
| 13:06:28 | def- | is there a description somewhere of what should work and doesn't and what to change? |
| 13:06:43 | Zuchto | But then I don't use languages like Haskell in REPL either... but that is mostly because I don't like when the repl and intepreter differs (don't remember what the difference is with haskell, just that I've encountered some that bothered me). In python I'm very much a fan of repl tho |
| 13:07:32 | Araq | def-: tests/caas has lots of tests |
| 13:07:48 | BlaXpirit | is there a way to make absolutely everything in a module public? |
| 13:08:55 | Araq | and there is some code to run them in tests/testament/caasdriver.nim |
| 13:09:00 | ekarlso | should a command like registering a package belong in nimble or a sep utility ? |
| 13:09:14 | Araq | ekarlso: in nimble |
| 13:09:53 | Araq | BlaXpirit: you can use a macro for that I think, but you don't want to do that. you want to live with the * |
| 13:10:07 | ekarlso | BlaXpirit: thnx btw for docopt :) |
| 13:10:11 | BlaXpirit | :> |
| 13:11:03 | Zuchto | Btw, Is there any web backend frameworks out there for nim yet? |
| 13:11:16 | * | Zuchto aka. mr. too lazy to google |
| 13:11:29 | ekarlso | Zuchto: jester.. |
| 13:12:04 | ekarlso | Zuchto: http://github.com/ekarlso/nim-packages uses it alot |
| 13:12:17 | ekarlso | that repo isn't up to date with latest stuff but |
| 13:12:31 | Araq | def-: idetools are mostly implemented in compiler/suggest.nim and compiler/service.nim |
| 13:14:32 | Araq | one major pita is that findClosestDot and findClosestCall and findClosestSym business |
| 13:16:04 | Araq | it's worth trying a different approach where you make the lexer insert a pseudo-token for the cursor position which then the parser uses to construct a dummy AST node |
| 13:16:27 | Araq | which then triggers the suggestions |
| 13:17:24 | * | Sphax quit (Quit: ZZZZZzzzzz) |
| 13:17:36 | def- | Araq: well, i don't even understand how to test idetools yet |
| 13:19:01 | Araq | well as I said tests/testament/caasdriver runs the tests, well used to run them |
| 13:19:12 | Araq | it's not been maintained |
| 13:19:32 | def- | oh, i tried tester and all kinds of tests failed |
| 13:22:29 | gokr | Was the idetools stuff meant to be able to run incrementally or did I dream that? |
| 13:23:22 | gokr | People are complaining about the response time, but ... that must be fixable. |
| 13:25:03 | Araq | gokr: it's a server so everything is kept in RAM and it recompiled only what's necessary |
| 13:25:17 | gokr | Ah, then it can't be slow. |
| 13:25:32 | Araq | it's not slow. it simply doesn't work at all ;-) |
| 13:25:45 | gokr | I thought I read somewhere that someone felt it was too slow |
| 13:26:19 | Araq | you can also run it from command line in non-serving mode and then I can see why it's too slow |
| 13:27:45 | Araq | def-: well main|main_dirty is a good starting point. figure out why it doesn't work. |
| 13:28:32 | * | zahary quit (Read error: Connection reset by peer) |
| 13:28:43 | ekarlso | JWT stuff is really kneat |
| 13:28:51 | ekarlso | doesn't require you to store any token info in a db |
| 13:29:04 | * | Sphax joined #nim |
| 13:30:28 | Araq | def-: but as I said, implement the curser token feature, I think this makes things *much* easier to debug |
| 13:33:14 | def- | Araq: there is no testcase for main/main_dirty, is there? |
| 13:33:34 | def- | oh wait, there is, my bad |
| 13:35:34 | * | BlaXpirit_ joined #nim |
| 13:36:29 | * | BlaXpirit quit (Ping timeout: 245 seconds) |
| 13:39:20 | * | jefus__ is now known as jefus |
| 13:40:50 | * | jpoirier quit (Quit: Leaving) |
| 13:43:25 | * | Demon_Fox joined #nim |
| 13:50:56 | ekarlso | a sanity question, to get version info about a package would it be ok to do GET /package/foo/releases then vs including it in /package/foo? |
| 13:56:01 | * | JinShil quit (Quit: Konversation terminated!) |
| 13:56:52 | ekarlso | no preferences ? ;) |
| 14:00:08 | * | EXetoC joined #nim |
| 14:08:57 | * | Varriount|Laptop joined #nim |
| 14:16:55 | yonson | How can I join all elements of a seq into a string? |
| 14:18:20 | Araq | strutils.join |
| 14:19:07 | yonson | does it work on seqs though? |
| 14:19:11 | BlaXpirit_ | yes |
| 14:19:49 | yonson | i´ll look into it, thanks |
| 14:22:45 | * | flaviu quit (Ping timeout: 276 seconds) |
| 14:25:12 | * | flaviu joined #nim |
| 14:32:32 | yonson | Ok, can you tell me whats wrong with https://gist.github.com/yonson2/e528476843aa1e0cbc54 ? |
| 14:43:48 | * | BitPuffin joined #nim |
| 14:45:19 | Araq | yonson: join takes a seq of strings, you give it an array of ints |
| 14:45:28 | Araq | *a seq of ints |
| 14:46:27 | yonson | hmm |
| 14:47:14 | yonson | to turn an array into a seq i only need to precede it with a @ right? |
| 14:49:24 | yonson | oh |
| 14:50:39 | yonson | ok, seq of strings |
| 14:50:50 | yonson | yeah, everything works now, thanks |
| 15:03:45 | EXetoC | did you expect int-string coercion? |
| 15:04:36 | * | johnsoft joined #nim |
| 15:09:13 | * | nande joined #nim |
| 15:16:13 | * | Varriount|Laptop quit (Ping timeout: 246 seconds) |
| 15:19:43 | * | saml joined #nim |
| 16:03:19 | BlaXpirit_ | type T = ref object of RootObj; type U = object of T - what is this? |
| 16:08:07 | * | JinShil joined #nim |
| 16:11:36 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 16:14:09 | yonson | EXetoC, nah, I just messed up and didn´t see where |
| 16:14:12 | yonson | rookie mistake i guess |
| 16:17:00 | * | SplinterOfChaos joined #nim |
| 16:20:18 | * | UberLambda joined #nim |
| 16:25:25 | BlaXpirit_ | hmm... |
| 16:25:55 | BlaXpirit_ | it's starting to seem like with a complex object hierarchy having a separate file for all type definitions is inevitable |
| 16:46:46 | BlaXpirit_ | basically... is it possible to inherit from a C struct? |
| 16:54:52 | BlaXpirit_ | oh boy... scratch that. looks like having absolutely everything in one file OR public is inevitable |
| 17:01:53 | * | infrashortfoo quit (Remote host closed the connection) |
| 17:02:12 | * | infrashortfoo joined #nim |
| 17:02:12 | * | infrashortfoo quit (Client Quit) |
| 17:07:52 | EXetoC | BlaXpirit_: the issue being the absence of symbol browsers and so on? |
| 17:07:58 | BlaXpirit_ | no |
| 17:07:59 | EXetoC | don't forget about 'include' |
| 17:08:07 | BlaXpirit_ | impossible to have circular reference |
| 17:08:28 | BlaXpirit_ | i have object that owns a different object, and that different object must have a pointer to parent |
| 17:08:40 | BlaXpirit_ | and i cant achieve it unless they are defined in one block |
| 17:09:23 | * | brson joined #nim |
| 17:10:18 | ldlework | BlaXpirit_: indeed :) |
| 17:10:46 | BlaXpirit_ | well there's the fatal flaw of nim |
| 17:10:46 | ldlework | we really need forward type declarations |
| 17:10:56 | EXetoC | that is a case of strong coupling though |
| 17:11:00 | ldlework | BlaXpirit_: lol as dramatic as ever |
| 17:11:17 | ldlework | EXetoC: coupling isn't an inherently bad thing though |
| 17:11:26 | BlaXpirit_ | well i need to find a reason why nim is not popular, if nobody is telling me |
| 17:12:07 | ldlework | BlaXpirit_: what I do is create a types.nim and include all the typedefs there and just put methods in their own file |
| 17:12:16 | ldlework | then I use a magic compiler include to include types.nim |
| 17:12:22 | ldlework | this obviously doesn't work for libraries |
| 17:12:30 | BlaXpirit_ | [:54:11] <BlaXpirit_> oh boy... scratch that. looks like having absolutely everything in one file OR public is inevitable |
| 17:12:44 | BlaXpirit_ | ldlework, if u put methods in a different file, then everything must be public |
| 17:12:53 | ldlework | BlaXpirit_: right |
| 17:12:54 | EXetoC | ldlework: no, but doesn't it make sense to then have those types in the same module? |
| 17:13:00 | BlaXpirit_ | which is not that bad, |
| 17:13:17 | BlaXpirit_ | but at that point one gets sick of the stars |
| 17:13:18 | ldlework | EXetoC: modules mean nothing in Nim in terms of abstraction |
| 17:13:28 | ldlework | Furthermore they are even worse filesystem-like modules |
| 17:13:56 | ldlework | the only reason to split things up in Nim is for source organization and file shortening which is always a valid desire |
| 17:14:09 | * | sampwing joined #nim |
| 17:14:34 | BlaXpirit_ | sigh https://bpaste.net/show/07a6a0c05d67 |
| 17:14:45 | BlaXpirit_ | couldn't even do object of Sprite |
| 17:18:42 | EXetoC | ldlework: it does affect visibility. is that not an abstraction? |
| 17:19:20 | ldlework | EXetoC: Not really. Its not like the two types change how they are coupled when you put them in different files. |
| 17:20:00 | ldlework | Split them up, their integration points are now public. Woop. |
| 17:20:38 | ldlework | Furthermore, if the two types should be coupled over a limited interface, putting them in the same file breaks that abstraction too |
| 17:22:32 | EXetoC | it's not just about coupling, is it? |
| 17:23:47 | * | jefus left #nim ("Leaving") |
| 17:26:22 | * | jpoirier joined #nim |
| 17:28:23 | Araq | let's see ... starts with a "Game" object and yup ... goes downhill from there ;-) why does TileObj require a back pointer to Game? |
| 17:29:35 | BlaXpirit_ | cuz it can do things |
| 17:30:58 | BlaXpirit_ | may need access to neighboring tiles, to the player, to whatever else it may activate |
| 17:31:05 | BlaXpirit_ | change global things |
| 17:31:51 | Araq | global variables are nice for global things. |
| 17:32:11 | BlaXpirit_ | mmmmn no |
| 17:32:24 | Araq | mmmmmm yes |
| 17:33:09 | BlaXpirit_ | i'm not gonna pretend that "there can be multiple games going" |
| 17:33:12 | BlaXpirit_ | but it's just this case |
| 17:33:19 | BlaXpirit_ | in general, your argument is invalid |
| 17:33:36 | EXetoC | it does not need to know about the game, but whatever floats your boat |
| 17:34:32 | ldlework | BlaXpirit_: its fine, its one of the remaining go-isms |
| 17:34:40 | BlaXpirit_ | ? |
| 17:34:55 | ldlework | "The language is broken in X way, so write your programs in Y style, infact, you should be writing in Y style even if the language wasn't broken this way" |
| 17:35:18 | BlaXpirit_ | what does not need to know about the game... do you even know what it is? |
| 17:35:23 | ldlework | vs like "Oh sure you can write your program like that the language supports that." |
| 17:35:31 | BlaXpirit_ | i've implemented this hierarchy in Python and in C++ |
| 17:35:54 | BlaXpirit_ | in C++ with more hardcore OOP instead of object variant |
| 17:35:57 | ldlework | BlaXpirit_: and you can implement it in Nim, if you use one of the work arounds |
| 17:36:07 | * | vegai left #nim (#nim) |
| 17:36:25 | BlaXpirit_ | i dunno, maybe i'm just stupid and dont know fundamentals of programming |
| 17:36:35 | BlaXpirit_ | but i dont see a better way |
| 17:36:57 | * | MajorWork quit (Quit: Leaving) |
| 17:37:21 | BlaXpirit_ | game must know about player, player must know about game... game owns a level, level owns a tile, tile owns an object, but the object needs to do things outside itself, so it needs references to other things |
| 17:37:46 | EXetoC | the game must know about the game objects, yes, but the game objects don't need to know about the game |
| 17:38:05 | BlaXpirit_ | ok |
| 17:38:09 | ldlework | BlaXpirit_: basically they are saying you write a third component that actually has the dependencies on Game and FooObj |
| 17:38:14 | EXetoC | they could, but that's not the way I do things, that's all |
| 17:38:31 | ldlework | BlaXpirit_: but its annoying to write an entire system this way |
| 17:38:39 | BlaXpirit_ | ok, so let's say you can turn lights off and on in your game |
| 17:38:39 | EXetoC | just saying. anyway, time to avoid this evil procrastination tool for a while :p |
| 17:38:40 | ldlework | Where each data dependency involves a third component |
| 17:38:51 | BlaXpirit_ | and you have a light switch |
| 17:39:08 | BlaXpirit_ | how can the light switch turn lights off if it doesn't know anything |
| 17:39:14 | * | JinShil quit (Quit: Konversation terminated!) |
| 17:39:33 | ldlework | BlaXpirit_: "You're doing it wrong, and you could easily do it right, just saying how I would do it, but before I reveal the answer to you, let me call you a distraction and run off." |
| 17:40:34 | ldlework | BlaXpirit_: you have a third thing called LightToggleSystem |
| 17:40:41 | ldlework | it has dependencies on Lights and Switch |
| 17:41:02 | ldlework | BlaXpirit_: do this for every single integration point between any two types and you will have no circular dependencies |
| 17:41:10 | BlaXpirit_ | srsly |
| 17:41:16 | ldlework | but your code wont be readable or semantic at all and in 6 weeks you'll hate your own game |
| 17:42:01 | BlaXpirit_ | 3rd rewrite is enough to hate it anyway |
| 17:42:09 | ldlework | but hey, its easier to just tell you than to simply observe that the feature that the language intends to fix for supporting this, is simply broken/unavailable right now |
| 17:42:21 | ldlework | tell you that you're stupid, that is |
| 17:42:22 | BlaXpirit_ | i like your attitude |
| 17:42:23 | EXetoC | or the switch simply has access to the connected light(s), but that is a much more narrow dependency compared to having access to the whole game |
| 17:42:30 | EXetoC | oh right, procrastination and all that |
| 17:42:43 | BlaXpirit_ | pfft let me tell you a different use case |
| 17:42:50 | ldlework | EXetoC: yay now everything that ever interacts with the light needs to be in lights.nim |
| 17:42:59 | BlaXpirit_ | a thing that destroys every block around it |
| 17:43:07 | BlaXpirit_ | and the thing can move around |
| 17:43:08 | * | Sphax quit (Quit: ZZZZZzzzzz) |
| 17:43:22 | BlaXpirit_ | so basically it needs to keep 8 references at all times |
| 17:43:31 | BlaXpirit_ | and any time you move it, the game itself needs to update 8 reference |
| 17:43:38 | BlaXpirit_ | just so you dont need to have a reference to game |
| 17:43:43 | BlaXpirit_ | is that gud? |
| 17:43:50 | ldlework | BlaXpirit_: yeah, the answer is the same |
| 17:43:55 | ldlework | but in this case, the answer seems less bad |
| 17:44:01 | ldlework | beause your dependencies are so general |
| 17:44:17 | BlaXpirit_ | i dont understand |
| 17:44:27 | ldlework | but having a LightToggleSystem just for things that can turn on and off lights is annoying |
| 17:44:31 | ldlework | BlaXpirit_: you'd have some third component |
| 17:44:37 | * | We7W3ntyf0uR quit (Read error: Connection reset by peer) |
| 17:44:42 | ldlework | that knows about that thing, and the game, or the map structure or whatever |
| 17:44:51 | ldlework | there is then no circular dependencies |
| 17:44:56 | BlaXpirit_ | it's stupid as heck |
| 17:45:00 | ldlework | the third component's dependencies can be as general as you'd like |
| 17:45:14 | ldlework | BlaXpirit_: just wait for forward type declarations |
| 17:45:27 | BlaXpirit_ | you know how many different kinds of relations between things there can be? |
| 17:45:32 | BlaXpirit_ | i'd need like 100 more types |
| 17:45:48 | ldlework | BlaXpirit_: yes, this is why I said its ridiculous to program this way, as a fundamentalist thing |
| 17:45:50 | EXetoC | ldlework: it does? I didn't think much about it, it was just one more example |
| 17:46:17 | ldlework | EXetoC: the problem is that you're just spouting weightless and thoughtless generalizations about how you can whimsically avoid BlaXpirit_'s problems with magical design |
| 17:46:34 | BlaXpirit_ | Araq too |
| 17:46:35 | EXetoC | also, look into entity component systems. they are neat |
| 17:46:37 | ldlework | EXetoC: non-recursive designs are bloated and unsemantic. They're harder to read and follow |
| 17:46:57 | ldlework | EXetoC: uh, I've only been reiterating that over and over since this conversation started |
| 17:47:46 | ldlework | this is the problem with not paying attention to the conversation but high-browing it at the same time :/ |
| 17:47:51 | EXetoC | nothing wrong with examples.. |
| 17:48:20 | EXetoC | bad or not. it's just yet another way to do things, rather than the supposed "one true way" |
| 17:48:30 | ldlework | EXetoC: entity component systems have their own tradeoffs |
| 17:48:41 | ldlework | They are not "some magical other way" |
| 17:49:06 | EXetoC | forget it |
| 17:49:14 | ldlework | Wow you couldn't even agree to that. |
| 17:49:49 | ldlework | You're usually more level headed than this, dunno why you're trying to seem so uninvested. |
| 17:51:35 | BlaXpirit_ | ldlework, so should i continue with 1 file? |
| 17:51:56 | BlaXpirit_ | u don't seem to think that this hierarchy is hopeless |
| 17:54:01 | ldlework | It wont be when forward type declarations show up |
| 17:54:09 | ldlework | And it wont be hard to refactor a monolith types.nim when that happens |
| 17:54:19 | BlaXpirit_ | ok |
| 17:54:30 | BlaXpirit_ | thanks |
| 17:56:30 | * | EXetoC quit (Quit: WeeChat 1.0.1) |
| 18:09:08 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) |
| 18:12:33 | * | Sphax joined #nim |
| 18:17:28 | * | davidhq joined #nim |
| 18:17:44 | * | jpoirier_ joined #nim |
| 18:18:56 | * | jpoirier_ quit (Client Quit) |
| 18:21:37 | * | Sphax quit (Quit: ZZZZZzzzzz) |
| 18:22:23 | * | Sphax joined #nim |
| 18:24:18 | Zuchto | BlaXpirit_: I might be out of line here but as for game objects: the game isn't (and shouldn't be a part of the object (as has already been stated)) but rather as you iterate over the objects to calculate their next state it's that processing that is dependent on the game. Does that make sense? |
| 18:25:05 | BlaXpirit_ | no |
| 18:26:38 | Zuchto | BlaXpirit_: ok, do you want me to try and explain it some other way or do you not care about my opinion? :P |
| 18:27:05 | BlaXpirit_ | i don't understand |
| 18:27:09 | BlaXpirit_ | or maybe you don't understand |
| 18:27:29 | BlaXpirit_ | seen my example about a light switch? |
| 18:28:27 | ldlework | BlaXpirit_: he's exactly saying what I have |
| 18:28:52 | ldlework | the code that uses the Foo and the Game doesn't live in a Foo method, therefore Foo doesn't need a reference to Game |
| 18:29:15 | * | Sphax quit (Quit: ZZZZZzzzzz) |
| 18:29:29 | BlaXpirit_ | LightToggleSystem? |
| 18:29:54 | BlaXpirit_ | i can understand such a concept, but i don't find it useful |
| 18:31:23 | * | threewood quit (Ping timeout: 240 seconds) |
| 18:32:47 | Zuchto | If you give the game object access to the game world without limiting where the game is accessed you are essentially loosing all track of state in the game. This makes any future optimizations really difficult and you will start seeing strange behaviours as hidden states are starting to show. Also, no, I haven't seen the example. I'm just talking about this in the abstract. But it's a fully realizable |
| 18:32:50 | Zuchto | abstraction |
| 18:33:48 | * | Sphax joined #nim |
| 18:34:14 | BlaXpirit_ | well there really is not much of an example |
| 18:34:46 | BlaXpirit_ | [:37:58] and then [:42:02] |
| 18:34:53 | Zuchto | also, yes, I think I'm very much on the same page as ldlework on this |
| 18:35:21 | BlaXpirit_ | ldlework didnt pose it as the better solution though |
| 18:35:31 | ldlework | Indeed. It has its own tradeoffs |
| 18:36:08 | ldlework | For parts of your programs where the integrations between types are very wide, it probably is worth it |
| 18:36:13 | Zuchto | BlaXpirit_: so you want to know how i propose that you handle the lightswitch that turns of the light? (given that the switch and the light are two separate objects)? |
| 18:36:22 | ldlework | For tiny types that are recursive, its absurd to use ECS design for that |
| 18:36:43 | BlaXpirit_ | not really, Zuchto. i wont even have a light switch |
| 18:36:47 | ldlework | A simple recursive relationship is far far far far simplier and easier to reason about |
| 18:36:50 | BlaXpirit_ | example from [:42:02], however... |
| 18:37:38 | * | sampwing quit (Remote host closed the connection) |
| 18:37:56 | * | sampwing joined #nim |
| 18:38:01 | BlaXpirit_ | a block that you can move and it can destroy things around itself |
| 18:38:16 | BlaXpirit_ | lets say in a strictly tile-based environment |
| 18:40:36 | Zuchto | BlaXpirit_: yeah, you need to give the game object a game to act on when calculating it's next state, this "acting" could very well be calling an interface for destroying some other component of the game |
| 18:41:04 | ldlework | Zuchto: how do you discover and refer to that other component? |
| 18:41:15 | Triplefox | The solution i end up at is to inline the behavior of a game object at the top level and let it remain plain old data |
| 18:42:19 | Zuchto | ldlework: by some kind of location carried by the game object I would persume |
| 18:42:53 | Zuchto | for the game object to interact with the game there needs to be an interface where the game object can query information about the game |
| 18:43:04 | * | jpoirier quit (Ping timeout: 246 seconds) |
| 18:43:40 | BlaXpirit_ | Zuchto, do you realize that this triples the amount of work? |
| 18:43:59 | BlaXpirit_ | and that's a very optimistic expectation |
| 18:45:15 | BlaXpirit_ | it's like pouring water from one bucket to another, but through a funnel |
| 18:45:16 | ldlework | BlaXpirit_: this is why I said it is good for wide integrations but not tiny integrations |
| 18:45:31 | ldlework | I highly recommend this pattern for the larger integrations in your codebase |
| 18:45:38 | ldlework | And recursive relations for everything else |
| 18:45:48 | BlaXpirit_ | now this I definitely don't understand |
| 18:45:54 | BlaXpirit_ | what's a "larger" integration |
| 18:46:23 | ldlework | BlaXpirit_: more recursive dependencies |
| 18:46:45 | ldlework | Like if you have more than a single recursive relationship, it might be worht it to refactor the dependency out into a FooSystem |
| 18:47:54 | Zuchto | BlaXpirit_: what makes you think it triples the work? |
| 18:48:13 | BlaXpirit_ | Zuchto, "interface where the game object can query information about the game" |
| 18:48:21 | * | jhc76 joined #nim |
| 18:48:33 | BlaXpirit_ | do you realize how many different kinds of interactions there may be, needing more and more different queries |
| 18:48:44 | BlaXpirit_ | and you gotta make these pointless interfaces for everything |
| 18:49:25 | Triplefox | all the new symbols you have to introduce to name everything |
| 18:51:09 | Zuchto | BlaXpirit_: You seem to be making the assumption that I haven't built these kinds of systems... I know how to fail, and I know quite a few ways you can introduce pretty significant weaknesses into your system. If you are just making a small game with a few objects that interact a little bit, then pragmatic is better then anything. If you intend for the system to grow at all you need clean interfaces.... they are |
| 18:51:12 | Zuchto | not pointless. |
| 18:51:41 | * | kniteli quit (Quit: Leaving) |
| 18:52:14 | Triplefox | The scaling argument is not a good one because it's built on the expectation that every codebase will become some enterprise edifice anyway |
| 18:52:35 | BlaXpirit_ | ok, Zuchto. then what object will respond to the queries? |
| 18:53:08 | Zuchto | Triplefox: no, not really. But it is all about balance, if you do too much towards the enterprise goal you will never get anywhere. |
| 18:53:22 | Zuchto | BlaXpirit_: that is up to your game logic |
| 18:53:30 | BlaXpirit_ | an explosive queries (what exactly) to find blocks around it |
| 18:53:31 | ldlework | BlaXpirit_: see how you're not getting any specific advice? |
| 18:53:37 | BlaXpirit_ | ldlework, :p |
| 18:53:43 | ldlework | BlaXpirit_: just write your game, you have a path forward |
| 18:53:54 | ldlework | and let me play it when its coming along :P |
| 18:55:10 | Zuchto | BlaXpirit_: an explosive would probably query the game for tiles and objects around a certain coordinate an set them as "blow up" or something :P |
| 18:55:21 | BlaXpirit_ | ok |
| 18:55:32 | BlaXpirit_ | so after all, the object needs to keep a pointer to the game |
| 18:55:50 | ldlework | You can make a third object that keeps track of the tiles |
| 18:55:51 | Zuchto | no, it's being lent a pointer to the game as it calculates the next step |
| 18:55:57 | ldlework | Game has a reference to Map and Foo |
| 18:56:01 | BlaXpirit_ | oh, that's interesting |
| 18:56:08 | * | threewood joined #nim |
| 18:56:27 | Zuchto | if the tiles are game objects (can be interacted with) then they belong to the world, the world does not belong to them |
| 18:56:47 | ldlework | Zuchto: "dependency injection" |
| 18:57:12 | BlaXpirit_ | Zuchto, "belong" is represented by direct ownership, pointer is not necessarily it |
| 18:57:26 | ldlework | BlaXpirit_: right, the world owns the object, but not vice versa |
| 18:57:35 | j3rky | i'm thinking about writing bindings for a C++ library. is the following still relevant, or is there better support now? http://forum.nim-lang.org/t/166#803 |
| 18:57:38 | Zuchto | BlaXpirit_: no, but if they own a pointer then they can interact with it whenver |
| 18:57:41 | ldlework | BlaXpirit_: in this sense, the Foo method that takes a Game pointer is really FooGameSystem |
| 18:57:50 | ldlework | Since it is just a method that takes a Foo and a Game |
| 18:57:59 | Zuchto | ldlework: I really don't like dependency injection... it seems ugly |
| 18:58:04 | ldlework | Zuchto: uh you just recommended it |
| 18:58:09 | Araq | j3rky: nope, c2nim now rocks for C++ code |
| 18:58:18 | j3rky | ok awesome :) |
| 18:58:19 | ldlework | Passing a borrow into a function is the most basic form of dependency injection |
| 18:58:50 | Zuchto | ah ok, I've just heard the term thrown around and don't like the sound of it :P |
| 18:59:00 | Zuchto | but if that is what it is... then I'm ok with that |
| 18:59:11 | Araq | ldlework: we must not support every programming style under the sun just because Go chose to support very few different styles. |
| 18:59:30 | BlaXpirit_ | Araq pls |
| 18:59:41 | ldlework | Araq: sure but me pointing out that we're using the same bad justification for something objectively bad about our language is not the same as advocating that we support every single style. |
| 18:59:46 | ldlework | Araq: please note the non-sequitur |
| 19:00:05 | Araq | it's not objectively bad at all. |
| 19:00:11 | ldlework | Yes, yes it really is. |
| 19:00:24 | ldlework | Not supporting recursive types across modules, even though you support them fundamentally? |
| 19:00:39 | ldlework | That sounds like a problem with the module system. A bad interaction among disparate features. |
| 19:00:42 | BlaXpirit_ | heck, even C can do it, not just Python, C++ and most of other languages |
| 19:00:57 | BlaXpirit_ | (at least i think C can do it) |
| 19:00:59 | ldlework | BlaXpirit_: Python can totally do it |
| 19:01:10 | Araq | so what? ML and F# cannot. |
| 19:01:23 | BlaXpirit_ | ldlework, uhh of course it can, i've even done it before |
| 19:01:23 | ldlework | Araq: Dude |
| 19:01:31 | ldlework | You already plan on supporting forward type declarations |
| 19:01:44 | ldlework | Why are you making confidence shattering excuses for something you intend to fix anyway |
| 19:01:51 | ldlework | ARe you simply in an argumentitive mood? |
| 19:02:04 | Araq | bye. |
| 19:02:31 | ldlework | BlaXpirit_: I said that it can't |
| 19:02:34 | ldlework | err |
| 19:02:37 | ldlework | can |
| 19:02:38 | ldlework | not can't |
| 19:02:42 | BlaXpirit_ | and i said that it can |
| 19:02:43 | ldlework | and I notice that you also said that it can |
| 19:02:45 | ldlework | :) |
| 19:02:46 | BlaXpirit_ | so what's the deal lol |
| 19:02:48 | ldlework | haha |
| 19:03:40 | BlaXpirit_ | python just has an easy copout, it doesnt need to know the type |
| 19:03:51 | ldlework | Furthermore, I've yet to hear anyone who uses ML extensively herald it as the most amazingly designed language. I always hear how nice of a tool it is, but not how great of a language it is. |
| 19:04:02 | Araq | ldlework: I intend to "fix" it because I'm tired of arguing ... not because it's a particularly good idea |
| 19:04:26 | ldlework | Araq: yeah supporting feature X, but not if you use the module system. Totally a strong and rock solid position. |
| 19:04:40 | ldlework | You barely have to be snide and sarcastic to win me over, your position is just so self-evidentally good. |
| 19:04:50 | BlaXpirit_ | having all types in one file, with every field public, is gud |
| 19:05:13 | ldlework | Araq: I love your solid character and sensibilities but sometimes you seem absolute arbitrary. |
| 19:05:46 | ldlework | I wonder |
| 19:06:04 | ldlework | Would we ever put the "feature" of not being able to use recursive types, only across modules, as the first feature on the website? |
| 19:06:33 | ldlework | I mean, hey that decision was founded in sound general principle not finicky whimsy of someone trying to look down on others because of program structure and design? |
| 19:06:52 | ldlework | Why shouldn't we advertise it. |
| 19:07:00 | Zuchto | this seems really infected :O or is it just ldlework |
| 19:07:03 | Zuchto | ? |
| 19:07:21 | BlaXpirit_ | i bring up the worst in people |
| 19:07:31 | ldlework | No, arbitrary design brings out the worst in me. |
| 19:07:48 | BlaXpirit_ | well hey, that's what i talk about all the time |
| 19:07:51 | ldlework | Especially when it has long term consequences for something I'm passionate about. |
| 19:07:58 | Araq | it's not arbitrary at all, otherwise it would only be Nim with that problem |
| 19:08:06 | BlaXpirit_ | well isn't it? |
| 19:08:10 | Araq | but it exists in plenty of programming languages |
| 19:08:20 | ldlework | Araq: there's a solution, but you want to avoid the solution because other languages have this inherent problem for which they don't have solutions for. |
| 19:08:23 | ldlework | That's fucking arbitrary. |
| 19:08:33 | ldlework | Your justification is piss. |
| 19:08:43 | Zuchto | ldlework: how about making a pull request? and if it's not accepted, just fork nim? |
| 19:08:50 | Zuchto | no? |
| 19:09:06 | ldlework | Not, "Avoiding recursive types, specifically across modules, is benefitical for program architecture because objective reasons X, Y, Z that are mutually exclusive to the benefits to using recursive types in the same module." |
| 19:09:08 | ldlework | Please. |
| 19:09:19 | Araq | how can it be arbitrary when it comes up in every language with a module system? but whatever man |
| 19:09:22 | ldlework | If you have something along those lines, I'm sure BlaXpirit_ and I will be responsive to it. |
| 19:09:22 | BlaXpirit_ | Zuchto, you know very well that hacking on the compiler is a very difficult task. why bring this up? |
| 19:09:52 | BlaXpirit_ | Araq, that was just a false sentence |
| 19:10:07 | Zuchto | BlaXpirit_: because ldlework is being an ass to the person that, as far as I know, is doing just that |
| 19:10:08 | BlaXpirit_ | doesn't come up in Python, for one |
| 19:11:12 | ldlework | Zuchto: It isn't about the complexity of the implementation though. |
| 19:11:31 | ldlework | Its about the justification of the design. |
| 19:11:54 | Araq | simplicity of implementation is a design justification, whether you like it or not |
| 19:12:01 | ldlework | But isn't the one being used here. |
| 19:12:17 | ldlework | You're making a consequential argument, not an implementation complexity argument. |
| 19:12:41 | ldlework | Why can't we just stick to objective reasoning about feature X instead of waving our hands, making completely unrelated remarks and orthogonal arguments. |
| 19:13:06 | Zuchto | well, nim is a fairly opinionated language. And I would guess that those opinions are largely based on Araqs... If you have other opinions you either need to convince Araq with specific implementations or other convincing methods... or you fork it. |
| 19:13:06 | ldlework | What is the -objective consequence for software arhicture of programs written in Nim- by allowing them to use recursive types across modules, vs only in the same module? |
| 19:13:18 | ldlework | Zuchto: what IS the opinion though |
| 19:13:27 | ldlework | Zuchto: it seems like you're making a compltely emotional argument |
| 19:13:33 | ldlework | you have no reasoning about the actual topic at hand |
| 19:13:43 | ldlework | you're making 'be nice' 'implement it yourself' 'nim is opinionated' arguments |
| 19:13:53 | ldlework | that have zero bearing on what we're actually discussing |
| 19:13:55 | Araq | ldlework: how can you understand 3 modules when they are all so related that they mutually depend on another? |
| 19:14:11 | Araq | you cannot, it might as well be a single module |
| 19:14:17 | ldlework | Araq: can you show objective evidence that this makes modules harder to reason about? |
| 19:14:27 | ldlework | Or does it make them easier to reason about because each part is smaller and isolate? |
| 19:14:41 | Araq | no, but I have plenty of experience with the average C# design |
| 19:14:45 | ldlework | Araq: Or is this a case of "Just purport my own opinion on styling as objective fact." |
| 19:14:50 | ldlework | Araq: and I have plenty with python |
| 19:14:51 | Araq | and there have been studies about it too |
| 19:14:53 | Zuchto | ldlework: well no, because "objectively true way of doing something" is a stupid illusion that really has no bearing except for those that have bought into the illusion |
| 19:14:55 | ldlework | and structing my programs like this |
| 19:15:10 | ldlework | Zuchto: so there's absoltuely no substantial way to argue design |
| 19:15:16 | ldlework | great, you've reasoned yourself out of this conversation |
| 19:15:19 | ldlework | and nothing of value was lost |
| 19:15:40 | Araq | ldlework: let's see if I can find the link |
| 19:16:00 | ldlework | Araq: Nice one study vs 15 years of designing my programs this way, to an efficiency that keeps me hired and shipping |
| 19:16:11 | Zuchto | ldlework: sure it is, "in my experience, this is much better for these cases, I find these cases much more valuable than the other cases, so I'm doing it this way"... it's pretty straight forward actually |
| 19:16:12 | ldlework | Oh and tons of other programmers who design their programs this way |
| 19:16:27 | Araq | so what? |
| 19:17:12 | Araq | by that logic Java is an excellent design |
| 19:17:56 | BlaXpirit_ | it is, in many aspects |
| 19:18:06 | Triplefox | Programming languages let you get away with murder sometimes, but it doesn't make them right |
| 19:18:17 | Araq | if you want Java, you know where to find it. |
| 19:19:19 | BlaXpirit_ | so that's your argument |
| 19:20:39 | Araq | what's your argument again? the language makes your ugly design come up as ugly? well yes. |
| 19:20:56 | BlaXpirit_ | Araq, you still haven't explained how to make it not ugly |
| 19:21:24 | BlaXpirit_ | you're not in on the topic |
| 19:21:25 | Araq | I did but it doesn't matter since you won't listen anyway |
| 19:21:39 | BlaXpirit_ | the one who is not listening is you |
| 19:22:18 | BlaXpirit_ | and i can understand that you don't have time to listen to some random guy |
| 19:22:32 | Zuchto | "the less you know the less you know you don't know"... |
| 19:22:32 | * | Varriount|Laptop joined #nim |
| 19:23:15 | BlaXpirit_ | sure, throw some random quote |
| 19:23:52 | Triplefox | Well, we've reached "no u" already |
| 19:25:01 | * | Zuchto isn't even part of this discussion according to ldlework so nothing they say can be seen as related to the discussion in question |
| 19:25:33 | Araq | btw the forum needs moderation |
| 19:27:18 | BlaXpirit_ | i don't know how github issues usually manage to avoid the same fate |
| 19:35:02 | Varriount|Laptop | Araq: Howso? I would be willing to moderate, if I had the tools available. |
| 19:35:41 | Araq | dom96: make him an admin please |
| 19:38:38 | * | Sphax quit (Quit: ZZZZZzzzzz) |
| 19:38:54 | * | Sphax joined #nim |
| 19:42:19 | * | Sphax quit (Client Quit) |
| 19:43:55 | ldlework | BlaXpirit_: notice how you're not recieving any specific advice |
| 19:44:01 | ldlework | BlaXpirit_: recursive types are inherently bad |
| 19:44:10 | ldlework | BlaXpirit_: I mean, as long as their in different modules...I think? |
| 19:44:50 | ldlework | BlaXpirit_: I don't know just shutup, your design is bad because you want to organize your code |
| 19:44:56 | BlaXpirit_ | have you gone too deep with the sarcasm |
| 19:45:12 | ldlework | As if, splitting two types across a module somehow fundamentally changes the architecture of your program! |
| 19:45:32 | Zuchto | I actually think this channel is in need of some moderation |
| 19:45:45 | ldlework | BlaXpirit_: for this argument, there is no depth of sarcasim which can remedy it |
| 19:45:49 | BlaXpirit_ | :p |
| 19:47:13 | * | UberLambda quit (Quit: Leaving the Matrix) |
| 19:47:36 | BlaXpirit_ | Zuchto, you mean censoring? |
| 19:47:50 | Zuchto | BlaXpirit_: nope, just removing spam |
| 19:47:57 | BlaXpirit_ | talking about problems with the language now forbidden? |
| 19:48:14 | Araq | as promised here the link: http://fsharpforfunandprofit.com/posts/cycles-and-modularity-in-the-wild/ |
| 19:48:34 | def- | there's a nim-offtopic channel if you're feeling spammy |
| 19:48:48 | Zuchto | IMHO being an ass about it should be "encouraged" to be done in other areas |
| 19:49:04 | BlaXpirit_ | Zuchto, notice how nobody is being an ass from the beginning |
| 19:49:29 | Zuchto | BlaXpirit_: could you clearify? I don't understand what you are getting at |
| 19:50:16 | BlaXpirit_ | i always start calm, provide some evidence, but after an hour of pointless arguments there isn't much to do except becoming an ass |
| 19:50:46 | Zuchto | BlaXpirit_: and you believe that being an ass about it is a valid option at that point? |
| 19:50:55 | ldlework | Araq: what exactly is the point of showing us this? |
| 19:51:37 | ldlework | F# is designed in way X so we see that projects in F# exhibit source organization features Y |
| 19:51:39 | ldlework | So? |
| 19:51:55 | ldlework | How is that at all related to types across modules being somehow a bad -software architecture- |
| 19:54:12 | Araq | and not that I really care but: cyclic graphs cannot be managed with reference counting, acyclic graphs can. that is an objective criterion. traversal for tree like structures is easy, for general graphs it's much harder etc etc etc |
| 19:54:14 | ldlework | "Nim supports generics and inheritance but if you want to do OOP programming, Fuck You, Nim is really a functional language because we arbitrarilly limit the language to mirror limitations in F# (which show up for compltely unrelated reasons than in Nim) |
| 19:54:32 | BlaXpirit_ | Araq, there are no reference cycles in my code |
| 19:54:40 | ldlework | Araq: so disable them within the module too, if that's your argument |
| 19:55:03 | ldlework | Use an argument that actually justifies the thing we're talking about _please_. |
| 19:55:13 | Araq | ldlework: no it's a *necessary* evil, not something you are proud of because of "software architecture" |
| 19:55:32 | ldlework | Why is it a necessary evil if not because of software architecture. |
| 19:56:14 | ldlework | How are any of the points you've actually responded with, actually related to the specific issue we're discussing, even tangentally? |
| 19:57:08 | BlaXpirit_ | still 0 valid arguments |
| 19:57:24 | Triplefox | I don't know, i actually read the article |
| 19:57:31 | ldlework | This article concludes, F# is better because it makes you go out of your way to create a cyclical dependency across modules. |
| 19:57:37 | Araq | trees are nice, general graphs are not. with Nim's restrictions you get a tree like module structure without them you get general graphs |
| 19:58:04 | ldlework | Araq: and what exactly is traversing those trees? |
| 19:58:08 | BlaXpirit_ | breaking news "graphs are not nice" |
| 19:58:13 | Araq | I don't care if that's relevant point for your personal agenda or not |
| 19:58:28 | ldlework | Araq: what in Nim, actually has to deal with graph traversal with regards to the module system |
| 19:58:39 | Triplefox | I like the modules as they are |
| 19:58:51 | ldlework | Triplefox: we're not trying to change the module system per-say |
| 19:59:06 | ldlework | And, great as long as they're sufficient for you, we should all shut up |
| 19:59:19 | BlaXpirit_ | damn you're good at arguments |
| 19:59:19 | ldlework | Let us remember to run by all our shortcomings with Nim through Triplefox first |
| 19:59:47 | ldlework | BlaXpirit_: because the actual answer here is "Oh right, just wait until forward type declarations." |
| 19:59:58 | Triplefox | Uh, so you want to bully? |
| 20:00:17 | ldlework | If Araq had just said that instead of taking some high-brow self-contradicting position for which he can provide no direct argumentation against, then we both would have been satisfied long ago. |
| 20:00:26 | ldlework | Because that's all that needed to be said about this problem. |
| 20:02:57 | ldlework | Triplefox: Uh, so you just want to sqaush other people's conversations that have no effect or bearing on you by making a wierd obersvation that you don't suffer the same difficulty as others? |
| 20:02:59 | ldlework | What? |
| 20:03:56 | Triplefox | Your conversation consists of forcing someone to say they're wrong |
| 20:04:06 | ldlework | Nope |
| 20:04:08 | ldlework | There is a problem X |
| 20:04:14 | ldlework | there is a sufficient solution Y |
| 20:04:23 | ldlework | But Y is purportedly bad because X shouldn't be a problem at all |
| 20:04:31 | ldlework | so instead of providing a solution to X |
| 20:04:32 | ldlework | we say |
| 20:04:34 | ldlework | You're wrong. |
| 20:04:37 | ldlework | You're thinking wrong. |
| 20:04:40 | ldlework | You're a bad programmer. |
| 20:04:42 | ldlework | Read this article. |
| 20:04:56 | ldlework | If there was a solution as nice as Y, that we were missing, everyone here would have provided it. |
| 20:05:03 | ldlework | Instead of the hand waving and high-browing. |
| 20:05:37 | Triplefox | Except that you're getting a change already |
| 20:05:45 | ldlework | Triplefox: right, that was my point, that's Y |
| 20:05:55 | ldlework | But we just had to pointout how people who need Y are terrible programmers |
| 20:06:06 | ldlework | Because there is some hidden unspoken thing you could do instead of X that would alleviate it |
| 20:06:16 | ldlework | Just it seems no one can actually produce what that altnerative is |
| 20:06:38 | ldlework | So the discrepency between "Shutup and just write your software correctly" and the blinding abscence of a simple solution being reported into the channel, speaks volumes. |
| 20:07:25 | BlaXpirit_ | this happens every time on this channel |
| 20:07:30 | ldlework | Maybe next time we can just skip the bullshit |
| 20:07:33 | ldlework | and talk about the engineering |
| 20:07:37 | Triplefox | Well, did you actually present the problem that requires your solution in a way that is comprehensible |
| 20:07:50 | ldlework | Triplefox: so you don't even know the context |
| 20:07:54 | ldlework | but you're going to load your question anyway |
| 20:07:56 | ldlework | Yay |
| 20:08:02 | ldlework | More fucking hand-wavy high-brow bullshit |
| 20:08:58 | ldlework | Triplefox: no, we just spontaneously started arguing and Araq himself has no idea why he has suggested to add forward type declarations to the language, afterall what we're talking about isn't well defined.. |
| 20:09:21 | ldlework | He just got lucky that he is going to add the solution to the language even though we never described what the problem was in a comprehensble way first |
| 20:09:23 | ldlework | ffs |
| 20:10:03 | Triplefox | So, you didn't. |
| 20:10:19 | ldlework | Triplefox: now who's trolling? |
| 20:10:42 | Triplefox | If you did you'd link me |
| 20:10:56 | ldlework | To the scroll back that's already available to you |
| 20:10:57 | * | Zuchto doesn't see anyone trolling but someone is working really hard to pull some aggro |
| 20:11:10 | ldlework | that you should have consumed before being a complete dickwad who's lost on the context |
| 20:11:45 | ldlework | but feels he's jsutified in loading his questions and taking a moral high-ground in a conversation he could be bothered to go read the part before he joined but wants a link, to a pastebin spoonfeeding the context that he's trampling on in the first place |
| 20:11:51 | ldlework | Triplefox: you're a good internet citizen |
| 20:11:53 | Triplefox | No. I am a dummy. Point me to what you said. |
| 20:11:55 | ldlework | really, examplary |
| 20:12:29 | ldlework | Triplefox: How about you do what any self-respecting person purporting to care about a conversation they've already trampled on (without context) and go contextualize yourself. |
| 20:12:35 | ldlework | By using the wheel on your mouse |
| 20:12:36 | ldlework | to scroll up |
| 20:12:39 | ldlework | its called |
| 20:12:39 | Zuchto | ldlework: are you really trying to take the high ground here? :D |
| 20:12:41 | ldlework | Due diligence |
| 20:13:06 | ldlework | Zuchto: yeah I have the benefit for actually being involved in the conversation, and bothing myself to own the context before injecting myself into said conversation |
| 20:13:09 | ldlework | so there's that |
| 20:13:20 | BlaXpirit_ | the only reason ldlework can't take high ground is that nobody is listening |
| 20:13:31 | BlaXpirit_ | only 2 people here have read every message of this conversation |
| 20:13:47 | BlaXpirit_ | and they both agree. |
| 20:13:55 | BlaXpirit_ | so there is nobody to argue against |
| 20:13:56 | ldlework | BlaXpirit_: sure, I'm just practicing for the next time we decide to not address the engineering and just effortless give one-liners that make us appear to be informed and wise |
| 20:14:07 | BlaXpirit_ | you're well practiced |
| 20:14:47 | Zuchto | ldlework: still being an ass, I would say that that makes any high ground you try and claim about being a "good internet citizen" pretty much null and void. |
| 20:15:05 | ldlework | Sure, but when I'm responding to someone being ass, hope is already lost |
| 20:15:21 | Zuchto | but yeah, I should really not be getting involved in this infected wound of a discussion. Detaching this channel now |
| 20:18:12 | ldlework | "I'm going to contribute to the problem and then walk off in an attempt to appear unaffected by things that I want you to think are below me but clearly arent because my failure to beunaffected in the first place." |
| 20:18:53 | ldlework | One day we will care less about appearing cool to members in our own community and fix problems with the product. |
| 20:18:54 | ldlework | One day. |
| 20:20:45 | * | BlaXpirit joined #nim |
| 20:26:05 | * | bjz_ joined #nim |
| 20:29:08 | * | bjz quit (Ping timeout: 245 seconds) |
| 20:38:55 | * | Varriount|Laptop quit (Ping timeout: 246 seconds) |
| 20:41:22 | * | Varriount|Laptop joined #nim |
| 20:53:56 | * | bjz_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:54:40 | * | Varriount|Laptop quit (Ping timeout: 246 seconds) |
| 20:58:19 | * | yonson quit (Ping timeout: 255 seconds) |
| 21:12:23 | * | Varriount|Laptop joined #nim |
| 21:15:13 | * | matkuki joined #nim |
| 21:16:55 | * | bjz joined #nim |
| 21:18:13 | matkuki | Is there a function for getting max item from a sequence of ints/floats? |
| 21:18:54 | matkuki | @[1,2,3,4,7,99,5] > 99 |
| 21:19:03 | ldlework | I don't think so, Tim. |
| 21:19:17 | matkuki | ok |
| 21:22:33 | BlaXpirit | :s |
| 21:22:41 | BlaXpirit | indeed looks so |
| 21:27:14 | def- | matkuki: max |
| 21:27:29 | def- | .eval echo max(@[1,2,3,4,7,99,5]) |
| 21:27:33 | Mimbus | def-: 99 |
| 21:27:44 | matkuki | Like in Python? Great, let me try! |
| 21:28:20 | matkuki | def-: What module is "max" in? |
| 21:28:39 | def- | matkuki: system.nim, it's imported by default |
| 21:28:52 | matkuki | Great, thanks. |
| 21:30:27 | * | bjz quit (Ping timeout: 276 seconds) |
| 21:36:25 | * | BlaXpirit quit (Ping timeout: 265 seconds) |
| 21:40:29 | * | zahary joined #nim |
| 21:46:09 | * | enquora joined #nim |
| 22:00:02 | * | enquora quit (Remote host closed the connection) |
| 22:00:41 | * | sampwing quit (Ping timeout: 252 seconds) |
| 22:07:12 | * | Matthias247 joined #nim |
| 22:17:41 | * | jpoirier joined #nim |
| 22:20:10 | * | sampwing joined #nim |
| 22:20:34 | * | EXetoC joined #nim |
| 22:21:07 | * | Varriount|Laptop quit (Ping timeout: 246 seconds) |
| 22:21:50 | flaviu | http://forum.nim-lang.org/t/773 |
| 22:22:10 | EXetoC | two threads with the last reply being in 2012 have appeared on the first page |
| 22:22:30 | def- | EXetoC: there was a reply, but it was deleted by an admin |
| 22:22:51 | EXetoC | ok |
| 22:23:49 | EXetoC | just some information missing then |
| 22:28:14 | BlaXpirit_ | i don't understand how max of a seq works |
| 22:28:22 | BlaXpirit_ | there is no such signature |
| 22:28:26 | BlaXpirit_ | is it varargs? |
| 22:29:13 | BlaXpirit_ | ok, varargs magically works on seqs too |
| 22:30:13 | Araq | varargs is just openarray with more special undocumented typing rules |
| 22:32:38 | BlaXpirit_ | then why doesn't echo work that way? |
| 22:32:56 | BlaXpirit_ | probably because of varargs[expr |
| 22:36:42 | Araq | yup |
| 22:38:12 | * | JinShil joined #nim |
| 22:39:57 | * | zahary quit (Read error: Connection reset by peer) |
| 22:40:29 | * | zahary joined #nim |
| 22:52:44 | gmoore | Araq: is there any write equivalent to staticRead / slurp? we currently have a bunch of Python pre-build code for generating supporting files when our project is building. it would be cool to be able to have macro calls in nim which generate the support files instead of having to have a pre-build step. |
| 22:53:18 | Araq | static: writeFile() is supposed to work |
| 22:54:08 | gmoore | oh, ok. i haven't tried it yet, i was going from the system docs. readFile says use staticRead, writeFile mentions nothing so i just assumed it wasn't doable |
| 22:54:31 | gmoore | for my understanding why is it that readFile won't work at compile time but writeFile will? |
| 22:57:07 | Araq | there is nothing to understand here, slurp predates 'static' |
| 22:57:23 | Araq | readFile should work too but maybe I didn't implement it |
| 22:58:12 | BlaXpirit_ | nice to know this |
| 22:58:49 | flaviu | Araq: It looks like I was wrong on the nanopass framework. They make no attempts to optimize the process. |
| 23:00:39 | Araq | I don't even remember what 'nanopass' is |
| 23:02:04 | flaviu | Araq: That thing where you have > 50 passes instead of just 10-20. http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf |
| 23:08:23 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) |
| 23:08:41 | Triplefox | i'm trying to find it again, but there was a 1960's era fortran compiler that used 64 passes as a measure to save working memory |
| 23:10:17 | * | ARCADIVS joined #nim |
| 23:11:22 | gmoore | Araq ah ok that sounds great then. i'll give it a try later. thank you |
| 23:13:28 | Triplefox | http://ibm-1401.info/1401-FORTRAN-Illustrated.html |
| 23:14:49 | Araq | flaviu: https://github.com/Araq/Nim/issues/1940 is caused by the interaction of passes |
| 23:15:06 | Araq | and particularly nasty to debug |
| 23:15:20 | Araq | well ok, I didn't try too hard yet |
| 23:16:49 | Araq | in fact, I wanted to blog about this bug |
| 23:16:57 | Araq | let's see if I'll manage |
| 23:17:18 | * | flaviu quit (Remote host closed the connection) |
| 23:17:29 | * | flaviu joined #nim |
| 23:22:19 | * | onionhammer quit (Ping timeout: 255 seconds) |
| 23:25:01 | * | sillesta quit (Ping timeout: 255 seconds) |
| 23:26:04 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:28:55 | threewood | @ldlework: Languages that worry about semantics tend to be the ones that have prohibitions against arbitrary recursion across module boundaries, particularly recursion of types |
| 23:29:23 | threewood | IMO, rather than asking 'why don't we just do this', one should ask 'what does it mean' |
| 23:29:33 | ldlework | threewood: which ones? |
| 23:30:03 | threewood | like ML variants and all of the dependently typed theorem provers |
| 23:30:04 | ldlework | also, forward declarations will come, so where is your point |
| 23:30:14 | threewood | I don't know what Haskell does with recursive types across modules |
| 23:30:33 | threewood | My point was my second line |
| 23:30:41 | ldlework | the limitation isn't there because it was some forward thinking design |
| 23:30:57 | threewood | That wasn't my point |
| 23:31:03 | BlaXpirit_ | threewood, if you don't know what it means, go to google lol |
| 23:31:11 | ldlework | The case you're making isn't the case here in reality, so I don't know why you're making that case |
| 23:31:54 | threewood | My point is this: If you can answer what the recursion means, then you should probably have it. If you can't, you should probably try to answer what it means. |
| 23:32:01 | ldlework | "forward declarations" |
| 23:32:08 | ldlework | I don't know why we keep talking about this. |
| 23:32:36 | ldlework | Or how you can read that conversation and bring it back to life with more underhanded generalizations of virtue |
| 23:32:41 | ldlework | "Forward Declarations" |
| 23:32:56 | ldlework | There's nothing else to say. Really. |
| 23:34:26 | ldlework | "Don't be a worse programmer than me - if you just understood why you write broken software you would see the light" |
| 23:35:08 | ldlework | Is stepping backwards from where we are on this matter, so let's just not ping/highlight me, with regards to this issue going forward |
| 23:38:30 | Araq | http://fsharpforfunandprofit.com/posts/cyclic-dependencies/ |
| 23:38:36 | Triplefox | threewood: i'd be up for discussing it in detail, since i still don't know what is making this one worthy of a knife fight |
| 23:38:46 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:38:59 | Araq | ldlework: no, I don't want you to discuss this, but perhaps others find it interesting |
| 23:39:36 | ldlework | Araq: Which part of this article is true only for recursion across module boundries? |
| 23:40:19 | Araq | read the article. |
| 23:40:28 | Araq | "VS2008 shipped a week later than planned, because VS2008 had a dependency on SQL server, and SQL server had a dependency on VS" |
| 23:41:00 | threewood | Triplefox: It's not worth a knife fight and I didn't realize I was stepping into one. I saw some hostile comments from ldlework above, but I assumed they were directed at someone who had already angered him :) |
| 23:41:45 | threewood | Guess not ... Be careful. That kind of hostility can be really toxic in a young project like this. |
| 23:41:52 | Triplefox | well then. as you were :) |
| 23:41:57 | ldlework | You might say, "Yes, I can understand why circular dependencies are bad for assemblies, but why bother for code inside an assembly?" |
| 23:41:58 | ldlework | Well, for exactly the same reasons! Layering allows better partitioning, easier testing and cleaner refactoring. |
| 23:42:20 | threewood | But I'm open to discussing the issues... I'm just learning about Nim |
| 23:42:31 | ldlework | Better keep the broken module system, so that I have better partitioning by shoving multiple types into the same file. |
| 23:42:34 | ldlework | I see his and your points. |
| 23:42:45 | ldlework | I was looking for a fundamental consequence to the software architecture itself. |
| 23:43:05 | ldlework | But I guess the deployment of two disparate software systems is the same as me referring to a related type in my library. |
| 23:43:44 | threewood | If you're not worried about logical issues and termination properties, the main issue is probably just picking representations for types |
| 23:44:12 | threewood | You'd just need an extra layer of boxing |
| 23:44:14 | ldlework | threewood: I'm worried about the fact that my program functions correctly as long as I abuse compiler flag options to overcome limitations in the module system. |
| 23:45:22 | ldlework | You see, my program actually happens to work already. And I'd like to not abuse work-arounds "just because" theoretically my program might be hard to manage if I decide to use Nim's flexibility to write bad software. |
| 23:45:44 | ldlework | Better, make it less flexible to save me from myself. |
| 23:45:46 | flaviu | A bit meta, I don't think that discussions of this form are really suited to IRC. |
| 23:45:52 | ldlework | Even though, like, it can already be done anyway. |
| 23:46:03 | ldlework | And is done, with the result of, y'know, working software. |
| 23:46:10 | ldlework | But hey, this article! |
| 23:46:17 | ldlework | This article. I mean what's more to say. |
| 23:46:18 | flaviu | Not that I'm trying to tell anyone to stop talking or anything, I'm trying to start another discussion. |
| 23:47:12 | Araq | ldlework: the article might be of general interest. I'm well aware that at this point nothing will change your mind. |
| 23:47:24 | * | darkf joined #nim |
| 23:47:49 | Triplefox | part 2 is of interest because it gets into the idioms F# is using to resolve cycles when programmers are forced to do so |
| 23:47:54 | ldlework | Anything directly related to recusion across modules and how that will negatively affect my ability to write functional software, that isn't also true of just recursive types in general - will instantly change my mind. |
| 23:48:02 | ldlework | Literally - offer *anything* |
| 23:48:11 | * | yonson joined #nim |
| 23:48:47 | ldlework | I mean afterall, this is what I've said and asked for since this conversation started - continued to ask for throughout the entire discourse. |
| 23:49:09 | ldlework | My 'angry' language, an effect of getting nothing but high level generalizations that don't actually address the specific point in dispute. |
| 23:49:11 | ldlework | So... |
| 23:49:15 | ldlework | Call me crazy, okay. |
| 23:52:26 | * | Trustable1 quit (Quit: Leaving) |
| 23:54:05 | ekarlso | dom96: woul it be hard for me to add DELETE support to jester ? ^ |
| 23:54:14 | * | jpoirier quit (Quit: Leaving) |
| 23:58:46 | * | milosn quit (Ping timeout: 255 seconds) |
| 23:59:55 | * | milosn joined #nim |