Monday, 31 October 2011

'They Called Me A God'

Here is a conceptual wall of text just waiting for consumption by the masses.


At first, there was nothing; at first, I did nothing. There was nothing to to. Before long, doing nothing became tiresome, so I began to ponder. But, of course, pondering had its limits, for there was nothing to ponder about. So when pondering became monotonous, I began to explore. This came with its own set of benefits and disadvantages; no matter how long I searched, I found nothing, and it seemed there truly was nothing. I searched for a long time, longer than I had cared to ponder, although, my perception of time was skewed at best: There was no way to measure time, nor was there certainty that time itself existed.
When I became disinterested in searching, I soon came to the realization that despite the fact that there was nothing, but there didn't have to be. I had found two things to do already, was it not possible for me to create something to do? I searched, but with a purpose this time: I searched for a means of creation. I must have searched for a long time, but of course this passed me by. With eyes for my new target, I began to notice things. I noticed tiny clouds, barely distinguishable from the possibly infinite black surrounding them.
These clouds were the most interesting thing I had ever seen, as they were not nothing, therefore they were something. I observed them for a long time: I now measured time by their sporadic movements. This was not the best, nor the most accurate way to tell time, but now time was sure to exist, and I could now see events, their causes, their effects, and their length; the cloud moving as a whole to its unspoken and possibly undetermined destination seemed to be a much slower process than, say, small parts of the cloud breaking away and rejoining. There soon seemed to be an abundance of clouds, each of them made up of millions upon millions of tiny particles, I had observed, when there used to be merely dozens. This gave me my most radical idea yet: If these clouds became from nothing, could I not create from nothing as well, or perhaps use the clouds to create? My urge to make something out of the infinite nothing began to grow to the point of passion.
With an even newer and more ambitious target, again I searched on. In some places, the concentration of clouds seemed more dense than elsewhere, and sometimes, multiple clouds had joined to make a denser, larger cloud – These, I kept my attention on. I noticed something else whilst exploring – something else entirely. Where the clouds were large and many, there seemed to be a pressure. A pressure that was surely not coming from the clouds, and which seemed to always come down to a pinnacle at a certain point in space.
It was at these points I observed the particles that made up the clouds slowly appearing, seemingly from nowhere. Perhaps there was another realm like this one overlapping, and particles were coming through the weakest points of the barrier that kept the entities of the two realms ignorant of each other – or perhaps the entities in the other realm know of my existence but I not theirs? If this was true, then where did the material that makes up the other realm come from? Perhaps there was no other realm, for if there was, would it not be a process such as this that formed the contents of said realm? If this was true, there could be infinite realms, each accidentally – or maybe purposefully – forming the next? I took a moment then to admire how complex and inquisitive my pondering had become. Whether or not it was possible, probable or impossible other realms existed, these points of material generation needed more examination than merely theoretical.
I began to interact with the particles coming from these points. I caught them and held them, and when they were many, I compressed them together. Many, many particles compressed together seemed to make something very, very different from the clouds, something that was not part of the infinite black, but something palpable. Interested, I waited. I waited until particles beyond counting – for it would take as long as the clouds do to reach their destination – then I pushed them into each other, making a very, very dense, solid object. This was far more dense than many clouds that had joined, and far more solid than anything that had ever existed. This was a material that was special – it needed a name. After much pondering, I named it Rock, for only a sound so dense and solid like the Rock itself could describe such a material.
After I had spent such a time collecting tiny particles, the Rock continued my work. By itself, it started to pull, a tiny force at first, other particles into itself. It was soon surrounded by its own cloud, getting denser as it moved towards to the rock. The cloud grew and so did the rock, attracting clouds from further and further as it grew. Was a Rock the final destination of the clouds, or were they merely misguided ghosts, the only force moving them the momentum from the interactions of the particles that make them up and from their creation?
The Rock grew and grew, with me transfixed in pondering and observation. It grew to a strange shape both long and wide, but some parts bigger than others, and when a single part was denser or larger it attracted more particles. Offended, I carefully evened it out into a perfect, round shape, even on all sides, so that it could grow into a healthy, uniform shape and not be burdened by parts of itself pulling the wrong amount of particles in the wrong direction. I watched and pondered, and the Rock grew and pulled.

Sunday, 30 October 2011

The Theory/Concepts behind Tenga

If you have read my post below about Python, you may have picked up the name Tenga. Tenga is an interpreted language of my design and implementation. Tenga is based on a few ideas:

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.

Python is not a good first programming language.

Every day I see Python reccomended as a first programming language, and I can't fully express how wrong I think this in mere words.

People reccomend Python claiming its simplicity will give you a good kickstart into programming, but this is the exact approach that will turn programming from a sought after skill involving discipline and dedication into a sit-down-and-screw-around type trivial activity. Books proclaiming to teach you x language in y days are bad enough, but a language with such simple language so that you can 'focus on just the logistics' is the exact opposite of what a beginner programmer needs, and here's why:

1.  Programming is messy.

There's no escaping that fact. There are lacks of backwards compatability that obsolete entire projects, there are compilers that will throw an error about missing parentheses or a misplaced semicolon in a header file, and proclaim the error is in the file including it, there are programs so large even their sole developers gets lost within them - what I'm trying to say is that programming is not clean nor simple, never has been, never should be and probably never will be. To begin programming by learning Python will, in fact help you focus on just the logistics; the flow, the structure, all those good things, and that is beneficial, with that I am okay. But learning to program in Python bears unforseen consequences. I have read of several cases of people either starting in Python or switching to it (From Perl, of course) who have gotten lost in Java or C code, and blamed their inherited inability to both read and write code in a messier language on their fixation with Python. But is it Python's fault? Python is a good language. But for someone ignorant to the theoratical side of things (I almost used the word messy again), is has a numbing effect. Programmers get so wrapped up in their comfortable, warm Python beds, sucking their thumbs and humming sweetly out of satisfaction with their perceived understanding of everything that they fail to notice their bed slowly taking the shape of a coffin, and their ears are deaf to the sound of the hammer. They are hidden from the nasty monsters outside such as the Lambda calculus, Assembly, compilers; everything a programmer needs to know inside ad out to truly be considered a good programmer. Now, don't get me wrong; of course, I'm not saying every Python developer is sealing their own fate of mediocracy. I'll explain further later.

2. Newline termination
Note: This section is deprecated. Pratt parsing is probably used by the interpreter, therefore making newline 'termination' not a drawback, merely less messy. Forcive indentation, however, is  more of an issue.

Okay, this section is more of a critisism towards the Python interpreter.
I've always been beyond curios when it comes to implementing a compiler/interpreter, and after a good playaround, and a semi-thorough study of ther Python interpreter, I have found a few things that tickled my pondering bone. Why do people implement newline termination? C++ is terminated by semicolons; Cobol is terminated by full stops (No, I'm not american, so I will not call full stops 'periods'), Lisp is fully parenthesized, and Tenga, my under developement (up to version 0.001 Alpha Mc-Does-not-work-yet pre-release 0) baby of an interpreted language is terminated by an interesting mix of commas and full stops similar to that found in Algol 68. Usually, compilers/interpreters discard newline characters at the scanning (sometimes, lexing) stage, and terminate statements at the given character, but Python terminates at newline characters. Why is this? Of course, Python has no termination character (Unless you count '\n') so newline is a feasable indication to the interpreter that a statement is over, but a massive gain in flexibility would be had with the implementation of argument satisfation termination. THis may be a new concept, it may not be, but heres an example anyway. (Beware the pseudocode)

for (int x = 0; x < y; x++)

As we can see, 'for' takes one argument when the parenthesized block is considered as a whole, and the poarenthesized segment takes three arguments, essientially. Here, have some pseudoEBNF notation.

forloop := "for" ([statement]; [comparison]; [statement])["{" statement {statement} "}"]

As you can see, the initialisation, condition and incrementation are all optional, so maybe this isn't the best example, but nonetheless, a good interpreter would not complain if this fit the specification for the syntax in the language, and neither would the Pythion interpreter, that is, if Python used syntax like this. But what is the user wanted to split it up over multiple lines?

for
(int x = 0;
x < y; x++){ //code }


Okay, this is messy (There it is again) and I know of no programmer who would do this with a for loop with such arguments for for, but sometimes things such as linked lists make doing this kind of typographical acrobatics necessary (a Rootnode->next->next->governor = Rootnode->next->next->next->governor; kind of deal), and newline termination would cause an interpreter or compiler complain about this. If, instead, argument satisfaction was implemented, the contents of the parentheses would evaluate to a corrent abundance of arguments, the for loop would be syntactically correct and the interpreter would move on, but of course, this is not the case.

And last, but not least:

3. Python is used by the wrong people.

Beginning programming on a slippery slope into language dependance and newline terminated statements is definately the wrong approach, by all standards. What would I reccomend, you ask? Assembly. "Assembly to start off? What is this guy smoking?" You may say, but bare with me. My advice is to go as low level as possible, as Python is an extremely high level language. Starting with Assembly (Okay, it might be a bit of a stretch. Any language between (and including) c++ and Assembly would be low level enough to give you a sense of direction when trudging through semicolons.) and moving upwards, (learning Lisp on the way; every programmer should learn a little Lisp) reading about theory along the way, of course, will give you a full understanding of programming itself, instead of just the ability to read and write the simplest of programming languages. If I must allude to one of the greatest essays of all time, Teach yourself programming in 10 years, a minimum of 10,000 hours must be dedicated to something to truly become good at something; I think that it is then, with a profound understanding, a programmer should indulge in Python. Now a programmer understands and can benifit from understanding, and use his knowledge of algorithms to use Python to his full advantage. The right person to use Python is an experienced programmer, not a new programmer.