Hacker News Reader

> a bit lucky to catch the ML train

I'd argue that the fact that it was explicitly a design goal to be a teaching language meant that it saw wide-scale adoption by universities, which made it more likely that someone writing an adaptor library to old linear algebra packages would write it in python.

Perl6 was brave enough. It became a totally different language and lost much of its user base who moved on to Python, Ruby and to a lesser extent Node.

From what I saw, Python3 doesn't have type hints but it at least warns when you try to do stuff which involves magic, such as trying to increment a float.

Perl6 doesn't warn in those cases. If you use type inferrence it just happily goes ahead and uses the equivalent of perl5 BigNum which makes the code run 50x slower, instead of upgrading to BigNum when int overflows like Ruby does. If you use ugly C-style loops instead of nicer native for loops, your loop will run 2x faster. Too much magic or the wrong sort of magic can be really annoying sometimes.

> If you use ugly C-style loops instead of nicer native for loops, your loop will run 2x faster.

This is what I currently consider a workaround. At the moment if you have a constant endpoint and it fits in a native int, such as `for ^10`, it is already highly optimized and actually runs faster than the equivalent in Perl 5. That is not done yet where the endpoint is a native int variable. :-(

Since Python 3.5 (3 years ago) type hints are part of the core syntax. Don't need to put them in comments. https://www.python.org/dev/peps/pep-0484/#type-definition-sy...

> a_list = [] # type: List[T]

How do you do that with out a comment?

> a_list: List[T] = []

a_list: List[T] = []

from typing import List

a_list: List[T] = []

Visit https://docs.python.org/3/library/typing.html for more information.

They badly need to update the docs, then. Almost everything I see on that page does this:

vec = [] # type: Vector[float]

vec = [] # type: Iterable[Tuple[float, float]]

a = MyClass() # type: MyClass[int]

x = Foo() # type: Foo[int]

Ugh that's because PEP 484 (which introduced 'proper' type hints) only introduced it for parameters and return types and implemented in Python 3.5. Type hinting bare variables was introduced with PEP 526 and implemented in Python 3.6.

While I really like the concept of PEPs, and I think keeping original (like as they were written) PEPs around are the right thing to do, I do wish sometimes that Python did a better job at incorporating changes from PEPs into the core documentation once implemented.

the GIL was not removed or at least a solid parallelism story was not included

Not for lack of trying. People have been trying to do this since at least python 1.4. They just haven't found a way of doing it without negatively affecting single threaded performance, which Guido considers an unacceptable trade-off. http://pyparallel.org is probably the most interesting latest experiment in this field, but it never got cross platform support and seems to have stalled out.

They were breaking many things, maybe they should have rewritten the C API? From what I remember that's the blocker.

That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.

Here's a video and HN thread that covers most of the current problems with removing the GIL:

https://news.ycombinator.com/item?id=11842779

They did break all C extensions in py3k -- not so bad you can't work around it with some preprocessor magic but break it they did.

And they continued to break them within the py3k lifetime, mostly unicode related stuff from what I can remember. Probably still break stuff but I haven't had time for my toy python projects in a while so haven't been messing with the C-API lately.

We're actually agreeing here, I think.

I wished they had broken everything harder and once and for all, in order to fix the issue.

If there's going to be breakage anyway, people adjust their expectations. The scale is basically:

a lot of breakage > a bit of breakage >>>>>> no breakage.

Once you do break backwards compatibility, you might as well do it in a big way, provided you:

* don't offer vaporware for a decade (hello Perl 6!)

* try to offer some mitigations for the migration pain (auto-conversions, support libraries, top-notch docs, etc.)

* offer a great carrot at the end of the tunnel (good performance would be such a carrot)

The C api isn't the blocker for removing the GIL. The blocker is that Python is a dynamic language and there is no good way to know if another thread has just changed the underlying function on an object or not without having fine grained locking.

Fine grained locking works, but is expensive for non-multithreaded applications and slows down Python. It would speed up multithreaded applications though.

"I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX."

You can stop worrying. That is absolutely what will happen.

But it is a good thing. Languages should be something, not merely an accumulation of every fad and trend that appeared over its lifetime. That means eventually they will mature, and eventually hit a peak, and then fade. But during that process, at least you'll have a nice, mature language, instead of one always chasing the latest pretty-shiny, immature, confusing, crammed with too many features, with libraries constantly jerking around trying to keep up and always just a bit broken. Indeed, I kind of thing Python has already done a bit too much of the latter, and were I in charge of Python I'd give some serious attention to the idea of simply freezing the core language.

Python is what it is. Let it be what it is, because what it is is pretty good. It's by far my favorite language of the genre it is in. It's got way too much baggage to compete in the next arena, so let it be the master of the one it is in instead.

What's the last mainstream language that died? Even more so, what's the last mainstream language since the age of the internet that died?

Nothing truly dies anymore. It just lives as a ghost and haunts unfortunate journeymen.

> [Languages] will mature, and eventually hit a peak, and then fade.

"Maintenance mode" should be a badge of honor: you have created something that is a stable foundation for new things. For example, how many programming languages are implemented in anything other than C and/or themselves? Not a lot, and that's a huge compliment to C. Despite its faults, you can probably count on your C program working after you're dead.

> I think Python 3 was not brave enough, to be honest

Agree 100%. I would have added:

* fix the C API and pass the interpreter instance as the first parameter to all functions as is common in other interpreted languages, rather than relying on a global state.