Programming languages

Concurrency

Memory

Class VS prototype inheritance

Class Prototype
Class definition (fields and methods) and object instantiation are separate Both fields, methods and construction are done in the constructor function
Class definition are not changeable at run time, the fields and methods are always the same New fields and methods can be added to each object independently or to all objects sharing the same prototype object
Inherited class fields are writable by sub classes Prototype object cannot be modified through the object that references it => setting values on a object does not affect all others sharing the prototype
Instances of sub classes do not reference the same objects coming from the class hierarchy All object created from the same constructor function share a reference to the same proto object

Design by contract

Interaction between software components is materialized in a contract that specifies:

Contracts guarantee the Liskov substitution principle since subclass preconditions should not be stricter whereas post-conditions may have additional constraints => guarantees inheritance keeps type semantics

Difficult to implement contracts on called component state in concurrent programs, For example in a stack used by several threads after the call to ‘push’ you may not have the post-condition size(before call) < size(after call) since other clients may have done some ‘pops’ in the mean time.

Assertions are a way to guarantee the contract is respected, their goal is not recover from errors but to fail-fast to allow easier debug => not very adapted for a prod environment or to give clients friendly error logs

Assertions should not produce any side effect since they can be deactivated so they should not modify code behavior.

Cloud computing

API Design

Math concepts (what is this doing here ?!)