Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thank You, Guido

blog.dropbox.com

Post reply on HN
Print view View original

81–90 of 388 posts

Re: Thank You, Guido

#81

Post by drakonka »

not2b wrote: 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.

I 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!

Re: Thank You, Guido

#82

Post by gcthomas »

FpUser wrote: post #46
FpUser wrote: post #36

Earlier quoted context omitted.

"But it never amounts to anything close to a debate about what language I should use." So if your task was to deliver let's say commercial grade FFT library ( substitute with any other long computationally extensive process ) for consumption by others you would write it in Python?

Simple question leads to downvoting? Looks like we have a knight in shining armor protecting the castle of Python.

There are FFT libraries written in Cython, the superset of Python that compiles to C/C++. Just because the Cpython runtime might be too slow for this type of task doesn't mean the language is.

And why would anyone write FFT code anyway? Robust implementations exist already - see netlib.org for algorithms implemented in C, C++ and Fortran. SciPy uses these and wraps them for use in Python, with newer code worn in Cython.

So yes, FTT applications can be, and routinely are, written in Python if that is what you are most familiar with, as is the case for many natural scientists and data scientists.

Re: Thank You, Guido

#83

Post by evmar »

3pt14159 wrote: post #79
not2b wrote: 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.

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

Re: Thank You, Guido

#84

Post by tathagatadg »

I owe a lot to the python language and the community. One thing specifically stands out with Guido is humility. Smart, successful and kind ... empathy for others - from the language design to focus on readability, to helping new comers - what an amazing role model! It is no surprise when you see that reflection in the python community at large.

Re: Thank You, Guido

#85

Post by awj »

FpUser wrote: post #70
ivalm wrote: post #55

Earlier quoted context omitted.

Clearly his statement is predicated on the kind of work he does. Dont be obtuse.

If this is "predicated by the type of work" then why make generic statement? Am I the one being obtuse?

Do most generic statements start with "This matches my experience"?

Kinda seems like you are, mate.

Re: Thank You, Guido

#86

Post by badfrog »

whitten wrote: post #56
peterwwillis wrote: post #41

Earlier quoted context omitted.

There 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.

I 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?)

I 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.

Re: Thank You, Guido

#88

Post by FpUser »

pbourke wrote: post #54
FpUser wrote: post #36

Earlier quoted context omitted.

"But it never amounts to anything close to a debate about what language I should use." So if your task was to deliver let's say commercial grade FFT library ( substitute with any other long computationally extensive process ) for consumption by others you would write it in Python?

Given the success of the Python numerical computing stack (numpy, scipy, etc) it would probably be a good idea to do just that. Of course you’d profile the library and move some of the performance-critical bits to C / C++ / Rust. Thankfully Python has some well-trodden paths to that solution.

IMO a good an practical idea would be to write it in C/C++, expose as flat C API and then offer wrappers in whatever popular consumer languages there are (python included). The world of software does not end with Python

Re: Thank You, Guido

#89

Post by slightwinder »

whitten wrote: post #56
peterwwillis wrote: post #41

Earlier quoted context omitted.

There 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.

I 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?)

Would 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.

Re: Thank You, Guido

#90

Post by VectorLock »

3pt14159 wrote: post #79
not2b wrote: 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.

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…

I think Python 2 had hit the perfect balance of "just enough but not too much" which I'm very deeply worried that Python 3 is going to deviate from.
Post reply on HN