15 ms·
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
by not2b 7y ago
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.
- jredwards 7y agoDefinitely stood out for me. We haven't started that process either, but we're hoping to soon.
- peterwwillis 7y agoThere has to be a term for when the business builds something with one tech stack, and then later, as if it was totally by surprise, realizes it needs to replace the whole thing, for basically no added business-value, and this happens every few years. I mean, everyone has known they would have to do this eventually, but it just kept being put off, like the business is a bad procrastinator. And they all do this.
- whitten 7y agoI assume you are referring to "technical debt", unless you were being ironic and I didn't catch your irony emoji. (Is there an ironic emoji?)
- riffraff 7y agothere almost is, an irony mark or percontation point "⸮" https://en.wikipedia.org/wiki/Irony_punctuation https://en.wikipedia.org/wiki/Irony_punctuation
- badfrog 7y agoI don't think that quite applies. Technical debt comes from making choices that help you in the short term but cost you more in the long run (i.e. you're paying interest). Needing to move off a deprecated tech stack wouldn't really qualify unless there was a longer-term option available at the time you originally decided on your tech stack.
- slightwinder 7y agoWould it really be technical debt when we talk about transition from py2->py3? Technical debt is about the consequences of bad design. But py3 is more the consequence of growth and gain of experience. And for a company it is an external debt. I would call it more something like upgrade debt or time debt, as it's a problem that appeared because an external situation changed over time. Similar problem in that regard are operating systems which change and let old software behind, or in case of linux old packages not working anymore, repos disappearing, etc.
- bryanrasmussen 7y agopy2 to py3 would be handling the technical depreciation of value.
- peterwwillis 7y agoThis is different. Tech debt is a factor of letting things get slowly worse. Those things can be improved if you just work on your tech debt. What I'm talking about can't be improved or fixed, or higher-ups refuse to improve or fix it. Instead, it has to be completely replaced. It's like a Replicant with a four-year lifespan. You literally know it's going to die in four years, and nobody orders a new one until the old one is practically dead, and everyone has to rush to replace it.
- agustif 7y agoSounds like Egyptian emperors and pyramids
- S_A_P 7y agostack underflow.
- specialist 7y agoSame as every other industry. Being a CADD person, I had a lot of contact with A/E/C, facilities management, space planning, etc. Seems like everyone suffers legacy, neglects maintenance, prefers do overs. Cultural? Misaligned incentives? Bad accounting? Complexity catastrophe (when cost of any change outweighs benefits)? If someone knows, please tell.
- Spooky23 7y agoIt's always easier and sexier to build than maintain. All capital expense decisions are made at a point in time. Sustained operations are hard unless you have growth, because flat budgets are cuts given inflation, etc. Given the choice between stocking the toilet paper or doing a preventative maintenance on the elevator that may impact your successor a few years from now, what do you choose? The only times that facilities are run well is when there is a retired senior military nco in charge. Usually someone who was a chief of the boat in the Navy.
- specialist 7y agoI hadn't thought to mine knowledge from old seadogs, a la Peter Drucker. Thanks.
- bryanrasmussen 7y agoWhen I was working for Thomson Reuters WestLaw they sold the Danish/Swedish holdings and we had to move off the platform we had just spent a year moving onto (the sale happened about 7 months after the move was completed), we had one year to move off or we would have had to pay approximately $180,000 a month for using their platform (approximately as being represented in DKK not USD), of course we managed the move and also managed quite a lot of added business value.
- lostcolony 7y agoIt's just delaying maintenance. We're bad at recognizing that software requires maintenance and periodic updates/replacement, same as anything physical. Businesses think once it's written it will always just work...and that's true if the underlying OS and hardware never change, and the business never changes, and requirements never change. But even if it's a completely niche application whose requirements never change, after a while the hardware breaks, and we can't buy the same, and we can't license the old OS or it has documented problems that won't be fixed, so we have to use a new one, and we can't get the old software dependencies to work on the new one, etc etc.
- strbean 7y agoAdd to that list "and there is basically one guy still qualified to work on the system", which is practically the case now for old COBOL banking systems. See http://cobolcowboys.com/ http://cobolcowboys.com/
- hnick 7y agoThe software version of driving a car until it falls apart instead of doing more than the bare minimum to keep it running. It's not always the wrong choice but it's wrong to be surprised when faced with the expected outcome.
- 3pt14159 7y agoI'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 really surprise me. Many of the projects that were built upon it were built by non-developers (scientists, etc) that have no strong reason to keep everything current.
- evmar 7y agoGo 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 https://golang.org/doc/go1compat
- majewsky 7y ago> They are still discussing whether to change something in a backwards-incompatible way in Go 2. FTFY
- sadfklsjlkjwt 7y agoFortran from the 1980s is still supported...
- cik 7y agoHell, I fixed something in Turing last week. My eyes are still bleeding.
- pletnes 7y agoYou misspelled the 1960s.
- gowld 7y agoAnd yet almost no one chooses to write new Fortran code for applications. We rely on a few ancient critical widely used libraries like BLAS, accessed from non-Fortran programs.
- drakonka 7y agoI recently went through this process for the Python portions of our large central codebase. It took a few months but most of that was due to coordinating delivery and careful backwards-compatible rollout to multiple streams and licensees, guiding licensees through upgrading their own scripts, etc. Maintaining backwards compatibility wasn't as painful as I expected, but I'm happy that we got to deprecate P2 support on schedule - constantly testing both for every change review gets a little tedious!
- pvg 7y agoWhat 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'.
- azinman2 7y agoGuido has been working there for 6 years yet only now is starting the conversion?
- wil421 7y agoBusiness decisions. Dropbox needs to stay competitive especially with all the alternatives from FA(N)AG (removing Netflix). Many alternatives come bundled with other services. Not all companies have the big tech or mid/early stage VC money to throw around. Who knows what kind of other tech debt Dropbox has accumulated.
- pvg 7y agoIs the Python 2->3 process and decisions surrounding it an important part of Guido van Rossum's long career? Sure. Does the fact that Dropbox, quite predictably and like all businesses with large Python codebases has also had to deal with that transition add anything interesting, unexpected, "curiosity-gratifying" to a story about his retirement? I'm not seeing it. It's a long thread of stridently off-topic comments most of which aren't even about Python, never mind the dude's retirement.
- takeda 7y agoThere 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.
- papln 7y agoThe article doesn't say "only now". It says "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3. " "already" refers to "sometime in the past 6 years".
- darksaints 7y agoDon'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.
- gowld 7y agoThe friction is that people don't like changing thngs that work, and a lot of Python 3 is backported from future People migrate when the allure of Python 3 outweighs the hassle of juggling 2 versions. Naturally, people who grew up on Python 2 are more hesitant than people who started later on Python 3.
- kccqzy 7y agoYes but the source-to-source compilers do a fraction of the work needed to get a code base migrated. I've tried both the builtin 2to3 utility and many proprietary converters, including fancy ones that run type inference on Python 2 code and produce type annotations. None of them, as expected, can deal with the str/bytes split without manual intervention. Fundamentally the issue is that the Python language is too dynamic for static analyzers to fully understand the code and perform conversions. I'm not just talking about type systems, but also monkey patching, reflections, etc. What we really need is a tool that runs your Python 2 code, records types and other dynamic manipulations, and then produce Python 3 code. But I'm not aware of such a tool.
- darksaints 7y ago> What we really need is a tool that runs your Python 2 code, records types and other dynamic manipulations, and then produce Python 3 code. But I'm not aware of such a tool. That's a great idea, but it sounds pretty intense to implement. I ended up becoming addicted to ML-family languages pretty early (Scala, F#, OCaml, Rust) for a variety of reasons, but I never fully grasped how much strong/static types help for refactoring until I tried refactoring some Ruby code. I can't imagine trying to write an automated tool for the task.
- takeda 7y agoFunny that you mentioned it, because there's such tool and one of it orginates from Dropbox - PyAnnotate[1] There's also MonekyType[2] from instagram, but it only works on Python 3. I will also drop PyType[3] from Google, although this one tries to statically determine the types and when I used it felt a bit buggy. [1] https://github.com/dropbox/pyannotate https://github.com/dropbox/pyannotate [2] https://github.com/instagram/MonkeyType https://github.com/instagram/MonkeyType [3] https://github.com/google/pytype https://github.com/google/pytype
- depressedpanda 7y agoI, for one, would very much enjoy if posts about Python on HN didn't -- without exception -- contain threads about py2 vs py3. We get it, some people are unhappy that py2 is deprecated. But whatever sympathy I might hold for that viewpoint is drowned out by the incessant and unproductive whining I keep seeing here. Can we please move on now?
- draw_down 7y agoThat strikes me as rather churlish. Moving on is the whole point- even the company who employs the Python guy can't seem to move on. Seems relevant IMO.
- generationP 7y agoWhat 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?
- riazrizvi 7y agoRegarding 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-does-not-support-the-buffer-interface/34688434#34688434 https://stackoverflow.com/questions/5471158/typeerror-str-do...). Anyhow the double-duty type needed to be disambiguated into two separate types, a breaking change.
- papln 7y agostring.length() still doesn't make sense in Python 3 There's nothing "simple" about "list of characters" in Unicode. Discussed at length at: https://news.ycombinator.com/item?id=18154667 https://news.ycombinator.com/item?id=18154667 Here's how a Unicode export with 20 years of experience in Unicode explained it: https://blog.golang.org/strings https://blog.golang.org/strings > Some people think Go strings are always UTF-8, but they are not: only string literals are UTF-8. As we showed in the previous section, string values can contain arbitrary bytes; as we showed in this one, string literals always contain UTF-8 text as long as they have no byte-level escapes. > In fact, the definition of "character" is ambiguous and it would be a mistake to try to resolve the ambiguity by defining that strings are made of characters. > [Exercise: Put an invalid UTF-8 byte sequence into the string. (How?) What happens to the iterations of the loop?] If you aren't in Unicode, then "character" is the same as "byte" so splitting the types gets you nothing of vlaue. Assuming you are not implementing a low-level Unicode library, what's your use case for "list of Unicode characters" ?
- thijsvandien 7y agoDropbox could be much more dependent on Python 2 than the average user, because from what I've read, they use a heavily modified version of the interpreter for obfuscation purposes (e.g. scrambling of opcodes). On internal projects, that is likely to be different, of course.
- musicale 7y agoPython 2 to Python 3 breakage is the worst thing that ever happened to Python. Even simple things like retaining the print statement (which could certainly coexist peacefully with the print() function) would have made things easier. It's not too late though. We could add better backward compatibility into Python 3.
- acdha 7y agoThe print function replacement can be done in a few seconds using at least 3 different tools with no risk (futurize, modernize, pyupgrade). The amount of time spent talking about why it’s hard to change greatly exceeds the time required to do so.
- mixmastamyk 7y agoUse logging for non-trivial apps.