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 -~----------~----~----~----~------~----~------~--~---