I work in quantum information, and I need support for complex semidefinite programs.

I use MATLAB/Octave, with the SeDuMi solver (to share open source code) or MOSEK (amazing, with free academic licenses).

For the modeling, I use either YALMIP (amazing breadth of functionality, though additional features tend to not compose well), and CVX (restricted use cases, but I find it amazingly robust).

I haven't made the jump to Python (CVXPY support for complex variables seems missing/shaky), or Julia (I tend to write OOP-lite code and haven't been able to wrap my head around Julia's abstractions).

I've also been exploring exploiting symmetries in convex programs, see https://replab.github.io/web

> The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.

I'm currently teaching modern scientific Python programming, if that's a thing.

You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic?

I was thinking of dividing academic code in 3 "Ps":

- Playground: throw-away scripts for data analysis, fast moving code where any rigidity slows the process. Internal use by a single researcher usually.

- Prototype: code that serves as a foundation to the above, or is reused frequently, but is otherwise not shared outside a research group.

- Product: code, often open source, that is shared with the community.

Most tutorial about "good coding practices" do not make distinctions between these three stages.

For Python, there are practices that work at any level: auto-formatting code and sorting imports, gradual typing. But things like tests, API documentation, dependency management only apply to steps 2 and/or 3.

Stage 3 does not always happen. There are a few remarkable counterexamples, but most research software does not usually finish taking the form a product.

In my experience, what happens is that some prototype works quite well and gets used in the next project. But the next project is building a new prototype, not improving the previous one. After a few projects, the person who wrote that first prototype already left the department, but there are people who depend on it to get results. If enough time passes, you will have some piece of legacy code that very few people can understand.

The problem with academia is that, while the prototype is an excellent topic for an article, the real product, a maintained (and maintainable) software project, is not. And getting funding in academia to do something of no academic interest (ie. that cannot be turned into a paper) is very difficult. If the software is of no interest to some industrial partner willing to spend money, that code will just keep moving between the USB drives of PhD students, probably branching into slightly different versions, until someone is brave enough to start working in a new prototype and the cycle starts again.

Maybe add a fourth category.

- Petrified: code that's set in stone and everyone's to scared to touch in because "it works, but God knows how".

With the increasing expectation that academic research results should be reproducible, there's really no such thing as throwaway "playground" or "prototype" code. Everything is potentially a "product".

Not only are software development life cycles different, but also the attitude to development. Which is not a surprise when in most cases, the output is not the software (or system), but research or learning; the code is merely a side effect.

Two book recommendations, to refresh your mind if you've been too deep in "investing in inner growth" (can be a trap).

- the Zhuangzi, translation by Burton Watson, which I've read many times. See the last two paragraphs of https://terebess.hu/english/chuangtzu.html about the useless tree

- Cutting Through Spiritual Materialism by Chögyam Trungpa, which I haven't read except extracts, but it could be relevant to you (esp. if you're looking at spiritual growth).

But anyway, instead of buying new book... I'll speak of what I'm doing in a week.

I'll go for ten days in the countryside with my dear partner and leave the laptop at home. I'm quite productive these last months (just submitted something to Show HN today), I find I'm missing guidance on a few areas of my life, and I'm in dear need of slowing down and cutting the external noise.

Haven't taken real holidays in years.

Definitively a good idea to disconnect, it's really important, and definitively need to do it more.

Do you mind if I email you directly at hello@...?

I have a few thoughts to share and questions to ask about your search.

I wrote my PhD in TeXmacs: https://www.texmacs.org

Advantages:

- It's the fastest environment for me to type mathematical manuscripts.

- If you are familiar with LaTeX, you can backlash your way in immediately.

- If you are familiar with Word, you can use the dropdowns as you would use the Equation editor.

- The typesetting is great.

- It has great LaTeX export (there are a few things to clean up, but that time is in the single percent digits compared to the time savings).

- It has .bib support for citations.

(Working with exported LaTeX code seems ugly, because of the pretty-printing though)

Disadvantages:

- It crashes. Nowadays much less, but that's still a hassle. Splitting your work in multiple files helps (especially for a PhD-sized document).

- Five years ago, it was difficult for me to figure out how to use macros, customize the layout, so I mostly gave up. If you have to automate a lot of custom type-setting, LaTeX is probably still king. I haven't skimmed through the new book, I would do it if you plan to use TeXmacs: https://www.scypress.com/book_info.html

- Fiddling with bibliography formatting wasn't fun, it is not fun either with LaTeX, but LaTeX often has a StackOverflow answer for you.

I'd give it a try, absolutely. You'll need to decide pretty quickly if you want your workflow to go TeXmacs->LaTeX->PDF or TeXmacs->PDF.

In the first case, you'll process the pain points in LaTeX, but there'll be people around you to help you.

In the second case, you'll have to dig into TeXmacs styles if the default options do not suit you.

I also use TeXmacs to prepare slides, because that's the most efficient workflow I have. Though I have to route my intent around the software limitations, I find it quite worth it.

That's pretty cool! I find it a step harder than Wordle, because you cannot guess your way into the puzzle.

I gave up, will try tomorrow again.

Yes - it probably is a bit harder than Wordle. I think this is for people who like Wordle, but find it a bit too easy.

I'm starting to add type annotations to numerical code, and I wonder how to handle the disconnect between `float` (which is how floating-point literals are typed) and concrete NumPy types such as `numpy.float64` (which is the scalar type I get out of NumPy arrays).

I ended up defining an alias:

Float = Union[float, numpy.float64]

but I wonder if there is a more legitimate way to handle thiss.