On 08/30/10 09:51 PM, Robert Bradshaw wrote:
On Sun, Aug 29, 2010 at 3:47 AM, Dr. David Kirkby
There are two different goals that people have here. One is to build a
solid, bug free piece of mathematical software, ideally conforming to
all the good software engineering principles, building everywhere,
well tested, etc. The other goal that people have here is to make Sage
into something useful for their current research and teaching needs.
While these two goals certainly complement each other, they have
vastly different priorities.
IMHO, if Sage is to be a viable alternative to the 4M's, it needs to address the
former.
If so, what should we do better?
* I think a good start would be to try to attract some compute science
students to do some projects looking at how quality could be improved. In
essence, I don't believe Sage has the right mix of skill sets.
Welcome, all CS students! On a more serious note, we have had one CS
student look at the security of the notebook for a master's thesis,
but more would be nice.
That's something William and others need to actively seek out though - ask in CS
departments.
One CS student project is useful, but that must be a very small fraction of the
total number of student projects.
He can buy me a copy of
http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/0137035152/ref=sr_1_1?ie=UTF8&s=books&qid=1283077786&sr=8-1
if he wants.
Some of what we do may be due to ignorance, but, as I've said before,
it's often a question of allocation of resources (mostly time).
But if anyone is going to spend a lot of time doing something, it would make
sense to reduce ones level of ignorance.
I believe the time/effort used to find out how to write better software, would
reap benefits in the medium and long term.
* If there was funding, then pay someone with a strong background in a
commercial environment with knowledge of how to develop software. Someone
good would cost a lot of money. He/she should be interviewed by someone who
knows the subject well. Perhaps ask a prof from the CS dependent to be on an
interview panel.
If there was funding, most people would probably rather spend it on
someone who could develop new algorithms to further the state of
mathematical research. If there were funding for many people, perhaps
a percentage could go to funding someone with as CS background just to
focus on software development issues.
I suspect you are right - people would rather spend the money on someone
developing algorithms. But what area? Ask 20 random Sage developers and you are
likely to get 15 different answers.
I think this was clear when William tried to get a list of the most annoying
bugs. There were barely any common ones. People have different interests. As
such, an extra person working on algorithms in field X is probably only going
to benefit a small fraction of the Sage community. In contrast, someone whole
could improve the procedures could benefit everyone.
A year spent cleaning up Sage's procedures would benefit everyone - a year spent
developing algorithms would probably have far less overall positive impact.
* Have regular "bug fix only" releases, where the aim is just to increase
the quality, and not to add features.
Nathann Cohen has said "-1" to that idea. William has said it would put
people off, and at least one other developer (forget who) did not like it.
But I feel it's probably one of the easiest ways to improve Sage.
I'm unconvinced that this would help, and agree it could put people
off. We could bump all non-bugfix tickets to the next release but I
don't think it'd increase the actual number of bugs fixed. (Bug-fix
Sage days work well though.)
By bug-fix release, I should elaborate. I would include
* Bug fixes
* Added documentation.
* Extra test code
I think having releases where new features were not introduced, but those three
areas were addressed, it would result in a concentrated effort to reduce the bugs.
But, that was NOT the main reason for suggesting it.
My reason was that basically by having 'bug fix' releases, you would create some
releases which are more stable than others. Those would be more suitable for
people who don't want to keep upgrading every couple of weeks. They might chose
to have stability in preference to features. I believe there are a lot of people
in that category.
* Have a system like gcc, where the releases numbers x.y.z mean something.
Only have z != 0 on bug-fix-only releases. Make it clear on the web site
that the the x.y.0 are less well tested.
+1
But to do that effectively, one needs to have bug-fix only releases - just like
gcc does.
* Make release candidates available for anyone to report on.
+1
I was pretty sure you were against that a few weeks ago - saying they should
subscribe to sage-devel and would be aware of them. Perhaps it was someone else.
Sorry if I'm mistaken.
I think making the release candidates public for a couple of weeks would be
good. I've lost count of the number of times a release is made, only for it to
be realised there's a fairly serious problem a couple of days later.
* Have longer times between the "final" release candidate and a release
date. I expressed concern that 4.5.3.alpha2 was going to be released last
Monday and 4.5.3 released on Friday. Luckily that has not happened.
+1
We do seem to agree on quite a bit.
* Something I suggested before, which would not be perfect, but would be
useful, is to have a "risk factor" on trac tickets.
That's an interesting idea.
I think one worth perusing.
* I think William is spot on this blog post.
http://389a.blogspot.com/2010/08/computational-projects-part-1.html
There should be a difference in code quality that one developers for
oneself, and what gets put into Sage. It sounds like William will be
developing things for himself, which wont be committed to Sage, as he will
not have time to document/test them sufficiently well. That's a good sign.
But I think a lot of the code in Sage is very specialised things, that are
only useful to a very small number of people. IMHO, that should be in
external packages which people include if they want them. These bits of
code will be unmaintainable if the person including them leaves. I don't
think they really should be in the core Sage code. I think the R model is
more appropriate.
I do feel that code improves going through the review process and
getting it up to snuff to get into Sage. It'd be sad if there's
decreased motivation to do so (but I totally understand).
Yes, I agree code would improve with the review process. I would not discount
having optional packages reviewed myself. I just feel that having very
specialised code in the core is not such a good idea. Arbitarily, I'd say if
less than 100 are likely to use it, then don't add it to the core. That would
make the core less susceptible to bit rot.
If you look at the Wolfram Research Library, where are a whole load of optional
packages available contributed by users. I assume they have gone through at
least some form of review before being put on the Wolfram web site.
Acutally, it's quite funny, since 2004 there has been a very nice library for a
polar plot of a list of data.
http://library.wolfram.com/infocenter/MathSource/2061/
Then in Mathematica 6, Wolfram Researhc added ListPolarPlot[]
http://reference.wolfram.com/mathematica/ref/ListPolarPlot.html
The funny thing is, the old contributed code for creating polar plots of a list
of data is *much* better than what's in the core Mathematica code.
Something like adding doctests to otherwise stable code could make a
student project.
Yes.
But also an equally good, perhaps even a better student project would be to look
at whether there are more appropriate ways to test some parts of Sage. Again,
that is for a CS type student.
Someone said the R interface is "rough around the edges". I'd like to see
less emphasis on sticking things into Sage, and a bit more on not having
things that are "round around the edges".
Yes. Sometimes we just take the best that's out there rather than not
have it at all.
But R itself is not "rough". It is a well respected package, with commercial
users and commercial support. But I'm told the Sage integration to R is rough.
I'd like to see a bit more emphasis on having things with smooth edges before
they get integrated.
* Have design documents, which document how specific areas will be done. It
seems at the minute that someone has an idea for new bit of code, they
create some code for the library, it gets reviewed and committed. I don't
see any real design documents.
We used to do "sage enhancement proposals" now and then, but I haven't
seen one in a while.
I've not seen one at all.
I have on and off worked on Sage for at least 5 years, though I lost interest at
one point when it was clear the Solaris fixes Michael had were not being
integrated.
* Run the self-tests for the packages. In many caes upstream packages have
test code, but the people that added the .spkg's never bothered looking at
running the tests.
+1
This one really is a "no brainer" but unfortunately a very small fraction of
packages in Sage do this.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
