pragma solidity ^0.8.10;

contract HelloWorld {
    string public greet = "Hello World!";
}

```pragma```

 is the compulsory first word in the first line of code within any Solidity file.

 ```pragma```

 is a directive that specifies the version of Solidity compiler to be used for current Solidity file.

### 2.

 ```Solidity ^0.8.10;```


Solidity is a new language and is subject to continuous improvement on an on-going basis. Thus, there are older and newer versions and you could set a range of compiler version with this syntax:



```Solidity
pragma solidity >= ^0.5.0 < 0.9.0;

As stated earlier, Solidity is created to be EVM-Compatible. It is a contract-specific language. A smart contract is a set of functions that does stuff. Thus, in-between the

 ```contract Name{ }```

 tags, there are other properties, including functions, data types, and technically every other thing you have in a normal object oriented language.

### 4.

 ```public```


The

 ```public```

 keyword signifies functions that can be called internally and externally, by any one. 

# Greeting the Blockchain in .vy
Let's greet the rest of the Web3 world again, but this time, with Vyper.



```Python
# @version ^0.2.0

greet: public(String[100])

@external
def __init__():
      self.greet = "Hello Blockchain"

You can instantly tell that it means the version of the current Vyper source file.
### 2.

 ```greet```


A public variable named greet is declared as a string data types, and initialized with a max length of 100.
### 3.

 ```@external```


Despite that the contract is set to public, the

 ```@external```

 keyword is repeated. What this means is that the function below it can only be called via transactions or other smart contracts.

....

After comparing these languages, you will notice that Solidity is JavaScript influenced, while Vyper is... you guessed right, Python influenced.

Why build Vyper when Solidity is in high demand and adoption?

# Coming to terms with the Vyper
A [research was conducted in 2018](https://arxiv.org/pdf/1802.06038.pdf), where roughly one million deployed Ethereum Smart Contracts were analyzed. The research uncovered vulnerabilities in these smart contracts. The researchers grouped these vulnerabilities into threw: for ease of identification:
- *Suicidal Contracts* - smart contracts that arbitrary addresses can kill.
- *Greedy Contracts* - smart contracts in a state where they can no longer release ether
- *Prodigal Contracts* - Smart contracts that can be made to release ether to arbitrary addresses.
What's common among these vulnerabilities? 
They are introduced to the smart contracts via code. It could be unintentional from the developer, but regardless, these vulnerabilities have the potential to cause unexpected loss in funds for users. 
That's why Vyper was built. It tries to eliminate this by letting users write secure code and making it difficult for programmers to write misleading or vulnerable code accidentally. 

# Conclusion
This article introduced you to smart contracts. You learned about languages used in writing smart contracts, comparing the two most adopted ones. Next, you see how contracts are written in both languages and what each beginning term stands for. 
Perhaps you concluded on a choice of language for authoring your smart contracts already; however, do put the findings from this article into consideration.


### Did you enjoy this article?
Follow me here and on [Twitter](twitter.com/ghostmac9).