Sunday, 30 October 2011

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.

No comments:

Post a Comment