Hello, this post is inspired a bit by the virtual Nim conf (all the talks were very interesting). I thought I'd jot down some thoughts if why I'd like to switch to Nim from Python. I hope that this is helpful. Sorry if it's a bit long-winded.
Many years ago I was tasked with looking after a database for a particle physics experiment. My task required writing scripts. As I was unfamiliar with scripting in those days a colleague suggested to me Perl. He showed me how to write a script to do do the tasks that I needed. I found this to be magic. Chiefly because I didn't understand all the special symbols and incantations in the script. I was able to do extremely simple things, but nothing more.
I then stumbled upon Python and found I was able to create scripts much more easily. I could even write a script that read and wrote to a file (you can appreciate how poor my grasp of Perl was)! I was so happy with the language that I suggested it be adopted by our experiment. It was. This was in 1999/2000. I mention the date as you'll understand that this was an early version of Python. It was not as popular as today, didn't have as many libraries and (I believe, although my memory could be faulty) was not installed by default on Linux. But, we found the expressiveness and the ability to get productive quickly a big selling point.
A few years ago I stumbled upon Nim. I thought it seemed interesting and decided to give it a whirl. This was at the time when early versions of Python 3 had been released and I was looking around for another language as I was concerned that the migration from Python2 to Python3 may not be so simple. I think my concerns are probably unjustified as there are a lot of people using Python (many hands make light work). I like the built-in static typing and the syntax. I found that I could do simple things relatively quickly. I think that it can be a very useful language for people that have worked in Python to migrate to.
I am excited about Nim now as I was about Python back at the turn of the century.
For me things that I thought were missing in Nim are:
There is already quite decent documentation and a good book on Nim. I think that the community is very friendly (at least that's my experience so far).
I think that Nim is a great language with a lot of potential! I hope that I can help the community (with my limited skills).
I always like to hear about why people pick Nim!
Many years ago I was tasked with looking after a database for a particle physics experiment.
That's awesome! May I ask which experiment that was? Just curious, because I'm currently doing my PhD in Physics. The majority of my group actually works on ATLAS (both data analysis and hardware development for the HL-LHC), but I search for axions with CAST. :)
Hello,
The experiment I worked on was BaBar at SLAC. Although the simulation and reconstruction and analysis code was written in C++ book-keeping was better done in a scripting language. It was easier to do this in Python. I _think, but you would know better, Python has moved to the analysis area too. So, more researchers are using Python there.
For analysis, I think Nim could have an advantage as it's faster. I think the time to develop the code is about the same, but Nim would reduce the execution time. It would also help to reduce the debugging time as a chunk of time is spent keeping track of which variables are which type.
I think I recall that someone wrote an interface to ROOT for Nim, so you can read and manipulate your data in Nim.
For your analysis are you using Nim? I think that would be a great thing. I know nothing about Axions, or searches for Axions. I should look it up to find out more.
I would think that data analytics people would be interested in Nim as the turn-around time would be quite short.
Another area that I think Nim could be very helpful is in SageMath (similar to Mathematica). This code is written in Python, and I think that there would be significant gains in it being written in Nim. I think it would be a significant job to do.
hope your day goes well, adil
Another area that I think Nim could be very helpful is in SageMath (similar to Mathematica).
SageMath is a loose collection of C/C++/Fortran/Cython/Python libraries wrapped in Python. I expect that most of the time is actually spent in the low-level languages rather than the Python glue.
Also developing a SageMath equivalent in Nim would require contributors significantly well-versed in all domains of science and engineering.
For example SageMath includes:
i.e. developing a SageMath-like package would be the ultimate goal once we have a critical mass of scientific libraries https://github.com/nim-lang/needed-libraries/issues/77
a way to rapidly check snippets of code. I think in this regard inim would be very useful. I tend to be a bit of a hacker and tend to experiment with snippets of code to understand how they work before slapping them into a program.
INim is great. Also if you're using VSCode you can try Code Runner aswell. You are able to select a few lines of code and run it.
The experiment I worked on was BaBar at SLAC.
Oh, that's nice and also a kind of a funny coincidence. That means you were involved with an experiment studying weak CP violation whereas we're now trying to study strong CP violation, heh.
Although the simulation and reconstruction and analysis code was written in C++ book-keeping was better done in a scripting language. It was easier to do this in Python. I _think, but you would know better, Python has moved to the analysis area too. So, more researchers are using Python there.
Yes, a lot of people use Python all over the place in physics now. Most of my ATLAS colleagues write their ROOT scripts using pyroot / rootpy instead of ROOT's C++ abomination. Which is always kind of funny when you see them talking about "running python" but encountering segmentation faults... :)
For analysis, I think Nim could have an advantage as it's faster. I think the time to develop the code is about the same, but Nim would reduce the execution time. It would also help to reduce the debugging time as a chunk of time is spent keeping track of which variables are which type.
Oh yes, for sure! Unfortunately I feel most physicists don't realize that dynamic typing is a burden.
I think I recall that someone wrote an interface to ROOT for Nim, so you can read and manipulate your data in Nim.
Yes? I haven't seen that. Sounds to me like creating that wrapper would be kind of a pain, given how ROOT is 1. C++ and 2. essentially provides its own standard library.
For your analysis are you using Nim? I think that would be a great thing. I know nothing about Axions, or searches for Axions. I should look it up to find out more.
Yep, I'm writing my whole analysis in Nim. Since the axion community is still pretty tiny (although it has been growing and should grow even more now after the last European Strategy for Particle Physics update, which really endorses axion searches) I'm not really forced to use some existing analysis framework. There was some code written by my predecessor, but that was all ROOT and MarlinTPC. Threw it all away and started from scratch. Code is here:
https://github.com/Vindaar/TimepixAnalysis
It's one big mono repository for my whole thesis essentially though. The most interesting code is the Analysis directory.
In general axion searches all deal with the same big problem: given that axions haven't been detected yet, it means their detection via some interaction is hard (-> coupling constants are tiny). What does that imply? Of course that no matter what kind of experiment one builds, all sorts of background will massively dominate everything one measures. So they are all very low rate experiments, which need the best possible background suppressions (both hardware and software wise) as possible. In that sense it's a little similar to neutrino experiments, except even worse. Also neutrino experiments of course have the benefit nowawadays of simply having a lot more manpower and money to build in better locations (e.g. waaayy below ground to shield from cosmics) than we do.
My experiment - CAST - is simply sitting in a random hall at surface level at CERN. The only shielding from muons I have is ~20 cm of lead. So there's still like ~1 muon every couple of seconds in my detector. What we want to measure are X-rays which are the result of axions entering our magnet (LHC prototype dipole magnet, 9 m long, 9T magnetic field) and interacting with the virtual photons of the magnetic field. These would just be the result of X-rays interacting in the Sun and randomly converting to axions and then leave the Sun unhindered.
Have a great weekend!
The CERN ROOT effort is indeed a wrapper: https://github.com/watson-ij/nim-root, but it could provide an interface to ROOT which could be useful?
Goodness your code looks quite extensive! I am sure your community would be interested in reusing some of your code. Just a thought, have you considered giving a talk at CHEP? To me, it looks like it would be worthy of a talk at CHEP (https://www.jlab.org/conference/CHEP2021). I am not in the committee (certainly not an academic), but I would think there's a place for it. Incidentally, I personally hope they make the conf virtual as I'm not sure things will be fine in May/21 (I hope so, but I am not sure).
I've heard of neutrinos as my wife works on T2K and Hyper-K.