Designated Target Audience of Julia 1.0?

It is relevant to the developer.
For which I think the best would be the path which requires the least resources (Development time mainly).
So if it can be done using VS Code / Juno / Spyder or Jupyter Lab any of the is as welcome as any other solution.

Still waiting for a credible equivalent to MPI and OpenMP… sigh…

Data transfer and package visibility is pretty opaque with pmap, which is the closest to what I mean.

Have you looked at PARTR? (Parallel Task Run-time).
It’s a work in process, but looked very interesting to me.
There’s a video on Youtube about it, made during the talk a month ago at the C.A.J.U.N. (Cambridge Area Julia Users Network) Meetup.

1 Like

You’re talking on the forums to the developers. Hence…

1 Like

I don’t use Matlab, but recently I needed to run a script from someone so I spent 2 hours with our IT trying to install it on my Linux laptop, wading through cryptic messages from the license server. Finally I gave up and went with Octave :smiley:

I sincerely hope that grad students who otherwise use computers should be able to figure out the setup for a Julia environment, even without JuliaPro.

4 Likes

lots of WiP with great promise. many, many possibilities 2-5 years out…risk is unless packages become abandoned along the way, as the original authors are done with what they themselves needed and now have to move on to day jobs elsewhere.

julia 1.0 could use more adopters in 2018-9. a growing user base to get to 1% in https://www.kdnuggets.com/2018/05/poll-tools-analytics-data-science-machine-learning-results.html — yes, their survey is misrepresenting julia’s situation. it’s early. it ain’t over until the fat lady sings. she hasn’t even started singing yet.

my takeaway from this thread is that julia 1.0 is world-class ready for numerical analysis, mathematical programming (optimization, etc.) of many forms in fall. matlab users are probably one primary target. I hope it is a big market. I hope this segment has many prominent evangelists. stepheng and others…

/iaw

PS: I am just a little sad that it won’t be for mixed data set IO programming in this iteration. I hope for 2.0.

1 Like

I’m hoping for a lot sooner than that - and I think there are enough of us who really need this, who also have the skill set to do some interesting things in this area, that this is very possible.
This is where the advantages of Julia in programmer productivity, will come into play, IMO.

this is a multiple equilibrium situation. it may well be that companies won’t touch it, because they don’t touch it…maybe because they worry about julia being around, getting market share, hiring people that can code in it, many other reasons. for computer languages, there are important “externalities” in having others adopt it, too.

this is why I believe it is more important for julia to become a superior solution for some segment, rather than to be “nearly competent” or even just a little better than existing solutions in many places. (I originally thought the target was data analytics, but now I think it is numerical analysis / mathematical programming.)

julia needs a few initial niches, where it can establish a major foothold. it can branch out from there. it’s a “1.0 target” question.

Isn’t it mostly a legacy code issue? I see that there are some new physics software/packages written in C++ and Python nowadays.

My experience is that the development cost of writing Fortran code far outweighs the little gain in performance. I don’t enjoy hand coding a matrix inversion subroutine in Fortran when I know that NumPy and Julia can do it already and probably do better than me. And I doubt if there are many grad students or postdocs who can actually be enthusiastic about coding in Fortran if not insisted by their PI that code be written in Fortran. My point is that, if given a free choice, not bound by PI’s will or grant proposal or a legacy project codebase, it is likely that there’ll be more people prefer Julia to Fortran in their daily work.

8 Likes

No it’s not. Most physics PhD programs seem to still teach and use Fortran. Most ODE solvers in use are still Fortran programs. Modern Fortran really isn’t that bad of a language anyways. But this is a big pool of people who would like to modernize but cannot:

  1. Sacrifice the array-based semantic loss of a Fortran → C++ conversion
  2. Sacrifice the speed of a Fortran → Python conversion
  3. Sacrifice the loss of a common language of a Fortran → C++ + Python conversion

Sure, I agree with this one. There are a lot of legacy people :smile:. You can see this is the biggest pool of people in the SoCal Julia meetups: lots of ex-Fortran physics grad students.

4 Likes

Its a similar situation in biophysical sciences, except the choice of Fortran seems to be arbitrary as there isn’t as much heavy array work. People tend to experiment with C++ for structure and R for its ecosytem, but usually with terrible results. Obfuscated terrible OOP or painfully slow sludge.

And yeah modern Fortran seems so much better, but I rarely see it used, and I just reviewed 30 Fortran codebases!

The whole field desperately needs generics but doesn’t even know the term.

2 Likes

Too true.

One of my upcoming conference slides is going to be

GENERIC PROGRAMMING

with nothing else on the page

Second you on this. Fortran 2003 or 2008 is not bad at all. For example, I actually liked elemental functions, which automatically broadcast scalar functions onto arrays (like a Julia dot-syntax without a dot). But problem is that most people still program in a Fortran 90/95 way (if not 77). Many still write one subroutine that does 10 different jobs and wonder why their code is so hard to debug. And despite the ISO types (iso_fortran_env) that ensure portability, people continue to hard-code kind parameters to select double precision types. It seems that a lot of good modern Fortran features are underutilized.

LOL. I haven’t been there yet. Definitely gonna check that.

3 Likes

Why is that? I’m somewhat ignorant of modern Fortran (or old e.g. FORTRAN 77).

[I just posted another question on Julia’s “memory model”, I got no answer, still assume aliasing is the same as in Fortran.]

Do you have any idea of features in the language that keeps them using Fortran, as opposed to just inertia (or because of libraries, as Julia can reuse them all)?

Besides the OO features Fortran now has (I doubt it’s that, nor that it attracts many to Fortran), there’s now a tail-call optimization (TCO) guarantee.

I also doubt it that, as I think of Fortran as more of a imperative, rather than a functional (as in Scheme) language. Julia doesn’t have TCO (only in FemptoLisp), I think not even in the restricted sense as in Scala, where it’s only for self-recursion. Scheme has TCO even for mutual recursion. Seems the former is easier, and Julia could well adopt, at least if this is an important advantage of Fortran.

http://fortranwiki.org/fortran/show/Fortran+2018

"Most new features in Fortran 2018 are defined in two Technical Specification (TS) documents:

  • TS 29113: Further Interoperability of Fortran with C
  • TS 18508: Additional Parallel Features in Fortran"

This was a little surprising to me, as I thought it had good C interop (just to C++ always a problem), and for Julia at least I can’t really see how better it could be (except for the row vs major, I do not view to be an issue, as 1D arrays/strings are ok), possibly they are tacking the same 2D+ issue Julia has?

Keyword “in use”; as your package is state-of-the-art (and includes all of those [Fortran] solvers and more), it should attract people to Julia?! Or do (most) people not need all the new solvers? I also read all the options could be paralyzing…

From what I can tell as someone who reads a lot of Fortran but writes basically none: Fortran is conceptually simple, and nearly always fast. Its just hard to write really bad Fortran. Its like GO from the 70s for scientists, simple, easy to understand, few confusing abstractions. Scales well. It ends up with a lot of code duplication where Julia would push some complex abstraction, but I can see the attraction of that.

People don’t seem to be using many post 95 features, not that I know them all, but mostly things are kept super simple.

8 Likes

In my experience it is very easy to write really bad Fortran. In my career I have seen pages and pages of bad Fortran. But, even really bad Fortran program can be fast.

4 Likes

Just start with a COMMON block. The rest of the bad Fortran didn’t take to much effort… :tired_face:

For economics it would be a great tool. For data science and machine learning, it needs some work, but it can get there soon. I would suspect, for teaching programming with focus on scientific computing it would be ideal.

4 Likes

I love that C[++] offers strong typing. I loved that the old Fortran (which was all I ever read) seemed to have cacheable (I->O) / parallelizable functions (i.e., no globals with sideeffects).

I love that julia has generic programming with weak typing, allows some strong typing, has data sets, and parallelization (though not complete yet). I don’t like that julia does not allow me to require strong typing and that I cannot tell the compiler that a function should not have accidental globals / side effects. I like compilers to tell me when I make errors, beside the fact that the compiler can often use this to speed up the executables.

2 Likes