ChrisRus

Working on a new spin on domain models and software product line engineering, in JavaScript, for data scientists that need to build sophisticated process pipelines, and complex interactive visualization UX --- from data and reusable stuff. The dream is an open and extensible cloud that functions like the software service analogue of the system-on-chip ecosystem that's eating the devices/IoT world.

Note that the idea here is sound; identify and specify the roles of various actors in detail specifying explicitly that they are not actual _classes_. Effectively, this is high-level block diagram and there's every reason in the world to have that clearly defined before actually building a system.

But, then when you go to actually implement and testing something designed this way that's non-trivial. That's the point where I am arguing that OOP should not be manner in which the implementation is expressed because the paradigm is optimized for organizing functions that operate on common data context. But, not for organizing actors that must share data and carefully coordinate the which and in what order functions are applied to modify that data.

OOP is not a helpful paradigm for modeling systems. If it was, we would design digital circuits with classes. But, of course that's not possible. Because classes are absolutely a horrible metaphor for representing shared state at runtime. And, that's most of what modern systems are doing. Have you ever stopped to consider that a class API is effectively the pin-out to a chip that's missing it's observable state vs input specification? Nobody would use that chip because it's actually not adequately documented. And, so why people think OOP is still a reasonable basis for building re-usable code and expressing ideas about system architecture after decades of disappointment is one of software enduring mysteries. My speculation is that the half-life of talented engineers before they become managers is approximately equal to the number of years you need to seriously struggle with OOP before you have enough perspective to start having ideas of your own. And, then you switch to management, and buy a book on design patterns, and kick the can to the next generation.

This looks very interesting indeed. I am currently working on a system that allows hierarchical system modeling and evaluation of so-called "observable process models". I can easily understand leveraging something like this over HTTP to reduce implementation details of model and state transfers.

I am going to watch the whole thing. I guess now it will be largely review. But, the fascination is in the instruction; this is not an easy topic to teach.

Soon it will take less time and be more cost-effective to commission the integration of an SoC for your application than to risk your business to software basket weavers.

JavaScript developers interested in this should also take a look at https://encapsule.io/docs/ARCcore/filter that makes it simple to implement bulletproof JSON validation and normalization. Advanced application of this library additionally allows for runtime type-based metaprogramming in JavaScript (i.e. build generic algorithms that are specialized to handle specific app-defined data types at runtime).

How does this differ from Firebase?

Need to know. Members of the kernel team generally have zero knowledge of what happens in the build lab between the sources and the product that's released to the world.

OO is absolutely the wrong paradigm; at its most elegant OO exceeds at encapsulating one very simple form of automata. But is utterly worthless of modeling hierarchical automata systems with complex dependencies and shared state requirements. Systems modeled using finite state machine models capture the requirements and can be used to generate the runtime. This approach works but suffers from lack of tools and an appalling lack of system design skills in the software community.

The more you look at microservices, the more you'll appreciate basic TTL logic design with buffers, blocks, latches, and sequential logic. I wrote a paper about this subject a long time ago. Everything I've seen since further convinces me that this is the path forward for software.

http://blog.encapsule.org/early-encapsule-project-history/20...

I wrote ARCcore.filter to solve many of the issues discussed. And, because it works at the JavaScript function level to normalize/validate function I/O it works well with _everything_ to solve the runtime data problem. And, it opens up a new world of type-based runtime metatemplate programming to JavaScript developers. https://encapsule.io/docs/ARCcore/filter

I totally believe distributed systems should be modeled using declarative circuit metaphors.

From Jack Reeves he cites the epiphany "that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker."

Ha. That is laughable. If it were so, then we would be able to automatically graft features from one product to another. I contend this is exactly how SoC are designed and there's no reason why we shouldn't copy the methods of the digital design community (proven to scale or you wouldn't be reading this).

Cool! Thanks for the links and the reply.

I have felt this train of thought could be useful for a general purpose approach to software engineering beyond distributed systems interop

One of the best articles I've read in recent years on the topic is 'On the Industrial Adoption of Model Driven Engineering. Is your company ready for MDE?': http://www.uajournals.com/ijisebc/journal/1/4.pdf

Unfortunately this has been a hobby horse of mine for about 10 years that I don't have a lot of time to dedicate to....

It's a fun horse to ride if not a bit of a wild and tiring.

I have been working on a moon-shot project for more than a decade that seeks to model distributed systems as if they were digital logic circuits. One of the natural areas of interest is of course FSM's - in particular declarative specifications of FSM's. I continue to believe (although it's a wildly unpopular notion among some of my machine learning friends) that this obsession with the mechanics of declaring design intent with models and then synthesizing runtime code will fundamentally transform software engineering over time. But, declarative FSM's aren't enough to make it practical IMHO.

I wrote a short essay about this work in which I argue that the software engineering community needs to embrace the design methodologies and rigour of hardware designers: https://medium.com/@alpinelakes/on-monday-i-learned-i-got-ac...

See also: http://blog.encapsule.org/early-encapsule-project-history/20... (old code but same ideas as what I'm building now in Node.js/HTML5 @Encapsule).

Several things I believe are actually essential to make use of any of these ideas at scale:

- There needs to be an ad-hoc extensible standard for notating serialized data with markers, tags, semantics, metadata (whatever you care to call it). It is not practical to do unsupervised feature extraction on internal message streams. And, it's _insanity_ to write/test/maintain custom validation/normalization logic.

- Given the above, FSM declarations must be encoded with labels (as above) so that generic code can easily affect interop.

- Small FSM's are reasonably easy to comprehend. But, very few systems can be modeled with simple FSM's. Rather, real systems can be modeled as complex directed graphs where edges represent the flow of observable state from one FSM to another (vertices represent individual FSM).

- Given that real systems can be modeled using non-trivial graph models of FSM (as above), building reusable components by splicing and dicing the graph up is logically possible. But, this is not something that mortals can do by hand. Considerable tooling is required to make it practical to design systems like this.

If you're interested in these topics, and want to help, look me up @Encapsule.

#1 on HackerNews is worth it. Congratulations, man!

HW design is not that different from SW design.

Shouldn't be. But it is.

I doubt that Windows will ever be open sourced. I think it's more likely that they continue to integrate Linux API's into the commercial OS product and slowly morph into a their own Linux distro when most of the legacy code has been replaced.

will not be swallowed

I've added comments to the OP but to summarize:

OO inheritance is useful for codifying a limited set of real-world models. But to truly generalize, we need to stop pretending that it's feasible to make progress without actually investing the effort to codify state v time behavior contracts over software. Today, if anyone bothers to even try to document these behaviors, it's done inconsistently and not in a form that's readily usable by tools that help you through the maze of detail. This is a shame.

Re-usable software requires (a) strong contracts for data I/O (what we call API) and (b) state v time contracts in _machine readable form_. Conceptually, no hardware system on earth would exist if not for the fact that both (a) and (b) are formally defined. Don't take my word for it: go read up on state-of-the-art SoC design and IP blocks and ask yourself if exchanging _text files_ (IP blocks) is really any different than software. I think it's not.

Begging the question: http://www.nizkor.org/features/fallacies/begging-the-questio...

Almost _never_ a valid reason to use this phrase. Using it incorrectly signals (a) you're reaching (b) not so cunning a linguist after all.

HA. It's been patched to "raises the question". Good edit!