Hacker News Reader

Comment by CJefferson | Hacker News Reader

Which other languages?

My C89 code, C++98 code and Fortran 77 code all still compile on a modern Ubuntu, and none of these are expected to break any time soon. The compilers just support multiple versions.

View on HN

I'd strongly suggest watching "What is C++" [0] from this year's cppcon. There's a lot of good content, but the relevant bit is that c especially (remember, c++98 is younger than python2!) values backwards compatibility very highly. This is sometimes useful, but it has costs. Performance costs, safety costs, and especially ergonomic/complexity costs for future development (the kitchen-sink-ness of modern cpp).

People aren't wrong to make different tradeoffs than you. Especially given that strict backwards compatibility is impossible (especially in a language like c/++, people will rely on things that aren't intentionally public, because they can introspect your bytes).

Compiler changes break code all the time, it's just almost always semantic and not syntactic. I find this amusing, since the syntactic changes are usually easier to detect and fix.

And python2 still works, it just won't get new features.

[0]: https://youtu.be/LJh5QCV4wDg

> And python2 still works, it just won't get new features.

Probably more importantly, it wont get security fixes.

Yeah, Python 2 will still work. Ita not like there's a kill switch or anything. It just wont receive any official or supported updates. Effectively, Py2 will be abandonware.

I have been extremely critical of the P2 to P3 drama, but to be totally fair, things haven't been as smooth as we like to remember in C++ land. While the c++11 standard (and successors) are highly compatible with c++98, most compilers at the turn of the millennium had questionable conformance and each compiler upgrade to a more recent and strict version was a lot of pain (I still remember the pain when GCC started enforcing two phase lookup).

I agree things could be better in c++, but never was never anything like python 3, redefining / , or removing printf. Also, usually once you fixed your code, it still worked in older compilers (although not always).

While I generally agree with your comment, Python generally gives easily accessible migration paths. Regarding your division example, you could import from __future__ integer_division (maybe it was another name?) Since I think Python 2.5 before it became the default in, I think, 2.7.

I wish the wallrus operator was available as a future import, bit it's not.

Also, Python never had printf. It had a print statement; print became a function in Python 3. Yes, its a syntax change, but its for the better. Having print as a first class statement expands its utility and versatility.

Removing printf was an example of a change C++ could make of similar effect (they could argue you should be using cout, so you don't need it). Sorry it was unclear

Yes also often the compiler would tell you exactly what to do (90% of the time it was a missing typename).

I don't understand people complaining about the removal of the print statement. Switching that to a function call is the easiest part of porting to Python 3. You don't even have to do it yourself, just run 2to3. If you're complaining about that I feel like you're just looking for something to complain about.

You are right. The print statement is easy to complain about. My main issue was all the strings/unicode changes, which were hard to track down as often code would continue to work until a non-unicode input came in, when it would error. Debugging all those issues took ages.

This is a good point, because of the dynamic nature of python, the incompatibility is not always visible at compile time (parse type?), but can happen at run time and only rarely.

You need very good test coverage.

Those languages also don’t have massive runtime libraries with thousands of potential bugs that may even be security holes. They are not comparable in the slightest.

Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9.

Tcl 8.3 to 8.4 when they added unicode support as well.

I believe PHP did similar thing.

> Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9.

It was a major version release; Ruby, through 1.8, used an version numbering scheme similar to the old Linux version numbering scheme; odd second digits were development major versions, even second digits were stable major versions.

1.9 was a slight break because it was a major release but, IIRC, seen as stable.

Reply on news.ycombinator.com