amend the mission statement and the roadmap to reflect landscape and Sage changes 20 years on #36827
Comments
|
As author of the original mission statement, I do agree that much has changed in the world in the last 20 years, as outlined here. |
This is an important point. To make it more concrete, I would add that existing solutions should be reused and existing standards should be followed whenever possible. Sage currently has many complex 'customizations', that might have been improvements over the state-of-the-art solutions at the time they were introduced, but are now preventing an easy adaptation of the new standards (examples are custom package manager, custom test runner, custom doctest format, custom sphinx setup). |
|
I also think that the mission statement is no longer appropriate. But the perhaps most important point is missing in the list above:
|
|
This also means that focusing the discussion on the Sage distribution in its role of providing the Sage "application" to end users is fundamentally misguided. (See the Apr 2023 sage-devel thread "What was/is/will be the purpose of maintaining the Sage distribution?" Instead, we need to focus on what the Sage distribution provides for the development and distribution activities of Sage (as an upstream project).
|
|
Dima and Matthias: do I have your permissions to delete all the off topic argumentative comments above? Please just answer yes or thumbs up. Thanks! [Edit: I've deleted most of this discussion. Please have a civil and useful discussion. Thanks!] |
|
On 6 December 2023 19:36:24 GMT, William Stein ***@***.***> wrote:
Dima and Matthias: do I have your permissions to delete all the off topic argumentative comments above? Please just answer yes or thumbs up. Thanks!
sure
|
|
It's hard to come up with catchy short mission statements, but let me propose one: Enable and utilize open-source mathematical libraries within Python realm Comments welcome. Please feel free to spread the word. @kcrisman @vbraun @videlec @nthiery @fredrik-johansson @isuruf @fchapoton @jhpalmieri @VivianePons @tornaria @tscrim @fperez |
So whose role is this? For those who have no idea what wheels and reference distributions are? In the thread mentioned, "We decided to get out of the business to publish binaries; we weren't doing it well, and numerous distributions and third-party binaries filled the role." The first part may be true, but I am not too convinced by the latter for Windows, and even for Mac we do rely on the kindness of the 3-manifolds project. I'm trying not to be too snarky on this, but Sage is still a tool, and if the mission statement changes, at least I personally would like it to be a tool that is available to the unwashed masses. And that means, now more than ever, "apps" that can be downloaded and installed very easily. (As an example, the demise of the Android app using the cell server, while understandable, was a pity.) One doesn't have to invoke Maple or Mma to say that providing the Sage "application" to end users is a really valuable thing for someone to do. And who else would? Maybe Docker images are part of this, but that's a pretty weighty solution. Maybe conda is, but I haven't seen consensus on that yet. Maybe CoCalc is part of this, but probably not for everyone, not least because not everyone in the world has 100% connectivity at all times, nor may be allowed to use cloud solutions (for various reasons). Likewise the cell server, though it is fantastic for many things, and probably has more Sage users than all Linux ones combined. If we don't provide a GUI, then how does a user install it? Do they know? Do they need to delve into CLI to do it? If someone is told to download Jupyterlab and then get a Sage kernel, is this something someone can do who is just starting a programming course and has never seen a command line before? Maybe no one of these questions is important on its own, but together they are crucial. @williamstein 's most brilliant idea (and no disrespect intended, or surely taken, with respect to his other brilliant ideas!) was to be open to it when @wdjoyner asked him if Sage could do calculus. And once Sage went beyond just providing a few localized research tools, but a full ecosystem to take the young mathematician from day one of college to the frontiers of research, the role of end-user distribution needs to be part of the discussion. Otherwise I don't really see the point of having a mission statement, or Sage qua Sage, at all. The alternative would be dozens of independent Python modules which may or may not interface with various C libraries. In the end, that would be a real loss to the open-source mathematics community. Sage's strength is precisely in allowing people to seamlessly use calculus, graphs, representations, statistics, number fields, and a bunch of other things all in one computation (including from dependencies like GAP, Pari, R, etc.) using a friendly and well-supported base language. |
|
So as not to be charged with only complaining, which could be justified after that long of a comment:
This is hardly objectionable as a goal for something, but Sage is really more than the union of its parts. How about this? Surely too long, but brevity isn't my strong suit, as amply demonstrated here. Unify and interweave open-source mathematical libraries, using the full Python ecosystem as a framework |
|
I think that the mission statement should address the needs and interests of users, not developers, packagers, distributors, etc. The idea that Sage aims to make existing open source mathematical software available to its users in a consistent convenient computing environment should be the main component of the mission statement. Developing and expanding the Sage environment should be the primary goal of Sage developers. Other things, even core features such as the choice of using Python as the framework in which to implement the environment, are implementation details. The reason for using Python should be that the Sage developers found it to be the best choice for how to implement the Sage computing environment. |
|
I also have a suggestion for a secondary component of the mission statement. This does not apply directly to Sage users. Instead it applies to the community of which Sage is a part. And it also relates to modularization. I think Sage should aim to support other open source computing environments by enabling them to conveniently embed parts of Sage. |
|
Modern mathematics with an integration mission |
|
Is that a self-referential mission statement? 😊 |
|
The most important property of a mission statement for SageMath is that it suggests answers to questions about the direction and scope of the project, and also helps people who find out about Sage to know what Sage is. The current mission statement has been very helpful in that regard many times over the years. E.g., if somebody said "Maple is awesome because it can do XX, and we really need that functionality to be able to use Sage instead", the mission statement would suggest that adding XX to Sage would be reasonable (for many values of XX). If somebody said "Sage should be rewritten in Julia", the mission statement would suggest: "nope, since that doesn't clearly help people who need a viable alternative to the Ma's, since they mostly don't care about the underlying implementation language.". If the mission statement were instead about increasing the use of Julia in the world, then such a suggestion would be strongly supported by the mission statement (obviously). A shortcoming of the current mission statement is that it suggests a broader scope of functionality than the core Sage library actually has, e.g., Matlab involves a ton of functionality (simulink) that has nothing to do with the Sage library, at least. |
|
I agree that the original mission statement has served us greatly and is still good. On the other hand, Sage has grown so big that the competitive and inferiority complex mindset against Magma, Maple, Mathematica and Matlab is now inappropriate. In revising the Sage documentation, I removed a few sentences from such sentiments. So I suggest (we are) "Creating open source mathematics software in Python ecosystem". Maybe Python is an implementation detail, but it is also true that Python is the primary reason that Sage exists. |
|
Keywords I care about:
So that could make something like: "Sharing, integrating, and leveraging libre computational mathematics" or: "libre integrated computational mathematics at the fingertips of all" |
|
concerning:
This is a point where one needs to tread with care and respect: we use and interface with other projects but don't necessarily "incorporate them", which could mean "manage and lead their development". Even seamless interfacing can step on toes: once it's so smooth that people don't realize what is being used, it becomes harder for people to properly reference the actual software being used. If research software is not properly referenced, the developers lose citations and have a harder time getting funded, because the impact of their work becomes less visible. There have been attempts with various success to make it easier in sage to find what code was used for a given computation so that proper citations can be generated. The way we deal with software not directly and explicitly contributed to sage must be handled with care. Also, the statement is a description of a fact about sage. It's not part of its mission. If you formulate it more aspirationally "to incorporate ... and make them all accessible in a single uniform computing environment" you see it's more something for a United Nations of Mathematical Software and would be mainly a political body that would need representation and input from all incorporated projects. I don't think that's what we're striving for or set up for to do successfully. |
I think this is too narrow because implicitly it says "we're making academic code that is not suitable for production use". This may not matter for some highly specialized areas of pure mathematics, but it does for areas such as graph theory, polyhedral geometry, ... |
|
@nbruin 's point is well taken. I think it would it be better to simply say:
I think that is something Sage does, and also a part of its mission, related to not re-inventing wheels. |
|
As @tornaria said, I think we need to have the mission statement be short and catchy. In particular, IMO we should avoid legalese and detail. We could have a separate long-form detailed explanation, but the mission statement is basically our community's elevator pitch. What @mkoeppe is saying about production use is crystalizing a part I couldn't express concisely for the portion that is not research and teaching. I vehemently disagree with the implications of academic code is never suitable for production use. That being said, I fully agree with the sentiment that our mission statement should have something for people who want to use Sage for, e.g., "real world" applications. I just don't yet see a short catchphrase for this... |
|
it's worth having a look how SciPy presents itself: Fundamental algorithms for scientific computing in Python Or SymPy SymPy is a Python library for symbolic mathematics... Or GAP Groups, Algorithms, Programming - Or Macaulay2 : Macaulay2 is a software system devoted to supporting research in algebraic geometry and commutative algebra... It seems that not stating that Sage is Python-based implies that it uses its own language... |
To clarify: I did not object to this! Just to avoid using wording that implies that you need extensive Python experience to use Sage. |
|
On behalf of @sheerluck, who can't login to GH, I post this here: Considering the transformation of Sage into a system of modern Python libraries, the new mission statement could be: "Empowering the world with open-source Python libraries for mathematical computation." This mission statement reflects the shift in Sage's focus from being a standalone application to a collection of Python libraries. It emphasizes the open-source nature of Sage, its commitment to providing tools for mathematical computation, and its goal to empower users globally. This mission statement is short, catchy, and clearly communicates Sage's new focus and goals. It provides a concise and compelling overview of what Sage is, what it does, and why it matters. |
|
I think this discussion has wandered off course. Catchy slogans definitely have their place and purpose. But mission statements have a different place and purpose. As @williamstein commented above:
I don't think that catchiness helps with that. I think that clarity and some specificity can help. |
is actually not too bad |
It's good to evaluate it based on "suggests answers to questions about the direction and scope of the project". Here are some questions that the above statement tends to answer. (I'm not claiming I agree with any of the answers.)
Anyway, try testing any question you can think of related to Sage development on that mission statement and see what happens... |
|
|
I also very much like "Empower the world"! Evaluating the statement by checking whether it "suggests answers to questions about the direction and scope of the project" sounds compelling . So I tried with a couple questions.
Presumably, the balance for Q1 and Q4 could be improved by replacing "Python library" by something that would convey concisely "tightly integrated together and tightly integrated in the Python ecosystem" (yeah, whatever the latter mean). Let me try: Empower the world with libre computational mathematics software, tightly integrated together and in the Python ecosystem Hmm. Concise. Hmm. The second part could use some love. Out of curiosity, I played a bit with Chat-GPT (hmm, Chat-GPT and love in the same sentence ...). Nothing that convinced me, but for some suggestions of synonyms. E.g.: Empower the world with libre computational mathematics software, seamlessly woven together and in the Python ecosystem I ponder about adding "community developed". E.g. for a better answer to Q3. But that adds verbosity. Cheers, |
|
I think sage is still not just a python library and I think there is an important component where that is essential for its adoption: the preparser. I don't think sage would be viable as a suggestion for a CAS if it required |
|
I think sage is still not just a python library and I think there is an
important component where that is essential for its adoption: the
preparser. I don't think sage would be viable as a suggestion for a CAS if
it required ** for exponentiation. Writing polynomial input with it is
just not acceptable for many mathematicians. Hence, I don't think we should
portray sage as just a python library in its mission statement.
This is why something like "Free/Libre Mathematics Software based on
Python", many variations of which have been proposed here, is likely a
better option. It also focuses more on the math and less on the CLI import
statements, which some random researcher used to Mathematica will find
annoying and boring.
|
If one can get used to not putting |
|
Please no "libre". It is a French word. I guess that the word is less familiar than Python to non-European people. |
I prefer the general philosophy that we accommodate our potential users rather than ask them to make accommodations. |
It's also a spanish word, and so it rhymes with the "for the world" stanza. Recall that spanish is the second language by number of native speakers (mandarin first, english third). Also it's written "livre" in portuguese (fifth by number of native speakers, after Hindi, according to wikipedia). In any case, the point of using "libre" is that there is no faithful translation to english, unless you resort to shenanigans like "free as in speech" vs "free as in beer" (metaphors which sound very US-centric to me). BTW, the majority of native spanish speakers (by a very large margin, maybe 10 to 1) live outside Europe. Similar for portuguese. I don't know about french (probably not). Did you know there are about the same number of native speakers of spanish in the US than in Spain? |
|
No. But I know that there are many. Let me correct myself: "to Korean people" (due to the recent boom of learning coding and AI, of course) |
|
Let me correct myself: "to Korean people".
Also to many others! Let's not make Zamenhof's mistake in thinking that
Esperanto should sound vaguely Latinate... but seriously, if the mission
statement is in English, then probably for practical purposes either "free"
or "free/libre" is the best variant, because to most English-speaking
non-developers (and probably even to many of them if they live in the MS
ecosystem, which we must admit is a huge number), "libre" alone is not an
English word. (Or maybe "open" as in the current version?) Even FOSS or
FLOSS is something people who aren't invested in software will have to look
up in a wiktionary.
But perhaps that's bikeshedding. The bigger question is precisely who the
mission statement is aimed at. The point (to me, and it sounds like to
many others) is to reach not just developers, but primarily *users*. The
current mission statement is at least clear in this sense.
|
|
If one can get used to not putting $ around maths, one can also get used
to ** instead of ^. (or to ^ vs ^^ vs ** as in Haskell). Non-availability
Mma's, and a bit of exposure to C/C++, Fortran, Javascript, real life in
general, etc might help 😄
I prefer the general philosophy that we accommodate our potential users
rather than ask them to make accommodations.
Agreed, and for that matter it would be nice to help people who don't even
use $ or \( around their math use Sage. The f(x)=x^2 notation is golden
for selling Sage in practice, at a grass-roots level.
… Message ID: ***@***.***>
|
|
one doesn't actually need a preparser to redefine |
I made the claim that this discussion had wandered off course. Now I can rest my case. I wish you all good luck in your quest to empower the world. |
|
Empowering the world sounds like a tautology because it refers to an intrinsic human motivation. I think we shouldn't waste three words about it. Most of the above test-questions are developer oriented. We should not adress ourselves in the first lines a potential newbie reads about Sage. The questions of such a person will be totally different:
I still think that the proposal of @culler answers these questions in the best possible way. Therefore, I cite it again adding one extension (based on the popular ... with numerous examples):
|
|
Let me remind you that there are several prominent places where we can post the mission statements. (A) sagemath frontpage: https://www.sagemath.org/ For (A) and (B), we need both one mission banner (short statement) and one long mission statement. For (C), we may expand the mission statement even longer to describe the community rather than the software. Perhaps we are discussing for (A) and (B). |
|
I think the banner should be sober and to the point, without any "empower" etc. |
Since you and four others voted for #36827 (comment), I misunderstood that we're not just talking about the banner. If we just want to replace the banner, my suggestion is: Mission: To be the gateway to experimentation, exploration, learning, teaching, application and research in mathematics. Well, gateway is a metaphor again. But I think it should be culturally neutral. BTW: I also avoid cathedrals! |
It seems this discussion was probably about the overall mission statement, but it's a good point here that we might not want to have a longer mission/vision statement as a banner item, and that (in principle) those could be separate. That said, this discussion probably should be about the "bigger" version, from which the latter could be distilled once we can agree on it (if we can agree ...) |
|
Former Sage amateur user here - I randomly came across this thread and thought I'd add a relative layman's perspective. I got into Sage because it was the one stop shop for doing math without using proprietary software. I didn't need much at the time, and could have used scipy instead, but I didn't want to repeatedly scour the web for individual libraries every time I played with a new field. I was doing a math degree, and I wanted to build skills in a single system that would cater for my needs no matter what I needed in the future. And Sage was perfect for that. If you do pivot away from providing an app, and towards providing libraries, I really hope that you will also provide the app, built on top of these libraries. The app could be easy to install, maybe have an optional preparser, etc, without putting extra burden on the libraries. I stopped using Sage because Python took off in science, and I didn't want to limit myself to the Sage ecosystem. I know that I can install other packages into the Sage environment, but that feels clunky and wrong. I tend to have a single virtual environment that I use for random experimentation and prototyping, and that environment is now built around Jupyter and PyTorch, not around Sage, so whenever something more mathy piques my curiosity, I just sigh and move on. But I'd love to add Sage to my environment once that's possible. P.S. "mission statement" is a phrase that can mean many things, but we are not here to argue about language. This thread started from needing to answer questions about where to focus efforts, so I feel like William's comments about having to "suggest answers to questions" are getting insufficient attention. |
The original Sage mission statement ("Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab") appeared close to 20 years ago, and since then there were big changes in Python and non-Python maths computing landscape, as well as in Sage:
Nevertheless, one sees the (old) mission statement invoked now and then to defend the current uncontrolled growth of the number of packages, continued vendoring of most everything, etc.
Therefore the need to amend the mission statement is crucial, we don't want it to lead to complete unraveling of the project.
While I can't at the moment of writing this produce a short new version, here are few points which I see as crucial
a. Sage should be a good, economic citizen of Python universe; it should not duplicate efforts elsewhere.
Existing solutions should be reused and existing standards should be followed whenever possible. Sage currently has many complex 'customizations', that might have been improvements over the state-of-the-art solutions at the time they were introduced, but are now preventing an easy adaptation of the new standards (examples are custom package manager, custom test runner, custom doctest format, custom sphinx setup).
b. Sage (the distribution) should slim down, in view of a; e.g. there is no need to ship its own GUI or a set of compilers.
The text was updated successfully, but these errors were encountered: