00:14 <+Learath2> no need to tie your hands with such ideas 00:59 <@heinrich5991> it also enables stuff 00:59 <@heinrich5991> so it's not entirely tying your hands ^^ 06:04 <@deen> Learath2: The idea is that by restrictring your own power you have fewer things to think about and thus make fewer bugs. If you see a value is immutable you don't have to reason about how it will change during the function execution 06:04 <@deen> And of course, like heinrich5911 said, the compiler can make use of it for optimizations 06:06 <@deen> 5991* 06:09 <@deen> See also: "Using control structures instead of goto", "Using scope instead of globals", "Static instead of dynamic typing", DSLs, etc 06:10 <@deen> https://en.wikipedia.org/wiki/Rule_of_least_power 11:52 <+bridge> [ddnet] Interesting 13:36 <+bridge> [freenode] immutability is used for reliability/performance too 13:36 <+bridge> [freenode] like Java (and others) making strings immutable 14:55 <+Learath2> or you can just pay attention? The optimization gains are nice which is why it'd be a nice language feature like in javascript 14:57 <+Learath2> but having it by default or forcing it on all variables is just overkill, been using redux for the last month and everyone keeps shouting at you to not mutate the state but mutating the state is much quicker then making a new copy of the entire app state and modifying that 15:02 <@deen> Well, if you have to modify the entire state all the time, then it sounds like you still want to do imperative programming. I guess redux is trying to enforce functional style. You have some example? 15:05 <+Learath2> I want the language to let me do whatever I want without fancy keywords. If I want safety features or to mark something immutable I should be the one to decide that 15:05 <@deen> So you also want to type check by default? 15:06 <+Learath2> I guess you mean "(disable) type check..." 15:07 <@deen> yes 15:07 <@deen> And in my experience people keep forgetting to mark values as immutable 15:07 <+Learath2> As long as it doesn't hurt the language's structure I don't mind, if you are going to make it a mess like js you better keep the type checking 15:10 <+Learath2> I feel a strongly typed language helps very much in reducing bugs, but ask many people who use js, py, ruby and they might feel it slows them down 15:13 <@deen> Yeah, and you sound similar about immutability :D 15:14 <+Learath2> I kinda enjoyed the fact that javascript had all the tools needed to write in a functional way but also let's you write in an imperative way 15:14 <+Learath2> What's wrong with freedom? Opionated languages and frameworks make us boring and predictable. 15:15 <@deen> What's wrong with freedom? Building codes and fire exists make us boring and predictable. 15:16 <@deen> So the idea is that you want your code to be boring and predictable in order to work together in big teams and easily read and understand each other's code 15:16 <@deen> Preferring a simple solution over an interesting but harder to understand one 15:17 <+Learath2> off-topic: deen: where did we mount the test server maps? servers/test/maps or servers/test/data/maps? 15:17 <@deen> Go language tries very hard to do that 15:17 <@deen> dunno :D 15:17 <@deen> run-all.sh says test/data/maps 15:18 <@deen> Nim is quite the opposite, you can write fully imperative code, do unsafe stuff everywhere, have macros that change the language in some places to something totally different. So that's a whole lot of fun, but I wouldn't recommend it to a large team for mission critical software 15:20 <+Learath2> mission critical software has been written for decades, standards and coding simply not fancily already solve these issues 15:20 <+bridge> [freenode] heh. there was a dude on hedgewars server the other day who was scoffing at rust, 'cause it wasn't coq 15:20 <+bridge> [freenode] "How can you trust any code that hasn't been formally verified" 15:21 <+bridge> [freenode] at some point, gotta actually just get stuff done 15:21 <+bridge> [freenode] (this was because we were discussing the rust port in that room) 15:21 <+Learath2> functional programming surely makes it easier, which is why it's a nice paradigm, shoving it down peoples throats is just, meh 15:21 <@deen> yeah, I tried running a SAT solver on some of our code at work, ran out of memory after 48 hours :D 15:21 <@deen> not much success with proving for me 15:22 <+Learath2> what is a coq even? 15:22 <@deen> https://en.wikipedia.org/wiki/Coq 15:23 <+bridge> [freenode] did you guys see how Sir Robin was discovered using a SAT? (the conway knightship) 15:23 <@deen> yeah 15:24 <+bridge> [freenode] also... apparently some dude out there is busy formally verifying fundamental rust libs, so at least there's that, if it makes dude-on-our-gameserver-feel better. 15:24 <+bridge> [freenode] 'course he misunderstood me at time and thought I was suggesting this was a normal thing to do in rust. but then, he also thought rust only had memory bounds checks, nothing more 15:25 <@deen> Unit testing would already be a step in the right direction :D 15:25 <@deen> At least prove that your code works for one case, not for all 15:25 <+Learath2> currently learning rust, it is pretty different 15:26 <+Learath2> as in I've never quite seen anything like it 15:28 <@deen> anything in specific? 15:29 <+Learath2> the syntax is really new, i keep finding myself thinking in if/else if/else where I should probably be thinking in terms of match blocks 15:39 <@heinrich5991> deen: coq is different, it's not an automatic prover but a proof assistent – it won't run out of memory, it'll tell you to specify the proof ^^ 16:09 <@deen> heinrich5991: I know, I've used it a bit. Wanted to try out something new though 16:29 <@heinrich5991> o_be_one / o_tee_one: I understand your name now. it hit me in the shower :D 19:06 <+bridge> [ddnet] pituh?