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

Software Architecture Guide

martinfowler.com

Post reply on HN
Print view View original

291–300 of 303 posts

Re: Software Architecture Guide

#291

Post by hyperpallium »

eitland wrote: post #288
blub wrote: post #284

Earlier quoted context omitted.

A philosophical book of essays about software from 1975 is not relevant for a set of recommendations on architecture 44 years later. You are correct that chapter two lacks supporting evidence. And that's a problem for the book, it doesn't mean it's ok to omit data everywhere now.

I seems to me that you and hyperpallium agree. I still hold that 1.) That book is still one of the most relevant books I've seen lately (which might be scaring, I haven't made up my mind yet) 2.) While he might not have (or at least not include) data, he argues hos case well, and while I wouldn't bet money on experiments to follow his smooth curve I would be willing to bet (a small amount of) money that for non-trivi…

Let's be clear: I think (i) the book is great and (ii) your rude and inaccurate comment was not.

(i) I said:

> It's still great though

(ii) I said:

> lacks data

You replied:

> It is the computer book with most tables pr page of any I have seen.

> How you come to this conclusion is beyond me.

In case you were wondering, this is the part where you apologize handsomely.

Re: Software Architecture Guide

#292

Post by hyperpallium »

naasking wrote: post #280
hyperpallium wrote: post #272

Earlier quoted context omitted.

I'm interested. Could you elaborate on "most compilers", with a specific compiler, and how it is "engineered"? Although much care and thought goes into compilers, and they are related to discrete mathematical models (though, more descriptive than prescriptive for hand-written recursive descent parsers; unlike the central PDEs in some engineering), there is much tweaking for efficiency and especially for helpful error…

CompCert is the most extreme example of course given it's fully verified and the strictness required entails a high level of attention to details. Almost every compiler will be based on graph or tree transforms; Haskell and Rust are both engineered around reduction to intermediate, lower-level languages. I don't think the tweaks you mention necessarily negate the core engineering, unless the system is completely unus…

Thanks, I was thinking of more used languages, such as c, python, java, javascript (they'd have greater need of good engineering, wouldn't they?).

I don't know Haskell or Rust well enough to appreciate their compiler engineering (and haven't heard of CompCert). But I might have a look at their source - I have a long-term project about tree transforms ATM and hadn't thought of looking at what compilers do (even though I was aware of Knuth's attribute grammars).

Yeah, nah, I think your "core operation" is a reasonable definition, both as primary function, and as the basic design (despite crafted tweaks atop).

Re: Software Architecture Guide

#293

Post by proc0 »

jammygit wrote: post #167
proc0 wrote: post #157

Earlier quoted context omitted.

Of course it can be quantified otherwise hiring based on skill level for a software role would be impossible. You can look a examples of code and know someone's level and then deduce their performance based on output and quality of code. The problem is NON-technical people are the ones who want to quantify your performance! Which has been my problem for years in the software industry. If you haven't written code in y…

The standard practice is to quiz based on algorithms and data structures. How is that quantifying anybody’s performance? I knew a smart young algorithms guy once who could solve anything, but he still liked storing all his data in the global scope until he was told to stop it.

Yeah now that I think more about it, those quick tests say nothing about a candidate. It's definitely harder than it seems.

Re: Software Architecture Guide

#294

Post by blub »

eitland wrote: post #288
blub wrote: post #284

Earlier quoted context omitted.

A philosophical book of essays about software from 1975 is not relevant for a set of recommendations on architecture 44 years later. You are correct that chapter two lacks supporting evidence. And that's a problem for the book, it doesn't mean it's ok to omit data everywhere now.

I seems to me that you and hyperpallium agree. I still hold that 1.) That book is still one of the most relevant books I've seen lately (which might be scaring, I haven't made up my mind yet) 2.) While he might not have (or at least not include) data, he argues hos case well, and while I wouldn't bet money on experiments to follow his smooth curve I would be willing to bet (a small amount of) money that for non-trivi…

I don't have an opinion on the book, I read it too long ago and just skimmed chapter 2 now. I don't think it's comparable with or relevant for this blog post.

hyperpallium's original message, the one that started this thread is a feeble attempt at legitimizing the blog post by comparing it to a bunch of unrelated and generally appreciated things.

Re: Software Architecture Guide

#295

Post by camgunz »

goto11 wrote: post #290
camgunz wrote: post #282

Earlier quoted context omitted.

I mean I quoted the entire 3 paragraphs up there, so of course I'm paraphrasing. Fowler advocates strongly for OOP. Presumably he'd find an OO entity system clearer (if you're gonna quibble with this, imagine how much more productive this conversation would be if we had an understanding of what "clearer" meant, then recoil in horror as you realize thousands of developers are having this exact same unproductive discus…

> I do, weirdly, feel a little like you're not applying the principle of charity to me though. Fair enough, we can all be guilty of that. What part of your argument have I misunderstood or misrepresented?

I think I've pretty directly disagreed with:

> focus on clarity first and only optimize for performance if absolutely necessary

I think that in a lot of very important, very common use cases (take your pick: game engines, embedded programming, OS development, language runtimes, linear algebra libraries, etc. etc. etc.) this is extremely bad advice. It's... probably good advice for enterprise applications; but that's a pretty small subset of all software. I think that if you start with clarity here and do performance optimization after the fact you will build something that can't be used as intended--almost always (of course, not "alwaysly", see Python).

More broadly, I think this is a far too narrow way of looking at "clarity" vs. "performance". I have some idea of what I think clarity is, and I have some idea of what I think performance is, and they're both pretty nuanced and deep topics. I think they're two big bags of variables in an even larger bag of engineering variables, and I think Fowler does us all a huge disservice when he skips that entire discussion with what is your synopsis up top there. Maybe you're writing Python and you need a certain level of dynamic nature in order to reach your desired level of flexibility and clarity. That can be fine! The point here is that these are rich topics, and they deserve better than what I see as a pretty blithe dismissal.

Re: Software Architecture Guide

#296

Post by extra_rice »

Spearchucker wrote: post #256
lonelappde wrote: post #221

Earlier quoted context omitted.

You wouldn't send a business rule from a web page, you'd put it in the domain model on the server. The web page has a UI model, not a domain model.

That's the point. And yet Fowler objects because it violates encapsulation and information hiding, because it requires a service layer and makes a model less expressive.

You can easily serialise a well fleshed out (i.e. non-anemic) object. Does the view layer in this particular example need to know the encapsulated business rule? In my experience, not usually. Otherwise, there's most likely a problem with responsibilities. And when that data comes back from the UI, it's also relatively easy to reconstitute it back to well fleshed out objects.

Re: Software Architecture Guide

#297

Post by [deleted] »

camgunz wrote: post #295
goto11 wrote: post #290

Earlier quoted context omitted.

> I do, weirdly, feel a little like you're not applying the principle of charity to me though. Fair enough, we can all be guilty of that. What part of your argument have I misunderstood or misrepresented?

I think I've pretty directly disagreed with: > focus on clarity first and only optimize for performance if absolutely necessary I think that in a lot of very important, very common use cases (take your pick: game engines, embedded programming, OS development, language runtimes, linear algebra libraries, etc. etc. etc.) this is extremely bad advice. It's... probably good advice for enterprise applications; but that's…

[deleted]

Re: Software Architecture Guide

#298

Post by eitland »

hyperpallium wrote: post #291
eitland wrote: post #288

Earlier quoted context omitted.

I seems to me that you and hyperpallium agree. I still hold that 1.) That book is still one of the most relevant books I've seen lately (which might be scaring, I haven't made up my mind yet) 2.) While he might not have (or at least not include) data, he argues hos case well, and while I wouldn't bet money on experiments to follow his smooth curve I would be willing to bet (a small amount of) money that for non-trivi…

Let's be clear: I think (i) the book is great and (ii) your rude and inaccurate comment was not. (i) I said: > It's still great though (ii) I said: > lacks data You replied: > It is the computer book with most tables pr page of any I have seen. > How you come to this conclusion is beyond me. In case you were wondering, this is the part where you apologize handsomely.

Can you explain what is rude?

I am not a native speaker so I just looked up the phrase you seem to point to and the two first definitions says it means:

- Very difficult for one to comprehend or do.

- not something that I can understand

Am I missing something here?

Besides, I feel you moved the goal posts early on. I replied to you talking about the whole book, you replied with a single example.

Please let me know if I've missed something.

Re: Software Architecture Guide

#299

Post by inopinatus »

Chris2048 wrote: post #278
inopinatus wrote: post #264

Earlier quoted context omitted.

I don’t reward sealioning.

> Sealioning is a type of trolling or harassment which consists of pursuing people with persistent requests for evidence or repeated questions Asking what you mean by what you wrote in a public discussion forum isn't seasoning. You aren't being asked for evidence for you opinion, but what that opinion is , and the context of a discussion forum implies you mean to discuss the topic. Also, I can't see the "persistence"…

I looked at the correspondent’s other posts in the same thread. They qualified.

Re: Software Architecture Guide

#300

Post by inopinatus »

blub wrote: post #287
inopinatus wrote: post #264

Earlier quoted context omitted.

I don’t reward sealioning.

All right, but if we take the standard definition of philosophy then your initial claim makes no sense. The study of the fundamental nature of knowledge, reality and existence is unrelated to writing software.

When I build applications the questions of “What is truth?” “What is the essence of a thing?” “What is useful?” are top-of-mind throughout, because there’s no rigour without context and purpose.

Software development is applied philosophy. Wittgenstein would’ve been good at it.

Post reply on HN