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

171–180 of 201 posts

Re: The Grug Brained Developer (2022)

#171

Post by mrkeen »

hitchstory wrote: post #162
mrkeen wrote: post #156

Earlier quoted context omitted.

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.

Nice and clean in the context of an integration doesn't mean no state it just means no state outside of the context of that test. If I set up an integration test that sets up a database from scratch and tears it down and tests only the behavior of the app in that rigidly defined context, then yes, it will be useful. It will tell you how the code behaves in the scenario you've created. Bad integration tests will share…

That's precisely what I meant by my comment. The 'cleaner' the integration test, the less it will behave like the real-world system.

> Bad integration tests will share state with each other

The real-world system shares state.

> If I set up an integration test that sets up a database from scratch and tears it down and tests only the behavior of the app in that rigidly defined context

... constructing a particular set of circumstances which will never occur in the real-world system.

Re: The Grug Brained Developer (2022)

#172

Post by ketzo »

pphysch wrote: post #89
kirse wrote: post #37

Earlier quoted context omitted.

everyone is going to get on the HTMX wagon This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib... I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skip…

HTMX is pretty much feature complete though.

Wars have been won and kingdoms lost in the space between “pretty much” and “complete”

Re: The Grug Brained Developer (2022)

#173

Post by ragnese »

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.

It's just a joke. I'm almost certainly one of the people he's poking fun at and I don't think we should get bent out of shape. He obviously thinks that C or Java levels of static typing are fine/good, and thinks that fancier stuff like found in Rust and Scala is a waste of time. I think he's dead wrong, but that's life.

Re: The Grug Brained Developer (2022)

#174

Post by ChrisMarshallNY »

jongjong wrote: post #6

It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…

I'm not really a fan of the term "overengineered." I often find it is a direct translation of "Something I don't understand quickly."

In my experience (including my own development), overly complex designs accrete, as opposed to start off complex.

They usually seem to begin with "This is simple, let me just do this...", then, when we run into Roadblock A, we design in a mitigation, and so on...

Eventually, we have a ghastly chimera.

Other times, it comes from trying to coerce software written for one purpose, into another, and the glue code is kinda messy.

Also, there was an article mentioned here, about "Don't design a general-purpose framework."

I can concur with that. The app I'm releasing now, has a server component that is, in my opinion, way too complex. I designed it, and implemented it, so I get to say that.

The deal was that I originally developed it as a general-purpose framework. It has a layered architecture, and I did heavy-duty unit testing of each layer, as I was writing it.

It works very well, is fast, and secure.

But way too complex, as this app is its only implementation. It handles a lot of stuff this app never touches, like trees of user permissions. I have a very simple, rather "flat" permission structure, so a whole shitton of code never gets used. It was tested heavily, works well, but will never be used. I don't like having unused code paths, but I don't have the luxury of time to remove it (I have removed some, but there's plenty more, where that came from).

If I were to rewrite it (I won't -see "works very well", above), it would be much simpler.

Re: The Grug Brained Developer (2022)

#175

Post by greenie_beans »

bredren wrote: post #93
jauntywundrkind wrote: post #74

Earlier quoted context omitted.

Ah! Carson Gross is author of grug brained developer, and htmx! I'd love to see some real critiques of htmx. Personally I think the web's big ongoing challenge has been figuring out how to update the page well, and we keep trying all kinds of attempts. That causes fatigue, and some of the ideas are wild or grow crufty over time. Htmx seems like a back-reaction, to insist on grug brained less/YAGNI. And even though th…

Some critiques focus on the developer insecurities that make them vulnerable to HTMX's charms: - Writing Vanilla JS ES6+ is not that hard, actually it is pretty fun. - Toolchain for JS/TS/CSS was bad but is pretty good now. esbuild is simple and great. - Dodging learning the above two things does not serve the dev. Others have to do with foundational aspects of the project: - HTMX is in denial of need to support nati…

> Writing Vanilla JS ES6+ is not that hard, actually it is pretty fun.

i like vanilla es6 too. i've enjoyed using it with htmx, rather than using intercooler or alpine.

Re: The Grug Brained Developer (2022)

#176

Post by [deleted] »

gemstones wrote: post #104
jauntywundrkind wrote: post #74

Earlier quoted context omitted.

Ah! Carson Gross is author of grug brained developer, and htmx! I'd love to see some real critiques of htmx. Personally I think the web's big ongoing challenge has been figuring out how to update the page well, and we keep trying all kinds of attempts. That causes fatigue, and some of the ideas are wild or grow crufty over time. Htmx seems like a back-reaction, to insist on grug brained less/YAGNI. And even though th…

The best critique of HTMX is the same critique of Rails + partials + a bit of helper JS for inserts (the popular stack that predates modern SPAs.) Say you’re writing a true web app. You’re making a mobile view, and the user has scrolled down and loaded some items (and partially inserted them as the scroll bar has moved down.) They add a card representing a few items to a cart, which 1. changes the look of the card an…

[deleted]

Re: The Grug Brained Developer (2022)

#177

Post by n4r9 »

dryanau wrote: post #137
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…

I'm confused. The original article is in favour of typed languages. Aren't you in agreement?

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.

Re: The Grug Brained Developer (2022)

#178

Post by hitchstory »

mrkeen wrote: post #171
hitchstory wrote: post #162

Earlier quoted context omitted.

Nice and clean in the context of an integration doesn't mean no state it just means no state outside of the context of that test. If I set up an integration test that sets up a database from scratch and tears it down and tests only the behavior of the app in that rigidly defined context, then yes, it will be useful. It will tell you how the code behaves in the scenario you've created. Bad integration tests will share…

That's precisely what I meant by my comment. The 'cleaner' the integration test, the less it will behave like the real-world system. > Bad integration tests will share state with each other The real-world system shares state. > If I set up an integration test that sets up a database from scratch and tears it down and tests only the behavior of the app in that rigidly defined context ... constructing a particular set…

>... 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 find that well engineered integration tests are usually able to reproduce 90% of bugs sourced from production while unit tests can often manage only 10 or 15%. Bug in the SQL? Browser is involved? No can do.

Re: The Grug Brained Developer (2022)

#179

Post by vasergen »

josephg wrote: post #9
jongjong wrote: post #6

It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…

I struggle with this constantly. I think there are two problems: 1. I like interesting puzzles. A lot of code - especially commercial code - is pretty boring if you do it right. I find myself subconsciously pushing for features that will be fun to implement. And by "fun", I mean, features that will overcomplicate everything. 2. While I'm in the middle of programming something, all the choices that I make seem straigh…

> A lot of code - especially commercial code - is pretty boring if you do it right.

That is a very good point. If your code doesn't look boring, then you probably doing something wrong.

Re: The Grug Brained Developer (2022)

#180

Post by randomdata »

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.

Is it? When was the last time you saw, say, Coq in the wild? If you ever saw it you can be certain the program is correct, but I certainly have never seen it. Most likely because anyone using it really is still trying to satisfy the type checker.

Clearly type systems live on a spectrum with varying degrees of sacrifices made, with each sacrifice compromising some ability to check for correctness, but giving back some other advantage, improved developer productivity being one possibility.

It is not a question of static typing or not – it is how complicated of a type system do you really need? Even Grug agrees that dynamic typing is not sufficiently complicated for most circumstances, but maybe a primitive static type system somewhere in the middle of the spectrum that helps catch the most grievous of errors (and provides popup magic!) with a sprinkling of automated testing to fill in the gaps where the type system falls short is good enough?

Post reply on HN