Live data from Hacker News

Thank You, Guido

blog.dropbox.com

251–260 of 388 posts

Re: Thank You, Guido

#251

Earlier quoted context omitted.

Honestly: the Java environment is exceedingly good at that. Backwards incompatible changes are truly minimal, and only those that are strictly necessary are added. And since Java 8 the language is pretty nice and offers good functional idioms. Of course, major versions of libraries still change. But there's no match with the JS approach.

> Honestly: the Java environment is exceedingly good at that. I would argue that the .NET Framework is way better. The way you can have multiple versions installed side by side and have the framework pick the correct one to run is awesome. Granted, you can do something similar with the JVM by mucking around with env vars, but it's not the same thing.

Well, .Net Framework is analogous to Python 2.7. It will never receive anything but compatibility, security, and bug fixes going forward according to MS.

The Future is .Net Core.

Re: Thank You, Guido

#252
post #83

Earlier quoted context omitted.

I'm starting to long for a stack that doesn't constantly change. Just set the features and that's it. Security updates only after that. It feels like a constant grind keeping up with everything. Containers, clouds, programming languages, operating systems, frontend frameworks, transfer protocols, it seems like it takes so much effort to just build something and keep it going. That Python 2 is still around doesn't rea…

Go has a compatibility promise from 2012 that they've upheld for now seven years. They are still discussing whether to change something in Go 2. https://golang.org/doc/go1compat

I came to say this. I learned Go in the early years and have come back after not touching it in years and it all still sounds eerily familiar and a lot of the basics I learned are still relevant to what I do.

Go is good at being Pythonic in some senses too. Some would say to a fault.

Re: Thank You, Guido

#253

Earlier quoted context omitted.

I used `async` as the name of a function decorator in some Python3.4 code, which then broke in 3.6 which introduced `async` as a keyword.

What was the level of effort to remediate that?

Probably around 4-6 hours of work all told.

We had to come up with a new name, do a find/replace, review the changes, test, fix a couple of issues because the replace wasn't perfect/complete, update the dev documentation, make a new patch release, and then create packages for the various supported platforms. Oh and looking back over it now, the filename had to be changed too, because apparently you can't use a keyword as a module name in Python either. So where the documentation linked directly to that file, that had to be updated as well.

[1] https://github.com/saulpw/visidata/issues/164

[2] https://github.com/saulpw/visidata/releases/tag/v1.2.1

Re: Thank You, Guido

#254
post #131
post #117

Earlier quoted context omitted.

The downside is that also means a lot of the core APIs are a huge pain in the ass to work with, especially relative to something like Python, and the “solution” to this problem ends up being something like Spring which has to use so much reflection and metaprogramming to accomplish what it does that it also relies heavily on exceptions for control flow. So without even getting into the other issues, debugging becomes…

Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements. You can't have it both ways, OTOH current JVM can still correctly run bytecode compiled by Java 1.0.1 (or maybe even earlier), so the backwards compatibility is indeed excelle…

Not necessarily. Java currently ships two date libraries, for example: java.util.Date and java.time.*. There are some duplicating classes like Vector from the old times and ArrayList from new times. There are two I/O frameworks: old I/O (File, FileInputStream, etc) and nio (Path, FileSystem, etc). While I don't like the particular way Java did that, basically you just have to ship all old versions and keep them working and ship new versions with some adapters to ease migration.

Re: Thank You, Guido

#255
post #2

"“When asked, I would give people my opinion that maintainable code is more important than clever code,” he said. “If I encountered clever code that was particularly cryptic, and I had to do some maintenance on it, I would probably rewrite it. So I led by example, and also by talking to other people.”" This is very sage advice.

The third option, of course, is to just comment your clever code to make it less cryptic. Yes, you can have your pie and eat it :)

The compiler doesn't care about comments, so in my experience comments quickly go out of date as others change the code and ignore comments.

There's nothing to say code can't be performant and legible. In fact I'm a bit confused what "clever" means here. Writing performant but illegible code does not take more cleverness than performant while legible.

Re: Thank You, Guido

#256
post #16

Did you notice this: "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3." Even the company that hired Guido is still heavily dependent on Python 2, and it doesn't surprise me at all; my own employer still has a lot of it in internal tools.

What surprises me most is his insistence on a non-incremental update. To this day, I have no idea what the logic behind "no intermediate steps" is. Codebases are written in Python that would dwarf Margaret Hamilton's famous stack. Why should everyone have to adapt the string functions to unicode and get rid of different-type comparisons and change syntax in one go, without a good way to sound out bugs inbetween?

Regarding string, the breaking change was necessary because it was a double-duty type, sometimes acting as a byte-array and other times acting as a string. Meaning some of its functions, like string.length(), gave a value that only made sense for string-as-byte-array, but not as string-as-simple-list-of-characters. More detail on Stackoverflow if you want (https://stackoverflow.com/questions/5471158/typeerror-str-do...). Anyhow the double-duty type needed to be disambiguated into two separate types, a breaking change.

Re: Thank You, Guido

#257
post #16

Did you notice this: "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3." Even the company that hired Guido is still heavily dependent on Python 2, and it doesn't surprise me at all; my own employer still has a lot of it in internal tools.

Don't they have source to source compilers that do the migration for you? I don't understand why the friction is so strong with python.

Unfortunately that's not as easy, because python is a dynamic language, and allows you to do some shenanigans.

For example in python 3 they actually made import statements more predictable they are now absolute by default, it was a bit ambiguous in python 2. Ignoring the ambiguity (which is a problem by itself) some people were creative and instead doing standard imports like god intended decided to do it dynamically using importlib, that can't be easily fixed if the file you're importing is a variable.

Another problem: unicode, actually most python 2 code is broken and it can crap out whenever you use characters outside of ascii. That's because it conflates bytes with text, python 3 makes the distinction strict, so you have to properly address it. Though for 99% of application user meant text, so perhaps this assumption could be made?

- division, in python 2 division worked similar to C, if both the parameters were integers you get integer as a result, python 3 changed it to be more what most people would expect, although python 3 also introduced // which had the prior behavior so I guess this could be automated

There are probably others too.

Re: Thank You, Guido

#258
post #16

Did you notice this: "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3." Even the company that hired Guido is still heavily dependent on Python 2, and it doesn't surprise me at all; my own employer still has a lot of it in internal tools.

What surprises me most is his insistence on a non-incremental update. To this day, I have no idea what the logic behind "no intermediate steps" is. Codebases are written in Python that would dwarf Margaret Hamilton's famous stack. Why should everyone have to adapt the string functions to unicode and get rid of different-type comparisons and change syntax in one go, without a good way to sound out bugs inbetween?

I mean, it seems like you are suggesting 3 incremental non-backwards compatible changes. I'm not sure how that's better. Nobody is going to sign on to the first two, so you end up with the exact same situation we have now, but took a more complex approach to get there.

Re: Thank You, Guido

#259
post #192

Earlier quoted context omitted.

Some of the syntax changes are barely different (print statement a function instead of a keyword, good) but a lot of new things are added that I would consider to be syntactic sugar (walrus operator, for example) that threaten to detract from the two biggest things that drew me to Python: clean syntax and obvious understandability.

Python allows imperative code with side effects in imported modules, as well as the "else" statement for "for" loops, so Python has never guaranteed obvious understandability.

Sure there are plenty of things that aren't perfect in Python, but I think it was the best of all viable candidates that came closest to that goal.

Re: Thank You, Guido

#260
post #152

Earlier quoted context omitted.

What is 'even' about this, given that Dropbox was founded well before the first version of Python 3 was released? Feels like less of a 'did you notice' and more of a 'let's have an interminable python2 v python3 thread no matter the topic at hand'.

Guido has been working there for 6 years yet only now is starting the conversion?

There was a blog article maybe a year ago, that Dropbox finished migrating client side code to Python 3.

He also spent large amount of time working on mypy (type checker) which my understanding is also is used for the migration to address unicode issues.

Post reply on HN