Detaching Swift-only components like
Data structs API designs from Foundation would be great.
Detaching Swift-only components like
Right, this I think is one of the cruxes people have with Foundation. Because its evolution is decided internally by Apple, we currently don't have a "Foundation" that would be open to new types, new methods etc that can be put through evolution. And if we were going to move types out of Foundation proper and into some other place, I would want that other place to be governed by SE, thereby allowing for a more powerful and robust Swift Foundation to evolve in the open.
What I want to explore is precisely why it would be great; we’ve gone over some points above, but I think those points can be looked at without necessarily moving these types or splitting Foundation in this particular way.
I mean decisions would be made through evolution.
That would be really bad. Evolution already is very toxic for the development of Swift itself. I surely don’t want this process getting influence on macOS and iOS.
This topic might share a lot of goals with this?
Please can you elaborate ?
The Evolution process misses a strong lead and vision. So development of Swift moves very chaotic and not targeted. Beside that there are the ever present bikeshedding wars. Both not something I want for macOS/iOS APIs.
I believe this is only partially true.
Each version of swift has has a specific goal in mind (ie: ABI stability for swift 5). This primary objective has been a motivating factor behind several proposal acceptions/rejections of which I've been following.
That being said, I do understand why you feel that development is chaotic. A large amount of the proposals are created because of what a single contributor feels like working on and pitching to the community. There isn't always a long-term goal and many proposals start as, "I like/want/need this feature, so I'll see if others agree that we should add it." There is some oversight from the core team, but many times that oversight boils down to a simple decision of "does this actively harm our long term goal for swift?" If not, then it's usually accepted.
This is true of any development where there is more than a single developer though (and sometimes even when there is only one dev). It's impossible to avoid bike shedding and as long as it doesn't go on for too long I don't see the harm (of course we may draw the line for what qualifies as "too long" in different places).
I would already be glad if a clear long term design goal would be decided on and communicated. It would remove a lot of chaos, imo. A kind of open mission statement.
I'm in complete agreement with you here. "World Domination" is not exactly the most specific goal
Although I do think the core team is realizing that they need to give more specific long term goals to the community and the following posts/threads are proof that long term goals are becoming more important:
These show that the core team is trying to formulate the long-term swift (and swift.org) goals by getting feedback from the community. I'm sure there will be more announcements in the future once the actual mission statement has been decided on by the core team.
The long-term goal as stated on https://swift.org/about/ is:
The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services. Most importantly, Swift is designed to make writing and maintaining correct programs easier for the developer. To achieve this goal, we believe that the most obvious way to write Swift code must also be:
Safe. The most obvious way to write code should also behave in a safe manner. Undefined behavior is the enemy of safety, and developer mistakes should be caught before software is in production. Opting for safety sometimes means Swift will feel strict, but we believe that clarity saves time in the long run.
Fast. Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). As such, Swift must be comparable to those languages in performance for most tasks. Performance must also be predictable and consistent, not just fast in short bursts that require clean-up later. There are lots of languages with novel features — being fast is rare.
Expressive. Swift benefits from decades of advancement in computer science to offer syntax that is a joy to use, with modern features developers expect. But Swift is never done. We will monitor language advancements and embrace what works, continually evolving to make Swift even better.
What do you feel is lacking from this goal statement?
Just saying that Swift aims to be safe, fast, and expressive is a very general statement. I'm sure everyone here could define those 3 things differently. Which is probably why the "Expressive" section states:
Basically what I glean from those goals is that Swift is always changing and the end goal is really a moving target. Nothing concrete about what is actually being done to/for swift.
I think what many developers (like myself) are looking for is a more specific set of goals. Yes, those are the general goals of the swift language as a whole, but what is being done to achieve those? What does it take to say that my idea for a proposal matches the criteria of being safe, expressive, and fast?
How are we replacing C-based languages across multiple platforms? (Or at least how have we enabled them to be replaced?) What APIs are being/should be written to make swift more expressive and easier/safer to use? Which algorithms are commonly implemented in other languages that Swift is working to implement "faster" and/or "safer"? And the best question (or at least my personal favorite), when are all of these things being implemented in swift?
I'm not alone in saying I want the specifics of what can be/is being done to achieve those very broad goals. I'm sure that whatever list of specifics we come up with today will be different a year from now, but breaking down the broad, generic goals into a smaller set of achievable goals can help give a lot of direction and comfort to the community.
There's a lot more that goes into making swift as a whole safe, fast, and expressive than just making new things safe, fast, and expressive.
"Safe, fast and expressive" isn't the goal, they are design principles. Questions of how or when aren't about goals either, they are about plans (and I agree completely that the core team could be more specific here).
The goal, as stated, is that Swift should be "the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services."
Personally, I think that goal is vague since there is no prioritization between systems programming, apps and cloud services. Things that are unproblematic on iOS and macOS, e.g. important APIs only being available in Foundation, are problematic in the cloud. And other things that make iOS and macOS development possible, e.g Obj-C interop and AnyObject lookup, might be long-term hindrances for systems programming.
I would like for example a clear long time commitment to oop - This would remove all the bad dissing you get from parts of the community when you want to use it. It often feels like oop is a third class citizen of Swift.
No one is going to remove classes and inheritance from Swift, and that's all OOP really is, from the perspective of syntax.
There is a difference between retaining the syntax and being fought by the community because you want to use it. I have often heard here that oop sucks, is dead and inferior to value types and functional programming. That's not a clear commitment to oop in Swift.
A clear commitment by the core team that oop is a equal part of Swift would enable to point at the statement when people start with the oop hate.
I fear I'm not good at putting in words what I intend to say so of something is unclear just ask for clarification.
There is no silver bullet, different languages prioritise different things. For example, the fact that fatal errors are unrecoverable is a big problem for server-based applications (you need to build some infrastructure around it so that an illegal array access or integer overflow doesn't just halt your entire service), while it probably makes a lot more sense for iOS/macOS (the user can just restart the App). Similarly, the choice of ARC vs. GC is not "superior" but a clear tradeoff between predictable performance and not requiring users to deal with low-level details such as retain cycles; one which, I think, makes much more sense for certain types of applications than for others.
A young language, just like a political party, becomes the surface onto which people with very different desires, needs and philosophies project their ideas. We're already seeing this with some people wanting to push traditional (Java-like) OOP, asking for things like abstract classes, a
protected modifier, etc., whereas others try to push FP and would like to see HKTs and so on; yet other people seem to want Swift to be much closer to the metal and want to implement parts of Rust's borrow checker.
Ultimately, I think, the language will have to decide what it wants to be.
I think you’re confusing love of fp with hatred for oop. The latter isn’t going anywhere in Swift, but a lot of patterns are objectively better solved using fp, and pointing that out, is not the same as hating oop. The opposite is also true.
I would be wary about throwing around terms like "objectively" so easily. Whatever studies there are about FP vs OOP productivity are very inconclusive, to my knowledge (which is to be expected, there are way too many confounders).