#header-inner {background-position: right !important; width: 100% !important;}


'Ola AH': a Concurrent or the Real-Time Language?


Recently had lot of insights concerning 'Realtimeness' of 'Ola AH' Programming Language i am to create - or more precisely, lack of a 'Real Time Language Features' in this language by it's design.

Current State.

'Ola AH' Programming Language was designed without strict real time features in mind, but still concurrency is important part of it. It would take a lot of effort to change this now, and would make 'Ola AH' Programming Language much more difficult tool to learn & use.

'Concurrency' is about running software parts simultaneously & coordinating them, without bothering about 'pessimistic cases of time deadlines' for processes runs. Concurrent systems still can work in real time.

'Real Time Systems' have additional property - when a task execution time exceeds it's time deadline, we can say that system failed. It's concurrency taken to extreme.

Architecture & Operating Systems Dependency.

Exact time of an instruction running depends both on hardware architecture (parts used) as well as on the operating system & it's version.

Currently, only RT Linux supports real-time demands for personal computers, as far as i know.

Other considerations & design.

So far i don't plan to make 'Ola AH' Programming Language to acquire 'Real Time Properties', because of:
- lack of education & experience in Real Time Systems by language's creator,
- 'vendor lock' & dependency on RT Linux,
- amount of effort with regards of change required for programming language semantics (Stitie Space, Stitie Machine, State, Strategy, Router, Events, MATEN, Prism, Mindful Imaging - perhaps more),
- amount of effort required by developers using this language - both to learn as well as to use - they would need to count how much every instruction 'costs' processor-cycles-wise, other-devices-wise, taking in account operating system used, it's version, as well as hardware architecture. Amount of processors & concurrent running adds to the task's difficulty,
- with current design of 'Ola AH' it's still possible to write 'Real Time Solutions', with slight syntactical support ('asm insert' instruction & 'AH' Anti-hack mode), it's just very hard to do still,
- this would reduce this Programming Language's niche severely - language would lose it's general purpose & simplicity, as more competent programmers are harder to find and more costly to hire. personnel rotations would cost even more than that - it would take a lot of time & cost to take over a project from a former team member.


  1. ... how NEMS nanites can be handled by non-realtime but still concurrent programs?

    1. individual NEMS nanites will be autonomous, only occasionally receiving new orders (strategies) from a coordinator.
    2. strategy messages probably won't aim nanite-by-nanite-individually, messages will aim groups of nanites. authorized nanites-receivers will be able to decrypt these messages & extract the parts of the code/data they need, skipping the rest.

  2. i do not know if individual nanite-receives will or will not use real-time-systems solutions.

    i know only that coordination system written in 'Ola AH' won't use real-time-systems solutions, using weaker concurrency mechanisms instead.

  3. i mention NEMS nanites, but other scales also are to be considered, both MEMS microbots, milimetrites and larger can be autonomous - and sooner than NEMS nanites;

    these can also be coordinated using 'Ola AH' Programming Language and Stitie Space (probably 1.2) which is part of it's semantics.