ferdterguson's comments

Python is my day job and I'm very fluent in the common data science tools like Pandas, but you'll hardly ever catch me using Pandas because Excel is just so much easier for 2d data.

The thing is, I never use Excel because the data I work with every day is almost always multidimensional, so I work with xarray[1]. It drives me crazy to see coworkers using Excel for things that it is not suitable for and having crazy solutions like multiple tables per sheet, multiple sheets, multiple files or other hacks to describe another dimension of data.

[1] http://xarray.pydata.org

> It still takes lot of expensive human work to select the good quality works and proofread /edit/ peer review them etc before it is fit for publishing in a decent journal

Good thing that almost all of that expensive effort is done by volunteer scientist editors and reviewers. I routinely see spelling errors and english errors (going against journal guidelines for British/US english) in scientific literature. I'm convinced publishers do as little proofing as possible.

Pandoc?

In my field, if you get a TT position and play nice, you usually get tenure. But yeah - it's basically all about money. You can't do good research if you don't have solid funding, you don't get solid funding unless you have good research in high impact journals.

One thing they mentioned in the 'left out' section is code review. I'm a researcher in a computation-heavy field and I think that anything I write that is intended to be used in our research group or used by other people should be code reviewed. In my experience, so many codes written by former group members or by senior group members become blackboxes that no one can read or maintain in five years.

Code review for anything more complicated than a script has helped the quality of what I write. It also ensures that there are other people who have at least seen the code that I wrote. Even if they don't fully understand it, they are at least empowered enough to wade through it if need be.

This is more likely to be applied to topology optimization imo

Retain means pay monthly.

> Python in some cases can be 100x slower than C

Yeah, the Python implemented version is. But people doing serious computing in Python that requires speed are doing it with NumPy or even Cython or just straight up calling C/Fortran libraries in Python.

Maybe that's just the language, not the support?

To me the Hardee's burgers are just like Burger King.

Not a field, but a person who everyone thought was Nobel prize bound and it turned out to be all BS. You may think that it's just one person, but the amount of research dollars that got allocated to try and prove or disprove all of this work would be staggering. https://en.wikipedia.org/wiki/Schön_scandal

I would pay actual dollars for an org-mode spacemacs reference

I understand the GPL, but I personally prefer BSD/MIT and I am disappointed when I come across things I like in the GPL. IMO the GPL is not really 'free'.

On the other hand, the GPL wouldn't make a difference here unless they are actually distributing it and my understanding of LGPL means that they could do whatever they wanted to as long as they use NumPy and don't change it.

Just because the API is bad doesn't mean we should throw money at it. I agree that NumPy might not be the best recipient either. It's hard telling, really.

Personally, I believe the biggest blocker for me is to have good visualization tools. That's ultimately what gets me paid is showing other people my work and getting them to give me money to continue it.

On the core science stack IMO there's numpy, scipy, sympy, matplotlib, pandas and xarray. I probably use it next to least, but I really think sympy is the one that could benefit the most from some funding.

Word has built in diff. Review -> Compare.

It's kind of slow though in my experience. Diffing plain text is amazing. I recently used it to diff a research paper I was peer reviewing that the TeX source was provided for. I felt like a wizard.

People are dogging on you for suggesting learning styles. Learning style aside, seeing something with your eyes helps you see it with your mind. I think very few people would find it easier to understand a paragraph or a few than a good illustration or demonstration.

Not sure if you are aware of detexify [0], but it recognizes my trackpad-scratch quite well. The backend and all of the training data are open source, so you could indeed implement this yourself if you wanted.

I'd buy mobile app any LaTeX OCR software.

[0] http://detexify.kirelabs.org

I use Microsoft OneNote to take notes. The math notation is almost exactly the same as in LaTeX and you basically compile it on the fly with the spacebar. <ctrl>+'=' toggles math mode on and off from the Mac. There are some hiccups, especially with OneNote keeping track of fonts (in my experience) but you get used to them.

Same in Python Juypter Notebooks. I wish I could use rst though. I have to google it every once in awhile to remind myself that they won't support it (https://github.com/ipython/ipython/issues/888#issuecomment-2...)

You make some good points regarding LaTeX. In my opinion, anything that you can express in markdown is not that hard to read in TeX source. Most of md is centered around section headers, links, basic text formatting (bold/italic) and lists. Most of those are very readable in TeX source.