Live data from Hacker News

Thank You, Guido

blog.dropbox.com

281–290 of 388 posts

Re: Thank You, Guido

#281
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 in…

I’m finding that one of the biggest time sinks is code that looks like it’s doing something other than what it’s actually doing.

Code smells draw the eye when debugging. Your brain wants the problem to be in the code that’s clearly “wrong”. So smelly code anywhere near common code paths has a huge cost compared to smelly code in some leaf function in an obscure feature.

One of the wisdoms of XP, I think. The code you touch the most should be the sanest.

Re: Thank You, Guido

#282
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?

I’ve ratcheted this up a notch with jr devs.

When are you having fun reading someone else’s code? You’re usually there trying to solve a problem. Your plans for the day have gotten away from you. You may even be having a Bad Day. And this is at least doubly true for failing tests.

Take pity on the person.

Re: Thank You, Guido

#283

Earlier quoted context omitted.

What surprises me most is his insistence on a non-incremental update. To this day, I have no idea what the logic behind "no intermediate steps" is. Codebases are written in Python that would dwarf Margaret Hamilton's famous stack. Why should everyone have to adapt the string functions to unicode and get rid of different-type comparisons and change syntax in one go, without a good way to sound out bugs inbetween?

Regarding string , the breaking change was necessary because it was a double-duty type, sometimes acting as a byte-array and other times acting as a string. Meaning some of its functions, like string.length() , gave a value that only made sense for string-as-byte-array, but not as string-as-simple-list-of-characters. More detail on Stackoverflow if you want ( https://stackoverflow.com/questions/5471158/typeerror-str-…

In python 2.7 they also introduced "bytes" although it was just another alias to "str". I wonder if they would make python 2.7 distinguish between them and add an option (like another import from __future__) to throw errors when these types were mixed.

This would help a lot in preparing code incrementally to work on python3.

In the mean time, mypy in python 2 mode doesn't warn about str bytes either :/

Re: Thank You, Guido

#284

Earlier quoted context omitted.

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.

Not really. The newer open versions still don't match Oracle JDK 8. Wanna bundle a JVM with your app so your users don't have to worry about the Java runtime? Well, you can't do that anymore. Wanna use JavaFX? You have to jump to Java 11 and hope your dependencies don't fail with module packaging errors. Do you use Scala? GLHF. Standing still in the Java ecosystem is fine. Keeping on with the advances is painful and…

> The newer open versions still don't match Oracle JDK 8

I'm currently working on a web service that was written under Java 8.

For giggles, I just ran the end-to-end tests suite under Java 8, 11, and 13. The only error I got was an incompatibility with Google's Error Prone linter, which I was able to fix with one line change.

This represents a few hundred thousand lines of production code that works just fine under every important JDK in use today.

Re: Thank You, Guido

#285

Thank you Guido! At the risk of sounding saccharine, Python has literally made life better for my colleagues and me. In the corporate, financial world where I’ve been working, people often see coding as someone else’s job. Python, and the community that has grown around it, have made programming accessible (socially acceptable?). It has saved months of work for us. I hope you enjoy whatever you set yourself to next.

I can only agree. Me and a colleague are the only ones using Python for HR (HRIS) that we know of, but people are very interested when we tell them how we use it for data quality, automation and reporting. There will surely be more in the future.

Re: Thank You, Guido

#286

Earlier quoted context omitted.

> 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

"It was done at least once" != "it was a good choice", though. There's a reason why most OSes are not written in Lisp, and it's not because the OS writers aren't smart enough to learn Lisp. It's not because they don't know it exists. It's because there are better languages to write an OS in.

Writing an OS in Lisp basically means adapting or developing, and then growing, a Lisp implementation on the bare hardware. Someone would only do this if they are simultaneously interested in OS research R&D and Lisp implementation R&D.

This is different from someone working on an OS in, say, C. They just pick some C compiler and use it, without becoming a C researcher and implementor.

(They might bemoan some things happening in the development of the compiler they are using that affect their work, but not actually take that on.)

Re: Thank You, Guido

#287
post #275

Earlier quoted context omitted.

Guido has been working there for 6 years yet only now is starting the conversion?

The article doesn't say "only now". It says "He has already put into motion the conversion of the Dropbox server code from Python 2 to Python 3. " "already" refers to "sometime in the past 6 years".

Motion describes something that isn’t stopped, meaning not yet complete. This implies it’s more recent, or the conversion is more difficult than it should be.

Perhaps it’s already done, in which case this word choice is poor.

Re: Thank You, Guido

#288

Earlier quoted context omitted.

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?

Honestly, if you're smart, it's just really fun to make things dense and logically concise. Think of it like a minor form of code golf. My first CL at my first job out of college was writing a state machine at Google. I remember collapsing it into this dense, elegant representation by hinging on a couple of bits of state. It took me an extra half day, but I was really proud of the end result, and I remember being mil…

My best friend in college was a writer, pursuing a BA in Literature.

I’ve been thinking again lately about little bits I picked up via osmosis and my own early creative writing experiences. In fact I was just noting a couple weeks ago how refactoring resembles an exploratory writing exercise.

I think we need to embrace the creative writing similarities. Would we ever celebrate an author who published efficient, dense and cryptic text? Rarely.

One of the things we do want is someone who paints a clear picture in a few well chosen words. Another is to be inspired. Tricked or bored are not on that list.

Re: Thank You, Guido

#289

Earlier quoted context omitted.

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

To me, C is a tale of the perils of maintaining backwards compatibility: there are lots of parts of C, and particularly its standard library, that should never be used because there's no way to do so safely, but can never be removed and so inevitably new code will continue to be written that uses them.

What is there? I'm thinking of gets() which was actually removed from the standard. Other functions, you can absolutely use them correctly, even if it's not a great idea. I don't think a large percentage of C bugs comes from the standard library.

If you depend on some functions in the standard library, it's super-easy to replace them. They're leaf dependencies.

Anyway, C has about the smallest standard library you can have. And if we're talking about it's benefits in terms of compatibility, we're probably talking about the fact that it doesn't introduce new syntax / language features each other week.

Re: Thank You, Guido

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

> This is very sage advice. I mean in real life (when you don't have Guido to do it for you), if people are writing code you can't understand then you need to tell them to fix it. And many people don't like being told they need to rewrite their code because you can't understand it, so it leads to conflict and eventually you often need to fire people. So yes, it's good advice, but by cleaning up engineering debt you'r…

We have reached a middle ground in our organisation (not a tech company, so there is less code and a slower pace). We don't require rewrites, but simply recommend that next time the code be written in a more lenient style. The education aspect is a good lens through which to view the issue also, sometimes resistance to an unfamiliar style is due to a fixed mindset around a known set of language functionality. It could be an opportunity to learn something new which is genuinely useful.
Post reply on HN