Nothing real is measurable; everything real is countable.

#Java
The JVM
- is the detailed, formal specification for a 32-bit abstract machine. Abstract implies hardware and OS-independent and thus is interoperable across platform-dependent implementations. It operates on abstracte data types rather the native data types of any ISA:
• 32-bits types: integers, floats, and references are called primitives
• 64-bits types: long and double are supported but consume two units of storage
• smaller types: boolean, byte, short and char are extended to 32-bit ints

It loads code, verifies it, and executes it. It has instructions for:
• Load and store
• Arithmetic
• Type conversion
• Object creation and manipulation
• Operand stack management (push & pop)
• Control transfer (branching)
• Method invocation and return
• Throwing exceptions
• Monitor-based concurrency

The specification includes various dynamic features such as GC and thread management.

JDK
- is an software development kit for Java and consists of:
• a private stand-alone implementation of the JVM such as JRE's HotSpot
• the Java standard library, JCL
• an interpreter/loader (java)
• a compiler (javac)
• an archiver (jar)
• a documentation generator (Javadoc)

HotSpot
- relies on JIT; and divides the memory into generations:
• young generation: heap for short-lived objects
• old generation: heap for long-lived objects
• permanent generation: used for class definitions and associated metadata

JVM languages
Any language that can express a valid class file. The existing languages includes ports from other languages:
• JRuby (#Ruby)
• Jython (#Python)
And entirely new languages that compile to Java bytecode:
• Clojure
• Apache Groovy
• #Scala
• #Kotlin

JVM languages are compatible with each other i.e. libraries of one can be used with programs of another. A new feature will supports dynamically typed languages in the JVM, and is developed within the Da Vinci Machine project whose mission is to extend the JVM so that it supports languages other than Java.

#structures

Sequential
• Array: contiguous elements
• Matrix: contiguous elements each paired with two indices
• Tensor: contiguous elements each paired with n indices
• Linked List: non-contiguous elements each paired with a pointer to the next element
• Stack: contiguous elements with a top pointer
• Queue: contiguous elements with a head and tail pointer

Non-sequential
Elements are accessed without restriction.
• Binary Tree: contiguous elements each pointing to at most 3 other elements: one parent and two children
• Hash table: contiguous elements mapped to non-contiguous elements using a hash function
• Graph: non-contiguous elements each paired with a list of elements it is connected to

The less you know about a problem, the easier you think it is to solve.

“A thing isn't quite real until you name it.”
— Jordan Peterson

“Don’t be afraid of ideas that are not your own.”
— Douglas Crockford

GC analogy for belief revision
Dynamically iterate over all beliefs and "collect" the contradictory ones.

Syntax comparison

C-ish

if (cond)
{
    ...
}
else
{
    ...
}

Citronic

cond ifTrue: {
    ...
} ifFalse: {
    ...
}

Nilic

if cond {
    ...
} else {
    ...
}

Pythonic

if cond:
    ...
else:
    ...

Rubic

if cond
    ...
else
    ...
end

One-liner conditionals

C-ish
if (cond) ... else ...

Citronic

cond `ifTrue` ...

Nilic
if cond then ... else ...

Pythonic
no support

Rubic
if cond ... else ... end

#Python development tips by S. N. R.

The notebook from jupyter.org, and kivy.org for rapid GUI development

“The mouse and the windowed desktop are perhaps the two greatest innovations in the history of human-computer interaction. But like all innovations, they are best seen as part of a continuum rather than a terminus. The mouse and the window led us out of the confines of the keyboard and the text prompt to the world of graphical and spatial possibility we enjoy today. But there's no reason to stop there.”

“Many activities today still need only a keyboard and terminal screen—and it's likely the personal computer could have still evolved, albeit more limitedly, using only those. Most activities today need only a mouse and windowed information display on top of that, and the evolution of software and hardware can and will continue while limited to these. Eventually, though, the shift to another interaction paradigm is inevitable. Just as the advent of the mouse and windowed GUI opened many new doors, so will the next generation of interfaces after that.”
— 10gui.com

Evolution of the UI

CLI (Command-line user interface)
Dominance: 60s-80s
Input devices: the keyboard
Input: a successive series of codified text with an strict syntax i.e. commands
Process: handled by a program called a shell which is a program that accepts commands as text input and converts commands into appropriate operating system functions
Output: a limited range of responses
Output devices: monochrome monitor
Advantages: efficient, automatable via scripting
Disadvantages: tedious, esoteric, steep learning curve

GUI
Dominance: 80s-present
Input devices: the mouse
Input: intractions with metaphors via movements and actions of the mouse
Process: metaphors are ultimately translated into commands
Output: visual metaphors e.g. desktop, file, trash can, dragging, etc.
Output devices: color monitor
Advantages: customizable visuals, exoteric
Disadvantages: not everything that can be done with a CLI can be done with a GUI

Multi-touch technologies may be the bridge from traditional GUIs to the natural user interface: NUI.

A UI is like a joke, you shouldn't have to explain it.

Repetition is probably an effect of mis-design.

#Nile
Conversions and Descriptions
Methods in most languages are unintuitive in how they named and used; e.g.: toString, stringify, etc. While all return a value of type string, one may return a functionally deserializable serialization of the object, whereas another may return a natural language description of it; and it's neither easy nor necessary to remember which is which.

Nile has done extensive separation and then intuitive unification to reach the following alternative syntices and semantics:
• to & from Serialization
defined for Object, it's usable anywhere and for anything.
• describe Description
returns whether the object fits the description. 'whether' implies Boolean return type. For example the domain of description for Integer includes 'odd', 'even' and 'prime'.
• to Text
arbitrarily defined, returns a Text which is essentially a String but always guaranteed to be in natural language. This makes it easier to fully localize your apps. Text literals use double quotes.

The source instance to target type and target type from source instance operators are sugars that translate to constructors of the target type that consumes an instance of the source type as input, which may or may not destroy it, and returns an instance of the target type as output.

A perfect language has no idiosyncrasies.

The human brain evolved during over ten thousand years; of course any comparable AI will be slow.

The tester and the developer must have different ways of thinking.

Naming conventions

ThisIsPascalCase 🌊

this_is_snake_case 🐍

thisIsCamelCase 🐫

this-is-kebab-case 🍢

Give an object allocated space, and you resize it statically;
Teach it how to allocate space, and you resize it dynamically for a lifetime.

Limitations of the brain, both natural and artificial, forces the organism to prioritize their pieces of knowledge.

Imagination versus programming is like levitation versus driving.

The latter requires sophisticated, already material, machinary to instruct abstract commands; the former requires nothing but the brain itself.

The latter is based on the slow process of learning to master the machine-specific instructions; the former depends only upon intuition, already genetically embedded.

The former is impossible to materialize; the latter, however laborious to implement, is possible to materialize, i.e. execute.

Somewhere in the middle lies our compromise.