1. Interpreted Languages are the future.
Some languages survive decades and come out on top, some languages seem timeless. But programming itself moves and grows, and this I forsee: soon gone are the days of lengthy compile-cycles; gone are the days of recompiling simply to debug; gone are the days of worrying if a language falls short in the field of performance: with VM based and interpreted languages growing ever more popular, and with hardware expanding into the impossible, an interpreter is notperceived as as much of a performance hit as it once was, if at all. Features that can be implemented with an interpreter can go far beyond anything possible in a compiler: features such as the tcallback keyword, which declares a function with a condition so that that function can be called by the Tenga interpreter is met. This is typically used as a debugging function to call if the main function returns with a nonzero status. Eg:
int main(int argc, char- args-) if argc is < 2,
return -1. else, Parse_Input(-argc, -args). return 0.tcallback int Debug_Menu() because `main` is not 0,//Subject to change write "An error occurred. Are you sure you entered the arguments?\n". return 0.And the backticks operator: This returns the last returned value of any function. No arguments can be given; it takes a function name, and returns the last returned value of said function regardless of arguments. Eg (Beware: Pseudocode):
int Parse_Input() if `Scan_Input` is not 0 or `Lex_Input` is not 0, Send_Error(), return -1. //Et cetera
Etc.
2. Programming is messy.
There's no escaping that fact. Languages like Python do try their best to clean it up, but it's a futile effort. Clean, readable code is the goal of all programmers, or should be, at least, and languages like Python bring this goal closer than ever, and what ever kind of slippery slope this involves, this is positive. My very own effort takes a different approach. Python aims, or at least succeeds to as a side-effect, to remove most, if not all clutter from the screen, such as parentheses and semicolons (At the cost of newline flexibility and mandatory indentation (proper indentation is very, very good practice, but again, this is a hit to flexibility, and rules out some IDEs that may use 5 spaces for indentation instead of the standard 8 spaces/tab)) whereas Tenga aims to organise ideas in such a way that has never been widely used: Englishlike sentences/statements, which brings us to the enxt point:
3. Commas and 'Periods' help organize code
Even after using sentence based syntax for a short while during writing the sample source code with which to test the early versions of the Tenga interpreter, I have already noticed a massive difference in the I write code with Tenga. It is another thing to think about, but I'm sure it will come more than natural after a small adjustment time. Commas and ...Periods... help organize code into nice little chunks in the form of sentences, which are statements gruoped together with commas and terminated by a *period.
Eg:
int main() int a, b, c, char d, e, f. d = read(). if d is 'a', write "Aw cool bro\n".
return 0.
See how the declarations are separated from everything else from both a blank line and a period? It doesn't look all that impressive, and it barely affects the readability, but the effect it has with writing code is great.
*I still don't like using that word.
Tenga will involve features and operators that are either standard, new, or raised from the dead. Many arts have been lost, and comma/period termination died with Algol. I intend to raise it from the dead, and I intend to keep improving Tenga until I'm dead and gone.
No comments:
Post a Comment