nokome

Hi yoz, Stencila dev here. Thank for your interest. We're definitely still around!

Development of the frontend has indeed slowed down while we focus on more lower-level "backend" tools for research reproduciblity (e.g. https://github.com/stencila/dockter).

But were currently recruiting for a frontend designer and an engineer. So will be definitely be getting back to the interfaces soon!

Just a quick word of thanks for SheetJs from a Stencila dev! All the "mindnumbing testing and grinding work that honestly no one really wants to do" is obvious and much appreciated. Your efforts are so important for the ensuring interoperability but are often not recognised because they are "in the backend".

Yes, we'd love to have real-time collaboration, preferably in a decentralised way using Dat!

Thanks for the feedback. Comments and "track changes" are a commonly requested feature, important for collaboration, and certainly something we want to implement!

Hi, Stencila dev here, thanks for the feedback. There are several modular components that make up Stencila. The user interface modules are indeed built using Javascript, and Node.js is used in a number of places including the desktop and CLI apps and format converters. But for code execution, Stencila does not rely on Node, and users can use R, or Python or SQL.

Reproducible research depends on reproducible execution, which depends on a reproducible environment, which depends on a reproducible set of libraries and frameworks.

Completely agree. We are trying to make it easy for people to use reproducible libraries and environments. To this end, we are developing Nix environments (a highly reproducible way of defining computing environments) which include Stencila "execution contexts" for R, Python etc with standard libraries included. These environments can be connected to the user interface. See https://github.com/stencila/images/ for more details.

Hi, Stencila dev here. In my opinion, Stencila is not ready for daily usage. But we are looking for beta testers who are willing to put up with bugs and crashes and help us shape the framework. We have converters, based on Pandoc, which are able to convert to both PDF and Latex - although they are also in preliminary development.

Hey, yeah it's all open. The Dockerfile is here: https://github.com/stencila/stencila/blob/master/docker/ubun... I'm no expert, but it seems to be doing the job. Would appreciate any suggestions you might have! I'd like to make it smaller i.e. use a smaller base image.

Hey, author here. I used byzanz for this one: https://www.maketecheasier.com/record-screen-as-animated-gif... . For snazzier stuff, Screenflow is good.

Thanks for the feedback.

Your suggestion about named arrays is important and relates the discussion here around the approach taken in the OSX Numbers app and the now dead Lotus Improv. Its connected to a planned feature in Stecnila sheets that I call cell "mapping" - effectively projecting an R/Python object onto grid cells. There is some more about that here: https://github.com/stencila/stencila/issues/118.

Also related is an proposed improvement in how sheet expressions are translated into R code for arrays: https://github.com/stencila/stencila/issues/157

Hey, that's really cool, thanks for the link. Right now you can't do that...but give us a few weeks. We are planning to implement conditional cell formatting using CSS i.e. cell CSS styles as a function of R expressions https://github.com/stencila/stencila/issues/97. Once that is done, it would be fun to see if we could create these types of pretty picture.

Absolutely. I think it is the rapid prototyping aspect of spreadsheets that is perhaps the most powerful. For analysing large amounts of data they are obviously not great. But they excel (pardon the pun) at providing an environment in which to quickly formulate and visualise numerical models - because they are reactive so you can see what happens when you change inputs - without having to recompile, or manually rerun code.

@debacle, thanks for the nice feedback.

Regarding cell names. Currently every cell has an "id" e.g. A1 which is represented in the background R session as the variable A1. If you enter a formula like "pi = 3.14" into cell A1 then that cell has an id of A1 as well as a "name" (like an alias) of "pi". You can name a cell "a1" e.g. enter "a1 = 42" into cell A1 - but that could be confusing.

Yes, not being able to tab between cells is annoying - no decision was made on that - we just haven't got round to it. Just created an issue: https://github.com/stencila/stencila/issues/162. Thanks for the prod!

Thanks for the comment. Yes, the title of the article does sound negative (I was just trying to for something that caught the eye - something that is perhaps harder to do these days than back in 1991 when Linux was released). But the body of article is supportive of the spreadsheet approach and looks to ways that we can improve it and reach out to the existing user base - not to knock it down.

Thanks for the comments. Actually, I was just working on importing Excel spreadsheets into Stencila sheets last night. Some interesting aspects involved in translating Excel formulas into R expressions e.g. `AVERAGE(A1:A5)` to `mean(A1:A5)`. To do it properly looks like we'll need to build an Excel formula parser. But do-able - and could be fun!

Hey, Stencila developer here. Thanks, nxsheet looks really nice - great work too!

I agree, somehow getting spreadsheets into the workflow of reproducible data analysis is important. They are a tool that I for one had ignored (focussing instead of reproducibility of text + code) - but there are too many people that use them to ignore them!

Thanks again for the interest. I've launched a few more workers on EC2 for all of you attempting to play with the demo sheet (each of you gets a Docker container running an R session). Things seem to have stabilized for now. A good robustness test - more work needed! Sigh.

Thanks for the link. I was aware of Pyspread (which sound similar) but not of Resolver One - I'll add a link in the article

Yes, you're right this doesn't solve all the issues with spreadsheets as a programming environment. The "averaging over the right data" is a big one, and yes, being able to diff a text file won't help that.

Thanks a lot for the suggested syntax - it's really good to get some feedback. I need more time to think it through and work out exactly how this would work.

In the meantime, one solution to the problem, that I would like to implement soon, is cell mapping - in effect projecting native data structures onto grid cells. That way you can still display and modify your data in the spreadsheet but use a sensible formula like `mean(data$height)` instead of `mean(A2:A5)`. Would love comments on that idea - there's an issue on it https://github.com/stencila/stencila/issues/118

Hi, article author here. I have never used Improv but while researching for this work I did read about it and yes, it did seem to have introduced several innovations to address flaws in the spreadsheet approach. The OSX Numbers app seems to have picked up some of these ideas. And, I'm hoping to apply some of them to Stencila Sheets too.

Hey, Stencila developer here. Yes, I agree. I recently came across the Numbers app when I was writing this. I haven't used it but from what I have read it seems to have some really good ideas for improving the spreadsheet interface.

Yes, I think that they certainly help at making spreadsheets more readable. At present Stencila sheets only has named cells but one of the things we want to add soon is mapping of cells onto underlying `data.frames` or matrices. In other words to "project" data objects onto the spreadsheet grid.

Thanks for the comment. "Spreadsheets are dead, long live spreadsheets!" does actually capture the intent of the article more accurately. But I used "..., long live reactive programming environments!" because I wanted to emphasise the point that spreadsheets are actually reactive programming environments. The article isn't try to suggest that the spreadsheet interface is going to be replaced. Rather is says that by combining it with a "code-based" approach we might be able to create a whole lot of benefits for testability, audit-ability and reproducibility.

Hey, thanks for pointing that out. Fixed now. I actually got it wrong in all three places I mentioned him :(

Hey, Stencila developer here. Thanks to the original poster for sharing the link and for all the interest. Unfortunately, the site is not handling all that interest too well (R session hosting instances filling up, timeouts,...). I'm working on it but please bear with me while I try to stabilize things.