One actually has to install Excel too. (And before you say it’s pre-installed on Windows, that’s not always true, and for me there were lots of issues and complexities surrounding my outlook/office/Microsoft account, which I still don’t understand, before that stuff worked).
In the context of a company that uses Excel extensively in its internal processes, no.
I’ll agree that installing Julia can be easier than installing Excel and getting your license working, but you cut off the difficult part from my quote: typing the right commands and file paths to get a notebook to open. Excel users want to click not type commands. I intend to try to figure out a Makie or Genie front end for my package at some point, since Pluto was not the quick fix I hoped it would be for easy interactive visualization.
Are there any scientists using Excel, except for non-scientific tasks?
Biologists actually renamed genes because excel kept converting them to dates
I know the intent of that is to be helpful, but it’s not because it’s not actionable. To make this actionable, please share the following types of information.
- What documentation were you reading that you thought needed to be improved? Was it on multi-GPU computing, symbolic differentiation, or something else? These are all “the documentation” of Julia and its ecosystem, and which part of this world are we talking about?
- What did you find needed to be improved? Was it the language and grammar that was bad? Was it missing examples? Did you not find the examples useful towards what you were trying to do? Or was the documentation for what you wanted completely missing?
It’s just that some people just accept the issues and struggles surrounding excel and office, but immediately glaze over when presented with anything new that is non-zero effort.
It’s a bit annoying sometimes.
Will, this could be mitigated with building one-click installers…
There’s actually something like this in the works for VS code!
MS Office gets pre-installed on my work computer by our IT people. I also got VS Code (being MS software) installed and administered by them, so zero effort.
To get Julia I needed permission. Our IT is relatively liberal, and I have a trusted connection and even got admin privileges for my computer, so that was not a problem. But could easily be a problem in a little bit more “corporate” setting.
I’d say not just “some” people, but the majority. And there many good reasons for that. One of these: MS Office is what everyone use, thus you practically have to use it too to be able to exchange documents with colleagues. Another reason: it is just a tool to get the job done, and as a tool it is good enough.
For an alternative tool to be successful, it has either to offer some unique or major advantages, or be really easy to use. “Easy to use” meaning easy to use for people who only can open file by a double click in the Windows Explorer. The means one-click installer and GUI is a prerequisite. BTW I don’t see file size as a problem: A couple GBs of download is nothing special.
Yes, sure! A lot. There are a lot of scientists doing main part of their work away from computer, who use Excel to organize and process data, which I would regard as science. Most of them even never programmed in any language, at least after the university.
Ok, they are called scientists, but their work in Excel is probably not rocket science?
As long as you hardly care at all about the result.
Excel is really really AWFUL if you care about the result. It’s a huge worry because engineering offices design bridges and such on the basis of Excel spreadsheets that almost certainly have a lot of bugs.
There was a big kerfuffle in the econ/policy world where Reinhart and Rogoff made some strong recommendations about economic policy based on essentially Excel errors: The Reinhart-Rogoff error – or how not to Excel at economics and that’s just one of the more public and well known examples. The number of major bugs in Excel spreadsheets causing science errors must be astronomical.
Of course all software has bugs, but Excel makes it particularly easy to miss them, as the “code” is invisible until you click on each individual cell and there are a lot of “automatic” behaviors which vary from version to version (like deciding things are dates rather than names)
And despite the gross error identified, governments and main stream economics simply continued to consider that their result was correct and that policies should take it into account very strictly.
Which just goes to show that Excel was the right tool for the job, because no-one really cared about the result, they just wanted to do whatever they wanted to do
No one with an account on this forum is going to argue that Excel is a better tool than Julia for scientific analysis, but if we are going to take Julia “to the next the level of popularity”, then we need to build tools with Julia that everyday people* enjoy using. Then when they ask “Wow, how did you make this?”**, they will have some interest in learning Julia. That is step 1. Currently, the reaction to my package run with main()
from the REPL, is “Woah, retro! That looks like an 80s sci-fi movie.” I’d really rather them say, “Wow, how simple and elegant”, so I have some work to do to get it there. I hope that continued development on Genie, Makie, Pluto, Package Compiler, etc. makes this easier in the future. (Excel is at least simple if not elegant.) Step 2 is then to make Julia itself easy to pick up and use. VSCode and Pkg need a lot more development and documentation before that will be true, but I have banged that drum enough already. (Anyone remotely near a scientific field already knows how to use Excel, and it is as mature as it is going to get.)
*Remember that you on this forum likely have more technology knowledge and motivation to overcome obstacles than average.
**Most of the really cool Julia tools I have seen are very academic and nerdy. It would be nice to go broader and not just deeper to build our user base. Obviously complex science is the bread and butter, but I don’t see any reason that Julia can’t do all the things that Python is currently doing eventually. I’d like to see us build our user base from new coders too, not just Matlab and Python converts.
I think the very first thing to do to achieve this should be that the Pluto notebook needs another file extension rather than .jl
which is actually very annoying. I always find it confusing to identify a notebook file from a common Julia script in Finder.
A Pluto notebook is supposed to function like a script though. That is a critical feature.
For Linux, macOS, or other Linux systems, a hash bang line at the top may help.
However, Windows could be complicated.
The best solution would be in the code itself. The script runs and then starts Pluto on itself.