Fixing bad code written by others is practically my profession. It certainly is a large fraction of my job.

I don't recall bad indenting ever getting near membership in the top twenty flaws I must battle in code written by others.

For contrast, consider this flaw common to all the large Python projects I've had the misfortune to try to correct:

1) Certain member names are duplicated across almost every object type in the project, so text based searching for those names finds everything, which is the equivalent of finding nothing.

2) Every important object type has member contributions scattered all over a giant project. No object type has any place where its purpose or contents are documented or encapsulated.

Clearly (2) is more the fault of the few specific programmers responsible, rather than entirely the fault of the language. (1) isn't even necessarily bad. In many C++ projects with decent support tools, it isn't a problem at all. But the combination of (1) and (2) ends up being deadly in Python, while in C++, (2) is impossible and (1) isn't very harmful.

Before I ever saw a Python program, one of the things I thought was a flaw in most object oriented languages, including C++, is the excess emphasis on encapsulation:

C++ makes you entirely define an object when you define it. That object definition must declare everything that goes into that object (either directly or by pulling in previously defined sub objects). Member functions etc., might be defined later, but they all must be declared in the object definition.

On occasion, that is a very painful restriction and leads to much uglier code than would be required if the encapsulation rules were a bit less severe.

Back then, I foolishly thought that professional programmers tend to be professional, so they would encapsulate when they should even if the language makes it easy to not encapsulate.

Now I understand they won't. Python makes it too easy to not encapsulate. C++ makes it too hard, which isn't great either. But looking at the results from ordinary professional programmers in both languages, I'm convinced that most programmers most of the time will mess up big project structure more in a language that makes not encapsulating too easy.

Before a mod sees this thread and locks it, I'd like to point out I only wanted a little bit of advice as to which I should pick. Not to start a flame war

I don't really think you have. Other than one idiot who maintains you have to know C to be a programmer everyone else was just contributing their thoughts on the different languages. I think most people have made good points even when their opinion on your choice of language differs from mine.

I don't think anyone suggested that you started a flame war....

Here's a little truism about fora such as LQ: Sometimes you get less than you asked for, and sometimes more.....

PS: I'm a mod, I've seen it, not closing it ......yet.

careful---I think you meant to say:
"A purist with possible evangelical tendencies"

You're right...my fingers slipped

Oh, I too had to understand/fix/discard code written by others.

And in a sense bad formatting in such code may be a blessing. This is because I intentionally reformat files in such cases manually, at the same time doing in my head initial code analysis and understanding basic things about the code. And after that the code is formatted the "perfect" way - because it is my way.

...

C++ <-> Python - of course, Perl is in the middle . And there is more than one OO model which can be used with Perl. And with functional approach/anonymity encapsulation is the way of living in Perl, i.e. by default things belong to scope.