Hacker News Reader

Comment by SoSoRoCoCo | Hacker News Reader

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.

View on HN

> 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?

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.

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.

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.

Yes, that's true. And aren't some versions of RedHat still on 2.7 too?

But I class this as a packaging issue more than a 2.7 vs 3.x issue: you see the same problems with (as a random example...) different versions of OpenCV - people not using virtual environments have problems even if they are all on 3.7.

When I think of the "2.x vs 3.x problems" I was thinking more of the language and core libray level incompatibilities.

macOS ships with both py2.7 and 3.7, `python` would call 2.7, and `python3` would 3.7

As of macOS 11.0 there is no python anymore. You have to download it.

Really? YAY!!! I upgraded to Big Sur and it is still there... but I don't know if it is a legacy since I've been TimeMachining my machines since 2012 and things persist.

Hmm apologies, I was wrong.

The Catalina release notes[1] said they would remove it and I was sure they mentioned it again in this year’s WWDC but apparently it’s still included after all.

[1] “Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.”

> Linux did take over the world, just not on the desktop.

I'm honestly not sad that it never happened.

It took over my desktop around ~1998 and I wonder if massive adoption of Linux on the desktop would have benefited me or been worse (from my perspective).

As it stands literally every single tool I want/need to do my job is already available for Linux and indeed many of those tools are simply better on Linux (docker on a mac is horrible, I have a work issued current gen macbook pro, I use it purely for testing docker set-ups and then it goes back in its case).

Its going to sound elitist but not dumbing down the platform for the average user is a benefit to me.

Well, it would certainly make may day live easier if we had Microsoft Office, the Affinity Suite, and Lightroom on Linux, which would probably have happened if Linux was the dominant desktop.

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).

> "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.

> 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

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/web-environment

Ah, but it does expose Linux you say, 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.

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?

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).

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 :)

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)

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.

reminds me of standardization of the shipping container, not sure of all the details of how that push had happened though

Reply on news.ycombinator.com