Indeed, I was thinking the same. If a student already has some CS background, he/she should be allowed to skip intro courses. We already do that with college assessment and AP programs for subjects such as Math, Chem, Physics and English Writing. So why not with CS? Put CS students through a comprehensive series of tests, and depending on the results, they should be allowed to skip intro-level courses (either granting full credit, or letting them take more advance courses for those credits).

Not just spreadsheets, but also side-by-side diffs. With my two monitors, I keep one portrait and one landscape. If I have one, I simply flip back and forth depending on the task (trivial on Windows, sometimes not so trivial on Linux, but still.)

I have two monitors, one portrait for code view, one landscape for all other kind of shit (in particular to look at side-by-side diffs). And when I work with three monitors, I keep two protrait and one landscape. Basically the formula is one landscape, and everything else portrait.

For anyone who cares to work with code on a daily basis, this is just common sense. I cannot believe that developers have to make a case for it.

This is like "making a case to wipe your crack after taking a dump, and not before" kind of thing.

I don't because I do not see a distinction between development and management/hr culture. It is one. You, the generic "you", either have the culture, or do not. You either keep it, or you let it devolve.

Even within large organizations, different departments will have different cultures, some better than others. The question (the one I never made) is not whether such a good culture can be kept by every organization of any size.

The question is, when a culture supports such a culture, can it handle self-imposed limits on code features. The answer is yes, and I've worked in very large organizations (10K+), on projects with product code bases spanning millions of lines and histories of many years.

I've seen it work. I have no reason to lie or make bullshit.

You either believe my personal anecdote, or you do not.

It is as simple as that.

Uh, not home owners, but owners of rental properties. Whether the conflation of terms is accidental or if you are being deliberately obtuse, only you know.

Not homeowner. Renting landlord. The later do not have the freedom to choose whether to keep their rental units safe or not. Do we really need to have a discussion of why?

Homeowners, then buyers, as opposed to reality (landlords and renters.) You can frame the problem in any way you want, but that does not necessarily yield a valid argument.

This me-me-me-me-me-owner-buyer-me-me-me-me-NIMBY-BAD-GUBMINT-me-me-me shit really gets old.

Bingo. That is an ever better solution from the point of view of stopping things absolutely. The only problem I have with not implementing them is that we only find this out till linkage time. For large projects, or for testing, this can be a drag.

I much prefer to implement them private so that any code that accidentally attempts a copy gets stopped when the compiler hits the compilation unit (which could be right off the bat and closer to the code, as opposed to having it delayed all the way to the end during link time.)

That is absolutely true. Hard to say what it has to do with everything since (well-written) modular and procedural programming also deals with state change via ADTs and associated manipulator APIs. Think Ada's private and limited private types, or opaque pointers whose examples abound in Ada and C/C++.

Code reviews, scanning tools, processes, guidelines, stuff that programmers worth a shit abide by, that helps with that.

Non-trivial projects that are 1) run well, and 2) staffed with competent programmers will use any and all of the tools I mentioned above. For example, I can use plain ints to pass pointers in C or C++. It is a feature. But we can have coding guidelines that prevent that, and code reviews and other static analysis tools that act as gatekeepers.

If you have #1 and #2, no problems. Lack either, then problem. I know, I've seen it when working in small and (very large) C/C++ and Java projects.

Software process management + developers == culture.

A good development culture will police itself against that with relative success IN ANY NON-TRIVIAL project.

A crappy development culture will never be able to police itself like that EVEN WITH TRIVIAL projects.

Been there, done that. Apparently you haven't.

See my responses above. What this tells me is that either you have never worked with an effective development culture and/or you have very limited experience with quality development, code reviews and automated static code analyzers.

I used to believe in this until I had to work on both. Although one can compile best-practice C with a C++ compiler (sans the gotchas), that glosses over the idiosyncrasies of each language. C does not have initializers as in C++.

More importantly, it does not have references, type-safe casting operators and its template language is not turing complete as in C++. These differences will never go away, and these differences alter completely the type of design and implementation of your code and your abstractions.

Not to mention the C++ rules of PODs versus everything else which affect how we link C code with C++ code (and viceversa.) And modern C++ heavily uses templates in manner that makes the language resemble something else entirely. Whether that is a good thing is highly subjective, but whatever.

So from a practical point of view, it is sane to treat both languages as fundamentally different.

When we program in a language (be it Ruby, Java, C or C++ or whatever), we ought to do so in the idiomatic way that naturally exploits the best capabilities of the language. So with that in mind, we cannot treat C and C++ as the same language (and it is not quite accurate to compare modern C++ as a superset of the former, regardless of historical evolution.)

I do believe, however, that is very important, if not fundamental, to understand C semantics to use C++ effectively. The fundamental semantics behind the primitive types and control structures remain more or less the same. And I've always found that C++ programmers without a good background in C tend to make certain mistakes when they need to operate with pointers (since they are so used to work with references.)

Furthermore, integration of C with C++ is not an uncommon task, and development of C++ code with that in mind is paramount. It is very hard to do that without a good understanding of C.

You need to progress through modular programming and abstract data types. Then OO makes a lot of sense. Well written, highly modular C code with good abstractions tends to resemble well-written C++ without operator overloading in my experience.

Hell, well-written modular programming resembles well-written OO programming (since the later can be seen as a natural extension... or conclusion of the former.) Well-written procedural code must exhibit characteristics of modular programming.

What happens with C++ (specially at the beginning of its development) is that everybody tended to use every single goddamend feature, abusing operator overloading (and later templates). So C++ became "equivalent" to "overloading gotcha and magic-behind-the-curtains" soup smeared over a tangle of classes in an inheritance tree from hell (in many ways, not dissimilar from Java at the beginning with its own gotchas.).

One can program clean C++ with very simple semantics, using operators to the bare minimum, using templates judiciously, knowing when to use virtual and always implementing the big three (default constructor, copy constructor and = operator.)

If you can modularize your procedural code and how to layer your abstractions, then you know how to split your code into modules and classes. You know how to encapsulate and delegate responsibilities. That is key for developing cleanly in C++ (or Java or C#... or in any language for that matter.)

You are absolutely correct. That, a lack of begin/ending tokens, a lack of a ternary operator, and (pre Python 3.x), limited lambda expression support are my biggest gripes with the language.

Like... missing a semi colon.

Depends on the IDE (I typically configure Eclipse and Notepad++ to show whitespace). Hell, even VIM can let you do that.

Even without those settings, whitespace is not invisible either. And the rules are not that spacing must be neat and tidy, but simply that they are compatible within and among blocks.

True that people can accidentally mess it up (hell, I've done it myself)... but shit man, unit tests? CI? Testing code snippets in a REPL when you have one? There is not a goddamned excuse NOT to do any of that regardless of the language that you are using.

The only way for this rules to cause havoc is for people that are doing fire-and-forget programming. That is all.

I'm not defending, I'm explaining and quantifying the problem, and I'm proposing, based on the evidence I've seen in real life, that continuous pain with indentation rules in Python have to do with people not doing shit they are supposed to do (continuous testing, coding small, testing small, refactoring, etc.) Shit that they are supposed to do in any language.

So, indentation rules are simply compounding problems that are more fundamental and closer to that area between the keyboard and the chair. I'm not defending, I'm explaining.

The add-ins are not. The app itself is.

Most people do not. Do you really think the average smartphone user is going to be invest hours away to thinker and bypass such measures just to avoid paying $0.99 (the average price of an upgrade/add-in)? Most people, even tech savvy ones do not.

The sheer scale of the market makes it a number game. It doesn't matter if some people bypass the measures. There are potentially millions who do not, and of which a small fraction might pay for the upgrade. A small fraction of a very large number might still be large enough to get your ROI back. That is how it works.

Which is easily solvable by setting spaces-for-tabs in your editor (and which I do when working in Python, ... or Java... or C/C++... or pretty much everything because that really solves a whole bunch of issues.)

And violations of spacing/indentation rules are trivially caught by with automated testing/CI, which I do with Jython... or Java... or even C/C++ .... or pretty much everything whenever possible because it is the sane thing to do.

I've only been doing Python for 2 years, including C-to-Python bindings using Python 2.7x, Java-to-Jython/WLST integration (with Jython/WLST being based on Python 2.2), and a tiny bit of Windows automation with IronPython.

Most of my background is Java for enterprise development and C/C++ for embedded/system-level development.

As such, I initially I stumbled across some of the nuisances with Python, the spaces, the lack of a stack trace on exceptions, or the fact that exception hierarchies are slightly, but oh-so-different between Python 2.2 and 2.7. But past those stumbles, I simply use tool configs, procedures and coding standards to deal with them.

And that is the same when I do Java or C++. Each has their own gotchas and effective Java/C++ developers simply do the same - use tool configs, procedures and coding standards to deal with them.

Why would anyone mix tabs with spaces. Use one or the other, regardless of whether you do Python or not. If I see a code base in any language that has that shit mixed up, I know I'm bound to find some other stupid shit in the code.

Why? Because mixing tabs with spaces all over the place, like spelling errors, lack of meaningful comments and/or deeply nested code (arrow anti-patterns), these are all proxies for bad coding practices.

I originally found Python indentation rules to be annoying. After all, how hard is it to auto-indent from an IDE or a command line (or force an auto-indent of code before checking in, or en mass before merging back to the trunk)?

But you know what, people are idiots, and I've learned IN GENERAL not to expect them to write clean code (nor tell clean code from apple pie.)

It is still possible to write horrible Python code, but it is a lot harder to do so in it than in Java or C++ or C#. I would still have preferred to see Python having start and end markers for blocks (a-la begin/end or curly braces) on top of indentation rules.

But it is still a good compromise. Hard to see where code blocks end? Increase indentation. Better yet, refactor that shit out. If I see I have a harder time telling the end of a block, chances are that block is already large (time to refactor out), or that there is a lot of code around it (time to split it into better levels of abstraction).

You know, the kind of stuff we are supposed to do in any language anyways.

Besides, accidental violations that render Python code invalid, those things are trivially solvable by doing shit we are supposed to be doing anyway (namely, avoiding mixing tabs and spaces, automated testing, keeping code small and at least dry-run your shit before committing it to source control.)

I'm not saying programming in Python is Nirvana (for some things, it truly sucks.) But some of the things people complain about, they are just asinine complains for shit that broke because, on a fundamental level, they are not following good industrial practices IMO.

Police officer finds 9-year old girl, unconscious behind some bushes IN A PUBLIC PARK, completely nude and obviously the victim of a sex assault. The scene is captured on camera.

Using this real life scenario, care to run your "I paid, I want to see it" rant by me again? Are you really that obtuse or unable to think analytically that you fail to see how your idea is utterly idiotic?

OMFG, who the hell would want to work in IT for less than $42K a year? Because if $42K/year is the median that would suggest half of all IT technicians are getting paid peanuts. Unless you live in a low-cost, rural small city or town, less than $42K/year is very goddamned low nowadays.