It’s been a long time since my last post here. I’m excited to announce a preview release of StrataCode is available at http://www.stratacode.com. For readers of this blog, download a copy with the code SC-P0 and let me know what you think. To read more, checkout the intro article at www.stratacode.com/articles that introduces why programming in layers helps build more scalable and customizable systems, or checkout the super cool data binding, web framework, data sync, dynamic Java, and new parsing framework at www.stratacode.com.
Introducing StrataCode
Published by jeffvroom
I'm a software architect with 35 years of diverse experience. Initially in low-level graphics software including work on the X window system for the GS1000. Lead developer at AVS, then chief architect of AVS/Express. Senior architect and then chief architect at ATG. CTO at Tribal Fusion, Principal Scientist at Adobe for 3.5 years. More than 10 years as a software architecture consultant, performing tech due diligence and writing challenging code. View all posts by jeffvroom
Published
Jeff Vroom's Blog 
Can’t wait to see it in action!!
Jeff, as promised on FB, here’s my off the top of my head reaction…
Re AVS/Express: yes, I was a big fan as you know. Never used ATG Dynamo or any of your later frameworks. So when you say “Now truth be told, I like building applications, not infrastructure”, well I think the author doth protest too much!
Microservices: neat presentation of the downsides. The industry has been repeating the microservice anti pattern since CORBA.
Customisation: inversion of control. 90s Java and C++ frameworks made this mistake; inherit from this interface and supply this and only this behaviour was a very rigid approach that only worked when your problem was one the framework designed had anticipated. MFC was an egregious example.
Layers: second graph suggest layers are a low coupling mechanism. In strongly typed languages inheritance is a high coupling mechanism, as explained by footnote 1. Smalltalk or Python style languages that do all the type checking at runtime have lower coupling. But the cost is that it makes large codebases harder to navigate for new devs as the points of coupling can’t be found by grepping for types. I’m wary of magical coupling mechanisms. IMHO unfamiliar coupling mechanisms are one of the biggest learning challenges for devs in a new language or system.
What exactly are layers? From the blog I understand that they are a powerful low coupling high cohesion abstraction mechanism. I’m guessing they may be like Zope Acquisition from late 90s early 2000s. Traditional inheritance resolves member references by looking to base classes when a subclass doesn’t supply that member. Zope Acquisition resolved missing member references by lookup in parent/container objects at runtime, not compile or buildtime. Hardly surprising that many found it confusing. So I’m guessing that Strata has some novel reference resolution mechanisms that allow code to be unchanged when the resolution targets move across modules and processes. There seems to be a hint that code can be unchanged in the face of changes between synchronous and async styles, which would be ground breaking. The dawn of async with Doug Schmidt’s C++ Reactor work and Twisted Python is still working its way into the mainstream. Even after 20 years of Python coding, and 15 years of async work in C++ and Python, I’ve only just started using Python 3’s async/await keywords. And look how long it took the Java world to come up with Netty.
Adopting a new paradigm is always difficult. As a dev I’ve been through several paradigm shifts: structured to OO, compile time to run time type checking, callback style inversion of control for event driven systems, imperative to functional, and synchronous to asynchronous. Some of those shifts entailed adopting a new language too.
Communicating a big new idea is very difficult. I think I need to see small worked examples in Strata vs the same example in vanilla Java to get my head around it. Some youtube videos talking through examples would be great. Failing that I guess I’ll have to wait on an old fashioned show’n’tell over keyboard, pen & paper and IPA next time I get to CA!
Thanks for taking the time for such a thoughtful reply. I really appreciate the feedback. I like the idea of inheritance with “low coupling” as a way to describe the benefits of layers. It is kind of like Zope Acquisitions, or objective C mixins, though more structured and less flexible. It’s like taking a normal class, breaking into an independent part, and another part that depends on the first one. So maybe the fields go into the independent part and the methods are in the downstream part. The code-processor uses the layer dependency and the type name to stitch them back together again into the original class. This keeps the type names the same unlike the other approaches so code can more easily go back and forth.
Here’s a 3-minute video where I describe the client/server layer thing as part of the site builder example:
Looking forward to that IPA!