#toyprogrammingchallenge

Okay folks, this should be simple, but maybe not.

The goal is to write a function that takes a positive integer and returns a list of its prime factors. So if you did 12 you should get the list [2, 2, 3]

As neither 1 nor zero are prime, as a result should return an empty list.

This is taken from a #tdd #Kata, so if you have not done this one I encourage you to do so. If you are not into #TDD then solve it however you like.

@Absinthe Easy to solve yes, but rather difficult to solve efficiently!

@freemo @Absinthe An even deeper rabbit hole with TDD: "You want to test your factorization? Well, you need a primality test... But wait! Who's gonna test your primality test? Well, you need a prime number generator... But wait!..."
No monkeys, no coconuts, no bottles, no fun...

@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.

@Absinthe

I think people would have a tendency to repeat the way they did it the first time the second time, its hard to forget a solution you just did.. still I do think TDD thinking changes to some extend the design process. Sometimes for the better sometimes for the worse maybe.

@namark

@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.

@Absinthe

I'm familiar with TDD and even had to practice it at a few workplaces in that manner. IMO when taken to that extreme, as some people do, I think it is more harmful than good, usually. But i can see at times it being beneficial in other ways.

@namark @Lossberg

@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....

@Absinthe

Well, from our brief discussion with @freemo we arrived at needing a prime number generator to write the test for factorization, which itself would require at least a trivial primality test, which will have to be written without a unit test. How was your approach different? Did you generate a certain amount of prime numbers by hand and deemed that acceptable?

@freemo @Lossberg

@namark @freemo @Lossberg

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

@Absinthe

As I said, I have done a lot of TDD, I know the idea well...

@namark @Lossberg

@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.

@Absinthe

Its not that I'm not willing. I've done the problem before, and am a bit busy as usual lately.

@namark @Lossberg