@meow464 let’s do that. What exactly is required to get a reproducible binary?
@certik There are no hard rules, just anything not deterministic or system dependent.
File paths and timestamps are two obvious things. If the compilation process is prallalelized all outputs would have to be written in the same order, for example all object files should be added in the same order to the .a. I know there are some linker aspects one should be aware of but not sure what.
Having Fpm definitely helps, makes it easy to download dependencies at specific commits.
Debian and golang are two good places to look. IIRC golang has reproducible binaries by default.
But that’s an idea for the future. Maybe next year I will give it a try.
1 Like
LFortran default mode is to compile everything into ASR first, and only compile via LLVM or other backends once the main program is asked to be compiled. So it seems using fpm to get all the dependencies, then get one ASR out of everything, and then one compilation should do the trick. The ASR to binary compilation will depend on LLVM version, but we could also use some of our other backends like WebAssembly → x86, and control the output more, but it would then depend on LFortran’s version.
1 Like
Honestly fpm is the place where you would enable this. You need to ensure you compile with
- Exactly the same versions of all dependencies
- In exactly the same order,
- With exactly the same version of the compiler
I believe Haskell’s stack build system boasts being able to do this.
3 Likes
Just a global notice about reproducible build (which might not apply properly to context of usual Fortran usage): having reproductible binary isn’t necessary a good thing for all cases, specially in security context: having diversity in binary make functions position in the binary random, and so adds some complexity for attacker.
With reproductible binary, one leak of exact function offset in memory, permits to know exact position of all functions (as relative position of functions is known due to reproductible build).
1 Like
I’m not familiar with reproducible build systems, but my colleague always stresses the importance of reproducibility. He works with NixOS which has reproducibility as its main feature. Perhaps you would like to check this out.
2 Likes
Yes, I am familiar with NixOS. It uses hashes to identify dependencies uniquely. Julia Pkg, Spack, etc. all do that. Fpm doesn’t do it yet, but it is designed in such a way so that it could. It behaves that way.
I glanced through the paper, hoping to find a section that addresses the perceived limitations and weaknesses of the Julia language (e.g., Why I no longer recommend Julia) – particularly the reliability issues of the language, or proposes a plan to address them. Alas, no discussion. Maybe I missed it.
2 Likes
1 Like
I have not yet read the paper in details but you seem right. Some would say they are “overly enthusiastic”:
https://twitter.com/juanluisback/status/1590716977365934081
Probably enthusiasm is both a flaw of youth and a strength. I think Backus’ team was in the same spirit during the initial FORTRAN project. But it reminds me the title of a discussion between K. Lorenz and K. Popper, “The Future is Open” (Die Zukunft ist offen):
2 Likes
A quote for every programming community:
3 Likes
"There are yet many Universities teaching Fortran! But I have study modern Fortran in details recently and I’m honestly not impressed! "
1 Like
Why was he not impressed ? What would impress him ? What has impressed him in the past and why ?
If you or someone with a similar curiosity who also uses Twitter (I don’t, otherwise I would ask) may want to inquire directly with that poster on that platform, the bio of that poster suggests someone is generally interested in learning programming languages and more importantly, teaching the languages to a diverse audience who might otherwise find programming difficult or even be scared of it.
1 Like
I would love to, sadly you and I are both in the same boat. 
Ok, I just opened up a Twitter account and posted a direct inquiry with that poster. I noticed @everythingfunctional had done the same.
6 Likes
Yep, I haven’t heard anything back though.
5 Likes
He’s been posting very brief snippets for a while (looking at his tweet history) and commenting with generic frustration. But never really going deeper on why and how.
Example: https://twitter.com/elucian_moise/status/1589764978760101889?t=1pk8qvT3HotvMomi6UWQjA&s=19
Mmm here he’s complaining that Fortran does not have “switch” but then in the example he’s using select case.
Elsewhere he was complaining about parameter to mean “constant”. Is he arguing about naming conventions?
Anyway I’m tired of scrolling so I’ll stop here. 
I looked into this one. It appears to be a misconception about the possible meanings of the word parameter. I guess the person is more familiar with languages such as C, D, Nim, & Julia, which use the const keyword. We could equally argue, that the final keyword in Java, or the readonly in C#, don’t make sense to a Fortran programmer.
A few dictionaries I checked list constant as a synonym for parameter. But parameter can also mean a characteristic of something, i.e. “the parameters of the atmosphere, density, temperature”, which would normally be interpreted as dependent variables. In some sentences it is also used for limits/boundaries of something. I guess the Fortran usage originates from independent variable, i.e. a value which determines a particular function from a family of functions. E.g. we could have a quadratic f(x) = x^2 + px + q, where p and q are the parameters. Using a Fortran 77 statement function (and implicit typing 
) this may have been written as:
PARAMETER(P=-4.,Q=2.)
F(X) = X**2 + P*X + Q
READ *, X
Y = F(X)
Or the volume of a sphere could have been calculated as:
PARAMETER ( PI=3.14159 )
REAL RADIUS, VOLUME
SPHERE ( R ) = 4.0 * PI * (R**3) / 3.0
READ *, RADIUS
VOLUME = SPHERE( RADIUS )
I watched recently a talk by Joe Armstrong, a co-designer of the Erlang programming language. In the talk he highlights that in 1985, most programmers knew sh, make, and C, and hence had a common language. Some might have also known Assembly, COBOL, or FORTRAN. Nowadays with over 2000 programming languages, programmers don’t have a common language, and can’t talk with each other. Not to mention the differences in build tools…
5 Likes