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

151–160 of 201 posts

Re: The Grug Brained Developer (2022)

#151

Post by namtab00 »

rebeccaskinner wrote: post #87
hudon wrote: post #56

Earlier quoted context omitted.

> smart people are naturally attracted to complexity like moth to a flame I think the general inclination here towards static typing is due to this, rather than any evidence that statically typed languages lead to higher quality software. Engineers just love puzzles. I'm also looking at you, Rustaceans... runs for his life

I’ve seen some variation of this accusation being thrown around for years- and frequently by people who I regard as smart, capable developers. On the other hand, having worked with languages all over the spectrum of static typing- I’ve also seen first how how high the bar really is for benefiting from static types before you hit diminishing returns. The best answer I can come up with is that people just seem to have…

Nothing to add, except for a sincere appreciation for how you eloquently and impartially summed up the divide.

Re: The Grug Brained Developer (2022)

#152

Post by namtab00 »

thefourthchime wrote: post #99

I've been a developer for 30 years, and I'll admit that in my early days, I was arrogant and thought I was smarter than everyone else. I'd describe myself back then as one of those "big-brains" loving all the complexity demons. 10 years later, and I've shifted more towards being a "Grug brain" developer. Now, I focus on the simplest solution that could possibly work, knowing that it's probably not perfect. But that's…

There's some indescribable and pleasurable sensation in the back of my head when I delete code.

It's like I'm FEELING the space being freed.

Re: The Grug Brained Developer (2022)

#153

Post by josephg »

qweqwe14 wrote: post #79
erik_seaberg wrote: post #59

Earlier quoted context omitted.

It might be different if you have to talk to an ASIC that cannot understand protobuf, or send billions of values at line speed. But generally I don’t have to care anymore whether a number is sent in exactly sixteen bits, for the same reason I long since stopped caring about message framing or parity or run-length limits or 0-5 vs ±12 V busses. Expressing any of those constraints takes more effort than letting the mac…

It wouldn't be ad hoc per se, basically you would have a set of guidelines on how to transmit data and that by itself would be a standard. Something like "use fixed length 8/16/32/64 bit signed/unsigned integers in big endian, length prefix can be 8/16/32 bits, bool is 1 byte (00 = false, 01 = true)" etc, without extra stuff like varints or bit packing, which a lot of current formats are doing. In short, just use the…

I agree; sometimes writing your own binary format is the right call. To my point upthread, the trick is knowing when that’s the right choice and when it’s better to use protobuf or something standard. (Or, when to just stick to json).

Developing good instincts for this stuff takes a lifetime.

Re: The Grug Brained Developer (2022)

#154

Post by fredrikholm »

MrVandemar wrote: post #109
dinkleberg wrote: post #55

Earlier quoted context omitted.

Of the languages I’ve used, Go comes closest. The language is small and boring, but it means I stay focused on the problem and hand instead of getting fancy.

That's the first thing anyone has ever said about Go that makes me want to learn the language. That sounds like an ideal programming language.

This mindset permeates through the entire ecosystem and tooling as well.

Enterprise projects build in single digit seconds, test suites fly by, project builds to a single binary (with embedded resources), most third party dependencies follow the established interfaces (which means plug and play) and so on.

It's the one language that I feel confident in, despite having worked in several other languages for many more years than Go.

Re: The Grug Brained Developer (2022)

#155

Post by freilanzer »

randomdata wrote: post #142
mordae wrote: post #106

I have a beef with the typing section: > grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug Juniors at my job routinely ship code that breaks due to null access in production, Sentry tells me. During intensive development periods that's about 1 detected null-a…

> That's just rude and uncalled for. But is it wrong? Based on your stated experience, not even you seem to buy into type systems that force formal proofs – instead accepting lesser type systems that make tradeoffs between catching some problems (along with, most importantly, providing popup magic!) and not bogging you down in every little detail needed to prove total correctness.

> But is it wrong?

Yes, because people don't "not often ship code in statically typed languages". It's obviously wrong.

Re: The Grug Brained Developer (2022)

#156

Post by mrkeen »

nicolas_t wrote: post #144
aardvark179 wrote: post #125

Earlier quoted context omitted.

Strongly disagree. Integration tests work brilliantly until a certain size or complexity is hit and then they become really bad. Unit tests are harder to write and maintain, but they will serve you much better in the long run because when they fail it’s much easier to understand and debug. The worst sort of tests are integration tests which secretly depend on another integration test having run first, which will be t…

> The worst sort of tests are integration tests which secretly depend on another integration test having run first That's an example of bad integration tests. Well engineered integrations tests don't do that.

It's a property of the code under test, not the tests themselves.

If the system is crappy/stateful/implicit, and you somehow manage to write nice/clean/stateless integration tests against it, I'd argue that the tests won't be close enough to the expected running of the system to tell you anything useful about it.

Re: The Grug Brained Developer (2022)

#157

Post by Tao3300 »

noman-land wrote: post #30
pjs_ wrote: post #22

OK I reckon everyone is going to get on the HTMX wagon over the course of the next few months, and it's going to blow a ton of young minds and save a huge amount of global energy and make a lot of people very happy. And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come o…

Spoiler very much alert.

The Dimension Collector's Series DVD cover has the fanged face of a vampire woman on it.

If someone thinks it's ruined because they found out ahead of time that there are vampires in it... yeah, that's their problem.

Re: The Grug Brained Developer (2022)

#158

Post by Spivak »

freilanzer wrote: post #155
randomdata wrote: post #142

Earlier quoted context omitted.

> That's just rude and uncalled for. But is it wrong? Based on your stated experience, not even you seem to buy into type systems that force formal proofs – instead accepting lesser type systems that make tradeoffs between catching some problems (along with, most importantly, providing popup magic!) and not bogging you down in every little detail needed to prove total correctness.

> But is it wrong? Yes, because people don't "not often ship code in statically typed languages". It's obviously wrong.

I think you're taking offense on behalf of Java when the paragraph is dragging Haskel and Rust.

Re: The Grug Brained Developer (2022)

#159

Post by mmmm2 »

Defletter wrote: post #111
lawn wrote: post #96

Earlier quoted context omitted.

My hobby projects are always over-engineered despite my best efforts. There's absolutely no monetary incentives here so anecdotally I agree with you.

Yup, but it goes both ways. I end up over-eningeering as some feeble attempt to avoid technical debt, only to realise my over-eningeering /is/ the technical debt. Or I end up with relatively simplistic / specialised code that needs an entire rewrite and migration process any time something is added. Either way, it's a bunch of rewritten code mixed with paralysing anxiety about writing bad code.

I think we as developers underestimate the value of a 100 line Python script. Everything could be hard coded and inflexible, but it's still easy to refactor because you can keep the whole thing in your head.

"Bad" design can be fine if it's kept simple.

Re: The Grug Brained Developer (2022)

#160

Post by Spivak »

Mikhail_Edoshin wrote: post #133

If you need nuanced behavior, you need a complex controller. And you always need more nuanced behavior, this is the inherent nature of software development. Sometimes the appearance of simplicity is achieved by making the behavior simpler (e.g. dropping the support for old versions, not implementing parts of the specification, and so on). This is degradation, not simplicity. The right simplicity is an art of having t…

i don't think grug actually disagrees with you here but takes the position that skill both can't be counted on and doesn't scale.

And this matches my own dev experience cathedrals of complexity pale into comparison that code that's easy to throw away and rewrite to meet changing requirements or scope.

Post reply on HN