Hacker News Reader

Comment by sitkack | Hacker News Reader

> Let’s say hypothetically that Apple was dumb enough to pull a Guido van Rossum, and declare that Swift 6.0 is backwards-incompatible with Swift 5.0, much in the way that Python 3 is incompatible with Python 2.

Damn, I was waiting for this. The whole essay was a setup for this paragraph. Reframes the argument using a shared traumatic experience for everyone. This humanizes the effect, we all know someone that lost someone to the Python2/3 transition. I can't count the number of Python friends that turned into Gophers, joining some cult of middle class bearded tech dad with a side business distilling pear brandy.

Best Yegge Essay Yet! Welcome back Steve.

edit, finished the essay. He smoked GCP in this one, damn damn hard. Hickory.

View on HN

Apple already pulled the Python 3 stunt twice with swift. Swift 1 to Swift 2 to Swift 3 were all very much incompatible.

Of course the language wasn’t as broadly used back then and Apple is known for quicker churn than Python so the need to write code compatible across Swift versions was much less pronounced

Swift can be very painful from this perspective. I just recently had to do surgery on a project because one of my dependencies changed the tools version.

The back-compat promise is one of the reasons I'm investing in Rust for new projects, even if I find the actual programming much more pleasant in Swift.

But I'm a bit less optimistic about Rust now given the recent layoffs at Mozilla.

Rust is not that dependent on Mozilla

I don’t think so either, but it does breed confidence when there is a large organization backing a project

I haven’t used Swift heavily till recently, but didn’t they say from the beginning there would be lots of breaking changes in the first couple versions? Doesn’t make it less painful but they were at least up front about it.

They still don't have async-await. Once that arrives, a lot of code gets redesigned again.

Async/await currently looks like it'll be a non-breaking change. Obviously you'll have to redesign a whole bunch of code to actually take advantage of it, but you won't have to adopt it just to upgrade to the newest version of Swift. If you decide it's not worth the effort, you'll have the option to just not redesign anything.

Yes, hopefully not a breaking change, but a lot of APIs and libraries will have to be redesigned completely in order to allow people to take advantage of it. And a lot of old code will look inconsistent for quite a long while.

I'm a bit surprised that language support for such a key concurrency feature comes so late in the game.

It's not the same issue that Yegge describes though.

“So late in the game” is relative, no? Java doesn’t have it, Rust stabilised it last year after ~9 years (or around the same time period if we’re comparing 1.0 releases).

Async/await does not need to be a breaking change - C# managed fine without it being so. The breaking changes in Rust were around the standardisation of std::futures::Future rather than async and await.

That said async/await makes a world of difference to the usability of Rust for async code and I’d imagine it will for Swift too.

The only breaking change was that async because a keyword, the Futures stuff didn’t cause any breaking changes. There were three major versions of the library before it moved into the stdlib, though.

Right, by “breaking changes” I mean across the ecosystem rather than in the Stdlib. There’s still a decent amount of code based on futures 0.1 and many libraries that depended on it required rework as a result.

I don't get the Python3 bw-incompatibility hate. Getting rid of cruft is literally the only way to get rid of cruft. It's literally the Pythonic to not have cruft.

I dread the day Python will be as bloated as C++ or Java, neither that dare to remove things.

What cruft did py3 remove from py2?

Unintuitive string types, weird print function, unintuitive division, to name a few. I'm sure there are more things I can't recall at the moment.

> unintuitive division

Arguably worth it. Dividing 1 by 2 with "1 / 2" and getting 0 is a real 'wat' for novice programmers. And the workaround is a 'wat' for experts: instead of using a floating point division operator, cast one of your parameters to float.

Hey! Leave Java out of this, Java didn't do anything to you!

Joking mostly aside, python is way way closer to C++ in terms of language feature bloat; where Java is notoriously spartan and slow moving (moreso historically).

Ofcourse I know you're also reffering to standard lib gunk but that's relatively less impactful.

The big issue with the python 3 shift was when you touch something as substantial, subtle, and pervasive as strings you're going to cause problems. I wont speak to if it was worth it.

Probably less to do with backwards compat then how it was handled. The first few versions of python 3 didn't really provide any compelling benefit, (indeed things like performance were worse, not better), and most people didn't _care_ about the cruft it removed. The "print" statement being a great example. Was it kind of weird? Sure. Did that weirdness have any consequences at all? Not really. Was it worth it to force people to replace thousands of lines of code for something that was essentially a minor aesthetic issue, if that? No way.

Also the python 2 string type was more in line with how other unix utilities work, so while I do think the 3 string type is generally better for the web, it wasn't an obvious improvement for the other large usage of python. While it's a very versatile language, I would say the major niches of python are: web dev, shell scripting, and scientific computing. The changes in python 3 were (somewhat) helpful for web dev, but really were inconsequential and/or actively harmful for the other uses.

Mixed with how condescending the python dev team acted about it, and how it really wasn't until about python 3.6 that there was any compelling reason to move to python 3,you can see where most of the hate comes from.

And by the way, even if Python is very popular today, I do think that rift really hurt the language. I worked at least at one company where Python was considered for a project, but eventually shelved because of management's confusion over the 2/3 issue.

Agree with everything you said here, but let me riff on this

> The "print" statement being a great example. Was it kind of weird? Sure.

I am reminded of the Emerson quip "A foolish consistency is the hobgoblin of little minds". The Py2 print statement is special/weird because it is a very important and special behavior, especially for newcomers. It's not randomly special, it's special because it models something that deserves special treatment.

Py3 is more consistent, but less humane. I use it over Py2 only because the market has moved on, but every time I type print with parentheses I curse Guido.

> It's not randomly special, it's special because it models something that deserves special treatment.

Can you expand on this, why is this more humane? And why should print be a special function?

Two simple reasons. First, "hello world" requires less explanation

  print "hello world"
  vs
  print ("hello world")

Second, printing a line to stdout is an extremely common and special activity (especially during debugging). There is almost no programmer-defined function you could write that has a function as fundamental as that of "print".

Larry Wall of Perl thought about these things in terms of Huffman Coding, i.e. the most common thing you might want to write should have the syntax elide any easily understood context.

In the case of "print", we know we're not talking about any random function here: it's the function for getting output to the terminal, one of the most fundamental operations in all of programming. So I think it's totally fine for it to have a special representation in the language.

Interesting, thanks.

One nit I would call-out is that most people don't put a space between the print and the ("hello world"), so idiomatically when learning, print is 'just another function'. And since HelloWorld is usually the first thing people learn, I wouldn't want them to think print is different than any other function.

Also, the first line of The Zen of Python is "Beautiful is better than ugly", I can understand why consistency was a priority here.

We could get into a whole other discussion about whether or not a programming language should have and adhere to a "culture", but fundamentally I agree with the arguments against Python making this change. It's just not worth the effort, and like others have said, they might've lost of a lot of momentum to JS.

The funny thing is, if you type print with space it recognizes what you meant, and still wouldn't do it, raising an exception instead. It would've cost them literally nothing to support both ways to write print, since the parser has to detect statement print anyway.

Yes, but it would be a different way to do the same thing. It'd be anti-Pythonic.

That's great for new programmers. It's terrible for people in a mature ecosystem of lame duck software. Some production critical python code is 20 years old.

Most hate originates because they question whether it actually was cruft and wheter the new solutions are really better. And even more hate critics the way transition was handled. And indeed, that some removed features were added later again speaks for a certain lack of insight when decicions were made.

That the transition took nearly a decade (and for some still goes at this point) and several minor-versions is another hint at strong problems in planing. At the end we got something better, but the road toward it was just far to painful for what we got. And this fuels hate till today.

Python3's intentions were good, but the execution was abysmal. It was just a bunch of extra work on top of what should have been a pretty straightforward migration.

> we all know someone that lost someone to the Python2/3 transition

This feels like a very strange perspective. Why is it a problem to "lose" someone from a language? You're an engineer (a presumption on my side); casting yourself into a subsection of a "Python engineer" seems like a move with all the downsides and no upsides.

You don't lose, you're still an engineer. Platform loses a user. And that's bad for everyone as explained in the essay.

Apple is AFAICT the least concerned of all the major platform vendors about backwards compatibility. Programs routinely stop working on new releases of macOS or iOS, sometimes in ways that are impossible to fix. On Mac they’ve already changed processor architectures twice and look poised to do so again. That’s much more disruptive than the python 2 to 3 migration.

> That’s much more disruptive than the python 2 to 3 migration.

Yet Python 2 to 3 started in 2008 - 12 years ago, and is still not “done” in any meaningful sense.

If I think back to 12 years after the intel OSX transition - 2018 - I can’t think of a single outstanding issue, whereas I bash into python 2 vs 3 literally every time I touch it (and therefore mostly choose not to).

I am slightly disappointed that folks choose to focus on Swift in this quote. The essay was pointing out how GCP deprecates products and makes users rewriting running applications. This is akin to forcing a Python2/3 split with nearly every deprecation.

this is a really nitpicky thing to debate, but for me, since this essay is basically a sequel to the infamous Yegge Platforms Rant, then the platforms rant is still better, because it is much older and still correct. he could have directly copy pasted paragraphs into this essay and it would still be relevant

I was surprised he called out the Percona folks by name by giving a link to a quick-start button.

Apple already ~mandated moving apps to Swift. I don't see why they couldn't do it again? Purely because of the existence of Flutter?

When did Apple “mandate” apps move to Swift? The majority of code out there is still Objective C.

The problem isn’t making an incompatible “v2”. It’s getting rid of “v1”.

If I can’t take advantage of new functionality without moving to a new version that’s a headache. But it doesn’t cause me to throw away all of my existing investment. Especially if you can combine the old and the new.

Apple has not mandated moving apps to Swift. Obj-c is still fully supported and even continuing to be improved. They have not announced any plans to deprecate obj-c either.

Do you have a source?

Flutter and React Native both work on iOS. And obviously Objective C still works

I don't they'd ever deprecate Objective-C when so much of their internal software and the biggest apps are still 100% Objective-C. Objective-C support is a good counter-example to Apple supposedly deprecating things.

Good luck on deprecating Objective-C and the C++ toolchain.

As an example core of Unity is written with C++ with Objective-C bindings for APIs such as Metal.

If Apple would mandate Swift then things like Unity would just cross compile into swift, causing perf regressions for users, all for no benefit for Apple.

Reply on news.ycombinator.com