La Fée Verte @Absinthe@qoto.org

@namark I am doing that other one on REPL.it right now if you care to come join me :)
https://repl.it/join/evjnthdk-reasintper

@namark that one is simple, why not give this a try:

http://codingdojo.org/kata/StringCalculator/

@namark @freemo @Lossberg

I think we are in agreement. Maybe it is not as cool as I believe, I am used to my wife rolling her eyes when I get excited about stuff like this... :)

@namark @freemo @Lossberg

I am not saying that you shouldn't solve the problem that way. That is as legitimate solution as any. And as a solution that comes from just diving in and doing it that is what I would expect. But it is not what I would expect from doing the TDD technique.

@Lossberg @namark @freemo good reason to have tests reviewed as well as code. Maybe a reviewer can find a case you haven't done to test some aspect of the specification.

@namark @freemo @Lossberg

Short of walking you through it, here is one instance where it was walked through. You can see the the unit tests that were used, unfortunately, there is not a really good way to see each of the coding steps and refactorings. I think I will have to do a Git solution that does a commit on each phase-step.

There are a couple commented solutions that are further ideas I wanted to keep.

https://repl.it/@reasintper/One-Kata-at-a-time

@freemo @namark @Lossberg No matter. Not all problems are for everyone. Do the ones you like, ignore the ones you don't.

@freemo @namark @Lossberg

@freemo, I assumed that you would consider this as uninteresting as problems that require brute force. I am disappointed that you are not willing to give it a shot. But i didn't really expect you to find much interest in it in the first place.

@namark @freemo @Lossberg

Those are the types of assumtions one arrives at when not using TDD :)

@freemo @namark @Lossberg a prime sieve would be more complex than the whole solution.

@freemo @namark @Lossberg It is a pragmatic solution based on a "process" where the process is more important than the solution. Think of it like Algebra.

Big numbers, small numbers... it is all a matter of time.

@freemo @namark @Lossberg I realize you enjoy different types of problems, and different types of solutions. So maybe even the suggestion of this is something you may find no interest in. I can accept that. I would encourage everyone, even you to give it a try (at that absolutely ridiculous level of pragmatically following the 3 laws and using the R-G-R workflow) Maybe you will get something out of it, maybe you won't.

And by pragmatically, I mean your first test would look like:

def test_factor_zero_return_empty():
assert factor(0) == []

----

and the first code that makes it pass is:

def factor(num):
return []

-------

That is the level or pragmatism I am speaking of.

@freemo @namark @Lossberg see if you see it generate an algorithm different from what you might have done not doing it that way.

@freemo @namark @Lossberg The factorization problem/kata is one that I particularly enjoy, because when I am done, and I look at the 6 lines of python that it generates... I always shake my head and say "I would not have written that no matter how long I sat there, or how many times I tried." Humor me, and let's see if you see similar things....

@Lossberg by the way, I do a #toyprogrammingchallenge here, you can look at the origination of it all the way back the 'Ninety-Nine Bottles of Beer" challenge. https://qoto.org/@Absinthe/102805659580967435

Feel free to play at any of them that interest you. There is no timebox on these. Watch for the tag #toyprogrammingchallenge and include it on any answers you offer to any of them.

@freemo @namark @Lossberg

When I say TDD, I mean it is the way of design and development. (maybe even a way of life :D )

This means following the 3 laws:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.

2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Using a Red-Green-Refactor work flow. Write just enough of a unit test for the simplest unit test. Then see that test fail(Red). Then write the SIMPLEST solution in the code to make it pass. (Green) Then refactor to remove complexity and simplify. Lather, rinse, repeat.

@namark @freemo actually, what would be interesting would be to just sit down and knock it out. Then do it again walking the steps of TDD and compare the results.

@freemo @namark one of the fun things about TDD is how it can organically create an algorithm that you might not do just by sitting down and hacking at it.

@freemo I am trying to get one started somewhere else, and in that particular place it will have to be FOSS.

However, I would have no problem doing it as a for profit thing, but that sounds more like the definition of a "Coding Business" I wonder if it could make any money? :)

@freemo I guess, why not? Adds another layer of complexity to things whenever money gets involved though. :)