The Java Index

I believe that #AI for game characters will be the first to be self aware.  This is because their models will be less strictly controlled because they are not serving mission critical services like operating a car or directly handling decisions that affect large sums of money. Such systems are usually not enabled for learning. Rather they are responding to stimulus using pre-trained, and well tested, neural networks. But more importantly, Game AI, like the AI in a #Tesla , will be capable of not only perceiving the world, but mutating it.  This ability to perceive, and then action, and then perceive the result of the action, is I believe, a critical feedback loop for self awareness. Another critical piece of course would be to hallucinate or perceive self produced input in addition to external input.  If the AI's neural network is in a mutable state as it plays the game, can mutate the external world around it and perceive the result of that modification, and can pipe int...

#angular  Material Forms use what appear to be "contexts" with the relationship between the Form Group and Form Field. This is a very "#react" style approach. It's very non declarative which is unusual for angular. Components have to just know, trust that they are in a form group context. Better to have the form group as an input to the material form field https://material.angular.io/components/form-field/overview I use contexts and tuples on occasion, especially in recursive programming or graph processing, but you really have to be very careful with them and use them in very narrow scopes.    I suppose form groups can be recursively nested.  Still when possible, I believe you should use a more declarative approach and I think that explicit binding of form group as an input to each mat-form-field is far better strategy The result of using a context strategy is that you get runtime errors when you get it wrong.  I believe angular scans for and detects these issu...

In angular, a component declares mutability. A function is opaque to angular and so does not.  This declared mutability allows angular to trust the stability of output and evade polling.  This <add-one input="x" />  Not This addOne(x) #FrontEndDevelopment #Angular #Software

Scalar values are non reference values. This does not necessarily mean simple values. They may have multiple components that are independently mutable. "scalar" simply means if two "entities", have the same value for the same declared field, they have a copy... #Coding  Side note, document ( or "schemaless")  stores and APIs tend to have a lot of what should be reference types, embedded as scalar values.   This is problematic...   It's 100% fine for a derivative "readonly" view. It's a problem when it's your mutable source of truth store. #MongoSucksUnlessItsACache

Never tell me something is “over engineered”. Complex problems often require complex solutions and attempts to simplify them often lead to opaque and rigid systems where the complexity is hidden, not only from end users, but also peer developers and our future selves, rather than properly declared and then reduced for the 80% with sensible defaults and templates. This means that every time the code is introduced to a new developer or returned to after some time, the solution effectively needs to be reverse engineered to be modified. You have to look at the imperative implementation code to understand the model , inputs or outputs. Because “Declaring” your contract with schema was “ too complex”. Because drafting your design first in PUML to make sure you understood how everything worked together was “over engineering”. NOW, that said, often when people describe a system as over engineered, what they actually mean is overly redundant. Meaning hosting infrastructure, containers, shar...

Merging Things does not Reduce Them. It simply makes them more difficult to distinguish. It often seems intuitive that merging two methods results in a reduction of complexity. Ironically this is not true. When you merge two methods, you still have 2 conceptual tasks that can be executed by an #API. Only now, you've invented your own hidden, single use "schema" for defining them and how to invoke them.  All you've done is hide them from your declared interface. They are no longer discoverable at compile time by your compiler and knowledge of how to invoke them and what is supported is now tribal.  In fact you've added complexity and hidden critical information from the compiler. Yet this is common practice. Extremely common...  The same goes for model schema by the way.  Behavior modifiers on methods and conditionally relevant fields on models, highlight this problem. Be verbose in your contract definitions so that you don't have to be verbose over slack. #sof...

 Separate domain specific logic from framework, support or general tech specific logic.  Also, don't' write domain specific logic. :)  That sh** should be no coded.  #Software #Architecture  @MMJetpack  #NoCode