Skip to content
Snippets Groups Projects
notes.md 7.76 KiB
Newer Older
# Notes on how to improve the article

I copy/paste Ashwin's remarks on a version of the paper. If I do not respond,
it means that I basically agree and that we can modify the paper accordingly.

For some comments, I just took them into account and I don't include them
here. Similarly, we can empty this file when the corresponding modifications
have been done in the paper.

## General remarks

- av: The tentatively added title for the article does not suit the content
  anymore. We need to come up with a good title which reflects the theme.

- av: We need to collect more of citeable sources, esp. in the introduction

  * to promote further reading for eg. (NumPy, Cython, Pythran, etc. have
    citeable articles)

  * to substantiate the claims

- av: reorder the sections

  pa: Right now, I don't love the new organization that you proposed.  The
  logic of the organization may be more clearly expressed in the last version
  (?).  For now, I would prefer to keep it as it is.  It does not mean that I
  am against a reorganization but we can do that later.

  pa: I like your "Breaking the status-quo: Motivation to create FluidDyn"

  av: Thanks :). We can revisit the organization at the final stage. Maybe it
  the flow of thought will be continuous when it is all polished.

## Some remarks

### Abstract

- av: Some hint should be added in the abstract that this article
  includes a treatise on open-science and Python’s scientific ecosystem as a
  candidate for it. Also, that “we summarize the events and technologies that
  inspired and enabled the design of FluidDyn project”

### Science, software, open-...

- av: Not just companies which support open-source paradigm, but individuals,
  small groups, foundations and non-profit organizations. Most open-source
  projects are fuelled typically by the perseverance of one person in the
  initial stages e.g.: Linus Torvalds, Guido van Rossum etc.

  pa: I totally agree that these ideas are clearly missing. Note however that
  it is important that all these people are paid for their work and that there
  is money to pay for infrastucture needed for open-source. I don't like the
  myth "open-source = no cost, amateurs, working for free".

  av: If that is the case, it could be explicitly mention as

  *The open-source movement now involves not just individuals, but also
  foundations, non-profit organizations and corporations with proper funding
  channels. All of them work with a collective interest of advancing the
  open-source languages, libraries, software and operating systems.*

- av: Maybe we can cite something related Moore’s “law” about computer
  performance.

### Methods and tools for Open-source

- av: Mercurial commands are very similar to Git
  https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone

  pa: and most of the time simpler... A real advantage of Mercurial is the
  principle that one has to add extensions to modify the history.  At LEGI, a
  PhD student managed using Git to basically destroy a Git repository. It would
  have been much more difficult with Mercurial.

  av: Shocking! Some good things come from Mercurial's mysterious API.

- av: By choosing mercurial, we hope to lower the barrier for a newcomer to
  actively participate in our project.

- av: Since the code depends on a wide variety of external dependencies, CI is
  useful to avoid software-decay
  https://en.wikipedia.org/wiki/Software_rot. That is when the code becomes
  nearly stable in terms of feature, it does not go obsolete with new versions
  of its dependencies.

- av: include readthedocs.io, IRC / Matrix channels such as #python

### Python, a programming ...

- av: **Short bold font punchlines** followed by description. Since there are a
  lot of bullet points

### No type-checking

- av: But type-hinting syntax was introduced in Python 3.5
  https://docs.python.org/3/library/typing.html.

  pa: Yes we have to recall it here. It is already meantionned in the last
  version.

  av: And if not for debugging, useful for a user to know what type of
  arguments are to be supplied to a function.

  av: Of course, we don’t do this.

  pa: I think we will soon start to do it :-) Another reason to say bye bye to
  Python 2 (even if I know that we can put type-hinting in comments in Python
  2).

  av: Maybe we could also have a small subsection devoted to the **Outlook /
  Future Scope**. Some inputs could be helpful.

### A lively, huge and thus complicated...

- av: Mention packaging difficulties that can arise from dependencies (both
  Python and non-Python dependencies): the motivation behind developing conda
  and Anaconda.
  https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/.

### Another weakness ...

- av: Clarify concurrency and parallelism, for eg. this definition
  https://docs.oracle.com/cd/E19455-01/806-5257/6je9h032e/index.html.

  pa: I will work on this one.

### Rich landscape...

- av: There are also some groups which swear by functional programming
  languages such as Haskell, even for science.

  pa: I now mention Haskell in the list of language that are used for
  scientific applications. I don't think it is useful to write more on this.

  av: I agree.

- av: Clarify Julia’s limitations which are not negligible

  pa: Our goal is not to criticize Julia or to advertise it. To be honest, I
  consider that the Julia creators made a bad bet when they designed the
  language.  They choose to make it matlabish because Matlab was at the time
  the main target and because they didn't think that Python could be able to
  overcome Matlab. But right now, Python is winning the battle against Matlab
  in science and Julia is taking off too slowly.  Python will be widely used in
  science and Julia is not nice for pythonist because it is matlabish. I think
  this will be a problem for this language in an environment where Python is so
  strong.

  Then, the tools which make Python as fast or faster than Julia start to be
  mature so the motivation to switch to Julia will not be so large (mainly
  multiple dispatch?).

  I have added one example but I prefer to write it in a positive way ("From
  our point of view, a Pythonic flavor of Julia would be very interesting.")
  and that aware readers read between our lines rather than going too much into
  these details that are not so important for this article.

### Productivity at individual levels:

- av: Quote? "If you want to go fast, go alone. But if you want to go far, go
  together." - African proverb(?)

  pa: Yes!

### Discussion on Matlab..:

- av: Non-commercial academic license to make Matlab seem “free”, but resulting
  in unusable skills in a commercial setting

- av: Black boxes provides little insight and thus restrict our ability to
  debug when codes do not work. In contrast, community-level support is more
  reactive and has quicker turn around time in resolving bugs (via Github
  Issues etc.)

- av: Matlab is also good for complex processing in certain niche-fields, BUT
  typically when the data size is small or moderate.

  pa: complex processing ok but I think we show that Matlab is not good for
  long program.

- av: “Matlab team claims that teaching is mostly done in Matlab...” That claim
  could be true in terms of academic courses, but due to the viscious cycle
  that Matlab set in motion.

  pa: Matlab becomes much less dominant also in this field. It may not be so
  important to say much more than we already say on this?

- av: More citations needed!

  pa: On what exactly?

  av: I will start by adding a "citation needed" flag where I think some proof
  is needed.

## Different models for software development in fluid mechanics

- av: Open source models offers peace of mind in terms of: backup, less
  politics and ensures credit where it is due

## Implementation and architecture

- av: Module fluiddyn.util.mpi, needs some rephrasing.