---
title: "Simorg In 10 Minutes"
source: reference-book
version: genesis-0-1-0
id: reference-book/simorg-in-10-minutes
canonical: https://simorg.tech/docs/reference-book/simorg-in-10-minutes/
agent_guide: https://simorg.tech/agent-resources/simorg-gem.md
---

This is a quick start section, focusing on core functionalities of simorg.

We are going to discover simorg using a simple guessing game. Our application receives user's input from terminal and checks it against a target number. Guessing right leads to a success message, otherwise user needs to enter a new number.

Create a new file and call it <<<guessing-game.art>>>, we will add our simorg code inside this file.

Let's start from the core functionalities by creating two variables.

Using <<<$>>> before an identifier, marks that identifier as variable.

```
$TARGET
$guess
```

Using capital letters we mark <<<TARGET>>> as being a const variable that is being set only once during the lifecycle of our app. Let's give it a default value by replacing line 1 by,

```
3 $TARGET
$guess
```

Simorg doesn't have classical assignment operator <<<=>>> instead it uses eventflows. As soon as our application starts, the value 3 vibrates and starts an eventflow. When its event reaches <<<TARGET>>>, the variable vibrates in turn, this time under a new identity. An event is simply the availability of data at a specific moment in time.

We can keep adding operators in our eventflow pipeline. Let's add a logger operator so we can see the value in terminal,

```
3 $TARGET ?
$guess
```

By running our app,
"""
sim -f guessing-game.art
"""
3
!!!!

Cool! Let's now add a basic condition and test it. 

```
3 $TARGET ?
$guess

guess = TARGET  "Congratulations! You successfully guess the number!" ?
```
Simorg doesn't have any reserved keywords! So no more <<<if>>>, <<<else>>>, <<<while>>>, etc..!

Line 4 is again an eventflow pipeline which starts by the variable <<<guess>>>. if the value is equal to <<<TARGET>>> then it passes the event forward. In this case the incoming event reaches our string value literal and makes it vibrate. The incoming value is not used anymore; the value literal passes its own value to the logger operator.



Let's give the same value to <<<guess>>> and test our application,
```
3 $TARGET ?
3 $guess

guess = TARGET  "Congratulations! You successfully guess the number!" ?
```

By running our app,
"""
sim -f guessing-game.art
"""
Congratulations! You successfully guess the number!
!!!!


Let's add more conditions to cover other cases,
```
3 $TARGET ?
3 $guess

guess = TARGET  "Congratulations! You successfully guess the number!" ?
guess > TARGET  "Target is smaller than your guess" ?
guess < TARGET  "Target is bigger than your guess" ?
```

Now we have the core functionality of our app. Let's complete it by importing two blueprints. Simorg like any modern programming language has its own package manager called 
$$$ToPageLinker keyword=Logos toRoute=https://logos.simorg.tech$$$.

Let's use a random number generator. Using <<<#>>> before an identifier will help us instantiate our blueprint and have an identifier to call it,
```
"@stl/random0.1.7" #random

9 random.integer $TARGET ?
3 $guess

guess = TARGET  "Congratulations! You successfully guess the number!" ?
guess > TARGET  "Target is smaller than your guess" ?
guess < TARGET  "Target is bigger than your guess" ?
```

By pushing <<<9>>> into <<<random.integer>>>, we will create a random number between <<<0>>> and <<<9>>>, inclusive. Then this value will be set as our target.

Next blueprint is <<<terminal-input>>>. It will help us read a value from terminal,

```
"@stl/random0.1.7" #random
"@stl/terminal-input0.1.6" #terminal

9 random.integer $TARGET ?
"Enter Your Guess: " terminal.promptAndReadLine $guess

guess = TARGET  "Congratulations! You successfully guess the number!" ?
guess > TARGET  "Target is smaller than your guess" ?
guess < TARGET  "Target is bigger than your guess" ?

```

Our application is almost complete. Line 5 will prompt and read a value from terminal, and its event then makes <<<guess>>> vibrate.

As you noticed Simorg doesn't use any type definitions. Engine tries to convert types automatically. In case of failure a log message will be logged by engine. Simorg doesn't throw any exception at runtime. If something fails, the expected event will not happen.

Finally, let's re-arrange a few things to fulfill the requirement of our application and keep asking the user when the guess is not right, 

```
"@stl/random0.1.7" #random
"@stl/terminal-input0.1.6" #terminal

:terminal.promptAndReadLine $guess 

9 random.integer $TARGET "Enter your guess: " guess

guess = TARGET "Congratulations! You guessed right!" ?
guess > TARGET "Target is smaller, Guess again: " guess
guess < TARGET "Target is bigger, Guess again: " guess
```

Line 4 uses an open pipe, so this pipeline vibrates again whenever we need to receive a new guess.
We use the natural logger capability of <<<promptAndReadLine>>> to ask user for new inputs.

On lines 9 and 10, when user needs to guess again, the event is re-directed back into <<<guess>>>. The act of prompting and asking user to enter a number is now part of the declation of <<<guess>>> so whenever something is pushed into <<<guess>>> have to pass through all these pre-processors.

Awesome! Now you have a basic understanding about core aspects of Simorg. The event-driven nature of the language is helping us create a new declarative form of solutions.
Also, every single token that we use is referring to an equivalent data entity, in other words we are writing code from data's point of view not from a third-party observer's point of view. This is contributing to the simplicity of the language as we don't need extra unnecessary tokens. This is how Simorg achieves a solution using zero reserved keywords.


To gain a deeper knowledge about simorg, please continue reading our reference book. Happy Coding!