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

Firewalling your code

lackofimagination.org

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Firewalling your code

#71

Post by eithed »

wokwokwok wrote: post #56
acc4everypici wrote: post #38

Earlier quoted context omitted.

modules? crates??? uhmm... namespaces??? I think you're conflating the language design stuff with the tooling (packaging, and calling that 'modules') ....to be fair, you're conflating but I'm fanboying python in any case, the point being there's a distinction between an linker and a compiler but not in interpreted languages. so comparing rust's crates with JS, python (even java) is an instance of apples-to-oranges co…

Maintaining boundaries in your code is something you can do in any language, regardless of built-in support in the language or tooling. Ironically, untyped languages like js and python are particularly prone to the problems from poor unstructured code, because you can't use static type checking to find broken dependencies at compile time. /shrug

Can you explain how types would help with code structure? From experience, even with typed TS nothing prevents developers from creating a big ball of mud

Re: Firewalling your code

#72

Post by marcosdumay »

wokwokwok wrote: post #52
actionfromafar wrote: post #24

Earlier quoted context omitted.

Do you mean that if the constraints are visible when you change the code, it's better? But "hidden" constraints which will manifest only under specific conditions under runtime are bad.

I suppose. Abstractly: A constraint is an invariant that must be true before and after the change. It doesn't matter if they are 'hidden' or 'visible'; if you must maintain the existing behavior , then you have to prove that no constraints are violated by the change you make. The effort you have to expend is proportional to the number of places where you have invariant that must be maintained. However. If you isolate…

> Since the volume is always >= the surface

You'll find out that analogies to Euclidean geometry do not hold for software structure in general.

That's a nice heuristic though. Just be wary that if you follow it blindly, you will inevitable optimize things into a counterexample where everything breaks down while your proof still finds it's the optimal.

Static analysis is good, in moderation; dynamic validation is good, in moderation; accepting errors and dealing with them is goo, again, in moderation. All of those things turn bad if you do them out of dogma.

Re: Firewalling your code

#73

Post by mattgreenrocks »

ChrisMarshallNY wrote: post #68
mattgreenrocks wrote: post #67

Earlier quoted context omitted.

Assuming reasonable factoring, maintenance is only a problem when trying to seriously cheat the layers, eg your controller wants to modify the template engine’s internals for a single request. Better to just be honest about it by punching a hole in the abstraction that is appropriately named and using that.

No cheating! For example, I stop creating SQL, after the first layer above the DB access layer. Everything above that, is a function-based abstraction, so there's no SQL, in most of the stack. Some layers are meant to introduce "replacement points," so you could swap out the SQL for a NoSQL solution, if you want. Most layers have a fair bit of validation and permission-checking, etc. But making sure that I stick to t…

Yes, this is the way. But I'm fine with short-term cheating when there's no other way because it sticks out a lot more:

"wtf, why is the registration endpoint executing hand-written SQL but no other endpoint is?"

The fact that it ends up looking conceptually ugly compared to everything else means it is harder to ignore, and people have to justify their sloppiness when getting it merged.

> But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway.

It can be. I've found you usually internalize the rules eventually and your mind naturally slots things where they need to go. Then you can aggressively add features/refactor because the surface area is much smaller.

It's like learning to work with strong type systems versus fighting them.

Re: Firewalling your code

#74

Post by marcosdumay »

ChrisMarshallNY wrote: post #19

I've worked like this for decades. Layers, with each layer assigned a particular domain and API restriction (for example, I have a multi-layer backend, and, if I want to access the database directly, I need to implement that at the very lowest layer, and then set up a "tunnel" of access to the top-layer exposed API, through the intervening layers, applying whatever access control and filters are appropriate for each…

> Layers, with each layer assigned a particular domain and API restriction

Yeah, that's not a good way to do it.

You can only keep adding layers if they are platonic. If they represent any real-world domain, they will interfere with each other, your abstraction will leak, and every change will require changing everywhere.

Re: Firewalling your code

#75

Post by _cenw »

JonChesterfield wrote: post #8
_cenw wrote: post #5

Always feels like you're in a dysfunctional place when you have to program this defensively. I had an acquaintance who was writing library code for a few dozen data engineers in python, and she had to resort to locking down private methods by checking the call stack after engineers repeatedly got hold of private objects, or objects that are only there sometimes (e.g. when not running clustered). I adopted a similar s…

"I monkey patched your code and now it doesn't work" would be a deeply irritating bug report. It's directly equivalent to "I forked your codebase, changed the text files, and now it doesn't work".

This was the kind of place where data engineers would ask an LLM for config options (for the framework that was built internally) and then complain they didn't work. No idea how these people got by and even made more than the person writing the framework.

Re: Firewalling your code

#76

Post by layer8 »

IMO the better way to handle this is to statically determine the Dependency Structure Matrix of all modules and to have a linter in the build process that checks that the dependencies conform to the restrictions you want to impose.

Re: Firewalling your code

#77

Post by chipdart »

wokwokwok wrote: post #15

It’s probably over the top, although I respect the intent. The quickest way to destroy “velocity” is by introducing dependencies between implementation details with no barriers in code. The more constraints you have to satisfy when you make changes, the more effort it is to make the changes (provably); and thus, the more time it takes, destroying velocity. That said, doing this as described is probably overly dramati…

> The quickest way to destroy “velocity” is by introducing dependencies between implementation details with no barriers in code.

Nonsense.

The biggest velocity killer is having to deal with the technical debt left behind by those who mindlessly commit changes that turn your software into a big ball of mud.

Ask yourself this very simple question: why did your team felt the need to add these constraints? What classes of problems they were avoiding by preventing specific types of changes to the software architecture from being applied? What problems they experienced earlier that motivated them to ensure they wouldn't experience them again?

And why should your laziness to do things the right way take priority over avoiding making the same mistake?

Re: Firewalling your code

#78

Post by chipdart »

marcosdumay wrote: post #72
wokwokwok wrote: post #52

Earlier quoted context omitted.

I suppose. Abstractly: A constraint is an invariant that must be true before and after the change. It doesn't matter if they are 'hidden' or 'visible'; if you must maintain the existing behavior , then you have to prove that no constraints are violated by the change you make. The effort you have to expend is proportional to the number of places where you have invariant that must be maintained. However. If you isolate…

> Since the volume is always >= the surface You'll find out that analogies to Euclidean geometry do not hold for software structure in general. That's a nice heuristic though. Just be wary that if you follow it blindly, you will inevitable optimize things into a counterexample where everything breaks down while your proof still finds it's the optimal. Static analysis is good, in moderation; dynamic validation is good…

> Static analysis is good, in moderation;

Care to point out your best example on when static code analysis ceases to be good?

I don't think there is possibly any copout to justify away the benefits of static code analysis. Either your code works by complying to the interface, or it doesn't and violates interfaces. The only thing static code analysis does is force you to acknowledge the real interfaces.

Re: Firewalling your code

#79

Post by marcosdumay »

chipdart wrote: post #78
marcosdumay wrote: post #72

Earlier quoted context omitted.

> Since the volume is always >= the surface You'll find out that analogies to Euclidean geometry do not hold for software structure in general. That's a nice heuristic though. Just be wary that if you follow it blindly, you will inevitable optimize things into a counterexample where everything breaks down while your proof still finds it's the optimal. Static analysis is good, in moderation; dynamic validation is good…

> Static analysis is good, in moderation; Care to point out your best example on when static code analysis ceases to be good? I don't think there is possibly any copout to justify away the benefits of static code analysis. Either your code works by complying to the interface, or it doesn't and violates interfaces. The only thing static code analysis does is force you to acknowledge the real interfaces.

Hum... You mean you've never encountered complex interfaces dictated by their types?

I was about to make a Haskell joke, but it's actually Java that is most famous for this. There are lots of "enterprise Hello-Word" published on the internet if you want some done on purpose.

Re: Firewalling your code

#80

Post by chipdart »

marcosdumay wrote: post #79
chipdart wrote: post #78

Earlier quoted context omitted.

> Static analysis is good, in moderation; Care to point out your best example on when static code analysis ceases to be good? I don't think there is possibly any copout to justify away the benefits of static code analysis. Either your code works by complying to the interface, or it doesn't and violates interfaces. The only thing static code analysis does is force you to acknowledge the real interfaces.

Hum... You mean you've never encountered complex interfaces dictated by their types? I was about to make a Haskell joke, but it's actually Java that is most famous for this. There are lots of "enterprise Hello-Word" published on the internet if you want some done on purpose.

> Hum... You mean you've never encountered complex interfaces dictated by their types?

I asked you what you personally believe is your best example on when static code analysis ceases to be good. I fail to see how anyone's opinion or personal experiences determine your own personal opinion on a subject.

Can you provide any example on how static code analysis can be anything other than a good thing?

> There are lots of "enterprise Hello-Word" published on the internet if you want some done on purpose.

I'm sorry, what does this have to do with static code analysis?

Post reply on HN