I agree in general that Fortran needs to adapt quicker, but I’m just saying that not having a list with mixed items is not really a fundamental limitation. Here’s a reply from a StackExchange thread answering the question Am I safe mixing types in a Python list? (emphasis mine):
The language is fine with you mixing types in a list, but you should know that the Python culture might frown on it. Tuples are usually used when you have a known collection of mixed types, and different indexes have different semantics. Lists are usually used where you have a uniform sequence of varying length.
So your data would more conventionally be represented as:
data = [ ("name1", "long name1", 1, 2, 3), ("name2", "long name2", 5, 6, 7), ... ]To put it more succinctly: tuples are used like C structs, lists like C arrays.
To extend the answer above by analogy: tuples are used like Fortran derived types, lists like Fortran arrays. Now just because something can be done in a dynamic language like Python, doesn’t necessarily make it a good idea.
The Fortran code for the example above would be:
type :: record
character(len=:), allocatable :: name, long_name
integer :: a, b, c
end type
type(record), allocatable :: data(:)
data = [ &
record("name1", "long name1", 1, 2, 3), &
record("name2", "long name2", 5, 6, 7), &
... &
]
which is just as expressive for my taste. The decrease in productivity due to static typing is counter-balanced by the potential performance increase and safety. Which of these we value more depends heavily on the circumstances. How many records do we need to deal with? How many times will the application be reused? How much time do we have available? And sadly also, which language do my boss (and colleagues) prefer?
I also think it would be equally true to invert the sentence,
The popular languages for engineers and technology … have or are all rapidly providing solutions for their practitioners regardless of their paradigm (imperative, etc.).
leading to
The practitioners of engineering and technology have or are are all rapidly providing solutions for the popular languages regardless of their paradigm.
It is people who provide solutions using languages as a tool. Each of us has the opportunity to help improve and promote the language in many ways, by writing libraries for the areas you just mentioned, contributing to compilers, joining the efforts of the language committee, etc. I don’t see the Julia community waiting for the founding members to do all the work. Instead everyone rolls up their sleeves and tries to give back within their capabilities. Putting all the responsibility in the hands of the standard-bearers is just blame-shifting.
This reminds me of some nice sketches by A. Masselot that aim to illustrate workload sharing among processes
