gopaw, for Good Old PAW, is a program implementing the CERN-PAW commands and done with softinex tools.

Why doing gopaw? One recent motivation to do gopaw came from the introduction of the HDF5 file format in the Geant4/Analysis category (through the backend g4tools library) to store histograms and ntuples (see CHEP/2018 poster for this). Fine to produce files, but having interactive analysis tools that understand them would be highly welcome. And a tool that permits to open a file and plot an histo in two dedicated commands would be great, especially if these commands are familiar to physicists. A user API comes naturally: the one of CERN-PAW.

Why doing gopaw? A more older motivation is also to try to answer a more fundamental question: what is the best user API to do physics, and to manipulate HEP data in particular? A dedicated (command ?) language with "physics" keywords or a C++ or Python prompt ? Long time ago, someone said to us: with CERN-PAW I had the impression to do physics, with CERN-ROOT I have the impression to type C++. Then why not returning to do physics?! In the 1990s, when doers pushed to leave FORTRAN for C++ in order to have better I/O, better plotting, better graphics, was it unavoidable to push users to leave KUIP? a command system that, put all together, was perhaps more close to the physics than a C++ interpreter prompt exposing too much technicalities not related to the essential for a user. In the 1990s, was it not possible to just keep the facade of CERN-PAW for users, and then "behind the scene" have the doers smoothly migrating everything toward new technologies? Right now more and more (scripting) languages are around: Python, Lua, Julia, etc... but all theses are generic languages that do not know straight HEP data. To do analysis in a more intuitive (and reliable) way, the author have the strong feeling that a piece is still lacking in our computing environment, some kind of language strongly HEP-data oriented having keywords as "run", "event", "cut", "histo", "ntuple", "fit", "plot" beside generic keywords as "for", "if", "class". Somewhere we have the impression that the KUIP, along with the PAW commands are more close to users than a Python or a C++ prompt.

The passage of CERN-PAW to CERN_ROOT around 1990 posed also the interesting question of the relationship users/engineers (users/doers) around a software. A lot of users were happy by the CERN-PAW commands that they found "data driven" and highly compact to do typical interactive analyses. But clearly, "inside", it was hard to continue with FORTRAN that were clearly inadapted to handle more technical aspect as the I/O or the graphical systems. The passage to C++ "inside" (through CERN-ROOT) by doers had been done by compelling users to pass to C++ typing from an interactive prompt. Is "straight C++" (and also python) the right way to be "close to the data" in an interactive analysis system ? Are we lacking a "data oriented" language to do analysis? With gopaw, we want to show that a "middle way" was possible, a way that respected users in their analysis habits but also doers, by arranging to evolve, to refactor graduelly a software/program by keeping the user API (KUIP here) but by graduelly evolving the inside to deal with various new technologies around I/O and graphics. gopaw is written in C++ by avoiding the automanagement of everything found in CERN-ROOT (the "g" logic that kills object orientation but also the thread safety). It incorporates the KUIP library found in CERNLIB, that had already been migrated in C at that time, and then the "traditional" CERN-PAW commands (the KUIP.cdf and PAW.cdf describing commands are the same than CERN-PAW). For I/O it had not been possible to restore ZEBRA file reading, but we support the ROOT file format for histograms and ntuples, now also the HDF5 file format for histograms and ntuples produced by g4tools/HDF5 within Geant4 10.4, and also the FITS format heavily used in astronomy. The graphics of gopaw is based on our powerfull inlib scene graph logic with a GL-ES renderer able to run straigh on Linux, Mac, Windows but also on iOS and Android devices. gopaw has also offscreen rendering to produce plots in a vector PostScript or pixmap in PNG or JPEG. gopaw can even be built by offering a Python prompt beside the KUIP one, and by using Python as a replacement of the COMIS FORTRAN interpreter to define functions. In May 2018, we had been able to incorporate the core of gopaw (including ourex/KUIP, ourex/Python) within the ioda application and had alls the "examples/py_root" running on an iPad.