Live data from Hacker News

Thank You, Guido

blog.dropbox.com

141–150 of 388 posts

Re: Thank You, Guido

#141
post #25

The genius of Python is that it treads that fine line between allowing too little or too much control. Between being too strict or too liberal. Between trading speed for clarity and simplicity. It is the ideal programming language for an increasing set of tasks.

The only really risky part of adopting it at enterprise scale is that it's flexible enough that a developer can trick themselves into thinking they can extend it and they end up falling into DSL hell (where you're technically still using Python, but you've bent it so far via its runtime-dynamism that static analysis tools can't help you and you're now writing both code and a toolchain to support writing code).

But you don't have to do that to yourself to use the language.

Re: Thank You, Guido

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

Have you tried Fortran?

C also shows excellent stability and backwards compatibility.

Cobol is also quite stable, but IDK about the quality of open-source tools for it.

The problem of stability is that you are pinned to the moment when the interfaces were defined and committed to, and this moment goes further and further into the past. Quite often this means that you can't use the new things which give advantage to your competitors.

Re: Thank You, Guido

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

That coincides with the following:

> Code is read many more times than it is written. Writing code costs something, but over time the cost of reading is often higher. Anyone who ever looks at a piece of code has to invest brain-power into figuring out what it does.[1]

This is also noted in PEP8:

> One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".[2]

[1]: https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-cod... [2]: https://www.python.org/dev/peps/pep-0008/#a-foolish-consiste...

Re: Thank You, Guido

#144
post #22

I hated C++ and Matlab as an undergraduate. Hell, I hated programming as a whole - and effectively swear never to write a line of code once I was done with my BSc in Physics. Then, at work, I was introduced to Python. It was so...obvious, for lack of a better world. It was like a language I always knew that never spoke before. I'm now a software engineer, write Python almost all day, and looking back to the 18-year o…

> obvious

Yes, coming from Perl that was a huge hit.

Re: Thank You, Guido

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

Use C.

Standardized since the 80s, it has had only minor, backwards compatible revisions in 99 and 11.

According to the TIOBE index, it's the second most popular language in the world. It works on almost any platform imaginable and it has decades of tooling available for it.

Of course it doesn't have any of the good new things developed recently, but if it's stability what you look for, then I don't see a better option.

Re: Thank You, Guido

#146
post #107

Earlier quoted context omitted.

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

"And you'd find that Python is a go-to language for people writing such algorithms."

If it works for them, sure. Did not work for me.

Re: Thank You, Guido

#147

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.

I agreed until the disaster that was Jigsaw.

Maybe Jigsaw didn't impact you particularly hard, but you can't argue the JVM has a policy of minimal backwards incompatible changes given that debacle.

Re: Thank You, Guido

#148
post #28

Earlier quoted context omitted.

For a beginner, compared to many languages out there, it is very intuitive. I taught many 1st/2nd year college students Python as their first foray into programming, and it's flexibility and readability was a great way to get people in the door. I won't defend beauty, as that's extremely subjective. I happen to find the whitespace significantly more intelligible than nested braces and parens, but that's me. I know pl…

> Lisp is a bad language to write an OS in Beg to differ. Lisp machines were huge, back in the day, and there are still hobbyist projects like https://github.com/froggey/Mezzano

> and there are still hobbyist projects

Given that it's been decades, I think it may be safe to say "If Lisp were a good language to write an OS in, we'd see more than hobbyist projects and the Lisp machine companies would still be offering them."

(The need for garbage collection caused a bit of a stumble for the Lisp machines on the market, if I recall correctly).

Re: Thank You, Guido

#149
post #130

Earlier quoted context omitted.

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

Yes, I can see that being tiresome. Our projects are closer to simulations, so rather than focusing on a tight core at first, we have a number of factors that can be in play during each time step.

Rather than worry about figuring out structures for our simulation objects like we might need to do in a lower-level language, Python lets us just throw together some numpy arrays and dicts as needed, and really iterate quickly on the solution. If I was working on something with a tight computational core I would probably take the low-level first approach like you have. Horses for courses, and all that.

Re: Thank You, Guido

#150

> It is so intuitive and beautifully designed No it's not. Significant whitespace, underscores that mean things, lack of type system (but people treat variables as typed anyway), et all, make it quite a difficult language to understand. And we won't get into performance problems that it's cult following turns a blind eye to. I will say Python has inspired a generation of languages that got away from the C-inspired sy…

> lack of type system (but people treat variables as typed anyway) Python has a type system. The types are on the objects, not the variablenames. If people threat variables as types then it's their misunderstanding.

Correct. It's not a type system that lends itself to simple static analysis, but it's there.

That being said, simple static analysis definitely has its advantages, but it's not so useful that it needs to eat the world.

Post reply on HN