Philosophy

Angle tries to bring the syntax of programming languages closer to english, where appropriate without introducing unnecessary redundancies or ambiguities. This is difference to Knuths old idea of literate programming.

This convergence towards a more readable english dialect is occurring across the board in many programming languages, notably the logic operators and, or, not in c++, the in operator in python and the it variable in lambdas as seen in kotlin.

Angle adds to these gems the keywords is, be, of, that, which among others.

This Philosophy section amends the Angle guiding principles by containing more general insights, monologues and thought snippets.

Brevity is beauty

It is good that students learn Haskell to unlearn imperative patterns.

SwiftUI is an epitome of a beautiful declarative framework.

difficult to misuse

it's not clear how to achieve it but being difficult to misuse seems like a very valuable goal.

ergonomic, and performant

Less can be more

Cleverness in code starts working against you as a code base and organizations scale

The more powerful a language, the greater the burden on software tools, which either are needed to be more complicated in order to work, or are forced to do less than they could. This includes:

compilers — with big implications for performance
automated refactoring and VCS tools — with big implications for maintenance.

Similarly, the burden also increases for humans — for anyone attempting to understand the code or modify it. Extreme: APL

However we think the perfect language gives users the power to write APL like code yet discourage them through other means, or at least give a way to resolve those symbols into readable segments:

Reasoning tools that help tame the power of expressive language features.

there should be exactly one «standard» way to do things

Angles embracing of aliases seems to violate the good old python paradigm:

"there should be exactly one way to do things"

but is salvageable with the angle paradigm:

let the compiler inform the developer which is the correct way; that is: capture and normalize all aliases

It is now established wisdom that

Globals should be discouraged

when you use a construct that affects your whole program, then you have to reason globally about the changes it makes.

Interestingly this is why many dislike lisp: because all functions are global and not bound to objects, resulting in an incredible cluttering and ugly names (to counteract name clashing).

If statements should be discouraged

Instead we should aim for declarative pattern matching

Statefulness should be discouraged

Principle_of_least_astonishment?

We want to bring new idioms to development, that is surprise developers with new features. How can we at the sane time follow the Principle_of_least_astonishment?

By having forgiving interactive (meaning all kinds of common input are accepted) yet strict fundamentals (meaning the system behaves sound logically and reasonable)

One example of breaking Pola would be to require specific syntax which makes no sense: "Note to C++ programmers: do not place a semicolon after the closing brace."