Shameless plug of my 2012 blog post where I demonstrate The Clean Architecure for Go applications: https://manuel.kiessling.net/2012/09/28/applying-the-clean-a...
Thank you! You have gone much deeper.
A Theory of Software Architecture
201–210 of 246 posts
Re: A Theory of Software Architecture
#202Another "academic level" demonstration that doesn't work in practice. It's so simple to say "look how awesome this approach is" on a 50 line program, "just use pure functions everywhere". In real life things get very complex because there are 200 working parts interconnected. And not because "it's bad design". But because that is the requirement. Soon you get pure functions with tons of parameters or parameters that…
Sure, real life programs are very complex. But that doesn't stop you from testing and refactoring whatever local point you need to touch, so that you can get the job done easier.
My hunch is that moving pure-functions and pure-objects out of the spaghetti will gradually eat away at the spaghetti.
Re: A Theory of Software Architecture
#203Stop calling this theory. This isn't theory. This is just rules of thumb and an opinion.
You want actual theory? Here's theory:
Re: A Theory of Software Architecture
#204Stop calling this theory. This isn't theory. This is just rules of thumb and an opinion. You want actual theory? Here's theory: http://www4.di.uminho.pt/~jno/ps/pdbc.pdf
It's theory in the analytical/interpretive sense, not the empirical scientific sense.
Re: A Theory of Software Architecture
#205Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
It's not just pure functions. Two things break modularity: Free variables and mutation.
The problem with OOP is that no method is truly pure, no method is a combinator.
class Thing
var memberVar
def addOne():
return memberVar+1;
You can use static functions but the static keyword defeats the purpose of a class and makes the class equivalent to a namespace containing functions.
class Thing
static def add(x):
return x + 1;
namespace Thing:
def add(x):
return x + 1;
Use namespaces and functions when all you have are pure functions and use classes when you need internal state... there is literally no point for OOP if you aren't using internal state with your classes.
Re: A Theory of Software Architecture
#206Earlier quoted context omitted.
This reminds me of Brian Will's "Object-orientation is Bad" where he makes the case that most decoupling tends to be more confusing than long-form code that's got sufficient comments. https://youtu.be/QM1iUe6IofM?t=2235
I hate unnecessary functions with a passion and it's refreshing to hear his opinion. Sometimes a big, fat block of code is just easier to understand.
If you have a well documented system, OWNED by a software architect, then breaking it down is better.
If you don't have that, at least big fat blocks of code are self documenting...
Re: A Theory of Software Architecture
#207Earlier quoted context omitted.
> Sometimes a big, fat block of code is just easier to understand. John Carmack made once the same comment: http://number-none.com/blow/blog/programming/2014/09/26/carm...
> I don’t think that purely functional programming writ large is a pragmatic development plan, because it makes for very obscure code As a functional programming enthusiast, I agree with this. Recently I worked on rewriting a relatively large backbone web application in React/Redux (For those that don't know, Redux is a framework for writing JS in a more functional style). While moving all app logic to functional sty…
That's because JS is not a functional language. You are enforcing a functional style by discipline. Additionally a huge portion of benefits of the functional style are lost on untyped languages. If you're not using typescript you're dealing with a lot of unnecessary bugs.
If you guys moved to a fully functional paradigm where the language enforces the functional style you will see greater benefits.
Unfortunately for the front end the ecosystem for functional languages outside of TS/JS is not that great. But an easy one to try out to actually see the benefits I recommend writing a little app with ELM. With something like ELM, the functional style is enforced by the compiler. You will see that 90% of the bugs you typically deal with in JS/TS will disappear. One type of bug that will disappear is runtime errors. Runtime errors are not possible in ELM.
I find a lot of JS programmers haven't fully grokked the functional style. Example: You'll find JS programmers who talk about how much they like functional programming but don't understand why for loops don't exist in functional programming.
Re: A Theory of Software Architecture
#208Earlier 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 think "Too much software" comes from product and engineers not being willing to say 'no' to feature requests and product bloat, rather than any sort of strictly technical thing.
If your product or tool lacks a clear focus and goal, then the code base will reflect that, and will grow and sprawl endlessly.
Re: A Theory of Software Architecture
#209When I see a subroutine with a verb in its name I think of side-effects. In my book a pure function should be named after the result it returns, so in this case I would use the name `definition' instead of `find_definition' and `definition_url' instead of `build_url'. For predicates I try to avoid an "is" prefix when a simple adjective is sufficient.
Too bad you're heavily downvoted. Principle "function name is a noun if it returns something, and verb if it doesn't" is super useful - just by looking at its name you know immediately if it has side-effects. Since I learned it I apply it all the time in programs I write alone, but almost always I see pushback in a team because people are unfortunately used to see `getX`, `fetchY` etc. as method names.
Re: A Theory of Software Architecture
#210Stop calling this theory. This isn't theory. This is just rules of thumb and an opinion. You want actual theory? Here's theory: http://www4.di.uminho.pt/~jno/ps/pdbc.pdf
It's theory in the analytical/interpretive sense, not the empirical scientific sense.
The paper I presented is not theory in the scientific sense. It's theory in the mathematical/logic proof based sense. There are really two uses of the word "theory" for this context, science based theories proven by statistical experiments, and logical based theories created from a set of elements and assumed axioms.
Things like this shouldn't be titled with "Theory." Call it your "opinion" or a "design pattern." Theory is associated with things like the theory of gravity (science) or game theory (math). This title is wildly inappropriate and shows a lack of understanding of what constitutes a theory.
The fact that this post is voted up shows how much the public misunderstands "theory" and how they mistake things like this which is actually just someone's qualitative opinion with the integrity of an actual theory.
Using big words and drawing diagrams does not lend any formal legitimacy to your opinion.