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

A Theory of Software Architecture

danuker.go.ro

Post reply on HN
Print view View original

221–230 of 246 posts

Re: A Theory of Software Architecture

#221

Post by RangerScience »

AnimalMuppet wrote: post #180
jhardy54 wrote: post #173

Earlier quoted context omitted.

> Use mostly functions, try to make most of them pure. This reminds me of: > Eat food, not too much, mostly plants > > -- Michael Pollan My new mantra: Write software, not too much, mostly functions.

"Not too much" is interesting. If I understand you correctly, you can write "too much software". I can think of at least three ways - bad architecture, too little abstraction forcing repetition, and just bad writing. Did you have something else in mind here?

I would definitely add "too many features". You can do a really good job building something way too large and you've built too much.

Re: A Theory of Software Architecture

#222

Post by RangerScience »

AnimalMuppet wrote: post #200
asimpletune wrote: post #192

Earlier quoted context omitted.

I think more likely is to actually have too much abstraction.

Either can be a problem. Too much abstraction and you're writing FooFactoryFactoryFactory. Too little, and you're repeating yourself. Somewhere between the extremes is a sweet spot. The problem is that, as the project continues over time, the sweet spot moves...

Nah. It's always about 4 layers. Hardware/services/data stores/etc, wrappers/models/components, business logic / application, ops/deploy.

If you nest your models/components deep enough that they're forming new abstraction layers, you're nesting them too deep. Backup and use mixin-style stuff instead.

If your business logic or application are nesting pretty much at all, then you haven't succeeded at making good choices in your models/components.

Re: A Theory of Software Architecture

#223

Post by yokto »

cies wrote: post #51
speedgoose wrote: post #32

I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…

I find the Multitier Arch (MA) has much better names. The arch proposed by the article has "Application Business Rules" (ABRs) and "Enterprise Business Rules" (EBRs). Now in a small start-up, what are the "enterprise rules", is "enterprise" not merely a buzzword in this context? And how ABRs and EBRs differ is not well explained. In MA this is much clearer: the Data Access Layer (DAL) contains DAOs (the persistence s…

I've always been confused by the Clean Architecture and even somewhat dismissive, because the terms used are so "not Clean" (from my perspective biased towards startup/indie/freelance). Multitier Arch is already 10 times more appealing just by using more appropriate words.

Re: A Theory of Software Architecture

#224

Post by justincredible »

irjustin wrote: post #85

Along the same lines as the article, I've started thinking about internal code as ETL - all code. There is some faucet, transformation and then a sink. Only at the sink does external state get mutated. It helps because transformations can be closer to pure functions and you know there is no state changes until you've hit the sink/loader. Not sure yet, I haven't concluded it's the right way for me, as it has saved a f…

Idempotent means feeding the output back in as the input will result in the same output. It might require purity, but is conceptually distinct.

For example, boolean negation is a pure function as it depends only its input and has no side-effects, but it's not idempotent since: not(not(var)) != not(var)

Re: A Theory of Software Architecture

#225

Post by necovek »

oaiey wrote: post #84
necovek wrote: post #15

Earlier quoted context omitted.

Generally, to those of us who apply the functional approach everywhere, it comes naturally whatever the problem. There are idiomatic ways to program in particular languages (even in Python or JavaScript) which are strictly against the functional approach, even though nothing in those languages prohibits it. It gets trickier with external dependencies which are "forced" on you too. Do you have a concrete "domain" exam…

A shadow DOM. A state manager ;). A protocol implementation which needs state. There are cases where the domain has state. Like said, typically, for request/response cases which is 90% of everything we program nowadays, this state is typically loaded from somewhere else. I am also not particular arguing for OOP here. It is just the absolutism which are an issue.

A DOM is a huge hierarchical data structure and not much else (sure, it has function pointers too, but that's pretty much it).

You can easily turn things into substructures and have functions only work on those: whether you pass by reference or value is up to you and your choice of language, but even when passing by reference (to avoid memory copying), you can write functional code.

Again, it sure is non-idiomatic for most languages, but that does not mean it's impossible or even hard.

As far as "absolutism", generally, aiming for minimal statefulness will help you write more maintainable code (citation missing :).

Re: A Theory of Software Architecture

#226

Post by necovek »

tarruda wrote: post #108
necovek wrote: post #20

Earlier quoted context omitted.

I think it only requires a change of mindset for a developer. Learning TDD truly will usually lead to functional code, even if you do not write your tests first. Eg. I can't imagine what would be hard for a MS Paint clone to achieve using this approach. There are always things with side-effects (IO, namely), agreed, but in this CRUD example, the integration bits are coupled in a way where you need a single trivial in…

> Any concrete things where you think you can't apply it? I'd say that you can apply it mostly everywhere, however it is not friendly to most people that will maintain the code, and that is a problem since most software will have many maintainers over its lifetime. This reply to another comment I made on this thread should elaborate a bit more: https://news.ycombinator.com/item?id=24917764

Oh sure, there's always going to be some friction! So let me go on a tangent here.

While the current education system is geared toward procedural programming for the most part (I imagine mostly theoretical computer science curriculums only focus on functional programming and lambda calculus too, but even then, only very late and very theoretical), the question is more of whether it is a better approach when applied "universally" (with non-functional languages, it's unlikely to be really pure)?

If deemed that it is, functional proponents like me (and you, it sounds like) should push for it to get a better coverage in Universities than eg. OOP, even for OOP languages. Most academia is out of the software industry, so should we educate them or not? And how best to do that if the answer is yes?

I do have a worry that some of it is also incomprehensible to some people, or that the barrier to entry is higher. Is such purity more reserved for those that also like mathematical abstractions?

Now, the biggest problem I have with colleagues reviewing my code is that it seems too-simple, and they would have introduced another 2 layers of indirection/abstraction, but they can't really say that anything is wrong with my approach. It's really hard to get them to jump out of their "OOP bubble".

The code is easy to maintain, but there is a big risk that someone will pop in and just turn it into one big side-effect mess that will be hard to maintain. But then again, that's what they would have done anyway, this has at least some chance of not becoming that :)

Re: A Theory of Software Architecture

#227

Post by asimpletune »

RangerScience wrote: post #222
AnimalMuppet wrote: post #200

Earlier quoted context omitted.

Either can be a problem. Too much abstraction and you're writing FooFactoryFactoryFactory. Too little, and you're repeating yourself. Somewhere between the extremes is a sweet spot. The problem is that, as the project continues over time, the sweet spot moves...

Nah. It's always about 4 layers. Hardware/services/data stores/etc, wrappers/models/components, business logic / application, ops/deploy. If you nest your models/components deep enough that they're forming new abstraction layers, you're nesting them too deep. Backup and use mixin-style stuff instead. If your business logic or application are nesting pretty much at all, then you haven't succeeded at making good choice…

Agreed, and I’d add that code duplication is hardly a big problem. It’s kind of like if I legitimately see a lot of code duplication, then I have enough data points to do the right thing. On the other hand, abstracting early to avoid code duplication is worse.

Re: A Theory of Software Architecture

#228

Post by peterwwillis »

rvense wrote: post #126
peterwwillis wrote: post #97

Earlier quoted context omitted.

The former example was much easier for me to understand than the latter, even if it wasn't factored well. But I'm assuming that the functions aren't mucking about with global state or something equally distasteful.

Well, if we assume that both are doing the same work, then the explicitly named variables y, foo, and bar of my second example would, in the first example, have to be global variables, or at least things that are defined in the scope of the definition/call of x. Given that, I have to say that I, err, and I'm sorry if this sounds a little arrogant, but I don't really believe you when you say that it's easier to unders…

I don't really fully understand how the kernel scheduler works, but I know in general how it works, and so I can write software using it. In this sense, a simple implicit abstraction is easier for me to understand than one where I'm peeking under the covers, so to speak.

Even just seeing a few variables or objects passed around, I still don't know exactly what it's doing, or hiding. I can more quickly understand the high level idea with the former example without the details potentially confusing me.

Re: A Theory of Software Architecture

#229

Post by peterwwillis »

skinkestek wrote: post #102
peterwwillis wrote: post #97

Earlier quoted context omitted.

The former example was much easier for me to understand than the latter, even if it wasn't factored well. But I'm assuming that the functions aren't mucking about with global state or something equally distasteful.

> But I'm assuming that the functions aren't mucking about with global state or something equally distasteful. It seems fairly obvious to me that either the former example is waaaay simpler or it is doing something really distasteful.

Some designs don't require your own code to pass around state between functions, because each function can handle state in its own way without dependence on other functions. I've written a lot of such simple scripts where I just need to execute a series of tasks that aren't necessarily related to one another, but do follow each other.

Re: A Theory of Software Architecture

#230

Post by RangerScience »

asimpletune wrote: post #227
RangerScience wrote: post #222

Earlier quoted context omitted.

Nah. It's always about 4 layers. Hardware/services/data stores/etc, wrappers/models/components, business logic / application, ops/deploy. If you nest your models/components deep enough that they're forming new abstraction layers, you're nesting them too deep. Backup and use mixin-style stuff instead. If your business logic or application are nesting pretty much at all, then you haven't succeeded at making good choice…

Agreed, and I’d add that code duplication is hardly a big problem. It’s kind of like if I legitimately see a lot of code duplication, then I have enough data points to do the right thing. On the other hand, abstracting early to avoid code duplication is worse.

Hmm... I think you might be right. Or, at least, that the problem that is and the problems that go with code duplication are easier to resolve than those that show up with shit abstraction.

Maybe... Duplication is a code smell, but shit abstraction is a code problem...?

Post reply on HN