Mental Models

A mental model is an explanation of someone's thought process about how something works in the real world

— Wikipedia

Mental models help you map objects and their relationships to set an approach to solving problems. Most developers think that their mental model is "how the code works", but It’s more complicated than that because most of their representations are:

How the code editor works code (shortcut, code completion)?
What are the language rules and keywords?
What role do those lines have? Are they initializations, input/output, or data processing?
How are these lines connected to the overall goal of the program?
What are the available data models (array, sets)?
What are the language paradigms (object-oriented, functional)?
How the hardware target works (memory, runtime, processes)?
What would be the perfect architecture?
...

Why?¶

Usually, Software/Hardware designers start as a programmer: there are mainly focused on the implementation part of product lifecycles. As they get more confident with larger code base, they quickly move from just:

write code that does X

to write code that:

complies to coding standards,
is efficient, easy to maintain, easy to read by colleagues,
has unit tests, and doesn’t leak,
doesn’t break the continuous build,
and does X.

Mental models are made through repetition. However, repetition by itself isn’t enough. For example, if you built an application in a similar domain every day for five years, you would get really good at building that kind of application. However, you wouldn’t improve as an architect when domain or technology changes.

You need a language that is close to those mental models and can evolve with your experience. U is built for that.

U for Humans¶

Characterizing developers’ interactions with code, with their activities, and tools is the biggest challenge. To reduce cognitive load by thinking to all aspects and have more fun, U aims at improving your productivity by:

Having a simple source code model: your code and the outside world,
Avoiding confusion with whitespace-sensitive grammar: if spaces have meaning to us, they should have meaning to machines too.
Removing keywords: no need to remember keywords. Short operators are easier to remember than alphanumeric keywords when fluent in U:
```
::A :user      # Is less boring than 'class User'
::Is :Readable # Is less boring than 'trait IsReadable'
```

Reducing visual overload: any alphanumeric word should have an added-value, don't repeat yourself:

# Instead of repeating <fn>
fn :a, 1
fn :b, 2

# Group declarations in block
{-fn
    :- :a, 1 # <=> fn :a, 1
    :- :b, 2 # <=> fn :b, 2
}

# Group declarations in line
static (:a, :b) : (1,2)

Reducing type and annotations; U infers value type by default. Type annotations are only required when U compiler cannot resolve value types.

Visual Impact¶

Following the adage "a picture is worth a thousand words", U improves the visual impact by:

Having less reserved characters,

Using your iconic memory: by using operators, you are not reading a keyword but recognizing an image, as you do with numbers:

::if # Keyword IF: use visual memory + language processing => IF statement
:?   # Use faster iconic memory: ':?' => IF statement
1    # Use faster iconic memory