6 ms·

It is great that you respond with succinct reasons. People who have used Python for some years seem to forget just how clunky it really is. I've been using Exc

It is great that you respond with succinct reasons. People who have used Python for some years seem to forget just how clunky it really is. I've been using Excel since 1990, and sure, it has its own warts, but Python is a very rudimentary tool compared to Excel. Python is a machine shop. Excel is a car. It may be a lemon, but it's a functional car. This is a great example of programmers not being able to see the forest for the trees. Reminds me of the "Once Linux gets a desktop it will take over the world" debate from circa 1997-today.

fock 6y ago
I wonder what the problem is with standarizing companywide around python@3.x, numpy@1.1x and pandas@1.x. At this point these can all be considered mature and why on earth would an org, which is not developing these packages, nor heavily consuming outside code (because they didn't with excel either in a sensible way?) decide to jump on the "but we need rrrrrollling release"-fad bandwagon?
- yold__ 6y ago
  The problem isn't feasibility, it's resources. Building and rolling out a standardized environment, and maintaining it, will cost millions of dollars. It shouldn't, but it does. And for what added benefit? The end-users don't want it, you'd have to spend another couple million for a lateral move at best. More than likely, you'll end up with a pile of Python spaghetti code that runs slower than the spreadsheet (see point #4 about massively recursive calcs).
  - shnock 6y ago
    Why does building and rolling out a standardized environment cost so much? Could you break down the requisite steps and resources required to achieve this? Thank you, I appreciate it :)
    - yold__ 6y ago
      Up-front costs (mostly salaries, but all I.T. projects are "billable") 1.) Getting buy-in from solutions architect, software architecture, information security, I.T. management. This will be a 6 month process. 2.) Getting buy-in from actuarial management and audit. Another 6 month process. Recurring annual costs (over 10 years) 3.) Contractor at $150 an hour = $300K annually 4.) Contractor PM at $50 an hour = $100K annually 5.) Information security compliance hoops, getting it to play nicely with the myriad of endpoint security tools, etc 6.) Ongoing maintenance and support (failed rollouts and upgrades, user desktop support, user training)
      - tomnipotent 6y ago
        This isn't realistic at all. Assuming actuaries know Python like they know Excel, the only other added cost is someone technical to slap together a working environment, which isn't particularly hard when compared to the state of what Excel offers in a collaborative environment. You just don't jump from "humans in Excel" to "CI/CD perfected pipeline" overnight, nor do you need it. Excel shops still have costly expenses rewriting entire workflows/re-doing Excel files constantly as people come and go, it's not like there isn't already maintenance cost with the current method.
    - buryat 6y ago
      reminds me of standardization of the shipping container, not sure of all the details of how that push had happened though
trimbo 6y ago
> Reminds me of the "Once Linux gets a desktop it will take over the world" debate from circa 1997-today. Linux did take over the world, just not on the desktop. It was on servers and mobile, which now have more users than desktops or laptops (edit: servers via the web). Technology gets its warts fixed when it grows along an explosive new market, especially if the market ends up being larger than the last. Python is currently riding the data science wave, and that wave is growing. If that market expands to the point where large scale data-science type work wags the dog of VBA/excel, the clunkiness[1] will work itself out. [1] - I don't actually understand what's clunky about Python in the context of the article. Seems like a reasonable direction in a complex market (reinsurance) driven by actuaries. I'd be surprised if newgrad actuaries/stats people aren't using Python?
- SoSoRoCoCo 6y ago
  Absolutely. I worked at Intel and our distributed computing pools went from a combination of SunOS and AIX machines to Linux in about 3 months, essentially overnight, (back in the 90's). It was an astonishingly fast deployment. Linux dominates the server world AND the entertainment device world (hello busybox & gstreamer!) [1] Regarding clunkiness of Python: mostly it is the packages, installation, and 2.x vs 3.x nightmare that persists. Everyone seems to forget the initial pain getting the Python env to work, esp. when it comes to cython native compilation issues / arch wheels, unsupported packages, etc. The only issue I have with python is it is extremely challenging to make cross-platform deployments for single-executables. I've tried three different approaches and they were all trainwrecks. Once that is ironed out, I'll be switching from Electron to whatever Python offers.
  - nl 6y ago
    I think the 2.x vs 3.x issues have mostly been resolved by now. I don't think I've hit one for a long time, and even StackOverflow answers are more likely to be Python 3 now.
    - SoSoRoCoCo 6y ago
      macOS still ships with Py2.7 and has dependencies, and npm-gyp only recently switched to 3.x. same with python SDR. it depends what you use: less popular packages are still languishing. but that discounts the tens of thousands of projects that are already out there that are in use and need conversion. it'll take probably 3-5 years for it to really go away.
atoav 6y ago
Depends really on your proficiency at python and the task at hand. For many "small fry" tasks Excel is perfectly fine and faster. Good when the table data is meant to be in foreground. For things where data exploration and formulas should be in the foreground or where data and formulas should be strictly separated python (or a python/jupyter notebook) has tangible benefits (e.g. really good list syntax).
rualca 6y ago
> "Once Linux gets a desktop it will take over the world" debate from circa 1997-today. Pretty much all servers run on linux. Linux also dominates smartphones in the form of Android phones. Chrome OS is also linux, and it's market share is currently at around 6%. I mean, other than desktops Linux pretty much is everywhere.
- pjmlp 6y ago
  > Linux also dominates smartphones in the form of Android phones. Not really. See any Linux specific APIs on the NDK official APIs? https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Android is a mix of Java and Kotlin based frameworks, ISO C and C++, POSIX subset and a couple of additional libraries. Whatever kernel gets used is an implementation detail for Google and Android device makers. Can be completely replaced in Android 12, and the eco-system would continue to work. > Chrome OS is also linux, and it's market share is currently at around 6%. Basically Android (already mentioned above) and Web stacks. https://chromeos.dev/en/android-environment https://chromeos.dev/en/android-environment https://chromeos.dev/en/web-environment https://chromeos.dev/en/web-environment Ah, but it does expose Linux you say, https://chromeos.dev/en/linux https://chromeos.dev/en/linux Indeed, except of the small detail that as shown on the Google IO talk, it is actually a design similar to WSL 2, running a second kernel on a hypervisor based environment. The real kernel powering ChromeOS doesn't get exposed to userspace and can also be replaced at any time, if Google so desires. In fact, in a near future Android and ChromeOS can be running on top of Fuchsia and most consumers wouldn't even notice.

fock 6y ago

I wonder what the problem is with standarizing companywide around python@3.x, numpy@1.1x and pandas@1.x. At this point these can all be considered mature and why on earth would an org, which is not developing these packages, nor heavily consuming outside code (because they didn't with excel either in a sensible way?) decide to jump on the "but we need rrrrrollling release"-fad bandwagon?

yold__ 6y ago
The problem isn't feasibility, it's resources. Building and rolling out a standardized environment, and maintaining it, will cost millions of dollars. It shouldn't, but it does. And for what added benefit? The end-users don't want it, you'd have to spend another couple million for a lateral move at best. More than likely, you'll end up with a pile of Python spaghetti code that runs slower than the spreadsheet (see point #4 about massively recursive calcs).
- shnock 6y ago
  Why does building and rolling out a standardized environment cost so much? Could you break down the requisite steps and resources required to achieve this? Thank you, I appreciate it :)
  - yold__ 6y ago
    Up-front costs (mostly salaries, but all I.T. projects are "billable") 1.) Getting buy-in from solutions architect, software architecture, information security, I.T. management. This will be a 6 month process. 2.) Getting buy-in from actuarial management and audit. Another 6 month process. Recurring annual costs (over 10 years) 3.) Contractor at $150 an hour = $300K annually 4.) Contractor PM at $50 an hour = $100K annually 5.) Information security compliance hoops, getting it to play nicely with the myriad of endpoint security tools, etc 6.) Ongoing maintenance and support (failed rollouts and upgrades, user desktop support, user training)
    - tomnipotent 6y ago
      This isn't realistic at all. Assuming actuaries know Python like they know Excel, the only other added cost is someone technical to slap together a working environment, which isn't particularly hard when compared to the state of what Excel offers in a collaborative environment. You just don't jump from "humans in Excel" to "CI/CD perfected pipeline" overnight, nor do you need it. Excel shops still have costly expenses rewriting entire workflows/re-doing Excel files constantly as people come and go, it's not like there isn't already maintenance cost with the current method.
  - buryat 6y ago
    reminds me of standardization of the shipping container, not sure of all the details of how that push had happened though

trimbo 6y ago

> Reminds me of the "Once Linux gets a desktop it will take over the world" debate from circa 1997-today. Linux did take over the world, just not on the desktop. It was on servers and mobile, which now have more users than desktops or laptops (edit: servers via the web). Technology gets its warts fixed when it grows along an explosive new market, especially if the market ends up being larger than the last. Python is currently riding the data science wave, and that wave is growing. If that market expands to the point where large scale data-science type work wags the dog of VBA/excel, the clunkiness[1] will work itself out. [1] - I don't actually understand what's clunky about Python in the context of the article. Seems like a reasonable direction in a complex market (reinsurance) driven by actuaries. I'd be surprised if newgrad actuaries/stats people aren't using Python?

SoSoRoCoCo 6y ago
Absolutely. I worked at Intel and our distributed computing pools went from a combination of SunOS and AIX machines to Linux in about 3 months, essentially overnight, (back in the 90's). It was an astonishingly fast deployment. Linux dominates the server world AND the entertainment device world (hello busybox & gstreamer!) [1] Regarding clunkiness of Python: mostly it is the packages, installation, and 2.x vs 3.x nightmare that persists. Everyone seems to forget the initial pain getting the Python env to work, esp. when it comes to cython native compilation issues / arch wheels, unsupported packages, etc. The only issue I have with python is it is extremely challenging to make cross-platform deployments for single-executables. I've tried three different approaches and they were all trainwrecks. Once that is ironed out, I'll be switching from Electron to whatever Python offers.
- nl 6y ago
  I think the 2.x vs 3.x issues have mostly been resolved by now. I don't think I've hit one for a long time, and even StackOverflow answers are more likely to be Python 3 now.
  - SoSoRoCoCo 6y ago
    macOS still ships with Py2.7 and has dependencies, and npm-gyp only recently switched to 3.x. same with python SDR. it depends what you use: less popular packages are still languishing. but that discounts the tens of thousands of projects that are already out there that are in use and need conversion. it'll take probably 3-5 years for it to really go away.

atoav 6y ago

Depends really on your proficiency at python and the task at hand. For many "small fry" tasks Excel is perfectly fine and faster. Good when the table data is meant to be in foreground. For things where data exploration and formulas should be in the foreground or where data and formulas should be strictly separated python (or a python/jupyter notebook) has tangible benefits (e.g. really good list syntax).

rualca 6y ago

> "Once Linux gets a desktop it will take over the world" debate from circa 1997-today. Pretty much all servers run on linux. Linux also dominates smartphones in the form of Android phones. Chrome OS is also linux, and it's market share is currently at around 6%. I mean, other than desktops Linux pretty much is everywhere.

pjmlp 6y ago
> Linux also dominates smartphones in the form of Android phones. Not really. See any Linux specific APIs on the NDK official APIs? https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Android is a mix of Java and Kotlin based frameworks, ISO C and C++, POSIX subset and a couple of additional libraries. Whatever kernel gets used is an implementation detail for Google and Android device makers. Can be completely replaced in Android 12, and the eco-system would continue to work. > Chrome OS is also linux, and it's market share is currently at around 6%. Basically Android (already mentioned above) and Web stacks. https://chromeos.dev/en/android-environment https://chromeos.dev/en/android-environment https://chromeos.dev/en/web-environment https://chromeos.dev/en/web-environment Ah, but it does expose Linux you say, https://chromeos.dev/en/linux https://chromeos.dev/en/linux Indeed, except of the small detail that as shown on the Google IO talk, it is actually a design similar to WSL 2, running a second kernel on a hypervisor based environment. The real kernel powering ChromeOS doesn't get exposed to userspace and can also be replaced at any time, if Google so desires. In fact, in a near future Android and ChromeOS can be running on top of Fuchsia and most consumers wouldn't even notice.