Live data from Hacker News

Thank You, Guido

blog.dropbox.com

241–250 of 388 posts

Re: Thank You, Guido

#241

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…

Elixir 1.9 came out. No future core language changes are planned. There are no intentions of creating an Elixir 2.0. There will still of course be regular improvements and updates, but the core language is basically set. Read about it here: https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

If Elixir wasn’t an option for me, Clojure would be my next option. Clojure seems like it has a similar philosophy, and builds on a dynamic immutable core.

That being said I like writing code that can feel “done”. No “I wish I could refactor this object hierarchy to make it easier to use, etc” notions in the back of my mind. Not every piece of code is like that, but enough.

Re: Thank You, Guido

#242

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.

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 exhausting. The Java tech stack is awesome when it works, but to solve issues you have to go so deep into the tech stack that I'm starting to think it just can't be done unless you're at least a mid-sized company with JVM specialists on the payroll. Not developers, but systems people.

Re: Thank You, Guido

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

Lots of CPAN stuff is just plain Perl code, so the, "it just works" keeps working, too. It's to the point where a lot of "competing" Perl modules that try to solve the same problem have similar/same API's (but under the hood, rely on different things) - sometimes that is to solve the, "Well, the more popular choice went off and did something interesting in $VERSION+1, but we like the old way"

Also, if you desperately need an older version, you can usually install that older version rather than the newest.

Anyways, there's things you can do. I still work on code I started in my dorm room (in the 90's). Cranky CPAN modules aren't too big of a problem.

Re: Thank You, Guido

#244
post #201

Earlier quoted context omitted.

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.

Yes but the source-to-source compilers do a fraction of the work needed to get a code base migrated. I've tried both the builtin 2to3 utility and many proprietary converters, including fancy ones that run type inference on Python 2 code and produce type annotations. None of them, as expected, can deal with the str/bytes split without manual intervention. Fundamentally the issue is that the Python language is too dyna…

> What we really need is a tool that runs your Python 2 code, records types and other dynamic manipulations, and then produce Python 3 code. But I'm not aware of such a tool.

That's a great idea, but it sounds pretty intense to implement. I ended up becoming addicted to ML-family languages pretty early (Scala, F#, OCaml, Rust) for a variety of reasons, but I never fully grasped how much strong/static types help for refactoring until I tried refactoring some Ruby code. I can't imagine trying to write an automated tool for the task.

Re: Thank You, Guido

#246

Earlier quoted context omitted.

I used `async` as the name of a function decorator in some Python3.4 code, which then broke in 3.6 which introduced `async` as a keyword.

What was the level of effort to remediate that?

sed 's/async/whatever' ...

Re: Thank You, Guido

#247
post #18

To be honest, it is a sad moment, but it was expected. When Guido resigned from BDFL, I knew that it was the beginning of the end. And lets be honest, he's earned it. Thank you Guido, after learning Python, I never looked back, and it has been the source of great joy for me over the last decade.

> Thank you Guido, after learning Python, I never looked back That matches my experience. All the pros and cons that in principle apply to any language, whether newer than Python or older, mean nothing to me in practice. Python is the one that feels right, the others feel like a chore. Since I started with Python 10 years ago, nothing has changed that. There's ways I'll insist that Python is the best at [x], and ways…

There are a lot of times where Python is an inappropriate language choice. Anytime you have concurrency for instance. Definitely any time you need to distribute an application directly to an end user.

Beyond times when Python is clearly wrong, there are other issues, mainly around tooling and documentation. Languages have come a long way in the past 20 years.

Re: Thank You, Guido

#248

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…

Delphi still lets you build programs that used to run on Windows 3 with minimal changes, and definitely anything 32-bit. It's part of the value proposition: the language and libraries are planned for forward compatibility and stability for use ten years in the future, as well as now.

To save others the same DDG search I did -> Delphi is a Pascal language IDE that compiles to native Windows binaries. Apparently there is this thing called Lazarus that is a free version of it?

Re: Thank You, Guido

#249
post #56

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.

I assume you are referring to "technical debt", unless you were being ironic and I didn't catch your irony emoji. (Is there an ironic emoji?)

This is different. Tech debt is a factor of letting things get slowly worse. Those things can be improved if you just work on your tech debt.

What I'm talking about can't be improved or fixed, or higher-ups refuse to improve or fix it. Instead, it has to be completely replaced. It's like a Replicant with a four-year lifespan. You literally know it's going to die in four years, and nobody orders a new one until the old one is practically dead, and everyone has to rush to replace it.

Post reply on HN