Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

Post reply on HN
Print view View original

191–200 of 201 posts

Re: The Grug Brained Developer (2022)

#191

Post by hitchstory »

mrkeen wrote: post #182
hitchstory wrote: post #178

Earlier quoted context omitted.

>... constructing a particular set of circumstances which will never occur in the real-world system. What do you find unlikely about a scenario where a test uses an app in a realistic way (e.g. with a browser) set up in a realistic context (e.g. with some fixed sample data) to reproduce a realistic scenario (e.g. a bug that already happened)? I wouldn't say that isolation and realism are completely orthogonal but I f…

> I wouldn't say that isolation and realism are completely orthogonal Neither would I. I'm arguing that when you write a test method, you deliberately make the choice to include some kind of 'before-all' method, or not. The reasons you would choose to include a 'before-all' method will vary from case to case. Let's say you're testing an addUser method. If you choose to isolate its state to avoid 'test flakiness', it…

>The reasons you would choose to include a 'before-all' method will vary from case to case.

Not really. I would always purge anything that would cause tests to share state. I wouldn't do it on a case by case basis.

>What is it about your application code that would make you think that addUser is flaky enough to need a clean slate to run against?

The user already existing in the database? The behavior of the app would change in that case. Something has to wipe the db clean to test that scenario.

Thats why tests shouldn't share databases.

Re: The Grug Brained Developer (2022)

#193

Post by randomdata »

PH95VuimJjqBqy wrote: post #143
randomdata wrote: post #126

Earlier quoted context omitted.

> they were convinced that sort of flexibility was a good idea. Believing flexibility is needed still suggests a lack of understanding.

not being absolutely perfect suggests a lack of understanding, but at that point we're engaged in a tautology. Values are those things that help guide you in the face of imperfect information. Not having a crystal ball that can predict the future perfectly means you have imperfect information.

Perfection is not necessary for you to be confident that you have a reasonable understanding and can build something to match. It is possible the confidence will prove to be misguided, but you can deal with that later.

To prioritize flexibility means that one lacks the understanding required to even build a misguided confidence.

Re: The Grug Brained Developer (2022)

#194

Post by PH95VuimJjqBqy »

randomdata wrote: post #193
PH95VuimJjqBqy wrote: post #143

Earlier quoted context omitted.

not being absolutely perfect suggests a lack of understanding, but at that point we're engaged in a tautology. Values are those things that help guide you in the face of imperfect information. Not having a crystal ball that can predict the future perfectly means you have imperfect information.

Perfection is not necessary for you to be confident that you have a reasonable understanding and can build something to match. It is possible the confidence will prove to be misguided, but you can deal with that later. To prioritize flexibility means that one lacks the understanding required to even build a misguided confidence.

> It is possible the confidence will prove to be misguided

At which point your description of a lack of understanding applies, hence my comment.

Re: The Grug Brained Developer (2022)

#195

Post by randomdata »

PH95VuimJjqBqy wrote: post #194
randomdata wrote: post #193

Earlier quoted context omitted.

Perfection is not necessary for you to be confident that you have a reasonable understanding and can build something to match. It is possible the confidence will prove to be misguided, but you can deal with that later. To prioritize flexibility means that one lacks the understanding required to even build a misguided confidence.

> It is possible the confidence will prove to be misguided At which point your description of a lack of understanding applies, hence my comment.

That does not imply there is a lack of understanding in the moment. Understanding does not seek perfection towards future events. However, if you do not even understand what is known in the present, that is when you will start to lean on flexibility.

Re: The Grug Brained Developer (2022)

#196

Post by n4r9 »

randomdata wrote: post #183
n4r9 wrote: post #177

Earlier quoted context omitted.

I think they differ about the why . The article claims that types are useful mainly because they allow sophisticated auto-completions. u/mordae thinks there are more important benefits re avoiding bugs in production.

In the link, Grug acknowledges the benefits of correctness established by types to an extent, but is highlighting the diminishing returns. After all, if one truly valued type system-enforced correctness, they would be writing code in something like Coq, not C and typed Python.

That sounds like a false binary to me. All language features have trade-offs and interactions with other features. It's not about "truly valuing" one thing above all else - your relative preferences depend on your experiences and what you value in the product.

Some people think type correctness is very important; perhaps they value minimising bugs over shipping fast. Other people think auto-complete suggestions is more important; perhaps they value shipping fast over minimising bugs.

Both positions could well-justified depending on the domain. In healthcare or military, the former makes sense. In gaming or web development, the latter makes sense.

Re: The Grug Brained Developer (2022)

#197

Post by PH95VuimJjqBqy »

randomdata wrote: post #195
PH95VuimJjqBqy wrote: post #194

Earlier quoted context omitted.

> It is possible the confidence will prove to be misguided At which point your description of a lack of understanding applies, hence my comment.

That does not imply there is a lack of understanding in the moment. Understanding does not seek perfection towards future events. However, if you do not even understand what is known in the present, that is when you will start to lean on flexibility.

We can always beat a word into the shape we want it, but the phrase has a common meaning, I would suggest you use a different word.

Re: The Grug Brained Developer (2022)

#198

Post by randomdata »

n4r9 wrote: post #196
randomdata wrote: post #183

Earlier quoted context omitted.

In the link, Grug acknowledges the benefits of correctness established by types to an extent, but is highlighting the diminishing returns. After all, if one truly valued type system-enforced correctness, they would be writing code in something like Coq, not C and typed Python.

That sounds like a false binary to me. All language features have trade-offs and interactions with other features. It's not about "truly valuing" one thing above all else - your relative preferences depend on your experiences and what you value in the product. Some people think type correctness is very important; perhaps they value minimising bugs over shipping fast. Other people think auto-complete suggestions is mo…

> It's not about "truly valuing" one thing above all else

There is context here. With respect to the link, it is. It specifically refers to the "shamans" who promote that there is only one true type system way, and any "lesser" type systems are not sufficient.

C, typed Python, hell basically every language you are actually going to encounter in the typical programming project makes the very tradeoffs you mention because its probably not that important for the type system to perfectly express the constraints in order to validate correctness for your problems. That a primitive type system with some automated testing is good enough in the vast majority of cases. The idea, if you hadn't already figured it out before getting that far into the document, is to not overcomplicate things.

Re: The Grug Brained Developer (2022)

#199

Post by n4r9 »

randomdata wrote: post #198
n4r9 wrote: post #196

Earlier quoted context omitted.

That sounds like a false binary to me. All language features have trade-offs and interactions with other features. It's not about "truly valuing" one thing above all else - your relative preferences depend on your experiences and what you value in the product. Some people think type correctness is very important; perhaps they value minimising bugs over shipping fast. Other people think auto-complete suggestions is mo…

> It's not about "truly valuing" one thing above all else There is context here. With respect to the link, it is. It specifically refers to the "shamans" who promote that there is only one true type system way, and any "lesser" type systems are not sufficient. C, typed Python, hell basically every language you are actually going to encounter in the typical programming project makes the very tradeoffs you mention beca…

The linked article says:

> big brain type system shaman often say type correctness main point type system

This is a much weaker position than you're suggesting. Opining about the "main point" of type systems does not mean thinking that there is one true type system way.

Re: The Grug Brained Developer (2022)

#200

Post by p0nce »

stnmtn wrote: post #181
p0nce wrote: post #124

Earlier quoted context omitted.

While I agree mostly, you can overdo the "grug". For example it is possible to underengineer (underabstract?) a software for years until realizing that simple things are still complicated, and you forget to built good abstractions once the patterns have emerged. If you build abstractions, you need a way to correct them anyway, making breaking changes to their contract.

The point is that "underengineering" then having to tie up the abstractions when it's really needed is oftentimes (read: not always) better than overengineering and entering the domain of the complexity demon

I agree that the balance is way too often shifted in the way of overengineering, probably because of our field being skewed by "higher status" thinking.
Post reply on HN