> If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
People from the 70s are in their 50s today. Approaching retirement age, but most still able and employed. Things will get interesting in those countries as they hit old age and quit the workforce in a large wave.
> Unlike the metric system that actually has a clear logic behind it and makes handling scientific numbers more easy
The clear logic behind soccer is low barrier of entry. A vacant lot, some friends and a makeshift ball gets any child started. Even the poor can play it with minimal inputs.
> It’s just that Brazil currently doesn’t care about baseball that much and baseball first has to become popular
Baseball is a hardware-intensive sport. It's hard to get popular in poorer countries. Soccer on the other side demands just a vacant lot and some soft round object you can kick around to get started.
You just need a bat and ball? My friends use a plastic bat balls and find a grassy field. Soccer balls are actually more expensive.
Basketball is growing in Brazil a lot and that’s kind of expensive.
Skateboarding has become massive in Brazil and that’s even more expensive than soccer and every person needs their own skateboard, unlike soccer where you can pool your money to share 1 ball.
Idk what you are talking about, you don’t need fancy equipment to play most sports with your friends. Most of the time, it’s having the idea is the issue.
There is no supply chain of baseballs and baseball bats in Brazil. That would be considered a "exotic" choice of sport, with those supplies only available at expensive stores with imported goods
Right, but the limiting factor is not actually that it’s expensive.
The limiting factor is historical: Brazilians just don’t think of playing baseball already.
Which leads back to the point: Americans just don’t really think about playing soccer.
It’s not about cost, or about leagues, or any technical thing. There’s nothing stopping me, as an American, from trying cricket with my friends, except that the thought has never ever entered my mind.
Not if you want to develop world class talent. Baseball is incredibly technology dependent at this point. Ultra high speed cameras, radars, bat and ball sensors, software tying it all together, it's become rocket science. And honestly, if you don't have access to that technology, your chances fall dramatically.
The article is about global soccer, I'm talking about global baseball (MLB takes all the best players in the world). If you are a pitcher wanting to make it to the MLB, getting to 18 and throwing 65 mph and claiming "well that works in my country" isn't going to help you. You are miles behind.
> The US has also strangely invented a lot of sports (Americans football, basketball, baseball, volleyball, lacrosse, skateboarding, snowboarding, and so on).
It appears the sports industry in US skewed local preferences toward hardware-intensive sports, that sell lots of gear. Poor children can start playing soccer stuffing crumpled paper in plastic bags to create a makeshift ball, and using spaced sandals as makeshift goalposts. Minimal hardware requirements. It's harder to play baseball or football without all assortment of costly bats, helmets, gloves, et cetera. Basketball comes closer to soccer in this regard.
>It's harder to play baseball or football without all assortment of costly bats, helmets, gloves, et cetera
In practice, casual football isn't any more resource heavy than soccer. Most non-league games of football are going to be "touch football", which only requires a ball, a field, and some sort of end marker (as a kid, it was usually just "from that tree to that other tree").
Obviously, organized league play has a ton more equipment, but the sort of informal casual games that kids or young adults play requires much less. It's one of those things that doesn't really get talked about a ton compared to league play, so it's easy to miss for those who didn't grow up with it.
A sturdy stick makes a decent enough baseball bat if you're hitting a light enough ball. It you can scrounge up a tennis ball, they work pretty well for street baseball. Don't need gloves, bases can be whatever you can agree on. Of course, it you have something vaguely soccerball shaped, you can play kickball with improvised bases rather than playing soccer.
>A sturdy stick makes a decent enough baseball bat
Right around the 80’s and 90’s the idea of zero-tolerance youth crime policies swept the US. Right around the same time the popularity of baseball began a decline in the US. It went from being a universally played ‘pickup culture’ sport, to a sparsely played ‘pay to play’ sport.
Now I’m not gonna say the need for 8 or 9 boys to roam around a neighborhood with a giant stick looking for a place to play was the reason the ‘pickup culture’ games died. But I will say that it was probably a lot safer for those boys to just go to a basketball court and wait their turn in a ‘pickup culture’ game that did not require a giant stick or bat.
This is way off. You only need a ball to play American football. Or a ball and bat to play baseball. Yes, the organized competitive versions have more gear involved, but so does organized soccer/football.
> What a shame it will receive a halt when they where starting to make progress I know that after submitting the pep it will go back to development.
To be fair, the apparent lack of progress of the JIT before was in part due to the same team improving the base interpreter by 40-50% between 3.10 and 3.14. The JIT implementation was pursuing a moving target. It was not some static milestone. Kudos for them.
> For that reason, the Steering Council is formally requesting a Standards Track PEP be authored that the community can discuss and the Steering Council can formally accept (or reject), making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors.
I didn't notice the current PEP was a provisional one. Hope the new one gets approved. The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
Thank You. As someone who don't follow python closely I thought their JIT would be similar to what Ruby has.
Not that Ruby YJIT or ZJIT is anywhere close to what JVM provides, but in this case it seems to be quite far ahead of Python.
Which is surprising given how many major companies are using Python. May be because those using Python are not using it as critical part of work unlike Shopify and Stripe which is their core language?
Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.
The python overhead of launching big ML jobs is nontrivial, so I think speeding that up would be meaningful. (I mean the initial tracing and other setup, not things once the GPUs are actually doing the work).
That seems more like the tracing overhead than the python overhead. The original jit proposal would I believe not help at all with that since ML workloads basically do their own jit. The post being discussed however pushes for a general framework and good tracing support so might help ML workloads.
Sure but best case 15% faster clearly isn't worth the complexity of a JIT. It really needs to be at least twice as fast. Pypy pretty much achieves that on average.
Right... but it's still only 15% faster than a simpler alternative. In a language that is 50x slower than the alternatives. Clearly not worth it.
Of course the counterargument is that they'll improve it and maybe in future it will be 100% faster... But that seems pretty dubious given the progress so far.
When I choose Python for something, it is clearly for its speed.
It is nice to have the speed, always. But in Python, it would be a mistake to do it at the expense of flexibility. Same for typing: it is great to have it. I use it. But Python should be dynamic and the rest and extension that does not compromise everything else.
If a JIT can make Python 2 or 3x faster, or even 10x for some workloads, that is nice. But the language itself should support same idioms, reflection, dynamic typing, etc at the same level.
The post clearly says the intention is to get a formal spec for formal integration.
To leave their experimental phase they have to define some goals to meet and that requires making some architectural choices that still aren't decided.
I suspect the recent "we updated the GC without a PEP and it went live and caused massive issues and we need an emergency point release revert" pushed for a greater degree of process overall.
> Assets and productivity, on the other hand, can grow a lot more than the population.
Source? In a growing market, one can spread their investiments to get safe returns that approach the overall economic growth. In a shrinking market, the same logic should lead to small losses, year over years, making investiment much riskier and unactrative. Markets are made of people.
> The pigeon migrated in enormous flocks, constantly searching for food, shelter, and breeding grounds, and was once the most abundant bird in North America, numbering around 3 billion, and possibly up to 5 billion.
Past performance is not indicative of future results.
reply