Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
# 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.