Never said that. Nice straw man.

However, there are more potential points of failure with the cloud, so a well maintained in-house solution is generally better, because it eliminates many of the external network points of failure. It also allows for multiple points of on-site failover as well as offsite failover (in the case of onsite catastrophe).

have you actually worked in a scientific field, let alone a biological one?

Yes, articles are rarely written with less than 5 authors, and almost never with less than 3. However, the process of working over everything requires math at most stages - if you don't understand it, you will take a lot longer to complete the project, and someone else will beat you to the publication. While you could constantly go and bother your mathematician/statistician, that is still a horribly inefficient use of resources, and will still slow you down.

The biologists should not be math experts any more than the the mathematicians should be biology experts. However, both would need to dip into the others field and become at least somewhat experienced to be effective. To suggest that biologists need not be even math literate, is idiotic, if you want proper, accurate research, which progresses at any more than a snails pace..

While most groups worth with teams, some generalization in all members is a good idea. Everyone should have basic mathematical knowledge, otherwise they are going to waste the time of the math & stats experts, as well as their own, with stupid questions and requests (everyone I worked with had that problem with our local math dunce). We'd answer some odd question, the person would go back, do something, ask more question, and halfway through we'd finally find out what they were spending so much time on, and realize how bass ackward they were going about it.

to put it in your terms, it'd be like someone doing the 3D programming and not knowing much about trig or vector math. There are libraries around that would would do the grunt work for them, but they are still going to cause problems. Math and stats are integrated into every aspect of science.

However, at the same time you can't specialize in everything, and almost everything is done in a team these days, so having specialists with different topics is better than having everyone be a generalist, so long as you can communicate and work together. Where I am now, a very large number of research teams have statisticians on board for that very reason - a lot of scientists are more familiar with their specific fields than the nuances and tools of statistics.

Given the comment on town size, and bandwith, I suspect the GP was referring to monthly bandwidth more than dev costs. It's anonymous, they probably won't have to bother with dev costs. Even assuming cheap VMs and whatnot, the bandwidth for such a site could be an issue, and including the VM to run it, cost $30-$60 a month (was looking at a relatively cheap Linux/FreeBSD host with 500GB/month). I think the top plan had $100 for 2TB/month. Still not to or beyond the $2000/year number, but not exactly cheap.

It's been said before and again. You shouldn't rely on the cloud as your sole point of data access.

It's fine for backup and collaboration, but otherwise... I'm always a fan of in-house.

Actually, mild/low inflation is important to the economy. It provides an incentive to invest or spend, rather than horde - these keep the economy moving. The key is mild/low - if it is too high, then there is uncertainty in how much is appropriate for compensation.

That's where the problem comes with bitcoin, what was being described above. It fluctuates too much. Backing it is a problem. Of course, in a few years, when we are more comfortable with it, it might well become a viable form of currency, but for now, it's better described as a volatile commodity.

That, and even if they did have a good metric, I suspect the first few million to billion years, would have more rapid development.

SImply put, from an evolutionary perspective - the more precisely a genetic material copies itself, the more it will propigate. Until you run into a wall of needing to adapt to changing conditions in the environment.

Assuming that exact replication is not trivial, you can conclude that for the initial period of life, mutations would be more frequent than they are now, and therefore , any calculation covering the change rate would have a negative second derivative with respect to time. Possibly something like (T+Log(T)). If T+Log(T) were the growth rate of the complexity, the complexity vs. time would look exponential, and the Log(T) factor could easily be overlooked if you aren't towards the beginning of the process.

Yep, especially when there is a distal part of the code where the array length is changed, but the variable holding the length is not updated. Yep, easy to spot.

Of course, good coding habits can make that easier to spot, but generally speaking, I've seen errors like that crop up here an there. The only way to fix this "error in excel" is to make the user interface less friendly for the less technical users. And then they'll just move to another application with this "error".

or in a language that doesn't automatically have a length indicator for your array, any value is possible (so no 'null terminators'), and you have to keep another variable to tell you it's length. If you don't update that, you may miss a lot of stuff at the end. Which is exactly what happened in Excel.

Even then, it's only if you add it at the end, and don't 'insert' a row. If you use 'insert row', Excel automatically adjusts the ranges that you do not explicitly tell it not to adjust... I.E. if you have sum(C5:C$9), that '9' will never move, no matter what rows you insert/delete, but the 5 may go up or down.

Then most people wouldn't use it.

You are not restricted to that mechanism (and I usually avoid it myself), but most users would have some difficulty with it. Mind you, any technical user should know better, but you'd be surprised at the number of minimally technical people in the various sciences, when it comes to things outside of their focus.

And, an example of how to cause this with a code rather than UI setup: If you add row to the end: how does it know to add it or not? there are multiple ways of doing this (insert, easy to understand, Excel handles it fine), but what if you are at the end of the spreadsheet, should it know that you are continuing on with the same theme, or that you are staring a new one? I've seen plenty of people put multiple tables on the same sheet.

It's still user error. And the problem wouldn't be eliminated with your suggestion, just altered. Even with horrible vision, I can still see both the highlighted color and the outlines of the cell without much difficulty.

Unless it's open source, and then it's user error no matter what!

That was the first thing I thought. If it were LibreOffice or OpenOffice, and possibly Apple Numbers, they would have properly attributed it to user error (not as certain with Apple, /. can go either way with them).

But of course, since it is MS, this is a program error.

Odd. My general experience is that they keep the old APIs, but shuffle to favoring new ones.

If you want broken backwards compatibility, go for Apple, and even then they had a good reason for it. Still, they have the dominant position here, not MS. Maybe you should be more worried about them?

I suspect this is more a troll than a shill. A shill would hopefully use more skill.

Otherwise, I agree with your post.