jarhart

5 ms·

1. 1.▲
   by jarhart 13y ago

   I completely agree that TDD originally meant that, and still does. The problem is too many developers don't bother to learn what TDD really means and immediately think of it as a testing methodology because the first word is "test
2. 2.▲
   by jarhart 13y ago

   I'm often frustrated with developers looking at the term "test-driven development", focusing on the word "test", and thinking of TDD as a testing process instead of a development process. The BDD movement made some
3. 3.▲
   by jarhart 13y ago

   Actually it's not. Only the primitive readers have similar "overhead" as with the implicits approach. Most of the readers are defined by mapping or flatMapping over the primitives (either explicitly or with comprehensions). W
4. 4.▲
   by jarhart 13y ago

   It does actually solve the problem that DI solves in general, because you create readers that expect the dependency to be injected into them. You still have to decide how to do the injection and that's true for all of the non-framework
5. 5.▲
   by jarhart 13y ago

   I look forward to that blog post. In order to use Scalaz's monad transformers with scala.concurrent.Future, would I have to write my own monad instance for it, or is there a way to re-use the one from scalaz.concurrent?
6. 6.▲
   by jarhart 13y ago

   Technically, Scala's for comprehensions don't let you mix monads either, but implicit conversions make it work in some cases. For example, there's an implicit conversion from Option to Iterable so the Option (Maybe) and List
7. 7.▲
   by jarhart 13y ago

   I actually like using comprehensions in Scala so I don't find it annoying at all. Also I think having a clear distinction between the "normal" and "injected" functions is a good thing. I do find having to add implic