[12:15.00] <%thewormkill> I should mention that I am not a big fan of tests, especially in functional programming
[12:15.04] <%thewormkill> but this...
[12:15.05] <Insanity> Wy not?
[12:15.08] <Insanity> why*
[12:16.00] <%thewormkill> because testing is a concept inherently flawed when it comes to verifying software correctness
[12:16.09] <Insanity> It is?
[12:16.25] <%thewormkill> yes
[12:16.28] <Insanity> Hmm
[12:16.31] <%thewormkill> you want an explanation?
[12:16.36] <%thewormkill> I have 15 mins
[12:16.40] <Insanity> Sure, if you're up for it
[12:16.51] <%thewormkill> sure, just post the IRC logs on the forums
[12:16.58] <Insanity> Me? :o
[12:17.18] <%thewormkill> well, the basic idea with testing is that you create examples that are intended to prove your components work correctly
[12:17.37] <%thewormkill> Insanity: yes, you. I don't post my own logs, people who listen to me do
[12:17.40] <%thewormkill> ;)
[12:17.49] <Insanity> thewormkill, lol, what would it be posted under? xP
[12:18.03] <%thewormkill> now, if you want to prove something in mathematics, you can't just use an example
[12:18.08] <%thewormkill> Insanity: dunno, you choose
[12:18.14] <Insanity> Kk, sorry, continue
[12:18.31] <%thewormkill> Because an example is no proof. Instead, your proof needs to be universally quantified
[12:18.42] <%thewormkill> meaning that it succeeds to work for each possible input
[12:19.15] <%thewormkill> so we have two options: either write formal proofs for each and every thing (hard, often impossible, not everyone
[12:19.20] <%thewormkill> 's thing)
[12:19.47] <%thewormkill> OR we just tets our code with each possible input (impossible, ugly, bad idea)
[12:20.14] <%thewormkill> now, those are the "perfect" solutions that should guarantee correctness
[12:20.34] <%thewormkill> Now let's look how that problem is handled in real-life ecosystems
[12:21.04] <%thewormkill> In dynamic languages, you are beaten up if you do not use Unit testing to verify correctness of your code
[12:21.39] <%thewormkill> 's components. If you do not, the dynamic typing rears it's ugly(?) head and kicks you in the butt as soon as you change one component
[12:22.06] <%thewormkill> and this introduces regression testing which verifies inter-component logic after changes to individual components
[12:22.16] <%thewormkill> now, Insanity, do you see a pattern there?
[12:22.24] <Insanity> Kinda, yes
[12:22.43] <Insanity> It seems circular
[12:22.48] <%thewormkill> yes it is
[12:22.54] <%thewormkill> because you can write bad tests
[12:22.59] <Insanity> Wow
[12:23.03] <%thewormkill> and add more complexity to a system already complex enough
[12:23.19] <%thewormkill> so yeah, this is not a solution in the common sense.
[12:23.29] <%thewormkill> Now let us look at more advanced systems
[12:23.40] <%thewormkill> For instance, property-based testing
[12:24.06] <%thewormkill> that's a pretty nifty concept: The test framework provides methods to describe propertties of your code
[12:24.17] <%thewormkill> basically "examples with a variable"
[12:24.44] <%thewormkill> After you specified those, you run the tests, and the framework generates random data to fill in the gaps
[12:25.21] <%thewormkill> that's much better already. It actually shows you bugs. But, it is hard to think of an appropriate test for, say, an IO routine
[12:26.21] <%thewormkill> and since this kind of system is afaik only available in the world of functional programming, this leads to more problems with testing IO heavy tasks, due to the way pure functional programming languages handle IO and side-effects
[12:26.31] <%thewormkill> But all this still leaves us with one problem, Insanity
[12:26.33] <%thewormkill> we can
[12:26.46] <%thewormkill> certainly write tests like this
[12:26.49] <TungstenX> A test / QA should be a pedantic main in the ass and mine at work is a 3 finger proctology exam!
[12:26.56] <TungstenX> *tester
[12:27.11] <%thewormkill> and we need to, otherwise we will be fucked up heavily when writing python or ruby
[12:27.22] <Insanity> TungstenX, shut it
[12:27.37] <%thewormkill> but with property-based testing we need to define properties of our code... which means we need to describe our code
[12:28.19] <%thewormkill> depending on how small your code's tiniest units are, you might end up with a general inability to write tests
[12:28.23] <%thewormkill> BAD
[12:28.29] <Insanity> That would be, lol
[12:28.36] * m0rph (m0rph@ran.fa.li) has joined channel #Evilzone
[12:28.36] * Evilbot sets mode +h m0rph for #Evilzone
[12:28.41] <%thewormkill> Insanity: so yeah, we end up either being circular, or not fixing anything
[12:28.52] <Insanity> I understnad, now, damn
[12:28.56] <Insanity> understand*
[12:29.03] <Insanity> m0rph, welcome back
[12:29.06] <%thewormkill> so obv. the wheel is broken, we need to invent a new one IMO. Or find a revolutional approach
