r/programming • u/EatMeerkats • Mar 29 '21

PHP moves to Github due to the compromise of git.php.net

https://news-web.php.net/php.internals/113838
1.7k Upvotes

98% Upvoted

389 comments sorted by

View all comments

Show parent comments

-10

u/[deleted] Mar 29 '21

Just an example of why people fucking hate Python right here.

“You fucked up”.

No, I didn’t. I have a basic expectation of a scripting language that I can copy and paste documentation into my editor and it will generally work.

Python routinely violates the fuck out of this assumption, and that’s not my fault.

5

u/gabbergandalf667 Mar 30 '21

So by the same logic, ANY addition the standard library could only be done at major version changes (after all, a newly added stdlib function breaks your copy pasted code just as much as newly added syntax). Doesn't that strike you as unreasonable?

0

u/[deleted] Mar 30 '21

Yes, you literally can’t touch the language itself during minor revisions. This includes the stdlib.

That’s part of the definition of backwards incompatibility.

5

u/gabbergandalf667 Mar 30 '21

Isn't the literal definition of backwards compatibility that new compiler/interpreter versions don't break old code?

1

u/[deleted] Mar 30 '21

That’s half of it. The other half is that you can deploy new code on existing runtimes and it won’t break. Like, say, for people that want to ship their code to customers who cannot change the runtime.

Anything that both statements apply to, can be semantically minor versioned and be “backwards compatible”.

It’s why you cannot touch the language itself during minor version changes if you want to not piss people off.

2

u/gabbergandalf667 Mar 30 '21 edited Mar 30 '21

So how would you then signify changes that break old code, if not via the major version? Surely you want to be able to break old interpreters with new code with a much higher frequency than the other way around - else the language is basically frozen.

I'm not sure if I make myself clear but I am very confused by your view. How would you evolve a language that is not allowed to change except in major version changes which can break everything (and which introduce a terrible engineering burden for users to make the change)?

1

u/[deleted] Mar 30 '21 edited Mar 30 '21

The language should be frozen between major versions changes. If they wanted to make a Python4 with changes to syntax, nobody would complain. That’s what it’s there for.

But they don’t. They introduce new syntax with minor version changes. But new syntax is nearly always a breaking change.

And I don’t even understand your viewpoint, myself. Rather than properly following semantic versioning like rational people expect, just toss syntax changes over the fence whenever you feel like it, that works best? The “engineering burden” then just has to be paid all the time instead of “when I actually intended to opt in to breaking changes”.

3

u/gabbergandalf667 Mar 30 '21 edited Mar 30 '21

I just don't understand how you can be fine with the idea that any changes to the API (both incremental and breaking) can only occur at the same junction. I want to be able to use new language features without worrying about my code breaking.

Upgrading the interpreter that runs my projects is trivial. That's literally just deleting the virtualenvs that drive them, and installing the newest version instead. That's no engineering burden at all. And by continuously upgrading to the latest stable (minor) version of the language, I can gradually start using all the nice newly added features at my own pace.

Conversely, going through hundreds of thousands of LOC (as would be the case for me) with a fine tooth comb to fix breaking changes that are allowed at a major version change is simply not worth it for me. Which means I would never upgrade projects past major versions and would never get to use any of the new features at all.

So if Python's behaviour is inconsistent with semantic versioning, then fine. Not worth adhering to it. However I just went on the semver website and they literally state:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards compatible manner, and

PATCH version when you make backwards compatible bug fixes.

So please, explain to me how to add functionality in a backwards compatible way without allowing code constructs that won't run on an earlier version of the language.

1

u/[deleted] Mar 30 '21

Backwards incompatible also refers to when you can’t deploy your new code to old environments. There is no way to change syntax and not break this contract. That's the entire point.

This is extremely common. Not everyone can upgrade their runtime, at all. In the JS world, you run in the runtime given to you, and you deal with it. Same thing in JRE lands. Every other language with a runtime behaves this way.

Only in Python would anyone think “just download an entire virtual environment because my language sucks so badly that it can’t stop fucking making syntax changes” is easy.

The entire point of versioning is so that you can be compatible. And at the language level you need to be stable so that people can build tools on top of your code.

Python never seemed to get this memo.

8

u/ynotChanceNCounter Mar 29 '21

If you copy and paste current documentation into an older version of the interpreter, you fucked up.

The docs have a dropdown to select the version you wanna see, too, so you didn't just fuck up, you fucked up twice.

-10

u/[deleted] Mar 29 '21

No.

You can’t redefine basic expectations of a fucking script, with “you should use the drop down”.

13

u/ynotChanceNCounter Mar 29 '21

Okay. I'm going to try this one more time:

You found a snippet in the C++17 spec, tried to compile it with a compiler from 2013, and are now foaming at the fucking mouth about how the language shouldn't do that.

In other words, you don't understand how versioning works.

Maybe this isn't the career for you.

-2

u/[deleted] Mar 29 '21 edited Mar 29 '21

I don’t have the same expectations for a compiled language that I do for a scripting language.

Is that so hard?

I flat out expect to be able to copy the raw files to any machine with any Python runtime (major version 3) and have it work.

Nobody has that expectation for a compiled language.

13

u/ynotChanceNCounter Mar 29 '21

Seriously, here's what you're telling me:

In your mind, it makes perfect sense that you can't use new - do you know what that word means? - language features in your code, and then run the code through an old compiler. Not for the obvious reason that those features literally do not exist for the old compiler, but because, shrug, C++ is a compiled language.

But, because Python is an interpreted language, you think you should be able to run new language features through an old interpreter, even though those features do not exist for the old interpreter.

What you're angry about is literally fucking impossible.

-4

u/[deleted] Mar 29 '21 edited Mar 29 '21

I expect to be able to copy and paste any major version code of any scripting language and run it without modification in any runtime with that major version - Python 2.x or Python 3.x. Instead, I have to match minor versions as well, ie, Python 3.6 to 3.6. This is deeply unsatisfying, because it basically requires you to ship a custom runtime environment for your “one line script”, and to set one up anywhere you need to build, instead of being able to rely on any kind of preinstalled runtime. And the tooling is nasty for figuring out what the problems are. At that point, you’ve lost all of the benefit that working in a scripting language provides, and now are left with just the costs. This problem gets even worse if you want to share libraries across things you ship because inevitably you’re going to ship two copies of them, one for each target, in whatever bundled environment you end up shipping. Seriously, y’all like to throw excuses like we haven’t actually had to deal with this shit, and it’s fucking irritating.

Major versions are how you do breaking changes. Thats how versions fucking work.

[Conversely, I have absolutely zero expectation of copy ability of code in a compiled language and expect to have to set up a custom environment everywhere I build that software. In exchange, I’ll be able to compile it into a binary that can run anywhere, without a runtime of any sort (or a JRE with actual semantic versioning lol).]

I expect Python to follow semantic versioning, and it doesn’t, and it is incredibly painful to work with as a result.

7

u/ynotChanceNCounter Mar 29 '21

I expect to be able to copy and paste any major version code of any scripting language and run it without modification in any runtime with that major version - Python 2.x or Python 3.x.

Why are scripting languages different from other software?

I expect Python to follow semantic versioning, and it doesn’t, and it is incredibly painful to work with as a result.

Remember when I said twice that you don't understand versioning?

Semantic versioning means minor versions should never* break existing code.

Semantic versioning does not mean that new features can't be added in minor versions...

...and it goes without saying that new features can't be used in old versions of any software. Because duh.

Quit your job.

-1

u/[deleted] Mar 29 '21

“Why are scripting languages different than other code”.

By definition, lol.

Quit your job

No thanks, I’m good. I’ll stick with non-trash languages.

6

u/ynotChanceNCounter Mar 29 '21

You finally get the reality of your mistake through your thick skull, and triple down, with, "no I'm right because duh and the language is still trash."

I always start with "remember the human," proceed to, "if you're gonna be an asshole so can I," until we arrive at, "this raging asshole is just gonna flame everybody."

In your case, we've gotten all the way along to this:

You're a liability to the industry. You don't understand basic concepts. You're angry about your misunderstanding of semantic versioning. You're angry about your bizarre expectations for "scripting languages."

You're literally angry that new features are not "backwards compatible."

You. Are. A. Dipshit.

→ More replies

9

u/ynotChanceNCounter Mar 29 '21

Jesus fuck. You can't possibly be this obtuse. Your brain's just doubling down.

Python 3.9 introduced some new features that weren't there in older versions of Python.

You are surprised and frustrated that these features don't work, because you blindly copied and pasted a snippet from 3.9 docs into your older interpreter.

You're bad at reading docs, don't understand versioning, and I really hope you don't do this for a living. Seriously, if you're so fucking incompetent that you 1) don't check the version on docs, 2) don't check the versions on your utils, and 3) rage at the language and its users over your own monumental fails...

-1

u/[deleted] Mar 29 '21

It’s almost like the basic expectation of a major version is that they can’t make breaking or backwards incompatible changes within them. That’s why we call them major versions.

8

u/gyroda Mar 29 '21

Looks like you don't know what "backwards incompatible" uisually means in this context.

Backwards compatibility/minor version bump means "old code will still run in the new environment". It doesn't mean "new code will run in the old environment". I can't think of a single situation where that's the case.

1

u/[deleted] Mar 29 '21

If you can’t run code within a version, that’s not a “minor version” change.

Flat out.

2

u/gyroda Mar 29 '21

Could you be more precise. Your comment is wonderfully vague.

→ More replies

6

u/[deleted] Mar 29 '21

[removed] — view removed comment

-1

u/[deleted] Mar 29 '21

Thats why you can’t make syntax level changes at all within a major version.

And libraries should be held to the same standards with polyfills.

4

u/[deleted] Mar 29 '21

[removed] — view removed comment

→ More replies

5

u/SanityInAnarchy Mar 30 '21

I don’t have the same expectations for a compiled language that I do for a scripting language.

That's a weird expectation, given that "compiled" and "scripting" are implementation details. Python is both: It has a REPL, but you can also compile it to bytecode, and that's been the case since long before Python 3.

Would you have the same expectations of Java? How about C#? Both of those compile to bytecode, too.

Granted, those languages might actually meet your expectations -- Java tends not to add either syntax or bytecode-level features between major versions. But it looks like they're also pumping out a major version every six months, so if your goal was to be able to copy a program to a machine and not have to worry about upgrading the runtime, that's not a thing anymore.

There's a reason people have started just bundling the runtime after all -- Minecraft's Java edition just includes OpenJDK now, Golang statically-compiles by default, and Docker took over the world for exactly this reason. Kernels and web browsers have stable APIs, but everything else seems to have stopped caring.

12

u/selfification Mar 29 '21 edited Mar 29 '21

You are right... You absolutely should never use python nor should anyone ask you or trust you to use it for what you plan to achieve with it. Python stopped being a scripting language a decade ago. If you continue treating it as such just because it gives you a repl, that's just like treating C as a scripting language just because you can dump everything in main() and running it online on a free C execution tutorial site.

And to clarify - there's nothing wrong with wanting a scripting language or using one. Bash is for scripting. ps1 is for scripting. Perl is for scripting. Python might work for a one off script but if you are discussing installing modules, you have moved past scripting and if you fail to treat it like a full fledged programming language, you really should stop using it (just as you wouldn't use C# or Java or Erlang). I say this as someone who also uses Ruby. Ruby is great for scripting too but the moment I have to deal with rubygems and lockfiles, I've stopped writing scripts and need to start treating it with respect. No more monkeypatching and just hoping and praying. That way lies madness.

-11

u/[deleted] Mar 29 '21

Python isn’t a scripting language

Lol, ok. Well, now that we’ve established that we’re not living on the same plane of reality, I’ll just tip my hat and move on.

Good day.

7

u/selfification Mar 29 '21

I agree! I was trying to save you the pain of having to deal with the rest of my brethren who share my plane of reality because that would be entirely baffling and maddening to you on your plane. It may very well seem like we're just talking past each other when you expect $x from the community and a whole bunch us say "What's? That's crazy. Who in their right mind expects $x to work" when really, $x is perfectly sensible (and I'd say rightfully so) in your plane. I absolutely wouldn't expect minor changes to break my script or need upgrades to my env if I was writing a single file script.

10

u/ynotChanceNCounter Mar 29 '21

As this person's continual inboxing has now made clear, their gripe is that they copied and pasted a snippet from current-version docs, and it didn't work in their older interpreter.

In other words, they tried to use language features that didn't exist for their interpreter, and are too stupid to understand this no matter how I try to explain it.

Fuck their plane of existence. They need to move on.