Live data from Hacker News

Thank You, Guido

blog.dropbox.com

111–120 of 388 posts

Re: Thank You, Guido

#111

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…

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.

Python 3 is barely different in my experience and it's been about 10 years at this point.

I do enjoy some of the "new" features of python 3.

Re: Thank You, Guido

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

Elixir 1.9 came out. No future core language changes are planned. There are no intentions of creating an Elixir 2.0. There will still of course be regular improvements and updates, but the core language is basically set. Read about it here:

https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

Re: Thank You, Guido

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

Java is fairly stable I've found.

Just get away from javascript and once in 20 year platform language changes like swift and most platforms don't have that much churn.

Re: Thank You, Guido

#115
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.

You’d think it would be common sense when writing something that other people will read. We don’t see people writing books in acronyms or omitting words. How come so many people try to use code to show how smart they are?

> How come so many people try to use code to show how smart they are?

It's tricky, isn't it? The original quote was about "clever code" versus "maintainable code", but they are not orthogonal: it's possible to write code that's more maintainable (because it's harder to use incorrectly) at the cost of being more clever (because you need to learn more of the language or standard library to understand it). One person's "more maintainable" is going to be another person's "too clever" — you're going to get a bunch of different opinions on where the line lies. Not everybody is trying to show off their brains.

Re: Thank You, Guido

#117

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…

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.

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 a lot more complicated than it would be otherwise.

Personally I would second Go as a good answer for this. It has its limitations, but it’s simplicity and it’s standard library more than make up for that from a pragmatic standpoint imo

Re: Thank You, Guido

#118
post #88
post #54

Earlier quoted context omitted.

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

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 WASM and Python via pyo3 (Python/Rust bindings)

Re: Thank You, Guido

#119
post #111

Earlier quoted context omitted.

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.

Python 3 is barely different in my experience and it's been about 10 years at this point. I do enjoy some of the "new" features of python 3.

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.

Re: Thank You, Guido

#120
post #83

Earlier quoted context omitted.

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

Fortran from the 1980s is still supported...

Hell, I fixed something in Turing last week. My eyes are still bleeding.
Post reply on HN