Bill Hart wrote:
 >> >
 >>> > > * Releases happen so frequently that IT depts. cannot hope to 
keep up
 >>> > > with installing the latest releases.
 >> >
 >> > I wonder how much more often Sage releases are than iTunes releases?
 >> > I just checked and our releases are maybe about twice as frequent as
 >> > iTunes.  I'm just pointing out that Sage isn't that unusual with its
 >> > release schedule.  It used to be 2 years ago though.

Yes, but iTunes doesn't take ~1.7 GB of storage space.  I can't use Sage 
on my school computer cluster because (1) they only give me 2 GB of 
network storage space, so I don't have room for both my data and a 
personal installation of Sage, and (2) Sage changes too often and 
requires too many fixes (see below) to suggest having a shared install.

Perhaps a better comparison would be with a programming language 
interpreter or compiler, since Sage constitutes a computing platform. 
After a 1.0 release, these are expected to remain quite stable.  A more 
appropriate standard would be with the components Sage uses (e.g. PARI, 
GAP, Singular, etc.) or other CAS's, but I have little experience with 
these.

>>> * Users are expected to be developers
>> What does that mean really?  It doesn't seem technically meaningful to
>> write "Users are expected to be developers".  Expected by whom?  What
>> is a developer?
> 
> Dunno, ask the person who said this to me.

I can clarify this from my own experience.  When I first started using 
Sage, I wanted it to be a tool, like Matlab.  When I ran into a bug, I 
was asked to get a trac account and post a bug.  This is asking your 
users to be developers already.  Furthermore, since everyone is busy 
with their own projects, I had to try to fix the bug as well.

Maybe I'm not using Sage like most people, but it seems that _every_ 
time I use Sage I find missing/broken/slow functionality, and I start 
opening trac tickets and posting patches to _Sage_ (the tool) to get my 
particular application to run correctly and in a timely manner.

This situation could be viewed as either a good or bad thing.  When I 
find bugs in commercial tools, I spend a significant chunk of time 
trying to find a simple way to reproduce the bug, submit it, and then 
wait for six months or more for the company to fix the bug and issue a 
new release.  With Sage, I can fix the bug immediately and get on with 
my task.

On the other hand, I've never found a bug in Matlab.  And with the tools 
I have found bugs (still _much_ less often than with Sage), it takes 
much less of my time: I don't have to dig through source code that 
someone else wrote, find, fix the bug to the original author's 
satisfaction (or whoever reviews the ticket) -- often involving several 
iterations.

There are also other considerations in this area, e.g. tools/process 
flows are streamlined for _inside_ the Sage tree.  For example, I 
haven't figured out how to use a .pyx file outside the Sage tree.  (I 
used .spyx files instead.)

Just my humble opinion.  Enjoy!

---
Ryan Hinton
PhD candidate, electrical engineering
University of Virginia

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to