Ask HN: Why is scientific programming dominated by dynamically typed languages?
7 comments
The effectiveness is largely due to the uniform structure of the data that is being manipulated. This is obviously true with vectors, matrices in 2 or more dimensions.
Even when mixing numeric and textual data it is in a form that's not too difficult to line up. We don't think twice about not providing type annotations in our SQL queries. Most rows from a given relation are similarly shaped and outliers are filtered or conditionally handled. It would be very different if we were trying to operate on a wide range of structured types (e.g. customers, addresses, accounts) as both inputs and outputs. Scientific programming is usually dealing with large aggregates and not about producing individual records.
Even when mixing numeric and textual data it is in a form that's not too difficult to line up. We don't think twice about not providing type annotations in our SQL queries. Most rows from a given relation are similarly shaped and outliers are filtered or conditionally handled. It would be very different if we were trying to operate on a wide range of structured types (e.g. customers, addresses, accounts) as both inputs and outputs. Scientific programming is usually dealing with large aggregates and not about producing individual records.
Uniform structure of data favors static languages very well, however; look at how long science has been chummy with Fortran.
Also math programming; the computer algebra systems are all late-binding.
There are two reasons:
1. The users do a ton of work in a REPL of some sort. Jupyter for Python, R and Matlab have a notebook scheme, as do the CAS's.
So it's common to be running an environment where everything is reified at runtime anyway.
2. Polymorphism without generics. It's bloody hard to implement generics, and dynamic types let you ignore them entirely.
It's also very easy to get it wrong and very hard to make it understandable by a wide range of users.
And to counter a reason to make them early-binding:
Performance this is much less of a problem than you might expect in these domains, because scientific work is often dealing with big matrices and such, and you can heavily optimize those operations.
There are two reasons:
1. The users do a ton of work in a REPL of some sort. Jupyter for Python, R and Matlab have a notebook scheme, as do the CAS's.
So it's common to be running an environment where everything is reified at runtime anyway.
2. Polymorphism without generics. It's bloody hard to implement generics, and dynamic types let you ignore them entirely.
It's also very easy to get it wrong and very hard to make it understandable by a wide range of users.
And to counter a reason to make them early-binding:
Performance this is much less of a problem than you might expect in these domains, because scientific work is often dealing with big matrices and such, and you can heavily optimize those operations.
Honestly because it's easier. Modern scientific computing is actually dominated by C, which powers a lot of the libraries that do the crunching behind the scenes. Python has some fantastic connectors that can bind to C libraries and run computationally-intensive code very close to the machine. This makes the programming behind a lot of scientific computing look more like loading a library and running it with different input variables. This way grad students who are doing computational science but who do not have a background in computer science can get running fairly quickly.
For a long time fortran was the dominant scientific language and early versions of fortran were as static as it gets (no stack!)
Lisp era ai was mostly about inference over databases and not the intense numerics you see today.
Scientific computing is often experimental and ad hoc, it is important to be able to change it up quickly. The inner loops often are highly optimized so if you are using numpy you won't notice that python is slow. C++ is awful to do neural network work in (I have) and the kind of reprogramming supported by python is just what the Dr ordered for that kind of thing.
Lisp era ai was mostly about inference over databases and not the intense numerics you see today.
Scientific computing is often experimental and ad hoc, it is important to be able to change it up quickly. The inner loops often are highly optimized so if you are using numpy you won't notice that python is slow. C++ is awful to do neural network work in (I have) and the kind of reprogramming supported by python is just what the Dr ordered for that kind of thing.
Relatedly, check out https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
To expand on the other responses, the downsides of dynamic typing aren't as bad when the user of the program is also the developer.
Is there something fundamental within scientific programming that makes dynamic typing desirable?