WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

nCoDE [en-kohd] -

  1. NetKernel Compositional Development Environment
  2. to convert (a message, information, etc.) into code.

The nCoDE Module provides a Compositional Development Environment (CDE) paired with a Language Runtime. The CDE is an web-based AJAX visual editor for editing the programs. The word compositional refers specifically to the second C of the 3C's Construct/Compose/Constrain - an ROC development methodology. Composition is the process of assembling pre-built endpoints into systems and applications. Usually this consists of two distinct parts: 1) definining and structuring spaces, 2) orchestrating composite processes within those spaces. nCoDE helps with the latter of the two.

nCoDE leverages the capabilities of DPML (Declarative Process Markup Language) by translating it's internal definition into standard DPML code for execution. DPML takes a very pure approach to composition - it does nothing more than orchestrate requests between endpoints and the definition of literal representations. DPML supports both an imperative and a functional approach but nCoDE uses only the functional approach. Though the imperative approach can be modelled using the builtin sequence endpoint.

Most "drag and drop" visual programming languages use the dataflow programming paradigm. However nCoDE, in common with Yahoo! Pipes, uses a functional approach. Both approaches look similar in their visual representation, both utilise "black box" components and simple programs may actually look identical in both approaches however they differ significantly in how they execute.

Dataflow programming uses a model where each component can output changes and these changes then ripple through network as needed. The most well known example is a spreadsheet. In dataflow the data is pushed.

Functional programs are driven by their response and are in contrast pull based. Each function is only invoked if it is specified as an argument to a function that needs to be evaluated. This happens recursively and usually lazily. Functional programs have a deep foundation as expressed in lambda calculus. Functional programming is very closely aligned with ROC the main differences being:

  • ROC externalises scope into programmatically controllable address spaces.
  • ROC blurs the boundary between pure and non-pure functions with rich validity semantics on responses.