3 ms·

You're conflating the engineer/scientist role here pretty severely. The engineer routes around the problem, the scientist tries to understand the problem bette

You're conflating the engineer/scientist role here pretty severely. The engineer routes around the problem, the scientist tries to understand the problem better. An engineer with a deadline will not be held up in any significant way by the GIL. The engineer will use one of the many ways you've already listed to solve the problem and move on. The scientist, not bound as strictly by deadlines or by "just being done", will explore the issue more leisurely, focusing on the whys and what the problem means. The scientist will explore the implications. I think only you are attempting to "blame" Python for this problem - the author's tone in no way suggests that the problem is in Python itself or even the CPython implementation. There's a distinct, "here's the lay of the land on this issue" about this article, rather than a "Python is at fault for these reasons..." that you seem to be interpreting.

dekhn 13y ago
I'm an ex-scientist (>10 years) who is now an software engineer (>5 years). Everything below is anecdotal, but based on a pretty large sample of engineers and scientists combined with a highly skilled anti-bias corrector. While I agree superficially in many ways with your characterization of engineers on deadlines versus scientists who will explore certain issues more closely, I think there are a number of things wrong with your comment: 1) As a scientist I frequently had to deal with the GIL. A major part of my time was taking C libraries, making SWIG wrappers for them, and using the Python SWIG libraries to do productive science. Once SWIG-wrapped, a good C library is very quick to do prototyping but it requires close attention and a good understanding of CPython API threading details to ensure your SWIG libraries are safe for other scientists. 2) Nor are "engineers on deadlines" going to accept the GIL in CPython. I'm an engineer on deadlines and after 18 years of programming in Python, I've switched to go because frankly, I can't see Python having much of a future anymore. 3) Ultimately, engineers and scientists are the same thing. 24% of the time of every scientist is spent coming up with some engineering solution in a hurry so you can get your experiment to work, (the other 75% of the time is spent writing grant proposals begging for money for the engineering and writing papers so that your grant proposals get approved, and 1% actually feeling true scientific inspiration). The whole "leisurely" word you use doesn't apply to how scientists anywhere in the real world work (except perhaps somebody with awesome funding nearing retirement, or perhaps some wealthy citizen-scientist with a home lab).
- diminoten 13y ago
  Scientist in philosophy, not scientist in profession. I would think of it like going to the moon. Curiosity took us there, but a lack of a financial motive to continue going there made future missions more difficult, to the point where we stopped going. People have effectively gotten around Python's GIL for most engineering purposes. Those who remain aren't doing so because they have a problem to solve, they remain because the GIL is is the problem to solve. An end, rather than a means. This makes it... well you're right, not leisurely, but certainly more pensive an activity than trying to solve another problem and having to "overcome" the GIL. I doubt anyone these days would get paid to fully remove the GIL implementation in CPython. And yes I get it, you're old as fuck and know more than everyone younger than you. Neat.

dekhn 13y ago

I'm an ex-scientist (>10 years) who is now an software engineer (>5 years). Everything below is anecdotal, but based on a pretty large sample of engineers and scientists combined with a highly skilled anti-bias corrector. While I agree superficially in many ways with your characterization of engineers on deadlines versus scientists who will explore certain issues more closely, I think there are a number of things wrong with your comment: 1) As a scientist I frequently had to deal with the GIL. A major part of my time was taking C libraries, making SWIG wrappers for them, and using the Python SWIG libraries to do productive science. Once SWIG-wrapped, a good C library is very quick to do prototyping but it requires close attention and a good understanding of CPython API threading details to ensure your SWIG libraries are safe for other scientists. 2) Nor are "engineers on deadlines" going to accept the GIL in CPython. I'm an engineer on deadlines and after 18 years of programming in Python, I've switched to go because frankly, I can't see Python having much of a future anymore. 3) Ultimately, engineers and scientists are the same thing. 24% of the time of every scientist is spent coming up with some engineering solution in a hurry so you can get your experiment to work, (the other 75% of the time is spent writing grant proposals begging for money for the engineering and writing papers so that your grant proposals get approved, and 1% actually feeling true scientific inspiration). The whole "leisurely" word you use doesn't apply to how scientists anywhere in the real world work (except perhaps somebody with awesome funding nearing retirement, or perhaps some wealthy citizen-scientist with a home lab).

diminoten 13y ago
Scientist in philosophy, not scientist in profession. I would think of it like going to the moon. Curiosity took us there, but a lack of a financial motive to continue going there made future missions more difficult, to the point where we stopped going. People have effectively gotten around Python's GIL for most engineering purposes. Those who remain aren't doing so because they have a problem to solve, they remain because the GIL is is the problem to solve. An end, rather than a means. This makes it... well you're right, not leisurely, but certainly more pensive an activity than trying to solve another problem and having to "overcome" the GIL. I doubt anyone these days would get paid to fully remove the GIL implementation in CPython. And yes I get it, you're old as fuck and know more than everyone younger than you. Neat.