# Update on PRIMA: A Julia interface is available **URL:** \ **Category:** Uncategorized\ **Created:** [October 18, 2023, 5:44pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658 "2023-10-18T17:44:05Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [October 18, 2023, 5:44pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/1 "2023-10-18T17:44:05Z")
I have made a few posts here about [PRIMA](http://libprima.net), which is a package for solving general nonlinear optimization problems without using derivatives, providing the **modern-Fortran** reference implementation for Powell’s derivative-free optimization methods, i.e., COBYLA, UOBYQA, NEWUOA, BOBYQA, and LINCOA. I am glad to mention that PRIMA now has a [Julia interface](https://github.com/libprima/prima.jl). In addition, a [Python interface for the Fortran implementation of PRIMA](https://github.com/libprima/prima/pull/52) and a [native Python implementation](https://github.com/libprima/prima/pull/37) are under development, both making remarkable progress. In my opinion, one of the approaches to (re)popularizing Fortran is to produce quality modern-Fortran packages and make them available to users beyond the Fortran community. PRIMA represents such an effort. ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [October 19, 2023, 4:07am UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/2 "2023-10-19T04:07:04Z")
Congrats on the progress, @zaikunzhang. > a [native Python implementation of PRIMA](https://github.com/libprima/prima/pull/37) are under development, both making remarkable progress. My past efforts in having multiple project implementations natively in different programming languages have failed. The underlying reason for such failures was simple: As soon as there are two copies of a project in two different languages, they are guaranteed to diverge in functionality, interface, and implementation. Change is inevitable, and when it happens, it is practically impossible to keep multiple implementations in sync. I am convinced by experience that code duplication is pure evil, even within a single language. Despite all the negative comments here and there, in my experience, FPPs and wrappers are the only viable options to keep projects maintainable. I’d be eager to learn about your experience in this regard and others’ insights. ---
**Author:** ![ricriv](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@ricriv](https://fortran-lang.discourse.group/u/ricriv)\ **Post date:** [October 19, 2023, 12:06pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/3 "2023-10-19T12:06:22Z")
I agree with @shahmoradi, and can add that the last thing to want is to fix the same bug in multiple implementations. Indeed, having 1 reference implementation with multiple interfaces is the way to go. ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [October 19, 2023, 2:11pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/4 "2023-10-19T14:11:36Z")
> [@ricriv](#): > > having 1 reference implementation with multiple interfaces is the way to go. I hope this were the case, and I understand the difficulty in maintaining several implementations. However, unfortunately, people have repeatedly told me that they do not want to depend on libraries written in another language, (sometimes) in particular Fortran. A recent example is [Including Powell's derivative-free optimization methods? · Issue #225 · robertfeldt/BlackBoxOptim.jl · GitHub](https://github.com/robertfeldt/BlackBoxOptim.jl/issues/225#issuecomment-1770376913). It seems inevitable to me to have multiple implementations in different languages if I want to make the PRIMA solvers easily available to users in their favorite languages, which is the [goal of the PRIMA project](https://github.com/libprima/prima#other-languages). ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [October 19, 2023, 2:56pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/5 "2023-10-19T14:56:41Z")
> [@zaikunzhang](#): > > In my opinion, one of the approaches to **(re)popularizing Fortran** is to produce quality modern-Fortran packages and make them available to users beyond the Fortran community. PRIMA represents such an effort. Unfortunately, this approach doesn’t look that succesful if at the end > [@zaikunzhang](#): > > people have repeatedly told me that they do not want to depend on libraries written in another language, (sometimes) in particular Fortran ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [October 19, 2023, 3:04pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/6 "2023-10-19T15:04:21Z")
Right. But Rome was not built in one day, I guess. It is hard for me to see how the opposite of this approach (i.e., “do not produce quality modern-Fortran packages” OR “restrict the availability of good Fortran packages to the Fortran community only”) could help to repopularize Fortran. I am eager to learn if anyone could teach. In addition, no matter how popular Fortran were, there would always be users who do not want to use it, not to mention that Fortran is not so popular (yet / anymore). If you code for yourself only, you may simply ignore those people. But I develop software for others to use, which I hope is not a strange situation. What really matters to me is that my package is easily available to its end users **in their favorite languages**. **I do not have a preference for languages**. Fortran was chosen due to historical reasons — it was not a choice made by me. Thanks. ---
**Author:** ![oscardssmith](https://avatars.discourse-cdn.com/v4/letter/o/b9e5f3/32.png) [@oscardssmith](https://fortran-lang.discourse.group/u/oscardssmith)\ **Post date:** [October 19, 2023, 3:29pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/7 "2023-10-19T15:29:49Z")
To be clear, this isn’t a purely ideological stance. Libraries written in Fortran are inherently limiting for higher level languages because they don’t work on types that Fortran doesn’t know how to deal with. Have a function that returns an array of [posits](https://posithub.org/docs/posit_standard-2.pdf)? everything breaks. If the library was re-implemented in Julia? Everything now works. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [October 19, 2023, 4:49pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/9 "2023-10-19T16:49:00Z")
> [@zaikunzhang](#): > > What really matters to me is that my package is easily available to its end users **in their favorite languages**. **I do not have a preference for languages**. Fortran was chosen due to historical reasons — it was not a choice made by me. This is a completely legitimate approach, and my comment was definitely not meant to be a negative critique of your choice to port your library to other languages (your work, your choice, anyway). I’m just saying that, as a matter of fact, it defeats the initial statement about repopularization of Fortran. ---
**Author:** ![ricriv](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@ricriv](https://fortran-lang.discourse.group/u/ricriv)\ **Post date:** [October 20, 2023, 6:40am UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/10 "2023-10-20T06:40:05Z")
That’s understandable. On the positive side, PRIMA focuses on one class of algorithms, and therefore I wouldn’t expect too much development once it’s completed, except for the occasional bug fix or nice to have feature. The other nice aspect is that it might serve as a Rosetta stone of how good codes should be written, and showcase the strengths and limitations of each language 🙂 ---
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [October 20, 2023, 11:12am UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/11 "2023-10-20T11:12:49Z")
Thank you @ricriv for your encouraging words. > [@ricriv](#): > > The other nice aspect is that it might serve as a Rosetta stone of how good codes should be written, and showcase the strengths and limitations of each language 🙂 This is a nice perspective that I have never thought about before. I will keep it in mind and make efforts in this direction. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [October 20, 2023, 3:07pm UTC](https://fortran-lang.discourse.group/t/update-on-prima-a-julia-interface-is-available/6658/12 "2023-10-20T15:07:17Z")
> [@zaikunzhang](#): > > … It seems inevitable to me to have multiple implementations in different languages if I want to make the PRIMA solvers easily available to users in their favorite languages, which is the [goal of the PRIMA project](https://github.com/libprima/prima#other-languages). Sure, netizens of the computing world will do whatever and that will include **duplication** (and reinventing the wheel, etc.). In the case of the topic here, such duplication will extend to “native” implementations in Python, Julia, etc. of codes written in other languages, especially `FORTRAN` and `Fortran`! It is absolutely silly, particularly when it comes to Python, but that’s just how it is. But modern Fortran packages with well-designed APIs and performant code and with readiliy available and easy-to-use **bindings** with a few other languages and platforms including C, C++, Python, MATLAB, .NET (C#, Visual Basic), and increasingly Julia can minimize (but not prevent) code duplication. Basically these are the languages and platforms that rank high at Tiobe Index, IEES Spectrum survey on programming, etc. - **“usual supects”** @zaikunzhang (and team?) have made strong attempts to establish this with their `PRIMA` effort - mega kudos to them in this regard. But those in the Python, Julia, C++, etc. spaces will pursue duplication, and the more powerful and successful the algorithms are (such as with Powell in `PRIMA`), the stronger will be the driving forces to pursue duplication!