Live data from Hacker News

Thank You, Guido

blog.dropbox.com

191–200 of 388 posts

Re: Thank You, Guido

#191

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.

Yet we have multiple versions of Java at work (8 and 11) because some (pretty large) third-party components don't support the newer versions yet. Plus for things that do work there are a bunch of irritating warnings and whatnot.

It's not "exceedingly good" at it, it's just alright. Go has done much better for us in this area.

Re: Thank You, Guido

#192
post #111

Earlier quoted context omitted.

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.

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.

Re: Thank You, Guido

#193

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.

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

It'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.

Re: Thank You, Guido

#194
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 :)

Unless there’s a real and needed benefit, why complicate it?

I’ve seen clever code that was 300% faster, half the lines, completely unreadable, and called once per session, for a total the time of 10ms in a workflow that was minutes long.

No amount of commenting could justify it.

Re: Thank You, Guido

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

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

Re: Thank You, Guido

#196

Earlier quoted context omitted.

We all have our preferences. I find Python to be intuitive. I find Ruby to not be. I am sure someone would spend half a day trying to convince me otherwise, but, it's not worth arguing over in the end. There are more languages than most would care to count. Devs should pick a few that speak to them and move on.

But intuition is not something fixed like an extra toe or even ingrained through a lifetime like a sexual fetish. The core of what humans do is acquire new abstractions in such a way that what was previously convoluted is now intuitive. "Intuitive" is a word for "stuff I already know". Symplectic geometry is unintuitive until you learn it. Learn stuff.

Yeah. Jef Raskin pointed out that we use "intuitive" to mean "familiar" (in IT.) The computer mouse seems so "intuitive" today, but when he first handed a mouse to someone else, an architect IIRC, to use she turned it upside down and tried to use it like a little trackball. ("The Humane Interface")

Re: Thank You, Guido

#197

Earlier quoted context omitted.

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

It'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 facil…

I hadn't thought to mine knowledge from old seadogs, a la Peter Drucker. Thanks.

Re: Thank You, Guido

#198

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.

My general rule is that I don't even think about learning a new technology until at least two years after I first heard about it.

I assume that I hear about new stuff fairly early in their adoption, since I try to keep up with these things, so if it's still a thing two years later, it might have enough staying power to be worth learning. After that it still takes a while for me to get around actually learning the things.

Go and Rust are languages that have been on my todo list for a while now, for example, but I still haven't touched a JS framework because I haven't seen one with staying power yet.

Re: Thank You, Guido

#199
Someone who worked at Dropbox shared an anecdote. Guido received an email from some recruiter along the line "You seem to have great experience in Python. How many years of experience you have with Python?" To which he replied "All of it!". I am not sure if it is true story.

Re: Thank You, Guido

#200
> The result of this is nearly four million lines of checked Python code, nearly 200,000 improved type definitions, and countless hours saved for engineers.

The more I code the more I appreciate statically typed languages.

When I learned/started coding, I liked dynamically typed languages. It was easier to get past compiler. My code seemed to do something. And if there was anything wrong in the way, it would just continue to execute making me feel that my code is at least doing something.

Now more into programming, I don't want to go back to duck-typed languages. I like when compiler gives me guarantees along with exceptions being thrown at runtime when something goes wrong, crashing the program and noticing it immediately that something is wrong.

I think language people also recognizes benefits.

- PHP7 allows using strict types.

- Python has static type support

- Javasript -> Typescript

Disclaimer: Have used php, tried ruby. Using C# and javascript. Looking forward to typescript.

Do dynamic language people: 1. Write more tests? 2. Have more defective code? 3. Are better at writing code? 4. Maybe there is just no correlation between code correctness and static/dynamic lang. I just wrote down MY feelings.

Post reply on HN