Before discussions go into some generic direction about the field. This is a huge feasibility study contain different aspects done by hundreds of people. People who are mostly interested about the physics case of FCC should read/skim at least through the first volume [1], second chapter (Specificities of the FCC physics case) the first four sections. This is about 35 pages with somehow accessible language to people with some physics knowledge.
Personally I'm interested in their proposal about how they are going to approach software (Section 8). They plan to provide experiment agnostic and unified framework that is actually unified and user accessible. The field really need something like that, it is usually the pain point of most junior graduate student. The field suck at documentation and keep coherent software and write code in a bad way most of the time. I think they can have much better framework than Fermilab's art [2].
>hey plan to provide experiment agnostic and unified framework that is actually unified and user accessible. The field really need something like that, it is usually the pain point of most junior graduate student. The field suck at documentation and keep coherent software and write code in a bad way most of the time. I think they can have much better framework than Fermilab's art [2].
I don't think that I've ever heard of an area of software where folks say "it's got great documentation and the code's really good". In fact many programmers react allergically to any code that they review (including code that they wrote themselves but have forgotten about).
I'd echo this somewhat. Wading into other people's projects I'm often like "wtf is this mess.. why are your variables named a, b and c?"
BUT.. some of the code that LLMs have spit out at me is absolutely wild in how well it is constructed, and it gives me real imposter syndrome when I see the occasions when the code is so much tighter and better than I would have personally crafted.
A large part of that is just following style guides. It's crazy how few people actually read things like PEP8 despite writing tons of code in python. It's not even that much to learn and most is quite logical - all while making your code not just appear professional but also be more readable by others.
Also before the discussion goes off in a random direction such as software frameworks, I want to point everyone to volume 37, book 5, chapter 72, pages 8843-9023 (2022 incremental update) of their feasibility report. In it, they introduce a new cryptocoin known as "HIGGSCOIN" which will help fund the reactor. It has some interesting innovations for realtime payment systems, something that can be a pain point for bitcoin
Personally I'm interested in their proposal about how they are going to approach software (Section 8). They plan to provide experiment agnostic and unified framework that is actually unified and user accessible. The field really need something like that, it is usually the pain point of most junior graduate student. The field suck at documentation and keep coherent software and write code in a bad way most of the time. I think they can have much better framework than Fermilab's art [2].
[1] https://cds.cern.ch/record/2928193
[2] https://art.fnal.gov/