Live data from Hacker News

Can't Driven Development

rm4n0s.github.io

11–20 of 54 posts

Re: Can't Driven Development

#11
negative assertions are more powerful/expressive than positive ones. e.g. "Not an enemy" is more powerful than "A friend" - the latter limits the possibilities a lot.

or, #ifndef GONE is more powerful/flexible than #ifdef PRESENT

Of course, sometimes one wants exactly that specific things that positive assertions do. But IMO that's rarely the case, it's just going positive seems simpler/easier to think of.

one may say, in some system of rules, "Dont's" are more usable than "Do's". Think cultures..

Re: Can't Driven Development

#12

This doesnt make a lot of sense. The set of things your software cant do is infinite. The set of potential errors is massive and many if not most are unrelated to domain logic.

I think it's is finite. I couldn't think of another "can't" statement for my exercise. If you find any please tell me to patch the code. You thinking in DDD because in CDD there is no domain logic. Everything is part of stack trace tree

Your exercise can't: 1. Tell me who other people's friends are. 2. Change it's output if a spammer stops pinging after 1 hour. 3. Count the amount of times a person has pinged in their lifetimes. 4. Build a pyramid 5. Output Pi 6. Make me lasagna

Re: Can't Driven Development

#13

Earlier quoted context omitted.

I think it's is finite. I couldn't think of another "can't" statement for my exercise. If you find any please tell me to patch the code. You thinking in DDD because in CDD there is no domain logic. Everything is part of stack trace tree

Your exercise can't: 1. Tell me who other people's friends are. 2. Change it's output if a spammer stops pinging after 1 hour. 3. Count the amount of times a person has pinged in their lifetimes. 4. Build a pyramid 5. Output Pi 6. Make me lasagna

yes, it can't.

For some “can't” statements, you don't need to write any error.

The “can't” statements in CDD are for actions and input that you could take, but the software deliberately prevents you from doing them.

There are no actions or input, requested from the exercise that make it possible to do the list you gave me, so it does not make sense to create an error for them.

Re: Can't Driven Development

#14
post #8
post #5

Guard conditions, assertions, constraints and tests are dynamic limits on code and are critical to maintain quality despite code rot and drift from changes. Static constraints like types can also be also good, where types are good. I applaud anyone who advocates to focus on the unhappy path over the happy path. On a side note 25 years ago was the end of the dot.com and the height of the y2k scam and I have never seen…

I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.

Developers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.

Re: Can't Driven Development

#15
post #7
post #3

This is just TDD. Your tests should be written to verify and gaurd against "cants" not verify the happy path

It is not TDD because CDD does not architect the software through refactoring passed tests. It architects the code from the errors by following specific rules

lol

Re: Can't Driven Development

#17
post #8

Earlier quoted context omitted.

I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.

Developers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.

Yeah because back then the tech stack was:

php apache mysql linux

it was so small we could put it into an acronym.

Meanwhile in 2024 you could barely begin to even describe any individual layer of the stack with so few words. You'd be out of breath before even beginning to finish describing React.

(btw it's silicon, not silicone).

Re: Can't Driven Development

#19
post #8

Earlier quoted context omitted.

I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.

Developers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.

I am not asking, it will be the only way from now on if companies don't want to waste more money and time.

Because the option to parse stack traces from the programming language itself, it will destroy what ever built on or for microservices

Post reply on HN