Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / C++

Execution Performance, Linguistics, Totalitarian Elitism, and of course Python: Language as a Construct of Action

5.00/5 (2 votes)
18 Jul 2017CPOL3 min read 4.7K  
I’m an elitist in the worst way sometimes, so this is probably the pot calling the kettle black...

I’m an elitist in the worst way sometimes, so this is probably the pot calling the kettle black. But I simply want to pose a question, that no doubt will spark great debate among a very divided culture:

Why does the coding style we use to imply organization of the characters in the document representing code need to be so explicitly tied to the keywords, syntax, semantics, operators, closure, and the most important part… the resulting libraries that make up the development environment we seek to develop within?

It’s always the same argument Braces and Semi’s versus Linguistic command flow.

To compare:

C++
void say(char* statement, char* target) {
  cout << statement << ", " << target << "!\n" ;
}

void main(void args[]) {
  say("Hello", "World");
}
C++
def say(statement, target):
  print(statement + ', ' + target + '!')

say "Hello", "World"

The reality is, short of the other larger breadth of the language’s constructs–operators, keywords, and the syntactical protocol by which the compiler interprets the human-like instructions–the structure is nearly indifferent. Both are equally readable with even minor knowledge of either language. And with care, I’ve seen extremely large projects in both languages be extremely easy to browse and understand without inline documentation. And from my perspective, the lack of documentation in the globality of source trees is really the bigger problem to be solved in development–especially when brain to execution speed seems to be the most important reason for picking a language any more. I digress..

My point is, there is a mantra that exists within the Python community that semicolons and braces are evil characters that somehow dirty up code, and that by forcing the end user to indent their code in order to maintain closer and control flow, it somehow contributes to cleaner code. From my perspective, it takes more effort to maintain the whitespace especially within complex control structures. The result of this is a waste of development time and the possibility that a misappropriated amount of spacing can cause unintentional control structure closure or lengthy lines which need to be explicitly escaped with the ‘\’ construct borrowed from shell scripting.

So, I ask: “Why on God’s Green earth would we want to confine the language to a subset of the development community by strictly enforcing the personal coding style preference of Guido van Rossum?”

I don’t mean to be critical. I have a great deal of respect for both Guido and the contributors to Python at large. The capabilities of the Python Libraries both in execution performance and in the ability to not turn into the new Java (at least as of 2017) really provide an excellent development environment. I actually quote him regularly with the following from the Zen of Python:

  • Beautiful is better than Ugly
  • Explicit is better than implicit
  • Simple is better than complex
  • Complex is better than complicated
  • Readability counts

However, I believe each of these recommendations are in the grand scheme of things tossed to the side as the problem to be solved doesn’t fit within this set of guidelines. Moreover, I would note that if Readability depreciates at some point by utilizing whitespace indention as the construct for closure and control flow doesn’t, this in and of itself violates the recommendations that “beautiful is better than ugly?” And if, “Explicit is better than Implicit,” wouldn’t utilizing a construct (presumably braces) for Explicit closure or completion of a control structure be the winner?

To see a perfect example of some of these conflicts in beauty vs function, you should really read: The ‘ugliness’ of Python.

So, now that all of this winning has ran most of you off… TLDR; I give you the most beautiful (from a C programmers perspective) compliment to the C Language since TCL: pythonb aka Python with Braces. I discovered this wonder while trying to resolve a spacing issue in a 26,000 line project spread across 17 modules. I would share the mess I have inherited, however to avoid the most definite and expedient termination by my employer should I do so, I will just share the result of my search.

Please take this opportunity to find love for the snake of a language – Python with Braces.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)