Seems like that's exactly what he doesn't care about. If you're prototyping or writing a lot of one off operations (for data analysis, maybe) then maintainability is less important.

IME, you only know that with hindsight. I have made one off programs I never needed to look at again. I've also made what I thought were one off programs that I needed to maintain for a while.

Even in a prototype, you may need to rework a particular piece of code multiple times before it works correctly. Even with a prototype, you may need to use it as a reference for your official version. Even with a prototype, you may end up having to use that as the official version (usually not by my choice).

Also, caring about speed 2nd is shocking to me (but maybe I just come from a different world). What if it isn't fast enough on your first attempt? Won't you wish your code was maintainable so you could change it to be faster?

> What if it isn't fast enough on your first attempt? Won't you wish your code was maintainable so you could change it to be faster?

From my experience, this isn't the case at all. A lot of the time my first attempt is in Python. The first attempt is really more of a prototype or a proof of concept. If the code works and I want to productize it, the code needs to be sped up. I have (at least) 2 choices: (1) make the Python code as fast as possible or (2) rewrite the whole thing in C/CUDA. If I take option 1, performance gains will be marginal and I still probably won't be happy with the performance of the software. Option 2 might take a bit longer, but at least I'll get something performant out. As I'm just throwing out and rewriting the first attempt, I don't actually care at all if it was maintainable code. I don't even care if the ideas in it were well explained/commented, because they're all my ideas and they're still fresh in my mind and I'm just going to rewrite the code and then document/clean up the fast version.

The appeal of Julia is that I no longer have to do this rewrite to make my code fast. Furthermore, if I don't have to do this rewrite, it is actually in my interest to make my first version of the code be maintainable and well documented.

Fair enough. But you ignored/changed the foundation my reply was built on. I'm replying to TFA saying "speed is second" and maintainability is... not considered. You're talking about "correctness being first" and speed/maintainability being not considered.

Honestly, all these languages, even Matlab, are quite decent at maintainability at the scale they are typically used. Almost anything would be decent at that scale. And speed matters, but you can always rewrite particularly crucial piece in Fortran when you know it all works.

Some people build software as a product, for example SaaS companies, software vendors, or enterprise systems programmers. Then some build software to automate difficult tasks or to interact with data. I think the first group cares deeply (or at least should) about maintainability, the second group just wants it to work and work fast. If it's easy to update and fix later that's a bonus but not the main point. I fall into the first class of developer but I can understand the seconds point of view.

Also a lot of scientific computing things are very much it works or it doesn't, and once it does it is a reification of some fundamental mathematical algorithm: a black box that should never need to be opened again.

Which is terrible science. Job #1 of good science is reproducability. Crapping out black boxes and claiming "I've proven my theory" in a way no-one else can analyse or reproduce undermines the fundamentals of the scientific method.

I would argue that having two people independently crap out black boxes and comparing them is far more scientific than having one, open box that's never reproduced.

A former co-worker of mine was having trouble understanding the results of her experiment. The simulation software she was using had been the gold-standard implementation for over a decade. The code was clear, well documented, and well engineered. However, my co-worker decided to re-invent the wheel and write her own. The results of her code exactly matched the results of her experiment. Thus, she designed a new experiment and predicted the results with the standard code and her own. After performing that experiment, her simulation was vindicated. It eventually came out that the standard code made assumptions that were invalid in a huge portion of the phase space.

It's important, as a scientist, to be able to perform the same experiment twice and get the same result. However, it's far more important to perform to different experiments and get the same result. If measuring my body temperature a hundred times with the same thermometer isn't nearly as useful as measuring it twice with two different thermometers. Having one piece of code that runs on on a hundred different computers, giving the same result every time, isn't as useful as having two different, independent code bases.

I do my best to make my code maintainable. I have everything up on github. I'm constantly trying to improve the documentation. However, if my code is still being used ten years from now, we have failed as scientists. What should happen is that a new code base should be written that does the same things that my code claims to do. If we get the same results, then great. If we don't, then we find out why.

But that's not happening. There's no plans for an independent re-interpretation. Everyone keeps using my code, because it's clear and it "works". If my code was less maintainable, then that re-implementation would eventually occur and they would be able to check my results. Only then would we truly know if my code works or if it just "works". I'm not going to do that, but I'd understand the reasoning behind it.

i'm referring to cases where you are say, porting or adapting a well understood algorithm. once the algorithm is at parity in terms of inputs and outputs the implementation details are relatively irrelevant from that point forward.

Often, especially with languages in the statistics, maths and scientific computing fields, you're only writing code for yourself and maybe 1 or 2 others. Everything you write is throwaway, or just functions that can be called and maintainability takes a second seat to ease of use for non-programmers writing code.

I think the idea is you can hack together your prototype in Julia, and then instead of re-writing it in C, you can either rewrite or hopefully just refactor your existing code into something presentable.