No, not at all! The split of the standard library into core and platform is to empower Community members to create their own platform. Given the vast diversity that the Scala community has, everyone can benefit from creating their own platform with their unique features.
However… at this time the intent is to build the “official” Scala Platform first and then worry about supporting additional platforms at some point in the future. I think this is not the correct approach.
Assuming SPP gets off the ground I think the current one-platform approach will end up being divisive. There are very different styles of Scala programming and the Committee will need to choose one in order to provide desired consistency. At best this will make the Scala Platform irrelevant to everyone else. At worst it may cause anger and further fragmentation of the community. It also sets up a single point of failure: if the Committee fails to read users’ needs accurately then the Platform may end up being irrelevant even for the intended audience.
I think the idea of a Platform is interesting and probably useful, but only if it’s open to everyone. SPP should support the notion of multiple platforms immediately, not as a future concern. It should be reorganized to define platforms, tooling, and so on in a generic way; and should treat the official Scala Platform as a special case. The role of Scala Center and the Committee in managing these aspects would need to be redefined.
Is that so? I read the FAQ as “we create one platform, you can create yours and we’re already supporting you”. What is wrong with that, specifically? Would there be a problem with that today? Or are you asking the Scala Center to support other platforms?
I have found a few but I’m not sure I got what you’re thinking:
The Scala Center promises some limited resources only to the Scala Platform (for instance, their Drone CI support). But they’re resources are limited, so they can’t commit to supporting arbitrary many platforms.
More importantly, I’d expect other platforms would probably want more freedom.
The common tools are designed for the Scala Platform and not the other ones. In principle that might be a problem.
Some documentation should indeed be more generic. For instance, I care most about clear stability guarantees for users—so users get from the platform stability similar to that of a standard library.
Right now, those talk about “the Scala Platform” instead of being generic in multiple platforms. I’ll agree that’s an issue, and it seems the sort of thing you talk about specifically, but is that it? https://scalacenter.github.io/platform-staging/platform.html
There is no apparent mechanism to create your own platform, nor any other mention of this possibility in the documentation. Of course anyone can do whatever they want, but my point is that the notion of a platform, and the tooling and end-user machinery (which remains undefined) should be generic so other orgs can create platforms that work the same way. The process and dedicated infrastructure for the SPP-controlled Scala Platform should be an orthogonal concern.
Based on conversations with @jvican this is a desired outcome and something he has been thinking about, but isn’t a short-term goal. I think it should be.
If the Scala Platform is just one of many and this is abundantly clear to everyone then I think things will go [more] smoothly. But if it’s seen as the one true and holy platform I think people will fight about what goes in, or (more likely) will simply ignore SPP and go on doing what they have been doing and this will end up being a waste of time.
FWIW, I support the idea of making it easy for others to adopt the platform tools for their own platform(s) as soon as practical.
But the Scala Platform should come first because there are likely to be various bugs and pain points, and using it for the Scala Platform should allow most of those to be caught and fixed before they’re inflicted on someone else.
Once we can legitimately say, “Hey, empirically, this works pretty okay!” then we should get the tooling into the hands of anyone who wants it as quickly as we’re able.
The infrastructure we have brought together (and continue to work on) is not closed to the Scala Platform. The text that you quoted was written to make it clear that we don’t favor only the Scala Platform. The intent has always been for other platforms to reuse this infrastructure. That said, these tools are open and available to everyone in Scala community. Our plan is to to design the infrastructure around the Platform with genericity in mind. The idea is that it’s used by any Platform alike, be it the Scala Platform or not. For instance, a good candidate for this is the sbt plugin to help developers depend on Platforms. We haven’t figured out all the details yet, but sbt primitives like usePlatform(MyPlatform, "0.1") will be extensible by third parties. The same will apply for primitives to fetch concrete collection of modules within a Platform, instead of getting the whole jar.
You write:
However… at this time the intent is to build the “official” Scala Platform first and then worry about supporting additional platforms at some point in the future. I think this is not the correct approach.
This simply isn’t true. We’ve built this infrastructure and intend it to be used for any other platform. Sure, I’m personally focused on putting the Scala Platform Process together because this is one of my roles at the Scala Center. But that doesn’t mean someone somewhere else is somehow prohibited from defining their own platform and reusing this infrastructure.
I don’t see, though, why you propose to change the SPP. The Scala Platform process, as well as the Committee, are documents that define the Scala Platform and encode its goals, rules and expectations. Why do you propose that the role of the Committee should be redefined? Perhaps you can give some examples of sections of the Process you’d like to see changed so that I fully understand what you mean?
To sum up, the infrastructure is independent of this process. The SPP process documents as written are written to define the Scala Platform Process, so it makes sense that rationale about how decisions be made and how committees are formed are specific to the Scala Platform. If someone would like to define an alternate platform, then I would expect a similar process document to be written to define the goals, rules, and expectations of how modules are introduced and maintained for that platform.
Just to restate; we mean to enable several platforms. This is a goal that we seem to share. Things like sbt integration are definitely going to be designed with genericity in mind and hope that the Community help us nail them down!