Live data from Hacker News

Thank You, Guido

blog.dropbox.com

121–130 of 388 posts

Re: Thank You, Guido

#121
post #101

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…

Surprisingly enough, PHP is a good example of environment that doesn't break backward compatibility much. About the only change that had a significant impact on projects I worked on was removal of the 'mysql' DB extension (replaced by 'mysqli' and 'PDO'). For an older project I created a few shim functions and it still works just fine. While frameworks come and go, the core of the language is highly backward compatib…

If your timeframe goes back to PHP4, this most certainly isn't true. Just one glance of https://www.php.net/manual/en/reserved.keywords.php should prove this - every new keyword is a backwards incompatible change. And I mention this because I used to support software that used, as a variable name, something which became a reserved word...

Re: Thank You, Guido

#122
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…

Delphi still lets you build programs that used to run on Windows 3 with minimal changes, and definitely anything 32-bit.

It's part of the value proposition: the language and libraries are planned for forward compatibility and stability for use ten years in the future, as well as now.

Re: Thank You, Guido

#123
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'm starting to long for a stack that doesn't constantly change.

I looked up "engraving marble" to find an example of the above, but no luck there: They use lasers for that now.

Re: Thank You, Guido

#124
My whole career was based around Python -- 16+ years of it. I used many other languages but Python was the most enjoyable and useful.

Thanks Guido!

Re: Thank You, Guido

#125
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…

As I get older and crankier I find simplicity and stability become a lot more interesting than reinventing the same wheels over and over again.

This is probably why I’ve come to appreciate Rich Hickey’s talks more and more as years go by.

I think Clojure is a good fit when it comes to stability as per their own development guidelines [1]:

The Clojure development team values a measured and thoughtful approach to language evolution with a strong emphasis on maintaining backward compatibility.

[1] https://clojure.org/dev/dev

Re: Thank You, Guido

#126
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'm starting to long for a stack that doesn't constantly change

Come on over to Javaland, it's nice, warm, and the sun is always shining!

With the exception of the Java 8 -> Java 11 transition (skipping the non-LTS versions), things are pretty stable. You don't have to use any new-fangled features if you don't want... and your Java 3 code compiled nearly 20 years ago will still run just fine on modern JVM's.

Re: Thank You, Guido

#127
post #107

Earlier quoted context omitted.

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 Cyth…

And why would anyone write FFT code anyway? Robust implementations exist already The FFT was just an example, you can substitute it with any SolveTheWorldHunger computationally extensive algo

And you'd find that Python is a go-to language for people writing such algorithms. The black hole image which was in the news was produced from massively complex data sets from across the world. Would you like to guess which programming language was used?

Python looping is often the slowest part of data analysis algorithms, but no-one uses Python loops is these cases. Vectorising this sort of analysis using fast extensions makes Python perfectly speedy enough for actual scientists.

Re: Thank You, Guido

#128
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…

The world keeps moving, if you don't want to move with it then pick something that has already stopped.

Maybe C? Cobol? Ada? Fortran? Though even those languages have modern flavors & updates...

We make progress because we learn, not just new technology, bu new approaches to old problems. When I see an "old" programmer who keeps writing C89 code because "it still works", it is painful to see them rejecting decades of learnings about how to write better software.

Re: Thank You, Guido

#129

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…

One day tech historians are gonna look back at this era and shake their heads at all the time, energy, and talent being wasted by people just trying to keep up with tech trends for the sheer purpose of remaining employable.

I don't think it's that bad. I've never heard of someone who got fired because they didn't know the latest JS framework.

Also, new tech trends are not just hot air, there's also a lot of innovation happening. You just have to see through the hype and wait until the dust settles.

Re: Thank You, Guido

#130
post #88

Earlier quoted context omitted.

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

Yes, definitely a good approach as well. One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal. On my team, we've been successful with this rough approach: 1. write a prototype in Python to explore the idea/ensure correctness 2. extract the core library and re-implement it in Rust 3. consume the core from Javascript via WAS…

One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal.

Interestingly I've found something quite opposite for computational algorithms. The problem was that execution of Python under debugger was unbearably slow for me (I used VS Code for this case). So waiting until the code gets to the point I need was not fun. With C however it would get there almost instantly. Compile time for isolated computational function was nearly instant as well. Maybe debugging under VS code was the culprit but I did not feel that for this particular task Python was any more interactive than plain C.

Post reply on HN