I don't come from 'Java-land'. I'm primarily an Erlang developer, which already is a very similar language to Clojure. Perhaps this is why I'm not gushing about functional programming's panacea?
Aaron On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: > This has turned into an unconstructive argument and for whatever reason we > don't seem to be communicating clearly. Shame as I (and probably most > people on here) only want to help. You seem to be reacting quite strongly > to my thoughts - not sure why. > > If I may, I will just make/rephrase two points: > - I think you would find value in watching Rick Hickey's videos on "Simple > Made Easy" and also the one where he talks about "Hammock Driven > Development". > - when I started using Clojure I immediately looked for equivalents of all > the supporting infrastructure I used in good old Java land. I have no idea > of your situation, but if you are there you have a wonderful opportunity to > re-examine and build up a whole new toolchain/approach to development that > IME is significantly lighter and more powerful. > > Peace. > > On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: > > > > On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: > > > Comments in line. > > > On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: > > > > > > > > > > > > I don't want to seem rude but I think you've drank a bit too much > > > > kool-aid. > > > > > > > You know the phrase "I don't want to seem rude" doesn't actually do > > > anything right? :) > > > > > > > > > > I genuinely don't want to offend. People allow themselves to become > > vested in their viewpoint. If that has happened to you, I'm sorry. > > > > > > To say that functional programming and war against state means that > > > > your application doesn't need to be tested thoroughly is a joke. And a > > > > very bad one. > > > > > > > I agree, but who is saying that? I certainly didn't cover how much > > testing > > > is necessary. I thoroughly test my Clojure systems using midje, which > > > regularly rocks my world. My point is that the coverage is much *much* > > > easier to reason about in FP than in OO (for the reasons I gave). > > > > I'm not following how you translate this into information which > > explains how your system is being tested. > > > > > > > > > > > > Coverage doesn't just aid you in seeing which parts of state caused > > > > which branches to be hit, it also gives you notice if there are any > > > > logical errors in your code which cause the branches to not be hit. > > > > > > > And why are those logical errors which cause the branches to not be hit > > not > > > immediately obvious? Why do you need a tool to tell you that? I know > > my > > > Clojure code has around 100% coverage using white box testing for the > > > functions and mocking the interactions. > > > > And what's the harm in getting this information from an automated > > tool? With your 20 years industry knowledge you should know that you > > cannot rely on humans to think and act reliably. It's just not a good > > way to plan systems. *Especially* when it comes to asking someone how > > correct their system is. > > > > > > I would challenge you to put ego/emotion to one side, stop finding > > > non-existent points to argue against and re-read my post. By all means > > > come back and justify why all the points I raised which reduce the need > > for > > > coverage are invalid. Don't attribute stupid statements (like 'FP > > doesn't > > > need testing') to me - I can come up with my own stupid statements thank > > > you. > > > > You hand waved the need to use tools such as coverage reports simply > > on the virtue of some hard to quantify statements. I find that > > unscientific. > > > > > > If it helps, my stand point is from 20 years of building non-trivial > > > Enterprise applications (primarily Java) using the current best of breed > > > technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed > > > process (agile, TDD, DBC, BDD, most otherTLAs etc.). > > > > Arguments from authority mean nothing on the internet. > > > > > Using Clojure for the past year or so has opened my eyes to exactly > > > how many problems we solve, and infrastructure we use is to pamper > > > to complexity introduced by the tool-chain not the problem domain. > > > I am suggesting maybe coverage tools are one of those. > > > > > > > Coverage helps nothing on its own. It's a tool to aid in knowing which > > aspects of your system remain untested. It's fine to *believe* you're > > testing 100% of your system, but how do you actually know this? > > > > If you wander into a codebase you're not familiar with, what's the > > coverage? How do you know you're hitting all codepaths? You just > > cannot know this without reading all the code and the tests. Coverage > > helps to discover this information. > > > > My point isn't to eschew all other forms of testing in favour of > > coverage reports but to use them in tandem with the others to aid me > > in *knowing* which parts of the system are being tested and which are not. > > > > Aaron > > > > > > > > > Aaron > > > > > > > > On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: > > > > > I don't know. > > > > > > > > > > But maybe the lack of coverage tools is itself interesting? My (not > > > > quite > > > > > formed/making this up as I go) view is that maybe coverage tools are > > > > there > > > > > to address the implicit complexity in other mainstream languages > > and/or > > > > to > > > > > help mitigate the risk of the potentially large and hard-to-identify > > > > > 'impact analysis' you get in OO systems when you change state. In > > other > > > > > words, coverage is necessary because we want to feel safe that all > > > > > combinations of our code are extensively tested. Why don't we feel > > > > safe? > > > > > Because the system is hard to reason about. > > > > > > > > > > Functional programming on the other hand is full of much smaller > > > > discrete > > > > > and independent chunks of functionality. Ideally these small > > focused > > > > > 'bricks' are pure/referentially transparent so the *only* context > > you > > > > need > > > > > when reasoning about them is their parameters and the logic inside. > > > > > Assembling these bricks introduces interactions that need to be > > tested, > > > > > sure, but there are very few 'call this and watch the change > > > > cascade'/'this > > > > > code is sensitive (i.e. coupled) to that data over there'. > > > > > > > > > > My ramblings are to say, maybe the root cause of coverage tools is > > to > > > > solve > > > > > a problem (hard to reason about systems) which shouldn't be much > > less of > > > > a > > > > > problem in FP when FP is done right. OO + mutable state = hard to > > > > reason > > > > > about. FP + immutable state + pure/referentially transparent > > functions > > > > = > > > > > much easier to reason about. > > > > > > > > > > Or not. Just my 2 pence :). > > > > > > > > > > On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I'm looking for coverage reporting in Clojure. I've been using > > > > > > Cloverage[1] but I'm just wondering if there are any other > > coverage > > > > > > tools? > > > > > > > > > > > > Aaron > > > > > > > > > > > > > > > > > > [1] https://github.com/lshift/cloverage > > > > > > > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "Clojure" group. > > > > > To post to this group, send email to > > > > > clo...@googlegroups.com<javascript:> > > > > > > > Note that posts from new members are moderated - please be patient > > with > > > > your first post. > > > > > To unsubscribe from this group, send email to > > > > > clojure+u...@googlegroups.com <javascript:> > > > > > For more options, visit this group at > > > > > http://groups.google.com/group/clojure?hl=en > > > > > --- > > > > > You received this message because you are subscribed to the Google > > > > Groups "Clojure" group. > > > > > To unsubscribe from this group and stop receiving emails from it, > > send > > > > an email to clojure+u...@googlegroups.com <javascript:>. > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clo...@googlegroups.com<javascript:> > > > Note that posts from new members are moderated - please be patient with > > your first post. > > > To unsubscribe from this group, send email to > > > clojure+u...@googlegroups.com <javascript:> > > > For more options, visit this group at > > > http://groups.google.com/group/clojure?hl=en > > > --- > > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > an email to clojure+u...@googlegroups.com <javascript:>. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.
pgpZlAKU5rI_5.pgp
Description: PGP signature
