Hacker News Reader

Had Python 3 stuck to relatively simple changes like converting to the print() function, making a few libraries more consistent, etc. then it would be closer to the C++ compatibility-breaking changes proposed here. Instead, Python 3 went far beyond things that were easily convertible and it isn't surprising that adoption was greatly slowed.

C++ has atrocious defaults, where you have to add a bunch of keywords and do all these things just to make the simplest classes do the "right" thing. It's long overdue for some new behaviors.

Adding things like "override" to existing code has been an absolute joy. It has already prevented errors during maintenance in projects at work. It is well worth a few days of ugly revision control logs.

There are lots of ways to smooth a backward-incompatible transition for C++ on a larger scale. For instance, they could enable it on a file-by-file basis by having some new declaration like "using c++17;" (or better still, require only the old, out-of-date files to add this declaration in order to continue compiling).

The print function was one of the worst offenders. It is a pointless vanity feature (Guido prefers the new syntax), hardly worth the economic cost of upgrading all Python code in existence to adopt it.

Actually, he prefers the old syntax. The new syntax is there because he got swayed by practical considerations. For instance, back in July 2000, there was this:

https://www.python.org/dev/peps/pep-0214/

Where he basically said "Maybe print should be a function, but... nah".

Two years later, he says he regrets it:

http://legacy.python.org/doc/essays/ppt/regrets/PythonRegret...

And the benefits are explained here:

https://www.python.org/dev/peps/pep-3105/

Could have had the best of both worlds by giving the print function a different name from the print statement (e.g. printf for the function). Then the print statement could have been deprecated gracefully. (And then the print function could have been renamed print if anyone really cared at that point.)

Or alternatively they could have remove the mandatory parentheses around function calls, and kept the old syntax and made print a function.

(Sorry, trolling. ML-style function call syntax would clash a lot with other parts of Python.)

I don't know ML, but I really do wish Python had this feature. The only problem I see is that this makes it hard to refer to a function without calling it (see below). How does ML solve this?

    def g(): return 5
    assert g() == 5
    assert g != 5

Without parenthesis, how can the language distinguish the last two lines? How does ML do it? Would the same trick work in Python? I know Ruby has optional parenthesis, but functions aren't quite as first class there as they are in Python, which is why the have Proc and whatnot.

Your example, g actually takes the unit tuple, and returns 5. In ML, in general, you have to disambiguate with parentheses sometimes, but the compiler is very strict about types, so it's usually pretty easy to tell where they need to be.

Look here: http://try.ocamlpro.com/

Try this code:

let g() = 5 g() == 5 g != 5

First line defines the function. Second line should evaluate to true. Third line doesn't type check because a function is not the same type as a literal.

Exactly. My favourite ML-style language is Haskell, and there we almost never want to call a function with the unit-tuple as an argument.

Haskell does differentiate between IO-actions and functions. Here is an example:

    main = do
      let printFive = print 5
      print 1
      printFive
      print 6
      printFive

Will print

The type systems helps enormously keeping things straight here, but the basic concept would work in a non-statically typed language, too.

> the basic concept would work in a non-statically typed language, too

How? How do I compare. say, two functions for equality, without comparing the return value instead?

Oh, I should have been more explicit:

The decoupling of function calling and IO actions can work in non-statically typed languages, too.

Your question concerns a different topic. To give something like an answer: that problem can only occur with `functions' of zero arguments. Haskell sidesteps the issue by requiring all functions to have exactly one argument.

Okay, that's cheating. Or rather, that's fine for them, but is no help in porting this idea to Python, which definitely has functions of zero arguments, and they aren't even that rare. (Although comparing functions for equality is rare, but it should at least be possible.)

The print must have been the easiest function of them all to convert automatically with 2to3 since in py2 it's a language keyword, it's not possible to assign it to a variable, you can't construct it with strings to __dict__ lookups or any other types of dynamic programming hacks. If people can't even convert print then the migration is quite a lost case.

Second of all it's such a silly syntactic difference that if people are honestly bothered enough by it to stay on python 2 i just lost all hope for that community. Besides, the reason for changing it was not vanity with syntax, it was to move it from a language keyword into a standard function so it could be used in all the ways described above, marvys links describe this better.

After you run 2to3, you still have to go through the changes and manually audit them for correctness.

Since pretty much everything has at least one print statement, its removal ensured that everything had to be converted.

If Guido&co had tried to maintain backwards compatibility, they could have more easily made the important semantic changes (like unicode strings). Users would have been enthusiastic to upgrade, instead of angry that their time and money was being wasted on irrelevant syntax details.

If everything has at least one print statement you are doing it wrong. Functions in modules should return data, it is then the task of the view to present this data, which could be as simple as printing it or could involve rendering it to html, pdf, a gui, sending an email or whatever.

People know that global variables are a bad thing but fail to realize that print "foo" is essentially equivalent to global_variable_output_buffer+="foo". It simply shouldn't be scattered around everywhere.

This is not just academic nonsense, I was once given the task to parallelize the code in a large python code base, and to send the output in an email instead of printing to console. It would have been an easy job but a lot of the code was using print just the way you describe it causing intermingled output in the console when run in parallel.

It is one of the easiest changes to adopt though. I added a "from __future__ import print_function" to 2.x code and was able to switch file-by-file without a problem. As a function, occasionally it is more verbose but it is also a lot more flexible (they can add anything they want as new keyword arguments) and it's compatible with any other feature of the language that would use a function.

> I feel like I'm looking at a laundry list of mostly minor, tiny issues, that are a "solved problem" in the form of existing warnings. I can crank them up to errors as I modernize a codebase.

So the perspective you might be missing is that there absolutely are broken or useless parts of the C++ standard. There has to be a way to fix those if we want:

1. Continued improvements to the C++ language

2. Compilers that aren't needlessly complex to implement and support

3. Fewer weird edge cases and therefore fewer bugs when people miss them.

4. A language that can be taught to you instead of drilled into you.

A case in point is trigraphs. They are an almost entirely useless feature that requires an extra compiler pass. They cause real bugs that confuse and surprise all but the most grizzled C++ devs (myMap["crazyUserName!!!??!?!"]). It was like moving heaven and Earth to get them slated for removal in C++17.

It is not acceptable that things like this are this hard to get deprecated and removed. There needs to be an accepted, uncontroversial way to identify cruft, mark it deprecated, and eventually remove it from the language.

So... why the minor, tiny issues? Because we're not ready for the big ones yet. Let's get some minor issues under our belts and then we'll figure out how to deal with bigger ones.

> So the perspective you might be missing is that there absolutely are broken or useless parts of the C++ standard.

I'm not missing it. I feel C++ is a broken enough language that I generally prefer to use others. That said, C++ is my day job, so I get to feel the burn and wish it weren't so broken.

As a result, I'm all for getting rid of useless parts of the C++ language. But backwards compatibility is not useless! I'm willing to sacrifice minor, "theoretical" backwards compatibility for relatively minor reasons - I don't think I've seen any code broken by >> being interpreted differently in C++11 in templates, for example. I only know of one case where trigraphs were used intentionally - and compilers have been disabling them by default and warning about them for quite some time now (to the point where I don't really care if the C++ standard is fixed, because C++ in the wild is fixed.)

But getting rid of NULL and 0 as pointers? Breaking overrides missing the override keyword? Every C++ codebase I know will break massively. It'll make C++ification of a C codebase even more of a massive pain in the ass. Pass. Make them enabled warnings by default instead. Enable warnings as errors when you can. People are already doing this for you: http://codepad.org/R5XyUby2.

--------------------------------

RE 1: Continued improvements to the C++ language are occuring. C++11, C++14, and C++17 are all introducing new stuff, and providing better options for securing your code. This does not require breaking backwards compatability. Unfortunately this goes against points 2, 3, and 4, for reasons that have nothing to do with what's been listed here.

RE 2: I don't see anything in this list that would help significantly there. If anything, mandating more diagnostics about override keywords will complicate the compiler further.

RE 3: So lets add some sequence points that make parameter evaluation order defined. Lets get rid of those type aliasing rules that every large codebase runs afoul of. Lets do some high impact stuff that will catch some really nasty edge cases that, realistically, will fix more codebases than it breaks.

...but none of that seem to be on this list.

RE 4: A lost cause that's getting worse. Adding a bunch of caveats that "oh, except in C++2x you can't do this thing that's in decades worth of C++ tutorials, examples, and codebases - including most of what you've seen online" isn't going to make the teaching problem any easier. It's going to make it worse.

----------------------------------

"So... why the minor, tiny issues? Because we're not ready for the big ones yet. Let's get some minor issues under our belts and then we'll figure out how to deal with bigger ones."

We've already got lots of experience under our belts with fixing minor issues. auto, >>, template exports, throw() statements - all the way back to the very first standard, which eliminated implicit conversions from int -> enum, void* -> t* , and for loop scoping - with all the breaking of C or prestandard C++ that this entailed.

What will it take for us to be "ready" to deal with things like parameter evaluation order being unspecified - and thus at the mercy of your compiler version, flags, and phase of the moon? Fixing that would break no code that wasn't already broken, and eliminate a massive source of unspecified weirdness that I still struggle to explain to other C++ developers who have been coding for years.

I still have to carefully explain the difference between operator precedence (how a() - b() - c() is parsed), and sequence points (which define the evaluation order of a(), b(), and c() - or more accurately don't). They point to && and ||, and I explain how they - along with "," and "?:" - are special cased by the C++ standard to define additional sequence points that just happen to match the operator precedence rules - unless you overload them, so never do that - and by the end of it, I've either blown their minds or they still don't quite believe me.

Showing them how std::cout << i++ << i++ << i++ << "\n"; changes behavior depending on compiler flags tends to help - although that's cheating as there's additional unspecified (or undefined?) behavior for modifying the same integral multiple times without an intervening sequence point...

> It is not acceptable that things like this are this hard to get deprecated and removed.

Not only is it acceptable, it's preferable. What's not acceptable is when it's IMPOSSIBLE to get things deprecated and removed.

The problem with python is that they broke both source-compatibility and library-compatibility at the same time. If c++ breaks source compatibility but still allows calling external C-libraries or older c++ libraries nobody would even blink.

> But I feel like I'm looking at a laundry list of mostly minor, tiny issues, that are a "solved problem" in the form of existing warnings.

I'm not aware of warnings for uninitialized variables in constructors. Can you clue me in how to get these on in Visual Studio? I'm using a third party tool that can detect uninitialized scalars only and would love to have the extra scanning.

Sadly Visual Studio's compiler has no warning I'm aware of. Using /sdl will forcibly initialize all your members however - I guess Microsoft's approach to the problem is that fixing it for you is better than giving you ignore-able warnings.

There are third party tools - such as cppcheck - which should catch uninitialized members however.

I generally also compile with clang, which catches a lot of additional stuff for me.

And here's a random John Carmack link noting some of the static analysis tools out there:

http://www.gamasutra.com/view/news/128836/InDepth_Static_Cod...

I've been playing around with clang's Address Sanitizer all day as well, catching buffer overflows and underflows left and right in a janky old codebase I was suddenly thrust into recently...

We are (slowly...) doing the same thing across our codebase. The tool we use -- PVS-Studio -- just introduced checking for uninit'd scalars so we are grinding those down and doing eyeball checks in the ctors, but I was hoping for a more reliable method for the latter portion.

Thanks for /SDL! This looks like it may be very promising: http://blogs.microsoft.com/cybertrust/2012/06/06/warnings-sd...

At the very least that would help remove random behavior at the cost of speed (if I understand correctly). I'll have to sleep on /SDL and do some perf testing come Monday. I had really wanted to use /analyze (https://msdn.microsoft.com/en-us/library/d3bbz7tz%28v=VS.100...) but it crashes! D:

Unfortunately, I'm rooted in Windows SDK and I don't think clang supports that. The Microsoft Application Verifier has some run-time memory checks, so I'm not totally unarmed.

I looked at PC-lint doesn't have complete support for C++11 yet and I'm worried about the rate of false positives. I had not heard of cppcheck, so I'll have to give that go since it looks free.

Thanks for the info!

> a magic wand that makes source-to-source changes on a 100MLOC codebase trivial is pure fantasy

Actually, I have a slightly unrelated question: what are the issues that affect 100MLOC codebases that aren't so important for smaller projects? This is something people sometimes bring up, but I'm not too sure what exactly they mean by it.

The sheer size of the thing is a big problem.

Getting ~100KLOC of C++ compiling on a "new" compiler has been something that's taken me a few days before. Not too unreasonable.

100MLOC is literally 1000x the size - which extrapolating from "a few days" would mean it'd take me 8-14 years to fix up on my own were I to do it by hand. Or more realistically, the pace of change/growth on a codebase of that size probably outstrips my ability to convert it.

So now even a simple straightforward task such as fixing up technically nonstandard C++ syntax to standard C++ that multiple compilers will happily accept, is a task requiring either automated code modifications (scary!) or a large coordinated team effort. If 100 people working together are, optimistically, 100x as efficient as me alone - i.e. there's no overhead in terms of coordination and planning - it will still take them around a month to do the job via brute force.

A large codebase is more likely to contain older, less maintained code. It didn't get to be large overnight! ;)

So you're saying it's going to be even more effort to get compiling on a new compiler... that my 8-14 years estimate was low-balling the problem...?

;)

The problem was when someone budgeted for new code but didn't budget for this sort of maintenance. If there wasn't enough money for that, then the problem was the business plan.

Yeah, easy to say in hindsight, but we won't figure out how to budget better or call out bad business plans if we don't start recognizing it when it happens.

It's basically impossible to review and touch the whole code base if it's 100MLOC.

Unless there is a very good reason that convinces the business sponsors that it's OK to spend a few man years on it. Switching to a shinier version of the programming language usually isn't.

Are those projects likely to switch to c++11 or c++14 which dint have breaking changes? It seems unlikely. In which case why not break things?

Those kind of projects tend to use an ancient proprietary compiler that is no longer maintained.

Google brags about constantly doing large scale refactoring on heir codebase.