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.
OOP as realized by the languages in common use is a bit of a disaster.
What was originally conceived as message passing[1] is actually implemented by OO languages as passing around pointers to objects that have mutable state, so in effect, every object is potentially part of global shared state.
Inheritance is a confused mess of "is-a" semantics, type system behavior, and code/state sharing in a set of subclasses.
I'm often somewhat amazed that we can build working large-scale systems at all in these languages given their weaknesses and the knowledge/skill level of the average programmer.
please, current software - not event thinking about Electron-like things, just the software that comes with operating systems, be it Finder, explorer.exe, even fucking photo viewers and music players or terminals - are already slow and frustrating enough as is, it's not like message passing is going to make shit happen faster.
I saw a Pharo (smalltalk) demo recently, the damn thing was so slow to react I thought it was a bad joke. Can't even begin to imagine what actual message passing would look like - oh wait, I do actually know due to spending 6 hours last weekend finding why a software had uncomfortable mouse interaction, actually caused by fucking objc_msgSend making everything async and slow on that wretched Apple OS.
It isn't the languages themselves it is the structures and software architecture that people think will scale while not realizing how tangled their program is.
Inheritance by its nature introduces dependencies but accomplishes little to nothing that couldn't be accomplished better with a different technique.
Likewise putting any sort of transformation from one type to another inside a class introduces a dependency on that type, which may be doing the same thing, thus depending on other types, etc.
On the other hand message passing in the form of pointers, interprocess communication, copying within a program, etc. Can be done in C++. Unfortunately most people go where the language leads them because few people really have a great idea of how to structure complex software.
Decades of disappointment? Most large software projects are still done with OOP and it doesn't seem like any functional programming prodigy paradigm is going to replace it any time soon.
OOP languages also happen to be some of the most popular languages around - C#, Java, C++, Javascript. Coincidence? (in before nitpicking about how C++ and Javascript aren't OOP).
There are a few sure things in life. One of them is that speaking of OOP in a positive light will get an immediate comment on the orange site saying that it's garbage. Its almost comedy at this point.
Take full advantage of today’s multicore processors with Unity’s new high-performance, multithreaded Data-Oriented Technology Stack (DOTS).
DOTS makes great games run faster on multicore processors without the heavy programming headache.
DOTS provides programmers with a convenient sandbox to write safe multithreaded code for massive performance gains, while also optimizing thermal control and battery life on players’ mobile devices. By moving from object-oriented to data-oriented design, it will also be easier for you to reuse your code and for others to understand and work on it.
The new Conversion Workflow converts your GameObjects to entities with one click. At runtime, check the new Entity Preview Inspector to see how DOTS turns your GameObjects into entities
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.
Oh, thank you for sharing! I would love to see an example of where you are dealing with model and state transfers, so that we can make sure that the protocol we are building supports it. Is there anything more you can say about this?
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).
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.
