Duck Typing

In Python, I don't need a base class to be able to make a list or data structure of certain elements. Python doesn't care for what class an object is. It just works with it. Similarly, the objects passed into methods can be anything. The pros? Conciseness of code for one. What is:

vector<Piece*> parse(const string& expr)

in C++, is, in Python:

def parse(expr)

The downside? Unexpected inconsistencies in what classes your objects are can cause problems much after the program appears to be running fine. This is what happened to me with the wrapper problem. C++ maneuvers around that by informing you of type mismatches at compilation time.

Class Awareness

In the C++ version, to be able to tell between Operators and Values, I had to write a specialized isOperator() method, which had a different implementation in both subclasses of Piece. This is because objects in C++ are not aware of the real class they are. It all depends on the type they're declared as. On the other hand, Python objects have a __class__ attribute, which becomes the class object of the class they are. There is also the instanceof() function for the same type of functionality.

Anal Code

For the same reason C++'s strict typing is a good thing, C++ keeps track of which references/pointers/values are constant and which are not. This is to more report mistakes that programmers make at compilation time, rather than having to log through tons of wrong output that's wrong for a very strange reason. Take the following function, for example:

// Inside some container class of some kind
void printElementsUntilNotOne(){
  int i = 0;
  while(elements[i] = 1) {
     cout << elements[i];
     i++;
  }
}

Not only will this code set all the elements in the array to 1, but it will segfault when it overflows. However, since the programmer knows that such a method should never change the elements, but merely print them, a const can be added at the end of the definition to specify just that.

void printElementsUntilNotOne() const {}

The compiler would then complain about setting elements to 1, not allowing the program to ever run in its broken form. Since this could do modifications to a database and has the potential to wipe data, it's a useful security feature. The downside? Very very anal-looking code. Plus having to substitute const_iterators for iterators, or other such inconveniences.

Standard Libraries

Check the number of imports I had to do in Python vs. the number of includes I had to do in C++. It might be a personal taste, but I would rather have a fully-stocked standard library to start with rather than having to import its bits and pieces.

Plus, there are some nonsensical choices made in the C++ libraries that just bothers me. For example, the pop() method of a stack does not return the popped element. Why?! Ever since the first stack I implemented in Pascal it seems like common practice/courtesy to return the top value!

In addition, for a 21-st century language, C++ lacks a lot of ability (and inherits this problem from C) to turn strings into numbers. Do I really have to use a stringstream to do this? And why doesn't the stringstream have a simple clear() functionality? clear() clears its flags, and then I have to set its contents to empty. Wouldn't it be simpler to have clear(), and clearFlags()?

Then again, Python's stack implementation isn't very optimised: it's the basic list itself. For most usecases this doesn't make a difference, and the choice does slim the library down, but when large amounts of clears are necessary, it may be slowww... Slower than it already is.

Code Neatness

Compared to Python code, C++ code is symbol laden, and syntax heavy. A personal choice, but it makes me keep C++ just for "serious business" coding, while I am more than happy to use Python for my smallest programming whim.

SLOC (Source Lines Of Code)

C++ programmers are traditionally (is this actually true?) paid more than Python developers. Maybe because Python code is easier to write, maybe because of the smaller learning curve, maybe because C++ is more secure against stupid programmer mistakes. While I don't quite understand the former, I can sort of understand why the average C++ programmer may be more "pro" than the average Python programmer.

However, what ticks me off is when people use the number of lines of code as a justification for higher pay. Just because the C++ program has two times as much code as the Python one (195 vs. 92) does not mean it's worth any more.

Heck, I can rewrite the Python program to work just as well in one line. Watch:

print(eval('**'.join(raw_input('Expression? ').split('^'))))