top | item 42456034

(no title)

dajtxx | 1 year ago

Python seems to have started with 'why do those other languages have all this trash' and then spent the time since then learning why and coming up with worse versions.

I use python a lot these days, and like it, but it's pretty funny seeing stuff like the above and type hints.

I hate not knowing what types a function takes and returns.

discuss

order

nayuki|1 year ago

> Python seems to have started with 'why do those other languages have all this trash' and then spent the time since then learning why and coming up with worse versions.

This seems true to me too. Examples:

* if __name__ == "__main__": main()

* Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature

* @staticmethod as a decorator instead of being a language feature

* Duck typing vs. abstract base classes

* Static type hints got retrofitted to the language gradually, one feature at a time

* Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true

* Having a GIL instead of being truly multi-threaded from day one

* Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references

* Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).

Quekid5|1 year ago

The whole switch/pattern matching thing is a true abomination borne from: Well, things in statement position can't be expressions (or however Pythonistas might phrase it), so clearly switch/pattern matching must be a statement... It's such an own goal and undermines the main point of pattern matching.

(I do realize that there was opposition on this, but that the Clearly Wrong side won out is baffling.)

deaddodo|1 year ago

Your quibbles show either a) a fundamental misunderstanding of Python or b) are just flat out incorrect.

> * * if __name__ == "__main__": main()

So, don't use it. Python is frequently run as a scripting language (something Java is fundamentally bad at) and this stems from that. All it does is box logic off when a file is being run directly vs imported. It's a user convention and not a language one....ignore it if you hate it so.

> * Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature

This is all very well explained in the PEP. The quick run down, Python doesn't do anything to hide logic from users. Contracts are just conventions and python treats it that way; so the developer can say "you shouldn't use this directly, here's a notation to let you know", but nothing will stop a developer from doing what they want. In Java they'll just write a wrapper class, inherit the base class, and expose that logic. Or worse, fork the library just to edit the class' functionality in some minor way. In Python they'll just call it directly.

> * @staticmethod as a decorator instead of being a language feature

@staticmethod is a built-in, it is a language feature. It just doesn't follow your preferred syntax.

> * Duck typing vs. abstract base classes

You can do both in Python:

https://docs.python.org/3/library/abc.html

The concepts aren't mutually exclusive or even directly related. Java just happens to be bad at one of them, due to it's weirdly non-effective (for a VM'd language, at least) reflection system; so you think it's bad.

> * Static type hints

You're complaining about reflective programming and then complaining about a feature that essentially exists because you can't reflect. It's circular.

> * Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true.

GC arguments have run for decades and everyone has their opinions.

> * Having a GIL instead of being truly multi-threaded from day one

Python was created in 1989. Java was created in 1996. Can you guess what major change in computer history was happening around the latter's time?

Everything was GIANT-locked when Python was designed, unless it was specifically intended for SMP mainframes. The entirety of the FreeBSD operating system had a GIANT lock on it at the time, for instance. Linux didn't even exist. Mac OS and Windows both were fundamentally single threaded and cooperatively multitasked. Commercial Unices that supported SMP were only ~4-5 years old and a very small niche.

You might as well be complaining about "why didn't the x86 architecture just have 64-bit capabilities from the outset?"

> * Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references.

In other words: "it's not Java, so it's bad".

Java is a pure-OO language; Python is a procedural language with OO as an optional feature. To that end, it exposes OO-features in an optional manner versus forcing you to use them against your will.

So if the basis of all your arguments is "OO is better in Java", well the the response is "yeah I'd hope so, since you have no other choice as it's the fundamental paradigm". Guess what? Haskell is much better at functional programming than Java; that also doesn't make a valid argument about whether either is good or bad.

> * Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).

Java was developed 7 years later and during a time that Unicode was becoming the standard over ASCII. Python was designed when everything was still ASCII and Unicode a mere glint to the general computer science realm.

As you pointed out, even Java made a bad decision here due to their premature adoption of the standards (as any modern designed language is quick to point out).