Informatics Quick Reference Guide

The IT field is growing, and it is easy to get lost in the zoo of approaches, frameworks and technologies that loudly declare their "novelty" and "efficiency". But behind the wrapper are usually hidden good old ideas, re-invented in a different context. As a result, it’s not the simplest and most effective, but the most publicized implementation. Developers do not have time to make a thoughtful choice due to a constant lack of time, and managers choose the most common to reduce risks when searching for developers.

For myself, I try to reduce the term used in the industry or technology to a simple definition or illustrative example. I offer a handbook, very brief, and therefore incomplete and not claiming to be accurate.

Type - this is what the computer is able to argue. To argue in the sense of the usual human or formal logic, that is, according to the rules to build some conclusions from the original premises. The good news is that the computer does it automatically. There are different types of systems: some eliminate some type of errors, such as type mismatch, resource leakage (Rust Borrow Checking); others automatically generate an implementation (Haskell Type Class, Scala & Rust Trait). When types are easily perceived by man, they serve as documentation. Strong type systems can do more work for you than weak ones. And static type processing will do this work earlier, when compiled, and not later, when executed, as dynamic.

A class in OOP is one of the type systems, which allows one to reason about the internal structure, which fields and methods are inside. Analogs: record, tuple, type-product.

Inheritance in OOP mixes at least 4 ideas that should be implemented in separate ways:

1. Data inheritance is pretty useless after being wrapped in getter / setter and turned into methods with implementation inheritance. And an example of transparent wrapping is Elm Records and Haskell Records.
2. Inheritance of an implementation for reuse; it is recommended to replace it with delegation.
3. Interface inheritance (Ad hoc polymorphism) overloads the method, that is, allows one to get a different implementation for each type by one name. Analogues: Java Interface, Scala & Rust Trait, Haskell Type Class; algebra as a data type and a set of operations on this type.
4. Type combining is similar to Java Enum, Scala Case Class, Elm & Haskell Algebraic Data Type, type-sum.

Pattern Matching deconstructs an algebraic type-sum or type-product, that is, it is an inverse operation to the constructor.

An object in OOP is a closure where free variables are fields, preferably private ones.

OOP is a popular brand that has historically developed but not a unique set of ideas without a single central core.

Polymorphism is different .

Description , interface - type-product, consisting mainly of functions.

A design pattern is an informal implementation of an idea outside a programming language, since this language does not support the required level of abstraction. In another, higher-level language, it is possible to implement a pattern by means of a language.

Visitor is a design pattern that implements Pattern Matching.

Builder is a design pattern that implements a higher-order function that accepts parts and issues a product.

Dependency Injection is a design pattern that implements a higher-order function that accepts dependencies and issues a product. Isomorphic to the Builder pattern with the fact that dependencies are usually functions.

Client Web development is a sought-after, historically established, but not unique set of ideas based on the monopolistic position of JavaScript.

MVC , MVP , MVVC is a pure function and an abstract automaton for handling external events.

Event Loop (Node.js, Rust tokio) is an abstract automaton for handling external events.

Programming is an engineering science about code composition.

Category theory is a fundamental theory about the composition of anything.

Isomorphism is the transformation or replacement of something into something else and vice versa, that is, the essence of isomorphic things is one.

Refactoring is an isomorphism performed by humans.

Optimization is computer-performed isomorphism.

(Pure) function - the transformation of one into another is always the same.

The functor turns one type into another (function on types), so much so that you can optimize the composition of pure functions. For example, the “list” functor can turn type “ string ” into type “ list of strings ”, and type “ number ” into type “ list of numbers ”. Apply the function " length " to each element of the list of strings and get a list of numbers. Add 1 to each element of the list of numbers and get a new list of numbers. And you can replace (manually refactor or automatically optimize) a couple of passes through the lists for one composite, which will find the length of the line and immediately add 1, but most importantly, the intermediate list will disappear.

A monad turns one type into another, so much so that you can assemble functions with a side effect. For example, the monad " wait " ( Future , Promice ) has a side effect of waiting for the completion of a lengthy operation and converts the type " array bytes " into the type " wait for an array of bytes " and the type " confirmation " into the type " wait for confirmation ". Let's transfer functions of reading file name and will wait for an array of bytes from a disk. Then, we transfer the received byte array to the network send function and wait for the client to confirm receipt. And you can replace a couple of expectations with one composite (combinator (>> =) , bind , and_then ), which will first wait for an array of bytes from the disk, and then wait for confirmation from the client over the network, but most importantly, the explicit intermediate wait will disappear, allowing the execution environment to it is time to do other good things.

Duality - turned inside out also works. For example, from the fact that type-sum is dual to type-product, it follows that a function that accepts apples or pears (type-sum) can be replaced by a pair (type-product) of functions: one says what to do with apples, and the other what with pears.

Variation says that turned inside out works directly (covariance) or in an inverted way (contravariance). For example, a function that eats the type of apples or pears can be fed to the apples, but you cannot type apples or pears or peaches because it chokes with peaches. A more omnivorous function is harder to create and smaller. More argument - fewer functions with such an argument - this is "works in an inverted way", that is, the function is contravariant in the argument. But the result is a covariant function.

Calculations can be made yes even on pebbles .

Quantum computing does not work with bits, but with qubits. For example, instead of balls in the Marble adding machine, you can throw Kots Schrödinger. For example, a pair of cats will give 4 options: both alive, first live, second live, no survivors. As a result, for one start of the machine, we get the sum of all possible numbers. The only problem is how to turn Kotov Schrödinger downstairs cars into ordinary cats, useful in the economy.

Dependent types - working with types and code optimizations in the same way (Pattern Matching and calculations) as with values. Dependent types allow you to transfer to the computer work with computable patterns and even mathematics itself. For example, you can specify that the type of "set of elements", when the elements are not more than 64, can be replaced by the type of u64, which fits in the register. Or the compiler can make sure that the sizes of the added vectors are the same.

Additions and corrections are accepted.