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…
Thank You, Guido
221–230 of 388 posts
Re: Thank You, Guido
#222Earlier 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?
If you want newer versions of the JDK, you can get them directly from Oracle[2] still, or from alternatives like AdoptOpenJDK[3].
Re: Thank You, Guido
#223Earlier 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.
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
Re: Thank You, Guido
#224Earlier 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.
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"“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?
Re: Thank You, Guido
#226Earlier 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...?
Re: Thank You, Guido
#227There'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.
Re: Thank You, Guido
#228The 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
#229Did 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…
Re: Thank You, Guido
#230Earlier 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?
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.