Introduction
⋮⋮⋮ GRIDNET OS is a cutting-edge operating system designed specifically to deliver decentralized applications and services of any imaginable sort. Its primary purpose is to provide a secure, robust, and scalable foundation for the development and execution of decentralized applications (dApps) and smart contracts. With the rapid growth of blockchain technology and its increasing adoption across various industries, there is a growing need for an operating system that can cater to the unique requirements of this emerging field. There are unique features setting ⋮⋮⋮ GRIDNET OS apart from other popular platforms such as the ability to accept and process user’s input in real-time (termina / user-interface etc.), the ability to interact with UI dApp in real-time and a plethora of in-house Web 3.0 integrated capabilities (such as crypto-incntivized, truly decentralized cross browser communication, secured by unique in-house developed Zero Knowledge Proof Group Authorization protocols – to be seen nowhere else).
⋮⋮⋮ GRIDNET OS addresses needs of both developers and end-users by offering a versatile platform that enables the former to build and deploy dApps and smart contracts with ease, ensuring optimal performance, security, and interoperability – while users benefit from user-interface mechanics they are already well familiar with as these reassemble Microsoft Windows or Apple’s OSX – for the most of it. The terminal utilities and commands are also mostly backwards compatible with Linux. The operating system has been meticulously engineered to integrate seamlessly with various blockchain networks and consensus algorithms, making it an ideal choice for developers looking to create innovative solutions in the world of decentralized technology.
One of the key components of ⋮⋮⋮ GRIDNET OS is its native programming language, GridScript. Initially introduced as GridScript 1.0, a Forth-based language, it served as the backbone for the development of dApps and smart contracts within the ⋮⋮⋮ GRIDNET ecosystem. However, with the advent of GridScript++, the next-generation programming language for ⋮⋮⋮ GRIDNET OS, the platform is now poised to offer an even more powerful and feature-rich environment for blockchain development, rivaling popular languages such as Solidity.
GridScript 1.0 (Forth-based) and its role in the ⋮⋮⋮ GRIDNET ecosystem
GridScript 1.0, the original programming language for ⋮⋮⋮ GRIDNET OS, is a Forth-based language designed to facilitate the development of dApps and smart contracts within the ⋮⋮⋮ GRIDNET ecosystem.
Our choice behind incorporating and then – largely extending upon Forth was simple. We needed a language which was simple enough to be implemented and one which we could extend upon on very short notice. We could not afford forking projects such as Solidity due to 1) zillions of bugs 2) very messy source code 3) analysis of the source code of Solidity would involve more time than implementing the language alone.
As an adaptation of the Forth programming language, GridScript 1.0 inherited the simplicity, flexibility, and low-level capabilities that made Forth a popular choice for various embedded systems and real-time applications.
When implementing GridScript 1.0 we extended Forth to support features related to file system, cryptography, to take into account low-concepts related to decentralized state-machines. Our top priority was also making it serve as a textual interface to the operating system. Sure, some might consider Forth to be such a system on the grounds of is own but then – the original syntax of Forth never accepted things like inline parameters, optional parameters.. all these were added by us and extended upon over the years.
In the context of the GRIDNET ecosystem, GridScript 1.0 played a crucial role in providing developers with a straightforward yet powerful tool to create, deploy, and manage dApps and smart contracts. Its stack-based execution model and minimalistic syntax allowed for efficient and resource-friendly code execution, which is essential in the resource-constrained environment of blockchain networks.
Furthermore, GridScript 1.0’s extensibility and ease of integration with other technologies made it a suitable choice for the rapidly evolving blockchain landscape. Developers could easily leverage the language to build customized solutions tailored to the unique requirements of their dApps and smart contracts.
Despite its strengths, GridScript 1.0 faced limitations in terms of its expressiveness and ease of use, especially when compared to more modern and feature-rich programming languages. To address these challenges and to position ⋮⋮⋮ GRIDNET OS as a leading platform for blockchain development, GridScript++ was introduced as the next-generation programming language for the ecosystem, aiming to rival popular languages such as Solidity.
GridScript++ – the successor to GridScript 1.0 and its aim to rival languages like Solidity
As the successor to GridScript 1.0, GridScript++ is a powerful and versatile programming language specifically designed to meet the evolving needs of the ⋮⋮⋮ GRIDNET ecosystem. Built with the goal of rivaling popular languages like Solidity, GridScript++ incorporates a multitude of advanced features and improvements, positioning itself as a cutting-edge language for developing dApps and smart contracts.
GridScript++ retains the core principles of GridScript 1.0, such as efficiency and flexibility, while addressing its limitations in terms of expressiveness and ease of use. The language offers a more robust syntax, incorporating elements from modern programming languages like C++ and JavaScript. This allows developers to write cleaner and more maintainable code, ultimately enhancing the overall development experience.
Furthermore, GridScript++ introduces several new features that set it apart from its predecessor and competitors like Solidity. These features include enhanced support for data types, advanced error handling mechanisms, and improved modularity. This allows developers to write more complex and efficient dApps and smart contracts, while also simplifying the debugging and maintenance process.
One of the key advantages of GridScript++ over Solidity is its native integration with the ⋮⋮⋮ GRIDNET ecosystem. This seamless compatibility enables developers to harness the full potential of the platform, leveraging the unique features and capabilities of ⋮⋮⋮ GRIDNET OS to create more sophisticated and powerful dApps and smart contracts.
In summary, GridScript++ is a significant advancement over GridScript 1.0 and has been meticulously designed to rival and surpass languages like Solidity. By offering a feature-rich, expressive, and efficient language for dApp and smart contract development, GridScript++ aims to establish ⋮⋮⋮ GRIDNET OS as a leading platform in the blockchain landscape
GridScript++ and GridScript 1.0: Evolution and Relationship
The journey from GridScript 1.0 to GridScript++ reflects the evolving needs of the ⋮⋮⋮ GRIDNET ecosystem, as well as the broader trends in the blockchain and decentralized application development space. This section will discuss the major factors that led to the development of GridScript++ and the significant improvements it brings over GridScript 1.0.
- Complexity and expressiveness: GridScript 1.0, based on the Forth language, was limited in its ability to handle complex data structures and logic. This made it challenging for developers to create intricate dApps and smart contracts. GridScript++ addresses these limitations by introducing a more expressive syntax and support for advanced data types, allowing developers to write more sophisticated applications with ease.
- Performance: GridScript 1.0 was known for its efficiency, but as the demands of the GRIDNET ecosystem grew, the need for a more performant language became evident. GridScript++ has been optimized for performance, ensuring that dApps and smart contracts run smoothly and efficiently within the GRIDNET environment.
- Error handling and debugging: GridScript 1.0 lacked advanced error handling and debugging features, making it difficult for developers to identify and resolve issues in their code. GridScript++ introduces improved error handling mechanisms and robust debugging tools, streamlining the development process and increasing overall code quality.
- Developer experience: The unique syntax and style of GridScript 1.0, while efficient, presented a steep learning curve for new developers. GridScript++ incorporates elements from modern programming languages like C++ and JavaScript, making it more approachable and easier to learn for developers coming from different backgrounds.
- Interoperability: As the blockchain space matured, the need for seamless integration between various platforms and technologies became apparent. GridScript++ was designed with interoperability in mind, ensuring that dApps and smart contracts built with the language can easily communicate and interact with other blockchain platforms and technologies.
- Security: In the world of dApps and smart contracts, security is paramount. GridScript++ incorporates advanced security features and best practices to help developers write secure and reliable code, minimizing the risk of vulnerabilities and exploits.
The evolution from GridScript 1.0 to GridScript++ represents a significant leap forward in terms of functionality, performance, and developer experience. By addressing the limitations of its predecessor and introducing a host of new features, GridScript++ positions itself as a powerful and versatile language for the next generation of dApps and smart contracts within the ⋮⋮⋮ GRIDNET ecosystem and beyond.
Key differences between the two languages
GridScript 1.0 and GridScript++ differ in several key aspects, which impact the overall development experience, the capabilities of the languages, and their suitability for creating dApps and smart contracts. In this section, we will highlight the key differences between these two languages.
- Syntax and expressiveness: GridScript 1.0, based on the Forth language, employs a stack-based, postfix notation that is quite different from most mainstream programming languages. In contrast, GridScript++ uses a C++ and JavaScript-inspired syntax that is more familiar and expressive, allowing developers to write complex logic and handle advanced data structures with ease.
- Data types and structures: GridScript 1.0 supports a limited set of data types and lacks support for complex data structures, making it difficult to work with intricate data models. GridScript++ introduces a wide range of data types and structures, such as arrays, objects, and BigInt, enabling developers to manage complex data more effectively.
- Error handling and debugging: GridScript 1.0 lacks robust error handling and debugging capabilities, making it challenging for developers to identify and fix issues in their code. GridScript++ offers improved error handling mechanisms and debugging tools, which streamline the development process and result in higher-quality code.
- Language features: GridScript++ includes many features that are absent in GridScript 1.0, such as support for classes, modules, and exception handling. These features make GridScript++ a more versatile and powerful language, suitable for a wide range of applications.
- Performance: While GridScript 1.0 was known for its efficiency, GridScript++ takes performance to a new level. The language has been optimized to deliver high performance in the GRIDNET environment, ensuring that dApps and smart contracts run smoothly and efficiently.
- Security: GridScript++ incorporates advanced security features and best practices to help developers write secure and reliable code. This is a significant improvement over GridScript 1.0, which lacked some of the security measures necessary to protect dApps and smart contracts from vulnerabilities and exploits.
- Developer experience: GridScript 1.0’s unique syntax and style presented a steep learning curve for developers new to the language. GridScript++ offers a more familiar and approachable syntax, making it easier for developers with different backgrounds to learn and adopt the language.
- Interoperability: GridScript++ has been designed with interoperability in mind, allowing dApps and smart contracts built using the language to easily communicate and interact with other blockchain platforms and technologies. This is a notable advantage over GridScript 1.0, which had limited interoperability capabilities.
GridScript++ addresses many of the limitations of GridScript 1.0, offering a more expressive syntax, support for advanced data types and structures, improved error handling and debugging, and a host of powerful language features. These key differences make GridScript++ a more suitable language for the development of sophisticated dApps and smart contracts in the ⋮⋮⋮ GRIDNET ecosystem and beyond.
How GridScript++ builds upon the foundations of GridScript 1.0
GridScript++ is not intended to replace its predecessor, GridScript 1.0, but rather to build upon its foundations and enhance the capabilities of the ⋮⋮⋮ GRIDNET ecosystem. While GridScript 1.0 and GridScript++ have distinct features and target different use cases, they continue to evolve in parallel, complementing each other and enriching the overall development experience.
GridScript 1.0 serves as a powerful command line interpreter for the GRIDNET Operating System, allowing developers to write efficient and compact code that can be compiled directly to byte-code. This efficiency and the low-level access it provides to the GRIDNET platform make GridScript 1.0 a valuable tool for certain applications, particularly those that require direct interaction with the operating system.
On the other hand, GridScript++ focuses on providing a more expressive and powerful language for the development of dApps and smart contracts. While GridScript++ code is stored in a compressed format, it maintains high performance and offers a range of advanced features that are not available in GridScript 1.0.
Despite their differences, GridScript 1.0 and GridScript++ are designed to work together seamlessly. GridScript++ relies heavily on GridScript 1.0, with many of its functions acting as wrappers around GridScript 1.0 functionality. This close relationship enables interoperability between GridScript 1.0 and GridScript++ dApps, allowing them to invoke each other and even perform recursive invocations.
GridScript++ includes a native function called evalGS(), which accepts source code written in GridScript 1.0, providing a simple and efficient way to integrate GridScript 1.0 functionality into GridScript++ dApps. This interoperability expands the possibilities for developers, allowing them to leverage the strengths of both languages and create more versatile and powerful applications.
In summary, GridScript 1.0 and GridScript++ are designed to coexist and evolve together, each offering unique strengths and capabilities to the ⋮⋮⋮ GRIDNET ecosystem. Their interoperability and the ability to build upon each other’s functionality create a rich development environment that caters to a wide range of use cases, from low-level system interactions to complex dApps and smart contracts.
GridScript++ vs. Solidity: A Comprehensive Comparison
As the world of decentralized applications and smart contracts continues to expand, the choice of programming languages becomes increasingly important. In this section, we will provide an in-depth comparison between GridScript++ and Solidity, the leading smart contract language used in the Ethereum ecosystem. By examining the features, syntax, performance, and development experience offered by both languages, we aim to provide a comprehensive understanding of their respective strengths and weaknesses, as well as the unique benefits they bring to the table for developers working in the blockchain space. This comparison will serve as a valuable guide for those looking to make an informed decision about which language to choose for their next project, as well as for those interested in understanding the competitive landscape of smart contract programming languages.
The syntax and language features of GridScript++ and Solidity – comparison
GridScript++ and Solidity are two programming languages often used for different purposes. While GridScript++ is designed for the ⋮⋮⋮ GRIDNET Operating System, offering an object-oriented approach compatible with JavaScript, Solidity is the primary language for writing smart contracts on the Ethereum blockchain. In this article, we will compare the file system and storage capabilities of GridScript++ and Solidity and provide examples to illustrate the differences between the two languages.
GridScript++ ⋮⋮⋮ File System API
One of the significant advantages of GridScript++ is its built-in ⋮⋮⋮ File System API. This ⋮⋮⋮ API enables developers to perform file operations like reading, writing, and checking for the existence of files. It also supports creating directories for better file organization. Since GridScript++ is compatible with JavaScript, developers can leverage the full power of JavaScript to work with file data and perform complex operations.
The ⋮⋮⋮ File System API in GridScript++ returns an fsResult object, which contains the success status of the operation, relevant data, and error messages if any. This makes it easy to determine the outcome of the file operation and take appropriate actions in your GridScript++ application.
Here’s an example of how to use the ⋮⋮⋮ File System API in GridScript++:
// Read a file in GridScript++
const result = Filesystem.readFile("myFile.txt");
if (result.success) {
const fileData = new TextDecoder().decode(result.data);
console.log("File contents:", fileData);
} else {
console.error("Failed to read the file:"+ result.error);
Solidity Storage
Solidity, on the other hand, lacks a built-in file system. Instead, it provides a contract-based storage system for managing data on the blockchain. Data storage in Solidity can be achieved through variables in smart contracts and mappings to store key-value pairs.
While Solidity offers a different approach to data storage and manipulation, it may not be as intuitive and flexible as GridScript++ when dealing with file systems.
Here’s an example of storing and retrieving data using Solidity:
pragma solidity ^0.8.0;
contract SimpleStorage {
uint256 private storedData;
function set(uint256 _value) public {
storedData = _value;
}
function get() public view returns (uint256) {
return storedData;
}
}
As you can see, Solidity requires the use of smart contracts and contract-based storage to manage data, which can be less intuitive and more cumbersome than using a file system API like the one provided by GridScript++.
As one might see, GridScript++ and Solidity offer distinct approaches to data storage and manipulation. GridScript++ provides a powerful and intuitive ⋮⋮⋮ File System API that is compatible with JavaScript, allowing developers to leverage the full capabilities of JavaScript for file operations. In contrast, Solidity lacks a built-in file system and uses a contract-based storage system, which may not be as intuitive or flexible for developers accustomed to working with file systems.
- Provide code snippets in both languages to showcase the differences
In this section, we will further explore the capabilities of GridScript++ and Solidity by providing examples in the context of data storage and retrieval, directories creation, and data filtering.
Data Storage and Retrieval
GridScript++:
// Write data to a file
const dataToWrite = "This is some example data.";
const writeResult = Filesystem.writeFile("data.txt", dataToWrite);
if (writeResult.success) {
console.log("Data written successfully.");
} else {
console.error("Failed to write data:"+ writeResult.error);
}
// Read data from a file
const readResult = Filesystem.readFile("data.txt");
if (readResult.success) {
const fileData = new TextDecoder().decode(readResult.data);
console.log("File contents:"+ fileData);
} else {
console.error("Failed to read the file:"+ readResult.error);
}
Solidity:
pragma solidity ^0.8.0;
contract DataStorage {
mapping(string => string) private data;
function setData(string memory key, string memory value) public {
data[key] = value;
}
function getData(string memory key) public view returns (string memory) {
return data[key];
}
}
Directories Creation
GridScript++:
// Create a new directory
const directoryResult = Filesystem.createDirectory("myNewDirectory");
if (directoryResult.success) {
console.log("Directory created successfully.");
} else {
console.error("Failed to create directory:"+ directoryResult.error);
}
Solidity:
Directories creation is not applicable in Solidity, as it does not have a built-in file system. Data organization is typically achieved using mappings or structs within smart contracts.
Data Filtering
GridScript++:
// Read a CSV file and filter the rows based on a condition
const csvResult = Filesystem.readFile("data.csv");
if (csvResult.success) {
const fileData = new TextDecoder().decode(csvResult.data);
const rows = fileData.split("\n");
const filteredRows = rows.filter(row => {
const columns = row.split(",");
return parseInt(columns[2], 10) > 50; // Filter rows with the third column value > 50
});
console.log("Filtered data:"+ filteredRows);
} else {
console.error("Failed to read the file:" + csvResult.error);
}
Solidity:
In Solidity, data filtering is generally accomplished within smart contract functions. The following example demonstrates data filtering using a struct and a mapping:
pragma solidity ^0.8.0;
contract DataFilter {
struct DataEntry {
uint256 id;
string name;
uint256 value;
}
mapping(uint256 => DataEntry) private data;
uint256 private dataCounter;
function addData(string memory name, uint256 value) public {
dataCounter++;
data[dataCounter] = DataEntry(dataCounter, name, value);
}
function filterData(uint256 minValue) public view returns (DataEntry[] memory) {
DataEntry[] memory filteredData = new DataEntry[](dataCounter);
uint256 counter = 0;
for (uint256 i = 1; i <= dataCounter; i++) {
if (data[i].value > minValue) {
filteredData[counter] = data[i];
counter++;
}
}
return filteredData;
}
}
Object-Oriented Programming and Classes
GridScript++:
GridScript++ is compatible with JavaScript, so it fully supports classes and object-oriented programming.
class Animal {
constructor(name, species) {
this.name = name;
this.species = species;
}
speak() {
console.log(`${this.name} makes a noise.`);
}
}
class Dog extends Animal {
constructor(name) {
super(name, "dog");
}
speak() {
console.log(`${this.name} barks.`);
}
}
const myDog = new Dog("Buddy");
myDog.speak(); // Buddy barks.
Solidity:
Solidity supports contract inheritance for a limited form of object-oriented programming. However, it lacks native support for classes and traditional OOP features.
pragma solidity ^0.8.0;
contract Animal {
string public name;
string public species;
constructor(string memory _name, string memory _species) {
name = _name;
species = _species;
}
function speak() public pure returns (string memory) {
return "The animal makes a noise.";
}
}
contract Dog is Animal {
constructor(string memory _name) Animal(_name, "dog") {}
function speak() public pure override returns (string memory) {
return "The dog barks.";
}
}
Lambda Expressions
GridScript++:
GridScript++ supports lambda expressions as it is compatible with JavaScript.
const numbers = [1, 2, 3, 4, 5]; const squares = numbers.map(x => x * x); console.log(squares); // [1, 4, 9, 16, 25]
Solidity:
Solidity does not support lambda expressions. To achieve similar functionality, you would typically use a loop within a function.
Optional Parameters
GridScript++:
GridScript++ supports optional parameters, as it is compatible with JavaScript.
function greet(name, greeting = "Hello") {
console.log(`${greeting}, ${name}!`);
}
greet("John"); // Hello, John!
greet("Jane", "Hi"); // Hi, Jane!
Solidity:
Solidity does not support optional parameters directly. However, you can achieve similar functionality using function overloading.
pragma solidity ^0.8.0;
contract Greeter {
function greet(string memory name) public pure returns (string memory) {
return greet(name, "Hello");
}
function greet(string memory name, string memory greeting) public pure returns (string memory) {
return string(abi.encodePacked(greeting, ", ", name, "!"));
}
}
Type Conversions
GridScript++:
GridScript++ supports type conversions, as it is compatible with JavaScript.
const num = 42;
const numStr = num.toString(); // "42"
const parsedNum = parseInt("123", 10); // 123
Solidity:
Solidity also supports type conversions.
pragma solidity ^0.8.0;
contract TypeConversion {
function intToString(int256 _num) public pure returns (string memory) {
return string(abi.encodePacked(uint256(_num)));
}
function stringToInt(string memory _numStr) public pure returns (int256) {
return int256(abi.decode(abi.encodePacked
(_numStr), (uint256)));
}
}
The advantages of GridScript++ over Solidity
Let us now be more specific by highlighting known limitations of Solidity and describing how GridScript++ aims to mitigate these issues. All code snippets provided below are in GridScript++, we will be going over the limitations of Solidity one by one while describing how GridScript++ mitigates these issues.
- Limited support for object-oriented programming: Solidity provides basic support for object-oriented programming with contracts, structs, and libraries. However, it lacks support for classes, inheritance, and polymorphism. GridScript++ offers full-fledged support for object-oriented programming, including classes, inheritance, and polymorphism, allowing for more modular and reusable code.
class Animal { constructor(name) { this.name = name; } speak() { console.log(this.name + ' makes a noise.'); } } class Dog extends Animal { speak() { console.log(this.name + ' barks.'); } } const dog = new Dog('Rex'); dog.speak(); // Rex barks. - No built-in file system: Solidity does not have any built-in file system support or file management APIs. This limitation makes it difficult to manage data storage and retrieval, especially for complex applications. GridScript++ provides a powerful ⋮⋮⋮ File System API, enabling developers to perform file operations like reading, writing, checking for file existence, and creating directories.
// Write data to a file const filePath = '/path/to/file.txt'; const content = 'Hello, GridScript++!'; const result = Filesystem.writeFile(filePath, content); if (result.success) { console.log('File written successfully.'); } else { console.error('Error writing file:'+ result.error); } - Limited support for functional programming: Solidity does not have native support for higher-order functions, lambda expressions, or closures. GridScript++, being compatible with JavaScript, supports functional programming features such as lambda expressions and closures, allowing for more concise and expressive code.
const numbers = [1, 2, 3, 4, 5]; const doubled = numbers.map(num => num * 2); console.log(doubled); // [2, 4, 6, 8, 10]
- Lack of optional parameters: Solidity does not support optional parameters for functions, which can lead to code duplication or the need to write multiple overloaded functions. GridScript++ supports optional parameters, providing a cleaner and more efficient way to handle functions with varying numbers of arguments.
function greet(name, greeting = 'Hello') { console.log(greeting + ', ' + name + '!'); } greet('Alice'); // Hello, Alice! greet('Bob', 'Hi'); // Hi, Bob! - Limited type conversion: In Solidity, explicit type conversion is required when dealing with different types, and some type conversions are not allowed. GridScript++ offers more flexible type conversions, making it easier to work with different data types.
const num = 42; const str = String(num); console.log(str); // '42'
- Restricted error handling: Solidity’s error handling mechanism is based on reverting transactions and emitting events, which can be limiting when trying to handle different types of errors. GridScript++ allows for more robust error handling using try-catch blocks and custom error objects, providing better control over error handling and recovery.
try { const result = Filesystem.readFile('/nonexistent/file.txt'); if (!result.success) { throw new Error(result.error); } console.log(result.data); } catch (error) { console.error('Error:'+ error.message); } - Limited standard library: Solidity’s standard library is minimal, and developers often need to rely on third-party libraries for common tasks. GridScript++ benefits from the extensive JavaScript ecosystem, providing access to a wealth of libraries and tools that can be used to build sophisticated applications.
// Example: using the popular Lodash library const _ = require('lodash'); const users = [ { 'user': 'Alice', 'age': 30 }, { 'user': 'Bob', 'age': 40 }, { 'user': 'Cathy', 'age': 25 } ]; const youngest = _.minBy(users, 'age'); console.log(youngest.user); // 'Cathy'
Try it yourself – it’s available already!
For starters it might be a good idea to familiarize yourself with some of the previous Tutorials.
Recent Research paper:
https://www.mdpi.com/2079-9292/11/19/3004
Familiarize yourself with the overall architecture:
https://gridnet.org/wpp/index.php/2021/09/17/architecture-decentralized-processing-threads-and-fake-it-till-you-make-it/
Deploying a Hello World UI dApp on ⋮⋮⋮ GRIDNET OS:
How to get going with GRIDNET OS over SSH:
https://gridnet.org/wpp/index.php/2021/06/11/gridscript-basics-and-micropayments-from-the-users-perspective/
How to test support of GridScript++
You may choose to either use Virtual Terminal over SSH or through the Terminal UI dApp.
Whichever route you choose to follow, here are some of the key-points to remember as you go along:
- GridScript++ code needs to be placed in a file with a *.gpp extension.
- Use ‘call’ GridScript 1.0 instruction to evoke code in an external file. It’s like calling an executable. The utility takes path to the executable as a parameter.
Remember: by default the ‘call’ utility expects GridScript 1.0 compiled byte-code to be present within of the file.
Thus, make sure your GridScript++ code is placed in a file of the right extension – *.gpp. - Use ‘cat’ utility to paste minified GridScript++ code into a file of your choice
- Paste into a file and execute:
The above GridScript++ program retrieve a BigInteger from file ‘/PanBoczek/GNC/’ and printed it on screern.
Fell invited to play around!
Conclusions:
- Real-Time processing In contrast with Solidity, GridScript++ can run in ⋮⋮⋮ Decentralized Processing Threads in real-time (for example being an input to decentralized games running as UI dApps).
- Ease of Learning and Use: GridScript++ has a more intuitive and familiar syntax compared to Solidity, which is particularly beneficial for developers who are already proficient in mainstream programming languages like JavaScript. This ease of use allows developers to quickly adapt to GridScript++ and be more productive in creating decentralized applications.
- Interoperability with GridScript 1.0: GridScript++ is designed to be compatible with its predecessor, GridScript 1.0. This means that developers can leverage the power of both languages in their dApps, invoking one from the other, even recursively. GridScript++ includes a native
evalGS()function that can accept source code written in GridScript 1.0, further promoting interoperability. - Efficient Execution: GridScript 1.0 can be compiled directly to bytecode, resulting in efficient execution. While GridScript++ dApps reside in compressed format, they also benefit from the underlying efficiency of GridScript 1.0, as many GridScript++ functions are wrappers around the GridScript 1.0 functionality.
- Rich Standard Library: GridScript++ benefits from a comprehensive standard library, which provides a wide range of built-in functions and features that help developers build feature-rich and efficient dApps. This rich library makes it easier for developers to focus on their application’s core functionality, rather than implementing common utilities from scratch.
- Greater Flexibility: GridScript++ offers greater flexibility in terms of language features and constructs. This enables developers to adopt various programming paradigms, including object-oriented and functional programming, to best suit their application’s requirements. This flexibility empowers developers to create more maintainable and modular code.
- Strong Community Support: With the backing of the ⋮⋮⋮ GRIDNET community and our availability on forums almost 24/7 and continued development of both GridScript 1.0 and GridScript++, developers can expect regular updates, enhancements, and support. This strong community support ensures that GridScript++ remains a viable and competitive option in the world of smart contract development.
In following days / weeks will be extending upon the possibilities even further, everything we do – we do on YouTube LIVE, and provide updates on Twitter on hourly basis so make sure to stay updated. Next, we’ll be incorporating our custom Elliptic Curve-based cryptography constructs into GridScript++.
