Writing good Haskell always seemed harder to me than something like Python. The amount I'd have to think before beginning to type was a lot, but it always seemed worth it, as there was always potential always for a beautiful solution to any problem.
As a result, before I write code in any production language I give a little more thought to what I'm about to write, which I think ends up with a better result.
Heck, even if Haskell just gave a developer an appreciation for basic functional programming, that would be something that will benefit them for years in my view.
Maybe they're looking to get a lot of granularity.
Thinking of, https://haveibeenpwned.com/, you could give an email address and get value from the site, but there's no need for an account.
Assuming you store the email that's certainly more of a privacy/security risk than using it once and throwing it away.
Possibly. The wording is odd. It assumes that I have information about the identity of a user, but the only thing I have is the email address.
If my app asks for more data, which are backed up as a service to the user (no tracking), that is of course connected to the email address of the account. However, there is no effort from my side to find the actual identity of the user.
This whole identity thing is very confusing. Might need to contact Apple developer support.
This seems like such a significant problem for the language and has been around since the beginning of time.
Considering the amount of value that Python adds to companies and individuals around the world, is there a reason that institutions or someone with the means hasn't funded a project to "solve" the GIL problem?
It's far more common to have Python programs be I/O bound, and when they are CPU bound it's often not due to GIL contention (remember that C extensions can drop the GIL before doing something lengthy). It would be nice if the GIL was gone but a fair fraction of Python developers would not notice much difference.
> It's far more common to have Python programs be I/O bound
But part of the reason for that is that Python programmers know there's no point in trying to run multiple CPU-bound tasks in the same Python process, so they don't try.
> C extensions can drop the GIL before doing something lengthy
Yes, but they're still limited in what they can do--as soon as they call back into a Python bytecode they're GIL-bound again. And if you depend on C extensions any time you need CPU bound concurrent tasks, you're giving up a lot of the advantages of using Python in the first place.
It’s part of the reason but not all or, I suspect, even most: the number of things which people need to compute with multi threading but without much I/O is not an especially large fraction of what people use pure Python for. If you need raw CPU speed for arbitrary code, it’s not the language most people would pick.
The exceptions also tend to have existing high-quality extensions (crypto, compression, image processing, etc.) so while it’s technically true that you’re giving up Python most people aren’t doing that personally - they’re just calling Pillow or numpy - or they’re using it for a tiny fraction of the total program.
Frequently this ends up being the same speed or even faster than using other languages because most people are either using the same C libraries or learning just how many optimizations their simple implementation lacked.
Again, it’s not hard to come up with things where the GIL is inarguably a bottleneck but it comes up a lot more in debates than real-life in my experience.
I'm one of those with embarrassingly-parallel cpu-bound workloads. The multiprocessing module works, but the extra bookkeeping and plumbing over an actually-parallel-multithreading implementation is a pain in the butt. That said, the multithreading speedup is both faster and easier than porting to another language.
Definitely - I used to support a computational lab and have worked on enough other CPU-bound problems to have plenty of things which I wouldn’t recommend Python for. I just think that as a field we’re predisposed to focus on that as the kind of work Real Programmers™️ do when most groups are limited by their ability to implement and maintain business logic long before they hit the wall on what Python can do.
I think it's just not that big of a problem / can be worked around. I had a multi terabyte of RAM across 1000s of cores python product and we just used one process per core
Unladen Swallow wasn’t actually a serious attempt like V8 or anything and a large part of why it failed was that LLVM wasn’t ready and even when it was, it was ill suited to compiling a highly dynamic language like Python.
I think the big problem is all the code out there that depends on the GIL. A hypothetical python4 that removed the GIL would probably cause issues of the same general nature as the 2 -> 3 migration, though at a reduced magnitude.
I deployed on a sub five times in four years, so I'm maybe not the best one to give an example. For us, we got used to the 'no outside' within a day or so as there is always so much else to do.
Long term, you make friends, come up with portable hobbies, and just dig in to the job for a while.
I use it too much, but it's true. The world gets better when people put effort into it, not just because time passes, and its important to remind others that complaining is cheap but doesn't pay dividends like fixing problems. Along with the idea “A society grows great when old men [people] plant trees in whose shade they know they shall never sit”. Learn to enjoy planting the proverbial trees, the future will be thankful; and to be frank, we owe the future better than today. It is on loan to us, and we should act accordingly.
this seems like the real magic here. The author states at the start, automating all of the steps of something can be daunting. But this script can incrementally become a do everything script.
