A Brief Introduction
In most people's terms, I am new to programming. I am a high schooler with ~4 years of experience programming, one of which went into software development. I feel that to most people, it is strange that I already commit myself (no pun intended) to these kinds of projects. I do not write the neatest code. I write more functional code. With that said, I am looking for people to contribute ideas, code, and issue reports to my repository.
StormScript Repository
StormScript Docs
Why Do I Want to Make This?
For a long time, I have had very strong feelings about how programming is taught and how read. As much as I love C++ and JavaScript, I believe that syntax could be much better. What I mean is that we need more languages that read like Python, but are still very powerful. I understand that most, if not all of us here know many programming languages and are accustomed to these clunky, hard to write and read languages. Let's Face it, they could be much better.
How is this any better?
There are many reasons that I believe that StormScript fixes these issues. To show you, I will compare many languages with StormScript and why I think that it's better.
Functions
Without Arguments
C++:
#include <iostream>
std::string givehello() {
return "Hello, World";
}
int main() {
std::cout << givehello() << '\n';
return 0;
}
In C++, namespaces are out of control and pretty much the entire library of standard C++ functions and types that aren't inherited from C requires std::
in front of it.
Python:
def givehello():
return "Hello, World"
print(givehello())
JavaScript:
function givehello() {
return "Hello, World"
}
console.log(givehello())
Python and JavaScript are very readable and a little readable respectively, but both suffer from the same problem: They both lack a main scope, and just run code in what in other languages is usually the global scope. This kills readability because it is more difficult to sort out where you should put things and what needs to run immediately and what doesn't.
StormScript:
func givehello {
return "Hello, World!";
}end;
do{
printl givehello;
}end;
If you look carefully, you might notice that there is no parenthesis where arguments should go, and the reason is simple: If you don't have arguments, you shouldn't have to reserve a space for them.
With Arguments
In almost every language, running a function works the same:
functionname("arg1", &arg2, arg3);
StormScript arguments work in a completely different way. StormScript functions use the =>
symbol, which is usually used to declare an inline function.
E.g. in JavaScript:
return new Promise(resolve, reject) => {
resolve();
})
In StormScript, =>
actually is reserved for running a function with arguments. The @
symbol is used to declare a function with arguments.
@args: int x, str y;
func printxy {
printl x, '\n', y;
}end;
do {
printxy => x: 3, y: "hi";
}end;
Classes
Background
I could be alone in this, but it took me a long time to understand what a class is in programming. Since the start of developing StormScript, I have always wanted to change the keyword for declaring classes from class
to type
.
Examples
C++:
#include <iostream>
class human {
public:
int age;
std::string name;
std::string gender;
};
int main() {
human h;
h.gender = "male";
h.name = "Bob";
h.age = 22;
std::cout << h.name << " is a " << h.age << " year old " << h.gender << '\n';
return 0;
}
StormScript:
type human{
int age;
str name;
str gender;
}end;
do{
human h;
h|gender: "male";
h|name: "Bob";
h|age: 22;
printl h|name, " is a ", h|age, " year old ", h|gender;
}end;
StormScript doesn't differ too much from C++ in how its classes work, but the main difference is that it uses the type
keyword rather than the class
keyword for declaration.
If statements
StormScript has similar if statements to many other languages with one key difference, it uses is
instead of ==
and not
instead of !=
. I made this change because I make the mistake of typing =
instead of ==
, and because it makes it more readable.
Example:
do{
str x: "hi";
if x is "hi"{
printl x;
}end;
}end;
Be sure to check out the repository and documentation.
StormScript Repository
StormScript Docs
Top comments (7)
My opinions:
In some parts, you just swap one symbol/character with another, like
class
=type
,h|gender
=h.gender
etc. Whether that impacts readability is personal preferences.Changing the comparison operator may looks nice for now if you are just doing in/equality checks, but I'd still want that
==
as it also pairs with>=
and<=
.The
end;
also seems redundant to me when you are still using the curly braces for blocks.Finally, the deal breaker for me is the function syntax. I don't see any good reason to break function names and parameters into 2 lines and adding
@args
to denote what has already been perfectly describe by the traditional syntaxfunction name(arg1, arg2)
. Also forcing lines to stick together is just as bad as Python's whitespace scope - and I hate that :P.Or maybe I'm just too accustomed to the old ways and not seeing what you're offering :D
The point of swapping keywords and symbols is mostly for readability as the ones I added to StormScript either make more sense to me or make it more readable.
I believe that it is possible that
I could still use words rather than symbols for less than and greater than.
On
end;
being redundant I totally agree, and really just included it as a placeholder so that I can worry more about the core functionality. I am probably going to replace it with};
or just}
in the next release.I created
@args:
not because I like the look of it, but rather because of readability. I will change this at some point to something less likely to make code cluttered.I think that one of my main issues with getting people to use StormScript is that it is different, but I won't let that stop me from changing common syntax to what I and hopefully my contributors will believe to be better.
One question. How do I make a method in the class?
Thanks.
Methods are currently in the master branch but not in the latest stable version. You add them like this:
Oh, thanks. But, my honest opinion, what the use of end in every code block? Is it to make it more readable? Personally, it's really annoying to see it in every code block. Just opinion, okay.
Thanks.
I made that early on to spend less time worrying about how each block should end. Honestly I have been thinking about this for a while now, and I agree with you. I will probably change
}end;
to};
or just}
.I removed end in the latest merge