Live data from Hacker News

Thank You, Guido

blog.dropbox.com

221–230 of 388 posts

Re: Thank You, Guido

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

Can't you just ignore those comments?

Re: Thank You, Guido

#222

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.

How are people adapting to Oracle’s licensing changes?

It's not really that big a deal in my experience. We switched to the Corretto[1] distribution of the OpenJDK from Amazon and it was seamless.

If you want newer versions of the JDK, you can get them directly from Oracle[2] still, or from alternatives like AdoptOpenJDK[3].

[1]: https://aws.amazon.com/corretto/

[2]: https://jdk.java.net/13/

[3]: https://adoptopenjdk.net

Re: Thank You, Guido

#223
post #182

Earlier quoted context omitted.

Or Perl. Perl takes backwards compatibility very seriously. There was a lot of gnashing of teeth a while back on whether to make newer versions actually change the default behavior finally to some new features could be opt-out instead of opt-in. An by new features, I mean stuff like "use strict", which has been best practice for a couple decades now, but the change would cause problems for existing scripts that didn'…

Unless it uses CPAN stuff, or calls out to external tools. Those are often needed for key functionality, and they get stale much faster than perl itself.

The old versions of modules are available, if you don't happen to have the exact same code present.

Core modules are all I would worry about, but I'm pretty sure those are held to the same standard as far as backwards compatibility.

One or two modules might have been ejected from core or moved into core, but those should be easily found on CPAN as well.

In the end, getting something working from scratch on a newer Perl that has a lot of CPAN dependencies (as opposed to just updating Perl) might be a little annoying in that you have to track down all the module versions, but it's far from impossible, or even all that hard.

For example, the CGI module[1], which was a core module but historically seen as fairly bad (at least as of now, and at least in some of its uses, it supported a wide set of use cases), it was removed from core and housed on CPAN. If you follow the link provided and check the past versions (dropdown as part of the module path and name), you'll see there are many versions shown, possibly every public version, and going back to 1998 for CPAN, and 1995 for 1995 for the BackPAN. Each of those is visible as an item with it's documentation at the time and the module available to download and use. You can also access the CPAN testing matrix[2], and if you dig around you can actually find the results for some tests back in 1999.[3]

If I was responsible for getting some old Perl app to run on a more modern system, I would by much more worried about the OS changing in a complex way than I would about getting the Perl code to run again as expected. Which is to say, I wouldn't be worried much at all.

1: https://metacpan.org/release/CGI

2: http://matrix.cpantesters.org/?dist=CGI+4.44

3: http://matrix.cpantesters.org/?dist=CGI%202.55

Re: Thank You, Guido

#224
post #147

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.

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.

I’m a full time scala developer and have had basically no problems taking longer than a day to in moving to the LTS releases of 9+.

It’s probably pretty helpful that the scala ecosystem doesn’t depend much on non-well trodden parts of the JDK

Re: Thank You, Guido

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

This is a really good comparison and one I'm going to use going forward. Thank you.

Re: Thank You, Guido

#226
post #34

Earlier quoted context omitted.

Python is well-designed for what it is, and it certainly seems intuitive compared to bash or perl or whatever people were using before, but it is opinionated in a way that makes it hard to write anything but procedural-style code. That quality draws some people to it, but it's not a language that can be everything to everyone.

> it's not a language that can be everything to everyone. Unlike say, for example...?

Nothing can be "everything to everyone". People are different. No point in trying to conquer the world.

Re: Thank You, Guido

#227
post #38

There's a whole generation of programming language creators born in the early to mid 1950s. In no particular order: Guido van Rossum (Python), Bjarne Stroustrup (C++), James Gosling (Java), Rob Pike (Go), Larry Wall (Perl), Walter Bright (D). Makes me wonder what kind of secret club they have going on.. Enjoy the retirement, Guido!

> Makes me wonder what kind of secret club they have going on It's no secret; they lived through the time where the computing power was outstripping people's ability to express ideas harnessing that power, and the world was ripe for more expressive languages that leaned harder on the CPU to convert them into action. And, that's still true. ;) New languages are being invented, some haven't caught on yet.

Another environmental factor is the end of Moore's Law. As single-core performance plateaus, we'll probably see more "bare-metal" native languages like Rust and Zig for applications that don't have the latency budget for higher-level dynamic languages with runtimes. We also see languages with good concurrency support like Erlang and Go become popular as applications need to become more multi-threaded to use multiple cores effectively.

Re: Thank You, Guido

#228
> For the last several months, Guido and Sushma have been meeting once a week to talk about all things programming. But Sushma says the biggest takeaways were not just about how to do things, but how to become more confident and learn how to figure things out on your own.

The part about Guido personally mentoring women engineers is, despite his (obvious) technical contributions, the most impressive part about his Dropbox tenure to me. The article mentions him leading by example and it's inspiring to see someone of that stature and level of accomplishment willing to spend time with individuals. It's one thing to talk about fostering a welcoming community, it's quite another to offer up his time so generously when he could be doing "higher leverage" things with regards to diversity.

Re: Thank You, Guido

#229
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 think you are looking for COBOL.

Re: Thank You, Guido

#230

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.

How are people adapting to Oracle’s licensing changes?

The biggest change I've seen is that people are using OpenJDK itself (rather than Oracle's official distribution) a lot more, not only from the official OpenJDK distribution, but also the new Amazon's Corretto version, Azul's Zulu (the one I use at work, which has been backporting lots of security improvements to Java 8, which is very useful!), RedHat's OpenJDK, and even AdoptOpenJDK, all of which are completely free and open source...

If you want to quickly and easily switch between distributions, I highly recommend https://sdkman.io/ - it lets you install and use any of the above mentioned JVMs with a simple CLI... e.g. `sdk use 13.0.1.j9-adpt` or `sdk use java 8.0.232-zulu`.

I would guess that Oracle's JVM popularity has gone down from around 75% of Java users, to something like 20% after the changes, even though I don't actually have the numbers.

Post reply on HN