A few random thoughts : 1) the Jupyter notebook is an interface used by a *lot* of projects. Jupyter kernels do exist for a large number of computing tools. It is therefore well-developed and actively maintained.
2) In contrast, the Sage notebook, while quite advanced *for its time*, has remained a Sage-only interface. Yes, you can use a number of other tools with i, *as long as they are known by Sage*. This simultaneously enhances and limits its utility. For example, one can use the Sage notebook for Maxima (and even use Maxima, R or gap cells in a notebook mainly containing Sage code). But only with Sege-suported version of Maxima, R or gap. Don't even think of having Lisp or (heavens !) Fortran cells... And, yes, this need exists : a "Fortran engine" has been added a couple years ago to an R tool offering services quite related to SageTeX (writing \LaTeX or mrakdown text interspersed with code). For some needs, Fortran has not yet been replaced... 3) The same is true, with both aggravation and mitigation, for SMC and its related tools. I like the idea of a \LaTeX editor that supports sage (or other) snippets. But, again, *only* with the tools integrated in Sage... In contrast, emacs+SageTeX(+R+knitr) give me a better service... 4) Jupyter kernels *do* look at what is done in Sage, and some of the Sage notebook advantages are ported to other kernels. I wouldn't be *too* surprised to see, for example, a %%Maxima cell magic appear in the IRkernel that provides R notebooks. 5) The use of standard tools allow to alleviate some of the current inadequacies of Sage or its notebook : For example, whereas *Sage* interacts are not yet ported to Sage's Jupyter notebook, one can use Python's widgets to get interactive graphics in Sage Jupyter notebooks. Similarly, while the current Jupyter notebook won't display the graphs produced by R, this can be worked around by displaying images exported from R using the general-purpose IPython tools. So, we have a choice between : - a general-purpose tool that is maintained by a large community, which can be customized to our needs, but needs (a non-trivial amount of) manpower for this customization, - an ancient tool, well-suited to our past needs, but difficult to maintain and single-purpose, - a newer tool, extremely well-suited to our present perceived needs, but in practice unmaintainable outside SageMath Inc., as far as I can see... and also single-purpose. I'm afraid that history shows that this isn't even a choice : the multi-purpose nature of Jupyter gives it a (probably unbeatable) competitive advantage over its competitors. The SMC, however, will probably succeed for its initial goal (serving a large group of users using exclusively Sage and its federated tools via the Web), for which it seems probably unbeatable ; but for people needing a local installation, or needing an interface to tools not (yet) integrated with Sage, Jupyter is simply better. So I think that the best use we can make of our limited manpower is to concentrate on the Jupyter notebook and, to some extend, the SMC. Once all the abilities of the current SageNB can realistically be said to be ported to the Jupyter notebook, we should deprecate the SageNB as soon as it is possible. BTW, since the Jupyter notebook has been realistically usable with Sage, I spend most of my (quite limited) Sage time in the Jupyter notebook, most of the rest in emacs (for plodding paper-like material), and the rest of the rest in console (to reproduce a problem and ensure that it is not an interface problem before posting in sage-support or sage-devel). It seems that I "voted with my feet) : I haven't opened the Sage notebook in more than a year, save to cut'paste older code ... usually to the Jupyter notebook. HTH, -- Emmanuel Charpentier Le mercredi 23 novembre 2016 23:57:34 UTC+1, Jack Dyson a écrit : > > Hi Dima, > > Thankyou for your quick reply - I appreciate what you said about > development of sagenb as a whole, and actually I do see the point. > > Logically therefore, as you indicate, iPython is a good alternative. > Unfortunately, it is not fully compatible with sagemath, for example R > doesn't access it properly in all respects or the 3D graphics formatting > was of last time I checked. > > The current sagenb is excellent on both those things even if the structure > is dated: I want to just make clear it does *work* extremely well and > that's what a user spends 80% of their time doing. > > It is great that SMC's notebook is actually available in some way: and > here I feel that a decision needs to be made: > > therefore one of these should answer well: > > 1) "phase out" sagenb completely and* integrate SMC into the sage > distributable quickly* so that it is the default option - as was hinted > at a few years ago. It was in fact stated then that developing sagenb was a > "waste of developer resources" > 2) dump jmol and make iPython the default notebook and address its > remaining incompatibilities with packages (which would need a rewrite of > the sagemath API so it is no longer view model dependent I suppose) > 3) create a new independent team around sagenb : decide what we need and > continue Sam's work in whatever framework we want, the functional model of > the code made independent from the implementation > > The corollary is clear: not all sagemath users want to specialize to SMC > for various reasons, and the sagemath userbase (universities for example) > as a distributable is going to be under threat without a viable modern > *local* interface just like Maxima was years back before wxmaxima. > > I think William wrote something below about installing a docker and > getting SMC up, very welcome indeed : I'll give that a go for starters. > > Best from here, > > Jack > > > > > On Wednesday, November 23, 2016 at 9:05:50 PM UTC+1, Dima Pasechnik wrote: > >> >> >> On Wednesday, November 23, 2016 at 6:42:40 PM UTC, Jack Dyson wrote: >>> >>> On Friday, April 15, 2016 at 10:44:21 AM UTC+2, Jeroen Demeyer wrote: >>> > Hello all, >>> > >>> > I propose to make SageNB no longer a separate package but to move it >>> > back into the Sage git tree. For purposes of installation and use of >>> > SageNB, it will still be a separate Python package, but the sources >>> will >>> > be in $SAGE_ROOT/src/sagenb instead of a separate git repo. The >>> changes >>> > to the Sage build system to support this move will be minimal. >>> > >>> > The reason is that SageNB is truly in maintenance mode currently. >>> Making >>> > new SageNB releases regularly to fix things is a burden for the SageNB >>> > release manager Karl-Dieter Crisman. On #14840 [1], he said "the >>> sooner >>> > sagenb gets back in Sage proper, the better!" >>> > >>> > The original reason to split SageNB from Sage was to enable quick >>> > development. That worked for a while, but now that development has >>> > stalled, this reason no longer applies. A secondary reason was to make >>> > SageNB truly independent from Sage, but that also never happened. So I >>> > see no reason to keep SageNB split from Sage currently. >>> > >>> > I know this is a controversial proposal, but it will certainly be >>> easier >>> > to maintain SageNB this way. I also want to stress that this is >>> > orthogonal to any future deprecation or removal of SageNB: we can >>> still >>> > do that from the Sage git tree. >>> > >>> > Jeroen. >>> > >>> > >>> > >>> > [1] http://trac.sagemath.org/ticket/14840#comment:58 >>> >>> Hi everyone, >>> >>> With the greatest respect, I disagree strongly - chopping and changing >>> the notebook this way leads to a lot of instability in the code and >>> confusion for anyone who wants to get into developing on sagenb projects. >>> >>> Added to the fact that none of us would have time to document changes in >>> detail causes new contributions stagnate, which wastes effort and >>> randomizes progress. >>> >>> Actually the functionality of the current notebook is good, the look and >>> ui is very dated and as many are aware, a bit on the unpolished side. >>> >>> Remembering Samuel Ainsworth's really good work a few year's back, I >>> would like to ask why was that system not developed and integrated into the >>> local sagemath distributable? >>> >>> From the trials he conducted in 2012 it ran well on Sage 5.3 and was in >>> my opinion a decent step forward. I'll post this to a separate question as >>> I wanted to explore the possibilities of getting that up and running again, >>> even if only for private use here. >>> >>> It doesn't seem to connect to sage 7.3 so I wanted to see if anyone knew >>> why ? >>> >> >> I understand that opinions on usability of >> https://github.com/sagemath/sagenb/tree/newui >> diverge. (and with the breakneck speed javascript >> frameworks are developed, one may ask whether something written in 2012 >> is still a great idea) >> >> You ask why sagenb is not developed further. >> 1) the sagenb's design is really dated, and jupyter notebook seems a >> better (and much better >> supported) alternative. >> 2) Another actively developed alternative is SMCs notebook, which can be >> run >> locally. >> >> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
