# Redundancy in Synthesis - How to get the square of three?

### Before starting

• This example:
• is meant:
• to demonstrate the multitude of alternative options
• to serve as a quick reference to them
• not to get into their details
• happens to use numbers
• but could use any expression
• In Synthesis:
• DRY is promoted and facilitated better than most other places
• that’s not the meaning of redundancy used in this topic
• there are many alternatives
• too many of them
• read the short answer (near the middle of this topic) for the winner

### Ηow to get the square of three?

Here are just a few representatives of the endless ways:

• a word: `nine`
• its literal:
• number: `9`
• writes best
• JSON string: `"9"`
• most compatible in conversions
• unescaped string: `'9'`
• sometimes more practical
• a phrase: `the square of three`
• most direct
• shorter version: `square of three`
• with its: `three its square`
• possessor-first
• shorter version: `three's square`
• explicit:
• formal: `the power of three to two`
• normalized: `num from raising 3 to 2`
• mathematical-like notation: `3 ^ 2`
• spaces are necessary
• platform call: `Math.pow(3 2)`
• with comma(s): `Math.pow(3, 2)`
• with semicolon(s): `Math.pow(3; 2)`
• expanded once: `3 times 3`
• mathematical-like notation: `3 * 3`
• expanded twice: `3 + 3 + 3`
• grouped:
• left: `(3 + 3) + 3`
• right: `3 + (3 + 3)`
• outer parentheses are optional:
• `3 + 3) + 3`
• `3 + (3 + 3`
• with variable and that/those: `let x 2 times 3; that x plus 3`
• shorter version: `x= 2 * 3; ?x + 3`
• with it/them: `2 * 3; it + 3`
• implicit: `2; times 3; plus 3`
• sometimes even `it` is implied
• comma-equivalent: `2, times 3, plus 3`
• train: `( 2 )( times 3 )( plus 3 )`
• best looks (spacing matters)
• composition
• wide
``````double some num: 2 times that num
3 plus (double 3)
``````
• narrow
• with dash(es)
``````3 plus double-three
- double-three: 2 times 3
``````
• with this/these
``````3 plus this partial
- this partial: 2 times 3
``````
• shorter version
``````3 + !partial
- this partial: 2 * 3
``````

### Which alternative is the right one? Which one should be used?

• All of them.
• They can coexist.
• The best one is context-specific or the one that comes more naturally to you.
• If you don’t like some, use some others, you have options.
• The winner is you, the user.

• All of the above ways produce the same result (in the default context). However:
• some are direct alternatives to each-other, some have different approaches
• It is strongly advisable to experiment with all of them.
• some are more natural than others
• even more within specific contexts
• some are more verbose than others
• It makes a difference whether you write for yourself or for others.
• some are a little faster, some need a few more steps
• This should rarely be the criterion.
• some scale better, some not so well
• As expressions get more complicated, breaking them down is a must.
• some have more edge cases than others
• Don’t assume that some of them are safe to use without testing.
• some can be used in macros, some cannot
• Logseq may change that.
• Different environments have different constraints.
• Synthesis aspires to be portable to most of them.
• Actively-used natural languages are characterized as alive.
• They are considerably different than before many years.
• The users of those languages slowly shape them all the time.
• In contrast, synthetic languages are dead-on-arrival (meaning not vivid).
• Most of their choices are hard-coded since the beginning.
• They cannot be changed much without breaking much.
• Users have to learn to live with their bad parts.
• They often end up with:
• a short-sighted comity that bogs down progress for decades
• a “benevolent dictator” that takes hard gambling decisions
• a fork to a decisively-incompatible version that divides the community
• In Synthesis:
• redundancy is embraced on purpose
• It is necessary for long-term success.
• the hard-coded parts are relatively very few
• we neither:
• pretend knowing what is best for everyone
• have to choose something for everyone
• it will be the active community the one that will shape the language
• Or may develop a number of formal dialects.
• And yet individual users will still be able to deviate down to individual pages.
• Isn’t this a chaotic approach that prevents compatibility?
• Not more than the human mind.
• Non-trivial language patterns and idioms are not predefined, they emerge.
• The best structures and programs are not invented, they are discovered.
• Living languages have a good record of adapting to challenges.
• They don’t prevent conflicts, but they have the capacity for resolving them.
• Broad compatibility has always been very rare.
• What works well is to hide the incompatibilities behind simple APIs.
• Quite often, keeping it compatible is as easy as keeping it simple.
• Using natural language doesn’t prevent people from getting carried away, but reminds them not to.
• For short-term projects, simple conventions also work.
• But chosen and enforced by the projects themselves, not by the language.
• New paradigms don’t carry the pathogeneses of old ones.
• e.g. dilemmas like “spaces vs. tabs” becoming obsolete by outliners

Redundancy could be an anti-aging formula.

• they look older and older
• Because of the accumulating marks of time.
• a phrase is heard more and more: “Sorry, but this ship has sailed.”
• Meaning that further non-trivial changes are impossible.
• Because of the accumulated fixed and interdependent parts.
• In contrast, Synthesis:
• today looks young
• although is not young
• yet may still look young in years to come
• lets you decide yourself when your own ships are ready to sail
• And yet this metaphor doesn’t make full justice to Synthesis’ potential.
• Because in the world of natural languages the rules are flexible.
• For example, a ship can be in multiple places at once.
• Such abilities are not new to programming.
• But Synthesis can offer them at the language level.
• The human mind already does.
1 Like