Clojurians Log v2
architecture
@seancorfield I'm afraid I don't... a good deal of 'Simple Made Easy' kind of points to that line of thought, I think, as he basically recommends starting from a different set of atomic foundations, the most foundational of which is the extraction of state. The supposed 'great divide' between OOP and functional languages can usually be broken down into their philosophies this way, as well. I'm mostly speaking from my own experience - watch talks from Strange Loop, and you'll see dozens of different example architectures, each unique and each likely completely foreign to the problems you deal with, and yet each likely containing echoes of choices and tradeoffs you've had to make. So, if you want to learn from them, you have to distill them down to the common elements that we all end up working with. I think we can get better at formalizing principles, and grouping them together in combinations that have proven effective. For example: * A bunch of principles cluster around statelessness: Rigorous application of 'Immutability' and 'Referential Transparency' produces the quality 'Ease of Reasoning,' for example. * Another set of principles cluster around interaction: Rigorous application of 'Enacpsulation,' 'Message-passing,' and 'Reference-by-address' produces the qualities 'Pliable' and 'Maintainable,' and becomes greatly influenced by the degree of 'Cohesion' that is maintained. This isn't likely a realistic format, but there are probably methods like this to communicate these types of lessons. Maybe in the end I'm just circling back to the whole 'patterns' discussion, just at a systems and architecture level instead of the too-fine-grained code level. Something closer to the 'Enterprise Integration Patterns', perhaps.
Wowie, sorry for the wall of text.
@fellshard I appreciate the insight. The same to everyone else in the thread. The motivation for me asking about how others felt they learned to be a better architect was that i had just finished a white board interview that i felt went poorly. I was asked to “design a url shorting service”. I was short on sleep and stressed out so I didn’t do a good job answering. But after having been throw a few of these interview questions, i get the impression that i could become better if I just practiced more. To that end, Can anyone recommend any books or talks they thought were really good? To give some background (not attempting to humble brag, which would fail in this crowd 🙂 ) I have: * read designing data intensive applications * i’m reading the Morning Paper daily * watched most of the strange loop talks from the last couple years. * Most of the clojure conj talks from the last couple years. * finished most of MITs distributed systems class and another by Melborn (or something) * studied Onyx and Apache flink a good amount Though, I’m not sure more books or videos are what would make a big difference for me. I think i need more people to discuss these topics with constantly. Maybe even practice with people at the whiteboard as thats such a common tool for conveying information. Ideally an environment where everyone felt safe to … be wrong and egos weren’t on the line (which i feel they often are when your on the clock). Again, i appreciate the feedback. I’m just not able to transform it yet into a plan.
> i had just finished a white board interview that i felt went poorly Most whiteboard interviews go poorly. It's a bad technique. Developers don't come up with code or designs in just a few minutes under pressure in front of their peers -- that's just not how we work in the real world.
However, there's a book called something like How to Crack the Coding Interview that helps people deal with this sort of stupidity from interviewers.
I wouldn't take an interview as a sign of how much you've learned, aye. It is difficult to integrate the book learning into usable knowledge without practice, so focus on getting working in the field first.
@fellshard I’m sympathetic to those principles but also wondering when they don’t just become principles of FP (stateless, lazy, composable, etc…)
the worry I have is that we start building and island mentality around some principles rather than adopting well researched / thought out principles from the larger programming community
one of my favourite recent talks is by Gilad Bracha
and the killer feature of FP - according to him at least - is live coding
which puts Clojure in the driving seat
I think the ability to reason more simply with statelessness is a stronger killer feature for FP. Yeah, I suspect a lot of features tend to cluster together around the major paradigms. But we're talking less about just programming languages and more about architecture choices, which tend to be more... fungible, at least for now.
fair point
it’s probably the law by now here but Michael Nygard’s The New Normal has a lot of this down
I had never seen this, thanks