A computational scientist's wish list for tomorrow's computing systems

A computational scientist’s wish list
for tomorrow’s computing systems
Konrad Hinsen
Centre de Biophysique Moléculaire, Orléans, France
and
Synchrotron SOLEIL, Saint Aubin, France
February 1st 2020
Konrad Hinsen (CBM/SOLEIL) A computational scientist’s wish list for tomorrow’s computing systems February 1st
2020 1 / 38

Where I am coming from
1990 condensed matter physics, simple models, simple Fortran code
1995 biophysics, complex models, messy and buggy Fortran code
action: co-found Numerical Python
action: molecular simulation library in Python
2000 Scientific Python becomes popular
2010 Python 3 breaks all my Python code
insight: dependencies are a real problem for science
action: join the Reproducible Research movement
2015 scientific papers refer to software rather than models
action: start working on digital scientific notations
2020 2 / 38

Reflective tower of computational science
Notations and tools
for computational models
and methods
Models and methods
for molecular simulation
Proteins via
molecular simulation
1995
2015
2020 3 / 38

Topics
1 Focussing on the subject domain
2 Bottom-up growth, not top-down design
3 Knowledge consolidation
2020 4 / 38

Focussing on the subject domain
2020 5 / 38

Good ideas from the past
Reports and Articles
BeyondProgrammingLanguages
TerryWinograd
StanfordUniversity
As computer technology matures, our growing
ability to create large systems is leading to basic
changes in the nature of programming. Current
programming language concepts will not be adequate
for building and maintaining systems of the complexity
called for by the tasks we attempt. Just as high level
languages enabled the programmer to escape from the
intricacies of a machine's order code, higher level
programming systems can provide the means to
understand and manipulate complex systems and
components. In order to develop such systems, we need
to shift our attention away from the detailed
specification of algorithms, towards the description of
the properties of the packages and objects with which
we build. This paper analyzes some of the shortcomings
of programming languages as they now exist, and lays
out some possible directions for future research.
Key Words and Phrases: programming,
programming languages, programming systems, systems
development
CR Categories: 4.0, 4.20, 4.22, 4.40
Introduction
Computer programming today is in a state of crisis
(or, more optimistically, a state of creative ferment).
There is a growing recognition that the available pro-
gramming languages are not adequate for building com-
puter systems. Of course, as any first year student of
computation theory knows, they are logically sufficient.
But they do not deal adequately with the problems we
face in the day-to-daywork of programming. We become
swamped by the complexity of large systems, lost in code
written by others, and mystified by the behavior of our
almost debugged systems. When we look to the inte-
grated multiprocessor systems that will soon dominate
computing, the situation is even worse.
This crisis in software production is far greater (in
overall magnitude at least) than the situation of the early
50's that led to the development of high level languages
to relieve the burden of coding. The problems are harder
to solve, and the costs of not solving them are in the
hundreds of millions. "The symptoms appear in the form
of software that is nonresponsive to user needs, unrelia-
T. Winograd, Comm. ACM 22, pp 391-401, 1979
Three Domains of Description
Subject domain
Domain of interaction
Domain of implementation
2020 6 / 38

Subject vs. implementation domain
Dimensional analysis
Some but not all data
Applied at specific interface points
Dimension, unit, kind of quantity,
rank
Type checking
Every value has a type
Every function: input → output
No more than one type per value
2020 7 / 38

Subject vs. implementation domain
Dimensional analysis
Some but not all data
Applied at specific interface points
Dimension, unit, kind of quantity,
rank
Type checking
Every value has a type
Every function: input → output
No more than one type per value
Example:
Given: m: mass, v1, v2: velocity
Then: mv2
1 : energy, mv2
2 : energy
Allowed but undefined: v2
1 , mv1 · v2
2020 7 / 38

The two pillars of science
Theory
Science
Experim
ent
2020 8 / 38

Science
Models
Observa
tions
2020 9 / 38

Science
Models
Observa
tions
2020 10 / 38
Learning process
Input Inner state

Observations and models
Source: https://all-free-download.com/free-vector/download/laboratory-work-background-scientist-microscope-bacteria-icons_6837383.html
2020 11 / 38

Model
2020 12 / 38

Model
Model
2020 13 / 38

Wish list item #1
Observations and models as first-class objects
Today’s reality:
OK but perfectible for observations (data, metadata)
Models are absorbed by software tools
Models can be applied but not examined nor modified
Models cannot be composed nor transformed
K. Hinsen, F1000Research 3:101 (2014)
2020 14 / 38

The structure and implementation of scientific models
Models are stories with embedded formal elements
(equations, graphs, algorithms, ...)
Cross-references: hypertext
Metastories about models
2020 15 / 38

Empirical models
Mathematical model Example
function with Ptolemy: circles
fitted parameters with epicycles
2020 16 / 38

Empirical models
Mathematical model Example Computational model
function with Ptolemy: circles machine learning
2020 16 / 38

Empirical models
Explanatory models
Mathematical model Example
equation Newton: F = m · a, Fij = −Gmi mj r̂ij /r2
ij
general solution Kepler: elliptical orbits, sun at
(parametric) focal point, constant area speed
specific solution Earth’s orbit around the Sun
2020 16 / 38

Empirical models
Explanatory models
equation Newton: F = m · a, Fij = −Gmi mj r̂ij /r2
ij specification
general solution Kepler: elliptical orbits, sun at algorithm
(parametric) focal point, constant area speed (with input parameters)
specific solution Earth’s orbit around the Sun computation
2020 16 / 38

Explanatory models
composable constraints
intensional
abstract
small, understandable
Simulation programs
monolithic code
extensional
concrete
accidental complexity
2020 17 / 38

Wish list item #2
Focus on specifications
Today’s reality:
Specification languages are marginal
Overly focused on preparing implementation
No live coding systems for specifications, not even IDEs
No integration of specifications with code, graphics, ...
2020 18 / 38

Leibniz, a Digital Scientific Notation
2020 19 / 38

Leibniz, a Digital Scientific Notation
2020 20 / 38

Bottom-up growth, not top-down design
2020 21 / 38

Science works bottom-up
World view
Theories
Models
Observations
Uniﬁcation
speciﬁc
general
2020 22 / 38

Programming works top-down
Languages
Frameworks
Libraries
Applications
Control
speciﬁc
general
2020 23 / 38

Scientific computing
World view
Theories
Models
Observations
Uniﬁcation
2020 24 / 38
no digital
representation
many languages
many file formats

Wish list item #3
Support for a bottom-up, integrative style of work
Today’s reality:
Programming languages define universes with strong boundaries
Platforms (OS, Web, ...) impose strong boundaries as well
Weak interoperability
Lack of bridges, connectors, mediators
Competition rather than collaboration
2020 25 / 38

Knowledge consolidation
2020 26 / 38

2020 27 / 38

Coverage
2020 28 / 38

Precision
2020 29 / 38

Depth
2020 30 / 38

Confidence
2020 31 / 38

Technological consolidation
Tinkering Craft Engineering Industry
2020 32 / 38

Technology stacks
Tinkering Craft ...
Tinkering Craft
Engineering
Tinkering Craft
Engineering
Tinkering Craft
2020 33 / 38

Programming languages
Tinkering Craft Engineering
Infrastructure
Problem
domain
Hardware
control C
Rust
Python
Haskell
Smalltalk
Mathematica
Excel
Shells
2020 34 / 38

Programming languages for science
Tinkering Craft Engineering
Infrastructure
Problem
domain
Hardware
control C
Rust
Python
Haskell
Smalltalk
Mathematica
Excel
Shells
2020 35 / 38

Wish list item #4
Support for the knowledge consolidation process
Today’s reality:
Distinct language universes, weak interoperability
No refactoring or translation tools
Weak support for tinkering (REPLs, notebooks)
Weak support for working in the problem domain
2020 36 / 38

Programming systems for science
2020 37 / 38

Summary
Wish list
1 Observations and models as first-class objects
2 Focus on specifications
3 Support for a bottom-up, integrative style of work
4 Support for the knowledge consolidation process
Missing functionality
1 Interoperability
2 Bridges, connectors, etc.
3 Data first, tools adapt to data
4 Specifications and algorithms as data
5 Graphical tinkering environments
2020 38 / 38

A computational scientist's wish list for tomorrow's computing systems

More Related Content

Similar to A computational scientist's wish list for tomorrow's computing systems (20)

More from khinsen (7)

Recently uploaded (20)

A computational scientist's wish list for tomorrow's computing systems