Hacker News Reader

Comment by danso | Hacker News Reader

FWIW from the prelude:

> Originally created during the Python 2.4 days, we've tried to keep the content universal and exercises relevant, even for newer releases. As mentioned on the setup page, this material covers Python 2. While we recommend "avoiding" Python 3 for now, recognize that it is the future, as all new features are only going there.

View on HN

I remember my freshman year of college, I was told how some 60% of what I learn will be out-of-date by the time I graduate. I always thought that was a ridiculous statement. But nevertheless - the prime example was Python. At the time we were being taught Python 2.7 or so, we were told how by the time we graduate - most of the world will be using Python 3.X

Much less than 60% of my Python2 knowledge when I upgraded to Python3, more like 5% I would say, even then.

Since computing is a young field, that gets less true every year. I would say less than 60% of what I learned 15 years ago is out-of-date, but talking with my dad, it was a much higher percentage when he got his MS in the early 80s.

I am willing to bet that computing is a much older field than you realize. And the amount of change is much more than you're aware of.

Furthermore I do not believe that the rate of change will stop in several lifetimes.

On how old computing is, automated computing using punch cards was invented in the 1800s. "Programmer" has been a viable job title since WW II. Essays about programming written 50 years ago are still relevant today.

On how much things change, that depends on your environment. Across the hall from me there is a company of COBOL programmers. A lot of what they need to know hasn't changed since before I was born. Sitting next to me are people implementing code in node.js with react. Most of the libraries and best practices that they are trying to follow were invented in the last 10 years. I'm maintaining a legacy project that isn't using any technology less than 10 years old. The experience of how much things change is highly dependent on what exactly you are doing.

However I'm minded of what my sister said about nursing. When she started as a nurse she was told that on average half of what she knew would be out of date in 10 years. This is why nurses need continual retraining. This was ridiculous to her. But guess what? When she retired it was true, every 10 years about half of what she knew went out of date! Between new research, new technologies, new best practices and so on, nursing never stopped changing. And hasn't stopped changing since modern nursing was invented in the 1800s.

If a profession so much older than ours shows such sustained change, and our profession has shown an extended sustained rate of change, why would I expect this to change? The truth is that I don't. Sustained change is more the rule than the exception in technology, and none of the fundamental reasons why have changed.

Some knowledge is core - the ways that programmers get defensive and have trouble accepting their own bugs and mistakes has not changed since before I was born - and others change constantly. Learn the principles. Learn what is core. And be prepared to continue learning trivia forever because programming is continuing to change.

I feel like that means they were teaching from the wrong perspective. All of my cs classes were about principles, and the language was incidental, and I don't feel that the things I learned have gone out of date at all.

Edit: On a related note, I don't think python is a very good first language, despite it being my absolute favorite, because it uses kind of a mishmash of paradigms.

My university had an interesting approach to that problem - where it was necessary or useful to use real code, different classes were deliberately taught in different languages (mix of Java/ML/C/MIPS/Verilog).

What language would you say is a good first language? To me, Python seems very readable to a new programmer without having a capability/tooling ceiling that you will eventually reach, which seem to make it a decent choice.

As much as I hate to say it, probably C. Actually, I wonder if there are any toy languages out there that are basically C without raw pointers? If so I would go with that.

Yeah, for some reason Google is adamantly opposed to adopting Python 3. I have no idea why. It's clearly much better, more well designed, etc. I mean come on... print as a statement rather than a function call? That alone should be enough to make the decision I'd think.

Google has billions of lines of code, a non-trivial amount of which is Python. Moving to Python 3 would require an all-hands-on-deck massive effort.

You can begin a transition without moving everything at once, or even ever. Start with a policy that all significant new efforts should strongly consider Python 3 (including porting any dependencies). Keep a "scoreboard" for un-ported dependencies and add a point every time it's decided to keep a new project in Python 2 because porting a certain dependency would be too much work to identify the bottleneck. Invest in porting those. You should see the proportion of Python 3 to 2 go up. Eventually, you're left with a relatively small set of legacy stuff in Python 2, and that's probably fine to keep like that.

This works badly with monorepo and uniform build systems. Same reason why Google is still on cpp11.

That said, you can (and Google has) invest in things that make porting easier. Enforce future imports, use six, etc.

Google is on cpp11?? Impressive. Last time I read their guidelines, it read like a more conservative version of Bjarne's book from '98.

Python 2 was the norm when they adopted Python internally, but I think it's inaccurate to say that Google is "adamantly opposed" to Python. They've done a good job in making their most popular open-source projects 3.x compatible, such as Tensorflow: https://github.com/tensorflow/tensorflow/issues/1

I think the problem is that Python 3 is a different enough language that it's hard to consider it an upgrade, adapting existing code to it really is a port (although six and __future__ help).

And if you're going to port, it's not a question 2 vs 3, it's a question of 3 versus many other languages, chiefly Go.

Python 3 has some architectural decisions that make working with data difficult; mostly ///my opinion/// is that it completely botched Unicode handling.

The idea of data being encoded should be an extremely high level idea, with foundations that are supported by the internal libraries and maybe even compiler.

I feel that golang has a much more data-structure friendly view of Unicode.

    * The ancient paradigm of bytes remains
    * Strings are immutable sequences of bytes; but are trivial to cast back and forth.
    * 'runes' (distinct Unicode code points) also exist

However to actually validate or do anything fancy to a Unicode sequence a programmer would need libraries from https://godoc.org/golang.org/x/text which shows how truly complex /proper/ handling of Unicode data is; instead of just the simple copy / append / search (is this inside of / a match to it) operations that make up 99% of my handling of Unicode data.

Have you worked in Python 2 unicode?? Over half of the work and debugging the search engine service management team I was on was fixing unicode document injesting.

But I agree, making unicode part of the language is very dumb. I just wish they would give up as it has never been good.

What about Python3's unicode handling is botched?

It optimized for O(1) indexing to Unicode scalar values instead of optimizing for more useful things. Also, even though the API semantics are UTF-32, the storage may be USC-2 or Latin-1, so there's a surprise performance effect when a string gets it first non-Latin-1 character or its first non-BMP character. So much for O(1) behavior.

The best in-memory representation of Unicode is UTF-8. No alignment issues, ingest "decode" is mere validation and output "encode" step is a no-op. Space requirements are favorable to common computer language syntaxes. Byte-wise lexical sort matches code point-wise lexical sort.

However, since "narrow builds" of Python 2 already used UTF-16 which allowed for things like bridging strings with Cocoa, Python would have done well to stick to UTF-16 and get rid of the "wide builds".

Not having both "narrow" (UTF-16, Python 2 on Mac) and "wide" (UTF-32, Python 2 on Debian) is an improvement, though.

Python strings are immutable. The only time a string can get its first non-Latin-1 character is at construction time, which is necessarily O(n).

I don't think it has to be anything more than inertia. They're a massive company that has millions of lines code running in production for a whole chunk of languages. Making a change from python2 to python3 probably seems like more worth than it's worth. It is also a fairly googley problem to think that the way Google does things is automatically superior in all cases. So, since googlers use py2, why shouldn't it be good enough for everyone else?

Dropbox, which is a much smaller company and codebase than Google, is (as far as I've heard) still on Python 2, despite having hired Guido van Rossum away from Google to work on static type annotations for Python to fix all the str/bytes stuff and related incompatibilities in their codebase so that they can move. Certainly this was the status in mid-2016, about four years after they hired van Rossum: https://us.pycon.org/2016/schedule/presentation/2266/

The difficult engineering problems in the world aren't greenfield engineering.

print as a statement vs. function doesn't carry that much weight when you have tens of millions of lines of currently working code to migrate.

> print as a statement rather than a function call? That alone should be enough to make the decision I'd think.

I seriously cannot tell if this is a joke or not.

I don't think this is true, as a python user at Google. There's momentum that has to be shifted, and that can't happen overnight. But it is absolutely a work in progress.

The writing is on the wall for py2 at Google, and in some ways it has been for years.

Reply on news.ycombinator.com